News Xeon Phi „Knights Landing“ mit bis zu 72 Kernen

[Skysnake]

Setz mal ein "fast" vor das "stink normale CPU", dann passts. Ein paar für heutige Verhältnisse unschöne Sachen sind schon drin, wobei KNL da wohl das meiste fixen sollte.

 

[Ratzer007]

Mich würde interessieren was das teil kostet

 

[Nai]

So mal als Laie: Kann Xeon Phi etwas besser, genauer, schneller rechnen als Tesla? Was ist der Vorteil von einer CPU Lösung gegenüber einer GPU?

Mal etwas ausführlicher, inhaltliche Kritik oder Fragen nach ausführlicheren Erklärungen sind willkommen. Es war etwas problematisch das ganze inhaltlich "aufzurollen", da alles mit allem irgendwie zusammenhängt. Ich hoffe es ist mir dennoch halbwegs gut gelungen:

-Höherer Prallelismus, breiteres/anderes Hardware-Multithreading: Moderne GPUs benötigen je nach Anwendungsfall wegen ihrem Hardware-Multithreading mehrere 1000 Threads um gut ausgelastet zu sein (Titan kann maximal 29 000 Threads gleichzeitig bearbeiten, bei modernen AMD-Karten sind es 60k+ ), während Phi wenige 100 benötigt (Phi kann denke ich nur bis zu 300 Threads gleichzeitig bearbeiten). In den meisten Anwendungsgebieten ist der Parallelismus nicht aus dem Grund schädlich, weil man das Problem nicht genügend parallelisieren könnte, sondern aus anderen Gründen:
So benötigt man auf einer GPU wesentlich mehr Speicherplatz für die temporären Zwischenergebnisse aller Threads als auf einem PHI. Passt der Workingset der Zwischenergebnisse eines jeden Threads (auch die automatischen Variablen genannt) nicht mehr in die Register, müssen sie in in die Caches und den DRAM ausgelagert werden, was wiederum brutal Performance kostet. Dies wird als Register-Spilling bezeichnet. So kann man auf einer Titan beispielhaft schon mit Performanceeinbussen rechnen, wenn ein Thread mehr als 31 Zwischenergebnisse gleichzeitig zwischenspeichern muss. Des Weiteren führen mehr Threads unabhängig von Registerspilling auch zu chaotischeren globalen Speicherzugriffen (global = sämtlicher Speicher was sich alle Threads der GPU teilen wie Texturen, Vertexdaten, Hierarische Datenstrukturen), was wiederum der Cache-Effizienz schadet und brutal DRAM-Bandbreite kostet. Erschwerend kommt hinzu dass die GPU nur einen sehr kleinen L2-Cache besitzt (1.5 MB beim Titan), während der PHI einen sehr großen L2-Cache besitzt (Kernzahl* 2MB). Dadurch kann ein Algorithmus mit einem großen Working-Set für automatische und globale Variablen nicht mehr effizient auf einer GPU arbeiten. Meist kann man das zwar hinfriggeln, dass es irgendwie doch passabel oder eventuell sogar gut auf einer GPU funktioniert, was aber sehr viel Arbeit ist.
Allerdings ist diese Art des Hardware-Multithreading der GPU auch fallabhängig von Vorteil. Denn der Grund dafür, dass man ein Hardware-Multithreading einbaut ist immer der, dass man dadurch Latenzen besser überbrücken kann und die unterschiedlichen (Rechen-)Ressourcen besser auslasten kann. Dies kann eine GPU wegen dem breiteren Multithreading dementsprechend auch besser als ein Xeon-Phi.


