Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchfĂŒhren oder einen alternativen Browser verwenden.
NewsThreadripper Pro 9000: 96 Zen-5-Kerne mit bis zu 5,4 GHz kosten 11.699 US-Dollar
Schenken sich beide eigentlich selbstverstĂ€ndlich ĂŒberhaupt nichts, wenn sie in eine gewisse Monopolstellung kommen - auch wenn hier viele (warum auch immer) denken AMD wĂ€re die Wohlfahrt
Aber nein Ăberraschung es sind gewinnorientierte, börsennotierte Unternehmen die Konkurrenz brauchen âŠ
ErgÀnzung ()
freekymachine schrieb:
1699 Dollar fĂŒr den 9755WX find ich eigentlich ziehmlich gut
â1.700⏠fĂŒr einen 16-Kerner find ich eigentlich ziehmlich (?) gutâ - kann man sich nicht ausdenken, Anleger erfreuen sich an solchen Aussagen
Den Preis der 5090 finden natĂŒrlich alle auch âziehmlichâ gut - selbe Situation, selber Aufschlag
ErgÀnzung ()
S.Kara schrieb:
Z.B. Server von gut genutzten Webseiten. Jeder User verbraucht CPU-Leistung auf dem Server, das skaliert sehr gut. Oder Virtualisierungen.
Ich wieder mich eher ĂŒber eine zehn 5 + RDNA 4 APU mit 3D Cache freuen. Denke die Nische ist auch vorhanden. Aber wahrscheinlich bleibt das weniger Geld liegen.
Hab beim letzten Wechsel (ist schon einige Zeit her) von 8 auf 32 Kerne und von 128 auf 256GB RAM eine Zeitersparnis von 120% eingefahren. Das macht sich dann bei einer Query die vorher ca. 4h lief echt bemerkbar.
Eine Zeitersparnis von mehr als 100% ist mit unserer Technik aktuell gar nicht möglich. Selbst 100% sind nicht zu erreichen. Bei 4h und einer Ersparnis von 120% hÀttest Du das Ergebnis ca 50 Minuten bevor du es gestartet hast.
z.B.:
Eine Maschine die 100% schneller ist hat eine 50% Ersparnis.
Bei einer Zeitersparnis von 50% wÀre eine 4h Aufgabe in 2h fertig.
Bei einer Zeitersparnis von 100% hast Du das Ergebnis in dem Moment wenn man sie Startet.
Egal jetzt.
Auslasten von so einem Teil ist eine Sache fĂŒr sich. Es gibt immer wieder Software die viele Kerne benötig. Allerdings wurde etliche Software angepasst das es die GPU statt CPU nutzt wenn viele Kerne/Rechenleistung benötigt wird.
Allerdings gibt es etliche Software (z.B. UltraFraktal und deepzoom) die nicht auf GPU lÀuft. Oder h.264/h.265 in bester QualitÀt.
Gibt auch Spiele wie cities skylines 2 die bei vielen Einwohnern extrem CPU-Lastig werden. Hab mal zufÀllig ein youtub gesehen da hat es einer auf einem 96-kerner laufen lassen. Wurde glaub nur 64 Kerne+SMT ausgelastet.
@Inxession Der groĂe unterschied zwischen Epyc und Threadripper sind die hohen Taktraten auf einzelnen Kernen.
Photoshop ist auch so ein Kerne KrĂŒppel. Es gibt etliche Funktionen die nur auf einem Kern laufen und es profitiert unwahrscheinlich von diesem hohen boost von bis zu 5,4 GHz. Dann gibt es wieder Funktionen die nutzen fast alles aus was da ist.
Das meiste an Software hat leider mit schon mehr als 32 Kernen Problemchen unter Windows bis auf ein paar Ausnahmen. LÀsst sich aber entweder durch parallele Prozesse oder Linux recht gut umgehen. Selbst mit dem 64er aus der 3000er Serie hatte ich da schon manchmal zu kÀmpfen aber das ist nicht mit dem aktuellen zu vergleichen.
Die Overclocking Funktionen vom TR vs Epyc sind nicht zu verachten, da geht so einiges unabhÀngig vom AMD eigenen Boost.
Dann kennst du keinen Entwickler der in komplexen verteilten Systemen arbeitet wo es auch mal nötig sein kann lokal mehrere Services virualisiert in Testumgebungen inkl. DBs und Co laufen zu lassen.
TestServer welche fĂŒr einen Pull-Request automatisiert ganze Environments hochziehen um isoliert Regression-Tests auszufĂŒhren die Stunden dauern können, sich bei Erfolg zurĂŒcksetzen Datenseitig und ein Basisszenario bereitstellen fĂŒrs Manuelle Testing... profitiert extrem von einer richtig schnellen Kiste mit viel RAM.
All das Profitiert von vielen Kernen sowohl Lokal als auch in der Selfhosted Cloud Umgebung.
Hat man die Leute hat, die solche Systeme sicher aufbauen können und einmal aufsetzen und maintainen, kann sich das auch sehr schnell monetĂ€r gegenĂŒber der "Cloud" und "Fertigsystemen" wie Azure DevOps oder GitLab rechnen. Der Kostenvergleich eines richtig fetten Hetzner-Servers inkl. Full-Fallback in Finland oder so... Peanuts verglichen mit den Preisen in Azure. Und wer mal einen eigenen Beefy BuildAgent Cluster hatte, weiĂ wie gravierend der Unterschied ist. Schnell mal 1 Minute Wartezeit auf einen Build statt 15 Minuten und mehr. Und da liegt dann genau die Kohle vergraben.
Da werden einige noch aufwachen die nĂ€chsten Jahre. Die "Cloud" ist eine nette Idee und in manchen Szenarien auch gut um schnell einfach mal was hochzuziehen. Aber die Kosten werden immer mehr angezogen und gerade im Bereich Security explodieren die Kosten schnell ins Astronomische weil man oft fĂŒr ein einziges Feature das kritisch wĂ€re, im Enterprise Tier Level landet. Gerade Microsoft macht das schon geschickt... die Laufenden Kosten fĂŒr ein stark Skalierungs-bedĂŒrftiges System gehen da schnell komplett durch die Decke.
Dann kennst du keinen Entwickler der in komplexen verteilten Systemen arbeitet wo es auch mal nötig sein kann lokal mehrere Services virualisiert in Testumgebungen inkl. DBs und Co laufen zu lassen.
Wenn ich meine Monsterqueries gegen bestimmte Datenbanken abfeuere, begrĂŒĂe ich jeden zusĂ€tzlichen Kern mit Freude. Klar, RAM und dessen Anbindung ist auch enorm wichtig, aber CPU ist wie Oktan im Benzin wobei RAM der Hubraum ist.
Machst du permanent, 8 Stunden jeden Tag, die Monsterqueries? (was auch immer das fĂŒr eine DB sein soll)
DafĂŒr dann >12000 ⏠ausgeben? Da muss man schon sehr viele Monsterqueries haben.
Und wie gesagt, fĂŒr Serveranwendungen, darunter fallen fĂŒr mich Datenbanken, sehe ich das ja absolut ein, aber dafĂŒr gibt es Server-Systeme/CPUs mit entsprechend fetter RAM-Anbindung.
ErgÀnzung ()
7hyrael schrieb:
Dann kennst du keinen Entwickler der in komplexen verteilten Systemen arbeitet wo es auch mal nötig sein kann lokal mehrere Services virualisiert in Testumgebungen inkl. DBs und Co laufen zu lassen.
Ich habe 3 - 4 VM laufen, dazu dutzende Docker-Container und 3 Datenbank-Systeme.
Geht alles 1A mit 8 Kernen/16 Threads.
Welche "heavy" Anwendungen sollen dass denn bitte beim Entwickeln sein, die permanent etwas wie 96 Kerne auslasten sollten? Im Normalfall kompiliert man ein gesamtes Projekt ja auch nicht permanent neu, sondern nur die geĂ€nderten Teile. Komplett neu "from scratch" dauert es natĂŒrlich schon lĂ€nger, aber das sind doch Jobs, die man gut ĂŒber Nacht laufen lassen kann, oder auf dem Deploy-/Staging-System.
Die Auslastung geht hier und da mal kurzfristig hoch, aber ich bin Meilenweit von permanenter 8-stĂŒndiger Auslastung pro Tag entfernt.
Und wenn man permanent so etwas braucht, dann macht es doch mehr Sinn, dass auf einem entsprechenden Staging-Serversystem laufen zu lassen, dann ist man auch noch nÀher am Produktivsystem dran.
ErgÀnzung ()
HardRockDude schrieb:
FĂŒr hardcore professionelle Umgebungen. Denk dabei an 8K 60-120fps Videos/Filme, und nicht nur Schnitt und Editing, sondern Effektbearbeitung o.Ă€. Das braucht richtig fett Leistung, wenn man in Echtzeit arbeiten will.
Wenn du dein System nach "permanent Ausgelastet" konfigurierst machst du doch schon was falsch?
Es sollte deine Workload den du die meiste Zeit hast locker packen und idealerweise min. 40% headroom haben, fĂŒr wenn mal mehr als ĂŒblich gebraucht wird oder um halbwegs zukunftssicher zu sein.
Ich hab auch nicht behauptet dass es 96 Kerne braucht, nur dass ich 16 Kerne je nach Aufgabenbereich schon als zu Eng kalkuliert empfinde.
Ich hab oft mit Legacy-Applikationen zu tun, wo es schon mal vorkommen kann dass ich auch div. alte Windows-Systeme vollstÀndig lokal virtualisiere und die Fressen schnell einfach viel Speicher und auch gern CPU. Da bin ich froh hab ich genug reserven.
Will ich einen umfassenden Test vom gesamtsystem machen reden wir da schnell von 20 Docker Instanzen + 4-5 VMs die simultan aufgestartet werden mĂŒssen. Das Notebook das ich hier mal zu beginn bekommen hab kam da komplett an seine Kotzgrenze.
ErgÀnzung ()
Spriti schrieb:
Und wenn man permanent so etwas braucht, dann macht es doch mehr Sinn, dass auf einem entsprechenden Staging-Serversystem laufen zu lassen, dann ist man auch noch nÀher am Produktivsystem dran.
Da bin ich voll bei dir, im Idealfall hat ein entwickler gar keine Notwendigkeit an ein lokales Testsystem. Aber soweit sind die wenigsten Unternehmen in ihrer Infrastruktur, dass jeder Entwickler eine eigene Staging-Umgebung erhÀlt, um zu vermeiden dass man durch gegenseitige Side-effects sich im weg steht.
Da haperts bei ganz vielen schon dran kein brauchbares Seeding fĂŒr eine Testumgebung auf Knopfdruck bereitstehen zu haben. Schon gar nicht wenn die Systeme Kundenspezifisch konfigurierbar sind und du in ganz unterschiedlichen Szenarien testen mĂŒsstest... Leider sehen auch zu viele Unternehmen das Testing noch immer als Notwendiges Ăbel... Und nicht das Potential im Invest in richtig gut getestete Applikationen -> nix hindert an der Weiterentwicklung mehr als eine Zero-Trust-Situation in die Test. Da traut sich keiner mehr was anzufassen, weil man nie weiss obs am Ende direkt knallt.
FĂŒr Unternehmen/ĂD die haben mehren Server unter mehren VMS. FrĂŒher brauchst du zb 16 Server hier nur eine. 12000$ ist viel Geld plus entsprechende RAM aber billger als zb 16 Server @5000$ .
Daher Fortschritt ist es schon meistens bremsen schon die LAN Verbindungen (ausser mit Teueren 10GBIT LAN Komponenten) aber ich sehe schon manche Server Admins da am Grinsen mit 96 Kernen
Wenn ich fĂŒr jedes Mal, wo jemand Threadripper und Server in einem Kontext meint, einen Euro bekĂ€me, wĂ€re ich reich. Nochmal fĂŒr alle zum Mitschreiben: Server ist Epyc. Threadripper nix Server.
Ist so eine Rechnung intelligent?
Cache, Lanes, I/O Die, mehr Materialien, kleiner Markt, ExklusivitÀt. Insofern beantworte ich die Frage selber. Nein.
Ist so eine Rechnung intelligent?
Cache, Lanes, I/O Die, mehr Materialien, kleiner Markt, ExklusivitÀt. Insofern beantworte ich die Frage selber. Nein.
Die Rechnung ist zumindest interessant. Cache skaliert mit den Cores, der IOD skaliert sogar weniger als die Cores, PCIe-Lanes und RAM-Channel ebenfalls. Man zahlt bei Threadripper vergleichen mit Ryzen also pro Core mehr, obwohl man pro Core weniger "drum herum" bekommt. Kleiner Markt und ExklusivitĂ€t sind dann halt die GrĂŒnde dafĂŒr.
Einen Threadripper Pro mit 32 Kernen kann man im Betrieb gut fĂŒr Simulationen (FEM) benutzen. Man lĂ€sst meistens zwei kleinere Simulationen zu je 16 Kernen parallel laufen. Bei gröĂeren Simulationen mĂŒssen andere Simulationen zurĂŒckgestellt werden und es lĂ€uft dann die eine groĂe Simulation auf 32 Kernen. Vor dem Threadripper Pro musste man bei diesen gröĂeren Simulation eine Woche auf das Ergebniss warten. Wenn dann das Ergebnis nicht zufriedenstellend war und man was optimieren musste, gingen mit mehreren Iterationen Wochen ins Land. Man wurde nervös, dass man die Meilensteine nicht schaft. Andere Projekte verzögerten sich auch, weil die Simulatonsmaschine Wochenlang belegt war... Das waren gute Argumente fĂŒr den Kauf der neuen Workstation mit dem Threadripper Pro.
Da kannst du dir aber besser den dicken EPYC hinstellen oder besser gleich 4 DualSocket. Damit hast du dann paar hundert Kerne.
Lohnt sich bei viel Kommerzielle Software auch von den Lizenzen her, da die parallelen core Lizenzen deutlich gĂŒnstiger als die SouverĂ€nitĂ€t Lizenzen sind.
WĂ€re im Budget nicht drin und wĂ€re auch Overkill mit DualSocket und hunderten Kernen. Da die Lizenzen an die Kernzahl gebunden sind, wĂŒrden auch die Lizenzen bei 100 Cores steigen. 32 Kerne mit X3D-Cache wĂ€ren da besser gewesen, gab es aber nicht, also 32 Kerne mit maximal Takt war die Lösung.
Skysnake schrieb:
Lohnt sich bei viel Kommerzielle Software auch von den Lizenzen her, da die parallelen core Lizenzen deutlich gĂŒnstiger als die SouverĂ€nitĂ€t Lizenzen sind.
Wir haben Core Lizens. Auf der Workstation können mehre Mitarbeiter aus dem Netzwerk heraus ihre Simulationen starten. MĂŒssen sich halt nur absprechen, wenn es mehr als 2 Jobs oder ein groĂer Job auf einmal laufen soll... Die Workstation steht sogar im Serverraum (und darf dort laut sein) und nicht unterm Tisch, wie man das von einer Workstation vielleicht erwarten wĂŒrde...
Habe ich verstanden. Danke!
War auch ein Versehen da ich damit eigentlich eine Verringerung der Laufzeit von 60% implizieren wollte, aber voll gegen die Wand gelaufen bin.
⊠quasi von 4h auf ~1:45h.
