ARCHIV 1999-2006

ARCHIV :: # 2501

Architosh G5 Special

..plus ein Gerücht

Autor: kai - Datum: 27.10.2003

Architosh hat einige Infos zum Thema G5 und Performance zusammengefasst. Da gibt's Aussagen von Testern und Softwareherstellern dazu. Nemetschek kommt zu Wort stellvertretend für die CAD/CAM-Branche und ein Tester aus dem Bio-Informatik-Bereich.

Unten dran gibt's noch ne interessante Zusatzinfo in Form eines Gerüchtes, dass IBM gut vorankommt mit der Taktskalierung beim G5 und das Apple/IBM planen, die Caches auf dem Chip "wesentlich zu vergrössern". Was 1MB L2-Cache bringen kann sehen wir ja an Centrino und Opteron. Das wäre so ziemlich der einzige Bereich, wo ich beim G5 noch was verbessern wollen würde! ;-)

Kommentare

G5 mit 1MB Level2 cache

Von: ks | Datum: 27.10.2003 | #1
hab ich mir auch schon überlegt. Aber ist es nicht so, dass die Hitzeentwicklung rapide zunimmt?

Deswegen glaube ich, dass das erst passiert, wenn IBM auf 0.09um umstellt.

IBM sollte lieber an einer Mobilversion des PPC970 arbeiten.

Was unterscheidet eigentlich eine Mobilversion von einer Desktopvariante?

Bei Motorola war es ja nur der fehlende L3 cache oder?

Was könnte man denn beim PPC970 "weglassen", dieser hat ja kein L3 cache?

@ kai

Von: nico | Datum: 27.10.2003 | #2
"Das wäre so ziemlich der einzige Bereich, wo ich beim G5 noch was verbessern wollen würde!"

auch die altivec-einheit ist doch nicht die aktuellste gegenueber g4? die stammt doch noch aus ner zeit der gemeinsamen "roadmap" von apple,ibm und motorola und ist doch massgeblich von motorola weiterentwickelt worden, ibm war doch damals nie an altivec interessiert - da koennte ich mir auch einiges vorstellen, allerdings wird da wohl nix passieren - patente...

Vapochill im Mac

Von: gammel | Datum: 27.10.2003 | #3
Kann man den G5 eigentlich übertakten? So auf etwa 2,5 Ghz, mit entsprechendem FSB, wäre schon ganz lässig.

wunschliste..

Von: mattin | Datum: 27.10.2003 | #4
"Das wäre so ziemlich der einzige Bereich, wo ich beim G5 noch was verbessern wollen würde!"

ich würde mir auch eine bessere MP skalierung wünschen. da ist der P4 mit HT z.zt. könig, oder?

Mattin:

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #5
Nö. Nur in Cinebench! ;-)
Der G5 ist dem P4 in SMP haushoch überlegen, denn er hat dedizierte Busse für jede CPU. Beim Xeon teilen sich wie beim G4 2 CPUs einen Bus.

FSB-Durchsatz gesamt beim Dual Xeon 800MHz FSB: 6.4GByte/s
FSB-Durchsatz beim Dual 2GHz G5 1GHz FSB: 14.4 GByte/s

.soviel dazu! ;-)

ich wuensch mir was

Von: nico | Datum: 27.10.2003 | #6
@ mattin:
p4 koenig mp skalierung? der ist ueberhaupt nicht mp-faehig. ht ist aber ne feine sache - nur muss es die software unterstuetzen.

fuer den g5 (rechner, nicht prozessor) allgemein wuensche ich mir in der naechsten revision mind. einen pci-platz mehr, oder wenigstens platz fuer ein zweites optisches laufwerk.

am meisten wuensche ich mir eine mehrtastenmaus von apple - ob kabel oder blauzahn ist mir wurscht

@ nico

