Das klingt gut! Da mein nächster Mac sowieso für ca. Frühjahr 2005 avisiert ist, drücke ich ganz ferst die Daumen, dass es bis dahin klappt.
*lechz*

IBM "entwickelt"? Vermutlich haben sie schon Prototypen am laufen. IBM hat die größte Erfahrung mit Multi-Core-Chips(Power4/5).

ja mein nächste mac: 12" powerbook g5 *fg* also dass alles dauert ja noch - mit meinem g4 bin ich hoffentlich noch sicher unterwegs

Anfang 2005 ist zu optimistisch, wenn dann die Produktion bzw. der Testzyklus anläuft, wird es sicher Herbst/Winter 2005. Trotzdem ein überschaubarer Zeitraum. Intel will hingegen den Pnetium M als Dual Core in die Desktops bauen, nachdem sie den P4 abgeschossen haben.

naja sie werden die xbox ja eh mit 3fach core prozessoren mit 3,5ghz pro core beliefern also is der dual core proz wohl eher n abfallprodukt dieser entwicklung

zumindest solang die berichte über die cpu ausstattung der xbox 2 stimmen

On-Chip-Speicherinterface!

Ich hoffe, dass an dieser Front etwas passiert. Die Speicherzugriffs-Latenzzeiten auf dem 970 sind viel zu lang (im Vergleich zu AMD z.B.). Der 970 wird sonst bei Nicht-Streaming-Algorithmen immer etwas hinterherhinken.

Heißt dass jetzt, dass der Rechner doppelt so schnell ist???

Das klingt sehr schön... Ein Dual Prozessor, Dual Core G5 mit je 3 Ghz.... das wäre dann wie ein Quad Prozessor Mac.
Einfach traumhaft. Ich fürchte aber, dass Apple dann auch nur Single Prozzesor bauen wird, weil Dual Core schon reichen dürfte...

Blutfink

Von den hohen Latenzzeiten beim Speicherzugriff des PPC 970 habe ich auch schon gelesen. Und zwar etwas in der Developer Anleitung von Apple, um auf den G5 optimieren zu können. Dort wird behauptet die Latenzzeit wäre um vieles höher, als selbet beim G4...

Thunderson
Fast. Eine Skalierung von 100% gibt es nicht. Aber 90 bis 95% sind durchaus realistisch.

stefab: Wieso fürchten, dass sie nur noch Single-Prozessoren verbauen? Dürfte ein einzelner Dual-Core-Chip nicht sogar deutlich günstiger werden, als zwei Single-Core-Chips? Schon alleine, weil sie sich einen Kühlkörper sparen, denn der sieht irgendwie nicht billig aus. Ausserdem wäre wie Platz im Gehäuse für einen weiteren (Dual-Core-)Prozessor -- für wirkliches HiEnd.

Oder nicht?

> Fast. Eine Skalierung von 100% gibt es nicht. Aber 90 bis 95% sind durchaus realistisch.

mit HT schon (und mehr). denn das soll dann der neue G5, wie jetzt der P4, auch haben...

blutfink

Bitte erkläre uns mal, was du mit "Latenzzeit" meinst?

Also:

Die Dual-Core Version soll <b>kein</b>

- HT (SMT) besitzen
- integrated memory-controller besitzen

Prototypen bekommt Apple im August und September. Produktion soll im Januar 2005 beginnen.

Würde also nicht vor Mitte 2005 damit rechnen. Obwohl Apple im Juli 2001 die G4s auch direkt von der Produktion verbaut hat ohne vorher das Lager zu füllen

Mendel Kucharzeck:

Was Latenz ist, weiß Mendel glaube ich schon
Er wollte es auf den G5 angewendet wissen

Wusstet ihr, dass IBM in seine Server Intel Chips einbaut?

Die langen Zufriffzeiten beim G5 - ist das eigentlich nicht ein Problem des Speicherkontrollers im Chipsatz bzw. das Busprotokoll ?

mattin: 90-95% sind zumindest im Heimanwenderbereich sehr unwahrscheinlich, denn dort ist kein Programm wirklich für HT ausgelegt.
Ausserdem sind beide Virtuelle CPU's immer noch an einen gemeinsamen Bus gebunden - das Nadelöhr in diesem Fall.

Am Ehesten macht sich HT bei speziellen Anwendungen wie Video-Encoden bemerkbar, da ist der P4 "etwas" schneller als ein AMD ohne HT - aber nicht viel.

