ist denn Cuda schon in früheren Version von Mac OS X implementiert ? Naja die Karte kommt im Mai, aber nach dem letzten Change Log gibt es wohl auch nicht mehr soviel zu tun an 10.5.7

jo mei,
150 W ist kein "Stromverbrauch" sondern ene Leistung. Wann werden wir das je lernen? Da gib es wohl keine Hoffnung..... :'(

CUDA ist nicht in MacOSX integriert. Du mußt Dir CUDA-Software von der Nvidia-homepage herunterladen. Geht auch mit älteren Karten...

Seit 2 Monaten..

bald ist es soweit 10.5.7!
Nein echt, es ist quasi schon da: 10.5.7!

Man schon wieder ein Hinweis, Leute, 10.5.7!!!

Und dann hat sich wieder ein Monat nix getan und nun geht das schon wieder los..

[klugscheiss]Strom wird nicht verbraucht, nur umgewandelt. [/klugscheiss]

O je - wird nicht alles immer nur umgewandelt? So gesehen...

und 10.5.7 hat noch mehr Überraschungen an Board !

soso ? welche denn ?

root86org weiss vieles, glaubt er. so auch das hier ... lol:

Gäähhn, auf den OSX86 Maschinen laufen schon die 4870X2-Karten.
Manchmal ist es sogar ein Vorteil Mac OS X aufm PC-Maschinchen zu fahren

markus2 da gibt es Treiber von ATI für, die Crossfire unterstützen ?

Offiziell keine, aber auf 10.5.7 Beta Basis leicht verbesserte der OSX86 Gemeinde

Dienstag. Morgen ist Dienstag. Dann kommt 10.5.7. Halleluja!

Ab 10.5.17 läuft Leo dann rund

@ sonnendeck: Ab Snow-Leopard gibt es Grand Central, das kann Binärcode von beliebigen(!) Programmen on the fly für diese 192 Prozessoren übersetzen und diese damit fluten. Der Rechner wird dann richtig rennen! Und erst Recht, wenn die Programme speziell dafür geschrieben und optimiert wurden!
Und wo steht Microsoft?

Toll .. 4 Monate nach 10.5.7 fiebern alle 10.5.8 entgegen und auch dann werden 99% der User keinen Unterschied zur Vorversion feststellen .... Zumindest keinen der auch wirklich da ist.

Gerhard Uhlhorn:

Soso. Bis jetzt waren irgendwelche CPU-Emulatoren prinzipbedingt ziemlich schnarchlahme Krücken.

Seit wann sind denn die NVIDIA-und AMD-GPUs binär-kompatibel zu PPC,x86,Sun,ARM und anderem beliebigen Binärcodes von beliebigen Programmen?

Wie genau sieht das dann eigentlich aus, wenn das Festplattendienstprogramm auf der Grafikkarte statt mit der Core 2 Duo-CPU rödelt? Werden die Sektoren dann bunter?

Muß ich meinen iPod zum syncen mit iTunes dann an die Grafikkarte statt an den USB-Port stecken?

...und garantiert heult dann alles wieder rum, weil die Grafikkarte ja nur 128/256/512 MB RAM hat. Dabei stecken im super teuren Mac Pro ja schicke 12 GB RAM, aber nö, die sind jetzt unnütz...

Ich weiß zwar nicht genau wie Grand Central funktioniert, aber ich könnte mir vorstellen, das er meint, das man damit die ganzen Rechnungen auf die Grafikhardware auslagern kann, ohne die Grafikkarte direkt ansteuern zu müssen?
Mit meinen mageren Informatikkentnissen könnte ich mir vorstellen, das es durchaus möglich währe, aber kann vll einer begründen, wenn es nicht möglich währe warum?

MfG

Grand Central ist quasi SSE/Altivec auf der GPU.

Die GPU ist eine primitive CPU, die SSE/Altivec-ähnliche Operationen massiv parallel ausführen kann.

Alles drum herum muß normalerweise "von Hand" organisiert werden. (Daten rein in die Grafikkarte, Rechnenregeln in die GPU, rechnen lassen, Daten wieder raus).

Die GPU selber kann nicht auf den Hauptspeicher des Computers oder auf Peripherie (USB, Firewire, SATA usw.) zugreifen.

Die GPU sieht nur einen Bruchteil des Video-RAMs.

Die Rohdaten in das Format der GPU zu überführen ist Aufgabe der CPU.

Das Programm der CPU bleibt logischerweise bei der CPU.

Mac OS X läuft nach wie vor auf der CPU, die GPU ist also "nur" eine ausgelagerte, massiv parallele SSE/Altivec-Einheit.

Also nix von wegen "kann Binärcode von beliebigen(!) Programmen on the fly für diese 192 Prozessoren übersetzen"

