Sorry... Amd oder Intel [Archiv]

snakekick

2004-02-08, 03:33:48

Hallo leute .. ich weiß ein altes leidiges thema und soll jetzt auch nicht unbedingt wieder ein grundsatzdiskusion werden.
..aber.. mir jugts wieder in den fingern und ich würde gerne meinen rechner aufrüsten.. nur glaub das sich das kaum lohnt ? hab nen amd 2200
überlege hat ob es sich "lohnt" ~400 euro für ein neues system ( amd 64 3000 bzw p4 3000) auszugeben . ob das wirklich sinn mach.
naja und dann bleibt ja die frage welches system .. ich weiß amd is schneller bei spielen ( geil 5 fps schneller)
und intel ein wenig bei video ( auch toll 2 sec früher fertig)
aber was mich mehr interessiert ist wie das "arbeiten" bei voller auslast ist. ärgere mich schon recht oft wenn ich einige mp3 umwandle nen film fleißig encodiert und dann der scheiß ie nicht aus dem arsch kommt.
und für genau den zweck würd ich gerne ne neue cpu haben denk mal da macht sich der p4 doch besser bei so einem aufgabengebiet oder also von wegen ht ? was meint ihr ? und bitte kein amd is so geil oder intel is so geil antworten. ..gibts da eigentich mal nen benchmark für ? endecke sowas immer nur mit einzelnen anwendungen ..

Dunkeltier

2004-02-08, 08:08:51

Original geschrieben von snakekick
Hallo leute .. ich weiß ein altes leidiges thema und soll jetzt auch nicht unbedingt wieder ein grundsatzdiskusion werden.
..aber.. mir jugts wieder in den fingern und ich würde gerne meinen rechner aufrüsten.. nur glaub das sich das kaum lohnt ? hab nen amd 2200
überlege hat ob es sich "lohnt" ~400 euro für ein neues system ( amd 64 3000 bzw p4 3000) auszugeben . ob das wirklich sinn mach.
naja und dann bleibt ja die frage welches system .. ich weiß amd is schneller bei spielen ( geil 5 fps schneller)
und intel ein wenig bei video ( auch toll 2 sec früher fertig)
aber was mich mehr interessiert ist wie das "arbeiten" bei voller auslast ist. ärgere mich schon recht oft wenn ich einige mp3 umwandle nen film fleißig encodiert und dann der scheiß ie nicht aus dem arsch kommt.
und für genau den zweck würd ich gerne ne neue cpu haben denk mal da macht sich der p4 doch besser bei so einem aufgabengebiet oder also von wegen ht ? was meint ihr ? und bitte kein amd is so geil oder intel is so geil antworten. ..gibts da eigentich mal nen benchmark für ? endecke sowas immer nur mit einzelnen anwendungen ..

Was du unter arbeiten verstehst, da liegt der P4 leicht im Vorteil (u.a. durch HT). Auch wenn du oft Filme sowie Musik encodierst, ist der P4 die bessere Wahl (SSE2, HT).

Aber letztlich ist der Unterschied nicht allzugroß, so das du ruhig wenn du viel spielst zum AMD Athlon 64 3000+ greifen kannst.

Tigerchen

2004-02-08, 08:36:57

Das dumme ist wohl daß du wenn du spielst und encodest der P4 bei HT viel Rechenzeit fürs encoden zugewiesen bekommt. Das kann die Spieleperformance ganz schön runterziehen.

Beim Athlon ist es so daß das Encoden nur die Zeit erhält die das Spiel nicht braucht. Dann geht das encoden recht langsam, stört aber auch nicht.

Beim encoden + Office ist dagegen der Intel nicht zu schlagen.

Dunkeltier

2004-02-08, 08:54:01

Original geschrieben von Tigerchen

Das dumme ist wohl daß du wenn du spielst und encodest der P4 bei HT viel Rechenzeit fürs encoden zugewiesen bekommt. Das kann die Spieleperformance ganz schön runterziehen.

Beim Athlon ist es so daß das Encoden nur die Zeit erhält die das Spiel nicht braucht. Dann geht das encoden recht langsam, stört aber auch nicht.

Beim encoden + Office ist dagegen der Intel nicht zu schlagen.

Es ist eher umgekehrt, der Athlon fängt das ruckeln im Spiel an während im Hintergrund das Video encodiert wird. Würde man die Priorität des encodierens runtersetzen, so würde beinahe so gut wie nichts zum Schluß encodiert sein.

Der P4 HT nutzt seine zu Verfügung stehende Leistung gegenüber einem normalen P4 viel besser, und kann sich gleichzeitig zu fast 100% (der P4 Leistung) dem Spiel und dem Video zuwenden wobei beide die gleiche Priorität haben.

Tigerchen

2004-02-08, 09:23:44

Wenn beide die gleiche Priorität haben wieviel % stehen dann jedem Prozeß zur Verfügung?

kryz

2004-02-08, 09:49:38

theoretisch 50% für jeden...

also ich würde dir, wenn du dir denn was neues holst zum p4 raten, allerdings isses auch nicht so sinnvoll, da bald nen neuer sockel kommen soll (halbes jahr oder so) und dann stehste da mit so478.... an sich könnteste ja versichen mit deinem jetztigen system noch etwas auszukommen..... oder halt einfach nen größeren prozzi für wenig geld aufen und orfentlich clocken!

Avalox

2004-02-08, 11:50:47

HT ist eine kleine Registeroptimierung. Mehr nicht. Alt bekannt als SMT. Dieses ist nur vom Intel Marketing absolut aufgeblasen worden. Schon der Name Hyper Threading ist absolut lächerlich.

Unter gewissen Umständen erhöht HT die verfügbare Rechenleistung. Um dieses Ziel zu erreichen gibt es aber weit mehr Ansätze als allein HT. SMT ist nett, wird auch in Zukunft bestimmt in jede x86 Architektur auftauchen.
Weil es so billig und einfach zu realisieren ist. Mehr aber auch nicht. HT ermöglicht nichst neues.
Der entscheidende Punkt ist, sobald man Cache oder Prefetches optimierte Software einsetzt geht der Nutzen von HT stark gegen Null, bzw. kehrt sich unter Umständen sogar um. Das ist aber genau die Software, welche auf Performanz optimiert ist. Um es ein wenig ketzerisch zu beschreiben. HT beschleunigt vor allen Software, bei der der Programmierer der Ansicht war, dass Geschwindigkeit nicht die grösste Rolle spielt.

HOT@Work

2004-02-09, 10:18:01

Intel kann nur von HTT profieren, weil Windows so beschissen mit mehreren rechenintensiven Threads umgehen kann. HTT bringt und Linux lange nicht die Vorteile, die es unter Windows bringen kann (oder besser es bringt für non-HTT weniger Nachteile :D).

snakekick

2004-02-10, 01:36:59

jut jut .. abschließend läst sich doch sagen das der p4 mit ht der "sieger" is
ob es nun daran liegt das die software schlecht programiert wurde oder nicht .. er is in dem anwenungsgebiert schneller da spielt es ja auch kaum eine rolle ob es dieses prinzip schon jahre gibt oder nicht.. naja und zu dem punkt bezüglich warten .. das sollte man doch sowieso immer machen oder .) das der aktuelle amd sockel ja nun auch net jahre überlebt is ja auch nix neues.. nur das wort 64 bit hätte mich gereizt.. aber da is wohl ht mehr im vorteil .. naja dank euch !

Morpheus2200

2004-02-10, 02:18:41

Original geschrieben von snakekick
jut jut .. abschließend läst sich doch sagen das der p4 mit ht der "sieger" is
ob es nun daran liegt das die software schlecht programiert wurde oder nicht .. er is in dem anwenungsgebiert schneller da spielt es ja auch kaum eine rolle ob es dieses prinzip schon jahre gibt oder nicht.. naja und zu dem punkt bezüglich warten .. das sollte man doch sowieso immer machen oder .) das der aktuelle amd sockel ja nun auch net jahre überlebt is ja auch nix neues.. nur das wort 64 bit hätte mich gereizt.. aber da is wohl ht mehr im vorteil .. naja dank euch !

Ich würd trotzdem zum A64 greifen eben wegen den 64bit.
Das der P4 derzeit noch schneller ist beim encoden keine Frage (da so ziehmlich alles auf den P4 optimiert ist) aber wie siehts aus wenn 64bit software erhältlich ist, ein leistungs sprung von 20-30 % ist zu erwarten.

und HT ist ein Marketinggag und leider sonst nicht viel.

zild@home

2004-02-10, 04:54:43

warum die idee von HT war doch gut!
fürn anfang schonmal eine gute sache.
vielleicht kommt ja neues überarbeitetes besseres HT raus?

aufjedenfall find ich HT bis dato noch immer einfalsreicher als 64 bit CPU's die wir vielleicht 2006 sinnvoll unter windows nutzen können, von spielen mal ganz zu schweigen.

wenn dann schon so wie bei apple, die releasen wenigstens alles auf einmal + betriebssystem + ausgereiftes hardwaresystem.

betasilie

2004-02-10, 05:09:39

Ganz klar der Athlon64, weil er beim Gamen schneller ist und ggf. bald auch beim Encoden, wenn das 64bit-Windows kommt und entsprechend optimierte Aplikationen. Auch die Games werden dann nochmal um einiges schneller.

HT ist ganz nett, aber Encoden und Gamen kannst Du auch mit dem P4 vergessen.

GloomY

2004-02-10, 07:18:42

Original geschrieben von Morpheus2200
und HT ist ein Marketinggag und leider sonst nicht viel. Och Leute, so ein Gebashe muss doch wirklich nicht sein, oder?

