"Cooles neues Produkt" im Januar, MacWorld!

Status
Für weitere Antworten geschlossen.
Yo, ich vergaß, PPC User schauen nicht über den Tellerrand und haben eigentlich auch keine Ahnung...

Aber immer schön im 3d-Gaga Forum über andere Leute herziehen, die sich aufgrund ihrer Abwesenheit nicht wehren können....
 
ausm 3d-Gaga Forum:
Ganon schrieb:
Wobei in einem Punkt (ist aber nix neues was er entdeckt hat ;)) ist es trotzdem komisch.
In einigen Benchmarks von Apple ist Yonah wirklich nur "2 mal so schnell". Das bei 4fach Cache, höherem FSB und 2 Kernen. Und das gegen einen G4...
 
Das hatten wir doch schon alles...


Edit:
pallo schrieb:
Außerdem:
Die Entscheidung für Intel ist gefallen. Damit sollten die Kritiker sich mal langsam abfinden. Rumnörgeln bringt eh nichts!

Also daran halte ich mich jetzt selber (werde also zu solchen Themen nichts mehr posten), denn sonst geht meine nächste Klausur in die Hose, wenn ich hier dauernd abhänge.

Und wie schon gesagt: Entscheidung für Intel ist gefallen. Da bringen solche Diskussionen eigentlich eh nichts mehr außer unnötigen Ärger!
 
Zuletzt bearbeitet:
celsius schrieb:
ausm 3d-Gaga Forum:

Na na, Intel kritische Stimmen werden hier nicht mehr gern gehört *MiterhobenenZeigefingerwink*. Und wenn Du Intel nicht gut findest, hast Du eigentlich eh' keine Ahnung wie so manch' CPU-Guru hier. Dein Sichtfeld geht dann auch nur bis zum eigenen Tellerrand. Und jegliche Kritik ob gerechtfertigt oder nicht wird in die Welt der Halbwahrheiten verschoben ;)

Und schlussendlich, sollte Dir auffallen, daß irgendetwas was Du gebrauchen könntest, bei den neuen PC's aus dem Hause Apple nicht mehr dabei ist, dann gehörst Du halt zu einer Minderheit die irrelevant für die zukünftige Inteluserschaft ist.

Weil Apple macht jetzt dick auf Consumer und so ;)

So genug der Rede, ich geh' jetzt wieder mit meinem iPod spielen ;) ;)
 
So... Nun, Pallo, was hast du mir zu sagen?

Klär mich bitte mal auf und lass mich nicht dumm sterben! Ich bin begierig zu lernen, aber leider leider kommt von der Intel-Front eigentlich nur substanzloses Gelaber und persönliche Anfeindungen...

Was ist denn nun alles "falsch", was ich sage? Bitte konkret werden, ich freu mich schon!...
 
kai_d schrieb:
So... Nun, Pallo, was hast du mir zu sagen?

Klär mich bitte mal auf und lass mich nicht dumm sterben! Ich bin begierig zu lernen, aber leider leider kommt von der Intel-Front eigentlich nur substanzloses Gelaber und persönliche Anfeindungen...

Was ist denn nun alles "falsch", was ich sage? Bitte konkret werden, ich freu mich schon!...

mach dir da keine hoffnungen, man konnte bisher keine konkreten antworten erhalten nur " alles quatsch, geht nicht, rosarote brille und persönliche Anfeindungen usw usf.
 
PPC Jünger, verblendet, fanatisch und Godwins Gesetz bitte nicht vergessen
 
Technowigald schrieb:
PPC Jünger, verblendet, fanatisch und Godwins Gesetz bitte nicht vergessen

mir fällt noch mehr ein, aber was solls :)


ich wünsche mir mal von einem x86- jünger
etwas vergleichbares ;) (siehe zitat)
meint ihr das dass irgendwann möglich sein wird?



Vasco schrieb:
Muh,

mal ein paar Infos:

x86-Architektur (bis i586 (P55C aka Pentium MMX)):

8x 32bit GPRs
- EAX, EBX, ECX, EDX, ESI, EDI für Arithmetische Berechungen, Variablen etc.
- EBP, ESP, EIP für Pointer
5x 16bit Segment Register:
- CS, DS, ES, FS, GS, SS für Segmentselektoren in der GDT/LDT

8x 80bit FP-Register
- ST0..ST7 für 32bit (FLOAT), 64bit (DOUBLE) und 80bit (EXTENDED) Berechunungen

plus diverse Flag-Register (EFLAGS) und Model-Specific Registers (MSRs ab Pentium)

Ab dem Pentium-Pro/PII (i686) werden diese wenigen Register auf ein wesentlich grösseres Shadow-Registerfile abgebildet (damit Out-Of-Order Execution auch funktioniert). Der Programmierer kann diese nicht direkt ansprechen.

Nun zu den SIMD-Erweiterungen:

MMX (ab P55C) aliased 8x 64bit Register MM0..MM7 auf den 80bittigen FPU-Registern und ermöglicht es 8x 8bit BYTEs, 4x 16bit WORDs oder 2x 32bit DWORDs parallel zu verarbeiten.

