Hier könnt Ihr Prosa und Lyrik, Hasstiraden, Philosophisches, Zweckdienliches, Unsinniges und Sonstiges zum neuen Mac Pro verewigen.

Meines Wissens soll der Haswell ca 7% schneller bei gleichem Takt sein. Eine Leistungssteigerung spürt man ab ca. 15%. Der neue MP wird mit Hilfe der GPU schön gerechnet, aber man kann auch 2 FireGL in einen alten MP10 bauen.

Mir ist in Erinnerung geblieben, daß man sogar erst ab um 1/3 schneller erst wirklich einen Unterschied merkt (wenn man nicht die Zeiten stoppt).

Na ja, eigentlich erst ab etwa 30 %.
Nein, die GPUs haben tatsächlich diese Leistung. Und der RAM-Durchsatz ist auch tatsächlich erheblich höher.
Wer bestreitet das?

Natürlich hat man die volle Geschwindigkeitssteigerung nur mit angepasster Software, das ist schon klar. Daher sollte man darauf achten womit man arbeitet, und ob der Hersteller den neuen Mac Pro unterstützen wird. Sonst lohnt es sich kaum.

Im neuen Macpro ist sicher ein Ivybridge EP Xeon E5 2600 v2 drinnen. Der kommt im Herbst und hat bis zu 12 cores... Ich denke, als Single CPU Maschine hat er sicher das Nachsehen gegen DP Systeme.

Wenn ein Programm nur CPUs nutzt sind sie nur eine teure Dekoration, die die Leistung nicht steigern, also ist es "schön Rechnen".

Ich stecke 2x W9000 und 1x W5000 in den Mac Pro 12 und hab gewonnen? Wenn das doch so einfach wäre!

1866 Quad Channel DD3 Ram ist normal für die CPU Generation..
Jeder Hersteller, der die neuen Xeons verbaut hat die selben Merkmale wie der Macpro(ausser die Grafikkarten), nur das der Macpro halt eine CPU hat...

Die Features sind überhaupt nichts besonderes... es sind dann die aktuellen Intel Komponenten mit 2 FireGL. Keine Apple Magie oder sowas

Spannend und vieleicht auch etwas magisch ist das Design finde ich...

Also im Gegensatz zu lambam bin ich sehr wohl der Meinung, dass der Spruch "kauf Dir doch einen PC" angebracht ist.

Die Leute meckern und nörgeln, der MP/13 kann dies nicht und das nicht, ist sowieso viel zu lahm, sieht aus wie *beliebige Zylinderform hier einsetzen* und außerdem ist er klein und kann deswegen nicht Pro sein und so weiter und so fort.

Wenn man an so einem Punkt ist und fest davon überzeugt ist, dass Apple einem künftig nicht die gewünschte Hardware bieten wird, ja zum Teufel noch mal, dann kauf Dir halt einen PC! Alles andere ist sonst nur noch nörgeln auf Profi-Niveau und bringt einen weder beruflich noch emotional weiter.

Ich kapier das echt nicht. Warum hat eigentlich keiner der Kritiker, die ja vollkommen sicher zu sein scheinen, dass der MP/13 nichts für sie ist, die Eier zu sagen: "Ok, der ist nichts für mich, ich such mir was anderes, damit ich auch weiter meine Brötchen verdienen kann. Tschüss, macht's gut und danke für den Fisch." Nein, stattdessen drehen sie sich hier im Kreis und kommen immer und immer wieder mit den selben halbgaren Argumenten, warum sie den MP/13 scheiße finden.

Ich mache nicht noch eine Runde mit. Melde mich hier erst wieder, wenn's neues zum MP/13 gibt.

Liegt vielleicht auch daran, dass die, die hier so frech herummeckern ohne jemals selbst einen Computer gestaltet zu haben, nen Haufen Kohle in Software investiert haben, bei dem der Gewinn noch herauszuholen ist.
Vielleicht trauern auch die, die so unverschämt herumheulen obwohl andere ja besser wissen was sie benötigen als sie selbst, dem Arbeiten mit dem Mac nach, den sie zwar liebgewonnen haben, sich aber nun trennen müssen.

Außerdem ist die Argumentation "Dann geh doch nach drüben…" alt und langweilig. Ein Totschlagargument halt. Da sich noch weiter unterhalten zu wollen ist sinnlos, der Gegenseite sind die Argumente ausgegangen, sie weiß es nur noch nicht.

