AMD Ryzen Threadripper 2990WX und 2950X im Test: Mit Vollgas an Intel vorbei

[Phantomias88]

@Holt
Ich hoffe mal die Mehrheit stimmt dem Low-Level Zugriff zu!
Ein Treiber wäre schon wieder High-Level und würde weitere Latenzen mit sich bringen.
Die Vulcan API zeigt sehr schön, dass Programme besser Low-Level Zugreifen auf das System.
Via Skript(ing) wird inzwischen zu genüge programmiert, der Overhead verrät es.

 

[Holt]

@Holt
Ich hoffe mal die Mehrheit stimmt dem Low-Level Zugriff zu!

Was meinst Du damit? Sollte es SetProcessAffinityMask sein, so ist diese eine API Funktion und hat nichts mit einem Low-Level Zugriff zu tun.

Ein Treiber wäre schon wieder High-Level und würde weitere Latenzen mit sich bringen.

Auf HW ohne einen Treiber zuzugreifen, wird sich kaum ein Programmierer (außer er schreibt eben gerade diesen Treiber) antun wollen, außer es geht um sehr spezielle Software die spezifisch für diese Hardware geschrieben wird.

Die Vulcan API zeigt sehr schön, dass Programme besser Low-Level Zugreifen auf das System.
Via Skript(ing) wird inzwischen zu genüge programmiert, der Overhead verrät es.

Kann es sein das Du compilierte Programmiersprachen mit Low-Level verwechselst? Das ist aber nicht das Gleiche, Low-Level bedeutet direkt HW ohne die Treiber direkt anzusprechen und hat erstmal nichts damit zu tun ob dafür eine Skriptsprache verwendet wird oder eine die compiliert werden muss, auch wenn die meisten Frameworks für Skriptsprachen wohl keine Low-Level Zugriffe erlauben. Einer der Gründe für solche Skriptsprachen ist es ja gerade möglichst unabhängig von der jeweiligen HW zu sein und ja, der Preis dafür ist die meist nicht so optimale Performance. Aber Software speziell für eine bestimmte Hardware zu schreiben oder nur gut darauf zu optimieren, ist eben aufwendig und lohnt sich daher nur selten, meist nur im Rahmen von Projekten aber selten für Software von der Stange.

 

[Phantomias88]

Was meinst Du damit? Sollte es SetProcessAffinityMask sein, so ist diese eine API Funktion und hat nichts mit einem Low-Level Zugriff zu tun.
Auf HW ohne einen Treiber zuzugreifen, wird sich kaum ein Programmierer (außer er schreibt eben gerade diesen Treiber) antun wollen, außer es geht um sehr spezielle Software die spezifisch für diese Hardware geschrieben wird.
Kann es sein das Du compilierte Programmiersprachen mit Low-Level verwechselst? Das ist aber nicht das Gleiche, Low-Level bedeutet direkt HW ohne die Treiber direkt anzusprechen und hat erstmal nichts damit zu tun ob dafür eine Skriptsprache verwendet wird oder eine die compiliert werden muss, auch wenn die meisten Frameworks für Skriptsprachen wohl keine Low-Level Zugriffe erlauben. Einer der Gründe für solche Skriptsprachen ist es ja gerade möglichst unabhängig von der jeweiligen HW zu sein und ja, der Preis dafür ist die meist nicht so optimale Performance. Aber Software speziell für eine bestimmte Hardware zu schreiben oder nur gut darauf zu optimieren, ist eben aufwendig und lohnt sich daher nur selten, meist nur im Rahmen von Projekten aber selten für Software von der Stange.

Die API übersetzt in Echtzeit, also Assembler Sprache -> bekannt?

Ohne Treiber = Kernel übernimmt.

Treiber "bypass" für Vulkan und direkt in Assembler schreiben?

 

[Kalorean]

Der Inhalt deiner Beiträge hat absolut Substanz und ist auch für mich durchaus ab und an mal ganz interessant, nur, wie gesagt, diese Wall of Text immer, wo jeder Satz zerlegt und widerlegt werden muss, fällt halt auf.

Ich finde das als jemand, der technisch in der Hinsicht überhaupt nicht versiert ist, im Gegenteil sogar sehr hilfreich. Kontext ist grundsätzlich mMn immer hilfreich, vor allem bei einem solchen Format wie innerhalb eines Forums, bei dem man ob und ab einer gewissen Threadflut sehr leicht die Übersicht verlieren kann. Das ist keine Kritik an deiner Anmerkung, nur meine dazu, die signalisieren soll, dass es zumindest einen gibt, der es anders sieht.

 

[Superwilli]

Wäre Windows Server hier evlt. besser geeignet?

 

[Holt]

Die API übersetzt in Echtzeit, also Assembler Sprache -> bekannt?