Es ist entweder FP ODER (Integer) MMX möglich - aber nicht beides gleichzeitig.

3DNow! (ab K6) ermöglicht auf diesen MM-Registern zusätzlich 2x 32bit FLOATs (nach IEEE754).

SSE (ab P3/Athlon XP) enthält 8x 128bittige Register XMM0..XMM7 in einer neuen Funktionseinheit.
Dort sind 4x 32bit FLOATs pro Register unterbringbar für SIMD-Berechnungen. Alternativ kann man durch skalare Operationen nur das unterste Element benutzen. Dies ist primär dafür gedacht die total bekloppte stackbasierte (Stack in einem Registerfile!!) x87-FPU zu ersetzen.
Skalarer SSE Code is wesentlich fixer als herkömmlicher (skalarer) FP-Code.

SIMD-Berechnungen sind _nur_ effektiv wenn die Daten schnell in die Register geladen werden können. Dazu gibt es alignte Speicherzugriffsroutinen (MOVAPS) gegenüber unalignten (MOVUPS). Diese Befehle benötigen ein Ausrichtung Daten im Speicher auf eine 128bit Grenze (16 Bytes).

Großer Nachteil von SSE: Keine 64bit DOUBLEs in den XMM-Registern, ebenfalls keine Integer-Operationen.

SSE2 (ab P4/Athlon64) ermöglicht es nun auch in den 8x 128bittigen XMM-Registern zwei 64bit DOUBLEs unterzubringen. Ebenfalls kann (wie bei SSE) nur das unterste Element verwendet werden für skalare Berechnungen. Ausserdem ermöglicht SSE2 es mit 16x 8bit BYTEs, 8x 16bit WORDs, 4x 32bit DWORDs oder 2x 64bit QWORDs (oder 1x 128bit DQWORD) in den Registern zu arbeiten. SSE2 ist also eine Zusammenfassung von MMX+SSE plus Unterstützung von 64bit DOUBLEs.

SSE3 (ab P4-Prescott/Athlon64-Venice) erweitert SSE2 nur um lausige 10 Befehle, davon 2 für Barriers, 1 Integer, 4 Speicherzugriffsbefehle und 3 für SIMD-Berechnungen (HADDPS/PD) mit der man endlich (oh endlich nach fünf Jahren) das Skalarprodukt einfach berechnen kann.

Fassen wir zusammen:
- MMX+3DNow!: 8x 64bit MM-Register (mit denen der x87 FPU überlagert)
- SSE+SSE: 8x 128bit XMM-Register (eigene Funktionseinheit).

Mit dem Opteron und nun auch mit dem Athlon64 bzw. dem P4 mit E32MT wird
das ganze noch einmal erweitert. Es werden 16 neue 64bit breite Register R0..R15 eingeführt. Die unteren 8 davon enthalten in den unteren 32bit die altebekannten Register EAX, EBX, ECX, EDX, ESI, EDI, EBP und ESP - die oberen 8 werden erst aktiv wenn man in den 64bit Modus schaltet. Zusätzlich wird die Registeranzahl von SSE von 8 XMM-Register ebenfalls noch einmal verdoppelt auf insgesamt 16 (XMM0..XMM15).

Der PowerPC G3/G4 ist eine 32bit Implementation der 64bittigen PowerPC-Architektur welche IBM mit Motorola (und Apple) ins Leben rief, um die 32bittigen 68000er Prozessoren (68030/68040) des Apples (welche schon 8 Datenregister D0..D7 plus 8 Addressregister A0..A7 (A7 implizit SP)) abzulösen. Der PowerPC entstand aus der schon etwas älteren POWER-Architektur von IBM (welche z.Z. mit dem POWER5 immer noch aktuell ist). Die 32bit Implementation enhielt von Anfang an 32x 32bit Register GPR0..GPR31 plus 64x 32bit FP Register FPR0..FPR63. Wenn ich mich recht entsinne konnten je zwei 32bit FP-Register zu einem 64bittigen kombiniert werden (für DOUBLEs). Der PPC 601 bis 603 von Motorola ähnelte in der Architektur dem Pentium (superskalar), der 604 etwa dem PPro. Die e-Versionen (603e/604e) waren (kastrierte) Lower-Power Versionen für Notebooks (bei Apple heissen die Powerbooks und eigentlich nicht ohne Grund ;-). Der PPC 750 (G3) von Motorola war eine Neuentwicklung und ähnelte ebenfalls dem G3. Der G4/G4+/G4e war eine Weiterentwicklung dessen für höhere Taktraten.

Nach dem G4 bekam es Motorola nicht hin höhrere Frequenzen zu erreichen und schmiss das Mikroprozessor-Geschäft hin. Da Apple da ein bisserl dumm aus der Wäsche geguckt hat, haben sie bei Uncle Blue nachgefragt und heraus kam der G5 aka PPC970. Dieser ist ziemlich kompatibel zu den Vorgängern aber von Grund auf eine 64bit Implementation. Da der PowerPC von Anfang an für 64bit designed war musste hier nicht so gepfuscht werden wie bei x86-64 (64bit Erweiterung einer 32bit Erweiterung (i386) eines 16bit Mikroprozessors (i8086) der als Verbesserung eines 8bit Chips (i8080) entwickelte wurde, welcher von einem 4bit Taschenrechner abstammt (i4004)). Die Registerzahl bleibt bei 32 GPRs und 64 FPRs, alle nun 64bit breit.

