Fragen zu C3

[L. Trotzkij]

Kann mir jmd. mal ne Seite nennen, wo ich alle Versionen des Prozessors zu sehen bekomme, und die Kompatibilität zu PPGA, FCPGA und FCPGA2 Boards.

Danke

[Stone2001]

Original geschrieben von L. Trotzkij
Kann mir jmd. mal ne Seite nennen, wo ich alle Versionen des Prozessors zu sehen bekomme, und die Kompatibilität zu PPGA, FCPGA und FCPGA2 Boards.

Danke
hmm, schonmal auf der Via Homepage nachgeschaut? http://www.via-tech.de/c3.htm

[L. Trotzkij]

Habe ich.
Auf der Englischsprachigen steht aber nichts, bzw. nicht mehr als auf der Deutschen, die du genannt hast.

Möchte gerne so ne Übersicht über alle bisher erschienenen C3 Prozessoren, wg. der Kompatibilität zu den S370 Boards.

[Stone2001]

Naja, bei Via gibt es eine Liste mit Mainboards, auf denen die C3s laufen. Vielleicht hilft dir die weiter!

[Endorphine]

Original geschrieben von L. Trotzkij
Kann mir jmd. mal ne Seite nennen, wo ich alle Versionen des Prozessors zu sehen bekomme, und die Kompatibilität zu PPGA, FCPGA und FCPGA2 Boards.

Danke Wofür brauchst du denn die Informationen? Vielleicht kann ich dir auch ohne Tabellen helfen, habe mich etwas in die Materie eingearbeitet.