API steht für Application-Programming-Interface und hat erstmal nichts mit der Sprache zu tun, für die jeweilige Programmsprache braucht man nur eine Möglichkeit diese anzusprechen. Dann bedeutet "übersetzt in Echtzeit" eine Skriptsprache, denn die anderen ob C, C++ oder auch direkt Assembler werden zur Entwicklungszeit in den Maschinencode übersetzt. Maschinencode ist nicht das gleiche wie Assembler Sprache, da muss man auch noch den Quellcode mit einen Assembler in den Maschinencode, also die ausführbare Datei übersetzen, was übrigens sich übrigens von einem Compiler nicht wirklich unterscheidet, nur dass man eben von einem Assembler spricht, wenn der Quellcode entsprechend Assemblercode ist und Compiler übersetzen die Hochsprachen meist erst in Assemblercode und der wird dann in einem zweiten Schritt noch mal vom Assembler in den Maschinencode übersetzt, wobei man den gesamten Vorgang dann üblicherweise einfach als Compilieren bezeichnet, auch wenn es eben i.d.R. zwei Stufen (der eigentliche Compiler von z.B. C++ auf Assemblercode und dann der Assembler zu Maschinencode) sind.

Ohne Treiber = Kernel übernimmt.

Die Treiber stecken in aller Regel im Kernel, der Kernel greift auch nur beschränkt direkt auf die Hardware zu, sonst wäre dessen Entwicklung ja auch viel zu aufwendig.

Treiber "bypass" für Vulkan und direkt in Assembler schreiben?

Dann viel Spaß damit, aber da Du offensichtlich gar keine Ahnung von Softwareentwicklung hast, ja nicht einmal weißt was was ist, dürfte es sowieso nie etwas damit werden. Außerdem wäre der Gewinn wohl gering, denn Treiber werden meist sowieso in C(oder C++) geschrieben und gute C Compiler können auch ordentlich optimieren, da braucht man kaum noch versuchen an den performancekritischen Stellen mit Inline Assembler selbst Hand anzulegen, was dann die Portabilität des Quellcodes auch massiv einschränkt. Portabilität ist der Hauptgrund warum man überhaupt Hochsprachen nimmt, denn Softwareentwicklung ist sehr teuer und je mehr bewährten und ausgetesteten Quellcode man wiederverwenden kann, umso geringer fallen die Kosten und Entwicklungszeiten aus.

Das der 2990WX unter Linux besser abschneidet, wundert mich übrigens nicht, denn viele Linux Anwendungen sind schon lange NUMA Aware und dürften schon von daher besser mit dessen NUMA Architektur zurechtkommen. Außerdem ist Linux als OS für solche CPUs sowieso schon der Kosten wegen besser, denn Windows Server für 32 Kerne zu lizenzieren, kostet richtig Geld. Abgesehen davon hat Linux im Kernel schon viel mehr parallelisiert als Microsoft im Kernel von Windows.

 

[Phantomias88]

@Holt
Das war kein Angriff von mir, was deine Argumentation betrifft!

Sehe es doch als "persönliche Meinung" meinerseits.
Ist das so schwer zu akzeptieren?

 

[fdsonne]

@fdsonne
Ich mein da bist du leider nicht ohne Schuld. Wenn du damals sehr ähnliche Texte zum 7980XE abgegeben hättest, würde man auch deine jetzige Meinung dazu bestimmt ernst nehmen. So fehlt halt bisschen die objektive Grundlage dazu.

Ehrlich - ihr habt ne komische Art von Diskussionskultur - was möchtest du mir jetzt damit sagen? Wer meine Meinung nicht teilt - muss es nicht tun. Wer sie nicht ernst nicht - muss auch das nicht tun. Akzeptieren wäre vllt ein Anfang. Mehr verlangt doch überhaupt niemand? Warum zur Hölle macht ihr es euch immer selbst so schwer? Geht doch mal nüchtern an die Themen - Ich bin lange genug dabei um da drüber zu stehen ob mich wer leiden kann oder nicht. Mal davon ab, dass es auch gar nicht (mehr) möglich ist, von allen gemocht zu werden.
Hier tummeln sich zunehmend Fans und markenverblendete Wichtigtuer - solche Leute sind gänzlich unerreichbar was sachlich nüchterne Diskussionen angeht, weil alles was nicht der eigene Tellerrand ist, nicht akzeptiert wird. Um so "bekannter" dein Name hier ist, desto mehr werden gegen dich sein... Das hast du da oben ganz deutlich selbst sehen können (wenn du willst zumindest) - wenn auf die Aussage, ich verdiene mein Geld mit dieser Art von Hardware einfach nur ein - du kannst uns viel erzählen kommt, also einfach nichts anderes als ein kategorisches Abblocken jeglicher Akzeptanz, nichtmal ein Widerspruch oder irgendwas, was ansatzweise dem gle - egal ob richtig oder falsch, was will man da bitte hier erwarten?


