Doch eventuell PB G5 zur Jahreswende?

AltiVec ist eigentlich totes Silizium. Apple benutzt das noch nicht mal da im System wo es einsetzbar wär und etwas bewirken könnte. Im Kernel ist es auch nicht eingesetzt. Es gibt einige PS Filter und Audiosachen wo es in Programmen verwendet wird, in QuickTime z.B. wär dafür auch noch Potenzial, und das seit Jahren.

Und ich kann es Apple auch nicht verübeln, dass sie es selten verwenden, es passt einfach zu sehr wenigen Datenstrukturen und auch Autovektorisieren ändert daran nichts.

Bei dieser Adoptionsrate wird das MacOS etwa im Jahr der Geburt von Perry Rhodan mit AltiVec protzen können. Ich meine man könnte den Chipplatz besser nutzen. Z.B. für schnellere Integerunits.

Altivec ist schon recht, nur das was einige davon erwarten ist furchtbar übertrieben, es ist nicht die Wunschfee. Und meiner Meinung nach war es eine klassische Totgeburt. Zu spezialisiert.

 

So früh schon?

Zur Info:

Perry Rhodan

Geburtsdatum/Ort:
am 8. Juni1936 in Manchester (Connecticut)

 

Komisch nur warum dann Jobs auf eine Vektor-Unit bestanden hat und nur deswegen auf Motorola gesetzt hat, weil IBM AltiVec in ihre CPUs nicht integrieren wollte...

Und schalte mal die Autovektorisierung bei den Intel-Compilern aus und man sieht wie langsam der P4 auf einmal ist

Ich mein, ich bin kein Programmierer, aber unterhalte dich doch mal mit Hobold oder BadAndy, die können dir bestimmt sagen, wieviel AltiVec bringt.

Das einzige was ich nicht verstehe, warum IBM damals die eigenen Leute an Intel ausgeliehen hat, um autovektorisierende Compiler zu schreiben. Die mussten ein NDA unterschrieben und dürfen heute nicht an solchen Compilern bei IBM mitarbeiten.

Gruß
Kalle

 

Jobs macht merkwürdige Sachen und hat schon mal steinerne Meinungen, die er später mühsam kaschiert revidieren muss. Wer ihn aber vorher auf Unsinn hinweist muss mit Rausschmiss rechnen. Altivec war eine strategisch-"politische" Geschichte um der Stagnation der damaligen CPUs etwas entgegen zu setzen zu haben. Die Anwendung war auch damals schon begrenzt.

Und die Historie war wohl etwas anders, SJ hat nicht deshalb Moto gewählt weil die Altivec in den CPUs drin hatten und IBM nicht. Die Vektorunit brauchte Moto (heute Freescale) weil die CPUs auch für dem Embedded Bereich gedacht sind und dort Altivec als Signalprozessoreinheit arbeitet. Die war einfach schon mit an Bord, es war und ist gut designed, viel variabler als alles was damals und später bei Intel eingebaut war und kann tatsächlich in speziellen Fällen eine 5-7 fache Beschleunigung bei vektorisierbaren Operationen bewirken. Es war klug das zu nutzen, aber der Aufwand das zu Implementieren steht nicht immer in einem brauchbaren Verhältnis zum Nutzen.

Es gibt viele vektorielle Operationen, die Altivec übernehmen könnte, nur bringt das erst dann etwas, wenn diese Operation auch tatsächlich den Flaschenhals darstellt. Nur so als Beispiel: Man könnte mit heutiger Technik die Addiergeschwindigkeit einer Supermarktkasse kostenneutral um da Faktor tausend steigern. Aber solange die Scanner und die Handeingabe so oft hintereinander stattfinden und so zeitaufwändige Schritte sind, macht es keinen Sinn eine Teiloperation von 2 Millisekunden auf 2 Mikrosekunden zu verkürzen wenn die Gesamtoperation weiterhin 2 bis 5 Sekunden +- 2 Mikrosekunden dauert. Der Beschleunigungseffekt ist nur theoretisch da und praktisch kaum messbar.

Das gilt generell beim Optimieren eines Programmes. Sonderfunktionen implementiert man nur da wo es signifikante Auswirkungen hat. Daher hielt sich der Altivec-effekt einfach immer in Grenzen und bis auf spezielle Funktionen wird die Technik dann eben folgerichtig auch nicht nutzbar.