-SIMD: Ein Warp ist eine Gruppe von N Threads auf der GPU (N = 32 bei NVIDIA, 64 bei AMD). Eine GPU führt jeden Takt jeweils die nächste Instruktion eines Warps aus, wodurch ein und der selbe Befehl jeweils auf den unterschiedlichen Daten eines jeden Warpthreads ausgeführt wird (Single Instruction Multiple Data). Wollen mehrere Threads eines Warps wegen einem Sprungbefehl nicht an einem Befehl teilnehmen, so bleiben in diesem Fall die entsprechenden Rechenkerne unbenutzt und es geht Rechenleistung verloren. Dadurch reagieren GPUs sehr empfindlich auf Algorithmen mit chaotischen Sprungbefehlen. In den meisten Fällen kann man zwar die Sprungbefehle GPU-freundlich optimieren, was allerdings wiederum ein großes Gefriggel ist. Xeon-Phi besitzt ebenfalls SIMD-Instruktionen (eine Instruktion auf 16 SP-Werte gleichzeitig), jedoch beziehen sie sich auf die Daten eines einzelnen Threads. Hier muss man zwar den Quelltext auch etwas umgestalten, dass der Compiler diese SIMD-Instruktionen verwenden kann und Sprungbefehle können sich ebenfalls per Active-Mask, welche beschreibt welche der Daten überhaupt am SIMD-Befehl teilnehmen, negativ auf die Performance auswirken, aber afaik fallen die nachteiligen Auswirkungen von Sprungbefehlen auf die Performance wesentlich geringer als bei GPUs aus.


-Shared Memory: GPUs haben einen kleinen Scratch-Pad-Speicher auf dem DIE (ähnlich zu dem eDRAM auf den Konsolen). Diesen kann man nach belieben befüllen und auslesen, und dadurch die zu kleinen Caches etwas kompensieren. Allerdings ist es in den meisten Fällen ein großes Gefriggel den zu verwenden.

-Besondere Caches auf der GPU: GPUs haben besondere Read-Only-Caches (Texture-Cache, Konstanten-Cache), deren dazugehörige Daten während der gesamten Programmausführung nicht verändern dürfen. Diese Caches muss man explizit und "richtig" verwenden, was einen Mehraufwand bei der Programmierung bedeutet, jedoch aus Performancegründen wesentlich ist. Gleichzeitig muss man dafür sorgen, dass sich die Daten nicht verändern, was die Programmierbarkeit einschränkt.


-Vielzahl von Hardwarelimitierungen: Eine GPU besitzt für viele Aufgaben Spezialhardware. Verwendet man diese, was wiederum in den meisten Fällen empfehlenswert ist, so muss man die dazugehörigen Hardware-Limitierungen in Kauf nehmen. Stören diese Limitierungen bzw. stößt man an deren Grenzen so muss man *irgendwie* beim Programmieren darauf eingehen.


-Occupancy: Während bei dem Hardware-Multithreading auf Prozessoren jeder Thread seinen eigenen Registersatz hat (also bei 4 Fach bei einem PHI-Kern) teilen sich die Threads eines Multiprozessors auf der GPU einen Registersatz. Je mehr Register ein Thread auf der GPU benötigt, desto weniger Threads passen in einem Multiprozessor bzw. desto weniger Threads kann die GPU gleichzeitig bearbeiten. Wie bereits erwähnt, will man jedoch meist möglichst viele Threads gleichzeitig aktiv haben, um die Latenzen überbrücken zu können und die GPU gut auszulasten. So ist es in den meisten Fällein ein großes Gefriggel die Occupancy gut hinzubekommen. Auf einem PHI existiert das Konzept der Occupancy und die daraus resultierenden Probleme nicht.

-Keine Interrupts auf GPUs in Kombination mit Hardware-Scheduling: Ein Thread rechnet auf einer GPU so lange bis er terminiert; terminiert er nicht so rechnet er ewig (oder bis Windows den Displaytreiber zurücksetzt). Er kann sich auch nicht schlafen legen, die Kontrolle an einen anderen Thread abgeben, um auf ein bestimmtes Ereignis zu warten. Wenn er dennoch auf ein Ereignis warten muss, so muss er aktiv ständig die Bedingung abfragen, was Rechenleistung verschwendet. Diverse Anwendungen (wie Betriebssysteme) setzen auch voraus, dass man einen Thread per Interrupt unterbrechen kann. Diese Anwendungen sind auf der GPU ebenfalls nicht verwirklichbar. Auf einem PHI stellen sich wegen Interrupts diese Probleme nicht.