Also mal Butter bei die Fische - was soll ich zum 7980XE sagen? -> mir wäre nicht bekannt, dass der ne ähnliche oder noch anders komische RAM zu DIE Anbindung als der 2990WX hat? Und wenn du meinst das wäre doch so - dann bring doch bitte direkt konkrete Zahlen, Belege oder Fakten...

Wäre Windows Server hier evlt. besser geeignet?

Möglich, aber wahrscheinlich macht das nur bedingt einen greifbaren Unterschied... Auch der Server versucht primär die Zuweisung der Threads auf je einem NUMA Node zu halten, es sei denn, die Software verlankt primär was andres (durch mehr Threads als ein Node bietet, durch mehr Speicherbedarf als ein Node bieten usw.)

Man muss halt differenzieren. Hast du einen Task mit paar Threads Load, und der Rest vom Prozessor liegt brach -> hier kann der Threadscheduler klar viel bewirken.
Hast du einen Task mit sehr vielen Threads oder mehrere Tasks so dass der Prozessor jeweils Threadseitig gut belastet ist -> hier kann der Threadscheduler nur bedingt viel bewirken - mehr als nicht rumschubsen und möglichst nicht auf die beiden Compute DIEs zugreifen kann er nicht machen. Aber gerade letzteres WILL man ja als User, weil wozu 1830€ hinblättern, wenn 50% der CPU dann nicht benutzt werden sollten? Dann kannste gleich 2950er nehmen (mMn)

 

[Holt]

Sehe es doch als "persönliche Meinung" meinerseits.

Das Problem dabei ist nur, dass Du so wirklich gar keine Ahnung von dem Thema zu haben scheinst, dass Du alles durcheinander wirfst und wenn man von etwas keine Ahnung hat, sollte man auch vorsichtig sein wenn man versucht sich dazu eine Meinung zu bilden und erst recht wenn man diese auch noch kund tut. Betrachte meine Ausführungen also als Hinweis wo Du falsch liegst und als Ansporn Dich in dem Bereich weiterzubilden, dann ist es auch einfacher und vor allem erst sinnvoll da überhaupt mitzudiskutieren.

 

[Phantomias88]

Das Problem dabei ist nur, dass Du so wirklich gar keine Ahnung von dem Thema zu haben scheinst, dass Du alles durcheinander wirfst und wenn man von etwas keine Ahnung hat, sollte man auch vorsichtig sein wenn man versucht sich dazu eine Meinung zu bilden und erst recht wenn man diese auch noch kund tut. Betrachte meine Ausführungen also als Hinweis wo Du falsch liegst und als Ansporn Dich in dem Bereich weiterzubilden, dann ist es auch einfacher und vor allem erst sinnvoll da überhaupt mitzudiskutieren.

Dito
Wir sind hier international Vertreten.

 

[Holt]

mehr als nicht rumschubsen und möglichst nicht auf die beiden Compute DIEs zugreifen kann er nicht machen.

Die Threads nicht zu verschieben, sollte logisch sein wenn sowieso alle Kerne ausgelastet sind, dann bringt dies ja auch nichts. Aber wie soll der Task Scheduler die beiden Dies überhaupt erkennen, die keinen direkten RAM Zugang haben? Und selbst wenn der sie kennt, dann wäre die Alternative doch nur 16 Kerne zu nutzen, denn er kann eben nicht vorab wissen ob ein Thread dann z.B. gleich viele RAM Zugriffe machen wird und dann wären man wieder beim 2950X statt des 2990WX, wenn man die Kerne dieser Dies eben nicht nutzt. Der 2990WX ist eben eine sehr spezielle CPU und kann daher auch nur in sehr speziellen Anwendungen wirklich punkten und der Interessent hat die schwere Aufgaben herauszufinden ob die SW die er hat auch dazu gehört oder nicht. Wobei dies auch von den Daten abhängen kann, passen diese bei einer Ausgabe oder Einstellung eben noch in den jeweiligen Cache, wenigstens in den L3 Cache des CCX, so kann das Ergebnis ganz anderes ausfallen als wenn sie etwas größer sind und gerade nicht mehr rein passen, also ständig RAM Zugriffe nötig sind. Dazu muss man dann schauen ob diese oder jene Einstellung der CPU vielleicht besser passt, aber immer wenn man nicht alle Kerne aktiviert hat, hat man im Grunde nur eine zu teurer gekaufte CPU im Rechner sitzen.

 

[BessereHälfte]

Ehrlich - ihr habt ne komische Art von Diskussionskultur

Ja echt. Aber echt alle

Wer meine Meinung nicht teilt - muss es nicht tun.

Darf ich das nun auch zu dir sagen? bitte bitte