p.s. Diese Tabelle (http://users.erols.com/chare/elec.htm) beinhaltet auch alle aktuell erhältlichen C3-Typen bis auf den noch nicht ausgelieferten C5P nano-BGA (ganz runter scrollen). :)

[L. Trotzkij]

Naja, also ich hab hier so ein Micro ATX Board mit i810 DC-100(mit externem Grafikspeicher).
Der Vorbesitzer hat ein paar Microcode Updates geladen, so dass auch FCPGA Celerons laufen.
Wenn der C3 nun max. diesen Sockeltyp nutzt, sollte ja eigentlich jede Version laufen (Nehemiah, Ezra)?

Wie ist eigentlich die Chronik, sprich was war die erste Version?
Erst Samuel, denn Joshua kam nie raus, dann Sam 2, Ezra, Ezra T und Nehemiah?
Wo besteht der Unterschied in den Kernen, wie stark ist der Nehemiah oder auch der Ezra verbessert?

[BubbleBoy]

.

[L. Trotzkij]

ahh fuck.
Dann hat erst der Nehemiah SSE?

Also nach deiner Einschätzung wäre nur der Ezra normal funktionstauglich(ich habe FCPGA1)?

[Endorphine]

Original geschrieben von L. Trotzkij
Dann hat erst der Nehemiah SSE? Korrekt. Die Vorgänger haben nur 3Dnow. Original geschrieben von L. Trotzkij Also nach deiner Einschätzung wäre nur der Ezra normal funktionstauglich(ich habe FCPGA1)? ... und den gibt es als CPGA nur bis 866 MHz. Zwar nimmt er als C3-866A nur maximal 9,6 Watt auf, dürfte aber keine Leistungsrekorde aufstellen. Die FPU des Ezra ist zudem noch mal halb so "langsam" wie die des Nehemiah, sie läuft nur mit halbem Kerntakt.

[Quasar]

Original geschrieben von Endorphine
Zwar nimmt er als C3-866A nur maximal 9,6 Watt auf, dürfte aber keine Leistungsrekorde aufstellen.

Doch so "viel"? Ich hätte eigentlich etwas weniger erhofft. Da sind ja einige Celerons ziemlich dicht dran mit 11,2W bei 1,5v und 566MHz (Falls Bedarf an der Info besteht: die laufen auch mit einem Pups-Kühler [Verzeihung] noch passiv).


Wie schaut's bei den C3 eigentlich generell mit undervolting aus? Vertragen die das noch oder sind die schon am Limit?

[L. Trotzkij]

Dann wärs wohl das Beste nen Celeron 533/-66 zu suchen denn der hat ne bessere FPU, was für einen Video PC sicherlich besser ist, oder?
Außerdem habe ich ja schon Benchmarks des Nehemiah gesehen, also auch FPU relevante und die krochen schon mit ihm nur so dahin, wie ist es dann erst beim Ezra?

[Endorphine]

Original geschrieben von Quasar
Doch so "viel"? Ich hätte eigentlich etwas weniger erhofft. Da sind ja einige Celerons ziemlich dicht dran mit 11,2W bei 1,5v und 566MHz (Falls Bedarf an der Info besteht: die laufen auch mit einem Pups-Kühler [Verzeihung] noch passiv).


Wie schaut's bei den C3 eigentlich generell mit undervolting aus? Vertragen die das noch oder sind die schon am Limit? Ja, generell sind auch P3-Coppermine mit FSB133 bis zu 667 MHz potentielle Konkurrenten für den C3 Nehemiah C5XL bis zu 1,2 GHz. Der C3 ist nur im Integerbereich deutlich schneller (darauf hat Centaur optimiert). Die kleinen FSB66-Celerons sind aber keine wirkliche Konkurrenz zum C3. Von der Leistungsaufnahme her schon, aber nicht von der Leistung...

Zu Undervolting kann ich dir nichts sagen, mein Board bietet keine Optionen dafür.

[Endorphine]

Original geschrieben von L. Trotzkij
Dann wärs wohl das Beste nen Celeron 533/-66 zu suchen denn der hat ne bessere FPU, was für einen Video PC sicherlich besser ist, oder? Nicht wirklich. Durch FSB66 und 128 kiB L2-Cache ist der Celeron sehr lahm. Wenn, dann einen kleinen FSB133 P3. Wobei du dann ein aktuelleres Board benötigen würdest. Original geschrieben von L. Trotzkij
Außerdem habe ich ja schon Benchmarks des Nehemiah gesehen, also auch FPU relevante und die krochen schon mit ihm nur so dahin, wie ist es dann erst beim Ezra? Ja, die FPU ist einer der Teile, die stark beschnitten wurden, um das Die und damit die Leistungsaufnahme niedrig zu halten. Der Ezra ist da wirklich sehr langsam im Vergleich zur Konkurrenz durch die halbierte Taktrate.

[Quasat]

Als ich gestern mal den besagten Celeron auf seine Temperatur überprüfen wollte und darob mal SANDRA anwarf, habe ich nebenbei auch diesen nichtsnutzigen Benchmark laufen lassen.

Erstaunt durfte ich feststellen, daß die Datenbank von S. mittlerweile wirklich umfangreich geworden ist. Neben so exotischen Dingern wie Itaniums und ARM-Prozessoren sind auch C3 mit von der Partie.

Einmal ein 1GHz Erza und ein "Cyrix III" mit 667MHz (nehme mal an, daß ist Sam).
Was SANDRA so als FPU-Whetstones ausspuckt, sieht für die C3 nicht wirklich gut aus - PPro200 Niveau +10% für den GHz-Ezra.

Endo,
Ich würde wirklich gern mal ein paar kleine Vergleiche anstellen zwischen deinem C3 und meinem Celeron. Was meinst du?

[Quasar]

Original geschrieben von Quasat
Als ich gestern mal den besagten Celeron auf seine Temperatur überprüfen wollte und darob mal SANDRA anwarf, habe ich nebenbei auch diesen nichtsnutzigen Benchmark laufen lassen.

Erstaunt durfte ich feststellen, daß die Datenbank von S. mittlerweile wirklich umfangreich geworden ist. Neben so exotischen Dingern wie Itaniums und ARM-Prozessoren sind auch C3 mit von der Partie.

Einmal ein 1GHz Erza und ein "Cyrix III" mit 667MHz (nehme mal an, daß ist Sam).
Was SANDRA so als FPU-Whetstones ausspuckt, sieht für die C3 nicht wirklich gut aus - PPro200 Niveau +10% für den GHz-Ezra.

Endo,
Ich würde wirklich gern mal ein paar kleine Vergleiche anstellen zwischen deinem C3 und meinem Celeron. Was meinst du?

Dumm, wenn man beim Einloggen telefoniert, dann passieren solche Dinge mit dem Nickname...

[Endorphine]

Kein Problem, können wir machen. :) Ich wäre nur für - ääh - nachvollziehbarere Tests als Susi Sandra. =)

Ich brauche sowieso noch Anregungen für interessante und relevante Benchmarks.

[Quasar]

Ja, aber sicher. Sandra war bei mir auch eher Zufall - gerade wegen dieser angeblich so großen Diskrepanz interessieren mich jetzt ja doch die realen Leistungen des C3.

Ich würde sagen, reine FPU-Schlachten lassen wir mal lieber bleiben, das ist zu vorhersehbar.

Eher so Sachen, wie High-Bitrate DVD gucken ruckelnd/ruckfrei usw....