-x86 Architektur: Gerade bei kleineren Rechenaufgaben mit größerer und älterer x86-Code-Base mag es keinen Sinn machen sich einen Programmierer einzustellen, der das in mühevoller kleinarbeit auf die GPU portiert. Da mag es sehr vorteilhaft sein, sich einfach einen PHI zu kaufen und auf diesen den x86 Code direkt ausführen zu können.

 

[New Order]

@ CB

Was macht denn eigentlich der gute Herr Pohl? Warte schon die ganze Zeit auf den Bericht Ray Tracing „6.0“!

Für RT sollte die o.a. Karte ja u.a. auch eingesetzt werden.

 

[oldmanhunting]

@Nai
Ich danke Dir für das ausführliche erklären. Habe sogar ich verstanden.

@Ratzer007
Hättest Du den Thread gelesen, dann würdest Du nicht fragen.

 

[blöderidiot]

Mal etwas ausführlicher, inhaltliche Kritik oder Fragen nach ausführlicheren Erklärungen sind willkommen. Es war etwas problematisch das ganze inhaltlich "aufzurollen", da alles mit allem irgendwie zusammenhängt. Ich hoffe es ist mir dennoch halbwegs gut gelungen

Vieles, was Du schreibst, ist zwar ganz umfangreich und instruktiv, könnte aber um einige Fakten ergänzt werden: Was wäre heute besser, wenn man ein paar Arbeitsgruppen-Rechenknechte aufbaut, NVidia der Xeon-Phi? Und da muß man heute ganz klar sagen: NVidia. Und ich bezweifle, daß NVidia auf ihren Händen sitzt und nichts tut, während Intel KNL fertigstellt.

Hier die Konfigurationen der SCC 2013, Gewinner = NVidia-Systeme:

Das ist heute. Diese Gruppe verwendet Xeon-Phi.

 

[Iscaran]

Schön da treffen sich also ein paar Studentengruppen die jeweils ein Computing grid mit einer MAXIMAL steckdosenleistung von 3kW aufbauen...
In deinen Links werden zwar sehr schön die unterschiedlich aufgebauten systeme gezeigt aber welche LEISTUNGEN damit erzielt wurden eher nicht. Außer einem mickrigen vermerk "highest linpack score" und "best overall performance" und "2nd place" kommentaren gibts nicht viel infos zur Erzielten Leistung.

Allein aus der anzahl an nodes / cores / CPUs/ GPUs kann man das nämlich nicht schliessen - und aus Nai's Erklärungen wird man ersehen wieviel Software "optimierung" hinter allen ergebnissen noch so steckt.

Der beste spieler insgesamt ist demnach das balancierteste System das am einfachsten und schnellsten zu optimieren geht - weil man die dadurch eingesparte optimierungs Zeit wiederum schon nutzt um tatsächlich zu rechnen.

Dies zeigt sich auch sehr schön in dem Kommentar zum theoretisch schnellsten gebauten System der TU Chemnitz das aber WEIT hinter den möglichkeiten blieb:

"One team, Germany's own Chemnitz, went wild on accelerators. They configured eight Intel Phi and eight Nvidia K20s into their cluster. While this gave them a hell of a lot of potential compute power, it also consumed a hell of a lot of electricity.

Difficulties also arose when the team tried to get both accelerators running on the same application, so they ended up running particular apps on the K20s and others on the Phis. The problem is that even when they're idled, these beasts consume significant power and generate heat as well. Chemnitz put together a monster cluster, but like most monsters, it couldn't be completely tamed."

Aber klar Linpack scores sind ja auch das alleinige maß um performance wiederzuspiegeln .

 

[blöderidiot]

Schön da treffen sich also ein paar Studentengruppen die jeweils ein Computing grid mit einer MAXIMAL steckdosenleistung von 3kW aufbauen...
In deinen Links werden zwar sehr schön die unterschiedlich aufgebauten systeme gezeigt aber welche LEISTUNGEN damit erzielt wurden eher nicht