Also, Quadro zum Zocken kaufen und gut ist. Man liest sich.

 

[Goderion]

Vielen Dank an fdsonne und Holt für die vielen Infos, Antworten und Aufklärung.

Die API übersetzt in Echtzeit, also Assembler Sprache -> bekannt?

Wie meinst Du das? Wenn ich eine Windows API Funktion aufrufe, z.B. CreateFile in einem Programm, dass in C geschrieben und dementsprechend kompiliert wurde, werden die Parameter (Dateiname, Zugriffsrechte, usw.) für CreateFile auf den Stack (Variablen-Stapel pro Thread) geschmissen und dann wird direkt in die kernel32.dll gesprungen. Da laufen dann noch ein paar Prüfungen usw. und dann wird (Vermutung, sieht so beim Debuggen aus) ein Service-Call ausgeführt, also Wechsel vom Userspace in den Kernelspace. Der gesamte Ablauf, also der Aufruf der Funktion CreateFile im C-Programm, dann die Verarbeitung vom Kernel und je nach Situation die Ausführung im Treiber, ist komplett in Maschinensprache. Da wird nix übersetzt oder interpretiert. So habe ich das bis jetzt zumindest immer angenommen.

Ohne Treiber = Kernel übernimmt.

Mir ist nicht bekannt, dass der Kernel selber direkt auf Hardware zugreift. Das sollte immer über einen Treiber laufen.
Programm -> Windows/WinAPI/Kernel -> Treiber -> Hardware
Das ist doch das Großartige an diesem Konstrukt, dass ich als Programmierer die Hardware und Treiber nicht wirklich kennen muss. Ich programmiere etwas für Direct3D11 (könnte man als Render-Kernel betrachten) und es läuft auf millionen verschiedener Systeme.
Wenn ich eine Datei erstellen oder Schreiben möchte, muss ich nur den Pfad angeben. Der Kernel leitet dass dann je nach Pfad an den verantwortlichen Treiber weiter.
Schnittstellen FTW!

Treiber "bypass" für Vulkan und direkt in Assembler schreiben?

Wie? Du willst einen Treiber, z.B. den Grafikkarten-Treiber umgehen? Du willst die Hardware selber direkt ansprechen?
Und was hat das damit zutun, dass ich etwas direkt in Assembler schreibe/programmiere? "Verrückte Dinge", wie z.B. die Hardware direkt zu adressieren/steuern, geht nicht nur mit Assembler.

 

[jdl]

@Holt
Das war kein Angriff von mir, was deine Argumentation betrifft!

Sehe es doch als "persönliche Meinung" meinerseits.
Ist das so schwer zu akzeptieren?

Sorry, aber die Äußerungen von Dir lassen durchblicken, dass Du von Softwareentwicklung im Allgemeinen und von Systementwicklung im Besonderen keinerlei Ahnung hast.

 

[Holzmann]

Ach kommt schon, wenn hier einer keine Ahnung bin ich das, aber doch nicht Phantom!

 

[Phantomias88]

Vielen Dank an fdsonne und Holt für die vielen Infos, Antworten und Aufklärung.


Wie meinst Du das? Wenn ich eine Windows API Funktion aufrufe, z.B. CreateFile in einem Programm, dass in C geschrieben und dementsprechend kompiliert wurde, werden die Parameter (Dateiname, Zugriffsrechte, usw.) für CreateFile auf den Stack (Variablen-Stapel pro Thread) geschmissen und dann wird direkt in die kernel32.dll gesprungen. Da laufen dann noch ein paar Prüfungen usw. und dann wird (Vermutung, sieht so beim Debuggen aus) ein Service-Call ausgeführt, also Wechsel vom Userspace in den Kernelspace. Der gesamte Ablauf, also der Aufruf der Funktion CreateFile im C-Programm, dann die Verarbeitung vom Kernel und je nach Situation die Ausführung im Treiber, ist komplett in Maschinensprache. Da wird nix übersetzt oder interpretiert. So habe ich das bis jetzt zumindest immer angenommen.


Mir ist nicht bekannt, dass der Kernel selber direkt auf Hardware zugreift. Das sollte immer über einen Treiber laufen.
Programm -> Windows/WinAPI/Kernel -> Treiber -> Hardware
Das ist doch das Großartige an diesem Konstrukt, dass ich als Programmierer die Hardware und Treiber nicht wirklich kennen muss. Ich programmiere etwas für Direct3D11 (könnte man als Render-Kernel betrachten) und es läuft auf millionen verschiedener Systeme.
Wenn ich eine Datei erstellen oder Schreiben möchte, muss ich nur den Pfad angeben. Der Kernel leitet dass dann je nach Pfad an den verantwortlichen Treiber weiter.
Schnittstellen FTW!