Ich muss mal schauen, hatte da ein tolles QT Video, welches meinen Celeron-T auf 1000MHz zum Qualmen gebracht hat.

[thop]

Original geschrieben von BubbleBoy
Nehemiah
- 0,13 Mikrometer
- SSE statt 3DNow
- 1,4V
Ist der Nehemiah jetzt eigentlich i686 kompatibel? :gruebel: Dem Ezra fehlt ja leider irgendso ein popeliger Befehl.

Übrigens: läuft die FPU immer noch mit 1/2 Takt? Im Prinzip müsste die SSE Einheit die lahme FPU doch locker in die Tasche stecken oder? Oder taugt die SSE Einheit auch nix? Müsste man mal mit -mfpmath=387,sse oder gar nur -mfpmath=sse probieren.

[Quasar]

Guckst du hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1613595#post1613595).
So richtig flott ist das Ding noch immer nicht in der FPU, aber durch SSE kann es (von Endo auf angenommenen 1200MHz laufen gelassen) den Abstand auf meinen P3-S bei 1,5GHz (und 1,15v) von einem Viertel der Geschwindigkeit bei normaler FPU-Nutzung auf rund die Hälfte bei SSE verringern. Damit erreicht der Nehemiah fast P4-IPC-Counts *SCNR*.

[thop]

Freunde langsam sollten wir die Threads mal mergen is eh das gleiche Thema.

Jo die FPU taugt nix, ist auch nix neues. Immerhin gibs nen Boost mit SSE ... aber was ist schon SSE optimiert. Wenn mans nicht selber macht im Prinzip nix. Und was kann man in Windows selber machen ... im Prinzip auch nix ;)

Endo haste ma ffdshow ausprobiert? Das ist ja auch heftigst optimiert für 3DNow!/SSE, würd mich ma interessieren was da noch so übrig bleibt von den 1200 Mhz bei so nem Filmchen.

Interessant wäre es besonders wenn man SSE irgendwie abschalten könnte und dann lässte das ganze noch mal laufen.

[Endorphine]

Original geschrieben von thop
Ist der Nehemiah jetzt eigentlich i686 kompatibel? :gruebel: Dem Ezra fehlt ja leider irgendso ein popeliger Befehl. Welcher fehlte denn? Laut Feature Flags ist der C3 recht komplett ausgestattet. Mich enttäuscht nur der fehlende APIC (siehe Anhang). Original geschrieben von thop
Übrigens: läuft die FPU immer noch mit 1/2 Takt? Im Prinzip müsste die SSE Einheit die lahme FPU doch locker in die Tasche stecken oder? Oder taugt die SSE Einheit auch nix? Müsste man mal mit -mfpmath=387,sse oder gar nur -mfpmath=sse probieren. Die FPU läuft beim C5XL mit vollem Kerntakt. Die SSE-Einheit ist auch gut brauchbar (siehe Benchmark mit dem Mandelbrot Renderer von Zsack), wenn sie denn nur von den Programmen genutzt werden würde. Leider fragen ja die meisten Programmierer lieber CPU-Typen und Hersteller ab und entscheiden dann, ob sie erweiterte Befehlssätze einsetzen oder ob nicht. Der saubere Weg wäre über CPUid und die Feature Flags, nur scheint den kaum jemand zu gehen, meist bleibt SSE ungenutzt ausserhalb von Intelprozessoren (ebenso 3Dnow ausserhalb von AMD-Prozessoren).

[Endorphine]

Attachment vergessen. :D

[thop]

Der Ezra kann kein CMOV, aber ich sehe der Nehemiah hats jetzt :up: Könnte man also endlich für i686 optimieren (obs was bringt ist ne andere Frage). Der Linux Kernel optimiert sich ja selbst für i486 inklusive -Os (möglichst kleiner Code, angeblich wegen dem kleinen Cache) wenn man C3 Ezra angibt :o

[stickedy]

Original geschrieben von Quasat
Einmal ein 1GHz Erza und ein "Cyrix III" mit 667MHz (nehme mal an, daß ist Sam).
Was SANDRA so als FPU-Whetstones ausspuckt, sieht für die C3 nicht wirklich gut aus - PPro200 Niveau +10% für den GHz-Ezra.