Hmmm, Das hast Du vielleicht falsch verstanden. Irgendwie muß man ja, wie bei der Formel-Eins, eine Beschränkung einbauen. Und das ist hier, ähnlich wie bei der Formel-Eins, ein absolutes Ressourcenmaß - da Hubraum/Drehzahl, hier nur totaler Stromdurchfluß in Watt. Da hat man sich schon etwas dabei gedacht. Man darf also alles Geld der Welt einsetzten, um heute ein Spielzeug zu bauen, was möglichst schnell rechnet bei verbreiteten parallelisierbaren technisch/wissenschaftlichen Anwendungen. Diese Anwendungen sind:

• Gromacs (Moleküldynamik)
• MILC (Quanten-Chromodynamik)
• WRF (Wettervorhersage)
• AMG (Algebraic MultiGrid Modeling)
• CP2K (Dichtefunktionalrechnungen)

Ausser Wertung, aber als interessanter Aspekt, läuft noch HPC/Linpack. Die "detaillierten" Resultate wurden tatsächlich nicht aufgelistet, vielleicht liegt das daran, daß einige gar keinen ordentlichen Durchlauf geschafft haben und man diese Gruppen gegenüber den Geldgebern (es geht um viel Geld, ich weiss das von der Chemnitzer Truppe) nicht "kompromittieren" möchte.

So richtig verstehe ich Deine abwertende Einschätzung nicht, aber Du wirst Deine Gründe haben.

 

[Iscaran]

Ich wollte damit nur kommentieren dass der von dir verlinkte artikel weder dein Argument stützt dass das einzige, schnellste Rechensystem das für computing zählt von nVidia stammt:

Was wäre heute besser, wenn man ein paar Arbeitsgruppen-Rechenknechte aufbaut, NVidia der Xeon-Phi? Und da muß man heute ganz klar sagen: NVidia.

Die von dir gelinkten Seiten zeigen zwar welche systeme von einige Arbeitsgruppen benutzt werden aber sie zeigen in der Tat überhaupt nicht deren tatsächliche Leistungsfähigkeit - auch denke ich liegen z.B. AMD systeme auf Tahiti FirePro 10k rein "leistungstechnisch" nicht wirklich zurück.
Aber in dem Wettbewerb den du gelinkt hast galt die Einschränkung mit 3kW leistung ein System zu bauen das für diese leistungsaufnahme am schnellsten rechnet. Da ist halt klar dass die alten Tahiti Karten nicht mehr mitziehen können da sie eine TDP von 375W haben und damit wohl ca etwas mehr brauchen dürften pro Flop.

Aber egal - jedenfalls belegen die links von dir eben keinesfalls deine These dass man aktuell nur auf nVidia setzen kann. Allein schon wegen der aufzeigten inhaltlichen Mängel.

Mehr wollte ich eigentlich nicht aussagen.

EDIT: Hier sieht man ja wieviel die Software entwicklung ausmacht - eine Leistungssteigerung um Faktor 8 in 2 Jahren...rein auf Hardware war das nicht möglich.

Und wie Nai schon so schön dargelegt hat spielt gerade beim grid computing die optimierung der software auf die jeweilige hardware die hauptrolle.

Da hat nVidia natürlich auch marktvorteile da sie aktuell ~80% des computing markts mit Quadro /Tesla zukleistern. Was aber dennoch nicht zuviel bedeutet da sie seit Jahren beständig an Boden verlieren und AMD Jahr für Jahr seit 2008 höhere Zuwachszahlen in dem Segment hat (in absolutstückzahlen) wie nVidia. Nur so z.B.

In (bestimmten) CAD Anwendungen z.B. ist ne Tahiti ca 40x schneller als ne Tesla K10....

Ergänzung (21. November 2013)

Nachtrag:

Auch darf man für "kommerzielles" computing den Preis nicht vergessen...denn 10 billiger karten sind ggf. immer noch schneller als 5 genauso teure aber für sich genommen schnellere karten:

http://www.develop3d.com/hardware/graphics-cards-for-cad-ptc-creo-2.0-solidworks-2013
"It is also worth noting that AMD is currently offering some half price deals on AMD FirePro cards for one off purchases."

Bei gleichem Preis wäre z.B. AMD ca. http://fireuser.com/blog/performanc...ad_nvidia_quadrofx_1800_vs_amd_firepro_v5800/