Wie? Du willst einen Treiber, z.B. den Grafikkarten-Treiber umgehen? Du willst die Hardware selber direkt ansprechen?
Und was hat das damit zutun, dass ich etwas direkt in Assembler schreibe/programmiere? "Verrückte Dinge", wie z.B. die Hardware direkt zu adressieren/steuern, geht nicht nur mit Assembler.

Windows user?
No problem, 15. check

€dit: Womit wird das UEFI geschrieben? Ass...

 

[jdl]

Das ist doch das Großartige an diesem Konstrukt, dass ich als Programmierer die Hardware und Treiber nicht wirklich kennen muss. Ich programmiere etwas für Direct3D11 (könnte man als Render-Kernel betrachten) und es läuft auf millionen verschiedener Systeme.

Der große Vorteil von IBMs S/360 (erschienen 1964) war es, dass sie mit dem ersten Betriebssystem (OS/360) auf den Markt gebracht wurde. Bis zum Erscheinen der S/360 mussten Programme immer für die jeweiligen Maschine neu geschrieben werden. OS/360 hatten dann auch schon abstrahierende APIs und Treiberschnittstellen. UNIX wurde von zwei absoluter Könner entwickelt, zuerst für die DEC PDP-7, weil sie so eine Maschine zur Verfügung hatten, in Assembler. Der Port auf die PDP-11 erfolgte noch in Assembler, aber Version 4 von UNIX (1973!) wurde dann komplett in C neu geschrieben. Das war das erste Mal, dass ein OS nahezu 100% in einer portabel Sprache geschrieben wurde. Die systemabhängigen Teile sind bei UNIX sehr gering und die Assembler Codeanteile noch sehr viel geringer. Zum Vergleich CP/M und DOS sind obwohl sind jünger sind sehr viel mehr von der Plattform abhängig gewesen, und zuerst in Assembler geschrieben worden. Windows war früher ebenfalls sehr stark von x86 abhängig. Das hat sich erst mit der Einführung von Windows/NT geändert. NT ist sehr stark von VMS beeinflusst worden, weil MS Entwickler von DEC angeheuert hatte.

Man sieht an Linux wie flexibel das ursprüngliche UNIX-Konzept war und ist. Man kann mit relativ wenig Aufwand das OS auf eine andere Plattform portieren und dort betreiben. Anwendungen lassen sich ebenfalls leicht portieren. Wenn man einige wenige Grundregeln (Byteorder, 32Bit/64Bit sauberer Code) bei der Entwicklung beachtet hat, sind die Programme direkt für die neue Plattform übersetzbar.

- - - Updated - - -

Wie darf ich mir das mit dem Speicher vorstellen. Ich habe gelesen, das beim 2990WX jeweils zwei DIEs (0 und 2) zwei Speicherkanäle und 32 PCIe-Lanes haben. Die anderen DIEs (1 und 3) haben keinen direkt Zugriff auf RAM oder die PCIe-Lanes. DIE0 und DIE2 haben "direkten" Zugriff auf den gesamten Speicher. Wenn ich jetzt einen Prozess an DIE0 binde, können dessen Threads doch direkt auf den gesamten Speicher "ohne Umwege" zugreifen? Ob UMA oder NUMA ist in dem Fall doch egal?

Nein, jeder Die bei Zen/Zen2 hat maximal 2CCX mit je 4 Cores, 2 Speicherkanäle und bis zu 32 PCIe Lanes. Der Speicher und die PCIe Lanes sind immer lokal zum Die, d.h. man hat immer eine höhere Latenz und meistens auch eine geringere Bandbreite, wenn man auf diese von anderen NUMA-Knoten zugreift. Seit langer Zeit werden nur noch ccNUMA Systeme gebaut, so dass die Cache Koheränz auf dem kompletten Arbeitsspeicher gewährleistet ist. Früher gab es auch mal Systeme bei denen das nur für den lokalen Speicher galt. Daher kann man immer mittlerweile von jedem Core auf den kompletten Arbeitsspeicher zugreifen. Aber eben nicht direkt, sondern nur über die Interlinks des NUMA-Systems. Wie kompliziert die Zugriffe sind, hängt von der Topologie des Systems ab. D.h. wie viele Hopps braucht man im System, um auf den Speicher eines anderen NUMA-Knotens zuzugreifen. Sowohl EPYC wie Xeon SP bringen hier Verbesserungen gegenüber den Vorgänger Generationen.

Ergänzung:
Auch mit UMA Einstellung im BIOS sind die Threadripper NUMA Systeme, und können ihre wahre Natur nicht ändern. Wahrscheinlich verwendet AMD bei der UMA Einstellung einfach Memory Interleaving als Standardvorgabe im BIOS. Man kann das zumindest unter Linux auch über Software erreichen, wenn die Applikation spezielle NUMA-Libraries nutzt.

 