SMT ist ein vielversprechendes Konzept. Intels Implementation (HTT) war ganz am Anfang (Xeon B0 Stepping) - gelinde Gesagt - ziemlicher Schrott (15% Leistungeinbußen). Mit dem C1 Stepping wurden die größten Schwierigkeiten beseitigt, man konnte es immerhin für spezielle Zwecke einsetzen. Es blieb jedoch die prinzipiell schlechte Eignung der Caches (zu klein, Assotiativität). Das hat sich jetzt mit dem Prescott auch gebessert (Verdoppelung des L1 D-Cache, 8- statt 4-fach Assotiativ). Dazu kommen die paar neuen PNI Befehle, die neben ganz einfachen Sachen auch ein paar kleine Verbesserungen für HTT dabei haben. Bei aller Kritik muss man also klar sagen, dass Intel kontinuierlich nachgebessert hat. Jetzt davon zu reden, dass HTT Schrott sei, ist sicher nicht der richtige Zeitpunkt dazu.
So, genug Werbung für Intel gemacht ;)
Original geschrieben von Dunkeltier
Es ist eher umgekehrt, der Athlon fängt das ruckeln im Spiel an während im Hintergrund das Video encodiert wird. Würde man die Priorität des encodierens runtersetzen, so würde beinahe so gut wie nichts zum Schluß encodiert sein.

Der P4 HT nutzt seine zu Verfügung stehende Leistung gegenüber einem normalen P4 viel besser, und kann sich gleichzeitig zu fast 100% (der P4 Leistung) dem Spiel und dem Video zuwenden wobei beide die gleiche Priorität haben. Klick (http://80.237.203.42/vbulletin/showthread.php?s=&postid=1075789#post1075789).

Wenn du nur das Spiel (mir einem Thread) und nur den Encoding-Prozess (ebenfalls mit einem Thread) hast, dann sieht's so aus:

Beim Athlon ruckelt nichts, denn das Spiel hat Real-Time Priorität und der Encoding Prozess nicht (sonst kämst du nämlich gar nicht dazu, das Spiel zu starten; könntest nicht man das Startmenü öffnen). Dafür wird auch kaum am Encoding-Prozess weitergearbeitet, solange das Spiel nicht gerade nachlädt. Das ist aber auch der Sinn von unterschiedlichen Prioritäten. Der eine Thread soll weniger Rechenleistung als der andere bekommen.

Beim P4 ruckelt das Spiel und der Encoding Prozess arbeitet weiter. Welches Verhalten ist hier wohl wünschenswerter?

mapel110

2004-02-10, 07:23:50

Original geschrieben von GloomY
Beim P4 ruckelt das Spiel und der Encoding Prozess arbeitet weiter.

:w00t:
Ist das echt so?

GloomY

2004-02-10, 07:36:21

Original geschrieben von mapel110
:w00t:
Ist das echt so? Ich hab's bisher mangels P4 mit HTT nicht ausprobieren können. Zumindest spricht das, was ich im THG Video gesehen habe und einige theoretische Überlegungen durchaus dafür.

Anmerkung noch dazu: Dieses Phänomen tritt nur dann auf, wenn es nur exakt zwei Thread gibt, die ständig Rechenleistung fordern. Sobald drei oder mehr vorhanden sind, kann der Windows Scheduler beeinflussen, wie viel Zeit die einzelnen Threads bekommen. Wenn es nur zwei Threads sind, dann werden diese bei HTT immer ausgeführt. Das führt zu einer gleichmäßigen Abarbeitungsgeschwindigkeit, die unabhängig von den einzelnen Prioritäten der Threads ist. Das Spiel bekommt dann in diesem Fall eben nur noch 50% der CPU Rechenleistung, die andere Hälfte schnappt sich der Encoding-Prozess.

Endorphine

2004-02-10, 11:09:35

Original geschrieben von GloomY
Beim P4 ruckelt das Spiel und der Encoding Prozess arbeitet weiter. Welches Verhalten ist hier wohl wünschenswerter? Du störst dich an Gebashe und machst selbst fröhlich mit?

Natürlich muss man etwas Hirn bei der Prozesspriorisierung einsetzen. Wer dem Encodingprozess eine höhere oder gleiche Priorität gibt muss sich nicht wundern, wenn das Spiel im Vordergrund ruckelt. Wer dem Encodingprozess eine niedrigere Priorität gibt wird davon nichts bemerken, es wird ja lediglich freie Einheitenauslastungskapazität der CPU dem Encodingprozess zugeteilt.

Übrigens wird genau dieser Sachverhalt von Intel für's Marketing ausgeschlachtet. Angucken und dann bitte aufhören mit den Gebashe: http://www.intel.com/personal/do_more/demos/illustration.htm

Avalox

2004-02-10, 11:16:10

Wenn ich jemanden auf dem Sack gehe, weil es schon oft erzählt wurde, bitte einfach überlesen. ;)

Es ist in der Tat so, dass die gesamt Rechenleistung auf die Threads verteilt wird. Im Vordergrund steht nicht mehr die Thread Prio. Als vielmehr Wartezeiten, welche bei der Abarbeitung einzelner Befehle entstehen.

SMT (wozu auch Intels HT zählt) ist eine Überlegung die von Neumann Architektur der gängigen CPUs zu verbessern, von der Idee schon sehr alt und auch schon vielfach umgesetzt. In der x86 Welt ist diese halt erst mit HT einzug gehalten.

Nun warten CPUS schon mal ziemlich gerne,
genau genommen tun sie dieses bis zu 70% der gesamt Zeit. (Das ist aber nicht mit dem CPU IDLE zu verwechseln! Diese Wartezeit wird nicht im Taskmanager angezeigt.)
Dieses tun die CPU, weil grade Register neu aus dem Speicher geladen werden. Weil ein Sprung oder andere externer Semaphoren durchgeführt werden.

Nun hat man sich Gedanken gemacht, wie man diese Wartezeit besser nutzen kann. Eine Idee war, dass CPUs Befehle parallel ausführen können. Daraus resultierten die Superskalaren Ansätze, wie sie seit dem 486 in jeder CPU zu finden sind.
Ein Befehl lässt aber nur unter zwei Umständen parallel abarbeiten. Es darf nicht die CPU Unit verwendet werden, welche schon benutzt wird und es darf logischerweise kein Ergebnis eines parallelen Befehls für die Abarbeitung notwendig sein. Man hat festgestellt. Das moderne Software maximal einen ILP von 2,5 aufweißt. Mit allen Tricks. Dass heisst es sind 2,5 Befehle maximal parallel möglich.

Auf dieser Richtung kommt man also nicht weiter. Nun sind die Register (schnellste Speicher in einem Computer, in denen jedes Datum welches verarbeitet/erzeugt wird zwischengespeichert wird) in einem x86 knapp. Nun hat man die Anzahl der Register in den HT fähigen Pentiums und Xeons verdoppelt. Zwischen diesen beiden Register Sätzen wird hin und her geschaltet. Die Software bekommt davon eigentlich nichts mit.

Die Idee ist, sobald ein Thread ausgeführt wird und auf externe Ereignisse wartet, wird ein zweiter Thread welcher den zweite Registersatz nutzt ausgeführt. Idealerweise sind in dieser Situation die Register schon geladen. So lassen sich die Warte Zeiten der CPU insgesamt ein wenig verkürzen. Der Thread als solches wird aber nicht schneller ausgeführt.
Die Verwaltung des SMT verbraucht natürlich einiges an Zeit. Ferner können sich Threads untereinander stark behindern. Mit HT werden also die Pausenzeiten verringert. Mal mehr, mal weniger, mal verlangsamt sich auch eine CPU mit HT, weil die Threads im ersten und im zweiten RegisterSatz überhaupt nicht zueinander passen und um die selben CPU Ressourcen buhlen.
Beim bisherigen HT ließen sich die Thread untereinander nicht mal synchronisieren. Sprich ein Thread der auf einen bestimmten anderen Thread gewartet hat. Hat noch nicht mal sofort mitbekommen, wenn dieser fertig war.
Dass soll sich aber mit dem Prescott deutlich gebessert haben.

Nun kommt der eigentliche Knaktus am SMT. Der Programmierer kann sehr wohl die Wartezeiten der CPU beeinflussen. Er macht das auch, wenn er möchte, dass das Programm auf eine schnelle Abarbeitung optimiert wird. Dann wird die Software auf Cache-Management und Prefetches optimiert. Genau solche hochoptimierte Software finden man bei Spielen. Deshalb profitieren Spiele nicht so stark oder überhaupt nicht von HT. HT beschleunigt eher unoptimierte Software. Halt Software, bei der es nicht so stark auf die Abarbeitungsgeschwindigkeit ankommt.
Dabei wird jede moderne Software, wie auch Spiele, Mutli Threaded programmiert. Der Thread ist nicht mit dem Task zu verwechseln.

Schlussendlich ist HT eine nette Sache. Aufgrund des nur geringen Aufwand, bei der Herstellung wird es irgendwann in jedem x86 Prozessor zu finden sein. Wunder vollbringen, oder gar ein K.O. Kauf Kriterium ist dieses aber nicht. Wer sich über das schnelle encoden auf dem P4 freut. Sollte mal HT ausschalten und nochmal messen. Rechenleistung wird auch nicht aus dem nichts gezaubert. Mehrere Anwendungen teilen sich die gesamt Rechenleistung, welche ähnlich hoch liegt wie ohne HT. Die Thread Prios werden aber anders gehandelt. Da hat GloomY vollkommen recht.

Interessant ist EPIC. Ein weiterführender Ansatz zu Parallelverarbeitung. Dieses ist aber furchtbar zu programmieren.

Endorphine

2004-02-10, 11:18:21

Vor allem ist genau das Gegenteil der Fall als das, was die ganzen Intelbasher hier erzählen wollen: ohne SMT läuft entweder das Spiel flüssig oder die Videokompression. Wenn man beides startet hält die Videokompression im Hintergrund praktisch komplett an, da bewegt sich dann gar nichts. Wenn man sie auf eine höhere oder gleiche Priorität setzt bewegt sich logischerweise beim Spiel wenig (Achtung, Desktop-Windows priorisieren den im Vordergrund laufenden Task intern per default höher).

Mit SMT und niedriger Priorität für die Kompression kann man dagegen beides gleichzeitig. Das Spiel läuft durch die grössere Verwaltungsarbeit des Schedulers minimal langsamer (jedoch niemals um 50% - wie kommt man auf solchen Unsinn?) und die Videokompression schnappt sich über SMT die arbeitslosen CPU-internen Einheiten, während das Spiel voll weiterläuft.