Zudem benötigen aber Anwendungen und auch das Betriebssystem zum Löwenanteil Intergeroperationen vom skalaren und nicht vom vektoriellen Typ. Der potenzielle Anteil der Anwendung ist also von vorne herein stark beschränkt. Dass eine CPU vom PPC97X Typ heute von IBM eine solche Unit hat, heisst nicht, dass sie unverzichtbar wäre, sondern sie ist mit moderatem Aufwand und zu akzeptablen Kosten herstellbar und bringt einen gewissen Nutzen. Ausserdem muss man abwärtskompatibel bleiben und für das propagierte Altivecbewusstsein und das Image ist es erstmal wichtig dass das dabei ist.

Auf meine dezente Frage an einen Entwickler ob und wann der Systemkernel von einer vektoriellen Hardwareunterstützung profitieren kann gab es nur als Antwort, dass das gar nicht angedacht sei.

Altivec ist bis auf beeindruckende Sonderfälle eben in der Regel totes Silizium. Im Grunde sind eigentlich alle ähnlichen Sonderhardwarelösungen z.B. von Intel im Wesentlichen gescheitert, und zwar nicht weil sie etwa generell ineffizient wären, sondern weil sie nicht generell einsetzbar sind, die Kodebasis aufspalten, was sehr unwirtschaftlich und fehleranfällig sein kann, und weil die Mühen der Implementierung in der Regel die Ergebnisse nicht rechtfertigen. Besonders wenn man Programme auf verschiedenen Ziel-Systemen einsetzen will, z.B. Adobes PS.

Altivec kann und konnte also aus technischer Sicht die Gesamtperformance eines Prozessors und der darauf laufenden Prozesse nicht signifikant heben, weil das gar nicht zu diesem Zweck in eine CPU eingebaut worden ist. Es war und ist eine Unit für spezielle Fälle, die sensationelle Performance bei diesen und nur diesen reinen Vektoranwendungen bringt weil es hardwaremässig das in einem Schritt kann, was sonst ein umständliches Programm in vielen Schrittchen machen müsste.

Diese Spezialfälle waren und sind wichtig im Bereich den Moto mit dieser CPU abdecken wollte, aber beim Einsatz als generelle CPU für ein Computersystem sind sie rar. Apple könnte also relativ problemlos (abgesehen von der politischen Kehrtwende, die man dann verkaufen müsste) neue Mac mit CPUs herausbringen denen Altivec fehlt. Das könnten IBM CPUs sein, oder auch Intel CPUs, oder sonstwas. Auch Freescale CPUs sind da denkbar.

 

@Kate
ich gehe 100% konform mit Dir

Möchte sogar noch eines drauf setzen.
***jetzt bitte nicht hauen****

Altivec ist im Grunde sogar ein Hemmschuh für Apple.

Jeder, der einen G4 hat (mich eingeschlossen) freut sich zwar wenn er Altivec-Optimierte Programme erhält - und hofft auch immer darauf.
ABER eigentlich wäre es für die Chipentwickler und Programmierer einfacher Altivec fallen zu lassen - das spart Kosten und beim G5 bringt diese Implementation im Grunde auch nix - und das wird wohl auch die Zukunft sein.

Und noch einen...
Der G3 war im Grunde der effizientere Prozessor - vergleicht mal den G3 und G4 mit NICHT Altivic-Optimierten Programmen - da sieht der G4 nicht sehr gut aus.

Der G5 wird Altivec früher oder später überflüssig machen und "sterben" lassen.
Freescale wird mit dem e600 ebenfalls ENDLICH (so es wahr wird )einen Prozessor mit DDR2-Unterstutzung und einem FSB von über 600Mhz rausbringen - das bring mehr als noch mal ein paar Altivec-Recheneinheiten...
Da frag ich mich wozu man Altivec in Zukunft noch braucht.

 

Wenn der "G4" von Freescale mit e600 Kern und mit einem anständigen Buscontroller kommt wird das, so wie es im Moment auf Grund der Papierform dieser CPU aussieht, ein fast genialer Prozessor für einen Mobilcomputer sein. DAS wäre für mich DAS PowerBook der nächsten Generation.