[pclovely]

@Holt
Und die HAL ist keine Software die Treiber beinhaltet, von wegen LowLewel Hardwarezugriff? Die benötigst du um an dem Bsp. Teile der physischen und virtuellen Speicherverwaltung ansprechen zu können und sie teilt ja auch Treibern mit was die Hardware gerade so meldet oder tut. Die Speicherverwaltung ist dabei eine architekturspezifische Größe.

Das Sheduling bewältigt nicht nur Kontextwechsel, Register zu sichern und wieder herzustellen (auch virtuelle). Teile des Schedulers sind dabei Architekturabhängig und gehören auch zur HAL. Der Scheduler wird von einem Timer aufgerufen, der wiederum ein Treiber sein könnte, innerhalb der HAL. So einfach ist LowLewel und sein direkter Hardwarezugriff ohne Treiber nun auch wieder nicht.

Die HAL kann dabei Teil des OS sein.

Das der 2990WX unter Linux besser abschneidet, wundert mich übrigens nicht, denn viele Linux Anwendungen sind schon lange NUMA Aware und dürften schon von daher besser mit dessen NUMA Architektur zurechtkommen. Außerdem ist Linux als OS für solche CPUs sowieso schon der Kosten wegen besser, denn Windows Server für 32 Kerne zu lizenzieren, kostet richtig Geld. Abgesehen davon hat Linux im Kernel schon viel mehr parallelisiert als Microsoft im Kernel von Windows.

Dem gibt es eigentlich nichts hinzufügen, nur direkte Vergleiche und Benchmark mit anderer Hardware fehlen jetzt noch.

 

[Goderion]

Windows user?
No problem, 15. check

Was soll das? Kannst Du auch vernünftig kommunizieren? Jedes mal das gleiche mit dir. Ich frage so gut ich kann nach und es kommt immer nur so ein kurzer Quark von dir.
Und ja, ich arbeite und programmiere fast nur für und unter Windows. Und? Bin ich deswegen jetzt ein schlechter Programmierer?
Linux/Unix wird sicher ähnlich arbeiten wie Windows. Auch dort wird das Programm mit einem Kernel kommunizieren, bzw. einer Linux-API, und diese wird dann entsprechend mit einem Treiber kommunizieren. Nicht? Also, klär mich auf.

€dit: Womit wird das UEFI geschrieben? Ass...

Gerade gegooglet, wird anscheinend größtenteils in C geschrieben.
Ich kenne nix, was größtenteils in Assembler geschrieben wird. Ich kenne das nur an Stellen, welche sehr oft aufgerufen werden und es sich noch lohnt, die Sache "manuell" selber zu optimieren. Sicher wird es noch Sonderfälle geben, wo Assembler einen Großteil der Programmierung ausmacht, die Sonderfälle kenne ich aber nicht.

 

[KingCandy]

Der 32 Kerner ist schon ein ziemliches Monster, aber mir wird bei dem Stromverbrauch gleich direkt schumrig XD ... Ohne Fusionsreaktor wirds nichts mit der gesitteten Stromrechnung. Vorallem wenn man den auf 4 GHz laufen lässt, da kann man sich gleich ein 1400 Watt Netzknecht noch dazubestellen, wenn da noch ne Titan V im Doppelpack oder Ähnliches mitrennt. Und wer sich dann noch zwei Vegas reindübelt, muss schon eine stabile Stromleitung besitzen XD

 

[Phantomias88]

Sorry, aber die Äußerungen von Dir lassen durchblicken, dass Du von Softwareentwicklung im Allgemeinen und von Systementwicklung im Besonderen keinerlei Ahnung hast.

Ich kann inzwischen auf mehr Beta Versionen zurückgreifen, als es der Gesetzgeber kann.

Bypass, eben (own-flat)

 

[jdl]

Der 32 Kerner ist schon ein ziemliches Monster, aber mir wird bei dem Stromverbrauch gleich direkt schumrig XD ...

Es ist keine CPU für den Heimgebrauch, und daher ist wichtiger: "Wie viel Performance pro Watt gibt es?"

 

[pclovely]

Wahrscheinlich verwendet AMD bei der UMA Einstellung einfach Memory Interleaving als Standardvorgabe im BIOS. Man kann das zumindest unter Linux auch über Software erreichen, wenn die Applikation spezielle NUMA-Libraries nutzt.

Das Node Interleaving und dessen Aufteilung in Pages haben sie wahrscheinlich vom Opteron geerbt. AMD arbeitet dabei eng mit Entwicklern von Linux zusammen. Wie man unter Linux sieht ist der 2990wx deutlich schneller unterwegs.

 

[Goderion]

Ich kann inzwischen auf mehr Beta Versionen zurückgreifen, als es der Gesetzgeber kann.