Leider sagt das nicht viel aus:
Die Centaur CPUs haben einen RISC-Kern (wie alle heutigen CPUs), aber die Transformierung zwischen x86 und RISC dauert verhältnismäßig lange, da diese jedesmal neu übersetzt werden müssen (so ähnlich wie bei Transmeta). Centaur hat nur die wichtigsten (ich glaub die 90% am häufigsten gebrauchten) ausreichend schnell gestaltet, um Transistoren zu sparen.
Wenn also ein Benchmarkprogramm stupide sämtliche x86-Befehle abspult und die Ausführungsgeschwindigkeit mitprotokolliert kommt das raus, was SANDRA ermittelt ;)
RealWorld-Benchmarks sind hier das Maß der Dinge!

Ich hätte nen C3 mit 933 MHz (Ezra-T) zu bieten! Also falls dich irgendwelche Benchmarks interessieren, laß hören!

[BlackBirdSR]

Original geschrieben von stickedy
Leider sagt das nicht viel aus:
Die Centaur CPUs haben einen RISC-Kern (wie alle heutigen CPUs), aber die Transformierung zwischen x86 und RISC dauert verhältnismäßig lange, da diese jedesmal neu übersetzt werden müssen (so ähnlich wie bei Transmeta).

also das hört sich für mich an, wie beim P6/K6/(K7/8)
Die übersetzen ihre Befehle auch jedesmal neu. Mit Codemorphing hat das nichts zu tun.
Zudem der Decoder Befehle ja in einem Takt übersetzt.


Centaur hat nur die wichtigsten (ich glaub die 90% am häufigsten gebrauchten) ausreichend schnell gestaltet, um Transistoren zu sparen.
Wenn also ein Benchmarkprogramm stupide sämtliche x86-Befehle abspult und die Ausführungsgeschwindigkeit mitprotokolliert kommt das raus, was SANDRA ermittelt ;)
RealWorld-Benchmarks sind hier das Maß der Dinge!


was genau überprüft Sandra denn?
Ich kann mir nicht vorstellen, dass stipude alle x86 Befehle abgespult werden ;)

[stickedy]

Der Decoder der Centaur-CPUs übersetzt die aber nicht so schnell! Nur die häufigsten, die anderen dauern länger...
Ich stell mir das so vor, dass es bei AMD & Intel-CPUs ne Art Übersetzungstabelle gibt, so dass das ganze recht zügig von statten geht. Diese Tabelle gibt es bei den Centaur-CPUs dann nicht, zumindest nicht für den größten Teil der Instruktionen...

Zu Sandra: Gute Frage, aber es ist jedenfalls nichts, was der Realität entspricht...

[BlackBirdSR]

Original geschrieben von stickedy
Der Decoder der Centaur-CPUs übersetzt die aber nicht so schnell! Nur die häufigsten, die anderen dauern länger...
Ich stell mir das so vor, dass es bei AMD & Intel-CPUs ne Art Übersetzungstabelle gibt, so dass das ganze recht zügig von statten geht. Diese Tabelle gibt es bei den Centaur-CPUs dann nicht, zumindest nicht für den größten Teil der Instruktionen...

Zu Sandra: Gute Frage, aber es ist jedenfalls nichts, was der Realität entspricht...

Wenn es einen Takt dauert, dann übersetzt er die genau so schnell die andere CPU mit 1 Takt/Befehl.
Die weniger wichtigen Befehle (laut VIA), laufen dann eben durch den Microcode. Da ist dann im ROM gespeichert, welche Befehlsfolgen das ergibt, wie bei anderen CPUs auch.
Beim C3 laufen eben weit mehr Befehle durch das Microcode ROM als z.B beim K8.

[Endorphine]

Der x86-Dekoder ist natürlich in der Pipeline, so dass er die anderen Pipelinestufen nicht stört. Ich bezweifle, dass der Dekoder wirklich der Rechenleistungsflaschenhals beim C5XL ist. Ich denke es ist eher die Architektur insgesamt, die auf minimale Leistungsaufnahme durch ein möglichst kleines Die setzt. Das bedingt dann kleine Caches und wenige einfache Ausführungseinheiten sowie kleine Puffer. Mit insgesamt 192 kiB langsamem on-die Cache ist eben heute leistungsmässig kein Blumentopf mehr zu gewinnen. Da hilft es wenig dass der lahme L2-Cache 16-fach assoziativ ausgelegt ist.

Der C5XL ist eben ganz auf ausreichende Rechenleistung bei minimaler Leistungsaufnahme ausgelegt. :)

[stickedy]

Der Dekoder bremst ja nur bei den synthetischen Benchmarks! Für Real-World-Anwendungen und -Benchmarks macht sich das natürlich nicht bemerkbar! Das ist ja auch so gedacht...

