News Windows 7 mit HyperThreading-Verbesserungen?

[Suxxess]

Du meinst wohl eher, dass es für Anwendungen gedacht war, die auf Multicore optimiert waren. Dadurch, dass die HT Geschichte auch koordiniert werden musste hat es im schlechtesten Fall sogar Leistung gekostet.

Ausserdem muss man sehen:
Bei HT
Kern 1 Auslastung: 70%
Kern 2 Auslastung: 30% => 100% Leistung - Overhead

Bei Dualcore
Kern 1 Auslastung: 100%
Kern 2 Auslastung: 100% => 200% Leistung - Overhead

HT war damals teilweise sinnvoll, z.B. wenn sich ein Programm aufehängt hatte und man etwas Leistung brauchte um per Taskmanager das Programm zu beenden. Das war bei einem Kern der nicht mehr reagierte eine träge Angelegenheit, mit HT / dualcore wurde es dann besser da der andere Kern dann die Leistung aufbringen konnte um in den Taskmanager zu kommen.

Wenn ich AMD wäre würde ich den 1900er Sempron mit einem Kern gegen den Atom mit 4 (virtuellen) Kernen benchenmarken und die Ergebnisse werbewirksam vermarkten... (Der Atom hat trotz quasi 4 Kernen bei vielen Anwendungen keine Chance gegen den uralten Sempron.)

 

[BrollyLSSJ]

Ich hoffe, das bringt dann auch was bei aelteren Kisten, wie meinem P4 3.0 GHz, der ja auch HT hat.

 

[Blutschlumpf]

Wieso erst die physikalischen Kerne ? Zum Stromsparen würde ein echter Kern mit HT das Betriebssystem schon genügend "beschleunigen", die anderen Kerne könnten dann im Sparmodus bleiben, für die Mehrheit der Nutzer reicht das.

Versteh nicht was das bringen soll, dazu kannste dir auch nen DualCore kaufen, da sparste mehr und kommst trotzdem schneller weg als bei nem Quad der nur einen Kern + HTT nutzt
Lass den virtuellen Kern mal in Idealfall 10-20% mehr Performance bringen, die Wahrscheinlichkeit dass du das System mit deiner Methode ausbremst ist imo viel zu hoch.
btw, das OS brauchste nicht beschleunigen, das läuft auch mit einem Kern im EIST ohne HTT ganz locker.

 

[Realsmasher]

Wenn ein SingleCore Atom mit einem Thread allerdings voll ausgelastet ist (was immer der fall ist), dann hilft HT auch nix.

Hier befindet sich der Fehler in deiner Denkweise.

Eine cpu kann nämlich nicht eine Anweisung pro Takt und Kern ausführen sondern mehrere.

Der Atom schafft 2 pro Takt, ein A64/P4/usw schafft 3, ab dem Core 2 sogar 4 oder 5.


Du kannst also problemlos ein programm schreiben das pro Takt nur 1 Anweisung nutzen kann, weil etwa alle Anweisungen von der jeweils vorigen abhängig sind, dann hast du 100% cpu last, aber trotzdem ständig 50-75% freie Berechnungseinheiten.

Und genau DIE nutzt HT.


Das eine cpu die nur zu 80% Zeit unter Last steht noch 20% an andere Aufgaben verteilen kann ist Sache das Betriebssystems und hat mit HT rein garnichts zu tun.

 

[Limit]

Auf einem Atom oder generell auf SingleCores die Funktion zu implementieren find ich vollkommen sinnlos, da die meiste heute Software/BS Threading unterstützt. HT wird keine Rakete aus gering getakteten und am Anschlag laufende Prozessoren zu neuen Ufern führen.

SMT bringt bei voll ausgelasteten CPUs garnichts. Allerdings fehlen dem Atom viele Optimierungen, die die hohe Auslastung bei superskalaren CPUs überhaupt erst ermöglichen (Out of Order Execution z.B.). SMT ist was die Transistorzahl angeht sehr viel simpler zu implementieren als OoOE und die ganzen anderen Optimierungen die, die in der Core Architektur enthalten sind.

Falsch. HT hat nicht die Aufgabe zu "Teilen". Es soll nur die Prozessverarbeitung optimieren. Bedeutet, wenn eine Anwendung die 3Ghz eines Prozessors nicht voll auslasten, sondern nur 2Ghz, bekommen die restlichen Threads die übrigen 1Ghz.