So ein PowerBook würde ich fast blind kaufen und jedem "G5" PowerBook eindeutig vorziehen. Es sei denn IBM gelingt es einen 970er Prozessor für den Mobilbereich zu bauen der zusätzlich noch ein effizientes Powermanagement und geringen Grundenergieverbrauch hat. Das wäre dann aber eigentlich kein 970er mehr.

Im Grunde möchten die Kunden doch auch kein "G5" Laptop sondern einfach ein Laptop mit mehr Leistung bei besserer Akkulaufzeit als jetzt, und genau in diese Richtung geht es bei Freescale. Also würde ich es für sehr wahrscheinlich halten dass Apple genau das macht was Herr Schiller auch explizit sagte, dass im "G4" noch ein langes Leben im Mobilbereich steckt.

Ich halte es von der Technik her für recht sinnvoll und wahrscheinlich, dass auch die nächste Generation der PowerBooks und iBooks "G4" basiert sein wird, obwohl das marketingmässig durchaus mit einem neuen, überraschenden Namen kommen könnte.

 

Ich hoffe nur, daß Freescale auch die Sache mit der Hitze in den Griff bekommt.
Denn selbst wenn so ein Chip weniger Strom verbraucht kann es passieren, daß er sogar noch heisser wird da die Oberfläche ja kleiner ist.
Beim Destop wär das durchaus zu lösen - beim Mobilrechner könnte das sehr viel schwieriger werden.

Aber wenn es Freescale tatsächlich schafft wär das ein Meilenstein.

IBM schläft aber sicher nicht - eine GX-Variante des G5 mit 1MB-Cache soll es ja auch bald geben. Vielleicht basteln sie ja auch an einem stromspar-G5

Ich trau der Sache noch nicht ganz...

 

Ich sehe das genauso.
Was allerdings die Sache mit dem anderen Namen angeht - warum denn? Wenn dann würde ja nur sowas wie "G4+" Sinn machen, denn G5 ist vergeben, "G6" wäre Blödsinn (und für den e600 nicht gerechtfertigt). Allerdings hätte der Name "G4+" doch dann schon eher kommen müssen. Aber - wie Du sagst - Steve macht manchmal merkwürdige Sachen.

Was Altivec angeht: Du hast sicher recht mit dem, was Du sagst, aber ich find's trotzdem nett, um wieviel schneller vieles von dem, was ich mache auf meinem G4 läuft als auf meinem G3. Ich find´s klasse, daß Altivec mit auf der CPU ist und ich möchte es nicht missen.

Andererseits... das letzte mal als wir hier so eine Diskussion hatten (damals ging es darum, ob in die iBooks besser nochmal ein G3 kommten sollte - der PPC750fx von IBM - oder ein G4), ging die Sache überraschend zugunsten des neueren Prozessors (damals war das der G4) aus.

 

So so. Die Stagnation der damaligen CPUs...
Die Stagnation hat aber damals erst mit den MOTO-CPUs eingesetzt. Davor war man schneller, dann gleichauf.

Du willst mir doch nicht erzählen, dass man 1998 schon gewusst hat, dass man zwei Jahre später (dank MOTO) ins Hintertreffen gerät?

So so, 5-7 fache Beschleunigung. Da hab' ich aber schon von 30 facher Beschleunigung gehört
Und ich glaube, die Historie war so, dass Jobs unbedingt AltiVec nutzen wollte und IBM aber gesagt hat, dass man sich das RISC-Design nicht versauen will und AltiVec nicht nutzen wird. Daraufhin hat man dann Motorola zum Hauptlieferanten erklärt

Schon klar...

Wird man ja sehen, wenn der autovektorisierende Compiler von IBM da ist (+ zwei Jahre)

Komisch, warum nur arbeitet IBM dann an VMX2

Na und, nicht angedacht heißt noch lange nicht, nicht möglich
Wie gesagt, ob's möglich oder sinnvoll ist muss man jemanden fragen der Ahnung hat.
Mit wem hast du dich denn unterhalten, wenn man fragen darf?

Wenn sie gescheiter sind, warum hat dann Intel autovektorisierende Compiler

Schon klar und ein entsprechender Compiler wird da optimieren wo es eben möglich ist, was eben heute die wenigsten Entwickler tun.