"Performance Test 7.0 test, Quadro earned 770.1 points while FirePro earned a higher score equal to 1702.9 points. This is means about 221.12% performance gain for DirectX 3D graphics, therefore, the double."

"In Cadalyst Systems Benchmark 2011 test, Quadro a little faster than FirePro while using AutoCAD default drivers due c2011_8.dwg file score, but it was slower than FirePro in the other files (where FirePro was 102.32% faster). However, using AutoCAD optimized drivers, Quadro earned 613 points while FirePro earned a higher score equal to 2060 points. This is means about 336.05% faster in AutoCAD 2011."


Gerade im computing bereich gibt es eben viel mehr facetten als im reinen gaming sektor.

 

[blöderidiot]

auch denke ich liegen z.B. AMD systeme auf Tahiti FirePro 10k rein "leistungstechnisch" nicht wirklich zurück.

Da denkst Du imho schon falsch. Im wissenschaftlich/technischen Bereich spielen AMD-GPU-Server keine Rolle. Es gibt also gar keine Leistung, die FirePro-Karten bringen können, weil die gängigen wissenschaftlich/technischen Programme im HPC diese nicht unterstützen.

Aber in dem Wettbewerb den du gelinkt hast galt die Einschränkung mit 3kW leistung ein System zu bauen das für diese leistungsaufnahme am schnellsten rechnet. Da ist halt klar dass die alten Tahiti Karten nicht mehr mitziehen können da sie eine TDP von 375W haben und damit wohl ca etwas mehr brauchen dürften pro Flop.

Ja, und möglicherweise hilft Dir das, in der Realität anzukommen? Sorry, ich hätte das niemals so "bissig" formuliert, hättest Du nicht:

Da hat nVidia natürlich auch Marktvorteile da sie aktuell ~80% des computing markts mit Quadro/Tesla zukleistern. Was aber dennoch nicht zuviel bedeutet da sie seit Jahren beständig an Boden verlieren und AMD Jahr für Jahr seit 2008 höhere Zuwachszahlen in dem Segment hat (in absolutstückzahlen) wie nVidia. Nur so z.B.

geschrieben.

Das kann ich gar nicht glauben. Da möchte ich auch lieber nichts weiter dazu sagen.

In (bestimmten) CAD Anwendungen z.B. ist ne Tahiti ca 40x schneller als ne Tesla K10....

Unter welchen Bedingungen? Hat das irgendeine praktische Auswirkung?

"It is also worth noting that AMD is currently offering some half price deals on AMD FirePro cards for one off purchases."
Gerade im computing bereich gibt es eben viel mehr facetten als im reinen gaming sektor.

Der "computing bereich" um den es hier geht, ist der HPC-Bereich!

Was meinst Du denn, warum AMD die Karten für den halben Preis anbietet? Aus humanistischen Gründen?

Ergänzung (21. November 2013)

"In Cadalyst Systems Benchmark 2011 test, Quadro a little faster than FirePro while using AutoCAD default drivers due c2011_8.dwg file score, but it was slower than FirePro in the other files (where FirePro was 102.32% faster). However, using AutoCAD optimized drivers, Quadro earned 613 points while FirePro earned a higher score equal to 2060 points. This is means about 336.05% faster in AutoCAD 2011."

Ja, und heute sieht es so aus. Was nun?

 

[Iscaran]

Im technischen Bereich sind die HAUPTANWENDUNGEN: CAD + Solidworks - allein bei mir pro Büro 5 Rechner....ind nahezu jedem ist ne FirePro
drin.

Du musst unterscheiden zwischen ein paar "riesen-GPU" clustern und den sonstigen technischen anwendungen wo vor allem auch Preis eine rolle spielt.

Zu AMD gewinnt anteile im Markt:
http://jonpeddie.com/press-releases...eling-the-same-pain-as-the-broader-pc-market/
http://jonpeddie.com/publications/workstation_report/
Aktuell herrscht gleichstand - beide wachsen gleichschnell - aber bis ende 2012 hat AMD aufgeholt.

Aber der Markt sind ca. 1.25 Millionen GPUs:
Professional graphics market surges as well

