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

Volker

Ost 1
Teammitglied
Dabei seit
Juni 2001
Beiträge
14.298
#1
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
 
Dabei seit
Juni 2003
Beiträge
3.058
#2
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.
 
Dabei seit
Jan. 2009
Beiträge
3.851
#3
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.
 

hroessler

Lt. Commander
Dabei seit
Okt. 2013
Beiträge
1.554
#5
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 ()

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

greetz
​hroessler
 
Zuletzt bearbeitet:

hroessler

Lt. Commander
Dabei seit
Okt. 2013
Beiträge
1.554
#7
@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

Vice Admiral
Dabei seit
Juni 2008
Beiträge
6.617
#8
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 :D
 

hroessler

Lt. Commander
Dabei seit
Okt. 2013
Beiträge
1.554
#9
Glaubst du mein PC war ein Vernunftkauf? :p

greetz
​hroessler
 
Dabei seit
Jan. 2007
Beiträge
830
#10
But Can It Run Crysis? :)
 
Dabei seit
Juni 2017
Beiträge
240
#11
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.
 
Dabei seit
Aug. 2008
Beiträge
4.951
#12
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

Lt. Commander
Dabei seit
Apr. 2009
Beiträge
1.402
#13
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.
 
Zuletzt bearbeitet:
Dabei seit
Mai 2008
Beiträge
128
#14
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.
 
Dabei seit
März 2007
Beiträge
9.045
#15
....

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

Lt. Junior Grade
Dabei seit
Sep. 2008
Beiträge
388
#16
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

Lt. Commander
Dabei seit
Okt. 2013
Beiträge
1.554
#17
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 ()

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

Lt. Junior Grade
Dabei seit
Sep. 2008
Beiträge
388
#18
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.
 
Dabei seit
Jan. 2016
Beiträge
3.141
#19
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.
 
Top