Hab was gefunden -LOL [Archiv]

Demirug

2002-11-28, 08:08:33

Wieso angeblich?

Die CPUs gab es wirklich. Der i860XP war die Multiprozessortaugliche Weiterentwicklung des i860. Da sich die Intel RISC CPUs aber nie richtig durchsetzten konnten wurde die weiterentwicklung gestoppt.

Das i860 Chipset kann man übrigend dort bewundern http://www.digit-life.com/articles/pentium4xeonsmp/

Endorphine

2002-11-28, 10:37:22

Intel stellt ja nicht nur CISC-CPUs, ARM-CPUs, Chipsätze, Netzwerkcontroller, Flashspeicher und Pheripherie wie Webcams her. Auch RISC-CPUs wie der i860/i960 zählen zum Programm.

BlackBirdSR

2002-11-28, 10:47:39

Originally posted by Endorphine
Intel stellt ja nicht nur CISC-CPUs, ARM-CPUs, Chipsätze, Netzwerkcontroller, Flashspeicher und Pheripherie wie Webcams her. Auch RISC-CPUs wie der i860/i960 zählen zum Programm.

ist eigentlich keiner der Meinung man sollte diesen CISC / RISC Schmarn mal fallen lassen und die neuen CPUs meinetwegen auf der Basis der alten Einteilung neu definieren?

Klar sind x86 nach aussen hin CISC, aber nach dem Frontend ists damit einfach vorbei.
Genausowenig sind heuteige Alphas oder PAs noch wirklich RISC CPUs im eigentliche Sinne.

leider halten sich die beiden Begriffe genauso standhaft wie das Vorurteil RISC ist immerschneller als CISC.
Wobei hier imlizit gemeint ist, dass alle halbwegs RSIC ähnlichen CPUs immer schneller und besser sind als alle x86.

naja meine Meinung dazu.. man sollte es mal neudefinieren.

zeckensack

2002-11-28, 12:29:51

... oder jedem der wild mit diesen Begriffen um sich wirft mal mindestens drei Stunden Arstechnica (http://www.arstechnica.com/) verordnen :|

Endorphine

2002-11-28, 12:49:53

Originally posted by BlackBirdSR

ist eigentlich keiner der Meinung man sollte diesen CISC / RISC Schmarn mal fallen lassen und die neuen CPUs meinetwegen auf der Basis der alten Einteilung neu definieren?

Klar sind x86 nach aussen hin CISC, aber nach dem Frontend ists damit einfach vorbei.
Genausowenig sind heuteige Alphas oder PAs noch wirklich RISC CPUs im eigentliche Sinne.

leider halten sich die beiden Begriffe genauso standhaft wie das Vorurteil RISC ist immerschneller als CISC.
Wobei hier imlizit gemeint ist, dass alle halbwegs RSIC ähnlichen CPUs immer schneller und besser sind als alle x86.

naja meine Meinung dazu.. man sollte es mal neudefinieren.

Hmm, warum sollte man etwas neu definieren, wenn doch schon die derzeitige Definition eindeutig ist? *grübel*
Ich sehe da irgendwie keinen Sinn drin. Wer um solche Details weiss, kann in der Regel auch mit beiden Verfahrensweisen etwas anfangen.
Und wenn - was würdest du denn neu definieren wollen? Und mit welchem Ziel würdest du es neu definieren wollen?

BlackBirdSR

2002-11-28, 14:01:05

Originally posted by Endorphine

Hmm, warum sollte man etwas neu definieren, wenn doch schon die derzeitige Definition eindeutig ist? *grübel*
Ich sehe da irgendwie keinen Sinn drin. Wer um solche Details weiss, kann in der Regel auch mit beiden Verfahrensweisen etwas anfangen.
Und wenn - was würdest du denn neu definieren wollen? Und mit welchem Ziel würdest du es neu definieren wollen?

es ibt einfach zu viele Instanzen wo CISC und RISC falsch benutzt werden.
Sei es nun um diskussionen hinsichtlich G3/G4 vs x86 oder jetzt mit den aufkommenden Xeons/Opterons gegen Sparcs/IA64.

Es heisst dann ganz spontan, CISC.. seit den ersten Intel CPUs, lahm, heiss.
RISC sind diese Monster Server CPUs, die sind deshalb viel schneller besser.

Ausserdem sind die Begriffe an sich zum großen Teil nur noch eine Farce. RISC als Design Philosophie gibt es eigentlich kaum noch, und schon gar nicht in den groß angepriesene "RISC" CPUs wie Alpha, Sparc, PA-RISC, MIPS.

x86 CPUs nutzen intern eine Menge der selben Features die auch diese angeblichen RISC CPUs nutzen.

kann man da wirklich noch CISC und RISC sagen? wo ist der Unterschied in der Architektur?, es geht nur noch um eine äussere Repräsentation die aber über die Innenwerte gar nichts mehr aussagt.

Muss man, nur weil man es besser weiss dehalb trotzdem die "falschen" Begriffe verwenden?

Unregistered

2002-11-28, 15:17:04

eine frage hätte ich ... weiß nich ob es hiermit zusammenhängt oder nicht,
wie zum geier ist es möglich daß eine handelsübliche ultrasparc-cpu bei weniger transistoren, geringerem takt und niedrigerer leistungsaufnahme schneller ist als jede desktop-cpu ?!
was machen intel und amd denn da falsch ?

zeckensack

2002-11-28, 15:21:21

Ganz einfach, sie ist es nicht :bäh:

Unregistered

2002-11-28, 15:27:12

hm, hab mal irgendwo gelesen daß ne 1,2er us integer doppelt so schnell und fp 5mal so schnell wien p4 2,4 sein soll...
kann mich allerdings nich mehr erinnern wo... war wohl die computerbild ;)

