News Gigabyte ThunderXStation: Bis zu 108 ARMv8-Kerne in einem Desktop-Gehäuse

[Volker]

Gigabyte hat in dieser Woche sein Portfolio an ARM-Server-Lösungen ausgebaut. Mit der ThunderXStation kommt nun aber kein klassisches 1U-, 2U oder 3U-Gehäuse zum Einsatz, sondern ein klassisches PC-Gehäuse, wie es aus dem Desktop-Umfeld bekannt ist. Darin werden maximal zwei Prozessoren Platz finden.

Zur News: Gigabyte ThunderXStation: Bis zu 108 ARMv8-Kerne in einem Desktop-Gehäuse

 

[Postman]

Egal wie viele Kerne sie noch ansteuerbar machen, es ist alles witzlos wenn die Anwendungen das nicht unterstützen. Mehrkernprogrammierung ist oft aufwendiger, weshalb gerne daran gespart wird.

 

[Bully|Ossi]

ARM ist da wohl flexibel, sieht man ja bei den Smartphones. Ich bin da zwar kein Fachmann, aber das kann man wohl nicht mit X86 vergleichen.

 

[Qarrr³]

Es gibt genug Server-Software, die hervorragend mit vielen Kernen skaliert.

 

[hroessler]

ARM ist da wohl flexibel, sieht man ja bei den Smartphones. Ich bin da zwar kein Fachmann, aber das kann man wohl nicht mit X86 vergleichen.

Es ist vollkommem bumms welche Architektur darunter steckt, die Probleme bleiben die selben. Das Problem dabei ist ja nicht die CPU, sondern dass viele Programmiersprachen Multithreading bis heute nicht galant ausdrücken bzw. lösen können. Es gibt zwar Fortschritte (z.B. das Asyc-Await Pattern, und die vielen nützlichen Features aus den Funktionalen Programmiersprachen die nun nach und nach in die Mainstreamsprachen wandern), aber selbst damit bleibt der Aufwand für Multithreadung höher als bei der Singlethreaded programmierung.

greetz
​hroessler

Ergänzung (24. März 2018)

@Qarrr3: Das ist korrekt. Diese Software wurde entsprechend optimiert, kostet aber auch entsprechend Geld. Im Mainstream bezahlt dir diese Summen niemand...

greetz
​hroessler

 

[Gorby]

Da hast du nicht unrecht, aber im Mainstream braucht auch keiner einen Server mit 108 ARMv8-Kernen

 

[hroessler]

@Gorby: Aktuell sicher nicht, aber ich habe da was im Ohr, was mit 640 KByte zu tun hat.

Und die Diskussion bezog sich ja rein auf die optimierung von Anwendungen auf Multithreading, nicht auf die vorgestellte Maschine selbst. 6 - 8 Kerne bzw. 12 - 16 Threads kommen jetzt ja dank Ryzen und Coffee Lake in den Mainstream. Da wird das Thema schon interessant...

greetz
​hroessler

 

[Gorby]

Ja ich bin echt mal gespannt, wann ich wirklich sagen kann "mein alter Quad Core reicht nicht mehr". Denn es ist immer noch mehr oder weniger ein "haben will", als ein "brauch" bei mir

 

[hroessler]

Glaubst du mein PC war ein Vernunftkauf?

greetz
​hroessler

 

[latexdoll]

But Can It Run Crysis?

 

[Ko3nich]

Wieder ein Server Thema bei dem über schlecht skalierende Client Software gejammert wird ohne die Zielgruppe zu kennen.

Dass man in Programmiersprachen nicht einfach Teile Multi Thread fähig machen könnte ist auch bullshit.

 

[[F]L4SH]

Kann jemand mit Einsicht in den Bereich mal kurz anreißen, was man mit diesem Produkt an sich macht?
Klar - die Server in Racks mögen als Nischenlösung für Storage und Webserver noch gut funktionieren aber was genau macht man in diesem Workstation Formfactor damit? Softwareentwicklung?

 