Die Altivec SIMD-Erweiterung (seit dem G4) bringt 32 neue 128bittige Register für 8, 16 und 32bit Integers sowie 32bit Floating-Point Daten. Keine Unterstützung für 64bit Doubles. Bei der x86-Architektur gibt es nur 2 Operanden pro Befehl, etwa:

MMX: PADD MM0,MM1 (MM1 und MM0 werden addiert und in MM0 gespeichert)
SSE: ADDPS XMM0,XMM1 (XMM1 und XMM0 werden addiert und in XMM0 gespeichert)
ADDP

AltiVec dagegen kann (wie jeder Befehl beim PowerPC), drei Operanden pro Befehl ausführen:

vaddfp vr0,vr1,vr2 (addiere v0 und v1, speichere das Ergebnis in v2)

IA-64 (Itanium) von Intel dagegen ist eine von Grund auf neu designte Architektur mit 128 64bit Allzweckregistern GPR0..GPR127, 128 64bit Floating-Point Registern FR0..FR127 sowie 64 1bit Predicate-Register (für das Ergebnis von Vergleichen) und noch eine ganze Menge mehr. Die Architektur ist von Anfang an auf explizites Scheduling der Befehle durch den Compiler ausgelegt (EPIC). Hier muss der Prozessor nicht mehr Befehle dynamisch auf seine FUs verteilen sondern dies wird beim Kompilieren vom Compiler schon durchgeführt.

Über MIPS könnte ich auch noch was schreiben...

Fazit:

Ich halte von einer hohen Registeranzahl in einer ISA (Instruction Set Architecture) sehr viel. Lokale Variablen und Addressen sollten besser in den Registern zwischengespeichert werden (sofort verfügbar) statt ständig aus den Caches (L1-3) gefetcht werden zu müssen. Je 32 bis 64 GPR und FPR Register sind da denke ich wünschenswert. Register-Starvation wie bei x86 ist denke ich mal kein Geschenk für einen Compilerbauer.

x86 ist veraltet. Punkt.
Ständig wurde irgendwas angeflanscht. Improvisation par excellence. Die RISC-Architekturen (IBM's POWER/PowerPC, SGI's MIPS4, Sun's UltraSPARC, HP's PA-RISC, Digital's Alpha, Intel's IA-64) sind zwar wesentlich eleganter, aber durch eine hohe Anzahl an FUs und Out-of-Order Execution haben sich die x86-CPUs trotzdem wacker halten können (sogar ganz vorne ;-).

Um es kurz zu fassen:
"The x86 isn't all that complex - it just doesn't make a lot of sense."
Mike Johnson
Leader of 80x86 Design at AMD,
Microprocessor Report (1994)

Infos unter:
G4 vs P4: http://arstechnica.com/articles/paedia/cpu.ars (Hannibal Stokes)
x86/IA-32: The IA-32 Intel® Architecture Software Developer's Manual, Volume 1 - 3 (Intel)
x86-64/AMD64: AMD64 Architecture Programmer's Manual Volume 1 - 4 (AMD)
PPC: PowerPC Microprocessor Family - Programming Environments Manual for 64 and 32-bit Microprocessors (IBM)
IA64: Intel® Itanium® Architecture Software Developer's Manual, Volume 1 -3 (Intel)
Allgemein: Computer Architecture - A Quantitative Approach (Hennessey & Patterson) <- lesenswert!

Dieses Posting kommt zwar etwas zu spät, ich hoffe doch dass Ihr damit nicht mehr so im Dunkeln herumstochert - sorry ich konnt's einfach nicht ertragen :D


Cheers,
Vasco
 
Zuletzt bearbeitet von einem Moderator:
celsius schrieb:
mir fällt noch mehr ein, aber was solls :)


ich wünsche mir mal von einem x86- jünger
etwas vergleichbares ;) (siehe zitat)
meint ihr das dass irgendwann möglich sein wird?

Ach Menno, jetzt hör' auf, die schmeissen uns sonst wirklich noch raus :D :D
 
Technowigald schrieb:
Ach Menno, jetzt hör' auf, die schmeissen uns sonst wirklich noch raus :D :D

warum aufhören, der anfang kann nie günstiger sein :D
starten wir eine PPC revolution? rotfl
 
kai_d schrieb:
Was ist denn nun alles "falsch", was ich sage? Bitte konkret werden, ich freu mich schon!...

Ich fang mal an:

1. Der 7448 ist noch NICHT zu kaufen....
http://www.ppcnux.de/?q=node/6070

Zitat:
Mehr als die Ankündigung ist bisher aber auch noch nicht geschehen. Es gibt weder Informationen zu Preisen noch zur Verfügbarkeit. Das liegt aber auch wohl daran, dass FreeScale selbst noch nicht mal die Verfügbarkeit bestätigt hat.