BlackBirdSR

2002-11-28, 16:11:54

Originally posted by Unregistered
hm, hab mal irgendwo gelesen daß ne 1,2er us integer doppelt so schnell und fp 5mal so schnell wien p4 2,4 sein soll...
kann mich allerdings nich mehr erinnern wo... war wohl die computerbild ;)
hab leider keinen Wert von einem 1.2 USIII aber 1050MHZ tuns vielleicht auch ;) Alle Werte sind PEAK Werte, damit jeder Hersteller max. and die CPU anpassen kann.

SpecInt
CPU: 1 MHZ: 1050 NAME: UltraSPARC-III Cu INT 610
CPU: 1 MHZ: 2400 NAME: Pentium 4 INT 927
CPU: 1 MHZ: 2000 NAME: Athlon XP INT 808

SpecFP
CPU: 1 MHZ: 1050 NAME: UltraSPARC-III Cu FP 827
CPU: 1 MHZ: 2400 NAME: Pentium 4 FP 964
CPU: 1 MHZ: 2000 NAME: Athlon XP FP 693

zum Vergleich noch der SparcV64 von Fujitsu, der aber nicht mehr unbedingt viel mit den US3 zutun hat und nicht von SUN kommt ;)

CPU: 1 MHZ: 1350 NAME: SPARC64 V INT 847
CPU: 1 MHZ: 1350 NAME: SPARC64 V FP 1205

also auf 3xint und 5xfp komm ich nicht gerade :D

Unregistered

2002-11-28, 17:34:42

p4 fp > xp fp ?!
hä ?

0190

2002-11-28, 17:47:37

Originally posted by Unregistered
p4 fp > xp fp ?!
hä ?

P4 und XP Fließkommaleistung. Was ist daran so schwer zu verstehen?

Unregistered

2002-11-28, 18:09:33

Ich denke mal daß er das schon verstanden hat ;)
vielmehr wird ihn wohl wundern daß laut den genannten Werten die FPU des P4 schneller sein soll als die des Athlon XP, was ja nun nicht so unbedingt stimmt :)

0190

2002-11-28, 18:15:01

Originally posted by Unregistered
Ich denke mal daß er das schon verstanden hat ;)
vielmehr wird ihn wohl wundern daß laut den genannten Werten die FPU des P4 schneller sein soll als die des Athlon XP, was ja nun nicht so unbedingt stimmt :)

Hm, vielleicht tritt dort ein Athlon 2000+ (1xxx Mhz?) gegen einen P4 2400 Mhz an?

BlackBirdSR

2002-11-28, 18:28:43

Originally posted by 0190

Hm, vielleicht tritt dort ein Athlon 2000+ (1xxx Mhz?) gegen einen P4 2400 Mhz an?
nein es ist ein 2000MHZ Tbred.

Vielmehr basieren SPECFP Werte nicht nur auf purer Berechnung von komplexen Daten, sondern auch auf sehr großen Datenblöcken.
Der P4 macht durch seinen superben L2Cache, Speicherbandbreite, TraceCache und prinzipiellen Aufbau extrem viel Boden gut, da einige der Tests sehr viel Wert auf Streaming legen.