The market for professional graphics broke out of its doldrums in the second quarter as well. For the previous several quarters, the market had been listless, neither making strong headway nor backtracking. Well, if there was any quarter in recent memory we could label "breakout", it was Q3'12. The industry, primarily composed of the Nvidia/AMD duopoly, shipped a total of approximately 1.25 million workstation-caliber GPUs in the quarter (including both mobile modules and deskside add-in cards), representing sequential growth of 9.9% and year-over-year gain of 13.8%.

Im inhaltsverzeichnis dann zu finden: "Nvidia vs. AMD both make substantial — but similar — gains in volume ... so market shares once again relatively stable"


Naja egal wir driften ab.

Ergänzung (21. November 2013)

Ja, und heute sieht es so aus. Was nun?

http://www.tomshardware.com/reviews/best-workstation-graphics-card,3493-7.html

Eine seite weiter....ne 7970 an der spitze und das ist noch nicht mal ne "Fire Pro S10000."

Was ich damit sagen wollte es ist eher sehr fall spezifisch und die Leistung "rein Rohpower" mäßig nimmt sich in dem Segment nicht viel. Es hängt viel zu sehr von der speziellen anwendung ab.
Und damit kommt dem PREIS solcher karten eine nicht unwichtige bedeutung zu.

Wenn du 100 CAD Arbeitsplätze austatten musst/willst als unternehmen kaufst du 100 S10000 oder nur 100 alte Qaudro zum selben preis ?

 

[blöderidiot]

Hallo Iscaran,

Und damit kommt dem PREIS solcher karten eine nicht unwichtige bedeutung zu.
Wenn du 100 CAD Arbeitsplätze austatten musst/willst als unternehmen kaufst du 100 S10000 oder nur 100 alte Qaudro zum selben preis?

Da magst Du schon Recht haben, allerdings geht es dann hier spezifisch um CAD und nicht mehr um HPC. Allerdings habe ich dazu folgende Lektüre gefunden. Kann man das so, wie es da steht, akzeptieren?

 

[Iscaran]

Jo das Fazit von Xbitlabs, insbesondere die Stelle:

"It is clear, however, that one graphics card model is not enough for a good fight for the whole market."

Unterschreib ich so auch . Es kommt eben darauf an was man macht und zwar ganz konkret im computing....da die Performance eben mal um den Faktor 100 schwanken kann je nach spezieller anwendung/software.

 

[Nai]

Vieles, was Du schreibst, ist zwar ganz umfangreich und instruktiv, könnte aber um einige Fakten ergänzt werden: Was wäre heute besser, wenn man ein paar Arbeitsgruppen-Rechenknechte aufbaut, NVidia der Xeon-Phi? Und da muß man heute ganz klar sagen: NVidia. Und ich bezweifle, daß NVidia auf ihren Händen sitzt und nichts tut, während Intel KNL fertigstellt.

Machst du es dir da nicht etwas zu einfach indem du sagst, dass sie da und da eine bessere Performance erzielt haben ist eine GPU-Lösung allgemein besser? Wenn ich mich für etwas entscheiden würde, würde ich folgende Punkte abarbeiten:

-Wie performant laufen die Algorithmen auf GPUs und wie performant auf CPUs (PHIs)? Generell gilt, dass komplexere Algorithmen weniger GPU und mehr CPU freundlich sind, während einfachere Algorithmen eher GPU freundlich sind.

-Worauf läuft die vorhandene Code-Base? Ist der Code bereits parallel in x86 vorhanden würde ich eher auf den PHI setzen, ist er nur parallel in CUDA/OpenCL vorhanden, was vermutlich der weitaus seltenere Fall sein wird, würde ich eher auf GPUs setzen.

-Wie viel Zeit und Geld kann man für das Portieren der vorhanden Code-Base aufbringen? Bei viel Zeit und Geld kann man sich die Hardware nach den anderen Gesichtspunkten aussuchen, bei wenig Zeit und Geld ist man auf die Hardware angewiesen, deren Code-Base man besitzt.