Der Punkt ist, dass Grand Central den Code für den Hauptprozessor so übersetzen kann wie es Rosetta mit PPC-Code für den Intel macht, oder wie es früher mit 68k-Code für PPC gemacht wurde. Das ist zwar nicht das Optimum an Effizienz, dürfte aber doch eine erhebliche Geschwindigkeitssteigerung bringen! Aber noch mehr bringt natürlich CUDA-Code!

Dass bei der Quadro FX 4800 keine DisplayPort-Buchse verbaut ist, lässt für das 30 Zoll-Display kein nahes Update in dieser Richtung erwarten.

Gerhard Uhlhorn:

Und welchen Sinn macht es, zum Beispiel das Festplattendienstprogramm auf der Grafikkarte laufen zu lassen?

Knork: Und welchen Sinn macht es das Festplattendienstprogramm davon auszuschließen?
Wenn der Prozessor schon auf Vollast läuft, dann kann auch ein Festplattendienstprogramm davon profitieren. Es wird ja ohnehin nur dann auf die Grafikprozessoren übertragen wenn die Hauptprozessoren keine Kapazität mehr frei haben, sonst natürlich nicht.

Weil

1.) Die wesentlichen Aufgaben des Festplattendienstprogramms nicht parallelisierbar sind.

Wer ist bei nicht parallelisierbaren Aufgaben schneller: Die CPU oder die GPU?

2.) Das Festplattendienstprogramm im Wesentlichen Daten von/zur Festplatte schaufelt.

Wie genau schaufelt die GPU Daten von/zur Festplatte, und wo landen die von Festplatte geladenen Daten? Im RAM oder im Video-RAM?

Gerhard Uhlhorn,
Knork:

Grand Central - der Heilige Gral?
Steven P. Jobs and the Holy Grail

Man sollte hier nicht zuviel und schon gar keine Wunder erwarten -- erst recht nicht von Apple, das bzgl. Grundlagenforschung in Sachen "Ungelöste Probleme der gesamten Computer-Industrie" bisher eigentlich eher unauffällig gewesen ist.

Kann ja sein, dass Apple da einige technische Möglichkeiten bereitstellt, die das bisher Unmögliche möglich machen könnten, aber auch für Apple ist das alles eher Neuland. Und programmiert sein will es auch. Und zwar für jede einzelne Anwendung, die man sich so vorstellt. Und das braucht Zeit. Denn so gut wie alle am Markt befindlichen Anwendungen sind auf Parallelverarbeitung so gut wie nicht eingestellt bzw. auf Single-Prozessoren ausgelegt. Inkl. der gängigen Programmiersprachen. Das Problem ist ein wenig größer und umfangreicher als es sich so mancher in seinen Träumen zurechtfügt.

Mit Grand Central und OpenCL werden zwar neue Grundlagen gelegt. Doch der Weg, der gegangen werden muss, ist für die gesamte Computerindustrie neu und ungewohntes Terrain (auch für Apple). Und deshalb können Grand Central und OpenCL nur ein Anfang sein. Ein Anfang auf einer möglicherweise sehr langen und schwierigen Straße, wenn es um intelligente Parallelverarbeitung und -programmierung geht.

och menno, verrat doch net alles...


Für Gerhard Uhlhorn:

Kleine Auflösung für Dich:

Nur die Programmteile, die in OpenCL geschrieben sind, KÖNNEN via Grand Central zur Laufzeit auf mehrere Prozessoren (inkl. GPUs) verteilt werden.

Das "normale" Programm, das nach wie vor als Carbon- oder Cocoa-Applikation in Objective C geschrieben ist, läuft ausschließlich auf der PPC/x86-CPU.

Nochmal: Die Laufzeit-Übersetzung erfolgt nur für die OpenCL-Anteile, sprich: für vom Anwendungsprogrammierer explizit als parallelisierbar und in OpenCL gestaltete Berechnungs-Tasks.

Sonst nix.

Das Festplattendienstprogramm läuft also nach wie vor nur auf der CPU...

Was via Grand Central/OpenCL/CUDA auf die Grafikkarte bzw. deren Shader ausgelagert wird, hängt entscheidend von der Programmierung der Anwender-Programme ab. Das können und werden mit Sicherheit nur ausgesuchte Berechnungsprozesse sein, welche aufgrund ihrer Arithmetik von den ALUs der Grafikkarte schneller berechnet werden könnten.

Alles, was nicht in dieses Arithmetik-Schema passt, wird bestimmt nicht in Richtung GPU ausgelagert werden, sondern weiterhin schön brav von der CPU bzw. ihren Cores berechnet werden.