mrdigital

2004-02-10, 11:27:21

Meinst echt Endo, dass man auf nem P4 HT zocken und encoden gleichzeitig kann, so dass beide Aufgaben mit aktzeptabler Geschwindigkeit laufen (encoden mit 1FPS kann ich lassen, das habe ich nacht 2h Spielen mit 4 Minuten nur encoden wieder reingeholt)? Ich hab das nicht ausprobieren können, magels HT P4.

Avalox

2004-02-10, 11:28:13

HT ist kein gutes SMT.

Der Encoder läuft schon sehr viel schneller, wenn kein Spiel im Vordergrund die Rechenleistung mopst.
Es ist aber besser als nichts. Zur Zeit finde ich mehr Register aber interessanter.

Mit den neuen freigeschalteten Prescotts wird man ja wahrscheinlich beides haben.
Aber der wird ja nicht in D gefertigt und Scheiß heiss wird dieser auch.
Der Athlon 64 wird bei mir im 64Bit Betrieb übrigens auch sehr warm. (erstaunlicher Weise und schwer nachvollziehbar)

Endorphine

2004-02-10, 11:31:22

Original geschrieben von mrdigital
Meinst echt Endo, dass man auf nem P4 HT zocken und encoden gleichzeitig kann, so dass beide Aufgaben mit aktzeptabler Geschwindigkeit laufen (encoden mit 1FPS kann ich lassen, das habe ich nacht 2h Spielen mit 4 Minuten nur encoden wieder reingeholt)? Ich hab das nicht ausprobieren können, magels HT P4. Die gesamte Fachpresse wäre längst über Intel hergefallen, wenn diese etwas bewerben würden, was in der Praxis nicht funktioniert. Zudem hat THG es ja auch im Video gezeigt (OK, THG ist Intel-biased, aber ihre Videos werden sie nicht manipulieren, ohne dass ein Aufschrei durch die Szene geht).

Endorphine

2004-02-10, 11:34:21

Original geschrieben von Avalox
HT ist kein gutes SMT.

Der Encoder läuft schon sehr viel schneller, wenn kein Spiel im Vordergrund die Rechenleistung mopst.
Es ist aber besser als nichts. Zur Zeit finde ich mehr Register aber interessanter.

Mit den neuen freigeschalteten Prescotts wird man ja wahrscheinlich beides haben.
Aber der wird ja nicht in D gefertigt und Scheiß heiss wird dieser auch.
Der Athlon 64 wird bei mir im 64Bit Betrieb übrigens auch sehr warm. (erstaunlicher Weise und schwer nachvollziehbar) HT ist sicher noch fern von einer optimalen SMT-Implementierung. Derzeit hat aber keine andere x86-Architektur etwas besseres zu bieten, also ist es müßig, darüber zu diskutieren, wie viel besser SMT noch sein könnte.

Die x86-Konkurrenz soll erst mal vergleichbares bringen... Derzeit hat IIRC nur noch IBM ein praktisch realisiertes SMT zu bieten. Da wäre ein Vergleich (mit dem Xeon) natürlich hochinteressant, wenn auch akademisch (kein x86).

Avalox

2004-02-10, 13:31:56

HT ist eine nette Sache.

Nun muss man aber feststellen, dass SMT eher für Serveranwendungen gedacht ist. Mit sehr vielen Threads, welche gleichzeitig laufen.

Für Desktop und Workstations ist eher ein verbessertes ILP interessant. Dabei können mehr direkte Register durchaus helfen.

Ich finde nur den Namen Hyper Threading ist lachhaft.
Wenn ich mich heute Abend ein wenig entspannen möchte, dann schwinge ich mich auf mein Hyperrad und meine damit mein Fahrrad, welches ja zwei Räder hat. Danach sehe ich Hyper Fernsehen, weil ich mal zwischendurch mal auf ein zweites Programm umschalte.

Sun wird nun 4 Fach SMT liefern, welches halt Serveranwendungen sehr entgegenkommt.

Und sind wir mal ehrlich, würden sich nicht so viele Leute aufgrund der Schrumpf DVD Brenner mit Video Encodern rumschlagen, wäre das Thema HT Zuhause wenig zu gebrauchen.

Man muss mal wieder Intel für das Timing, der Markteinführung von HT bewundern. Lag bestimmt schon lange in der Schublade. Erst mit dem Prescott kommt nun ein wenig EV8 Technik in die Pentiums. Obwohl immer noch einer der wichtigsten Befehle scheinbar fehlt. HT nämlich zur Laufzeit abzuschalten.

Gast

2004-02-10, 13:42:32

hat hier echt keiner nen p4c?
ich werds mal testen, in divx umwandeln frisst aber zb sauviel power, glaub kaum das ich da noch zocken kann....
aber gut, ich check das demnächst mal.

Tesseract

2004-02-10, 15:14:00

@treadstarter: allein für den den zweck encoden+office wär der p4 wohl die bessere wahl

aber meine empfehlung lautet trotzdem: nichts kaufen
der unterschied ist einfach zu gering
gerade bei encoden usw. (also keine zeitkritischen apps) fällt ein schnelleres system erst bei viel höherer geschwindigkeit wirklich ins gewicht (zB um den faktor 2 schneller)

bei zeitkritischen wie spielen merkt man schon so um die 20% steigerung (subjektiv versteht sich)

wenn der encoder wirklich so das system ausbremmst würde ich mal schaun ob genug ram vorhanden ist und wenn ja die priorität des encoders runtersetzen, dann braucht dein encoden vielleicht 0,1% länger, dafür reagiert das sys wieder schnell

wenn du dennoch aufrüsten willst würde ich einen k8 nehmen
einfach deswegen weil spielen, wie gesagt, zeitkritisch ist und encoden nicht

GloomY

2004-02-10, 15:16:46

Original geschrieben von Endorphine
Du störst dich an Gebashe und machst selbst fröhlich mit?Ähm, ich bashe nicht. Ich zeige eine realen Schwäche von HTT mit Hilfe begründeter Kritik auf. Ich probiere dabei möglichst neutral zu sein, argumentiere mit Fakten und bin logischerweise an einer Diskussion interessiert. Bashen ist weit davon entfernt.
Original geschrieben von Endorphine
Natürlich muss man etwas Hirn bei der Prozesspriorisierung einsetzen. Wer dem Encodingprozess eine höhere oder gleiche Priorität gibt muss sich nicht wundern, wenn das Spiel im Vordergrund ruckelt. Wer dem Encodingprozess eine niedrigere Priorität gibt wird davon nichts bemerken, es wird ja lediglich freie Einheitenauslastungskapazität der CPU dem Encodingprozess zugeteilt.Hast du meinen Post und den Link zu dem Thread eigentlich richtig gelesen? Wenn ja, dann wüsstest du, dass du nicht einfach "freie Einheiten" dem zweiten Prozess zuweisen kannst. Sowas ist Wunschdenken. Woher soll die CPU denn wissen, dass sie den Befehlen der beiden Threads unterschiedliches Gewicht bei der Vergabe der CPU Recourcen geben soll? Ohne Hardwareunterstützung dafür (so wie in IBMs Power5) werden zwei Threads innerhalb des Prozessors immer gleich schnell abgearbeitet. Der OS Scheduler kann dies nur dadurch steuern, indem er die Threads unterschiedlich lange CPU Zeit zuweist. Wenn nun aber nur 2 Threads da sind, dann werden diese auch immer ausgeführt. Was soll der OS Scheduler denn da steuern? Er muss quasie immer beide Threads ausführen und das führt dazu, dass die beiden Threads unabhängig von ihren Betriebssystem-Prioritäten in etwa gleich schnell abgearbeitet werden. Es ist also nicht mehr möglich, dass ein Thread 90% der Rechenzeit bekommt.
Original geschrieben von Endorphine
Übrigens wird genau dieser Sachverhalt von Intel für's Marketing ausgeschlachtet. Angucken und dann bitte aufhören mit den Gebashe: http://www.intel.com/personal/do_more/demos/illustration.htm Argh, warum geht die Seite nur mit dem IE und nicht mit Mozilla (mit aktuellem Flash 7)? ;(

Zum Inhalt: Wenn das Spiel so anspruchlos ist und selbst mit 50% CPU Power auskommt, dann ist es klar, dass es nicht ruckelt. Spiel' mal UT2003, während du nebenher ein Video codierst. Dann sieht die Sache nämlich wieder anders aus.

Und ich merke auch hier nochmal an, dass ich nur behauptet habe, dass dieses Verhalten nur genau dann auftritt, wenn es zwei Threads gibt, die Rechenleistung wollen. Gibt es mehr als zwei, so kann der OS Scheduler wieder durch die zeitweise Vergabe der CPU an die Threads steuern. Wenn es aber nur zwei Threads gibt und im Prozessor auch immer zwei Threads ausgeführt werden, kann der OS Scheduler bei HTT gar nichts beeinflussen. Und das ist der Punkt. Kapiert?

Vielleicht ist in dem Video die Situation auch so, dass es mehr als zwei Threads gibt. Dann trifft die obige Situation natürlich nicht zu. Bloss dann zu behaupten, man könne generell ein Spiel laufen lassen und im Hintergrund encoden, ist einfach nicht korrekt.

edit: Man bemerke hierbei auch, dass ich die Vorraussetzung für meine Behauptung, nämlich dass es nur zwei Threads gibt, welche Rechenleistung brauchen, immer dazugeschrieben habe. Wie man jedoch weiss, bestehen die meisten Spiele auch nur aus einem Thread, sonst hätten SMP Systeme viel mehr Vorteile bei Spielen. Und das Encoden ist normalerweise auch nur ein Thread (gleiche Argumentation mit SMP), womit die Vorraussetzung für das Verhalten erfüllt wäre.
Original geschrieben von Avalox
Die Idee ist, sobald ein Thread ausgeführt wird und auf externe Ereignisse wartet, wird ein zweiter Thread welcher den zweite Registersatz nutzt ausgeführt.Es werden immer zwei Threads ausgeführt. Weder der Prozessor noch das Betriebssystem kann willkürlich die Anzahl der auszuführenden Threads während des Betriebs verändern.