Von: Soeren Kuklau | Datum: 27.10.2003 | #7
Richtig ist, dass der G4+ (7450 ff.) eine im Vergleich zum G4 (7400 ff.) weiterentwickelte AltiVec-Einheit hat. Richtig ist auch, dass der G5 (970) einige der AltiVec-Features des G4+ nicht besitzt. An anderen Stellen jedoch ist der G5-AltiVec wiederum neuer als der des G4+. Es gleicht sich manchmal aus; manchmal aber eben leider auch nicht.

Erweiterungen waeren hier also wuenschenswert; ob Motorola das zulassen wird, ist eine andere Frage.

@kai

Von: Cyrus Mobasheri | Datum: 27.10.2003 | #8
was verspricht du dir von 1MB Level 3 Cache. Wie stark wirkt sich dieser auf die Gesamtperformance aus? Ich dacht Cache wäre nur eine Notlösung, wenn ein Flaschenals zu Groß ist. Bei dem jetzigen FSB kann man ja nicht wirklich von einem Flaschenhals sprechen, oder? Erwartest du das der Cache schon im Januar vorgestlt wird. so das man so einen G5 dann im Januar spähtestens März kaufen kann? Oder ist das technich aufwändig, und man kann eher davon ausgehen, das Apple sich das aufspart, wenn sie mit dem G5 nicht mehr weiterkommen.

Cyrus:

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #9
Cache ist für schnelleren Zugriff auf Daten. Allgemein. Speicherzugriffe haben eine sehr hohe Latenz, beim G5 ist die sogar höher als beim G4! Nur ist die Durchsatzrate wenn die Daten dann mal kommen beim G5 eben ein Vielfaches so hoch wie beim G4! ;-)
Sicher kann man nen lahmen FSB mit Cache etwas kompensieren, aber mehr Cache bringt IMMER was, auch bei schnellen CPUs, denn Speicher ist immer deutlich langsamer, egal wie schnell der FSB ist!
Die Latenz für Speicherzugriffe kann man runterdrücken indem man nen Speichercontroller in die CPU integriert, wie das AMD z.B. gemacht hat. Aber selbst da ist Cache immer noch deutlich schneller!

Im übrigen..

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #10
..ist die Rede von 1MB L2-Cache, nicht L3-Cache! ;-)

@ kai, nico

Von: mattin | Datum: 27.10.2003 | #11
ich meine natürlich den xeon. der bringt im dual betrieb ne bessere skalierung als der G5, zumindest nach diesem benchmarks [Link]

"Nö. Nur in Cinebench! ;-)"

das interessiert mich aber ;) naja nicht wirklich, der G5 ist eh schneller als ich es zu träumen gewagt hätte :)

p.s. die benchmarkwerte stimmen genau mit meinen erwartungen überein, siehe den 3.5 ghz Xeon, was es aber damit [Link] auf sich hat ist mir nicht so ganz klar.

90nm

Von: mattin | Datum: 27.10.2003 | #12
"Keine Ahnung, wann und ob IBM das umsetzt! Januar wäre theoretisch möglich, aber ich denke aucn, dass sie damit auf 90nm warten, weil das Die sonst viel zu gross wird!"

ich denk, die sind bis ende 2003 auf 90nm?

Wunschliste

Von: Rüdiger Goetz | Datum: 27.10.2003 | #13
Hallo,

Hey ist bald Weihnachten, darf man sich was wünschen? ;-)

Aber im Ernst. Ich denke es gibt fünf Bereiche, wo man beim G5 zulegen könnte (in
Reihenfolge ohne Wertung):

1. AltiVec: Das AltiVec-Design des G5 basiert woh noch auf dem des ersten g4, wenn auch etwas optimiert. Hier hat IBM wohl erstmal AltiVec überhaupt auf den G5 bringen wollen und wird sich jetzt ans optimieren machen. Und ich kann mir nicht vorstellen, dass Motorola das so gut im Patenten abgescihert hat, den dann müsste sie ja ein Patent auf Superskalarität in SIMD-Einheiten haben. Da gäbe es wohl genug Prior art.

2. Größere L2-Caches: Wohl der am einfachsten zu realisierende Punkt. Und da IBM ja wohl um die Jahreswende mit dem geshrikten G5 kommen will, könnte das schon bald Realität werden.