[Hopsekäse]

Egal wie viele Kerne sie noch ansteuerbar machen, es ist alles witzlos wenn die Anwendungen das nicht unterstützen. Mehrkernprogrammierung ist oft aufwendiger, weshalb gerne daran gespart wird.

Das ist in diesen Bereichen sowas von irrelevant... Das ist ein Problem im privaten und semi-professionellen Bereich, wo man sich ein System kauft und dann muss da mal Software X, mal Y usw. laufen.
Wer so ein Spezial-Gerät kauft weiß ganz genau, dass er die Software dafür hat...

Kann jemand mit Einsicht in den Bereich mal kurz anreißen, was man mit diesem Produkt an sich macht?

Ich habe ein wenig Einblick in den HPC-Bereich. Da bieten auch immer mehr Anbieter ARM-Nodes an. Wozu weiß ich aber tatsächlich auch nicht. Potentiell wäre alles interessant, was an der Speicherbandbreite und weniger an der Rechenleistung hängt. Wobei die nicht wirklich viel höher ist als bei normalen x86-CPUs. Hexa- und Octa-Channel kriegt man ja auch dort.

Mein bisheriger Eindruck war eher, dass man damit ganz gut auf Speicherbandbreite und Speichermenge spezialisierte Systeme bauen kann, die etwas günstiger sind. Man kriegt ähnliche Bandbreiten und Speichermengen auch mit x86 hin, hat dann aber idR auch viel mehr Rechenleistung, die man womöglich gar nicht braucht, und bezahlt dafür ein gutes Stück mehr.

Ausprobieren konnte ich da selbst auch noch nicht so viel. Wir zwar haben ein Testsystem mit zwei ThunderX (der Vorgänger ohne die "2"). Aber so richtig Szenarien wo ich mir sage "Ha! Das schmeiß ich auf das ARM-Teil!" habe ich noch nicht gehabt.
Auf AnandTech gibt es zum ersten ThunderX einen ganz interessanten Artikel. Ein so richtig schlüssiges Workload-Profil kriege ich damit aber auch nicht zusammen.

Ansonsten wird auf Workstations halt oft "Ähnliches" gerechnet wie auf HPC-Maschinen, bloß "in klein".
Da unsere Haupt-Maschinen keine ARMe haben (haha), kann ich aber auch nicht sagen, was genau denn so für Codes auf ARM-Compute-Nodes geworfen werden.

 

[amdfanuwe]

Anwendung z.B. Messdatenerfassung bzw Steuerung.
Im letzten Projekt sollten Daten von ca. 100 Geräten, die über Ethernet angebunden waren, erfasst werden.
Also für jedes Gerät einen Thread angelegt der auf den entsprechenden Kanal lauscht... und der 4C8T Intel Server war hauptsächlich mit Threadswitching beschäftigt. Also wieder sequentiell programmieren mit wenigen Arbeitsthreads.
Auf einer 100C CPU hätten wir das Problem nicht gehabt.

Programmierung unter QT. Wenn man es verstanden hat, ist es einfach Threads anzulegen. Wenn nicht, denkt man, man hat viele Threads die in wirklichkeit aber doch nur in einem laufen.
Mit Go Lang von Google ist die Threadprogrammierung wesentlich einfacher und intuitiver.

Und noch ein kleines Beispiel zur Parallelisierung: 1 Frau braucht 9 Monate für ein Kind. Wie lange brauchen 10 Frauen für ein Kind?
Wenn man einen Kindergarten voll kriegen will, ist es natürlich nützlicher mehrere Frauen mit der Aufgabe zu betrauen. Die Durchlaufzeit bleibt aber immer ca. 9 Monate pro Kind.

 

[dMopp]

....