Nur das würde Sinn ergeben. Und die GPUs haben eben bestimmte Stärken, die sie auf diese Weise zum Einsatz bringen könnten, z.B. das Berechnen bzw. parallele Verarbeiten von Fließkommazahlen, und die CPU wiederum hat andere Stärken, nämlich die kooperativen und administrativen.

Diese unterschiedlichen Stärken und Schwächen von CPU und GPU geschickt aufzuteilen und schon bei der Programmierung des Betriebssystems bzw. der Anwenderprogramme zu berücksichtigen, das ist die Herausforderung der Zukunft. Und das zu etablieren, das dauert.

Man (bzw. interessierte Entwickler tun das) sieht ja jetzt schon, wie lange es dauert, bestehende Programme für Multi-Prozessor-Nutzung fit zu machen (und die existieren ja schon eine Weile am Markt!) bzw. dort bestehende Schalter einzubauen, diese Multi-CPUs oder Multi-Cores zu erkennen und für sich zu nutzen. Doch damit ist es meist nicht getan.

Bzgl. Grand Central und OpenCL kommt da ganz bestimmt noch eine ganze Latte mehr an Herausforderungen auf die Programmierer und Anwendungs-Hersteller zu: Vieles muss teilweise ganz neu gedacht und umgesetzt werden, und von so manchem kniffligen Problem ist eine Lösung noch in weiter Ferne. U.a. auch, weil die bestehenden Programmiersprachen dafür nicht oder schlecht gerüstet sind. Deshalb ja auch die Notwendigkeit von OpenCL.

Knork:

Das sehe ich auch so. Ergo wird in der ersten Zeit oder auch für länger erstmal nur ein kleiner Teil an Programmen (oder gar nur Progrämmchen?) bzw. ausgesuchte Bestandteile von MacOSX davon profitieren können. Weil's sicher nur schrittweise zu machen ist. Und sicher nicht immer sinnhaft. Es werden immer noch zahlreiche bestimmte Rechenoperationen bzw. Programmteile und Programm-Bibliotheken übrigbleiben, die besser und klassisch von der CPU bzw. ihren Cores ver- und bearbeitet werden als von den GPUs und ihren Cores bzw. ALUs, und die werden dann eben NICHT in OpenCL geschrieben sein, sondern in ihrer bisher bekannten Programmiersprache.

@quarks

Ich fürchte Du hast recht. Apple hat den Übergang auf Displayport ziemlich versaut, denn eigentlich sollten in der Übergangszeit beide Standards voll unterstützt werden und nicht nur halbherzige bis völlig sinnfreie Lösungen angeboten werden. Die anderen Grafikkarten bieten nur jeweils einen DVI und einen Displayport Anschluss an, so dass man nicht einmal 2 gleiche Monitore generell beim 24er CD / oder ohne Adapter betreiben kann und jetzt hat man bei der HighEnd Karte zwar 2 DVI Anschlüsse aber keine DisplayPortanschlüsse.

Ist Displayport schon am Ende bevor es überhaupt gestartet ist oder nur eine Lösung für den Consumermarkt?

Eigentlich sollte man erwarten können, das ausnahmslos jede neue Grafikkarte für den MacPro über 2 DVI ! und ! über 2 DisplayPortanschlüsse verfügen sollte, so das man wahlweise 2 Monitore auf die alte oder auf die neue Weise aber auf alle Fälle mit demselben Verbindungsstandard ansteuern kann.

Und diese ich möchte schon sagen hirnrissige Steckerpolitik findet seinen Höhepunkt beim MacMini, wo man wohl aus Rücksicht auf die schlechte Lösung beim MacPro lieber einen Displayport mit einem Mini DVI Stecker + passendem DVI Adapter kombiniert, anstatt 2 DisplayPort Anschlüsse zu verbauen und eben einen passenden Displayport auf DVI Adapter beilegt.

Diese schlechteste aller möglichen Lösungen werde ich wohl nie verstehen können und es dürfte auch wenig bis keine Argumente geben, die Apples Entscheidung in irgendeiner Weise nachvollziehbar machen kann, außer das sie noch ein paar Peanuts mit Adapter verdienen oder schlimmer noch ihre Kunden bewußt verärgern wollen.

Wenn Apple so weiter macht, kann DisplayPort eigentlich nur floppen.

nur um das mal hervorzuheben,

Mac OS X 10.5.6 erschien am 15. Dezember 2008. Ich glaube solange war der Zeitraum bis zum nächsten update noch nie.

@ MetallSnake

Ehm, nur mal so aus Neugierde. In was wird der elektrische Strom den umgewandelt?

Elektrischer Strom ist eine gerichtete Bewegung von Ladung. In was soll sich den ein Elektron umwandeln?