3. Größere L1-Cache: Früher (zu G1/2-Zeiten) hatten die PPC immer größere L1-Caches als die x86er. Dann zog zuerst AMD gleich und vorbei und nun auch Intel. der P4 hat ca 100kB L1-Intruktion-Cache (aber nur 16 kB für Daten), Athlon und Opetron haben je 64kB für Daten und Instr. Zumindest beim L1-Daten-Cache wirds bei 970er etwas eng mit 32kB.

4. Mehr Integer-Units: Eine der Mankos der Pwer4/PPC970-Design (siehe c't 20/03) scheint zu sein, das er im Vergleich zu AMD und Intel releativ wenig Interger-Unit hat. Zwar könnte der PPC 970 max.4 Int9-Instruktion verteilen, er hat aber nur 2 Units dafür. AMD und Intel können dagegen 3 Rechen-Int-Operation verteilen (+ jeweils eine Load/Store dazu) und haben auch aureichend Integer-Units dazu. Eine Int-Unit mehr würde hier wohl bei Interger-Benchmarks (SpecInt und die meisten Real-World-Benchmarks) einen nicht zu unterschätzenden Schub bringen.

5. SMT, Symetric Multi Threading, bei Intel HyperThreading genannt (kllingt mehr nach Hype). Wegen, RAM und L2-Cache-Latenzen liegen immer wieder Units brach. Beim CPUs mit SMT (aktuelle P4 und haben die letzten Alphas nciht auch sowas, oder wurden diese Alpha schon gecancelt) können diese Units für einene weiteren Prozess genutzt werden. Zwar behindern sich nun die beiden Prozesses auf der CPU etwas (umso stärker umso mehr sie dieselben Units brauchen, umso wichtiger wären mehr Interger-Units mit SMT), insgesammt steigt aber i.d.R. der Rechendurchsatz (der einzelne Prozess braucht zwar länger, aber zusammen sind sie schneller fertig als hintereinander ausgeführt).

Ich denke die Punkte 1-3 könnte man schon in einem überrabeiteten 970er sehen (wobei ich bei 3 am spektischsten bin). 4 und 5 wären zwar auch schön wird es aber erst mit einem Desktop-Power5 geben, auf den wir wohl noch bis min. Ende nächsten Jahren warten dürfen.


So jetzt muss mich erst mal sehen was inzwischen hier nich geschrieben wurde ;-)


Bis dann

R"udiger

@r"udiger

Von: comical ali | Datum: 27.10.2003 | #14
also wenn man wissen will, was in den ueberarbeiteten G5 integriert werden wird oder eben nicht, lohnt sich sicher ein blick auf den POWER5.
1. ok das ist der einzige punkt der unabhaengig vom POWER5 ist
2. ist ein wenig mehr geworden gegenueber dem POWER4
3./4. da hat sich laut c't nicht viel veraendert gegenueber dem POWER4
5.ist da! soll besser sein als intels aktuelles.
Zusatz: onchip memorycontroller ist auch mit drin

*kaffesatzwegschuett*

@comical ali

Von: Rüdiger Goetz | Datum: 27.10.2003 | #15
Hallo,

zu 2. Wobei die L2-Größe vom Power4 zum PPC970 ja auch nur bedingt ableitbar war (1x512 kB statt 3x512kB). Es wäre also denkbar das bei einem PPC980 etwas stärker eigenes passiert.

zu 3/4.; Gehört trotzdem auf meine Wunschliste ;-)

zu 5. Sicher der Power5 wird SMT haben, ob das, sich aber auch auch in einem PPC980 wiederfindet, ist ja noch nicht ausgemacht.

Im Übrigen: die Cachegrößen könnten auch schon zu einem sagen wir mal PPC975 verändert werden und bei einem PPC980 wieder die alten Werte haben (wie zeitweise beim G3 und G4, wenn auch da von verschiedenen Firmen).

Wie gesagt, es ist eine Wunschliste und es gehen eh nie alle Wünsche in Erfüllung. ;-)

Bis dann

R"udiger

@kai