-Worauf laufen die Anwendungen, bei welchen man keinen Quellcode hat? Unterstützen die Anwendungen nur x86 dann kann man nur auf den PHI setzen (oder sie selbst neu schreiben!), während wenn die Anwendungen nur CUDA können, muss man auf CUDA setzen.

-Wie viel Zeit und Geld kann man für das Optimieren aufbringen? Bei viel Geld und Zeit würde ich eher auf GPUs setzen, während ich bei weniger Zeit und weniger Geld auf CPUs setzen würde, da bei GPUs im Allgemeinen mehr Optimierungsbedarf besteht.

-Wie teuer sind die Anschaffungskosten der Hardware und die Betriebskosten im Bezug auf die Performance?

-Willst du auf den Rechnern auch eine rechenintensive graphische Ausgabe (CAD, 3D-Design) haben? Wenn ja, dann würde ich auf GPUs setzen, da sie die graphische Ausgabe auch berechnen können.

All diese Gesichtspunkte kann man kombinieren um eine Kosten/Nutzen/Zeit Rechnung zu machen und das ganze mal z.T. durchzurechnen oder auch durchzuschätzen und dann gegebenenfalls abzuwägen.

Man könnte die Argumentation ja kritisieren und sagen die Entwicklungskosten, Potierungskoten und Optimierungskosten für den Quellcode sind irrelevant gegenüber den Hardwarekosten und den Stromkosten. Wenn man aber bedenkt, dass ein Programmierer einen Arbeitgeber wohl ca 4000-7000 € pro Monat kosten wird und bei der Portierung/Optimierung des Quelltexts sicherlich ein paar Personenmonate benötigt werden, so kommt sehr schnell ein Betrag von 100 000 € zusammen. Davon kann man sich bereits wieder recht viele Karten (PHIs, GPUs) kaufen, weshalb das Optimieren und Portieren gerade bei kleineren Clustern absolut unlohnenswert ist.

 

[Iscaran]

Danke Nai !

Genau das versuche ich die ganze Zeit zu erklären - aber deine Worte sind wesentlich besser als meine !

Liegt vielleicht daran dass ich nur am Rande mit sowas beschäftigt bin du aber wohl zumindest etwas tiefer in der Branche steckts.

 

[Krautmaster]

@Nai

*daumen hoch* -> bisher hab ich nur wenig Posts von dir gelesen aber das was ich gelesen hab gefällt mir sehr. Dankeschön!

 

[Skysnake]

Hallo Iscaran,

Da magst Du schon Recht haben, allerdings geht es dann hier spezifisch um CAD und nicht mehr um HPC. Allerdings habe ich dazu folgende Lektüre gefunden. Kann man das so, wie es da steht, akzeptieren?

Naja, sieht man doch sehr gut. Es kommt IMMER! auf die Anwendung drauf an. Kein Hersteller hat überall die Nasse vorne...

Und die meisten Anwender haben auf einem System 1-3 unterschiedliche Softwarepakete laufen und das wars dann meist auch. Daher muss man sich immer sehr genau anschauen, was man denn machen will.

Jo das Fazit von Xbitlabs, insbesondere die Stelle:

"It is clear, however, that one graphics card model is not enough for a good fight for the whole market."

Unterschreib ich so auch . Es kommt eben darauf an was man macht und zwar ganz konkret im computing....da die Performance eben mal um den Faktor 100 schwanken kann je nach spezieller anwendung/software.

Naja, Faktor 100 eher nur, wenn was broken/einseitig optimier ist, nen Faktor 10 kommt aber schpn häufiger vor, und selbst nen Faktor 2 reicht ja oft völlig aus, eben sich für andere Hardware zu entscheiden.

@Nai:
Jup, das triffts eigentlich in allen Bereichen

 

[Mr.Seymour Buds]

Alles schön und gut. Aber es mangelt an Softwarecode. Selbst eine mittlerweile veraltete NVIDIA Fermi optimal auszulasten, bedeutet Code zu schreiben, der nur von "diesen Experten" erarbeitet werden kann. Und ich meine jetzt nicht 2 lange Integer Vektoren addieren, sondern HPC Code im Sinne von naturwissenschaftlichen Simulationen.