Mein Schreibtisch gehört mir ... und nicht dem Computerzubehör. Laufwerke usw. gehören IN den Computer oder wie beim aktuellen Modell zumindest daraufgestellt. Ich verstehe echt nicht, warum viele Leute es schick finden, möglichst viel Computerzubehör, Kabel und Netzteile rumliegen zu haben

Und es wird echt anstrengend, dem Besuch immer sagen zu müssen: "Nein, der Müll gehört NICHT da hinein!"

Was glaubst Du wohl, was meine Worte „die volle Geschwindigkeitssteigerung nur mit angepasster Software“ bedeuten? Verstehst Du einfache Texte nicht?
Das finde ich nun total egal! Ein Pro-Computer muss gut funktionieren, mehr nicht! Aussehen muss er nicht (außer vielleicht als Dekoration in Prospekten oder Filmaufnahmen).

Nach meiner bisherigen Erfahrung, bedeutet das leider erstmal jahrelanges Warten, bis Adobe, Maxon, Autodesk und Konsorten ihren A**** hochkriegen und ihre Software optimieren (siehe Altivec, siehe SMP, siehe OSX Umstieg, siehe 64 Bit).

Ja, nur, dass Adobe in diesem Fall seine Software bereits angepasst hat. Andere werden sicher dieses Mal schnell folgen. Denn dafür ist die Leistung einfach zu hoch.

Ich persönlich verwende Adobe-Software, und die ist weitgehend bereits angepasst. Apples Software (Final Cut X) ebenfalls, MODO (3D-Rendering, ziehe ich C4D vor, weil die Ergebnisse einfach besser aussehen) gehört jetzt zu The Foundry (). Und die sind schwer begeistert vom Mac Pro (siehe weiter oben: ). MARI ist bereits angepasst, MODO wird sicher schnell nachziehen. Damit habe ich alle Software zusammen, welche die hohe Geschwindigkeit des neuen Mac Pro ausnutzen kann. Und darauf freue ich mich schon jetzt!

Ich weiß das Adobe AE zum rendern CUDA unterstützt, aber zu OpenCL Rendern konnte ich nichts finden. Kann CC scohn mit OpenCL rendern?

Da muss ich wohl was verpasst haben, momentan heisst es beim After Effects zB: “...Aus diesem Grund verarbeitet After Effects Bildinformationen noch schneller mithilfe mehrerer Prozessoren und verbesserter Unterstützung von NVIDIA-Grafikkarten...“
Auf Deutsch heisst das: Der raytraced 3D Renderer ist nach wie vor nur mit CUDA fähigen GraKas verwendbar.

The Foundry ist eine der wenigen Firmen, denen ich eine schnelle Anpassung zutraue. Gut für Nuke User - mir persönlich hilfts leider nicht viel, da ich weniger Compositing als Animation mache und da ist AE leider nach wie vor ziemlich alternativlos.

Zitat Phaseone über Capture one:
"Sie können Ihre Arbeitszeit verringern, indem Sie die Grafikkarte durch das sogenannte OpenCL Interface beschleunigen. Die Idee dahinter ist es, die Verarbeitungsleistung der Grafik-Hardware vollständig zu nutzen, um so die Anwendung zu beschleunigen.

In Capture One 7 wird die Grafikkarte nicht nur genutzt, um die Verarbeitung am Bildschirm zu beschleunigen, sondern auch wenn Sie Bilder zu Dateien verarbeiten.

Die Schnelligkeit mit OpenCL bietet Ihnen einen riesigen Vorteil. Wenn Sie eine der neuesten Grafikkarten in einem Mac Pro Computer nutzen, können Sie eine 80 Megapixel RAW Datei in weniger als 2 Sekunden verarbeiten."

AFAIK ist Premiere Pro CC die einzige Software von Adobe die was mit OpenCL anfangen kann.

Ja klasse, für Echtzeitplayback ohne vorrendern, aber das kann auch schon Premiere 5.5 mit Nvidia Karten und Cuda.

Mari scheint es bisher noch nicht mal für Mac zu geben oder liege ich da falsch?

Da ich bisher mit vorhandener Software arbeite, sieht bei mir das ganze mit OpenCL nicht so toll aus.

Tzunami





Ein paar Effekte werden wohl auch beschleunigt...

Wenn man sich den Softwaremarkt so anschaut, muss man sich schon sehr über Apples Entscheidung wundern, auf AMD zu setzen.

Ich habe Programme die bei mir OpenCL nutzen: smallluxGPU und OpenCL Benchmark V 2.0

Alle anderen verwenden bisher höchstens CUDA

MARI wurde ja auf einem Mac vorgeführt, das Video ist weiter oben verlinkt.