Trotzdem Schade das Apple keinen Kern mit HT rausbringt, die 5% mehr Fläche auf der DIE für einen zweiten Satz an Registern wäre kein allzugroßer Aufwand gewesen.

mattin
Es ging um Multi-Core, nicht um "simulierte" Prozessoren. Und da gibt es keine 100%ige Steigerung/Skalierung.

lex
Wusstest du das IBM die Pentiums sogar fertigt? Bei den richtigen Servern (p-Series) setzen sie aber vernünftige Prozessoren ein.

Die ganze Welt ist parallel. Das menschliche Gehirn arbeitet parallel und mit einem sehr geringem Takt. Die Leistung kommt aus der Parallelität der vielen arbeitenden Zellen.

ahso ok...

HT braucht der P4 nur, weil er eine so miese Pipeline-Ökonomie hat. Der schiebt im Normalbetrieb 20-30% (mal so aus dem Bauch heraus geschätzt) Pipeline-Bubbles herum und die kann man - im Idealfall - mit HT füllen.

Da der 970 seine Pipeline besser gefüllt hält, würde HT zu einem extrem unsymmetrischen SMT führen und nur wenig bringen. Dafür bringt er auf der OS-Seite wieder deutlichen Aufwand, denn der Scheduler muß berücksichtigen, daß der "zweite" (virtuelle) Prozessor nur einen Bruchteil der Last aufgebürdet bekommen darf, da er ja nur die Löcher füllen kann.

Der P4 eine zwei Stufen, die *nichts* machen sogar. Sog. "drive" stages.

Ratanplan: Gut geschätzt, laut wikipedia ~30%

Was mich wundert ist daß laut Text beide Kerne mit Cache auf 11*13mm passen sollen, das ist weniger als eine aktuelle AMD-CPU(P4 sieht man ja nicht).

Man sollte aber nicht vergessen daß seit der Pentium-Familie ~30% der CPU-Fläche für die CISC-RISC Umwandlung verwendet wird, na wenn das mal keine teure Platzverschwendung ist

MacMark: Das sehe ich heute zum ersten mal, 2Stufen in der P4-Pipe die nur dafür sorgen daß die Signale zur Richtigen Zeit an der nächsten Stufe bereitstehen.

...und trotzdem hat es die Wissenschaft bis heute noch nicht geschafft das analoge Gehirn eine Fliege nachzumachen - sind ja nur an die 14.000 Zellen

Auf jeden fall sehr interessante Entwicklung. War ja irgendwie auch logisch, dass diese Entwicklung kommen würde, da ja die PPC970er von den Power4(und5) von IBM abgeleitet sind.
Ich denke aber auch, dass vor Mitte 2005 nicht damit in verfügbarer Hardware zu rechnen ist, eher gegen Herbst 2005. Aber das wäre trotzdem toll für Apple.

Ich hoffe für Frühjahr 2005 erstmal mit den versprochenen 3Ghz.....

Mendel

Longer latency instructions


If you have written very tight loops that depend upon the latency of operations on the G4, your code may encounter stalls on the G5. These stalls can be addressed by better code scheduling, loop unrolling and software pipelining. Longer latencies to memory. As the CPU frequency has increased at a much faster rate than the memory frequency, the relative time to access memory has increased in the G5 vs. the G4. If at all possible, loops should be unrolled and data should be accessed as early as possible before it is used. Prefetching can be done using DCBT, or using the hardware prefetch engine if the stride is regular and established early. Another scenario to check for is invariant loads, i. e. loading of data that does not change inside a loop. By moving the invariant load outside of the loop, the processor does not need to re-fetch unchanging data from memory during each loop iteration. Removing these unnecessary memory accesses will result in big performance boosts. Frequently, use of global variables causes unnecessary memory accesses. The compiler is forced to be very conservative when globals are used because the compiler must assume worst-case aliasing conditions. Thus, rather than keeping values in registers, the compiler will load and store from memory to ensure correctness.

Noch zu Vergleich G4 optimierten Code am G5 ausführen...

Use fewer locks


Due to the increased number of execution pipeline stages and the increased latency to memory, the time to access and acquire a lock can be up to 2.5 times slower than on the G4. While there is little that can be done to speed up the execution of the locks themselves, reducing the number of locks used in your code can drastically improve its overall performance on the G5.


