News Sonoma: Oracles Low-Cost-SPARC-CPU mit acht Kernen und 64 Threads

[S.Kara]

Danke für die Antworten, aber scheint ja doch etwas kontrovers zu sein.

Dass die Anwendungen darauf ausgelegt werden müssen ist klar, auch dass es irgendwie einen Vorteil bringen können muss.
Es handelt sich bei der Zielgruppe ja nicht um irgendwelches Gamer, wo sich Kiddys durch sinnlose Zahlen beeindrucken lassen. Intel wird schon einen guten Grund für diesen Schritt haben.

Zwei physische Kerne werden aber immer schneller sein als nur ein Kern mit zwei Threads. Und mit steigender Anzahl der Threads pro Kern, muss auch der Performance-Anstieg pro Thread sinken. Gleichzeitig steigt aber auch die Leistungsaufnahme sowie der Aufwand für die Koordination. Irgendwo muss es also eine Grenze geben, ab der die Performance nicht mehr steigt, sondern eher wieder sinkt. Ich dachte eigentlich, dass 4-Way SMT schon das höchste der Gefühle darstellt. Aber wenn Intel nun meint dies verdoppeln zu müssen?

Kann man hier vielleicht in naher Zukunft auf einen Benchmark von CB hoffen? Oder interessieren sich hier einfach zu wenige dafür?
Wenn sich im HPC-Bereich 8 Threads pro Kern durchsetzen, kann man eigentlich davon ausgehen, dass wir im Consumerbereich irgendwann mal auf 4 Threads pro Kern stoßen werden.

 

[Piktogramm]

@S.Kara

Die ganze Multithreadgeschichte ist kompliziert und CB hat sehr schlechte Karten einen Test samt Artikel zu verfassen, der den typischen CB Leser (eher wenig Ahnung von komplexen Enterprise Anwendungen) mit genügend Vorwissen versorgt um danach auch nur ansatzweise verstehen zu können welche Aussagen die gefahrenen Tests zulassen. Vor allem weil es nicht nur die Hardware ist, auch die entsprechenden Kompiler spielen eine Rolle und die Ergebnisse streuen je nach Compiler Flags ganz erheblich. Einfach nur Standard Bench fahren hilft bei solcher Hardware nicht.
Was ja schon bei Haswell so, die Standard Bench Suites haben nahezu keinen Unterscheid* zur Vorgängergeneration aufgezeigt, hat man jedoch sowas wie Linpack mit AVX2 Unterstützung kompiliert gab es einen +70% Sprung im Vergleich zum Vorgänger. Bei den Xeon Phi wird es jedoch weit komplizierter als nur ein neuer Kompilerdurchlauf.
Wenn dich der Spaß wirklich interessiert, so gibt es da Artikel (auf English) bei Ars-Technica, mitunter bei Anandtech und in der c't vom Heise Verlag zzgl. der Präsentationsfolien von Intel zzgl. div. Wikipedia Artikel + dicke Bücher. Wirklich einfache Antworten gibt es da aber nicht und die Artikel der drei zuerst genannten Medien erfordern mitunter Vorwissen, damit der Kram verständlich wird.

Was die Steigerung der Effizienz durch Multithreading angeht, die beste Antwort ist da: "Es kommt drauf an".

Was den Bereich der Endkundenanwendungen angeht, die meisten Anwendungen bei Endkunden sind für massives Multithreading nicht prädestiniert. Bei Office Zeug gibt es auch bei großen Tabellen meist das Problem, dass einzelne Rechnungen erst ausgeführt werden können, wenn die Ergebnisse aus vorhergehenden Berechnungen vorliegen. Viele Probleme sind also teils parallelisierbar, in großen Stücken aber auch recht seriell. Bei seriellen Problemen bringt Multithreaded nix. Beim Webbrowsing und vielen Spielen ist es ähnlich. Videorendering machen mittlerweile eh spezialisierte Rechenwerke der GPU. Soviel aufwendiges Zeug bleibt beim Endkunden dann nicht mehr übrig und der Kram der übrig bleibt wartet meist darauf, dass für die Threads benötigte Ressourcen frei werden, wobei der Prozesssheduler des Betriebssystem da entsprechend der CPU Threads zuspielt die gerade auf keine Ressourcen warten und entsprechend arbeiten können, da lässt sich mit höherrangigem SMT meist nicht mehr viel hohlen.


*Bauernweisheit der IT: Alles was keine 15% Performance Differenz bringt ist egal