Vielleicht wird es klarer, wenn ich mal ein Bild poste?! Wenn man die Ausführungseinheiten horizontal und die Zeit taktweise vertikal darstellt, dann sieht das so aus:
http://www.slcentral.com/articles/01/6/multithreading/i/5.gif

(links ein traditioneller superskalarer Prozessor, rechts 4-fach SMT)

Recht sind immer 4 Threads aktiv, die sich die Ausführungseinheiten teilen, nicht nur dann, wenn der Prozessor nichts zu tun hat. Dies wäre im Übrigen das Verhalten von Course-Grained (oder auch Fine-Grained) Multiprozessoren.

Avalox

2004-02-10, 15:51:54

Ja völlig richtig.

SMT bietet zwei Performanz Vorteile, welche aber stark unterschiedlich gewichtet sind.

Zum einen spart sich die CPU im günstigsten Fall das neuladen der Register. Zum anderen wird bei entsprechenden externen Semaphoren auf den nächsten Thread umgeschaltet. Dafür hat jeder Registersatz bei, Intel sind ja nur hypermässige 2, einen Interrupt-Controller, einen APIC. Da in der Regel mehr als zwei Threads ausgeführt werden, wird auch beim Intel HT i.d.R. der Registersatz neu geladen.
Der grosse(kleine?) Vorteil ist das Umschalten bei externen Semaphoren, wie z.B. einen Sprung. Die CPU muss erst an die neuen Daten heran kommen, was im schlimmsten aller Fälle bedeutet, dass diese aus dem Hauptspeicher beschafft werden müssen. Bei diesen Wartezeiten wird auf den nächsten Thread geschaltet.
Obwohl dieser vielleicht gar nicht die höhere Prio hat.

Das Übel(eines von vielen bei HT) beginnt damit, wenn dieser Thread nun Daten/Ergebnisse des ersten Threads benötigt.
Dann fragt dieser an ob, der erste Thread diese Daten bereitgestellt hat. Das macht er mitunter so oft, dass der Ergebnis liefernde Thread gar nicht mehr richtig zu Abarbeitung kommt.
Um dass zu vermeiden, kann man einen Thread so programmieren, dass er eine Pause macht. Dabei ist aber das grosse Problem. Dass die Pause vielleicht noch nicht vorbei ist, obwohl der erste Thread schon längst das Ergebnis parat hat. Es stecken viele Tücken in HT. HT wird ja auch mit jeder Prozessorgeneration weiter entwickelt.

Das was man als Nutzen(5% - 15%) beim HT sieht kommt, tatsächlich mehr aus der Pausennutzung, als der Vermeidung des Registerladens. Obwohl beides dazu beiträgt.
HT ist ein Lückenfüller.

@Endorphine

Das was Intel so zu HT schreibt ist ja schon manchmal ziemlich doppeldeutig.

Schlimm wird es aber erst, wenn man die Werbung von PC Ketten hört.
Ich glaube Dell macht grade eine Werbung. Bei der der Slogen in Richtung geht.
„HT ermöglicht es ihnen mehrere anspruchsvolle Anwendungen parallel zu nutzen“

Und die Verkäufer im Shop erzählen dann. „Was sie wollen Surfen und gleichzeitig MP3s hören? Ja dann brauchen sie HT“

Quasi wird HT auf die Stufe des Multitaskings Ermöglicher gehoben. Das ist doch der eigentlich ärgerliche Punkt. Es tauchen ja sogar immer wieder Kommentare auf, wo HT mit Multiprozessing gleichgestellt wird.

Das geht dann ja schon in massiv in die Irreführung. Hätte doch eine schnellere CPU den gleichen Effekt untern Strich. Ganz im Gegenteil, diese würde auch die Software beschleunigen, welche für HT gar keinen Raum lässt.

zeckensack

2004-02-10, 16:24:26

Avalox,
die "Probleme" die du da beschreibst sind alle längst gelöst. Alle modernen Betriebssysteme haben Synchronisierungsobjekte, die Programme explizit nutzen können, um a)dem Scheduler unter die arme zu greifen und b)eben zu verhindern, dass durch das Warten auf neue Daten unnötig Leistung verballert wird.

GloomY,
ich weiss ehrlich gesagt garnicht, wie das bei HTT gelöst wurde, aber ich könnte mir schon vorstellen, dass eine SMT-Implementierung den Threads unterschiedliche Prioritäten zuordnen kann. Dh dass wenn eine Asführungseinheit gerade von beiden Threads "gewollt" wird, dann kann man es IMO sehr leicht so einrichten, dass eben einer der Threads immer gewinnt. Und das sollte man dann auch sinnvollerweise vom OS-Scheduler steuern lassen.

*wühl@intel.com*

Avalox

2004-02-10, 16:41:47

Ja, da hast Du Recht. Das sind Lösungen, welche generell für Multi Threaded Software, von einem Multi Threading OS gedacht sind und nicht speziell auf HT abziehlen.
Aber was macht dieses Sync Objekt auf HT Maschinen?

Erst der Prescott führt die Alpha Befehle "Monitor" und "Sync" ein. Bis dahin gibt es nur die feste Pause.

Ich mag es ja gar nicht schlecht reden. Finde diese Innovation auch gut und sehr sinnvoll.

Mich persönlich ärgern halt nur die Werbe/Verkaufs Versprechen.

BlackBirdSR

2004-02-10, 16:57:17

Original geschrieben von Avalox

Der Athlon 64 wird bei mir im 64Bit Betrieb übrigens auch sehr warm. (erstaunlicher Weise und schwer nachvollziehbar)

Ich habe noch keinerlei Angaben zur Wärmeentwicklung im 64Bit Modus gesehen.. und ehrlich gesagt, kann ich mir sowas auch nicht vorstellen.

AMD hat alle betroffenen Einheiten neu Designed und für 64Bit ausgelegt, soweit ich weiss. bei 32Bit wird eben aufgefüllt. Es ist nicht so, dass bei 64Bit plötzlich 2 neue 32Bit ALUs dazukommen, oder extra Einheiten angesprochen werden.
Demzufolge, dürfte sich der Unterschied in Sachen Verlustleistung doch sehr in Grenzen halten..

Avalox

2004-02-10, 17:06:21

Habe extra dazu einen Thread im Athlon Forum aufgemacht, weil mich das selbst sehr überrascht hat.

Die CPU Temperatur steigt bei mit tatsächlich von 38°C - 40°C beim surfen unter Win32, auf 54°C bis 57°C bei gleichen Verhalten auf dem WinXP for AMD64 Bit.

Hatte erst an einen Fehler von Aida auf dem 64Bit System gedacht und habe einfach mal nach einem Reset in das Bios gesehen und tatsächlich ist dort auch die Rest Temp. noch deutlich zu erkennen gewesen.

Wie gesagt mich überrascht es ungemein. Es mag aber mit dem Beta Status von WinXP zu tun haben. Ich habe übrigens im Win32 und Win64 c'n'q deaktiviert.
Außerdem sind ja die knapp 60°C noch weit von den erlaubten 80°C entfernt. ;)

Im anderen Thread hat sich übrigens jemand gemeldet der ähnliches schon gehört hat.

Mal sehen.

BlackBirdSR

2004-02-10, 17:13:34

Original geschrieben von Avalox
Habe extra dazu einen Thread im Athlon Forum aufgemacht, weil mich das selbst sehr überrascht hat.

Die CPU Temperatur steigt bei mit tatsächlich von 38°C - 40°C beim surfen unter Win32, auf 54°C bis 57°C bei gleichen Verhalten auf dem WinXP for AMD64 Bit.

Hatte erst an einen Fehler von Aida auf dem 64Bit System gedacht und habe einfach mal nach einem Reset in das Bios gesehen und tatsächlich ist dort auch die Rest Temp. noch deutlich zu erkennen gewesen.

Wie gesagt mich überrascht es ungemein. Es mag aber mit dem Beta Status von WinXP zu tun haben. Ich habe übrigens im Win32 und Win64 c'n'q deaktiviert.
Außerdem sind ja die knapp 60°C noch weit von den erlaubten 80°C entfernt. ;)

Im anderen Thread hat sich übrigens jemand gemeldet der ähnliches schon gehört hat.

Mal sehen.

vielleicht klappt das beim Win64 noch nicht so, mit dem Einschlafen der CPU ;)
kann mir nicht vorstellen, dass der Unterschied so groß wird.

Dunkeltier

2004-02-10, 17:38:11

Original geschrieben von GloomY
Och Leute, so ein Gebashe muss doch wirklich nicht sein, oder?