The resolution of the reservation made by the lwarx instruction is one cache line. Since this was increased from 32 bytes on the G4 to 128 bytes on the G5 this means that synchronization primitives that use lwarx/stwcx pairs are four times more likely to fail on the G5. Specifically avoid storing multiple mutexes in the same cache line.

Und die weniger optimale Altivec Einheit:

Velocity Engine issue constraints


Instruction issue to the Velocity Engine units on the G5 is the same as that in the 7400/7410 G4: only two instructions can be issued to the Velocity Engine units in the same cycle if one of them is a vector permute. In the 745X G4, these issue constraints were relaxed to allow any two Velocity Engine instructions to be issued each cycle. If your code differentiates between the different Velocity Engine issue schemes, choose the 7400-targeted one for use on the G5. Of course, your code may still need to be restructured to handle the increased latencies of the G5 Velocity Engine pipeline. Avoid small data accesses. Due to the increased latency to memory, the longer cache lines, and the nature of the CPU-to-memory bus, small data accesses should be avoided if possible. The entire system architecture has been designed to optimize the transfer of large amounts of data (i. e. maximize system memory throughput). As a side effect, the cost to handle small accesses can be very high and is quite inefficient. If possible, allocate data in large chunks to better amortize the overhead to access memory. Adjust to the smaller cache. High-performance programs that have tuned themselves for the presence of an L3 cache will need to be re-worked to fit in the (now larger) 512K L2 cache. The Effective-to-Real Address Translation (ERAT) cache contains 128 entries, enough to map 512K of data, the same size as the L2 cache. Thus, if you optimize your code for the 512K L2, you will maximize the use of the ERAT in the process.

Die Redaktion hier sagt ja immer, der G5 sei die Wundermaschine und der G4 der letzte Schrott. Bedenkt man aber, dass viel Software speziell auf den G4 optimiert ist, leidet der G5 darunter, sie die Kommentare weiter oben und mehr:



Und ich sage euch: solang nicht speziell auf den G5 optimiert wird, bringt er nicht mehr pro Takt, als der G4, ausser im 3D Rendering, wo der G4 wirklich immer Schrott ist und war.

PS: Man kann auf JEDEN Prozessor (auch G3, G4, G5 einzeln) optimieren, und nicht nur auf die Velocity Engine...

alles schrott was ihr hier faselt.

am besten ist eh mein 486 er Super Computer mit echten 100 MHZ, 518 MB Festplatte, krassen 8 MB Arbeitsspeicher und dem geilsten betriebssystem aller zeiten...win 3.11

wer ist bitte jetzt noch krasser als ich?


:-):-)

PowerFerdi...

Bis auf das OS ist das ja noch ok... Ich kann mich gut erinnern, schon damals war Win 3.11 seiner Zeit sehr, sehr weit hinten nach...

Immerhin gabs da schon die Amiga Workbench 2.0 oder vielleicht gar schon 3.0!

stefab: Soweit natürlich alles richtig was du postest und es sprudelt geradezu über vor Infos, aber zu sagen der G5 sei generell solange die Software nicht auf ihn optimiert ist pro Takt nicht schneller als der G4 ist blanker Unsinn. Zwar kann der G4 sogar pro Takt schneller sein, gerade wegen der besseren AltiVec-Einheit und den geringeren Latanzen, das sieht man z.B. bei RC5. aber dies gilt nur solange die Workloads nicht Bandbreitenlastig sind. Wenn sie es sind ist der G5 auch bei gleichem Takt meist überlegen, hier ist dann der wirklich aus der Steinzeit stammende FSB des G4 einfach der Flaschenhals, da nützen dann auch alle anderen Vorteile nicht mehr viel.

Das mit den Locks ist übrigens auch zum großen Teil ein OS-Problem. Hier kann man bereits sehr viel im Kernel- und scheduling Bereich optimieren. Allerdings ist es richtig dass eine unbedacht programmierte Anwendung hier desaströs zuschlagen kann, auch wenn das unterliegende OS wirklich gut optimiert ist.

Und ja, das Amiga-Kickstart war gerade vom Multitaskingverhalten seiner Zeit weit voraus, wenn nur nicht der nicht vorhandene Speicherschutz und die wenig portable Grafik-API so lange durchgehalten hätten, hätte es mir vielleicht auch länger als bis 1993 Spaß gemacht damit zu arbeiten. Zu dumm daß Commodore und Atari die Zeichen der Zeit nicht erkannt haben...