Archiv verlassen und diese Seite im Standarddesign anzeigen : Ist der Switch von Apple zu x86 ein Fehler? Cell und PPC besser?
Verwirrter
2006-01-16, 02:11:16
Ich interessiere mich für diese neuen Intel Macs. Folglich lese ich momentan viel auf Apple-Newsseiten und in einschlägigen Foren.
Jetzt gibt es eine Fraktion von Mac Usern die behauptet, daß der ganze Switch zu Intel ein riesen Fehler sei. Manch einer behauptet sogar, daß Apple eine riesen Chance verpasst: CELL
Beispiel:
Da IBM aber in Zukunft bald nur Altivec-fähige CPUs baut und Cell _nur_ mit Vektorcode wirklich performen kann und da IBM auch zu großen Teilen für die Intelligenz in Intels Autovektorisierung verantwortlich ist (ja, ist so! Dummerweise haben die Entwickler, die sie da hingeschickt haben nen NDA unterschrieben, so dass Intel das Knowhow per Patent schützen konnte) werden wir mit den ganzen Konsolen (ja, auch die Xbox hat drei Altivec-Units!) wohl sehr bald richtig geile autovektorisierende Compiler mit massiver Eigenintelligenz sehen. Das alles verpasst Apple aber jetzt wohl leider (bzw. evtl. "lässt verpassen" weil sie die Intel-Macs nicht schlechter als die 'alten' PPC-Macs aussehen lassen können!), weil sie sich gerade wie die Party richtig lustig wurde verpisst haben, nachdem sie jahrelang die Segnungen von Altivec angepriesen haben und IBM überhaupt erst dazu überredet haben.
Quelle: http://www.macuser.de/forum/showthread.php?p=1428086#post1428086
Dann etwas anderes:
Unless Intel doesn't adopt full Altivec functionality, no pentium 64 can "replace" G5.
http://forums.macrumors.com/showpost.php?p=2061701&postcount=247
Dann gibt es hier noch eine Diskussion u.a. bzgl Cell:
http://www.macguardians.de/fullstory.php?p=4060&c=1&bereich=1
Mich würde mal interessieren was die "Experten" dazu sagen!
Vieles hört sich so "schlüssig" an. Ob es sich nur so anhört oder ob es das tatsächlich ist, kann ich selber leider nicht beurteilen oder nur sehr bedingt. Soweit mir bekannt ist, taugt Cell nicht als Desktop-CPU. Aber vielleicht sehe ich das auch nur falsch!
Cell ist als Desktop-CPU gänzlich ungeeignet. Der general purpose Kern davon kann überhaupt nicht mithalten.
Altivec ist nun wirklich nicht so wichtig wie Apple früher getan hat. Das ganze lässt sich Größtenteils auf SSE2 übertragen, das einzige Problem ist die dynamische swizzle-instruction. Auch die Performance ist vergleichbar.
Cell braucht auch keine Autovektorisierung sondern Autoparallelisierung von Code. Autovektorisierung ist noch relativ machbar, aber Autoparallelisierung ist fast unmöglich, vor allem wenn man Code in Cell-verwendbare Häppchen mit kleinem lokalen Speicher übersetzen soll.
Hmmm?
http://www.research.ibm.com/cellcompiler/compiler.htm
Dazu will ich erstmal Benchmarks sehen. Ich glaube kaum dass man normalen Code so einfach auf 1 PPU und 7 SPEs verteilen kann.
Edit: Das Ding benützt OpenMP, für die Paralleisierung ist also weiterhin der Entwickler verantwortlich.
Für die Multi-Core CPUs muß der Code doch auch parallelisiert werden, damit die effektiv genutzt werden!
Dazu will ich erstmal Benchmarks sehen. Ich glaube kaum dass man normalen Code so einfach auf 1 PPU und 7 SPEs verteilen kann.
Edit: Das Ding benützt OpenMP, für die Paralleisierung ist also weiterhin der Entwickler verantwortlich.
Jo - und bei Core DUO und Quad-Core Kentsfield (2007, das ist nächstes Jahr) macht das also der magische Intel-Compiler, ja?
Other Gast
2006-01-16, 14:59:44
Jo - und bei Core DUO und Quad-Core Kentsfield (2007, das ist nächstes Jahr) macht das also der magische Intel-Compiler, ja?
Aber auf dem Core-Duo und Quad-Core wird immerhin die bisherige Software gut und schnell laufen. Das kann man wohl von Cell nicht sagen (siehe erstes Posting Coda).
Auch wenn bisherige Software für Multi-Core CPUs zum großteil Murkscode haben mag und diese daher nicht effizient nutzt.
ShadowXX
2006-01-16, 15:16:56
Jo - und bei Core DUO und Quad-Core Kentsfield (2007, das ist nächstes Jahr) macht das also der magische Intel-Compiler, ja?
Das nicht....aber die beiden bzw. die 4 Cores sind wenigsten ordentliche GP-CPUs die auf jede menge Speicher zugreifen können und nicht wie die SPEs, die spezialisierter sind und jeder nur 256KB hat (dazu ist alles In-Order).
Der Cell wäre IMHO genial, wenn es ein Dual-G5(oder besser)+4 SPEs wäre.
Jo - und bei Core DUO und Quad-Core Kentsfield (2007, das ist nächstes Jahr) macht das also der magische Intel-Compiler, ja?Nein natürlich auch nicht. Aber die SPEs sind nochmal nen anderes Kaliber was die Schwierigkeit für den Compiler angeht.
Nein natürlich auch nicht. Aber die SPEs sind nochmal nen anderes Kaliber was die Schwierigkeit für den Compiler angeht.
Dein großes Contra-Argument gegen Cell war die Parallelisierung von Code. Du gibst zu, dass das bei Intel genauso gemacht werden muss. Also was ist übrig von deinen Contra-Cell-Argumenten?
Das Verteilen auf die SPUs und das Load/Store-Management übernimmt übrigens eben jener Octopiler... Deswegen steht da ja auch "automatically"!
Im übrigen frisst das PPE ganz normalen PPC64-Code wie der G5 auch, sogar inklusive Altivec. Und nein, es ist NICHT so lahm, wie immer getan wird, nicht vergessen: M$ hat _nur_ PPEs in seinem Xenon-Prozessor!
ShadowXX
2006-01-16, 16:48:40
Dein großes Contra-Argument gegen Cell war die Parallelisierung von Code. Du gibst zu, dass das bei Intel genauso gemacht werden muss. Also was ist übrig von deinen Contra-Cell-Argumenten?
Das Verteilen auf die SPUs und das Load/Store-Management übernimmt übrigens eben jener Octopiler... Deswegen steht da ja auch "automatically"!
Im übrigen frisst das PPE ganz normalen PPC64-Code wie der G5 auch, sogar inklusive Altivec. Und nein, es ist NICHT so lahm, wie immer getan wird, nicht vergessen: M$ hat _nur_ PPEs in seinem Xenon-Prozessor!
Im vergleich zu einen G5 oder A64/P-M ist so ein PPE lahm.
Im vergleich zu einen G5 oder A64/P-M ist so ein PPE lahm.
Kann man bei Cell nicht einfach einen solchen Kern nehmen?
Wie sieht das überhaupt mit dem Stromverbauch bei Cell aus? ;-)
Könnte man schon, aber irgendwie hat das nicht ins Konzept gepasst.
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/8300945231/m/960005245731/p/67
Ich schlag mal vor, dass ihr diesen Thread genau lest. Auf die Postings von "BadAndy" achten, der ist der Mensch dort mit dem meisten Knowhow in Sachen Chip-Tech und der hat sowohl Xenon als auch Cell und Pentium-M getestet... Er hat später im Thread auch massig Stromverbrauchs-Zahlen über PPE und SPE (90 und 65nm), und ja, aus den Komponenten KANN man einen Laptop-Prozessor bauen! Warum denn auch nicht, der riesige OOOE- und Tracking-Transistor-Wasserkopf der den ganzen Strom zieht fehlt ja!...
Hier mal ein Zitat:
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/8300945231/m/960005245731/r/611000007731#611000007731
"After that digression... I do have is FTG results for xbox360. The person who sent them to me may have violated developer agreements to send them to me (this isn't completely clear to either him or me), and specifically asked me not to distribute the data. I also have data from the PPE in a Cell ... and no surprise everything running in cache looks very similar across these two. (Given that there are no optimizations to use SPEs in the bench, and no optimizations to use the MS-proprietary altivec extensions in the xbox360 (aka "Xenon," aka "Waternoose") cores.)
Bottom line: the MP rates are impressive .... The only scores I have in my collection of weird-machine FTG results which are like them or beat them are big multi-MP.
That statement I made is correct as I see it from FTG results and I want to repeat it: per thread, xbox360 runs like a 1.25 to 1.5 Ghz G4+ ... when not bandwidth-bound, on the tests which aren't too branchy, or pure pseudo-random access.
Be clear about what I'm saying here; this is comparing performance when in L2... the "on-chip" performance of each. xbox360 sure as hell does NOT have a 'bandwidth problem." (And neither will e600+IMC)
Given 6 threads... that is a hell of a lot of computation. And that includes altivec code too... and there are some of the tasks where xbox360 could run considerably faster if the proprietary MS extensions were used (and all those extra registers). This would take recoding... not done (yet).
The PPE/Xenon cores also run scalar SP and DP a bit faster than this rough rule of scaling vs G4+ too.
Branchy-code goes a bit slower per thread ... maybe 1.0 GHz G4+ equivalent, and sparse pseudo-random access codes are on par (maybe a bit better than) today's P4/Xeon (on Linux, meaning that the sum MP throughputs are about the same, which is no surprise when you consider that these codes are just memory-subsystem exercises).
Now the particular point I have been trying to make is performance at WHAT? And if you are talking "picture bashing" algorithms, or FCP, or codecs, or anything which is reasonably compute-intensive, and coded for MP, xbox360 rates will be impressive... and the "bang/buck" will be out of sight.
If your metric is single-thread performance on Windows apps ... Anandtech demonstrates that Dothan outruns Yonah.... and yes either would outrun the PPE core ... but not by as much as you think.
[..]
And when you look at the FTG results of either a Cell PPE or a Xenon core running against this 1.6 Ghz Dothan... you see interesting things. Single-thread... it wins more than folks here would think and wins some by very big margins... more than factors of two for some. The ones the PPE/Xenon cores win are pretty obvious: the well scheduled floating point (even DP): the floating point issue rate for PPE is twice what that Dothan can sustain.
And when you look at the single-thread cases the Dothan wins... they are obvious too... ill-scheduled code where the OOOE wins, and very branchy code.
[...]
On really bad branchy single-thread code PPE is running about 70% as fast as the 1.6 GHz Dothan... that is as bad as it gets... in the FTG anyway. And it beats the Dothan on a fair amount of single-thread scalar floating point. Pseudorandom access into main memory PPE wins... but the faster Intel buses and memory since that test item probably would make that a wash, or maybe a mild win for Intel.
On altivec/SSE code PPE just clobbers Dothan. There is no explicit SSE code in the FTG (yet... I have SSE code but i don't think it's very good. But then maybe none of it is "very good" by my standards???) so this statement rests on other information, but this is on firm ground. Dothan is weak at SSE compared to P4 ... single-thread PPE altivec is running up there with single-thread 2.0 GHz 970s ... and given 6 threads the MP altivec scores are spectacular... nothing else comes close.
Generally speaking anything you can SIMD you can MP... MP is just a simpler vectorization really.
OK, so that's what the numbers show... what does it "mean?" Obviously that's in the eye of the beholder. But for folks who want to do "picture bashing,' or anything which is MP-able or SIMDable ... the Xenon multicore just blows anything Intel has right now right off the map. And roughly speaking it looks like you'd need to have a triple-core Conroe at least to get into the execution resources league.
[...]
Apple has jumped to Intel ... but this is a jump to lower performance at higher prices, for the apps that Apple has traditionally touted."
Das Problem ist wohl nur das bisherige Apps einfach nicht gut auf Cell laufen würden.
Außerdem weiß ich gar nicht wie es mit Multitasking und Cell aussieht. Praktisch müsste man bei jedem Task-Switch die SPEs neu füllen, also 2MiB Daten - ich weiß aber nicht inwiefern das ein Problem wäre/ist.
Gast2
2006-01-16, 19:40:05
Das Problem ist wohl nur das bisherige Apps einfach nicht gut auf Cell laufen würden.
Dafür hätte man doch dann als Übergangslösung den Cell nur als Coprozessor für einen Dual-Core-G5 nutzen können, bis die Software soweit ist? Wenn das vom Preis und Stromverbauch OK ist... so als Idee!
ShadowXX
2006-01-16, 20:11:33
Ich poste dann mal als Gegenthese dieses von John Carmack:
I have a quote here from Gabe Newell talking about the next generation of processors and consoles. He says “the problems of getting things running on multicore processors are not solved. We have doctoral theses but no real world applications.” Do you agree with him?
The difference between theoretical performance and real world performance on the CPU level is growing fast. On say, a regular Xbox, you can get very large fractions of theoretical performance with not a whole lot of effort. The Playstation 2 was always a mess with the multiple processors on there, but the new generations, with Cell or the Xbox 360 make it much, much worse. They can quote these incredibly high numbers of giga-flop or tera-flops or whatever, but in reality, when you do a straighforward development process on them, they’re significantly slower than a modern high end PC. It’s only by doing significant architectural work that you even have a chance of finding speed-ups to what the PC can do, let alone it’s theoretical performance. It’s only through trivial, toy or contrived applications that you can deliver the performance numbers they claim.
Und nichts anderes als das, was im letzten Satz steht, hat der aus dem vom Gast geposteten Post gemacht.
Branchy-code goes a bit slower per thread ... maybe 1.0 GHz G4+ equivalent...
Beim Branching erreicht er also die Geschwindigkeit eines G4+ mit 1GHz......das ist nicht wirklich dolle.
Android
2006-01-16, 21:11:28
Ich habe anfangs auch gedacht, dass der Wechsel zu Intel ein Fehler sein könnte. Nachdem aber immer mehr Infos durchgeflossen sind, denke ich auch, dass es die richtige Entscheidung war.
Folgende Punkte:
Überall liest man von mehreren Kernen der Cell-CPU. Wer sich jedoch mit dem Thema richtig beschäftigt erkennt schnell, dass es sich schlicht um eine modulare CPU-Architektur handelt, die dementsprechend in vielen Gebieten zum Einsatz kommen wird. So hat die Playstation 3 auch keine 7 "Kerne", sondern spezialisierte "Zellen", die fälschlicherweise als Kerne bezeichnet werden.
Der Cell hat also spezielle Einsatzgebiete, auf die er getrimmt werden kann. PC`s sind als Einsatzweck jedoch gänzlich ungeeignet.
Dieser Cell-Hype ist also ein wenig übertrieben und man sollte sich davon nicht anstecken lassen.
IBM schaffte es nicht die für Apple so psychologisch wichtigen 3GHz "praktikabel" zu erreichen. Wer sich jemals einen G5 von innen angeschaut hat und sich die Kühlung einmal näher zu Gemüte führt, wird nicht lange brauchen um hinter das Geheimniss zu kommen.
Der G5 wird zu heiss und die Architektur lässt nur minimale Taktsteigerungen zu. Auch aus diesen Gründen konnte IBM keinen Notebookprozessor bieten.
Was übrigens mitunter das schlimmste war.
Apple war schlicht unzufrieden, gerade auch im Hinblick auf die Entwicklung der PC`s, und kündigte den Vertrag mit IBM (Es scheint also ein Klausel gegeben zu haben).
Apple konnte dies deshalb so einfach, weil sie seit Beginn an parallel immer eine x86-Lösung parat hatten. Kurz: Sie sind schon die ganze Zeit zweigleisig gefahren um sich abzusichern.
Nun kamen bezüglich x86 eigentlich nur AMD und Intel in Frage.
Man schaute sich beide Plattformen an und entschied sich aus vielerlei Gründen für Intel. Eines der wichtigsten waren wohl die reichlich vorhandenen Fertigungsstätten und damit die gesicherte Kontinuität.
Nachdem Intel dann noch eine neue Architektur vorzeigen konnte (Core Duo etc. kennt ihr ja schon), welche auch noch verdammt leistungsfähig und notebooktauglich war, erledigte sich die Sache und es hiess "Apple goes Intel"
Ob es ein Fehler war ? Die Antwort ist schon da: www.apple.de
Mit Sicherheit kein Fehler, sondern eine goldrichtige Entscheidung. Apple schwärmt und ist mit ihren Macs zufriedener als je zuvor. Ich würde sagen es ist nach dem Apple II die hoffnungsreichste Plattform überhaupt.
macuser
2006-01-16, 21:38:52
@Gast: Bist du Kai von MacGuardians?
Apple konnte dies deshalb so einfach, weil sie seit Beginn an parallel immer eine x86-Lösung parat hatten. Kurz: Sie sind schon die ganze Zeit zweigleisig gefahren um sich abzusichern.
Dafür gibt es bei Betriebssystemen einen HAL. Andere Betriebssysteme laufen auf viel mehreren Plattformen als Mac OS. Und selbst Windows lief mit NT 3.51 auf X86, PPC, Alpha und MIPS. Es klingt nämlich beinahe so heraus, als ob das jetzt eine grandiose seit langem geplante strategische Leistung wäre :|
Ob es ein Fehler war ? Die Antwort ist schon da: www.apple.de
Mit Sicherheit kein Fehler, sondern eine goldrichtige Entscheidung. Apple schwärmt und ist mit ihren Macs zufriedener als je zuvor. Ich würde sagen es ist nach dem Apple II die hoffnungsreichste Plattform überhaupt.
Inwiefern soll denn Apple X86 hoffnungsvoller sein als die bisherige X86 Plattform? Ich sehe mit dem Switch auch eventuelle Nachteile. Nun kann man Apple 1:1 mit PC HW vergleichen. Bisher sagt man ja, dass Apple hauptsächlich vom HW Geschäft lebt, also Apple Rechner (den iPod mal jetzt bei Seite). Ich als Kunde käme mir nun ziemlich verarscht vor, wenn ich für die selbe HW bei anderen Angeboten wie von Dell, Aldi, Lidl etc. um ein wesentliches günstiger käme. Hinzu kommt, dass das Apple OS eine Insellösung ist und auch nur ein ganz kleines Subset an PC Peripherie unterstützt. Mit dem Wechsel zu X86 bleibt meiner Meinung nach als einziger Unterschied das OS, und ob das alleine ausreicht, bezweifle ich stark.
"It’s only by doing significant architectural work that you even have a chance of finding speed-ups to what the PC can do, let alone it’s theoretical performance."
Hm, in welcher Welt lebt Carmack eigentlich? Hat der schon mitbekommen, dass jeder High-End-PC schon heute Dualcore ist?
Die "significant architectural work" ist bei ALLEN Programmen auf ALLEN Plattformen notwendig! Er war immerhin der erste, der ein Dual-Prozessor-Game gemacht hat (Quake3), und Roadmaps kann er ja wohl noch lesen: Zukünftige Performancesteigerungen kommen NICHT mehr mit Taktsteigerung sondern mit mehr Cache und mehr Cores!
Was man unbedingt beachten muss: Carmack spricht von SPIELEN! Nicht von Encoding, nicht von Rendering und auch nicht von Echtzeit-Videofiltern oder Audioprocessing/Soundsynthese, wofür sich die Cell schon fast aufdrängt (Warum bauen die Sony und Toshiba wohl in ihre CE-Geräte?). Spiele sind traditionell singlethreaded. Wie Sony, Nintendo und M$ das Problem lösen wollen weiss ich nicht, aber ich weiss eines: Mit Cell als (Co)Prozessor könnte Apple Mediaworkstations bauen, die jenseits von gut und böse sind. Parallelisiert ist der Code, ebenso vektorisiert schon. Eigentlich die idealsten Voraussetzungen die es geben kann, aber Apple geht halt inzwischen lieber den Weg des geringsten Widerstandes in Richtung Mainstream statt sich mal hinzuhocken und ne wirklich geile Maschine mit der passenden Software zu entwickeln - was irgendwann mal das Konzept eines Macs war, aber das ist wohl schon zu lange her (eine Woche)!
"Der Cell hat also spezielle Einsatzgebiete, auf die er getrimmt werden kann. PC`s sind als Einsatzweck jedoch gänzlich ungeeignet."
Bitte logisch begründen.
"Dieser Cell-Hype ist also ein wenig übertrieben und man sollte sich davon nicht anstecken lassen."
Naja. Echtzeit-Raytracing mit 1080-HD-Auflösung und 60fps, schon irgendwie beeindruckend, oder? Oder wie wär's mit 48 MPEG-Streams gleichzeitig decodiert? Hast du den MGS4-Trailer gesehen? Oder die Toshiba-Demo, wo man quasi vor nem Spiegel stand und er hat dem Betrachter in Echtzeit ne neue Frisur aufgesetzt? Oder das hier: http://gametomorrow.com/blog/index.php/2005/11/30/gpus-vs-cell/
"IBM schaffte es nicht die für Apple so psychologisch wichtigen 3GHz "praktikabel" zu erreichen."
...Und Intel schaffte nicht die 4 GHz und schon gar nicht die geplanten 9-10 GHz mit dem Pentium 4! What's the friggin point?
"Der G5 wird zu heiss und die Architektur lässt nur minimale Taktsteigerungen zu. Auch aus diesen Gründen konnte IBM keinen Notebookprozessor bieten."
Schmarrn. http://www.macwelt.de/news/hardware/332341/index.html
16 Watt bei 1.6 GHz für nen 970FX mit 1MB Cache in 90nm, d.h. für die 31 Watt "TDP" des Core Duo hätte Apple etwa knapp unter 2GHz G5 bekommen können - Singlecore, aber wie man an den Macaddict-Test sehen kann reicht das ja schon aus! ;-)
Ach ja: IBM liefert übrigens heute schon an Entwickler erste 65nm-Samples aus - leider nur für Cell, denn Apple will ja nicht!
Das ist übrigens auch so'n Beschiss mit der TDP: Wenn das Ding zu heiss wird schaltet er einfach automatisch den Takt runter, deswegen sind die neuesten AMD- und Intel-CPUs auch _komischerweise_ alle für dieselbe "TDP" spezifiziert, auch wenn sie viele hundert MHz Unterschied haben! D.h. mit CPU-bashing-code, der das Ding voll ausfährt (und nein, dazu gehören KEINE Spiele und Anwendungen, eher Routinen aus dem High-Performance-Bereich, die teils 98% der theoretisch möglichen Leistung aus einer CPU rauskitzeln!) läuft das Ding gar nicht mehr mit dem angegebenen Takt...
Naja. Echtzeit-Raytracing mit 1080-HD-Auflösung und 60fps, schon irgendwie beeindruckend, oder?
Gehört aber auf dem Cell ins Reich der Sagen. :|
Mr. Hallo
2006-01-16, 23:17:30
soviele gäste. da blickt man ja nicht mehr durch.
...Und Intel schaffte nicht die 4 GHz und schon gar nicht die geplanten 9-10 GHz mit dem Pentium 4! What's the friggin point?
intel hätte das locker geschafft, wenn sie wirklich gewollt hätten. das sieht man auch an übertaktungsergebnissen. aber warum sollten sie auch wollen, wenn sie eh eine neue, bessere architektur jetzt haben!
[quot€]
"Der G5 wird zu heiss und die Architektur lässt nur minimale Taktsteigerungen zu. Auch aus diesen Gründen konnte IBM keinen Notebookprozessor bieten."
Schmarrn. http://www.macwelt.de/news/hardware/332341/index.html
16 Watt bei 1.6 GHz für nen 970FX mit 1MB Cache in 90nm, d.h. für die 31 Watt "TDP" des Core Duo hätte Apple etwa knapp unter 2GHz G5 bekommen können - Singlecore, aber wie man an den Macaddict-Test sehen kann reicht das ja schon aus! ;-)
[/quote]
vielleicht die neuen g5. für die alten hat er schon recht. das waren/sind bei hohen taktraten auch richtige schluckspechte was der stromverbrauch betrifft.
aber wie man an den Macaddict-Test sehen kann reicht das ja schon aus! ;-)
du meinst also diesen test? http://www.macaddict.com/forums/topic/76536
mal daran gedacht, dass sse3 evtl. nicht richtig genutzt wird? ausserdem so schlecht finde ich das ergebnis garnbicht. für den quad ist es ja wohl eher peinlich
"Das nicht....aber die beiden bzw. die 4 Cores sind wenigsten ordentliche GP-CPUs die auf jede menge Speicher zugreifen können"
a) "jede Menge speicher" - und alle gleichzeitig, denn integrierte Speichercontroller hat Intel ja erst 2009 laut Roadmap (common platform)
Das ist ja ultra-effizient, schon klar: Vier CPUs streiten sich um den Speicher, eine Neuauflage von Intels aktuellem Klassiker: Vier Cores streiten sich um einen FSB!
Wie's anders geht und wie sackmässig schneller das ist zeigt der Opteron momentan, der Intel gerade richtig den Arsch versohlt im Serverbereich mit Dual Dualcore...
b) Was bitte machst du mit "vier ordentlichen GP-CPUs"? Vier singlethreaded Apps mit scheisscode (die nicht-euphemistische übersetzung für "General purpose"!) gleichzeitig laufen lassen? Entweder der Code IST multithreaded (dann ist es kein Scheisscode mehr) oder nicht!
c) Die Cell hat 25.6GB/s auf den Speicher. FÜNFUNDZWANZIG KOMMA SECHS GIGABYTE PRO SEKUNDE! Dazu kommen 300 GB/s (ja, DREIHUNDERT!) intern auf dem EIB zwischen den einzelnen SPUs und dem PPE! Was hat der Core Duo? DDR667 mit 5.4GB/s, und Dualchannel kann er nichtmal nutzen! Darf ich mal eben lachen?
Ach ja: DDR3 wird Ende 2006 mit 400 MHz starten und auch keine besseren Durchsatzraten bieten. Gähn.
"und nicht wie die SPEs, die spezialisierter sind und jeder nur 256KB hat (dazu ist alles In-Order)."
Welches Problem kannst du denn nicht mit der Cell rechnen? Sag mal ein paar Beispiele! Wenn die so spezialisiert ist sollte das ja kein Problem sein..
"Der Cell wäre IMHO genial, wenn es ein Dual-G5(oder besser)+4 SPEs wäre."
Laut BadAndy hat IBM in Japan Slides mit 970-Core und SPEs gezeigt, aber das könnte auch ein Fehler gewesen sein...
Aber mei, Apple wollte halt keine IBM-Chips mehr, nichtmal custom-designs geschweige denn Laptop-G5s, Cells oder sogar Xeons. Zu glauben, dass IBM Apple hängen lassen hätte ist echt die größte Lüge von Jobs überhaupt...
Wieviel Punkte erreicht denn so ein Cell im SPEC CPU2000?
Paar Anmerkungen, bevor das jemand falsch versteht:
Was hat der Core Duo? DDR667 mit 5.4GB/s, und Dualchannel kann er nichtmal nutzen! Darf ich mal eben lachen?
Gemeint ist: Unterstützen tut er's schon, aber es bringt nichts, laut Apple-Aussage!
Ach ja: DDR3 wird Ende 2006 mit 400 MHz starten und auch keine besseren Durchsatzraten bieten. Gähn.
..als natürlich die offensichtliche Steigerung von 333 MHz!
Zu glauben, dass IBM Apple hängen lassen hätte ist echt die größte Lüge von Jobs überhaupt...
glauben -> behaupten
Wieviel Punkte erreicht denn so ein Cell im SPEC CPU2000?
Wieviel Geld verdienst du denn so mit dem SPEC CPU2000?
Keins? Aber weil Apple GANZ PLÖTZLICH sagt, dass SPEC der geilste Benchmark der Welt ist (weil sie jetzt die Intel-SPEC-Compiler haben) und weil dieser altbekannte Bescheisserbenchmark (nicht nur Intel, auch IBM und Sun bescheissen da regelmässig!) die Basis für ihre "4x/2x schneller"-Behauptung darstellt ist der jetzt auf einmal total wichtig, schon klar....
Mr Hallo
2006-01-16, 23:35:22
wie wäre es wenn jeder gast mal das kästchen "ihr benutzername" ausfüllt?
weil sie jetzt die Intel-SPEC-Compiler haben
soweit ich gelesen habe verwendet apple aber gcc, weil der intel angeblich nicht objective-c kann?!
Hast du einen besseren Benchmark im Angebot? Besser im Sinne von: realistisch für CPU-limitierte PC Anwendungen
Ich bin nur grad auf SPEC gekommen weil ich für die Uni eine alternative Implementierung eines der Benchmarkprogramme schreibe (wenn es jemand interessiert: vpr).
Wie wird da eigentlich beschissen bei SPEC?
wie wäre es wenn jeder gast mal das kästchen "ihr benutzername" ausfüllt?
soweit ich gelesen habe verwendet apple aber gcc, weil der intel angeblich nicht objective-c kann?!
Nö, laut Präsentation sind es Intel Compiler.
Mr Hallo
2006-01-16, 23:48:45
Nö, laut Präsentation sind es Intel Compiler.
ja er hat gesagt, daß sie für ppc in dem vergleich auch den besten compiler genommen haben (so habe ich es zumindest in erinnerung -> keynote)
jedenfalls stand vor kurzem bei mactechnews diese meldung:
"Allerdings wird Apple wahrscheinlich in Xcode weiterhin auf den GCC-Compiler setzen, da es für Entwickler weniger Aufwand ist, auf nur einem Compiler zu entwickeln anstatt die Besonderheiten von zwei Compilern berücksichtigen zu müssen."
http://www.mactechnews.de/show_news_print.php?news_id=12116
weiter "Intel hat seine Entwicklertools in einer ersten Beta für OSX veröffentlicht."
seltsam, daß das zeug erst nach der keynote kommt und noch beta-status hat ;)
Außerdem sind es _rate Benchmarkergebnisse, ist der IMac G5 ein dual-core Modell? Wenn nicht kann man die Ergebnisse vom Intel Dual einfach mal halbieren um vergleichbare Werte zu bekommen.
Die Leute die Apple kaufen glauben Jobs auch dass die Intel-Prozessoren bei ihnen viel besser sind :)
Mr Hallo
2006-01-16, 23:55:26
"Wie wird da eigentlich beschissen bei SPEC?"
Hmmmmmmm???
"ist der IMac G5 ein dual-core Modell"
Nein! Single-Core!
Apple-Benchmarks: http://www.apple.com/de/imac/intelcoreduo.html
ja er hat gesagt, daß sie für ppc in dem vergleich auch den besten compiler genommen haben (so habe ich es zumindest in erinnerung -> keynote)
Hier kannst du das nachsehen:
http://www.zdnet.de/news/videos/0,39023127,39140069,00.htm
"... and these are using the best compilers on each. IBM's compilers on the G5 and Intel's compilers on the Core Duo.
OK!
dem gast seine neuen argumente für cell hat aber noch keiner widerlegt oder?
wo sind hier eigentlich die sogenannten cpu-gurus?
Dann ist der Intel bei Integerzeug ein bisschen (50%) schneller und bei Fließkomma genausoschnell wie der G5 wenn man dem SPEC Ergebniss glaubt.
Halte ich nicht für völlig abwegig.
Was ist an der x86-Platform denn nicht hoffnungsvoll X-D
"Allerdings wird Apple wahrscheinlich in Xcode weiterhin auf den GCC-Compiler setzen, da es für Entwickler weniger Aufwand ist, auf nur einem Compiler zu entwickeln anstatt die Besonderheiten von zwei Compilern berücksichtigen zu müssen."
Ja gut, klingt aber plausibel. Die SW Entwickler sollen ja schon universal binaries erstellen, also für x86 und ppc. Klar, dass das mit dem Intel Compiler nicht geht. Aber OSX für X86 zumindest wird wohl sicher mit dem Intel Compiler kompiliert wurden sein.
dem gast seine neuen argumente für cell hat aber noch keiner widerlegt oder?
wo sind hier eigentlich die sogenannten cpu-gurus?
Welche "Argumente" denn?
Bin zwar bestimmt keine Guru, aber ich mach mal Kurzantworten zu den Behauptungen:
.... JC hat keine Ahnung ....
Da hat jemand nicht die zusätzlichen Probleme von Cell und der XBox CPU erkannt und unterstellt deswegen einem der besten Leute Unfähigkeit.
.... Echtzeit-Raytracing mit 1080-HD-Auflösung und 60fps, ....
Wie schon gesagt mit Cell nicht möglich.
.... Beschiss mit der TDP ....
Suchfunktion benutzen um die TDP Angaben zu verstehen.
Wer Wärmeprobleme mit seinem Prozessor hat, sollte sich nach nem neuen Kühler umsehen.
as bitte machst du mit "vier ordentlichen GP-CPUs"? Vier singlethreaded Apps mit scheisscode (die nicht-euphemistische übersetzung für "General purpose"!) gleichzeitig laufen lassen? Entweder der Code IST multithreaded (dann ist es kein Scheisscode mehr) oder nicht!
Cell&Co verursachen mehr Probleme als nur die reine MT-Programmierung.
"Scheisscode" ist nunmal der Normalfall, weil optimierter Code zuviel Zeit und damit Geld kostet.
.... Speicherbandbreite ....
Speicherbandbreite muss immer auf den Anwendungsfall abgestimmt werden.
Ein "normaler" x86 Prozessor im normalen Anwendungsgebiet würde davon kaum profitieren. DDR2 wird für eine Zeitlang ausreichend sein.
Welches Problem kannst du denn nicht mit der Cell rechnen? Sag mal ein paar Beispiele! Wenn die so spezialisiert ist sollte das ja kein Problem sein..
Es geht nicht um die Ausführbarkeit, sondern um die Ausführungsgeschwindigkeit.
Um ein böses Beispiel zu nennen: Nicht parallelisierbarer und nicht SIMD-fähiger Code mit vielen Sprüngen und zufälligem Speicherzugriff auf einen grossen Datensatz.
Das dürfte die PPE noch am Besten hinbekommen. SPEs könnte man ziemlich vergessen.
Ansonsten empfehle ich die Suchfunktion, weil das Thema Cell schon 1000 mal durchgekaut wurde
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/8300945231/m/960005245731/p/67
Ich schlag mal vor, dass ihr diesen Thread genau lest. Auf die Postings von "BadAndy" achten, der ist der Mensch dort mit dem meisten Knowhow in Sachen Chip-Tech und der hat sowohl Xenon als auch Cell und Pentium-M getestet... Er hat später im Thread auch massig Stromverbrauchs-Zahlen über PPE und SPE (90 und 65nm), und ja, aus den Komponenten KANN man einen Laptop-Prozessor bauen! Warum denn auch nicht, der riesige OOOE- und Tracking-Transistor-Wasserkopf der den ganzen Strom zieht fehlt ja!...
Hier mal ein Zitat:
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/8300945231/m/960005245731/r/611000007731#611000007731
"After that digression... I do have is FTG results for xbox360. The person who sent them to me may have violated developer agreements to send them to me (this isn't completely clear to either him or me), and specifically asked me not to distribute the data. I also have data from the PPE in a Cell ... and no surprise everything running in cache looks very similar across these two. (Given that there are no optimizations to use SPEs in the bench, and no optimizations to use the MS-proprietary altivec extensions in the xbox360 (aka "Xenon," aka "Waternoose") cores.)
Bottom line: the MP rates are impressive .... The only scores I have in my collection of weird-machine FTG results which are like them or beat them are big multi-MP.
That statement I made is correct as I see it from FTG results and I want to repeat it: per thread, xbox360 runs like a 1.25 to 1.5 Ghz G4+ ... when not bandwidth-bound, on the tests which aren't too branchy, or pure pseudo-random access.
Be clear about what I'm saying here; this is comparing performance when in L2... the "on-chip" performance of each. xbox360 sure as hell does NOT have a 'bandwidth problem." (And neither will e600+IMC)
Given 6 threads... that is a hell of a lot of computation. And that includes altivec code too... and there are some of the tasks where xbox360 could run considerably faster if the proprietary MS extensions were used (and all those extra registers). This would take recoding... not done (yet).
The PPE/Xenon cores also run scalar SP and DP a bit faster than this rough rule of scaling vs G4+ too.
Branchy-code goes a bit slower per thread ... maybe 1.0 GHz G4+ equivalent, and sparse pseudo-random access codes are on par (maybe a bit better than) today's P4/Xeon (on Linux, meaning that the sum MP throughputs are about the same, which is no surprise when you consider that these codes are just memory-subsystem exercises).
Now the particular point I have been trying to make is performance at WHAT? And if you are talking "picture bashing" algorithms, or FCP, or codecs, or anything which is reasonably compute-intensive, and coded for MP, xbox360 rates will be impressive... and the "bang/buck" will be out of sight.
If your metric is single-thread performance on Windows apps ... Anandtech demonstrates that Dothan outruns Yonah.... and yes either would outrun the PPE core ... but not by as much as you think.
[..]
And when you look at the FTG results of either a Cell PPE or a Xenon core running against this 1.6 Ghz Dothan... you see interesting things. Single-thread... it wins more than folks here would think and wins some by very big margins... more than factors of two for some. The ones the PPE/Xenon cores win are pretty obvious: the well scheduled floating point (even DP): the floating point issue rate for PPE is twice what that Dothan can sustain.
And when you look at the single-thread cases the Dothan wins... they are obvious too... ill-scheduled code where the OOOE wins, and very branchy code.
[...]
On really bad branchy single-thread code PPE is running about 70% as fast as the 1.6 GHz Dothan... that is as bad as it gets... in the FTG anyway. And it beats the Dothan on a fair amount of single-thread scalar floating point. Pseudorandom access into main memory PPE wins... but the faster Intel buses and memory since that test item probably would make that a wash, or maybe a mild win for Intel.
On altivec/SSE code PPE just clobbers Dothan. There is no explicit SSE code in the FTG (yet... I have SSE code but i don't think it's very good. But then maybe none of it is "very good" by my standards???) so this statement rests on other information, but this is on firm ground. Dothan is weak at SSE compared to P4 ... single-thread PPE altivec is running up there with single-thread 2.0 GHz 970s ... and given 6 threads the MP altivec scores are spectacular... nothing else comes close.
Generally speaking anything you can SIMD you can MP... MP is just a simpler vectorization really.
OK, so that's what the numbers show... what does it "mean?" Obviously that's in the eye of the beholder. But for folks who want to do "picture bashing,' or anything which is MP-able or SIMDable ... the Xenon multicore just blows anything Intel has right now right off the map. And roughly speaking it looks like you'd need to have a triple-core Conroe at least to get into the execution resources league.
[...]
Apple has jumped to Intel ... but this is a jump to lower performance at higher prices, for the apps that Apple has traditionally touted."
So schnell (per Core,und single Thread)wie ein P-M @1120Mhz,wenn das nicht langsam ist,dann weiss ich auch nicht.
p.s. ein Core Duo @2Ghz,wurde alle 3 Cores Staub fressen lassen.
Wie schon gesagt mit Cell nicht möglich.Ein Cell ist für Echtzeit-Raytracing sehr viel besser geeignet als eine x86-CPU, der Meinung bin ich auch. Aber 1080p bei 60Hz ist Quatsch ;)
Android
2006-01-17, 01:58:36
Ich würde ja gerne auf die Argumente von "Gast" eingehen, aber weiss dann auch jeder andere "Gast" wer gemeint ist ? ;)
Kurz:
Der Cell ist kein vollwertiger "Multi-Kern-Prozessor". Es sind mehrere synergetische Kerne mit einem Steuerkern verbunden. Daher der Begriff "modular".
Man kann also einen Cell sowohl mit bspw. acht Kernen als auch mit bspw. zwei Kernen herstellen. Wichtig ist nur: Ein Steuerprozessor und mindestens ein steuerbarer Kern.
Deshalb ist auch ein Vergleich mit Desktop-Systemen unangebracht.
Das besondere am Cell ist also die Möglichkeit ihn zu spezialisieren ohne dabei die komplette Architektur über den Haufen zu werfen. Das ist das eigentlich neue an ihm.
Problem: Auch hier muss man die Software darauf "abrichten". Deshalb arbeiten IBM und Sony auch an einer Workstation auf Basis des Cell.
Tests mit herkömmlicher Software (Linux) zeigten jedoch keine signifikanten Unterschiede zu anderen Prozessoren.
Und genau das ist der Hype den ich meine.
Spezialisierte Systeme gibt es seit Erfindung des Computers (NEC, IBM etc.).
Und die Vektorberechnung gibt es schon seit ......... mein Gott da hab ich noch nicht mal gelebt.
Nur jetzt gibt es eine Architektur welche breitbandiger eingesetzt werden kann und damit erhebliche Entwicklungskosten einspart (Settop, Hifi etc.) und schon reden alle vom "Überchip".
Vergesst bitte nicht die Playstation 2 und ihren Eintrag im Export-Index. Sony ist wirklich was besonderes. Eine besondere PR-Maschine.
Für alle die mehr wissen wollen:
http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318
http://www.realworldtech.com/page.cfm?ArticleID=RWT022805234129
http://www.realworldtech.com/page.cfm?ArticleID=RWT072405191325
Hier könnt ihr mal den Blödsinn von den Cell-Teraflops und was weiss ich für Quatsch nachlesen.
Gehört aber auf dem Cell ins Reich der Sagen. :|
http://www.golem.de/0507/39524.html
http://www.uni-saarland.de/de/medien/2005/07/1122474975
"Als ein Highlight der diesjährigen Siggraph zeigt das Team der Saarbrücker Informatik den ersten Prototypen von Echtzeit-Ray-Tracing auf dem neuen Cell-Prozessor. In der extrem kurzen Entwicklungszeit von nur zwei Wochen wurden die Ray-Tracing-Algorithmen für diesen neuen Hochleitungsprozessor in Zusammenarbeit mit IBM Deutschland völlig überarbeitet. Schon mit einem einzelnen Cell-Prozessor werden Echtzeit-Bildraten bei voller Bildschirmauflösung erreicht."
Soso, du weisst ja Bescheid....
soviele gäste. da blickt man ja nicht mehr durch.
mal daran gedacht, dass sse3 evtl. nicht richtig genutzt wird? ausserdem so schlecht finde ich das ergebnis garnbicht. für den quad ist es ja wohl eher peinlich
Mal daran gedacht, dass Apple für iTunes/Windows schon SSE-Optimierung HAT? Mal daran gedacht, dass Apple ein Accelerate Framework für genau diese Zwecke hat?
Lustig find ich bei solchen Äußerungen ja immer, dass es nur um SSE*3* geht! Ja, das GUTE SSE3, nicht die SCHLECHTEN Versionen zuvor! Weil das ja sooo viel toller ist als SSE2, und dann tut der Verlust von Altivec auch gar nicht mehr so weh (http://www.simdtech.org/altivec/archive/msg?list_name=altivec&monthdir=200506&msg=msg00037.html), gell? ;-)
Und: Der Quad ist fast doppelt so schnell wie der Dual 2GHz im iDVD-Encoding (und nutzt übrigens 250% eines Quads aus). Lern lesen...
Die andere iLife-Anwendung, die über 200% CPU nutzen kann ist Garageband (240%). Für Software, für die garantiert NIEMAND einen Quad kauft ist das ein recht respektables Ergebnis...
wie wäre es wenn jeder gast mal das kästchen "ihr benutzername" ausfüllt?
soweit ich gelesen habe verwendet apple aber gcc, weil der intel angeblich nicht objective-c kann?!
Und? Was an SPEC ist bitte in Objective C???
http://www.apple.com/macbookpro/intelcoreduo.html
"Testing conducted by Apple in December 2005 using preproduction 15-inch MacBook Pro units with 1.83GHz Intel Core Duo; all other systems were shipping units. Estimated SPECint_rate_base2000 score: 30.3. Estimated SPECfp_rate_base2000 score: 25.6. SPEC is a registered trademark of the Standard Performance Evaluation Corporation (SPEC); see www.spec.org for more information. All of the MacBook Pro and PowerBook systems ran a beta Universal version of Cinebench. Other benchmarks were compiled using beta versions of Intel and IBM compilers for Mac OS."
Hast du einen besseren Benchmark im Angebot? Besser im Sinne von: realistisch für CPU-limitierte PC Anwendungen
Nein. Gäbe es einen, würde da genauso beschissen! ;-) So ist das leider nun mal!..
Intels Compiler sind schon gut, keine Frage, aber eben lang nicht so toll wie ihre SPEC-Werte vermuten lassen. Siehe Vergleich zu Opteron: Der Opteron lässt besonders in Dual Dualcore die Xeons sowas von arm aussehen, dass es kein Spass mehr ist. In ALLEN Tests! Nur in Spec schaut's komischerweise ganz anders aus...
Generell gilt die Regel: Je ähnlicher dein Code dem SPEC-Code ist, umso besser ist der Intel-Compiler.
Trotzdem ist JEDE Anwendungs-Benchsuite (damit etwas Vielfalt gewährleistet ist) ein besserer Benchmark als fucking SPEC!
Sogar Linpack ist besser für FP-Performance geeignet als SPEC, denn da ist wenigstens gewährleistet, dass JEDE CPU dank libgoto verdammt nahe an ihrem theoretischen Maximum arbeitet. Linpack-Benchmarks hatte Apple noch für den Quad, komischerweise jetzt nicht mehr für den Core Duo. Warum nur? Ganz einfach: Weil EIN Single 2.1 GHz G5 7.4 GFLOPS mit Libgoto schafft und ein Dualcore (Zur Erinnerung: das sind zwei!) 2GHz Nocona (Netburst-Xeon) mit Libgoto etwas weniger schaffen müsste (etwa 7.3 GFLOPS). Für den Core Duo gibt's AFAIK keine Libgoto, wohl erst wenn mit Sossaman die ersten Blade-fähigen Enterprise-Class Yonahs rauskommen. Aber: In FP war der Pentium-M immer schlechter als der P4, insofern wird der Wert hier eher niedriger sein.
Ach ja, nochwas zu SPEC: Böse Zungen behaupten, dass SSE3 primär dem Zweck dient, die SPEC-Werte hochzutreiben! ;-) Aber sowas würde Intel ja niiie machen!
Wie wird da eigentlich beschissen bei SPEC?
Ganz einfach: Der Code ist bekannt, also auch die kritischen Hotspots. Der Chip-Hersteller macht den Compiler. Zähle eins und eins zusammen.
(Hut ab an der Stelle vor AMD, die KEINEN eigenen Compiler haben und trotzdem ziemlich gut abschneiden! ;-)
Gibt auch Hardwarebeschiss, IBM schaltet z.B. gerne für den Single-CPU-SPEC die L3-Caches der anderen vier inaktiven Power4/5-Cores auf den einen aktiven zusammen und Dell & Co schalten Hypnothreading ab, weil das den Test verlangsamt...
Noch was zu SPEC:
Wusstet ihr, dass der Floating-Point-Teil von SPEC fast NUR aus Fortran-Code (!!) besteht? ;-) Ich weiss ja nicht, aber wieviele Fortran-Anwendungen setzt ihr denn so ein?
Welche "Argumente" denn?
[QUOTE]Wie schon gesagt mit Cell nicht möglich.
Wie schon gesagt: Leider doch! ;-) Und nun? Implosion?
Suchfunktion benutzen um die TDP Angaben zu verstehen.
Gehirn benutzen um Geschriebenes zu verstehen!
Erklär mir mal, wie es sein kann, dass ein Dualcore Opteron mit 1.8 GHz dieselben 95 Watt TDP hat wie ein Dualcore Opteron 2.4 GHz!
Oder dass der Core Duo von 1.66 bis 2.13 GHz dieselben 31 Watt TDP hat? Haben Intel/AMD die Gesetze der Physik besiegt und mehr Takt bedeutet nun nicht mehr Hitzeentwicklung, ja?
Cell&Co verursachen mehr Probleme als nur die reine MT-Programmierung.
Um das meiste davon soll sich eben der Octopiler kümmern.
"Scheisscode" ist nunmal der Normalfall, weil optimierter Code zuviel Zeit und damit Geld kostet.
Scheisscode WIRD aber aussterben müssen, seht das einfach endlich mal ein! Quad-Core von Intel 2007, Octa-Core 2008/2009, AMD dito! Da geht GAR NIX mehr mit Scheisscode!
Die Entwickler WERDEN bald (bzw. müssen schon, hallo Konsolen-Entwickler! ;-) in den sauren Apfel beissen müssen, ob sie wollen oder nicht! Takt geht RUNTER, Cores gehen hoch! So isses nun mal, und es ist GUT so, weil wir dann endlich den alten Scheisscode aus den 90ern loswerden, der ÜBERALL noch drinsteckt (teils sogar noch aus den 80ern, kein Witz! Hallo Adobe, hallo Quark, hallo Maxon, hallo Newtek!)
Im übrigen haben wir auf der Mac-Plattform den Vorteil, dass schon mehr Software multithreaded ist als auf Windows, weil Dual hier schon lange Standard ist bei den Powermacs. Sogar Consumer-Software wie Apples iLife ist durch die Bank multithreaded, manches (Garageband, iDVD) sogar echt nicht schlecht so dass es sogar nen Quad relativ gut ausnutzt!
Speicherbandbreite muss immer auf den Anwendungsfall abgestimmt werden.
Was soll DAS denn bitte heissen? Sind wir hier beim Astrologen, ja? Nebulöse Sätze ohne Inhalt und Sinn...
Wo kann man denn jemals ZUVIEL Speicherbandbreite haben frag ich dich?
Ein "normaler" x86 Prozessor im normalen Anwendungsgebiet würde davon kaum profitieren. DDR2 wird für eine Zeitlang ausreichend sein.
Die Cell ist aber eben kein "normaler Prozessor". Ihr jammert, dass die Cell beim Speicherzugriff ausgebremst wird, ich sag euch, dass das Ding Speicherbandbreite bis zum Abkotzen hat und auf einmal ist wieder die Rede von x86-CPUs? Hallo?
Es geht nicht um die Ausführbarkeit, sondern um die Ausführungsgeschwindigkeit.
Aber dass sich nahezu alle Routinen auf die SPUs verteilen lassen, da stimmst du zu, ja?
Um ein böses Beispiel zu nennen: Nicht parallelisierbarer und nicht SIMD-fähiger Code
Äh - ich frag dich nach nem Beispiel für ein Problem, das man nicht mit der Cell rechnen kann und du sagst "nicht parallelisierbarer und nicht SIMD-fähiger Code"? Hallo??? Die Frage war welches PROBLEM man nicht mit SIMD- und Parallelcode rechnen kann!
Ja, solche Sachen gibt es, sehr schlaue Köpfe zerbrechen sich über solche Dinger schon Jahzehnte den Kopf, denn was nicht parallelisiert oder vektorisiert ist lässt sich nicht auf nem Supercomputer rechnen! Aber ich würde gerne kommentieren, inwiefern solche Rechenjobs Relevanz haben für den Mac-User...
mit vielen Sprüngen und zufälligem Speicherzugriff auf einen grossen Datensatz. Das dürfte die PPE noch am Besten hinbekommen. SPEs könnte man ziemlich vergessen.
Also laut nem befreundeten Entwickler, der auf dem Ding programmiert macht er einfach keine Branches und rechnet eben mit den SPUs den ganzen Tree durch und entscheidet am Ende. Er sagt das ist schneller als Branches und immer noch um längen schneller als alles andere, was er je gesehen hat! ;-)
Ansonsten empfehle ich die Suchfunktion, weil das Thema Cell schon 1000 mal durchgekaut wurde
Offensichtlich noch nicht gut genug wie mir scheint! ;-)
ShadowXX
2006-01-17, 08:40:33
[QUOTE=RLZ]
Äh - ich frag dich nach nem Beispiel für ein Problem, das man nicht mit der Cell rechnen kann und du sagst "nicht parallelisierbarer und nicht SIMD-fähiger Code"? Hallo??? Die Frage war welches PROBLEM man nicht mit SIMD- und Parallelcode rechnen kann!
Ja, solche Sachen gibt es, sehr schlaue Köpfe zerbrechen sich über solche Dinger schon Jahzehnte den Kopf, denn was nicht parallelisiert oder vektorisiert ist lässt sich nicht auf nem Supercomputer rechnen! Aber ich würde gerne kommentieren, inwiefern solche Rechenjobs Relevanz haben für den Mac-User...
Du wirst es nicht glauben, aber es gibt weit mehr Programme, als solche, die sich nur mit Encoding, Decoding und ähnlichen Streaming-Sachen beschäftigen.
Für unsere Anwendungen (Massendatenverarbeitung von durchgehend verschiedenen Daten mit massig Branching) zum Beispiel ist ein Cell (und wenn er hundert SPEs hätte) völlig ungeeignet.
Also laut nem befreundeten Entwickler, der auf dem Ding programmiert macht er einfach keine Branches und rechnet eben mit den SPUs den ganzen Tree durch und entscheidet am Ende. Er sagt das ist schneller als Branches und immer noch um längen schneller als alles andere, was er je gesehen hat! ;-)
So.....voll die Supermethode. Ich Rechne alle 250 verschiedenen Fälle vorher auf 7 SPEs durch (wenn das in Ihre 256k passen würde, was ich da berechnen muss) um dann nachher auch noch das richtige Ergebnis rauszusuchen......und das soll schneller sein als Branching?
Was es garantiert ist, ist Resourcenverschwendung.
[QUOTE=RLZ]
Wie schon gesagt: Leider doch! ;-) Und nun? Implosion?
Ich hab das Thema mitbekommen seit dem Zeitpunkt an dem die Frage kam "Habt ihr Kontakt zu Sony? Wir hätten da Interessse am Cell."
Die Präsentation war mit 640x480 reine Primärstrahlen ohne Shader.
Die 1080er Auflösung mit 60FPS kam durch schlaue Leute zustande, die Cell mit PS3 gleichgesetzt haben, festgestellt haben, dass Sony diese Auflösung für Spiele fordert und daraus einen falschen Schluss gezogen haben.
Gehirn benutzen um Geschriebenes zu verstehen!
Erklär mir mal, wie es sein kann, dass ein Dualcore Opteron mit 1.8 GHz dieselben 95 Watt TDP hat wie ein Dualcore Opteron 2.4 GHz!
Oder dass der Core Duo von 1.66 bis 2.13 GHz dieselben 31 Watt TDP hat? Haben Intel/AMD die Gesetze der Physik besiegt und mehr Takt bedeutet nun nicht mehr Hitzeentwicklung, ja?
AMD gibt immer zB immer den TDP für das theoretisch grösste Modell einer Prozessorreihe an. Wie Messungen schon oft gezeigt haben liegen die Prozessoren aber eh weit darunter.
Suchfunktion hilft wirklich. Probier mal.
Um das meiste davon soll sich eben der Octopiler kümmern.
Das ist genauso wie MT nur begrenzt möglich. Z.B. welche Daten im lokalen Speicher der SPE liegen müssen, muss sinnvollerweise der Programmierer entscheiden.
Scheisscode WIRD aber aussterben müssen, seht das einfach endlich mal ein! Quad-Core von Intel 2007, Octa-Core 2008/2009, AMD dito! Da geht GAR NIX mehr mit Scheisscode!
Wenn sie meinen. :|
Was soll DAS denn bitte heissen? Sind wir hier beim Astrologen, ja? Nebulöse Sätze ohne Inhalt und Sinn...
Wo kann man denn jemals ZUVIEL Speicherbandbreite haben frag ich dich?
Schau mal was zu Anfang der DualChannel beim S939 gebracht hat. Inzwischen ist er notwendig um Dualcores zu versorgen und bringt wesentlich mehr. Nach dem Gesetz des abnehmenden Ertrags würde ein Vielfaches der Bandbreite kaum etwas bringen.
Da der Cell auf massive Streaminganwendungen ausgelegt ist, ist dort eine solche Speicherbandbreite nötig.
Die Cell ist aber eben kein "normaler Prozessor". Ihr jammert, dass die Cell beim Speicherzugriff ausgebremst wird, ich sag euch, dass das Ding Speicherbandbreite bis zum Abkotzen hat und auf einmal ist wieder die Rede von x86-CPUs? Hallo?
Die SPEs müssen über DMA-Zugriff sich Daten aus dem Speicher holen. Das ist nunmal langsam und wenn dies unvorhergesehen eintritt, drehen sie nunmal Däumchen. Moderne X86 CPUs können dank OoO umsortieren und weiterarbeiten.
Aber dass sich nahezu alle Routinen auf die SPUs verteilen lassen, da stimmst du zu, ja?
Ja.
Wie J.C. aber schon gesagt hat, bekommt man aber nicht die angegeben Leistung.
Äh - ich frag dich nach nem Beispiel für ein Problem, das man nicht mit der Cell rechnen kann und du sagst "nicht parallelisierbarer und nicht SIMD-fähiger Code"? Hallo??? Die Frage war welches PROBLEM man nicht mit SIMD- und Parallelcode rechnen kann!
Ja, solche Sachen gibt es, sehr schlaue Köpfe zerbrechen sich über solche Dinger schon Jahzehnte den Kopf, denn was nicht parallelisiert oder vektorisiert ist lässt sich nicht auf nem Supercomputer rechnen! Aber ich würde gerne kommentieren, inwiefern solche Rechenjobs Relevanz haben für den Mac-User...
Ok, dass es genug solcher probleme gibt, scheinst du einzusehen. Ansonsten empfehl ich dir eine Vorlesung zu dem Thema....
Da Entwickler aber nur im seltensten Fall die Zeit haben um die Probleme zu parallelisieren und Vektorisierung nur über die Automatismen der Compiler genutzt werden, spielt die theoretische Möglichkeit nur eine kleine Rolle. Der Code wird die Möglichkeiten einfach nicht nutzen.
Also laut nem befreundeten Entwickler, der auf dem Ding programmiert macht er einfach keine Branches und rechnet eben mit den SPUs den ganzen Tree durch und entscheidet am Ende. Er sagt das ist schneller als Branches und immer noch um längen schneller als alles andere, was er je gesehen hat! ;-)
Schön. X86 Compiler machen dies je nach Branches auch.
Allerdings geht dies auch beim Cell mal längeren Verzweigungen in die Hose.
Selbst alle deine Links bestätigen Leistungsprobleme bei stark verzweigtem Code.
Ganon
2006-01-17, 08:57:13
http://www.golem.de/0507/39524.html
http://www.uni-saarland.de/de/medien/2005/07/1122474975
Soso, du weisst ja Bescheid....
Und wo steht da jetzt was von 1080p bei 60fps? Ich lese nur "Echtzeit" und "volle Bildschirmauflösung".
Beides irgendwie sehr ungenau...
Tiamat
2006-01-17, 09:24:19
Man schaue sich doch nur die alte Apple Produktpalette an.
Man hat hier bei 5 Produkten die Auswahl aus 1.25 Ghz G4 bis zu Quad 2.5 Ghz G5 und das allein reicht doch schon um zu wissen das der Switch kein Fehler ist.Diese Kluft ist einfach Schwachsinn.
Wäre Apple wiederhin bei Freescale und IBM geblieben so wär die Entwicklung weiterhin so skurril gelaufen.
Jetzt kommt endlich mal Entwicklung ins Spiel von der auch mal die Normaluser profitieren und nicht nur die,die 2 1/2 Tausend € hinblättern.
Man darf hier nicht nur die Benchmarks sehen.Was genau bringt der Cell Prozessor der gesamten Apple Plattform ? Nichts,da er allein aus Kostengründen sowieso nur im Powermac verbaut werden kann.Powerbook mit G5 und Cell ? :| Wohl kaum ..
Im Moment setzt Apple ja eine Mobile-Prozessor von Intel als Desktop an.
Yonah is ja im Prinzip nur Intels next-gen mobile cpu mit Dual-Core.
Die wirklich neue Desktop-Generation erscheint ja in der 2. Hälfte des Jahres (Conre/Merom)und die ist höchstwahrscheinlich der Grund wieso man den Switch gewagt hat.
Man darf ja auch nicht die 8 zusätzlichen Register vergessen,die mittels PAE zum Einsatz kommen.Klar wird das ne Zeit lang dauern bis alle Apple-Produkte mit der 64bit Generation ausgestattet sind,aber das sind doch alles Lichtblicke,die ich mit der G4/G5 Lösung noch lange nicht sehe.
Cell for Desktop = Meiner Meinung nach Utopie
[QUOTE=RLZ]
Gehirn benutzen um Geschriebenes zu verstehen!
Erklär mir mal, wie es sein kann, dass ein Dualcore Opteron mit 1.8 GHz dieselben 95 Watt TDP hat wie ein Dualcore Opteron 2.4 GHz!
Oder dass der Core Duo von 1.66 bis 2.13 GHz dieselben 31 Watt TDP hat? Haben Intel/AMD die Gesetze der Physik besiegt und mehr Takt bedeutet nun nicht mehr Hitzeentwicklung, ja?
mal einige beispiele:
http://www.hardtecs4u.com/images/reviews/2005/amd_athlon_64_x2/leistung.png
hier in dem forum hatte mal jemand eine interessannte grafik zum stromverbrauch der g5 gepostet (-> die übertakteten ähhhhhhh hochgetaktetet g5s in den powermac). finde ich leider nicht mehr aber das sah ganz schlecht für die hochgetakteten g5 unter last aus. zugegeben: das bezog sich nicht auf den aktuellen dual-core g5. ibm scheint fortschritte diesbezüglich gemacht zu haben.
ich glaube gast ist das hier (macguardians):
""Auch den PowerPC 970FX, den Apple momentan verbaut, hat IBM verbessert. Dieser ist nun in einer Stromspar-Version erhältlich und soll lediglich 13 Watt bei 1,4 GHz und 16 Watt bei 1,6 GHz verbrauchen."
Intel Core Duo: 31 Watt. Damit dürften für den Stromspar 970FX ungefähr 2 bis 2.2 GHz drin gewesen sein.
Soviel zu "we tried EVERYTHING to get the G5 into the Powerbook" - well, maybe you should have actually BOUGHT it from IBM, Steve, you damn liar???
Es ist einfach alles Lüge an dem Switch..."
-> Vaporware
-> TDP
[QUOTE=Gast]
well, maybe you should have actually BOUGHT it from IBM, Steve, you damn liar???
Es ist einfach alles Lüge
Sorry aber ich muss gerade lachen, einen solchen Spruch von einem Apple-User zu hören! Sonst glaubt ihr Stevie doch immer alles, oder? ;D
Wie sollen Cells SPEs überhaupt in einem Multitasking-System funktionieren? Kann man die so einfach anhalten wie eine normale CPU? Und dann jeweils 2MByte ins RAM scheffeln? Kann man selbige überhaupt einfach per PPE auslesen?
Oder würden sie explizit per spezieller Api verwaltet werden und die Anwendungen nerven Dich mit "waiting for free SPE"?
Und - wenn mal ein Cell 2 kommt, werden dessen SPEs überhaupt kompatibel sein?
Im übrigen haben wir auf der Mac-Plattform den Vorteil, dass schon mehr Software multithreaded ist als auf Windows, weil Dual hier schon lange Standard ist bei den Powermacs.
Das glaubst du doch selst nicht. Jedes aufwenigere Programm unterstützt in der einen oder anderen Weise Multithreading, sei es auch nur für asynchrone Verarbeitungen von Eingaben, Ereignissen etc., damit die GUI aktiv bleibt und reagieren kann. Der springende Punkt ist doch, dass die zusätzlichen Threads nun voll ausgelastet werden und nicht nur Pippikram erledigen. Ich vermute, dass viele Dinge in den APIs durch mehr Threads erst mal parallelisiert werden, damit das nicht alles am Entwickler hängen bleibt.
Smithi
2006-01-17, 12:52:24
""Auch den PowerPC 970FX, den Apple momentan verbaut, hat IBM verbessert. Dieser ist nun in einer Stromspar-Version erhältlich und soll lediglich 13 Watt bei 1,4 GHz und 16 Watt bei 1,6 GHz verbrauchen."
Intel Core Duo: 31 Watt. Damit dürften für den Stromspar 970FX ungefähr 2 bis 2.2 GHz drin gewesen sein.
- Soweit ich weiß steigt der Stromverbrauch exponentiell mit dem Takt und nicht linear -> dann stimmt deine Hochrechnung schonmal nicht!
- Du weißt was TDP bedeutet und das diese sich zwischen den Herstellern unterscheidet?
- Der Intel ist dein Dual Core und der 970FX soweit ich weiß ein Single-Core! -> kein fairer Vergleich bzw. der intel steht selbst bei deiner Hochrechnung dann noch deutlich besser da!
Halbleiterphysiker
2006-01-17, 13:13:18
Erklär mir mal, wie es sein kann, dass ein Dualcore Opteron mit 1.8 GHz dieselben 95 Watt TDP hat wie ein Dualcore Opteron 2.4 GHz!
Oder dass der Core Duo von 1.66 bis 2.13 GHz dieselben 31 Watt TDP hat? Haben Intel/AMD die Gesetze der Physik besiegt und mehr Takt bedeutet nun nicht mehr Hitzeentwicklung, ja?
Wenn man keine Ahnung von den zugrundeliegenden Gesetzen der Physik hat, sollte man sich mit solchen Anschuldigungen etwas zurück halten.
Der Hochfrequenzwiderstand eines Transistors ist zwar frequenzabhängig, wird aber in größerer Weise noch durch die Bauteilgeometrie (Gatelänge, Dotierprofile, Oxiddicke etc.) und durch die Betriebsspannung bestimmt. (Spannung die man den Prozessor zum füttern gibt nicht unbedingt gleich Spannung die an den Transistoren anliegt), was wiederum davon abhängt welchen Arbeitspunkt man für den Transistor wählt, was wiederum davon abhängt welche Leistungsdaten mit der Bauteilgeometrie kritisch sind (Sperrstrom, Schwellenspannung, Unterschwellsteigung, Maximalstrom). Dabei wird der Arbeitspunkt auch noch dank Speedstep und ähnlichen Stromspartechniken noch häufig während des Betriebs gewechselt. Frag dich mal warum 1980 keine 2Ghz drin waren :-) zumindest ohne fl. Stickstoffkühlung.
Hinzu kommt dass der Cache nicht unbedingt mit dem Prozessortakt betrieben werden muss und sowieso wegen unterschiedlichen Anforderungen an die elektrischen Eigenschaften zwischen Logik und Speichertransistoren eine andere Geometrie und ein anderer Arbeitspunkt gewählt werden kann. Der Logikanteil von den 151 Millionen Transistoren des YonahDuos wird auf gerade mal 22 Millionen Transistoren geschätzt (11 pro Core).
So und jetzt frag dich nochmal warum man nicht einfach die TDP von völlig unterschiedlichen Prozessoren allein an der maximalen Taktfrequenz festmachen kann.
http://www.golem.de/0601/42789.html
IBM's blade agenda: Cell chip, InfiniBand
update IBM is expected to demonstrate a blade server next week based on the Cell processor the company is developing with Toshiba and Sony.
http://news.com.com/2100-1010_3-6035077.html?part=rss&tag=6035077&subj=news
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.