2. Der FSB hat nichts mit Apple zu tun
FreeScale hat den FSB generell nicht erhöht. Das hat nichts mit Apple zu tun. Die jetzt irgendwann hoffentlich höhere FSB-Zahl ist schon seit 3 Jahren angekündig...

3. SSE und Altivec sind 128bit Einheiten
Du hast Recht. SSE ist langsamer. Dafür flexibler da sie auch Skalare Operationen durchführen kann. Weiterhin kann SSE zusätzlich 2x64bit-Berechnung. Das kann Altivec nicht (4x32bit). Die verbreitete Nutzung von SSE ist damit einfacher.

4. CoreImage wird gejittet
CoreImage kann nur eines. Bilder bearbeiten. Wie dies geschieht, hängt vom Rechner ab. Dafür kann der JITC entscheiden:
- FPU-Code
- SSE-Code
- Altivec-Code
- OpenGL 2.0 Code

Das Ergebnis ist überall das selbe. Nur die Geschwindigkeit ist anders.

5. FreeScale kann nicht so schnell
Der DualCore G4 mag gut sein. ABER ES GIBT IHN NOCH NICHT. Der soll irgendwann dieses Jahr raus kommen. Wann auch immer. Bisher gibt's ja noch nicht mal den 7448. Und FreeScale hat Probleme die versprochene Verlustleistung einzuhalten. Schon jetzt frisst der 7448 in Testläufen mehr Strom als der 7447A.

6. CELL ist Hypeware
CELL ist als Desktop-CPU einfach ungeeignet. Das liegt schon alleine an der In-Order Arbeitsweise. Treudoof nach und nach alles Berechnen. Da kann Apple auch gleich beim G5 bleiben, da schon Altivec wenig genutzt wurde. SPUs zu proggen ist noch schwerer...

7. Apple beschränkt FSB?
Kannst du belegen das Apple den FSB von FreeScale beschränkt hat? Über 3 Jahre lang (Ankündigung für RapidIO usw. kamen da schon... für 2006). Warum? Und im G5 1,x "Ghz" FSB haben?

8. Hochoptimierte CPU besiegt von 08/15?
Du preist an, das bei Benutzung von Altivec ein gleichgetakteter G4/G5 schneller/gleich schnell wie Yonah ist. Das ist schön, wenn man den G5 an die grenzen bringen muss um einen Yonah im 08/15-Modus zu besiegen...

9. Altivec der Konsolen
Leider nicht kompatibel... IBM hat dazu VMX-128 "geschaffen". Die massive Anzahl an Altivec-Registern ist leider im G4/G5 nicht vorhanden. Daher bringt das nix. Zudem bringt Autovektorisierung bei Altivec nicht viel, da ein Compiler auch in 2 Jahren, ohne menschliche Hilfe, nicht entscheiden kann was er Vektorisieren kann. Und mit verlaub. Konsolen werden bei weitem anders programmiert....

10. CELL ist bei 64bit lahm
Du weißt schon das beim CELL bei 64bit-Berechnungen die Geschindigkeit nur noch bei 1/10 liegt?
 
Bitte, Leute, nicht persönlich werden.

Geflame wie in manch anderen Forum, gespickt mit persönlichen Untergriffen, ich glaub, ich bin nicht der einzige, der das nicht will.

Zur Sache: mir ist nicht ganz verständlich, warum manche Leutchen auf fast religiöse Art diesem oder jenen Prozessor huldigen.

Ehrlich: mir ist´s egal, welcher Prozessor drin steckt. Ich mag Intel nicht besonders, warum kann ich nichtmal sagen, die Jungs sind mir nicht (mehr) sonderlich sympathisch.

Aber: Nach dem Fauxpas mit Netburst sind sie IMO auf einem besseren Weg, und sie nehmen Milliarden in die Hand, um eine irre Produktoffensive anzugehen. Produktionstechnisch macht ihnen im Moment keiner was vor.

Bei Freescale/IBM: Freescale kann oder will nicht in der Intel - Liga mitspielen, konzentriert sich lieber auf seine Nische. Gut soweit. Eine grossartige Produktpalette für Macs würde ich mir jedoch nicht erwarten.
IBM: baut lieber Prozessoren für Microsoft und beklagt, daß Apple Just-In-Time Lieferung will und sich nicht an den Entwicklungskosten zu beteiligen bereit ist. Auch IBM denkt - wie Freescale - im Moment nicht daran, mehr als die vom Power abgeleitete Prozessorenlinie zu entwickeln. Offenbar nimmt Apple nicht genügend Prozessoren ab, um die Entwicklungskosten reinzuspielen und Apple ist zudem der einzige Kunde, man kann also nicht einfach aus der voll laufenden Produktion CPUs so abzweigen, wie Apple das braucht oder die Produktion nach Bedarf hoch und runterfahren.

All das gibt´s bei Intel: eine voll laufende, gigantisch zu nennende Produktion, kleinste derzeitige CPU-Strukturgrößen, das größte Produktportfolio, eine höchst ambitionierte Roadmap. Das alles garniert mit einem Milliardenbudget für nix anderes als Prozessoren. Nebenher gibts noch den anerkannt besten Compiler industrieweit.