Wahnsinn, wer hätte das gedacht
Spezialfälle... Audio... Video... verstehe :tongue:

Gruß
Kalle

 

Worauf willst du denn hinaus?

*Du willst mir doch nicht erzählen, dass man 1998 schon gewusst hat, dass man zwei Jahre später (dank MOTO) ins Hintertreffen gerät?*

Nö. Inwiefern steht das in Zusammenhang mit dem was ich geschrieben hatte?

*So so, 5-7 fache Beschleunigung. Da hab' ich aber schon von 30 facher Beschleunigung gehört*

Je nach OP-Code und Operanden sind auch Faktoren von 100 "drin" verglichen mit alternativen Möglichkeiten. Die 5-7 fachen Faktoren sind übrigens Angaben von SJ. Angeblich basierend auf Vergleichen. Ich meine die Faktoren sind schon seriös. Aber da gibt es keine "fixen" Angaben, es kommt auf die Art des Test und das Wertungskriterium an. Gerne kannst auch an allgemeine Beschleunigungen von 100 "glauben"

*und ich glaube, die Historie war so, dass Jobs unbedingt AltiVec nutzen wollte und IBM aber gesagt hat, dass man sich das RISC-Design nicht versauen will und AltiVec nicht nutzen wird.*

Sicher. IBMs Haltung war ja damals klar. Er wollte es eben nutzen. Wie ich schon sagte. Damals gab es ja noch das PPC Konsortium.

*Wird man ja sehen, wenn der autovektorisierende Compiler von IBM da ist (+ zwei Jahre)*

Ja und. Was der kann kann man auch selber, und was man selber lässt weil es nichts bringt kann der dann machen/nicht machen und es bringt auch nichts....der Anteil der prinzipiell vektorisierbaren Algorithmen in z.B. einem OS ist dann immer noch sehr klein.

*Komisch, warum nur arbeitet IBM dann an VMX2*

Was ist daran komisch? Apple und andere Kunden können es brauchen, bzw. wollen das haben und darum wird es gemacht. Es ist ja auch für manche Dinge durchaus vernünftig.

*.. und, nicht angedacht heißt noch lange nicht, nicht möglich
Wie gesagt, ob's möglich oder sinnvoll ist muss man jemanden fragen der Ahnung hat.
Mit wem hast du dich denn unterhalten, wenn man fragen darf? *

Simon Patience, wieso?

*Spezialfälle... Audio... Video... verstehe*

Ich verstehe dich so, dass du denkst, dass Altivec sich generell für Audio und Videozwecke einsetzen lässt und daher beim Weglassen der Unit diese Anwendungen "leiden". Die Unit lässt sich tatsächlich dafür einsetzen wie ich bereits geschrieben hatte. Und? Innerhalb der Anwendungen, die sich mit Audio und Video beschäftigen kann man damit gut arbeiten. Genau da sind die Dinge wofür die Unit gedacht war. Aber es geht auch ohne, Altivec ist nicht die generelle Lösung für die Performanceansprüche von Videoanwendungen. Audio ist auch z.B. auf einem G3 gut handhabbar.

Ich verstehe dich so, dass du meinst, dass ohne Altivec die Leistungsfähigkeit im Allgemeinen und speziell bei Audio und Videoanwendungen grob geschmälert werden würde?

Aber das geht am Diskussionspunkt vorbei.Ich wollte mit dem was ich geschrieben hatte klarstellen, dass es ein Irrglaube ist, dass Altivec generell die Leistungsfähigkeit irgendeines Mac bei realem Einsatz abgesehen von einigen Spezialfällen positiv beeinflusst. Aber dem hast du ja schon zugestimmt. Wieso bist du also so gereizt?

 

Muss ich dich jetzt schon selber zitieren?
"Altivec war eine strategisch-"politische" Geschichte um der Stagnation der damaligen CPUs etwas entgegen zu setzen zu haben"

Falsch... von Stagnation war damals noch nichts zu sehen, kam ja schließlich erst mit MOTO auf.
Und Apple wollte damals, dass IBM AltiVec in ihre CPUs integriert, sie hielten es aber für überflüssig... und jetzt arbeiten sie an AltiVec2.