[...]
Klick (http://80.237.203.42/vbulletin/showthread.php?s=&postid=1075789#post1075789).

Wenn du nur das Spiel (mir einem Thread) und nur den Encoding-Prozess (ebenfalls mit einem Thread) hast, dann sieht's so aus:

Beim Athlon ruckelt nichts, denn das Spiel hat Real-Time Priorität und der Encoding Prozess nicht (sonst kämst du nämlich gar nicht dazu, das Spiel zu starten; könntest nicht man das Startmenü öffnen). Dafür wird auch kaum am Encoding-Prozess weitergearbeitet, solange das Spiel nicht gerade nachlädt. Das ist aber auch der Sinn von unterschiedlichen Prioritäten. Der eine Thread soll weniger Rechenleistung als der andere bekommen.

Beim P4 ruckelt das Spiel und der Encoding Prozess arbeitet weiter. Welches Verhalten ist hier wohl wünschenswerter?

Schön das du mich wiederholst. Das sagte ich doch bereits, entweder ich habe die Priorität auf's Game gelegt und am Ende meiner Gamesession ist sogut wie nichts encodiert, oder aber ich habe die Priorität aufs encoden gelegt und ruckel mir im Spiel einen ab mit dem AMD. Das schrieb ich doch so schon bereits.

Wie schon gesagt, beim P4 HT sieht das anders aus da er erstens seine zu Verfügung stehende Leistung besser ausnutzen kann als ein Prozessor ohne HT und er außerdem den Threads mehr oder weniger die gleiche Priorität zuweist.

Dunkeltier

2004-02-10, 17:39:53

Original geschrieben von mapel110
:w00t:
Ist das echt so?

Nein, der AMD würde entweder im Spiel ruckeln oder mit dem encodieren gar nicht vorankommen! Gloomy schreibt imho Shit. Ich kann ja selber zwischen beiden Vergleichen.

GloomY

2004-02-10, 19:55:55

Original geschrieben von zeckensack
GloomY,
ich weiss ehrlich gesagt garnicht, wie das bei HTT gelöst wurde, aber ich könnte mir schon vorstellen, dass eine SMT-Implementierung den Threads unterschiedliche Prioritäten zuordnen kann. Dh dass wenn eine Asführungseinheit gerade von beiden Threads "gewollt" wird, dann kann man es IMO sehr leicht so einrichten, dass eben einer der Threads immer gewinnt. Und das sollte man dann auch sinnvollerweise vom OS-Scheduler steuern lassen.Und wie ist das implementiert? Der OS Scheduler muss dem Prozessor doch irgendwie mitteilen, wie sich dieser zu verhalten hat. Gibt es beim P4 irgend ein Flag, das man setzen kann, um die Bevorzugung eines Threads anzuschalten? Wenn ja, dann muss das irgendwo dokumentiert sein. Schließlich sollen die Leute, welche die OS Kernel schreiben, ja auch wissen, wie sie das optimal bewerkstelligen sollen.

Ich weiss, dass der Power5 die Regelung über die Anzahl der zu dekodierenden Befehle macht. Beim P4 mit seinem Trace Cache ist das wahrlich nicht wirklich sinnvoll, zumal der P4 ja sowieso eher das Probleme hat, genügend µOps aus dem Trace Cache zu liefern. Eine Einschränkung der Lieferung von µOps eines Threads (um den anderen zu bevorzugen) wäre hier sicher nicht das richtige Mittel, denn das würde den Flaschenhals nur noch weiter verengen.
Sicherlich gibt es noch andere Möglichkeiten, aber mir ist bisher noch nie irgendwas zu einer hardwaremäßigen Bevorzugung von Threads beim P4 zu Ohren gekommen, weder von Intel noch von anderer Seite.

Außerdem habe ich Grund zur Annahme, dass dies nicht der Fall ist. Angenommen der P4 hätte eine hardwaremäßige Priorisierung der Threads. Warum ist dann beim THG Video der P4 mit HTT schneller beim Fenster öffnen, aber langsamer beim Video codieren? Wenn gleiche Prioritäten im OS Scheduler vorliegen, warum wird dann die Rechenzeit unterschiedlich verteilt? Die Abhängigkeit der Befehlsverteilung vom An- oder Abschalten von HTT sollte doch gerade mit einer hardwaregesteuerten Lösung nicht auftreten.
Ich kann es mir bisher nur dadurch erklären, dass der P4 diese Regelung eben nicht besitzt. Für andersweitige logische Erklärungen bin ich sehr dankbar :)
Original geschrieben von zeckensack
*wühl@intel.com* Ich bin sehr gespannt und interessiert, ob du was findest. Ich werde mich auch mal auf die Suche begeben.
Original geschrieben von Dunkeltier
Schön das du mich wiederholst. Das sagte ich doch bereits, entweder ich habe die Priorität auf's Game gelegt und am Ende meiner Gamesession ist sogut wie nichts encodiert, oder aber ich habe die Priorität aufs encoden gelegt und ruckel mir im Spiel einen ab mit dem AMD. Das schrieb ich doch so schon bereits.Naja, du hast geschrieben, dass das Spiel beim Athlon ruckeln würde. Das ist aber eher unwahrscheinlich, denn Spiele haben meist Real-Time Priorität. Daher wollte ich das noch mal klarstellen.
Original geschrieben von Dunkeltier
und er außerdem den Threads mehr oder weniger die gleiche Priorität zuweist.... was aber nicht im Sinne der Erfindung ist. Ein Thread mit höherer Priorität soll ja gerade den Großteil der Rechenleistung bekommen können, wenn er sie benötigt.
Original geschrieben von Dunkeltier
Nein, der AMD würde entweder im Spiel ruckeln oder mit dem encodieren gar nicht vorankommen! Gloomy schreibt imho Shit.Der erste Fall tritt wegen der hohen Priorität des Spiele-Threads quasie nicht auf. Der letzteren Fall trifft sich genau mit meinen Überlegungen.

Im Übrigen bin ich für konstruktive Kritik offen. Wenn du meinst, dass ich "Shit" schreibe, dann zeige mir aber auch bitte wo und warum.
Original geschrieben von Dunkeltier
Ich kann ja selber zwischen beiden Vergleichen. Und? Mach' doch mal bitte. Hast du UT2003? Aber dann bitte mit CPU Limitierung benchen, d.h. 640x480, 1xAF, 1xAA.

Dunkeltier

2004-02-10, 20:09:04

Um mich kurz zu fassen: Bei AMD-CPUs kann ich entweder das eine (das Spiel) oder das andere (die Videodatei) haben, aber nicht beides gleichzeitig.

Der Intel P4 mit HT hingegen gibt mir beides plus noch ein paar Prozent mehr als ein Standard-P4 (weil er besser seine zu Verfügung stehende Leistung ausnutzt). Das es dabei ab und an mal Situationen gibt wo HT extrem mehr oder extrem weniger bringt ist mir auch klar. Trotz alledem bin ich der Meinung das die Vorteile überwiegen, und darum werde ich auch evtl. den Prescott oder deren Nachfolger ausprobieren.

Im übrigen habe ich derzeit keinen AMD Athlon XP und/ oder AMD Athlon 64 bei mir stehen um Benchmarks zu machen. Aber ich hatte mal einen (bzw. ganz viele :D) AMD Athlon XPs, und weiß noch sehr genau wie das war wenn zum Beispiel unter Windows mal wieder ein Programm hing (abstürzte) und so gut wie nichts mehr ging. Oder auch als ich SETI mit hoher Priorität laufen ließ und dann zocken wollte. Das war nicht schön. :)

Ich find HT jedenfalls nützlich, und den CPU-Hersteller kostet es so gut wie nichts (scheiß auf die 5% mehr Transistoren). Das dies natürlich nicht so performant wie ein Dual-Prozessor System ist dürfte allerdings jedem klar sein. Denn ich kriege ja nicht mehr Recheneinheiten, sie werden nur viel besser ausgenutzt.

BTW, ich habe gar kein Unreal Tournament 2003, weil ich dieses Spiel nicht mag. Ich stehe mehr auf OpenGL Shooter wie das alte Half-Life und die dazugehörigen Mods (TFC, NS, DoD, FA, NS, CS, etc.). ;)

CrazyIvan

2004-02-10, 22:38:24

@ Dunkeltier

Brauchst auch gar keinen Athlon... ;D

Mach doch einfach mal folgendes:

Bench' mit Deinem P4 einmal UT2K3 mit 640x480 1xAA 1xAF ohne jedwede Anwendung im Hintergrund.

Und dann machst Du das Ganze nochmal, wenn Du nen Encoder parallel laufen lässt.

Wenn Blackbird recht hat - wovon ich ehrlich gesagt ausgehe :) - dann wird der P4 mit in letztem Falle nur noch annähernd 50% Framerate haben.

Ein Athlon hätte da noch > 90%, da er die Priorität vom Spiel als Real-Time einstuft, während dem P4 HTT nur 50 % zugesteht.

Dunkeltier

2004-02-10, 22:40:26

Ich zitiere mich nochmals selbst:

Original geschrieben von Dunkeltier
[...]

BTW, ich habe gar kein Unreal Tournament 2003, weil ich dieses Spiel nicht mag. Ich stehe mehr auf OpenGL Shooter wie das alte Half-Life und die dazugehörigen Mods (TFC, NS, DoD, FA, NS, CS, etc.). ;)

Kapische? ;)

CrazyIvan

2004-02-10, 22:45:21

Willst Du Dich nur rausreden, oder warum stellst Du Dich jetzt so an?

Dann nimm halt irgendnen anderen CPU-lastigen Bench. Wirst mir doch net erzählen wollen, dass Du in nem anderen Thread grad nach ner neuen SuperDuperCPU zum Solitaire - Spielen suchst? :asshole:

Dunkeltier

2004-02-10, 22:52:33

Original geschrieben von CrazyIvan
Willst Du Dich nur rausreden, oder warum stellst Du Dich jetzt so an?

Dann nimm halt irgendnen anderen CPU-lastigen Bench. Wirst mir doch net erzählen wollen, dass Du in nem anderen Thread grad nach ner neuen SuperDuperCPU zum Solitaire - Spielen suchst? :asshole:

Doch, ich spiel hauptsächlich ältere Spiele. Oder gelegentlich mal C&C Generals sowie MechCommander. =) Krass, oder? Spiele auf Quake III Engine und UT/ UT2003 sagen mir einfach nicht zu, weswegen ich sie mir auch niemals gekauft habe.

Aber Tribes II und so habe ich auch noch, das macht auch noch Bock. Nun ja, darf man den nicht einen High-End Rechner für Low-End Spiele haben? BTW, ich glaube ich bestelle mir heute Abend noch den Athlon 64.

Kann ich übrigens den 3D Mark 2001 hernehmen? Und was soll ich im Hintergrund laufen lassen, ich sitze vor einen fast leeren Rechner (vor 2 Tagen formatiert). Reicht Seti@home im High-Prio Modus? Oder Prime? Sach was!!!

CrazyIvan

2004-02-10, 22:59:10

Jo, genau...