Zu Adobes OpenCL-Unterstützung:
Tja, ich weiß das leider auch nicht so genau.

Wie auch immer: CUDA unterstützt nur Nvidia. Wenn alle Welt nur auf CUDA setzen würde, wäre ATI schnell weg vom Fenster und wir Benutzer hätten dasselbe Problem wie jetzt mit Photoshop: Es gäbe keine Alternativen mehr. Und das wollen wir doch sicher nicht, oder?

OpenGL unterstützt Grafikkarten unterschiedlicher Hersteller, und OpenCL kann nicht nur GPUs, sondern auch CPUs mit Rechenaufgaben beschicken, sorgt also für eine bessere Nutzbarkeit. Deswegen sollte man (und vor allem wir Kunden) OpenCL unterstützen. Wir haben auf Dauer mehr davon!

Aber:
Es scheint ja so zu sein, dass OpenCL – zumindest bisher – schlechter lief als CUDA (warum auch immer). Wenn dem noch immer so sein sollte, sollten sich alle Hersteller zusammensetzen und OpenCL gut machen. Das wäre für uns Kunden besser, als einen Hersteller mit dem properitären CUDA zum alternativlosen Herrscher der Szene zu machen.

Es ist nicht nur nVidia sondern auch viele Firmen drumherum. Dazu kann man CUDA für x86 CPUs compilieren, die Compiler sind momentan kommerziell, aber es gibt auch ein FOSS Projekt - Ocelot. Damit wird sich dann CUDA auf AMD, x86 und nVidia compilieren lassen.
Ich hoffe auf OpenMP 4.0, dann ist das Thema OpenCL endlich erledigt.
Schlechtere Compiler, sehr viel schlechtere Treiber (wir haben AMD GPGPUs - ein Graus), fast keine Libraries und Entwicklertools. nVidia und Intel liefern für ihre Beschleunigerkarten umfangreiche Werkzeugsätze und Bibliotheken mit - AMD nicht. AMDs Software ist im Vergleich zu Software der beiden anderen einfach nur Schrott. CUDA hat deutlich mehr Features als OpenCL, so daß man viele Dinge mit OpenCL gar nicht machen kann, die mit CUDA möglich sind. Und ganz wesentlich man ist nicht auf C festgelegt, es gibt auch andere Sprachen für CUDA.

Bis vor zwei Jahren mußte man auf AMD Karten unbedingt das Stream API nutzen, um die Hardware ausnutzen zu können, weil mit OpenCL bzw. der AMD OpenCL Compiler das nicht möglich war.

Intel setzt ohnehin konsequent auf OpenMP für XeonPhi, das ist sehr viel flexibler als OpenCL oder CUDA, und läßt sich problemlos für CPUs compilieren und benutzen. Es stammt von normalen CPUs.
Weg damit! Es war, ist und wird immer schlecht bleiben. Intel setzt auf OpenMP. Sobald OpenMP GPGPUs unterstützt, man arbeitet daran, sollte man es als Standard fürs GPGPU Computing festschreiben. In normalen CPU Compilern wird es seit Jahren in den älteren Versionen unterstützt. Es gibt massenweise Bibliotheken, die auf OpenMP setzen, es gibt viele OpenMP-Werkzeuge, etc. pp.

Wie auch immer. Dann muss das eben in Ordnung gebracht werden. Das ist allemal besser als auf einen properitären Herstellerstandard zu setzen.

Mich wundert es das viele Open Source Anwendungen OpenCL imlementieren, NUR eben nicht unter OSX. Das beste Beispiel sit dabei Handbrake. Es gibt für Linux und Win eine OpenCL beta, aber eben nicht für OSX. Warum, ist die OpenCL implementierung bei OSX so müllig?

Ich erinnere mich da an die Flashbeschleunigung zurück, die es aus mangelder Ünterstützung von Apple nur für die nForce Chipsätze gab.

Ganz ehrlich, wenn es um etablierung von Standards geht, ist Apple das letzte. Wenn ich daran denke wie sie ihren eigenen Browser absägen indem die aktuelle Version immer nur mit dem neusten OS läuft. So wird das einfach nichts. Oder OpenGL, da turnt Apple auch hinterher, den OpenGL 4.0 gibt es schon seit 2010, 4.3 ist aktuell.

Mich wundert es nicht. Bisher hat Apple ja immer die schrottigsten Grafikkarten verbaut. Wozu diese für OpenCL nutzen?