Und noch ein kleines Beispiel zur Parallelisierung: 1 Frau braucht 9 Monate für ein Kind. Wie lange brauchen 10 Frauen für ein Kind?
Wenn man einen Kindergarten voll kriegen will, ist es natürlich nützlicher mehrere Frauen mit der Aufgabe zu betrauen. Die Durchlaufzeit bleibt aber immer ca. 9 Monate pro Kind.

Bei deinem Beispiel wird der Product Owner, CTO und Sales behaupten, 1 Monat pro Kind bei 9 Frauen... Und die Entwickler zwingen das so um zu setzten! Traurige Realität

 

[Haxor]

Dass man in Programmiersprachen nicht einfach Teile Multi Thread fähig machen könnte ist auch bullshit.

Wenn man ausschließlich mit Prozessen und Threads arbeitet ist das oft schon relativ aufwendig, weil sich die meisten Anwendungen für den Entwickler nur schwer mit diesen Methoden parallelisieren lassen. Zum Glück gibts da auch andere Ansätze wie das Aktorenmodell, womit man praktisch "unendlich" bzw. auf unbegrenzt viele Kerne skalieren kann. Grenzen hat das ganze aber dann doch noch im Speicherverbrauch und der höheren Latenz. Also auch nicht für jeden Anwendungsfall Ideal. Ich denke, dass die zukünftigen Compiler mehr in Richtung Parallelisierung entwickelt werden und der einzelne Entwickler muss sich dann weniger mit dieser "Thematik" auseinandersetzen.

 

[hroessler]

Wieder ein Server Thema bei dem über schlecht skalierende Client Software gejammert wird ohne die Zielgruppe zu kennen.

Dass man in Programmiersprachen nicht einfach Teile Multi Thread fähig machen könnte ist auch bullshit.

Richtig, genau deshalb wird es ja kaum gemacht. LOL

greetz
​hroessler

Ergänzung (24. März 2018)

Wenn man ausschließlich mit Prozessen und Threads arbeitet ist das oft schon relativ aufwendig, weil sich die meisten Anwendungen für den Entwickler nur schwer mit diesen Methoden parallelisieren lassen. Zum Glück gibts da auch andere Ansätze wie das Aktorenmodell, womit man praktisch "unendlich" bzw. auf unbegrenzt viele Kerne skalieren kann. Grenzen hat das ganze aber dann doch noch im Speicherverbrauch und der höheren Latenz. Also auch nicht für jeden Anwendungsfall Ideal. Ich denke, dass die zukünftigen Compiler mehr in Richtung Parallelisierung entwickelt werden und der einzelne Entwickler muss sich dann weniger mit dieser "Thematik" auseinandersetzen.

Der Optimalfall ist der, dass der Entwickler sich gar nicht mehr um Threads kümmern muss, sondern das OS oder eine andere Middleware das automatisiert tut.

greetz
​hroessler

 

[Haxor]

Der Optimalfall ist der, dass der Entwickler sich gar nicht mehr um Threads kümmern muss, sondern das OS oder eine andere Middleware das automatisiert tut.

Ich denke auch dass es in eine solche Richtung gehen wird. Das Problem bleibt dann nur noch der Bereich, der schnelle Reaktionszeiten benötigt, da wirds denke ich auch in Zukunft keine ideale Lösung geben.

 

[Shelung]

Das denke ich mir auch. Der Programmiere sollte eine Schnittstelle haben auf die er zugreift welche sich um die Prozesslastverteilung kümmert.
​Das ganze aber so das es absolut frei Skalieren kann. Egal ob 2 oder 200 Threads, es wird immer optimal ausgewählt.

 

[Hallo32]

Threads sind schön aber sobald das Ziel ist mathematische Algorithmen zu parallelisieren, werden die Grenzen sehr schnell ersichtlich.
Ob Threads eine Lösung sind, hängt immer ganz von der Aufgabenstellung ab.
https://www.computerbase.de/2018-03/multi-core-cpu-games/