Aber aufgrund dieser Architektur schneidet der C3 bei synthetischen Tests wie SANDRA etc. so schlecht ab...

[Endorphine]

Original geschrieben von stickedy
Der Dekoder bremst ja nur bei den synthetischen Benchmarks! Für Real-World-Anwendungen und -Benchmarks macht sich das natürlich nicht bemerkbar! Das ist ja auch so gedacht... Der Dekoder bremst gar nicht, da er in der Pipeline sitzt. :) Er würde nur bremsen wenn er mehr als einen Takt (oder bei manchen Befehlen länger) für die Dekodierung bräuchte. Das wäre mir aber neu. Wenn dem so sein sollte: wo kann man das nachlesen?

[BlackBirdSR]

Original geschrieben von Endorphine
Der Dekoder bremst gar nicht, da er in der Pipeline sitzt. :) Er würde nur bremsen wenn er mehr als einen Takt (oder bei manchen Befehlen länger) für die Dekodierung bräuchte. Das wäre mir aber neu. Wenn dem so sein sollte: wo kann man das nachlesen?

er braucht genau einen Takt nach den Via dokumenten..

das Dumme ist eben, dass alles in der CPU In-Order abläuft..

[StefanV]

Original geschrieben von BlackBirdSR
das Dumme ist eben, dass alles in der CPU In-Order abläuft..

OOO Designs sind ja auch 'etwas' Aufwendiger.

Der Haken wäre, daß man sich dadurch (aus VIAs Sicht) einige Probleme einhandeln könnte, z.B. einen höheren Energieverbrauch, ein größeres DIE...

Naja, mal abwarten, was bei der nächsten CPU Generation rauskommt...

[stickedy]

Hm... Dazu aus dem Ezra-Datasheet:
A few instructions dominate x86 instruction execution time. Over 90% of instruction execution
time is due to a few basic x86 instructions. Most x86 instructions have no significant impact on performance.
The VIA C3 Ezra processor design optimizes performance of the most important x86 instructions
while minimizing the hardware provided for the little-used x86 functions (these are primarily implemented
in microcode). The resulting instruction execution speed of highly used instructions is as
good or better than comparable processors. For example, the VIA C3 Ezra processor executes x86
load-ALU-store instructions in only one clock as compared to several clocks on other processors.
The execution time of little-used instructions is impacted to reduce die size, but this has no effect on real application performance.

Aus dem WinChip C6 Datasheet:
Good CPI on highly used instructions. The IDT WinChip C6 processor implements specific design features to reduce the number of cycles for heavily used instructions — including complex functions such as protect-mode segment-register loads and string instructions.
das:

Philosophically, this is a return to the same basic concepts of RISC design that allowed microprocessor performance breakthroughs in the 1980’s. Recently, however, contemporary x86 processors have followed a different path using very complex internal designs employing advanced architecture concepts such as superscalar execution, out-of-order instruction execution, reorder buffers, non-blocking caches, and so forth (these terms are all found in the datasheets of competitive
products).
und das:

The I-cache or bus unit delivers 16 or 8 bytes per clock to an x86 instruction buffer in the translator unit. The translator converts x86 instructions to internal instruction and data forms.
Assuming that the instruction is in the x86 instruction buffer at the start of the cycle, the translator translates an entire x86 instruction in one clock. Instruction prefixes require an additional translator cycle for each prefix. However, due to the asynchronous fetch and “lookahead” capability of the translator, these extra cycles for prefixes rarely result in a bubble in the execution pipeline.
The output of the translator is: (1) the internal micro-instruction stream to perform the x86 instruction function, (2) the immediate data fields from the x86 instruction, and (3) various x86 state information used to control execution (for example, operand size). The internal instruction stream for an x86 instruction can consist of micro-instructions directly generated by the translator, or micro-instructions from the on-chip ROM, or both. For performance-sensitive instructions, there is no delay due to access of micro-code from ROM.
The microcode ROM capacity is larger than most x86 microcode ROMs to allow more unimportant (relative to performance) functions to be performed in microcode (versus in hardware), to allow extensive self-test microcode, and to allow extensive builtin debugging aids (for processor design debug).
Instruction fetch and translator operation is made asynchronous from micro-instruction execution via a three-entry translatedinstruction queue between the translator and the execution unit. This queue allows the translator to “look-ahead” and continue translating x86 instructions even though the execution unit is stalled or is busy with a microcode sequence. The translator can also overlap generation of multiple internal instructions with translating prefixes on the subsequent
instruction.