Das ist das wohl überaschendste am neuen Mac Pro: die Idee zeitgenössische Grafikkarten zu verbauen. Jetzt lohnt es sich auch für Handbrake.

Also ich habe eine 680GTX in meiner Kiste. Das ist ja das Tolle an PCIe, man kann jeder Zeit eine moderne Grafikkarten nachrüsten. Die Karten im nMP sind zwar jetzt noch toll, aber wie sieht es aus, wenn der nMP verfügbar ist, oder 1-2 Jahre später?

Hinzu kommt, das das Maximum an nMP gezeigt wurde. Ich wette, Apple wird die kleinen nMPs mit Gurkenkarten begücken, so wie sie es immer getan haben.

Vielleicht ist ja OpenCL in Mavericks gut implementiert.

Nur eine minimale Verbesserung von ca. 1-2% laut Messungen.

Hmm … wenn Apple aber voll auf OpenCL setzt, und sogar einen ganzen Computer nur dafür baut, dann muss es natürlich auch vernünftig implementiert sein. Ansonsten ergibt es keinen Sinn.

Es ist eine BETA

Das wurde bisher auch jedes mal gesagt, wenn es um Leistung ging (OpenGL,Finder...), und am Ende war die Leistung zwischen Beta und GM fast immer nahezu gleich.

Der schöne MacPro.
Aber für den Alten gibts ja auch noch Verwendung. Man muss nur die Seite durch ein Lochblech ersetzen:

Bart S.

Das ist (war) aber ein PowerMac G5.

Großartig, Bart S.! Oben und unten hat man dann auch jeweils ein Tablett.
Man braucht nur noch ein paar iKitchen Gloves.

Das Ding ist noch nicht mal auf dem Markt und hier wurde es schon verteufelt, auf dem Scheiterhaufen verbrannt oder als Hochverrat an die Pro User abgestempelt.
Sollte man nicht über etwas urteilen nachdem man es ausprobiert hat?

Wer hätte jemals geglaubt, ein einziges Tochscreen Mobiltelefon könnte den Finnischen Branchenprimus über Nacht demontieren?

Ganz so extrem wird es zwar beim Mac Pro nicht sein aber warten wir es mal ab. Ich lasse mich gerne überraschen und werde mir den Mac Pro nach dem ersten Run in einem Store genauer unter die Lupe nehmen.

Mia
Das sind hier nur ein paar, die Immergleichen. Ich gehöre zu den Befürwortern, habe es dann, wie aktuell sonorman, irgendwann aufgegeben.
Das drehte sich im Kreis.
(Das mit dem Retina-Book war kein Ulk. Es ist mit tatsächlich ins Wasser gefallen. Ich warte bis Herbst mit dem Neukauf.)

wie gesagt der neue Macpro bringt aktuelle Server Hardware , wie jeder andere Hersteller auch.
Das Custom Design der PCIe Gpus und die Limitierung auf eine Single Prozessor Maschine erscheint etwas befremdlich und das Fehlen der Pcie Slots für andere Erweiterungen ausser den Pcie SSds und den Pcie Grakas scheint ein mutiger Schritt zu sein...

Ich freue mich darauf und bin gespannt, wie der neue MP sich schlagen wird.
Eins ist klar... Er wird leider nicht mehr so schnell sein wie die Vorgänger dieser Preisklasse...
Dennoch es wird die kleinste Workstation ever... und viele Grafiker usw glücklch machen...

Die CPUs im Mac Pro sind sauteuer. Die GPUs sind erheblich günstiger und trotzdem sehr viel leistungsfähiger als die CPUs. Daher ist die Überlegung, möglichst viel mit den GPUs zu machen, grundsätzlich richtig.

Es hängt jetzt letztlich alles von der Implementierung von OpenCL ab, wenn ich das richtig sehe. Wenn sie gut ist, werden die Firmen das auch unterstützen.

Jetzt mal Spaß bei Seite.
Ob OpenCL gut oder schlecht wird, wird die FIrmen nicht die Bohne interessieren. Ihre Produkte auf OpenCL anzupassen bedeutet Arbeitsaufwand und den machen sich Firmen nur, wenn sie sich dadurch mehr Einnahmen versprechen. Das beste Beispiel wäre da Adobe, die mehrere Jahre keine/oder schlechte MP unterstützung bei PS hatten.Wo PS Jahre lang nur einen Carbon App war, bis sie endlich nei geschrieben wurde. Selbst Apple wollte damals keine Ressourcen in die Entwicklung eines Cocoa Finders investieren.