Und du weißt, dass Apple, IBM, Motorola und einige Softwarefimen wie z. B. Adobe gemeinsam AltiVec spezifiziert haben?
Und du weißt ja sicher auch, dass die AltiVec-Einheit im G5 die vom Ur-G4 is.

Hat nix mit glauben zu tun. Um genau zu sein 38,5 mal schneller als der skalare Code:

--------------------------------------------------------
Ach doch, eine Routine hab ich schon vektorisiert, um den Kollegen mal zu zeigen dass sich das tatsaechlich lohnt. Dieses Beispiel ist jetzt meine neue persoenliche AltiVec-Bestleistung: 38,5 mal schneller als der skalare Code. Und das ist noch nichtmal die hochglanzpolierte Endfassung. Es lohnt sich halt doch, wenn man parallel sechzehn Ganzzahlmultiplikationen und dazu sechzehn Additionen mit einem einzigen Befehl pro Takt ausfuehren kann ...)

...

Ich hab keine Ahnung, ob irgendwer Buch fuehrt. Aber es ist das drastischste Beispiel was mir persoenlich bekannt ist.

...

(AltiVec kann entweder acht parallele 16x16bit, oder sechzehn parallele 8x8bit, wobei gleich zwei (16x16) bzw. vier (8x8) Resultate auf je einen 32 Bit Akkumulator aufaddiert werden.)

16 FMAC entspricht schon 32 skalaren Befehlen, und dazu kommt dann noch, dass die Integermultiplier des PPC970 nicht pipelined sind, das heisst man kann unterm Strich nur so alle zwei bis drei Takte (gibt leider immer noch keine ofizielle Doku mit genauen Werten) eine Multiplikation ausfuehren (obwohl der G5 ja zwei Multiplier hat!). Dazu kommt noch, dass wenn ein Multiplier am Ackern ist, blockiert er eine der Integer Pipelines auch fuer andere Befehle (also in diesem Fall Additionen). Unterm Strich fuehrt der G5 also den skalaren Code etwas langsamer aus als ein Befehl pro Takt. Daher ist der Speedup Faktor groesser als 32, so unglaublich es klingt.
--------------------------------------------------------

Genau, und er wollte, dass es IBM nutzt

Falsch! Wer schreibt denn schon Vektor-Code? Sind doch alle zu faul (hast doch vorhin selber gemeint, das es zu aufwendig ist)... und deswegen kommen die Autovektorierer ins Spiel, zwar nicht so gut wie handoptimiert, aber besser als gar nix.

Im übrigen können die Intel-Compiler inzwischen schon so optimieren, dass jedes Programm inzwischen SSE2 nutzt
Und schon komisch... wenn eine SIMD-Unit nur in ausnahmefällen genutzt werden kann, warum war dann wohl AMD so scharf auf SSE2?

Aber laut deiner These ja nur in Ausnahmefällen:
Nimm Musikern AltiVec weg und die hälfte der Plug -ins geht nicht mehr...
Video-Editor... und Encodieren dauert doppelt so lange...
FCP und Echtzeitfilter ade...
Schau dir mal die WWDC-DVDs an, Tiger ohne AltiVec, viel Spaß
CoreImage ohne passende Grafikkarte... okay...
Ohne Altivec und tschüs...

Du kennst FFT(Fast Fourier Transform), gibt's ne AltiVec-Version, zieht der skalaren Version die Schuhe aus.
Dito. DCT (Discrete Cosinus Transform).

Bin halt neugierig.
Systemkernel und AltiVec, hmm. Führt der Kernel irgendwelche Rechenoperationen aus?

GarageBand, verstehe

Jo.

Och komm, bin doch nicht gereizt *schäm*
Ich lege doch nur meinen Standpunkt dar
Generell kann die Leistungsfähigkeit sicher nicht gesteigert werden, aber von Spezialfällen reden finde ich eben auch übertrieben.

Also ich wollte dich jedenfalls nicht angreifen, sondern nur diskutieren

Wenn wir uns mal treffen sollten (was ich nicht glaube), dann geben ich dir mal einen aus oder kaufen dir ein paar Manolo Blahniks
Aber wenn ich blank bin, dann bekommste eben nur eine Fußmassage

Gruß
Kalle

 