Das ist höchstens ein Teilaspekt des Ganzen. Es geht in erster Linie darum die Auslastung der funktionalen Einheiten zu erhöhen (-> Superskalarität). Wenn man von Speicherzugriffen mal absieht, die meist vom Cache abgefangen werden, gibt es keinen Grund, warum ein Programm, dass mit 2GHz läuft, nicht auch mit 3GHz laufen kann. Es wäre dann einfach nur schneller fertig und würde sich anschließend beenden bzw. sich schlafen legen und auf neuen Input warten. Wenn du dir mal den Status der einzelnen Tasks anschaust, dann wirst du feststellen, dass die meisten Tasks die allermeiste Zeit damit verbringen zu schlafen (die ham doch ein schönes Leben ).

 

[Pitt_G.]

Seltsame Meldung mit der unterschwelligen Aussage, Leute kauft euch einen Core i7 dann seid Ihr bestens auf Windows 7 vorbereitet.
Aber erst die finale Windows 7 Version wird zeigen, obs stimmt oder nicht.

Und dann wieder dieser Titel der News. Klingt genauso wie

"Werden acht GByte Arbeitsspeicher Standard?"

Bin mal gespannt ob das auch wieder ins Aquarium wandert

 

[Sentionline]

Du kannst also problemlos ein programm schreiben das pro Takt nur 1 Anweisung nutzen kann, weil etwa alle Anweisungen von der jeweils vorigen abhängig sind, dann hast du 100% cpu last, aber trotzdem ständig 50-75% freie Berechnungseinheiten.

Und genau DIE nutzt HT.

Dann kommts drauf an wie gut die Sprungvorhersage arbeitet. Und die läuft nicht im BS, wird also auch nicht in Win7 drin sein, da solche zuweisungen zuviel hin und her beim Kernel sorgen würden. Run.dll lässt grüßen. Wenn aber mal die Vorhersage versagt, dann gehts in richtung "abwärts". Aufgabe von Intel isses insofern, diesen im Atom zu revolutionieren, damit es einen Performanceschub gibt.

Es geht in erster Linie darum die Auslastung der funktionalen Einheiten zu erhöhen (-> Superskalarität).

Dafür ist Cuda ja da. Das könn(t)en die ja implementieren.

Warten wir auf Larabee. Der hat 32Kerne mit je 2Ghz. Dann ist alles Skalar.

 

[andr_gin]

Kunden mit einem Lynnfield-Prozessor und Windows 7 als Betriebssystem sollen dann neben den vier realen Kernen auch die vier virtuellen Kerne effektiver nutzen können.

1.) Jetzt verbreitet sich dieser Schwachsinn auch schon unter den News Postern. Es gibt keine 4 physikalischen und virtuellen Kerne. Ein physikalischer Kern hat je zwei virtuelle Kerne, die absolut gleichberechtigt sind. Das war schon beim Pentium 4 so und ist jetzt nicht anders. Ist ja bei einem Dual Core genau das gleiche. Eine CPU, die im Sockel sitzt hat 2 Kerne, die völlig gleich sind. Es läuft auch auf keinem der 2 Kerne irgendetwas schneller.

2.) Es gibt mehrere Vorteile von Hyperthreading:
a) Es werden selten von einem Programm nur gleiche Operationen durchgeführt. Während ein Thread eine Addition durchführt, kann der andere eventuell eine Division durchführen
b) Es gibt Abhängigkeiten im Code. Teilweise lässt sich der Code parallelisieren z.B. e = a + b + c + d. Hier können a und b addiert werden, während c und d addiert werden. Bei Fließkommazahlen geht das z.B. aus Definition heraus nicht. bzw. wenn man c= a + b und a = b + c hat, dann kann man die Reiehenfolge nicht vertauschen.
c) Je mehr Operationen in einem Thread pro Takt durchgeführt werden, desto mehr Operationen stehen auch in der Pipeline, die z.B. 20 Stufen hat. Wenn man mehrere Threads hat, fällt die Sprungvorhersage deutlich leichter. Das macht bei kleinen, sich oft wiederholenden Schleifen nicht so den Unterschied, aber bei komplexem Code schon.
d) Der wahrscheinlich größte Vorteil von Hyperthreading ist, dass man bei einem Speicherzugriff den anderen Thread zur Gänze arbeiten lassen kann. Wird z.B. auf den RAM zugegriffen, so sind das ca. 50ns, also um die 150 Takte, die mit einem Thread verloren gehen. In der Zeit gehört der Kern fast zur Gänze dem anderen Thread. Der Scheduler des Betriebssystems macht das bei IO Zugriffen (z.B. Festplatte) auch so, jedoch sind die Speicherzugriffe zu kurz, als dass man einen anderen Thread aktiv schalten könnte (Speicherzugriff ca. 50ns, Threadwechsel ca. 10µs). Speicherzugriffe kommen öfter vor, als man denkt. Wenn ich die simple Operation c=a+b habe, heißt das schon, dass ich a lesen muss, b lesen muss, dann eine Addition durchführe und das Ergebnis auf c schreibe. Meistens arbeitet man noch mit Pointern, so noch ein Schritt dazu kommt. Selbst der Zugriff auf den L1 Cache braucht 3 Takte beim Core 2 Duo (4 Takte beim Core i7). Oft wird auch auf den L2 Cache zugegriffen, da in den L1 Cache mit 32KB nicht sehr viel hinein passt.