Apple war so schlau, Intel auch noch einen netten Batzen Kohle rauszuleiern, um den Switch zu unterstützen.

Wäre es wirklich schlau gewesen, an G4/G5 festzuhalten, angesichts o.g. Zukunftsaussichten? IMO war sogar der Zeitpunkt gut gewählt, genau zu der Zeit, als Intel dabei war, die Netburst-Scharte gehörig auszuwetzen.

Ich glaube, es handelt sich um eine Win-Win-Win - Situation.

Zum Macguardians-Artikel: ich bin nicht sicher, ob es zwei Versionen desselben gibt, da ich einige weiter oben genannte Zitate nicht gefunden habe.

Wie auch immer: Natürlich muss man sich fragen, warum Apple erst jetzt mit 1 Gig RAM kommt, erst jetzt eine aktuelle Graphik verbaut, erst jetzt einen flotteren FSB spendiert. Aber, immer noch besser, jetzt als nie. Falls es so bleibt, kann ich nur sagen: immerhin, aus Fehlern gelernt.

Mir ist´s wurscht, welche CPU drinsteckt, ich will ein Mac OS und ein Arbeitsgerät, das dem Preis angemessen ist, also gute Verarbeitung, ein gutes Display, usw. Und, nicht zu vergessen: ich leide nicht unter nicht vorhandenen Wartezeiten, der Mac darf (besser: soll oder muss) also ruhig flott zur Sache gehen.
 
celsius schrieb:
mir fällt noch mehr ein, aber was solls :)


ich wünsche mir mal von einem x86- jünger
etwas vergleichbares ;) (siehe zitat)
meint ihr das dass irgendwann möglich sein wird?

Man sollte auch das mit einbeziehen, was hinterher im Thread unter anderem von Gloomy noch gesagt wird. Letztendlich ist die Architektur nicht so entscheident, denn am Ende zählt immer nur das Ergebnis und ein aufgestockter, veralteter 8086 läßt auch heute noch jeden anderen Desktop-Prozessor im Regen stehen. Darüber kann man heulen oder aber, man findet sich damit ab und aus meiner Sicht wird eben für Apple nun vieles deutlich leichter und für die Kunden eben besser.

Ich wiederhole gerne, das ich kein Intel-Fan bin, ich bin auf dem Z80, gefolgt vom MC68000 groß beworden und doch kann ich durchaus realitisch einschätzen, was nun die Vorteile sind und der größte Vorteil für Apple ist nun einmal, das sie mit der x86 Architektur nun einmal ein CPU haben, die auch weiterentwickelt und Marktforderungen angepasst wird. Immerhin muss Apple gegen den PC Markt konkurrieren und nun sind die Rahmenbedingungen absolut ausgeglichen und Apple kann sich ganz auf Innovationen konzentrieren, denn genau die waren es, die eben Kunden fanden und banden. Den Normalkunden interessiert es nun einmal wenig, welcher Motor in der noblen Karosse werkelt, aber Komfort und Fahrgefühl ist es, was er letztendlich spürt.
 
Meiner Meinung nach hat Apple einen starken und zuverlässigen Partner in der Prozessorherstellung gesucht und ihn in Intel gefunden. Der Rest ist doch Geschichte. Ob das die richtige Entscheidung war, zeigt die Zukunft. Ich hoffe es.
 
-Nuke- schrieb:
Mehr als die Ankündigung ist bisher aber auch noch nicht geschehen. Es gibt weder Informationen zu Preisen noch zur Verfügbarkeit. Das liegt aber auch wohl daran, dass FreeScale selbst noch nicht mal die Verfügbarkeit bestätigt hat.

Wurde schon diskutiert. Apple hat das verbriefte Vorrecht, die Dinger als erstes rauszubringen und tut's nicht.

2. Der FSB hat nichts mit Apple zu tun
FreeScale hat den FSB generell nicht erhöht. Das hat nichts mit Apple zu tun. Die jetzt irgendwann hoffentlich höhere FSB-Zahl ist schon seit 3 Jahren angekündig...

Was wurde da wo angekündigt? Gib mal Link!...
Im übrigen genau so ne unfundierte Behauptung wie mir unterstellt wird....

Du hast Recht. SSE ist langsamer. Dafür flexibler da sie auch Skalare Operationen durchführen kann. Weiterhin kann SSE zusätzlich 2x64bit-Berechnung. Das kann Altivec nicht (4x32bit). Die verbreitete Nutzung von SSE ist damit einfacher.

Hab ich auch nie behauptet. 2x64bit DP-Floats kannst du beim G5 auch skalar rechnen und beide in einem Takt dispatchen genau wie bei Altivec (nur muss man die Vektoren nicht alignen), also irrelevant.
Und 32bit-Präzision reicht offensichtlich für viele Bereiche in denen es Apple einsetzt locker aus... Hat sich jedenfalls bisher noch keiner über die Audioqualität von Logic oder die Videoqualität von FCP beschwert, oder?