Kann mir irgendwer erklären, wir er das meint?
Was für Beta Versionen?
Gesetzgeber?

Bypass, eben (own-flat)

Du umgehst deine eigene Wohnung?
Rück wenigstens einen Link raus, wo man irgendwas darüber lesen kann, wovon du sprichst.

 

[Phantomias88]

Kann mir irgendwer erklären, wen er damit meint?
Was für Beta Versionen?
Geseztgeber? Land?
Richter?
Du umgehst deine eigene Wohnung?
Rück wenigstens einen Link raus, wo man irgendwas darüber lesen kann, wovon du sprichst.

Wenn es sein muss!?

 

[Goderion]

Wenn es sein muss!?

... und das Spiel geht weiter. Solange Du dich hier nicht vernünftig erklärst und deine Aussagen irgendwie erläuterst, muss ich annehmen, dass Du nur ein Troll bist, der sich einen Spaß daraus macht, die Leute hier zu ärgern.

 

[BessereHälfte]

@Goderion
Verstehe die Vorwürfe nicht. Du weißt schon was nötig ist, damit Trollen funktioniert?

Gegen Assembler spricht übrigens nie etwas. Man muß nur meist leider eigene Ideen haben um zu überblicken was passiert, wenn es über eine bestimmte Größe geht. Udn ab einer bestimmten größe wirds halt schwierig...

"Wie Softwareentwicklung funktioniert" hat hier vor einer Weile DragonTear zu erklären versucht. Hexcode hat sich auch kurz daran versucht. War nicht so gut
Neuer WPA3-Standard soll WLAN-Netzwerke zukünftig sicherer machen

Da wünscht mal sich recht schnell, daß echt nur Leute Software schreiben die Asm blicken...

 

[Holt]

@Holt
Und die HAL ist keine Software die Treiber beinhaltet, von wegen LowLewel Hardwarezugriff?

Auch wenn du mir versichert hast kein Bot zu sein, benimmst du noch immer so und holst irgendwelche Begriffe hervor, die in keinem Zusammenhang stehen. Ich werde daher nicht weiter darauf eingehen und will auch keine Grundlagen von Betriebssystemen diskutieren. Goderion hat es recht passenden zusammengefasst:

Programm -> API/Kernel -> Treiber -> Hardware

Natürlich gibt es Ausnahmen, etwa Treiber die direkt im Kernel sitzen, aber dies geht ebenso am Thema vorbei wie eine Diskussion um Details von Task Schedulern, wobei ein ordentlicher Task Scheduler einen Task auch suspendieren sollte, wenn er sowieso warten müsste.

Wie man unter Linux sieht ist der 2990wx deutlich schneller unterwegs.

Das kann man nur anhand gleicher Software und Testdaten wirklich vergleichen und hier bei phoronix hat der 2990WX bei Blender 2.79a mit dem bmw27 Test 78,54s gebraucht und der i9 7980XE 115,67s:


Unter Linux hat der 2990WX also 67,9% der Zeit gebraucht die es mit dem 7980XE gedauert hat.

Bei Anandtech hat der 2990WX unter Windows mit Blender 2.79b den bmw27 Test in 96s gebraucht und der 7980XE 152s:


Unter Windows hat der 2990WX also sogar nur 63,2% der Zeit des 7980XE benötigt, war also relativ zum 7980XE noch schneller als unter Windows, auch wenn beide unter Linux deutlich schneller als unter Windows waren, denn beim AMD hat es unter Windows 22,2% länger gedauert als unter Linux und beim Intel eben sogar um 31,4%

Allerdings waren die Setups in den Reviews auch unterschiedlich, so wurde von phoronix unter Linux eine schnelle Optane und 3200er RAM verwendet:

