|
|
|
CREON
aus Dormagen offline
OC God 23 Jahre dabei !
AMD Ryzen 7 3500 MHz @ 3500 MHz 70°C mit 1.1 Volt
|
Also: Hyperthreading nutzt einen Teil des Prozessors als virtuellen zweiten Prozessor, normalerweise macht das eine Anwendung nicht langsamer, es wird ja nur brachliegende Zeit weiterverwendet. Wenn Seti jetzt aber kein Multithreading unterstützt (was ich mir nicht vorstellen kann), dann könnte es eventuell wirklich etwas langsamer werden. Angenommen Seti verwendet nur einen Thread, im HT Modus würde dann Seti etwas langsamer laufen, andere laufende Vordergrundprozesse würden dafür aber extrem beschleunigt, da sie quasi einen eigenen (aber langsamen) Prozessor zur verfügung hätten, während Seti den anderen Prozessor komplett auslastet. Auch wenn Seti etwas an Punkten verliert, ist wenigstens der PC weiterhin nebenbei benutzbar. Um dann aus Seti maximale Performance zu erreichen, schaltet man einfach die prozesspriorität im taskmanager von seti auf hoch. trotzdem müßtest du mit dem gerät noch arbeiten können, da dir eben für alle anderen prozesse quasi nen zweiter prozessor zur verfügung steht. das wäre ohne hyperthreading nicht denkbar. Hier wäre der PC dann unbenutzbar langsam, ein paar Setiprozente hin oder her... Soweit allerdings nur bei Singlethreating. Ich vermute aber einfach mal, dass Seti nen Multithreating Programm ist, und diese laufen eigentlich auf HT Prozessoren IMMER schneller (genau wie zwei einzelne, rechenintensive Singlethreatingprogramme gleichzeitig ausgeführt mit HT schneller sind) Ich kann mir höchstens vorstellen, dass der laptop deshalb langsamer läuft, weil laptops im allgemeinen langsamer laufen als gleichgetaktete desktop rechner. insbesondere wenn sie nicht im netzbetrieb hängen. schaltest du mit der /onecpu option einen prozessor ganz ab, so wird die brachliegende leistung generell nicht mehr als 2. cpu weiterbenutzt. der rechner verhält sich also wirklich so wie ein p4 ohne hyperthreading. übrigens braucht man unter windows das sp1 um hyperthreading nutzen zu können. (Geändert von CREON um 20:45 am Juni 16, 2004)
Die Zensur ist das lebendige Eingeständnis des Herrschenden, dass er verdummte Sklaven treten, aber keine freien Völker regieren kann.
|
Beiträge gesamt: 4050 | Durchschnitt: 0 Postings pro Tag Registrierung: Mai 2001 | Dabei seit: 8677 Tagen | Erstellt: 18:23 am 16. Juni 2004
|
|
Eisenblut
offline
OC God 22 Jahre dabei !
|
Wenn man sich ansieht, wie man ein Programm umstellen muss, um es für mehrere Threads vorzubereiten, dann sind schon einige Eingriffe notwendig. Auch umgekehrt können die nötigen zusätzlichen Hooks von CPU-Seite ein Programm ausbremsen, gerade, wenn es sehr allergisch auf Verzweigungen reagiert. Insofern kann es sein, dass S@H auf einem P4 HT langsamer läuft als auf einem "normalem" P4. Was mich etwas überrascht, ist die Verwendung des Singleprozessorkernels beim HT, deshalb bringt es nichts, die HAL zuwechseln. Ob man Seti auf dem P4HT noch fixer hinbekommt, würde ich in einem entsprechenden Forum nachfragen. Ich könnte es zwar analysieren, aber dafür bezahlt mich ja keiner Ich muss weg, treffe mich um acht mit Freunden, deshalb erst einmal
With all due respect Sir, but...
|
Beiträge gesamt: 3756 | Durchschnitt: 0 Postings pro Tag Registrierung: Okt. 2002 | Dabei seit: 8178 Tagen | Erstellt: 19:48 am 16. Juni 2004
|
|
|
|
|
|
Eisenblut
offline
OC God 22 Jahre dabei !
|
@Kalli Wenn du nachlesen willst, was ich mit den verschiedenen HALs vorhatte, dann kann dir diese Seite einen Einblick geben. @CREON Jede Aufteilung eines Programm in mehrere Threads erfordert erst einmal einen gewissen Overhead, denn einerseits müssen die Daten und Prozesse erst einmal aufgeteilt werden, aber aufwändiger ist das Zusammenbringen der verschiedenen Ergebnisse. Aber meist lohnt sich der Aufwand, eigentlich ist es sogar sehr selten, das selbst ohne Optimierung ein Nachteil eintritt. Wenn man aber ein sehr spezielles mathematisches Problem hat, bei dem die Ergebnisse der meisten Rechenschritte direkte Auswirkungen auf die nächsten Instruktionen haben, dann kann eine CPU bei dem ständigen Versuch, doch irgendetwas zu parallelisieren, sich ziemlich ausbremsen, da andauernd spekulative Ergebnisse errechnet werden, die wieder verworfen werden müssen. Damit wird aber auch jedesmal die Pipeline resettet, was böse auf die Performance durchschlägt. Aber um das wirklich zu erklären, müsste man viel tiefer ins Detail einsteigen. Ganz nützlich sind diese Texte: 1, 2. 2 ist aber harter Stoff, selbst für Programmierer. With all due respect Sir, but...
|
Beiträge gesamt: 3756 | Durchschnitt: 0 Postings pro Tag Registrierung: Okt. 2002 | Dabei seit: 8178 Tagen | Erstellt: 2:05 am 17. Juni 2004
|
|
|
|