Lass einfach mal SuperPi (http://pw1.netcom.com/~hjsmith/Pi/Super_Pi.html) (1M) mit und ohne SETI laufen. Wäre gespannt wie'n Flitzebogen...

Dunkeltier

2004-02-10, 23:04:40

Original geschrieben von CrazyIvan
Jo, genau...

Lass einfach mal SuperPi (http://pw1.netcom.com/~hjsmith/Pi/Super_Pi.html) (1M) mit und ohne SETI laufen. Wäre gespannt wie'n Flitzebogen...

Dauert einen Moment, muß mir auch noch Seti wieder saugen und installieren. Wie soll ich die Prios verteilen, beide auf High?

Dunkeltier

2004-02-10, 23:39:29

Ich habe mit SuperPi einen Test 'gefahren'. Zuvor habe ich Seti von der Priorität 'Niedrig' auf 'Normal' gestellt. SuperPi startet übrigens direkt mit der Priorität 'Normal'. Heraus kam beim 1M Test:

mit Seti (beide Programme auf Priorität normal):
56 Sekunden

ohne Seti (beide Programme auf Priorität normal):
42 Sekunden

CrazyIvan

2004-02-11, 01:22:29

Mhhh...

hatte mir das Ergebnis zwar etwas klarer vorgestellt, aber im Prinzip unterstützt das meine Vermutung -> bei Spielen is HT ned so dolle, wenn im Hintergrund noch irgend ein anderen Thread daueraktiv ist.

Klar mag das insgesamt (coderperformance + Spielperformance) besser sein, als n Addi. Allerdings schraubt der Addi den Coder im Hintergrund auf idle zurück, während der P4 beiden "halbwegs" die gleiche Leistung gibt. Das führt nat. zu nem Einbruch im Spiel.

@ Dunkeltier

Kannst ja spaßeshalber noch folgendes benchen:

SETI -> low priority
SuperPi -> high priority

+ umgekehrt :)

Gast

2004-02-11, 04:42:15

Rein interessehalber: Wie würden sich denn zwei Athlon MP bei dem unterstellten Fall, daß man neben dem Video encoden noch ein Spiel zugleich spielt, verhalten?
Ich meine die Athlon MP 2600 sind recht günstig zu bekommen mittlerweile, vielleicht wäre das ja auch eine Lösung für den Threadstarter... ?

Endorphine

2004-02-11, 10:03:52

Wenigstens ist die Diskussion jetzt wieder halbwegs zu den Fakten zurückgekehrt. Ich möchte auch noch mal in die Runde werfen, dass Desktop-Windows per default mit einer internen Höherpriorisierung des Vordergrundtasks ausgeliefert werden (siehe Attachment). Dadurch ist diese Argumentation "mit HT bekommt jeder Task nur 50%" hinfällig. Selbst wenn man also nicht eigenhändig in den Task Scheduler eingreift und Prioritäten verändert bekommt der Videokompressionstask im Hintergrund nur ohnehin leerlaufende Einheitenkapazität der CPU zur Verfügung. Das wird irgendwie von allen vergessen, dass SMT nicht in die klassische serielle Pipeline eingreift, sondern quasi nur einen zweiten in Software zugänglichen virtuellen I/O-Port zur Verfügung stellt, der leerlaufende Kapazitäten nutzbar macht. Irgendwie habe ich das Gefühl, dass viele HT als SMT-Implementierung nicht im Ansatz verstanden haben, wenn ich die Postings so lese. :(

Hauptsache, Intel wird gebashed (da werden dann auch gern SMT-Schwächen der B0-Northwood Xeons in den Vordergrund gestellt, die kein P4-Besitzer je zu Gesicht bekommen kann). Irgendwie traurig.

mrdigital

2004-02-11, 10:20:55

Es ist doch so, dass eine HT CPU für den Windows Scheduler aussieht wie zwei CPUs und der Sheduler deshalb "200%" Rechenleistung verteilen kann, dadurch, dass die zweite CPU nun aber nicht wirklich da ist, sollte der Scheduler nur "150%" verteilen. Oder gibts von Intel einen Patch / Treiber für HT CPUs? Oder hab ich gar was ganz grob falsch verstanden? ;)

CrazyIvan

2004-02-11, 10:44:03

@ Endo

Genau das ist ja der Punkt. AFAIK kann das SMT des P4 nicht zwischen unterschiedlichen Prioritäten unterscheiden.
Daher ist es auch absolut hinfällig, über im Task Manager eingestellte Prioritäten zu reden.
Ich sage auch nicht, dass HT schlecht wäre - ganz im Gegenteil. Wenn sich dadurch wirklich die subjektive Arbeitsgeschwindigkeit erhöht, dann ist das doch okay.

Das Problem liegt nur darin, dass ich als User ein Game schneller bearbeitet haben will, als nen Codiervorgang im Hintergrund. Nur "weiß" der P4 das nicht. Der gibt beiden die gleiche Priorität. Solange der Drop-Down von 120fps auf 80fps ist, kann mir das schnuppe sein. Wenn er aber von 35 auf 18fps fällt, dann hab ich damit ein Problem. IMHO bräuchte der P4 nur ein Flag, mit dem man HT softwareseitig abschalten kann, wenn man eine zeitkritische Anwendung benutzt - IMHO sollte das net soo schwer zu implementieren sein und wäre eigentlich das Optimum.

Endorphine

2004-02-11, 10:55:26

Original geschrieben von mrdigital
Es ist doch so, dass eine HT CPU für den Windows Scheduler aussieht wie zwei CPUs und der Sheduler deshalb "200%" Rechenleistung verteilen kann, dadurch, dass die zweite CPU nun aber nicht wirklich da ist, sollte der Scheduler nur "150%" verteilen. Oder gibts von Intel einen Patch / Treiber für HT CPUs? Oder hab ich gar was ganz grob falsch verstanden? ;) Damit SMT nicht als SMP behandelt wird braucht es natürlich einen SMT-aware Scheduler. Sonst verteilt der Scheduler tatsächlich die Tasks so als wäre SMT = SMP. Und dann kann es tatsächlich zu Durchsatzeinbußen kommen. Das ist aber bekannt und wurde schon 100x hier ausdiskutiert (alle Windows bis w2k und Linux <=2.5 haben keinen SMT-Support), deshalb wundert es mich auch, wieso so getan wird, als würde SMT nirgends unterstützt. WinXP (SP1) und W2k3 bringen einen SMT-aware Scheduler mit, ebenso Linux ab Entwicklerkernel 2.5.