For benchmarking each of the systems had 32GB of memory (in each platform's respective maximum number of supported memory channels, DDR4-3200 frequency) and a 280GB Intel Optane 900P NVMe SSD

Bei Anandtech wurde wurde 4x8GB 2933er RAM und eine relativ lahme Crucial MX300 1TB SATA SSD verwendet. Intel hatte auf der Computex 2016 eine Demo mit Blender gezeigt wie viel dier Optane SSDs dabei bringen können:

The Computex demo was more of the same, as the company measured the render time of a fluid dynamics video. The scale of the rendering was impressive. It consisted of 1.1 billion particles and presented itself as a swirl of water that lasted only seven seconds. Surprisingly, Intel indicated that it required 35 hours to render the short clip with a computer sporting "the world's fastest PCIe SSD," which one would assume is an Intel DC P3608.

Intel presented a time-lapse of the rendering process, and the competing 3D XPoint-infused computer was able to render the same video in a mere 9 hours,

Man kann also die Ergebnisse zwischen Windows und Linux nicht unbedingt vergleichen, aber vielleicht kommen ja auch von Anandtech noch Ergebnisse unter Linux. Den 7980XE hat Anandtech mit einer MX200 1TB und 4x8GB 2666er RAM gebencht, phoronix den 7980XE mit "4 x 4GB DDR4-3200 Corsair memory, Corsair 240GB Force MP500 NVMe SSD", also mit nur halb so viel RAM wie den 2990WX und mit einer langsameren SSD.

 

[Goderion]

Verstehe die Vorwürfe nicht.

Welche Vorwürfe?

Du weißt schon was nötig ist, damit Trollen funktioniert?

Ja, aber bei der hohen Anzahl von Beiträgen habe ich noch die Hoffnung, dass da mal was "Vernünftiges" rüberkommt und er sich erklärt.

Gegen Assembler spricht übrigens nie etwas.

Ich lehne mich mal aus dem Fenster und behaupte, dass bei 99,999% der Dinge auf der Welt, die programmiert werden, Assembler bereits bei der Kosten-Nutzen-Analyse vom Tisch ist. Jede Programmiersprache hat ihre Vor -und Nachteile. Assembler ist meistens viel zu aufwändig und die Vorteile werden einfach nicht gebraucht. Assembler ist mir bis jetzt immer nur an wichtigen/kritischen Stellen begegnet, wo die Performance besonders wichtig ist.

Man muß nur meist leider eigene Ideen haben um zu überblicken was passiert, wenn es über eine bestimmte Größe geht.

Wie ist das gemeint? Welche eigenen Ideen sollen dabei helfen, Assembler besser überblicken zu können? Ich selber programmiere nur sehr sehr wenig in Assembler und dann direkt in Visual Studio. Ich weiß nicht, wie Leute programmieren, die nur oder größtenteils in Assembler entwickeln, aber da wird es doch auch sicher Entwicklungsumgebungen für geben, die einem helfen, den Überblick nicht zu verlieren.

Udn ab einer bestimmten größe wirds halt schwierig...

Das gilt für jede Programmiersprache. Ich weiß leider nicht, wie große Projekte, die in Assembler geschrieben sind, organisiert werden. Assembler ist ohne Tools/IDE anstrengender zu lesen als C/C++, das ist klar. Beim Debuggen in Assembler muss ich schon mein Hirn ordentlich quälen, um nicht den Faden zu verlieren. C/C++ liest sich im Vergleich dazu wie ein Kinderbuch.

"Wie Softwareentwicklung funktioniert" hat hier vor einer Weile DragonTear zu erklären versucht. Hexcode hat sich auch kurz daran versucht. War nicht so gut
Neuer WPA3-Standard soll WLAN-Netzwerke zukünftig sicherer machen

Hier kann ich nur rätseln, in welchen Kontext ich das stellen soll. Softwareentwicklung "funktioniert" überall anders, so sind zumindest meine Erfahrungen.

Da wünscht mal sich recht schnell, daß echt nur Leute Software schreiben die Asm blicken...

Was soll ein Java-Entwickler mit Assembler? Wie schon zuvor gesagt, glaube ich, dass bei 99,999% der Softwareentwicklung Assembler absolut keine Rolle spielt und das Wissen darüber auch keinen Nutzen hätte. Die wenigsten Entwickler, selbst wenn sie etwas in C/C++ programmieren, debuggen mit der Assembler-Ansicht, wozu auch? Ich mache das selber nur aus Neugier oder z.B. für Reverse Engineering, wenn ich den Quellcode nicht einsehen kann.

Hinweis: Das meiste was ich hier schreibe, stammt aus persönlichen Erfahrungen oder was man als Programmierer so über die Jahre halt "mitkriegt". Fachliteratur oder Ähnliches z.B. zu "Nutzen und Verbreitung von Assembler" habe ich nicht gelesen. Von daher, wenn ich hier Quark erzähle, immer raus damit. ;-)

 

[Pickebuh]

Der 32 Kerner ist schon ein ziemliches Monster, aber mir wird bei dem Stromverbrauch gleich direkt schumrig XD ... Ohne Fusionsreaktor wirds nichts mit der gesitteten Stromrechnung.

Oberflächlich betrachtet stimmt dies sogar.
Aber schaut man sich mal das Performance pro Watt Verhältnis an, so spart man sogar Stromkosten.
Die KW/h ist eine Zeiteinheit und daher muss man auch die Zeitersparnis bei solchen Rechnungen mit einkalkulieren.
Der 2990WX verbraucht im Schnitt etwa doppelt soviel wie ein 2700X, ist aber bei manchen Anwendungen 2,5-3 mal so schnell und dies noch bei unoptimierter Software.

Natürlich kann man mehr verbrauchen wenn man möchte, aber rein von der standardisierten Arbeitsleistung her, ist so ein 2990WX oder ein 2950X ein echtes Sparschwein.