Der K7 hat bekanntermaßen schwere Probleme die FPUs mit Daten zu versorgen wenn es um große weniger komplexe aber viele Berechnungen geht.
Genau daauf zielen die meisten Änderungen am K8 darauf ab, dem AUsführenden Teil des Kerns viel mehr Daten zu verabreichen.

Das sieht dann nach AMDs Angaben so aus:

CPU: 1 MHZ: 2000 NAME: AMD Opteron 1MB L2 Cache INT: 1202
CPU: 1 MHZ: 2000 NAME: AMD Opteron 1MB L2 Cache FP: 1170

sieht doch auch bei FP wieder ganz gut aus oder? ;)

Muh-sagt-die-Kuh

2002-11-28, 19:23:42

Originally posted by BlackBirdSR
Das sieht dann nach AMDs Angaben so aus:

CPU: 1 MHZ: 2000 NAME: AMD Opteron 1MB L2 Cache INT: 1202
CPU: 1 MHZ: 2000 NAME: AMD Opteron 1MB L2 Cache FP: 1170

sieht doch auch bei FP wieder ganz gut aus oder? ;) Zum Vergleich mal die Daten eines 1 Ghz Itanium 2 mit 3 MB L2 Cache:

CPU: 1 MHZ: 1000 NAME: Intel Itanium 2 3MB L2 Cache INT: 807
CPU: 1 MHZ: 1000 NAME: Intel Itanium 2 3MB L2 Cache FP: 1356

Hinweis: Hierbei handelt es sich um "base" Werte, also compiliert mit identischen Compilerflags für jeden Teilbenchmark.

BlackBirdSR

2002-11-28, 20:21:48

Originally posted by Muh-sagt-die-Kuh
Zum Vergleich mal die Daten eines 1 Ghz Itanium 2 mit 3 MB L2 Cache:

CPU: 1 MHZ: 1000 NAME: Intel Itanium 2 3MB L2 Cache INT: 807
CPU: 1 MHZ: 1000 NAME: Intel Itanium 2 3MB L2 Cache FP: 1356

Hinweis: Hierbei handelt es sich um "base" Werte, also compiliert mit identischen Compilerflags für jeden Teilbenchmark.

du kannst doch keine Base werte nehmen :chainsaw:

ich hab oben nur peaks.. und der Opteron hat keine Ahnung ob Base oder Peak, Chaos pur :D
naja ich seh gerade die eingetragenen Peak werte sind für den Itanium2 gleich den Baser Werten..

GloomY

2002-11-29, 03:55:41

Mal davon abgesehn, dass der Itanium2 mit seinen >270 Mio Transistoren weitaus mehr kostet als der Opteron von AMD...

Endorphine

2002-11-29, 09:09:59

Originally posted by GloomY
Mal davon abgesehn, dass der Itanium2 mit seinen >270 Mio Transistoren weitaus mehr kostet als der Opteron von AMD...

Wenn du die Taktfrequenz und die Skalierung berücksichtigst, ist der Itanium die wesentlich leistungsfähigere Architektur. Nur eben - wie so oft bei Intel - viel zu ehrgeizig und der Zeit voraus. So wie RDRAM 1998 auch noch nicht reif für den Markt war.

BlackBirdSR

2002-11-29, 09:55:35

Originally posted by Endorphine

Wenn du die Taktfrequenz und die Skalierung berücksichtigst, ist der Itanium die wesentlich leistungsfähigere Architektur. Nur eben - wie so oft bei Intel - viel zu ehrgeizig und der Zeit voraus. So wie RDRAM 1998 auch noch nicht reif für den Markt war.

ich denke niemand bezweifelt dass IA64 sehr schnell ist.
Das Problem bis jetzt sind nur die horror Kosten, der niedrige Takt und der große Software / Umstellungsaufwand.

Madison wird 1.5GHZ haben, und durch noch mehr Cache wird IA64 auch zweifelsohne ganz vorne mitspielen.
Die Frage ist nur... sind genug Leute bereit den Preis zu zahlen und die Umstellung über sich ergehen zu lassen?