p.s. Intel hat übrigens einen monitor/mwait-Patch (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1542224#post1542224) (PNI/"SSE3") für Linux geschrieben, der in den 2.6 übernommen wurde.

Ist im IA32-Optimierungshandbuch (danke an BlackbirdSR für den Link) auch explizit vermerkt:

Applications with multiple threads use synchronization techniques in
order to ensure correct operation. However, thread synchronization that
are improperly implemented can significantly reduce performance.
Several coding techniques and operating system (OS) calls that are
frequently used for thread synchronization. These include spin-wait
loops, spin-locks, critical sections, to name a few. Choosing the optimal
OS calls for the circumstance and implementing synchronization code
with parallelism in mind are critical in minimizing the cost of handling
thread synchronization.
SSE3 provides two instructions (MONITOR/MWAIT) to help
multithreaded software improve synchronization between multiple
agents. In the first implementation of MONITOR and MWAIT, these
instructions are available to operating system so that operating system
can optimize thread synchronization in different areas. For example, an
operating system can use MONITOR and MWAIT in its system idle
loop (known as C0 loop) to reduce power consumption. An operating
system can also use MONITOR and MWAIT implement its C1 loop to
improve the responsiveness of C1 loop. (See IA-32 Intel Architecture
Software Developer’s Manual, Volume 3.)

Endorphine

2004-02-11, 11:03:45

Original geschrieben von CrazyIvan
@ Endo

Genau das ist ja der Punkt. AFAIK kann das SMT des P4 nicht zwischen unterschiedlichen Prioritäten unterscheiden.
Daher ist es auch absolut hinfällig, über im Task Manager eingestellte Prioritäten zu reden.
Ich sage auch nicht, dass HT schlecht wäre - ganz im Gegenteil. Wenn sich dadurch wirklich die subjektive Arbeitsgeschwindigkeit erhöht, dann ist das doch okay.

Das Problem liegt nur darin, dass ich als User ein Game schneller bearbeitet haben will, als nen Codiervorgang im Hintergrund. Nur "weiß" der P4 das nicht. Der gibt beiden die gleiche Priorität. Solange der Drop-Down von 120fps auf 80fps ist, kann mir das schnuppe sein. Wenn er aber von 35 auf 18fps fällt, dann hab ich damit ein Problem. IMHO bräuchte der P4 nur ein Flag, mit dem man HT softwareseitig abschalten kann, wenn man eine zeitkritische Anwendung benutzt - IMHO sollte das net soo schwer zu implementieren sein und wäre eigentlich das Optimum. SMT greift nicht in die klassische Pipeline ein, sondern stellt nur ohnehin brachliegende (!) Ressourcen weiteren Tasks/Threads zur Verfügung. Der erste Task/Thread (der im Vordergrund) wird _nicht_ langsamer. Der Task Scheduler ist nun gefragt, den virtuellen Prozessor sinnvoll auszulasten. Dafür gibt's optimierte SMT-aware Scheduler.

Langsamer wird's mit SMT nur deshalb, weil mehr Overhead abzuarbeiten ist. Das sind jedoch - wenn überhaupt - nur Leistungsverluste im einstelligen Prozentbereich pro Task/Thread (!). Der Durchsatz nimmt zu. Ich hatte meine "Durchsatz vs. Leistung"-Arien eigentlich schon ad acta gelegt. Muss ich jetzt wieder damit anfangen?

Ich hab beim lesen der meisten Postings hier den Eindruck, als würden viele SMT als sinnloses Konstrukt begreifen, welches die bestehende CPU in zwei Teile teilt. :bonk: Hat denn niemand die ganze bestehende Literatur zu HT nur mal überflogen? =(

Beim Lesen vieler Postings hier merke ich vor allem eines: der Fehler liegt nicht in HT, sondern viel mehr im Verständnis für diese Technik. Komischerweise werde ich den Eindruck nicht los, als ob HT schon mal wesentlich besser verstanden wurde und das jetzt genau die Diskussionen wieder losbrechen, die ganz zum Anfang beim Launch des C1-Step P4 stattfanden. Was ist nur los? :ratlos:

Avalox

2004-02-11, 11:30:29

Hi,

ich weiss ja nicht welche Postings du genau meinst? Stimme mit Dir da aber überein, dass einiges scheinbar quer verstanden wird.
Ich kann dir aber sagen, dass es unter anderen in HT zu massiven synchronisations Schwierigkeiten von Threads kommen kann. Darüber hinaus haben die Threads in HT noch weit aus mehr Möglichkeiten sich gegeneinander ungünstig zu beeinflussen.
Ob man das einfach so als Overhead abhackt? Eher ist die einfachste Implementierung seitens Intel die Problemquelle

Das hat nichts mit Intel Bashing zu tun. Es ist halt so.
Im Augenblick jedenfalls noch. Sicher ist HT besser als gar kein SMT. Meistens jedenfalls.

Endorphine

2004-02-11, 11:36:54

Ich glaub', ich ziehe mich aus der Diskussion einfach zurück und lasse euch im Glauben, dass SMT einfach ein sinnloser Schrott ist, der die CPU physikalisch in zwei Teile teilt, so dass immer nur 50% der Leistung für einen Thread oder Task zur Verfügung steht. Implementiert, um die Massen für dumm zu verkaufen und von den 64-Bit Fähigkeiten vom K8 abzulenken. Das Video von THG ist von Inteltechnikern professionell getürkt und die Flashanimation von Intel ebenfalls. Ich ziehe alle meine falschen Behauptungen zurück und behaupte das Gegenteil.

Es macht einfach keinen Spass mehr. CU.

haifisch1896

2004-02-11, 11:48:42

@Endo

Gereizt?

Endorphine

2004-02-11, 12:13:35

Original geschrieben von hendrikhey
@Endo

Gereizt? Noe. Es ist nur wie der Versuch, in einem Sturzbach stromaufwärts zu schwimmen, wenn scheinbar alle technischen Details von SMT im P4 wieder in Vergessenheit geraten sind und man wieder bei null anfangen muss mit Erklärungen.

Deshalb: ja, SMT ist Müll. Kauft euch AMD-Prozessoren, die sind das einzig Wahre. SMT ist nur ein Marketingtrick von Intel, geschickt mit viel Bestechungsgeld von der gesamten Presse inszeniert, um von den 64-Bit Prozessoren von AMD abzulenken. In der Praxis funktioniert SMT gar nicht, alles läuft nur halb so schnell wie ohne. Überhaupt besteht Intel zu 99% aus Marketingleuten, die ständig neue abstruse Ideen produzieren, wie z. B. das man durch einen Task/Thread nicht ausgelastete Einheiten noch durch einen zweiten (oder weitere) beschäftigen kann, so dass der erste genau so schnell wie vorher läuft und nebenbei noch weitere Threads/Tasks parallel Rechenzeit bekommen. Dass das natürlich nicht funktioniert sollte klar sein. Da bekommen dann die zwei verbliebenen Techniker bei Intel diesen Quatsch vorgesetzt und müssen die Täuschung irgendwie in Silizium pressen, welches dann bei TSMC gefertigt wird (deshalb auch die Prescottverspätung analog zum NV30). Also teilen sie den Prozessor physikalisch in zwei Hälften und schon ist das Problem gelöst. Bestehende Software erkennt zwei Prozessoren und die Presse kann man ja kaufen, damit sie von Intel inszenierte Videos online setzt. Alle anderen werden mit viel Geld ebenfalls gekauft. Zum Glück hat noch kein Kunde bemerkt, dass SMT nicht funktioniert. Durch permanente Intelwerbung bekommt das Unterbewusstsein der Kunden eingehämmert, dass SMT funktioniert.

Überhaupt ist Intel eine globale Verschwörungsorganisation, die mit Terroristen zusammenarbeitet. Intel muss zerschlagen werden (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1543658#post1543658).

BlackBirdSR

2004-02-11, 12:19:50

Ja, dieses SMT gebahse geht mir auch manchmal gegen den Strich...

warum kümmern wir uns nicht um wichtigere Sachen..
sowas wie: Warum hat Prescott einen 2. ALU Block, und sind die FAST-ALUs noch vorhanden?

Mordred

2004-02-11, 12:22:28

Oh man ein verzweifelter Endo sowas sieht man auch selten ;>

Aber so ganz versteh ich das BAshiong hier auch net. Intel baut ebenso gute CPUs wie AMD nur nach anderem Prinzip. Wenn beides funktioniert dann kanns doch egal sein. Naja und im Falle von HT hat amd derzeit noch garnix dabei von daher hat intel da atm nen Vorteil weil nutzlos ist HT nun wriklich nicht.

Nja aber das hat endo schon zu genüge erläutert ;>

Endorphine

2004-02-11, 12:26:51

BlackBirdSR,

das IA32 Optimization Manual ist übrigens fantastisch, danke für den Link nochmal. :) Wenn ich das durch hab werd ich wohl wieder einiges grundlegend besser verstehen.

BlackBirdSR

2004-02-11, 12:32:43

Original geschrieben von Endorphine
BlackBirdSR,

das IA32 Optimization Manual ist übrigens fantastisch, danke für den Link nochmal. :) Wenn ich das durch hab werd ich wohl wieder einiges grundlegend besser verstehen.

ähm, ja.. gern geschehen, wenn ich auch nicht weiss wo ich das verlinkt habe :)

Edit:
ok ist mir wieder eingefallen..
gut das mein Kühler verschraubt ist, sonst würde ich ihn vergessen ;D

Avalox

2004-02-11, 13:06:50

gebashe? Begründete Kritik. AMD hin; AMD her.

Aber zum Thema Temp. des AMD64. Das wollte ich noch schreiben, bin aber von abgekommen.

Da die Kühler Befestigungen nun beim Sockel 754 ja besonders im Hersteller Ermessen liegt, fällt diese schon mal sehr billig aus. Bei meinen Arctic Cooling Kühler ist dieses zumindest so. Nach dem ersten Schreck der hohen 64Bit Temps., hatte ich erstmal den Sitz des Kühlers kontrolliert. Eine Schraube lies sich noch ein klein wenig bis zum Erreichen der Markierung festziehen und die Temperatur sank doch glatt danach um ein paar Grad. (das aber schon vor den Temperaturen die ich gepostet habe).
Aber vielleicht ein Tipp an Leute mit zu hohen AMD64 Temps. Zumal ich angenommen hatte, dass ich den Kühler ordentlich verschraubt habe.

Gast

2004-02-11, 14:42:32

Original geschrieben von Endorphine
Noe. Es ist nur wie der Versuch, in einem Sturzbach stromaufwärts zu schwimmen, wenn scheinbar alle technischen Details von SMT im P4 wieder in Vergessenheit geraten sind und man wieder bei null anfangen muss mit Erklärungen.

Deshalb: ja, SMT ist Müll. Kauft euch AMD-Prozessoren, die sind das einzig Wahre. SMT ist nur ein Marketingtrick von Intel, geschickt mit viel Bestechungsgeld von der gesamten Presse inszeniert, um von den 64-Bit Prozessoren von AMD abzulenken. In der Praxis funktioniert SMT gar nicht, alles läuft nur halb so schnell wie ohne. Überhaupt besteht Intel zu 99% aus Marketingleuten, die ständig neue abstruse Ideen produzieren, wie z. B. das man durch einen Task/Thread nicht ausgelastete Einheiten noch durch einen zweiten (oder weitere) beschäftigen kann, so dass der erste genau so schnell wie vorher läuft und nebenbei noch weitere Threads/Tasks parallel Rechenzeit bekommen. Dass das natürlich nicht funktioniert sollte klar sein. Da bekommen dann die zwei verbliebenen Techniker bei Intel diesen Quatsch vorgesetzt und müssen die Täuschung irgendwie in Silizium pressen, welches dann bei TSMC gefertigt wird (deshalb auch die Prescottverspätung analog zum NV30). Also teilen sie den Prozessor physikalisch in zwei Hälften und schon ist das Problem gelöst. Bestehende Software erkennt zwei Prozessoren und die Presse kann man ja kaufen, damit sie von Intel inszenierte Videos online setzt. Alle anderen werden mit viel Geld ebenfalls gekauft. Zum Glück hat noch kein Kunde bemerkt, dass SMT nicht funktioniert. Durch permanente Intelwerbung bekommt das Unterbewusstsein der Kunden eingehämmert, dass SMT funktioniert.

Überhaupt ist Intel eine globale Verschwörungsorganisation, die mit Terroristen zusammenarbeitet. Intel muss zerschlagen werden (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1543658#post1543658).
Das dumme ist da hinter all dem zumindestens Halbwahrheiten, die als übertriebene Fakten wiedergegeben werden.
Mit AMD64 dürfte wie bei Intels HT(Ihr könnts auch gern anders nennen) die Auslastung und somit auch die Temperatur steigen. Aber um 20°C?:kratz::ratlos:
Wie gross der Unterschied wohl bei Wakü wohl wäre?

Dunkeltier

2004-02-11, 17:03:56

Original geschrieben von CrazyIvan
Mhhh...

hatte mir das Ergebnis zwar etwas klarer vorgestellt, aber im Prinzip unterstützt das meine Vermutung -> bei Spielen is HT ned so dolle, wenn im Hintergrund noch irgend ein anderen Thread daueraktiv ist.

Klar mag das insgesamt (coderperformance + Spielperformance) besser sein, als n Addi. Allerdings schraubt der Addi den Coder im Hintergrund auf idle zurück, während der P4 beiden "halbwegs" die gleiche Leistung gibt. Das führt nat. zu nem Einbruch im Spiel.

@ Dunkeltier

Kannst ja spaßeshalber noch folgendes benchen:

SETI -> low priority
SuperPi -> high priority

+ umgekehrt :)

Mach ich, die Ergebnisse editiere ich gleich hier hin...

Seti low/ SuperPi high (1M): 56 Sekunden
Seti high/ SuperPi low (1M): 56 Sekunden