3.) Windows 7 kann keine Programme multithreaded machen, wenn diese nur einen Thread besitzten. Das sollte jedem klar sein, dass es da keine Wunder zu erwarten gibt. Es kann nur eine bessere Verteilung erfolgen. Die meisten Programme sind nicht vollkommen multithreaded und auch nicht nur rein singlethreaded. Oft hat man ein Programm mit einem Hauptthread, dass einen Kern zur Gänze belegt und dann noch ein paar andere Threads (teilweise im selben Prozess, teilweise andere Prozesse), die auch etwas an Leistung brauchen. Es gibt auch so halb optimierte Programme wie z.B. DivX6 oder WinRAR (ich meine echtes Komprimieren, nicht den Benchmark), die ca. 2 Threads auslasten können, aber nicht mehr, weil sich der Algorithmus nur teilweise parallelisieren lässt. Windows hat bisher die virtuellen Kerne nicht unterschieden. Es ist also unter Umständen passiert, dass die zwei größten Threads auf einem physischen Kern gelandet sind. Das war beim Pentium noch egal, da es sowieso nur einen physischen Kern gab und beim Core i7 ist das auch nicht so wichtig, da bei 4 Kernen die Wahrscheinlichkeit geringer ist (25%). Mit den kleineren Dual Cores ist das jedoch nicht mehr so unwichtig. Hier würde man schon zu 50% die zwei großen Threads auf einen physikalischen Kern legen.

 

[Limit]

Dafür ist Cuda ja da. Das könn(t)en die ja implementieren.

Das könnte man durchaus implementieren; es würde im Allgemeinen aber nicht viel bringen, da viele Standardalgorithmen (wenn man denn das ganze Verwaltungszeug im OS und vielen Programmen so bezeichnen will) nur wenig Parallelität auf Instruktionsebene erlauben und da kann auch Cuda nichts dran ändern. In den Fällen, bei denen es etwas bringt, muss man sich dann fragen, warum man es dann nicht gleich auf die GPU auslagert, die im Vergleich zu einer CPU extrem viel mehr Recheneinheiten besitzt (mehrere hundert statt nur 3-4 pro Kern). Nicht umsonst entwickeln zur Zeit sowohl Intel als auch AMD CPUs mit integrierter GPU.

 

[andr_gin]

1.) Die erste Frage ist, ob sich der Algorithmus sehr gut parallelisieren lässt. Wenn das für 4 bzw. 8 Kerne gut geht, wie bei X264, dann ist das auch für CUDA prinzipiell möglich.

2.) Die zweite Frage ist dann, ob die Hauptlast überhaupt auf den Recheneinheiten ist (z.B. Double Divisionen), oder ob es hauptsächlich nur Speicherzugriffe gibt und komplexen Code. Hier schaut es bei Grafikkarten überlicherweise sehr traurig aus. Bandbreite ohne Ende, aber die Latenz ist schlecht, was der eigentliche Faktor ist, der limitiert. Caches gibt es fast keine und wenn dann noch Threadsynchronisation dazu kommen, dann schaut es besonders schlecht aus. Wenn dann um die 100 virtuelle Kerne parallel Daten vom RAM lesen wollen, schaut es auch eher düster aus. Da wird dann 40ns lang adressiert und 5ns Daten gelesen über das schöne 512Bit Interface. Genau wegen diesen Problemen gibt es ja auch so viele Dual Karten, weil man dann wirklich alles parallisieren kann, aber dann braucht man eben auch den doppelten RAM. Es gibt zwar einige private Daten eines Threads, aber der Großteil wird zumindest theoretisch allen Threads zur Verfügung gestellt.

 

[rx4711]

Sehr lesenswert:
http://de.wikipedia.org/wiki/Hyper-Threading
http://de.wikipedia.org/wiki/Simultaneous_Multithreading

 

[Xonotron]

SMT bringt bei voll ausgelasteten CPUs garnichts.