Von: comical ali | Datum: 27.10.2003 | #16
auf die gefahr hin, dass ich mich hier in die nesseln setze, weil ich keine ahnung habe: der opteron hat in multiprozessorensystemen mitnichten eigenen speicher. bei diesen systemen addiert sich der einzelspeicher (der prozessoren) zum gesamtspeicher und schwups di wups haben wir auch wieder latenzen(ich weiss jetzt allerdings nicht ob nur fuer den fremdangebundenen oder auch fuer den eigenen speicher).
[Link]

Ali:

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #17
Soso. Was glaubst du denn, was die kleinen hellblauen Rechtecke sind, die in den Diagrammen an den Opterons hängen? ;-) L3-Cache? Wär mir neu, dass der Opteron L3-Cache hat!

Ein integrierter Speichercontroller bringt nur was, wenn jede CPU auch eigenen Speicher hat! Theoretisch würde es wohl gehen, dass man einen Opteron ohne eigenen Speicher per Hypertransport an nen anderen mit Speicher dranhängt und über diesen auf dessen Speicher zugreift, aber DANN hätte man Latencies, dass alle Lichter ausgehen!

Ich zitiere mal die C't 20, Seite 116 links:

"..denn den Speichercontroller (Northbridge) hat AMD auf den Chip integriert. Das bringt den AMD64-Prozessoren klare Pluspunkte in der Speicherperformance (insbesondere bei der Latenzzeit). Da jeder Opteron seinen eigenen lokalen Speicher hat, addieren sich pro Knoten die Einzelbandbreiten. Da kann die Konkurrenz nur staunen, deren Prozessoren sich einen Speicherbus teilen müssen.. Der Power4 und der Itanium versuchen, dieses Manko durch riesige L3-Caches auszugleichen.
Um auch auf den Speicher der anderen Opteronen schnell zugreifen zu können, hat AMD den Prozessoren einen schnellen Systembus spendiert. HyperTransport arbeitet wie IBMs GX seriell mit Hin- und Rückkanal - zwar nur 16bittig, dafür aber mit höherem Takt von 1.6 GHz DDR. Somit beträgt die Bandbreite ebenfalls pro Richtung 3.2 GByte - und das dreimal."

@comical ali

Von: Rüdiger Goetz | Datum: 27.10.2003 | #18
Hallo,

Der Opteron-Mehrfach-System hat eine sogenannte NUMA-Architektur (NUMA = Non Uniform Memory Architecture, O.K. NUMA-Architektur ist doppelt gemoppelt). Dabei ist es dann Aufgabe des OS daf[r zu sorgen, das
Prozesse möglichst so auf die CPUS verteilt werden, das ihr Speicher möglichst lokal ist. Das ist aber auch nix wahnsinnig neues mehr und wird von Firmen wie SGI, IBM, & Consorten
seit Jahren bei "Workstation-Servern" gemacht (siehe SGI Origin 2000 von 1997 oder wohl sogar bei der SGI Octan von 1997, (Dual-CPU Workstion mit 2 R10000 und Crossbarswitch)).

Vorteil eines solchen Systems ist das - wenn es Verteilung der Prozesse auf Speicher und CPUs gut gelingt - jeder Prozess mit vollem Speed auf den Speicher zu greifen kann und sich nicht einen Bus teilen muss. Unds wenns mal nicht klappt ist i.d.R. immer noch "nur" die Latenz gross aber nicht der Durchsatz. Ergo ab einer gewissen Größe (4 -8 CPUs und mehr) würde ein vergelichbar leistungsfähiges Bussystem unverhältnismässig teuer (selbst für Maschine im fünf- und sechstelligen Bereich) und bei den meisten Anwenungen, kann man auch auf einem NUMA-System auf "lokalem" Speicher arbeiten.

Umgekehrt sieht der einzelne Prozess einen einheitlichen Addressraum. Die Umsetzung übernimmt OS und MMU.

BTW: Es spielt dabei keine Rolle ob die einzelnen "Prozesse" echt ectra Prozess sind (acht Runs auf einerm achtfach System parrallel) oder Threads (8 Threads eines Prozesses auf einem 8fach System), solange der Speicher eines Prozesses/Threads im wesentlichen getrennt ist von dem der anderen.

Bis dann

R"udiger

Was ich mir für den nächsten PM G5 wünsche

Von: ks | Datum: 27.10.2003 | #19
ist:

a) Platz für zwei optische Laufwerke