Trotz Echtzeit-Prioisierung bleibt das System smooth und bedienbar. Man kann mit einer einzelnen nicht auf HT ausgelegten Applikation die CPU niemals ganz auslasten. Erstaunlich.

P.S.: In 2 Stunden und 45 Minuten spuckt mein Rechner immer gleichzeitig zwei WUs von Seti aus, insofern ich 2 Seti-Threads laufen lasse. =)

Soll ich mal SuperPi gegen SuperPi antreten lassen?

Gast

2004-02-11, 18:41:04

SuperPI vs SETI vs SuperPI*eg*
Dann würden nämlich mehr als Zwei Treads gleichzeitig laufen.

Dunkeltier

2004-02-11, 18:49:07

Original geschrieben von Gast
SuperPI vs SETI vs SuperPI*eg*
Dann würden nämlich mehr als Zwei Treads gleichzeitig laufen.

Ok, habe ich gemacht. Alle drei rechenintensiven Threads habe ich mit der Priorität 'normal' laufen lassen.

Ergebnis SuperPi 'normal' #1: 1 Minute & 32 Sekunden
Ergebnis SuperPi 'normal' #2: 1 Minute & 32 Sekunden
Ergebnis Seti@home 'normal': -

Avalox

2004-02-11, 20:15:39

Original geschrieben von Gast
SuperPI vs SETI vs SuperPI*eg*
Dann würden nämlich mehr als Zwei Treads gleichzeitig laufen.

Es laufen auch so mehr als zwei Threads. Du gehst nur von den Anwendungen aus.

Godmode

2004-02-11, 20:18:47

schau dir mal die vids auf www.tomshardware.de an da siehst du echt gut wieviel ht wirklich bringt.

GloomY

2004-02-11, 20:34:14

Original geschrieben von Endorphine
Ich möchte auch noch mal in die Runde werfen, dass Desktop-Windows per default mit einer internen Höherpriorisierung des Vordergrundtasks ausgeliefert werden (siehe Attachment). Dadurch ist diese Argumentation "mit HT bekommt jeder Task nur 50%" hinfällig.Du hast es immer noch nicht verstanden. Du kannst in dieser Situation rein gar nichts über Prioritäten im OS regeln.

Ich hol' mal weit aus: In wie fern kann der OS Scheduler steuern, wie viel Rechenleistung ein Thread bekommt? Er macht es durch eine zeitweise Aufteilung. Jeder Thread bekommt also für einen Bruchteil einer Zeiteinheit die CPU zur Verfügung. Die Rechenleistung ist proportional zu der Zeit, die ein einzelner Thread die CPU benutzen kann. Durch die Nutzungsdauer wird die Verteilung der Rechenzeit gereglt. Soweit klar?

Jetzt haben wir aber das Problem, dass in einer Situation, in der es nur zwei Threads gibt, welche die CPU nutzen wollen, der Scheduler keinen Thread hat, mit dem er die beiden Threads tauschen kann. Der Prozessor führt immer zwei Threads aus, wie soll der Scheduler dann die Nutzungsdauer regeln, um eine priorisierte Verteilung der Rechenleistung zu ermöglichen? Er kann es schlichtweg nicht, selbst wenn er es wollte. Er muss beide Threads ausführen und kann diese nicht durchwechseln. Das resultiert in einer gleichschnellen Abarbeitung beider Threads.

Ließ dir vielleicht einfach nochmal meine Postings durch, vielleicht wird es dann klarer für dich. So schlimm können diese nun auch nicht sein, Zeckensack hat's schließlich auch kapiert. ;)
Original geschrieben von Endorphine
Selbst wenn man also nicht eigenhändig in den Task Scheduler eingreift und Prioritäten verändert bekommt der Videokompressionstask im Hintergrund nur ohnehin leerlaufende Einheitenkapazität der CPU zur Verfügung.Hast du meinen Einwand auf der Seite davor gelesen? Ich wiederhole mich auch für dich gerne nochmal: Wie zum Teufel soll die CPU wissen, welchen Thread sie bevorzugen soll?
Original geschrieben von Endorphine
Hauptsache, Intel wird gebashed (da werden dann auch gern SMT-Schwächen der B0-Northwood Xeons in den Vordergrund gestellt, die kein P4-Besitzer je zu Gesicht bekommen kann). Irgendwie traurig. Ist ein Xeon kein P4? Hatten die Xeons mit B0 Stepping nicht große Probleme mit der Performance (http://www.2cpu.com/Hardware/ht_analysis/3.html)?

Entschuldigung, wenn ich diese Schwäche in Zusammenhang einer positiven Weiterentwicklung für HTT genannt habe. Es war halt nun mal so, dass die erste HTT Implementation in den Xeons mit B0 zu finden war und diese auf deutsch gesagt kaum was getaugt hat. Das darf man ja wohl aussprechen, besonders wenn man im gleichen Zusammenhang darauf verweist, in wie fern sich die Sache in der Zwischenzeit gebessert hat. Jaja, "hauptsache Intel wird gebashed". *Kopfschüttel*

GloomY

2004-02-11, 20:50:56

Original geschrieben von Avalox
Es laufen auch so mehr als zwei Threads. Du gehst nur von den Anwendungen aus. Der Punkt ist aber, dass diese keine Rechenzeit brauchen. Wenn so ein Thread die CPU nutzen darf, dann gibt er die Kontrolle sofort wieder an den OS Scheduler ab.

Diese Threads, die quasie nur im Speicher liegen und die CPU nicht nutzen, kann man bei solchen Überlegungen vernachlässigen. Sie haben keinen Einfluß auf die Verteilung der Rechenzeit, da sie sofort wenn sie welche bekommen, diese wieder zur Verfügung stellen.

Außerdem ist der Scheduler ja auch nicht dumm ;) Wenn ein Thread vermehrt die CPU nicht nutzen wollte, so wird der Scheduler ihn für eine gewisse Zeit nicht die CPU zur Verfügung stellen. Er wird diesem Thread erst nach einer längeren Zeit wieder die CPU zuteilen.
Original geschrieben von Dunkeltier
Ok, habe ich gemacht. Alle drei rechenintensiven Threads habe ich mit der Priorität 'normal' laufen lassen.

Ergebnis SuperPi 'normal' #1: 1 Minute & 32 Sekunden
Ergebnis SuperPi 'normal' #2: 1 Minute & 32 Sekunden
Ergebnis Seti@home 'normal': - Dunkeltier: Du musst logischerweise die Geschwindigkeit von allen Threads messen.

Zusätzlich dazu würde ich aus rein messtechnischen Gründen die Messzeit lieber etwas höher wählen, um den relativen Fehler gering zu halten. Du musst schliesslich nachdem du einen Thread gestartet hast, noch mit einem Eingabegerät den anderen Thread starten, wobei dieser Vorgang natürlich auch Rechenzeit beansprucht. Eine längere Messzeit lässt diesen Fehler im Vergleich dazu kleiner werden, somit wird das Ergebnis genauer. :)
Daher schlage ich vor, dass du nicht den 1M Test nimmst, sondern mindestens den 8M Test, wenn nicht sogar den 32 M Test (eine Instanz dürfte so etwa eine Stunde dauern).

Ich wäre dir ebenso verbunden, wenn du einfach mal folgendes mit und ohne HTT Benchen könntest: Zwei Instanzen Superpi, einer mit Real-time Priorität (höchste), der andere idle (niedrigste).

Und bitte bitte bitte ALLE anderen Threads zumachen. Auch den Taskmanager, da dieser auch Rechenleistung zugeteilt bekommt. Andernfalls gibt es nämlich wieder mehr als zwei rechenintensive Threads, wonach die Vorraussetzungen für das Verhalten nicht erfüllt wären.

Endorphine

2004-02-12, 10:04:24

:( :sick:

Avalox

2004-02-12, 13:35:33

[SIZE=1]Original geschrieben von GloomY
Der Punkt ist aber, dass diese keine Rechenzeit brauchen. Wenn so ein Thread die CPU nutzen darf, dann gibt er die Kontrolle sofort wieder an den OS Scheduler ab.

Diese Threads, die quasie nur im Speicher liegen und die CPU nicht nutzen, kann man bei solchen Überlegungen vernachlässigen. Sie haben keinen Einfluß auf die Verteilung der Rechenzeit, da sie sofort wenn sie welche bekommen, diese wieder zur Verfügung stellen.

Das bedeutet aber immer wieder Register-Neuladen.
Es dürfe einen nicht unerheblichen Unterschied ausmachen, ob sich ein Thread über längere Zeit in einem Registersatz tummeln kann. Das dürfte grade bei den neueren CPUs, wo die Cache Latenzen ansteigen, immer mehr von Bedeutung gewinnen.

Habe selber mit HT spielen und probieren können.
Besonders interessant ist es mit verschiedenen Anwendungen unterschiedlicher Ausrichtung zu probieren. Dabei dann auch ruhig mal HT im Bios deaktivieren.

Haben es auch mal in der typischste Konstellation Encoder und Spiel probiert. Anspruchvollere Spiele brachen in der Performance stark ein. Für den einen mag das Spiel vielleicht noch toll sein, für den anderen ist es dann schlicht unzumutbar. Je nach Anspruch.

@bans3i

Toms Hardware hat den Einstieg zum HT Artikel "Low-cost Dual-Processing" genannt. Eine ziemlich disqualifizierende Aussage.
Ich kann der Seite nichts abgwinnen. Wer zum Fazit des des "Prescott Tests" einleitend schreibt "Was Prescott kann, ist nebensächlich". Das kann einfach nicht sein.

Auch wenn sich, jetzt dem ein oder anderen der Magen umdreht.

Die besonderen Beziehungen und Methoden von Intel zu gewissen Webseiten wurden mal kurz in der c’t angesprochen, worauf hin zufälliger Weise ein Bericht über den P4EE auf Tomshardware mit dem erwähnten Inhalt vom Netz genommen wurde und etwas später überarbeitet wieder erschien.

Nun ist TomsHardware zum Glück nicht die einzigste Quelle.