Ich habe da in der Praxis ganz aktuell andere Erfahrungen gemacht. Intel core i7 920 auf Win 7 beta: Der Benchmark einer selbstentwickelten Applikation, die jeden Kern zu 100% auslastet. Man kann bei der Applikation einstellen, wieviele parallele Prozesse erzeugt werden sollen. Da es bei der Anwendung um Bitmapmanipulation vieler Dateien geht lässt sich das ganze sehr gut parallelisieren.

Ergebnis:
1 Prozess: 131,4 Sekunden
2 Prozesse: 66,5 Sekunden
4 Prozesse: 34,8 Sekunden
8 Prozesse: 22,2 Sekunden
16 Prozesse: 22,8 Sekunden

Die Leistung skaliert zwar ab 4 Kernen (erwartungsgemäß) nicht mehr linear aber immer noch deutlich! Ich war wirklich von den Socken als ich die ersten Ergebnisse mit eigenen Augen sah...

Jeweils einen der beiden virtuellen Kerne pro physikalischem Kern zu deaktivieren, damit sich die beiden virtuellen Kerne nicht gegenseitig ausbremsen bringt bei Nutzung von 4 Kernen so gut wie keine Performancevorteile, in meinem Fall 1-2%. Nicht zu vergleichen mit dem Perfomancevoteil durch das Nutzen aller 8 HT-Kerne...

 

[Blutschlumpf]

Stellt sich jetzt nur die Frage ob deine Ergebnisse relevant sind oder dein Code die CPUs einfach nicht vernünftig ausnutzt. Evtl. könnte man ja mit optimalem Code und 4 Kernen das ganze in 15 Sekunden abspielen

Andere Software zeigt da deutlich weniger Differenz zwischen 4 und 8 Threads:
https://www.computerbase.de/artikel...e-3#abschnitt_simultaneous_multithreading_smt.

Jeweils einen der beiden virtuellen Kerne pro physikalischem Kern zu deaktivieren, damit sich die beiden virtuellen Kerne nicht gegenseitig ausbremsen bringt bei Nutzung von 4 Kernen so gut wie keine Performancevorteile...

Darum gehts ja auch nicht.
Leg dein Programm mal mit 4 Threads auf die 4 Kerne mit je einer virtuellen CPU und dann einmal mit 4 Threads auf 2 Kerne mit je 2 virtuellen CPUs, dann kommt da vermutlich deutlich mehr als 1-2 % raus.
Sprich Core1-a + Core2-a + Core3-a + Core4-a gegen Core1-a + Core1-b + Core2-a + Core2-b. Darum ging es ja.

 

[Xonotron]

Stellt sich jetzt nur die Frage ob deine Ergebnisse relevant sind oder dein Code die CPUs einfach nicht vernünftig ausnutzt.

Öhm - das sehe ich anders. Es stellt sich die Frage ob die Ergebnisse repräsentativ sind, relevant sind sie ganz sicher weil vorhanden.
Ich greife auf Bibliotheken zurück auf deren Code ich keinen Einfluss habe, da bin ich sicher nicht alleine. Insofern ist das ein relevantes Szenario. Dass das Ergebnis je nach Code anders aussieht ist ja klar.
Es ging mir darum den von mir zitierten und in meinen Augen falschen Satz zu relativieren, weil meine individuelle Erfahrung eben eine andere ist. Ich wollte nicht den Eindruck erwecken, dass das repräsentative Werte sind die immer zutreffen - das habe ich aber doch auch gar nicht gesagt...

Darum gehts ja auch nicht. ...

Ahso, ich wollte damit zeigen dass Windows 7 schon jetzt offensichtlich sehr gut mit dem aktuellen Hyperthreading umgehen kann und es in der Praxis nicht oder vernachlässigbar zu Performanceeinbußen kommt, wie es früher teilweise beim P4 der Fall war - darum ging es ja in der News.

 

[Blutschlumpf]

Uns gings ja mehr drum ob man Gefahr läuft durch HTT Performance zu verlieren, da ist ein Benchmark der alle Threads nutzt sinnlos weil das Szenario dann ja nicht auftritt. Dass der bei 8 Threads schneller ist als bei 4 ist imo Minimalvorraussetzung, sonst wärs ja eh unsinnig.

 

[Xonotron]

Uns gings ja mehr drum ob man Gefahr läuft durch HTT Performance zu verlieren

?! ...aber genau das habe ich doch im letzten Absatz meines ersten Postings geschrieben, oder nicht?

Windows 7 verteilt die Threads bei Nutzung von nur vier Kernen eben so dass es kaum zu Performanceverlusten kommt. Natürlich hat man weniger Performance wenn man die vier Threads manuell auf zwei physikalische Kerne beschränkt, aber warum sollte man das tun? Windows 7 macht es nicht :-)

 