Die Diskussion bzgl. Altivec-kann-kein-DP ist übrigens sowas von stinkend alt, dass es kein Spass mehr ist. Glaubst du ernsthaft, du erzählst mir da was neues?

CoreImage kann nur eines. Bilder bearbeiten. Wie dies geschieht, hängt vom Rechner ab. Dafür kann der JITC entscheiden:
- FPU-Code
- SSE-Code
- Altivec-Code
- OpenGL 2.0 Code

Das Ergebnis ist überall das selbe. Nur die Geschwindigkeit ist anders.

Mag sein, Apple sagt aber trotzdem seinen Entwicklern, dass das finale Rendering bei CI in der CPU stattfindet. Warum konnte ich nicht rausfinden, ich vermute, dass es an unterschiedlicher Präzision der verschiedenen GPUs liegt. Beweis: Motion (nutzt CI!) rendering wird durch ne schnellere GPU nur ganz marginal schneller, selbst wenn der GPU-Unterschied dramatisch hoch ist.
Der Fakt bleibt, dass die Altivec-Version nach der GPU-Version mit Abstand die schnellste ist und dass gerade CI mit seinen Imagekernels sich _perfekt_ für die SPUlet-Architektur der Cell eignen würde. Es ist quasi dafür gemacht.

Der DualCore G4 mag gut sein. ABER ES GIBT IHN NOCH NICHT. Der soll irgendwann dieses Jahr raus kommen. Wann auch immer. Bisher gibt's ja noch nicht mal den 7448.

Da kenn ich Upgrade-Hersteller, die durchaus anderer Meinung sind...

Und FreeScale hat Probleme die versprochene Verlustleistung einzuhalten. Schon jetzt frisst der 7448 in Testläufen mehr Strom als der 7447A.

Interessant, Link?

Im übrigen: Rechtfertigt ein halbes oder ein Jahr Verzögerung den kompletten Umstieg auf eine andere Architektur, der insgesamt MINDESTENS zwei Jahre dauern wird und der die Kunden richtig satt Kohle für neue Software kosten wird und der viele langjährige Pro-User zum Auswandern bewegen wird, weil sie die Schnauze vom ewigen Switchen einfach voll haben?
Rechtfertigt es den Umstieg, wenn sich die Notebooks SEHR GUT verkaufen mit dem uralten G4-Chip und Apple im letzten Jahr 21% Zuwachs verzeichnen konnte? Welcher andere Hersteller hatte denn ähnliche Zuwachsraten bei den Notebooks?

Ende 2006/Anfang 2007 kommt übrigens auch schon PA Semi mit dem PWRficient. Die hätte Apple aus der Portokasse auch einfach aufkaufen können um sicherzustellen, dass das auch klappt, wollten sie aber nicht....

6. CELL ist Hypeware
CELL ist als Desktop-CPU einfach ungeeignet. Das liegt schon alleine an der In-Order Arbeitsweise. Treudoof nach und nach alles Berechnen. Da kann Apple auch gleich beim G5 bleiben, da schon Altivec wenig genutzt wurde. SPUs zu proggen ist noch schwerer...

Out-of-order-CPUs mit Wasserkopf sind einfach von gestern. Intel hat das schon mit der Itanic kapiert, aber die wollte leider keiner, weil die Zielgruppe gefehlt hat. Mit der PS3 stellt Sony/IBM sicher, dass sich die Entwickler damit auseinandersetzen MÜSSEN und dass eine Marktpenetration und Zielgruppe (Gamer) DA ist, was wiederum eine große Toolchain und viel Entwickler-Knowhow zur Folge hat...

Intels und AMDs x86-CPUs sind besonders toll bei Singlethreaded Integer-Scheisscode mit vielen Branches. Dieser Code WIRD aber in den nächsten Jahren aussterben MÜSSEN! Warum? Weil Multi-Core-Nutzung effizienten modernen Code voraussetzt und Multi-Core nun mal einfach ÜBERALL die Zukunft ist! Und wenn Multi-Core, warum dann nicht gleich Cell? Desweiteren bringt Intel quasi täglich neue SSE-Versionen raus, also ist Vektorcode auch hier die sinnvollere Wahl. Und Vektorcode und Altivec, nunja, ist halt doch was ganz anderes als mit Intel! ;-)

siehe hier:

I also see the same performance ratio - the AltiVec version is easily more than twice as fast as the SSE2 version (take the fastest G5 you can find and the fastest x86 you can find and the AltiVec-G5 version is easily twice as fast). I've taken pride in being able to handily beat the SSE2 version and in many cases doing so with far less instructions. I don't drink the Kool-aid.

I had a conversation with an engineer from a certain fruit company today and he said that even Intel engineers were having problems getting SSE2/3 versions of some of the Apple Altivec sample code running at anything better than half the speed of the Altivec code, and this on a CPU with twice the clock speed of a G5. Steve can sit in his distortion field all he wants but that doesn't change the fact that Altivec is far superior to SSE2/3.