Was die Zusammenbhänge in der Vergangenheit angeht, meine ich, beurteilen wir das doch eigentlich ähnlich, nur begucken wir es aus unterschiedlichen Perspektiven, ich sehe es mehr aus der Ei-Perspektive, du vielleicht mehr aus der Huhn-Perspektive.

Auch bei den Angaben zum vektoriellen Performancefaktor sind wir doch einig, du beziehst dich mehr auf die Faktoren für die Operation, ich mich eher auf die Faktoren für ein Programm. Das kommt dann gut hin mit den Werten.

Bei den Compilerfeatures reden wir aneinander vorbei. Sicher, eine Autovektorisierung im Compiler ist schön, und sie erspart die Handarbeit, die unter dem Strich bei einem ganzen Program kaum mehr bringt als ein guter Compiler. Aber da wo die Vektorisierung Sinn macht bringt auch der Compiler etwas und wo nicht eben nicht. Eine Autovektorisierungsoption im Compiler macht ja aus skalaren Operationen sequenzieller Natur nicht eine vektorielle Lösung für eine weiterhin sequenzielle, skalare Aufgabe. Genau das meinte ich, dass auf Grund dieses Compilerfeatures nicht auf einmal der gesamte Code eines Programmes um den Faktor 30, oder was auch immer, schneller wird. So wird das nämlich oft missverstanden, und so in der Art war das auch weiter oben von anderen angesprochen worden.

Deine Frage "..Führt der Kernel irgendwelche Rechenoperationen aus? " Aber ja!! Massenhaft! Bis auf die Speicheroperationen rechnet der wie irre!

 

:klimper: Das sind ja überaus grosszügige Schuhangebote von dir! ich hoffe mal für dich, dass du nicht in die Verlegenheit kommen wirst das wahr zu machen

Aber sehr nett ist es doch

 

Ja, so sehe ich das auch

Ja okay, kommt natürlich immer drauf an wie gut man Programm-Code vekorisieren kann.

Ja schon klar, dass das ganze Programm nicht um den Faktor 30 schneller wird. Was ich halt gemeint habe war, dass bis auf ein paar Ausnahmen die AltiVec-Unit von den Programmierern nicht genutzt wird, obwohl es Sinn machen würde.
Und bei einem entsprechenden Compiler wird eben dann optimiert was optimiert werden kann und da steckt auf jeden Fall noch Potential drin.

Na dann steht doch einer AltiVec-Nutzung des Kernels nichts mehr im Wege

EDIT: Was mich gestört hat an deiner Aussage war, dass AltiVec nur in Ausnahmen genutzt werden kann. Es waren vielleicht vor 10 Jahren Ausnahmen, aber heute sind die Ausnahmen Mainstream.

 

Kate, es ist ja nicht so, dass ich solche Angebote Tag täglich mache
Ein Mal im Leben kann man einer schönen Frau doch schöne Schuhe kaufen.

Es müssen ja nicht gleich welche für 2000$ sein

Gruß
Kalle

P.S. Und außerdem, du kannst dich ja auch noch für die Fußmassage entscheiden *lach*
EDIT: Aber was ich verspreche halt ich auch.

 

Schaut am besten, daß Ihr die Fußmassagen-Geschichte Altivec optimiert. Dann geht sie 38,5 mal schneller und Ihr habt viel mehr Zeit um Euch hinterher teuere Schuhe anzugucken. :tongue:

 

Endlich mal eine praktische Anwendung für AltiVec (aka Velocity Engine)!!

 

*lautlach*
AltiVec und Schuhe kaufen okay.
AltiVec und Fußmassage, neeeeee.

Kalle

 

:embar: ..ich nehme es als Kompliment.:klimper:

 

Um diese technische Diskussion zusammenzufassen, so dass diejenigen, die das langweilig finden etwas davon haben: - Es sieht also so aus: Es ist wahrscheinlicher, dass ich von einem grosszügigen, fremden Mensch aus dem Forum wahnsinnig überteuerte Schuhe bekomme, als dass ein G5 PowerBook zum Jahreswechsel erscheint.
Und überdies hat sich hier so ein bischen ein Flirtfaktor eingeschlichen, der von den IBMlern und Freescalern nicht bedacht worden ist...so kann's gehen.