und

b) Platz für drei Festplatten

das war's.

Ich geh' mal davon aus, dass Apple auf der MWSF die zweite Revision der G5s vorstellt (Auslieferung März): Single 2GHz, Dual 2GHz und Dual 2.5GHz.

Auf der MW Tokyo gibt's dann vielleicht schon G5 PBs, als Entschädigung für letztes Jahr (und die Japaner flippen aus *g*).

@ru"diger

Von: comical ali | Datum: 27.10.2003 | #20
das mit dem os wusste ich nicht. wer soll das dann bei den opterons machen? LONGHORN??? hihi haha ... dauert wohl noch ein weilchen uahhhh
*kringel*
also im ernst mal: linux kann das schon oder erst ab kernel 2.6 oder wie ?

@kai

Von: comical ali | Datum: 27.10.2003 | #21
ich sprach von multiprozessorsystemen - glaube ich. aber ruediger hat mich ja verstanden und ist auch auf meine fragen eingegangen ...

??

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #22
Ich sprach natürlich auch von Multiprozessorsystemen!
Was denkst du, warum Heise "jeder Knoten" schreibt? Wäre wohl sinnlos, wenn's nur einen "Knoten" gibt!

@Kai

Von: Rüdiger Goetz | Datum: 27.10.2003 | #23
> Ein integrierter Speichercontroller bringt nur was,
> wenn jede CPU auch eigenen Speicher hat!
> Theoretisch würde es wohl gehen, dass man
> einen Opteron ohne eigenen Speicher per
> Hypertransport an nen anderen mit Speicher
> dranhängt und über diesen auf dessen Speicher
> zugreift, aber DANN hätte man Latencies, dass
> alle Lichter ausgehen!

Genau das apssiert bei einer NUMA-Archtiektur. Sonsts müsstest du ja jede CPU mit dem maximal von einem Prozess benötigten Speicher ausrüsten, d.h. um einen Prozess mit 3.8 GB RAM laufen lassen zu können müsste ich auf eine 4fach Opteron-System 16 GB haben? Ne, da hat jeder Opetron 1 GB und as OS versucht das ganze möglich optimal zu managen.

Wenn man mal sich anguckt wie die Prozesse zwischen den CPU schon in einem normalen 2 oder 4 fach SMP-System springen, dann kann das OS sicher in einem NUMA-System auch immer den Prozess auf die CPU schicken,von der sie als nächstes den Speicher braucht. Das ist sicherlich eine zusätzlich Herausforderung für den Scheduler, aber es geht. Und es mag sein, das einige Teile OS auf allen CPUs parrallel gehalten werden.

Bis dann

R"udiger

Kai

Von: tjp | Datum: 27.10.2003 | #24
Es gibt verschiedene Multiprozessorsysteme. Ein Knoten hat immer für alle seine CPUs linear adressierbaren Speicher, die über einem gemeinsamen Bus oder einer lokalen Crossbarswitch eingesprochen werden können.

NUMA Rechner haben dagegen üblicherweise gleich eine ganze Reihe von Knoten, die über spezielle Switches miteinander verbunden sind. IBMs SP bringt es auf maximal 1024 Knoten mit maximal 8xPOWER3-II. ASCI White ist IMO der einzige Computer, der das SP Konzept komplett ausreizt (mit 8192CPUs auf 1024 Knoten).

Das OS leistet nun bei einem NUMA Rechner die Arbeit, daß der komplette Arbeitsspeicher als ein riesen großer linear adressierbarer Speicher erscheint. In Realität ist er auf n Knoten verteilt und jedesmal, wenn ein Knoten irgend etwas von einem anderem Knoten braucht müssen Daten kopiert werden. Ein direkter Zugriff auf die Daten ist nicht möglich.