[andr_gin]

1.) Durch den hohen Sprung von 4 auf 8 Kerne (ca. 55%) sehe ich, dass die Software sehr gut von einem zusätzlichen virtuellen Kern profitiert. Ich nehme an, dass die Anweisungen an sich sehr einfach sind und so die CPU auf Befehlsebene nicht so viel parallelisieren kann. In der Realität sind denke ich 20-30% zu erwarten bei Software, die sich linear parallelisieren lässt. Dann sind es schon 2-4% Unterschied. Bei nur 2 Kernen sind es dann schon ca. 5-10%. Das ist dann schon nicht mehr ganz egal, da das eher als Normalfall anzusehen ist und nicht Anwendungen, die nur alle 8 Kerne parallel belasten.

2.) Nur einen einzigen selbst geschriebenen Benchmark heranzuziehen ist denke ich nicht sehr praxisnahe. Ich habe schon Programme geschrieben, die waren auf meinem Athlon64 X2 mit beiden Kernen 10 mal so langsam, als nur auf einem. Das sagt nicht viel aus. Selbst geschriebene Benchmarks neigen generell dazu nicht sehr praxisnahe zu sein. Bei den meisten Anwendungen hat man zusätzlich noch jede Menge IO Zugriffe, die das ganze Bild komplett durcheinander werfen, sei es die Grafikkarte bei Spielen, das Dateisystem/Netzwerk bei Datenbanksystemen oder Webservern usw. Nur im Multimediabereich gibt es Programme, die rein die Rechnleistung der CPU fordern.

3.) Es kommen dann noch weitere Überlegungen dazu z.B. ob man unter Volllast die Threads eines Prozesses eher auf den selben physikalischen Kern legt oder nicht. Bei einer exklusiven Cachehaltung wäre das sehr intelligent, da sich die 2 Threads gleich die selben Daten teilen können und nicht den L3 Cache bzw. sogar FSB bei zwei seperaten Dual Cores (siehe Core 2 Quad) zu benutzen. Weiters gibt es den Vorteil, dass der Platzbedarf eventuell geringer ist, da die Daten nur einmal in den L1 Cache gelegt werden müssen. Bei einer inklusiven Cachehaltung fällt der erste Vorteil hier weg, da jeder Kern seine eigene Kopie der Daten hat.
Auf der anderen Seite werden zwei gleiche Threads auch die selben Einheiten nutzen z.B. entweder vorwiegend Ganzzahl oder Fließkommaoperationen. Bei einem anderen Prozess, der andere Einheiten benutzt könnte die CPU besser auslasten.

 

[Blutschlumpf]

Dann verstehe ich nicht was du mit den 1-2% Differenz meinst die du da gemessen hast.
Ob Win7 die jetzt richtig verteilt oder nicht ist ja ebenfalls egal, die grundsätzliche gefahr ist ja trotzdem da, auch wenns in deiner Config nicht auftritt.

 

[Xonotron]

Nur einen einzigen selbst geschriebenen Benchmark heranzuziehen ist denke ich nicht sehr praxisnahe.

...um einen dermaßen pauschalen Satz zu widerlegen um den es ging in meinen Augen schon. Nochmal: ich habe nicht behauptet die Ergebnisse wären repräsentativ.

Dann verstehe ich nicht was du mit den 1-2% Differenz meinst die du da gemessen hast.

Die Differenz aus den durchschnittlichen Ergebnissen von je drei Durchläufen mit je vier Prozessen einmal mit HT und einmal ohne.

Ob Win7 die jetzt richtig verteilt oder nicht ist ja ebenfalls egal, die grundsätzliche gefahr ist ja trotzdem da, auch wenns in deiner Config nicht auftritt.

Kann natürlich sein, dass in anderen Fällen Win7 die Prozesse ungünstiger verteilt und die Performanceeinbuße größer ist, das kann ich anhand meiner Zahlen nicht beurteilen. Vielleicht kann da jemand nen Beispiel für?

 

[Photon]

@ Photon : Ach ja ? Hast du ein Netbook schonmal mit win 7 rc1 laufen gehabt ? Bei deiner Aussage glaub ich das eher nicht. Das läuft wie Butter !

Jo, ein Windows hab ich schon seit Jahren nicht mehr verwendet. Aber es gab hier doch mal vor Kurzem einen Test, bei dem Win7 nur ein paar Prozentpunkte schneller als Vista war. Und von Vista hab ich was Netbooks angeht, auch nichts Gutes gelesen...