dass IA64 seiner Zeit vorraus ist würde ich nicht sagen..
klar ist es jetzt gerade fehl am Platz.. aber wenn nicht jetzt wann dann?
IA64 entwickelt sich mit BruteForce richtung SuperCPU und wenn es dann gebraucht/gewollt werden sollte ist es vorhanden, bewährt und anständig ausgereizt.
Würde Intel die CPU später bringen müsste man diese Entwicklungsprozess ebven später durchmachen, was dann härtere Konkurrenten bedeutet.

zeckensack

2002-11-29, 16:12:05

Wenn man sich den enormen Aufwand an Transistoren und Cache und nicht zuletzt Die-Fläche und Geld ansieht, dann wäre es auch einfach nur ein Armutszeugnis wenn IA64#3 nicht konkurrenzfähig schnell wäre.

Man muß einfach nur mal über den Tellerrand schauen, mit wie wenig Aufwand im Vergleich die Konkurrenz zu ähnlichen Ergebnissen kommt.

IA64 ist in meinen Augen ein bereits gescheitertes Experiment, das Intel nur aus Sturheit noch am Leben hält.

GloomY

2002-11-29, 16:38:52

Originally posted by zeckensack
Wenn man sich den enormen Aufwand an Transistoren und Cache und nicht zuletzt Die-Fläche und Geld ansieht, dann wäre es auch einfach nur ein Armutszeugnis wenn IA64#3 nicht konkurrenzfähig schnell wäre.lol @ "IA64#3" :lol:

Zum Inhalt: Ganz genau so seh' ich das auch.
Originally posted by zeckensack
Man muß einfach nur mal über den Tellerrand schauen, mit wie wenig Aufwand im Vergleich die Konkurrenz zu ähnlichen Ergebnissen kommt.

IA64 ist in meinen Augen ein bereits gescheitertes Experiment, das Intel nur aus Sturheit noch am Leben hält. Naja, vielleicht wird's ja noch was. Mal schauen, wie die Leistung des Madison aussieht. Der hat ja afaik 6 Integer Einheiten. Vielleicht kann da EPIC besser punkten...

btw: Zecki, in irgend einem (von dir gelinkten) Microprozessor Report (ist schon lang' her, ich find ihn nicht mehr) stand auch ein Artikel über EPIC drin. Wenn ich mich richtig erinnere, dann sind da auch Leute von IBM zu Wort gekommen. Ihre Meinung zu EPIC war, daß die Idee nicht umbedingt schlecht, aber es schlicht und einfach unnötig sei, dafür eine neue ISA zu entwerfen und alles bisherige umzuschmeißen. Bei Servern ginge es hauptsächlich um Bandbreite und nicht primär um ILP.

Ikon

2002-12-03, 17:49:02

Da wir eh' schon völlig OT sind:

Hat Intel die Einbrüche bei branch-intensivem Code (des Itanium1) mit dem Itanium2 eigentlich in den Griff bekommen? Oder ist das eventuell ein prinzipielles Problem von EPIC-Designs ...

BlackBirdSR

2002-12-03, 18:52:13

Originally posted by Ikon
Da wir eh' schon völlig OT sind:

Hat Intel die Einbrüche bei branch-intensivem Code (des Itanium1) mit dem Itanium2 eigentlich in den Griff bekommen? Oder ist das eventuell ein prinzipielles Problem von EPIC-Designs ...

es ist ein InOrder Design,
soweit ich verstanden habe gibt es keine Branchpredictions wie bei x86, sofern man für IA64 compiled.

x86 Code dagegen tut dem ItaniumI sehr weh.
wie das nun genau bei mcKinley assieht hat noch keiner gesehen ;)

GloomY

2002-12-03, 19:47:32

Originally posted by BlackBirdSR
es ist ein InOrder Design,
soweit ich verstanden habe gibt es keine Branchpredictions wie bei x86, sofern man für IA64 compiled.keine Branchprediction? Wie meinst du das?

Ich habe gehört/gelesen dass der Itanium immer beide Wege einer möglichen Verzweigung nimmt, und alle Möglichkeiten durchrechnet, bis er weiss, welcher der richtige "Weg" ist.

Muh-sagt-die-Kuh

2002-12-03, 19:52:27

Originally posted by GloomY
Ich habe gehört/gelesen dass der Itanium immer beide Wege einer möglichen Verzweigung nimmt, und alle Möglichkeiten durchrechnet, bis er weiss, welcher der richtige "Weg" ist. Jep, er berechnet parallel beide Zweige einer Verzweigung. Der falsche Weg wird, sobald der Branch-Zweig feststeht, einfach verworfen.