7. Apple beschränkt FSB?
Kannst du belegen das Apple den FSB von FreeScale beschränkt hat? Über 3 Jahre lang (Ankündigung für RapidIO usw. kamen da schon... für 2006). Warum? Und im G5 1,x "Ghz" FSB haben?

D'oh! Um Entwicklungskosten für neue Chipsätze zu sparen natürlich. Je länger du den alten Scheiss unverändert verkaufen kannst, umso höher deine Profite!
Für den G5 brauchten sie sowieso ein neues Chipset, da gab's keinen alten Scheiss, den man weiterverkaufen konnte. Ausserdem ist der Chipsatz hier in Deutschland primär von IBM entwickelt worden! ;-)
Belegen kann ich's nur durch BadAndys Posting und simple Logik: Warum gibt's jetzt, wo Apple nicht mehr da ist, den 8641D mit Dualcore, IMC und RapidIO?
Im übrigen hat FS schon früher CPUs mit IMC gebaut, der 8641D ist also nix neues....

Du preist an, das bei Benutzung von Altivec ein gleichgetakteter G4/G5 schneller/gleich schnell wie Yonah ist.

Wohlgemerkt ein EINZELNER G5!... Zumindest ausgehend von den FCP-Rendering-Werten fürs PB kombiniert mit den FCP-Rendering-Werten der Macwelt (ist leider nicht derselbe Test, aber FCP Rendering ist immerhin wohl wenigstens weitgehend ähnlich), Apple hat jetzt welche für den iMac G5 veröffentlicht, denenzufolge der Yonah-iMac 1.5 mal so schnell ist. Das passt nicht mit dem Zugewinn fürs PB überein, also wird man wohl leider die MW-Werte für Yonah abwarten müssen um das endgültig beurteilen zu können.
Auf jeden Fall ist anzunehmen, dass Apple spezielle Filter und sonstige Parameter ausgesucht hat, die den Intel Mac besonders gut dastehen lassen. Und selbst so ist der Yonah pro Core lahmer als der gleichgetaktete G5. Ein Powermac mit zwei FSBs ist wohl sogar noch deutlich schneller, da es bei FCP sehr viel auf Speicherdurchsatz ankommt.

Das ist schön, wenn man den G5 an die grenzen bringen muss um einen Yonah im 08/15-Modus zu besiegen...

Und wie kommst du auf das schmale Brett, dass ausgerechnet Apple IRGENDWAS für seine Benchmarks hernimmt, was "08/15" ist? Das wäre das erste mal und nicht besonders logisch... Warum sollte Apple bitte Werte nehmen, die den Core Duo nicht besonders gut aussehen lassen? Sie machen ja die meiste Software selbst, also ist nicht-Verfügbarkeit auch kein Thema!

9. Altivec der Konsolen
Leider nicht kompatibel...

Ach??

IBM hat dazu VMX-128 "geschaffen".

Neiiin, echt??

Die massive Anzahl an Altivec-Registern ist leider im G4/G5 nicht vorhanden. Daher bringt das nix.

Und warum interessiert das, wenn Apple auf Cell umsteigt? ;-) Läuft der alte Code mit 32 Registern nicht auf 128 Registern?

Zudem bringt Autovektorisierung bei Altivec nicht viel, da ein Compiler auch in 2 Jahren, ohne menschliche Hilfe, nicht entscheiden kann was er Vektorisieren kann.

Komisch, mir berichten hier leute, dass dank Autovektorisierung der Code mit GCC 4.0 (PPC) 15% schneller ist, und dass GCC 4.1 sogar noch deutlich drauflegt!
Natürlich ist Autovektorisierung NIE so gut wie echter Vektorcode, aber dass es nix bringen soll ist lächerlich. Intel verwendet das schon ewig und ziemlich massiv, und was glaubst du, warum sie inzwischen auf die x87-FPU fast verzichten können? Weil alle x86-Programmierer Vektorcode schreiben? Nö: Weil ihre Compiler das automatisch erzeugen!

Und mit verlaub. Konsolen werden bei weitem anders programmiert....

Ja, sehr effizient! ;-) Inwiefern ist das ein Nachteil für Apple?

10. CELL ist bei 64bit lahm
Du weißt schon das beim CELL bei 64bit-Berechnungen die Geschindigkeit nur noch bei 1/10 liegt?

Natürlich, sogar noch weniger. 9.46 GFLOPS im DP-Linpack ist zwar drastisch langsamer als 155.5 GFLOPS im SP-Linpack, aber immer noch besser als alles andere, was es zur Zeit gibt, incl. G5, Power5 und Itanic! ;-) IBM arbeitet übrigens laut BadAndy schon an DP-Cells, dann wohl mit VMX2 und 256bit-Rechenwerk...
 