Auch wenn ich es mir wünschen würde, OpenCL kommt auf dem Mac einfach nicht richtig in Fahrt. Nicht einmal für Handbrake scheint eine Mac OpenCL-Version in der Entwicklung zu sein (nur für Linux und Windows). OpenCL gurkt, auf dem Mac, einfach nur so vor sich hin. Ich würde es gerne mal einsetzen können, anstatt mir nur die OpenCL Galaxy demo reinzuziehen.

Das Apple auf die GPU setzt ist zwar eine toole Sache, aber wenn die Softwarefirmen nicht mitspielen, könnte das schnell ein griff ins Klo werden. Auch wenn sie mitspielen wird der nMP wohl nicht so viel davon haben, denn die werden sich bestimmt auch etwas Zeit bei der Implementierung lassen und bis dahin steht villeicht schon der nächste MP in den Startlöchern, mit neuen Ideen oder Ansätzen auf die sich keiner vorbereiten konnte.

Der Pro ist tot - es lebe der Pro

Ich freu mich auf das kleine runde Ding.





Hör auf ihr zu folgen, sie antwortet Dir nicht.

Hier wieder etwas ernüchterndes
Der ganze test hier:

Apple wird mit Sicherheit darauf verzichten, seine Signitureapps an die neue Hardware anzugleichen, bevor selbige erscheint.

Ein Fortune500-Unternehemn wird gerne darauf verzichten, relativ "billig" einen Woweffect durch die Presse zu jagen.

Wo wir gerade bei Grand Central sind, gibt es eine List, wo Programme drin stehen, die Grand Central nutzen?

Mir fallen spontan nur System Apps ein, aber sonst habe ich seit dem nicht wirklich was davon mitbekommen das jetzt Programme das nutzen.

Da die unterliegenden Frameworks Grand Central nutzen, muss nicht jedes Programm es explizit tun. Auch setzt sich in Apples Cocoa API das sog. "Block Programming" immer mehr durch und solche Blocks sind auch für die Grand Central Execution Queue geeignet - ohne dass der Entwickler etwas dazu tun muss.

Im Endeffekt ist Grand Central eine schönere Verpackung für das klassische Multithreading die dem Entwickler den Overhead abnimmt, selbst Threads zu erzeugen und diese dann zu managen.
Was für keine Code-Stücke, die zwar parallelisierbar wären bisher aber nicht wurden, weil der Entwickler den Aufwand gescheut hat, besonders vorteilhaft ist. Man kann nämlich mit Grand Central recht Einfach inline im Code mit wenigen Änderungen solche Dinge parallelisieren. Das ist aber eigentlich trivial und wird wohl kaum von einem Entwickler an die große Glocke gehängt ala "Unsere App nutzt jetzt Grand Central...". Insofern denke ich, dass viele Apps dort wo es etwas bringt Grand Central nutzen, ohne dass Du etwas davon lesen wirst.

Viele Apps benutzen auch Apples APIs, welche wiederum Grand Central nutzen. Dann weiß der Programmierer nicht mal unbedingt, dass seine Software das überhaupt nutzt.

Naja, so ganz so geht das auch nicht. Der Entwickler muss die Aufgaben ersteinmal selbst so zerlegen, daß sie parallelisierbar sind. I.d.R kann einem das kein Framework abnehmen. Auf den "passiert automatisch von alleine"-Effekt würde ich da also nicht bauen.

Natürlich gibt es genug Funktionen, die sich ohne dass der Entwickler etwas tun muss auf Ebene des Cocoa Frameworks mit Grand Central beschleunigen lassen.
z.B. Massenoperationen auf Arrays (makeObjectsPerformSelector), Sortieroperationen, Filteroperation oder auch jede Operation die auf größeren Daten geschehen wie die Suche in großen Strings oder auch Image Manipulationen (mit den Core Graphics Filter, wenn das nicht die Graka erledigen kann).
Das ist dann aus Entwicklersicht nur ein Aufruf einer Funktion die dann intern die Aufgabe parallelisiert.

Genau für solche kleinen Dinge ist Grand Central genau gedacht und weniger für den 10 Minuten Render Thread. Solche Dinge werden in der Tat i.d.R. von der Anwendung selbst mit klassischen Threads erledigt - ohne Grand Central.

Das stimmt so nicht. Wenn der Programmierer z.B. auf Core Image zugreift um einen Filter auf sein Bild oder Video anzuwenden, dann braucht er nichts zu zerlegen. Die Core-Image-APIs selbst ist bereits parallelisiert. Das Gleiche gilt auch für andere Core Services.

Working with OpenCL:

Vielleicht hilft's ja.