Rüdiger:

Von: Kai (MacGuardians) | Datum: 27.10.2003 | #25
Soweit ich das verstanden hab unterscheidet sich das Opteron-Konzept doch deutlich von SGIs ccNUMA.
Sicherlich sind beides NUMA-Systeme, aber beim Opteron hat jede CPU den schnellen Lokalen Speicher während bei SGI alle CPUs über die Crossbar auf "ihren" Speicher zugreifen, dies hat den Vorteil, dass der Speicher pro CPU dynamisch alloziert werden kann, bei AMD ist erstmal Sense und man muss grosse Latencies durch HyperTransport-Zugriff auf "fremden" Speicher in Kauf nehmen, wenn der lokale Speicher einer CPU ausgereizt ist.
Klar, so lange die einzelnen Threads ähnlich sind und gleichviel Resourcen fressen (Render-Threads z.B.) ist es egal, aber wenn man viele kleine Threads hat die wenig Speicher brauchen und ein paar wenige, die extrem viel brauchen denke ich mal, dass die SGI-Lösung besser ist, weil dynamischer! ;-)

Um eventuelle Korrekturen wird gebeten! ;-)

@Kai NUMA

Von: tjp | Datum: 27.10.2003 | #26
Da scheinst Du etwas zu verwechseln. NUMA Rechner sind keine einfachen SMP Systeme sondern bestehen aus vielen SMP Knoten. Bespiele für solche Rechner sind die größeren SGI Origin 2000/2200, die Origin 3000 oder IBM SP/SP2.

NUMA

Von: Rüdiger Goetz | Datum: 27.10.2003 | #27
Hallo,

@tjp: Muss ein NUMA-Konten selbst SMP sein, oder ist das nur so üblich?

@kai: Ich bin mir bei der Origin2000 nicht mehr sicher, ob der Speicher via Crossbar angebunden war, oder ob jedes CPU-Modul selbst eine Teil des Speichers hatte und mit diesem lokal und allen anderen via Crossbar kommunizierte. Ist halt schon etwasher (1996/7) ;-).

Sicher war es aber so, dass mehere Module aus Spiecher und CPUs (8 CPU) eine Einheit bildeten, die mit anderen Einheiten dieser Art über Crossbarswitches verbunden werden konnten. Wurde dann aber bei Max Planck nicht gemacht, da statt dessen 2 Origin 200 mit je 4 CPUs billiger kamen (und selbst das war anch meiner Zeit).

Bis dann

R"udiger

Auto CAD

Von: Jörg | Datum: 27.10.2003 | #28
Was ist eigentlich mit Autodesk? Die wollten doch Auto CAD auf MAC portieren, oder überlegten es jedenfalls!

Schon jemand was Neues aus der Richtung gehört?

Gruss,
Jörg

also mein knoten

Von: comical ali | Datum: 27.10.2003 | #29
befindet sich gerade zwischen gross und stammhirn ;)

@ali

Von: tjp | Datum: 27.10.2003 | #30
Da kann man nichts machen ;-)

Aber die Marketing leute lassen sich ständig neue Namen einfallen. NUMAflex (SGI), NUMA-Q (IBM), Grid Computing, MPP, HPC, ...

Viel L1-Cache gut für die Käsereibe!

Von: Leo | Datum: 28.10.2003 | #31
Leider tun Speicherzugriffe auf dem G5 ziemlich weh, vor allem die zufällig verteilten – ein Zugriff dauert so etwa 270 Prozessortaktschritte, wenn die Daten nicht in den Caches gefunden werden!

„Zufällige” Kreuz-und-Quer-Zugriffe auf Datenblöcke größer als ein paar Kilobyte kommen zwar nicht oft vor, aber nicht zuletzt deshalb, weil es sich keiner traut, die Algorithmen so auszulegen.
Durch mehr L1-Cache würde das erheblich abgefedert. Ich freue mich schon auf *richtig* schnelle 65536-Punkt-FFTs, hehe.