Ich hab zwar wirklich Hochachtung vor Daniel Dobberpuhl, aber P.A. Semi wird genau das Problem bekommen, wie AMD, wie NVIDIA und wie zuletzt ATI -> Geld, denn die Fertigungskosten bis zur Massenproduktion werden immer kostspieliger und risikofreudige Investoren weniger. NVIDIA als auch ATI mussten bis zum finalen TapeOut teilweise Verzögerungen von mehr als 6 Monaten hinnehmen, was nicht zuletzt an den Partnern und deren weniger gut als erwarteten Prozesse lag. Bei AMD war es gar nahezu 1 Jahr, bis wirklich taktfreudiges Silikon produziert wurde. Für mich stellt sich da nicht unbedingt die Frage, ob Dan Dobberpuhl das Wissen und die Befähigung hat eine solche CPU bis zur Produktion zu bringen, eher die, ob am Ende des Geldes eine CPU da ist. Aus meiner Sicht ist das einfach ein nicht bzw. nur sehr schwer zu kalkulierendes Risiko und ich kann nicht beurteilen, ob die addierten Geldmittel von P.A. Semi und Apple gereicht hätten, eine CPU auf den Markt zu bringen und über Jahre hinweg konkurrenzfähig zu halten.

Der CPU Markt ist für mich nicht so interessant, aber auf dem GPU Markt kenne ich leider zu viele Firmen, die an den Kosten und Möglichkeiten gescheitert sind. Egal ob nun Bitboys mit den Avalanche und damit verbundenen die Einstellung von eDRAM durch Infineon, was um so tragischer ist, da die Karten für die Serienproduktion fertig waren. Oder aber auch PowerVR, die nicht umsonst meine "Lieblingsfirma" am Grafikchipmarkt sind. Sie haben das Team, sie hatten fertige Designs, aber keinen Partner und so entwickelte man zwar nach dem Absprung von STM brav weiter, aber es fand sich niemand, der helfen konnte daraus fertige Karten zu machen. Obwohl ich die Hoffnung da noch nicht aufgebe, denn auch sie verdienen recht gut Geld im embedded bereich und IP ist nun einmal ihr Kerngeschäft.
 
kai_d schrieb:
Da kenn ich Upgrade-Hersteller, die durchaus anderer Meinung sind...
Also sind schon Upgrade mit MPC7448 verfügbar? Link?

kai_d schrieb:
Im übrigen: Rechtfertigt ein halbes oder ein Jahr Verzögerung den kompletten Umstieg auf eine andere Architektur, der insgesamt MINDESTENS zwei Jahre dauern wird und der die Kunden richtig satt Kohle für neue Software kosten wird und der viele langjährige Pro-User zum Auswandern bewegen wird, weil sie die Schnauze vom ewigen Switchen einfach voll haben?
Apple hat seit deutlich über einem halben Jahr keinen FSB mehr erhöht, keine tatsächlich relevanten Leistungszuwächse in den PBs mehr erzielt. Gut, man mag argumentieren (Ich hab's schon selbst), dass sie die PPC-Entwicklung angesichts des Intel-Switch ausgesetzt haben. Aber mehr als 1,8 Ghz sind mir trotzdem nicht bekannt, bei gleichem Takt. (Was gegenüber 1,67 Ghz beim G4 keinen spürbaren Leistungszuwachs bringt)


kai_d schrieb:
Ende 2006/Anfang 2007 kommt übrigens auch schon PA Semi mit dem PWRficient.
Sorry, die mögen sogar ein interessantes Produkt haben. Aber auf so ein Klitsche verwettet man als Computerhersteller nicht seine ganze Zukunft, wenn man sieht, was die Konkurrenz (Intel) so plant.

Im übrigen: Der PWRficient ist blumig angekündigt worden. Es wäre der normalste Vorgang in der PC-Welt, wenn es ein halbes Jahr, bis ein Jahr länger dauert...
 
kai_d schrieb:
Was wurde da wo angekündigt? Gib mal Link!...
Im übrigen genau so ne unfundierte Behauptung wie mir unterstellt wird....

Hättest du 2003/2004 auf die Seite von FreeScale geguckt, hättest du gesehen das dort schon der DualCoreG4 usw. erwähnt wurde (inkl. RapidIO, etc. pp.)... Die Seite hat sich bisher nicht wirklich geändert...


kai_d schrieb:
Da kenn ich Upgrade-Hersteller, die durchaus anderer Meinung sind...

Kennst? Ich kenne auch vieles...

kai_d schrieb:
Interessant, Link?

http://www.ppcnux.de/?q=node/5660

kai_d schrieb:
Natürlich ist Autovektorisierung NIE so gut wie echter Vektorcode, aber dass es nix bringen soll ist lächerlich. Intel verwendet das schon ewig und ziemlich massiv, und was glaubst du, warum sie inzwischen auf die x87-FPU fast verzichten können? Weil alle x86-Programmierer Vektorcode schreiben? Nö: Weil ihre Compiler das automatisch erzeugen!

Weil's mit SSE leichter ist. Weil wenn du Altivec nicht mit genug Daten fütterst, dann geht der Schuss nach hinten los und die Performance sinkt. Übrigens ist es leicht "pro-autovektorisierungs"-Code zu schreiben. GCC gibt ja selbst an was erkannt wird. Nur reichen 15% mehr Leistung einfach nicht, da diese beim G4 leider die Grundleistung von heutigen Intels nicht übertrifft. Zu diesen kommt dann auch noch SSE hinzu....
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben Unten