Benchmarkmärchen mit Fortsetzung...
- Ersteller Bokill
- Erstellt am
- Status
rkinet
Grand Admiral Special
Der P-M läuft auch bei höheren Spannungen voll linear mit dem Takt, also kein 'Sättigungsbereich' erkennbar.
Die absoluten Werte muss man wg. nur 'Prime' (THX i_hasser) ziemlich in Frage stellen.
Intel hätte den Dothan sonst sicherlich nicht mit 21 Watt, sondern eher 15-17 Watt off. spezifiziert.
Die guten Werte, beim Winchester ja auch bei Messungen recht gut, lassen für 90nm /Dual-Core doch geringe thermische Probleme auch bei Taktraten um 2,5 GHz erwarten.
na, das hätte aber auch und vor allem in den dothan-thread gehört...vielleicht mache ich es noch, vielleicht auch nicht... ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
so oder so: die geringen stromverbrauchswerte sind schon imponierend. aber es bleibt alles beim alten: wird intel mit dem p-m in die puschen kommen oder nicht?
ich habe da meine zweifel...
so oder so: die geringen stromverbrauchswerte sind schon imponierend. aber es bleibt alles beim alten: wird intel mit dem p-m in die puschen kommen oder nicht?
ich habe da meine zweifel...
@i_hasser
Deine Meinung zum PentiumM ist hier ja bekannt.
Was Simon aber unterscheidet zu vielen Hobbybenchern ist, dass er seine Ergebnisse nachvollziehbar macht. Gleiches OS, Treiber etct. da hatten wir vor längerer Zeit grottige Benches, die waren so unmethodisch, dass ich sie NICHT verlinken werden (Thread ist im OC-Forum mit Links zu dem Gamestarforum).
Simon hat im Laufe der Zeit so einige Benches gemacht, dass Prime ein bestimmtes Profil hat ist auch Simon bekannt. Nur Geduld ich erwarte da weitere Benches
.
Was nett an den Benches ist, dass Simon an vielen Eistellungen spielt (FSB, Cache, Kerntakt) und zwar auf der gleichen Plattform. Meine Hoffnung ist, dass dieses auch mit einem P4, K8 so gemacht wird. Dann kann man schön vergleichen. Idealerweise liegt so auch das gleiche Messequipment vor, mit dem gleichen Netzteil?!?
Ein Problem bleibt aber, wo kann man genau den Strombedarf ermitteln? Unabhängig vom Netzteil, Grafikkarte etct. ?
@Treverer
Es sind diverse Benchthreads mit dem PentiumM hier im Umlauf (natürlich auch Treverer`s die entdeckung der langsamkeit sowie Treverer`s dothan = intels zukuft? , irgendwann entarteten viele andere PentiumM-Threads immer wieder. Der PentiumM scheint deutlich die Nerven einiger P3D`ler zu reizen.
Da dieser Thread aber eine grosse Fundgrube von Benches ist, zum Teil auch systematisch hinterfragt (erstere Seiten), erhoffe ich mir da etwas mehr Ruhe und mehr Gelassenheit in der Diskussion.
Man darf ja nicht vergessen, das die Gleitkommaeinheit des PentiumM zwar schwächer im Vergleich zum K8 ist, aber soooo schwach auch nicht (aber immer noch Welten besser wie vom VIA C3/C5).
Simon zeigte auch sehr deutlich den Einfluss der Cachegrösse, und auch die Abhängigkeit des FSB auf die Rechen-Leistung des PentiumM. intel hat ein Problem, wenn sie den FSB hochdrehen und auch die Spannung heraufsetzen, dann verbraucht er mehr ... und mit der aktuellen Generation des Winchester (Turionlinie) nähert sich der K8 in Riesenschritten.
Ein Goodie hat der PentiumM aber, er kann sich teilweise abschalten, was nochmals den Strombedarf reduziert. Ob der Turion derzeit dieses Feature hat glaube ich nicht ... aber gänzlich ausschliessen kann ich das auch nicht. In ferner Zukunft hat aber AMD auch so etwas ähnliches vor siehe Analyst Day 2004 (Achtung selbstreferenzierender Bokill-Link).
So ist doch etwas mehr OT geworden wie beabsichtigt. Eigentlich geht es um die Benches an sich, nicht um Perspektiven, oder um schlechte Farbgebung der Benchtabellen.
MFG Bokill
Deine Meinung zum PentiumM ist hier ja bekannt.
Was Simon aber unterscheidet zu vielen Hobbybenchern ist, dass er seine Ergebnisse nachvollziehbar macht. Gleiches OS, Treiber etct. da hatten wir vor längerer Zeit grottige Benches, die waren so unmethodisch, dass ich sie NICHT verlinken werden (Thread ist im OC-Forum mit Links zu dem Gamestarforum).
Simon hat im Laufe der Zeit so einige Benches gemacht, dass Prime ein bestimmtes Profil hat ist auch Simon bekannt. Nur Geduld ich erwarte da weitere Benches
.Was nett an den Benches ist, dass Simon an vielen Eistellungen spielt (FSB, Cache, Kerntakt) und zwar auf der gleichen Plattform. Meine Hoffnung ist, dass dieses auch mit einem P4, K8 so gemacht wird. Dann kann man schön vergleichen. Idealerweise liegt so auch das gleiche Messequipment vor, mit dem gleichen Netzteil?!?
Ein Problem bleibt aber, wo kann man genau den Strombedarf ermitteln? Unabhängig vom Netzteil, Grafikkarte etct. ?
@Treverer
Es sind diverse Benchthreads mit dem PentiumM hier im Umlauf (natürlich auch Treverer`s die entdeckung der langsamkeit sowie Treverer`s dothan = intels zukuft? , irgendwann entarteten viele andere PentiumM-Threads immer wieder. Der PentiumM scheint deutlich die Nerven einiger P3D`ler zu reizen.
Da dieser Thread aber eine grosse Fundgrube von Benches ist, zum Teil auch systematisch hinterfragt (erstere Seiten), erhoffe ich mir da etwas mehr Ruhe und mehr Gelassenheit in der Diskussion.
Man darf ja nicht vergessen, das die Gleitkommaeinheit des PentiumM zwar schwächer im Vergleich zum K8 ist, aber soooo schwach auch nicht (aber immer noch Welten besser wie vom VIA C3/C5).
Simon zeigte auch sehr deutlich den Einfluss der Cachegrösse, und auch die Abhängigkeit des FSB auf die Rechen-Leistung des PentiumM. intel hat ein Problem, wenn sie den FSB hochdrehen und auch die Spannung heraufsetzen, dann verbraucht er mehr ... und mit der aktuellen Generation des Winchester (Turionlinie) nähert sich der K8 in Riesenschritten.
Ein Goodie hat der PentiumM aber, er kann sich teilweise abschalten, was nochmals den Strombedarf reduziert. Ob der Turion derzeit dieses Feature hat glaube ich nicht ... aber gänzlich ausschliessen kann ich das auch nicht. In ferner Zukunft hat aber AMD auch so etwas ähnliches vor siehe Analyst Day 2004 (Achtung selbstreferenzierender Bokill-Link).
Und Transmeta hat ja mit LongRun2 (Achtung selbstrefenzierender Bokill-Link) ja auch noch was feines zum Lizensieren.
So ist doch etwas mehr OT geworden wie beabsichtigt. Eigentlich geht es um die Benches an sich, nicht um Perspektiven, oder um schlechte Farbgebung der Benchtabellen.
MFG Bokill
Zuletzt bearbeitet:
Die Junxx von Computerbase haben erneut Benches mit Speicher gemacht. Die Basis bildete ein i915 Grantsdale die beide Speicherarten ansteuern kann. Die CPU ist ein 3,2 GHz Prescott.
Das MSI 915P Mainboard ermöglicht einen Vergleich beider Speichersorten (aber nicht zugleich). Andere Boards geben Auskunft wie glaubwürdig die MSI 915P Benches sind.
Bei der Software ist mir aufgefallen, dass neben zwei Packern und einer dicken Office-Benchmarksuite Sysmark 2004 auch etwas seltenes drin ist.
SANDRA 2004 zeigt dezente Unterschiede:
Bei einem Spiel schrumpfen die Unterschiede weg auf nahezu schlechtestens 2%.
Bei der Konvertierung SXW-Dokument mit OpenOffice zu einer PDF-Datei ist maximal eine Steigerung von ca. 8% zu sehen, in etwa vergleichbar mit SANDRA Speicher Benches.
Bei den Encodingbenches versprach ich mir deutliche Vorteile von DDR2, aber die sind gar nicht so gross. Bei der Konversion von vob-Format in ein DivX 5.1 sind es bestenfalls ca. 6%, von einer VOB-Datei eine SVCD sind es ca. bestenfalls 4%, bei Lame hingegen scheint DRR2 deutlichere Vorteile zu haben mit ca. 10%.
Details siehe Anwendungen und Encoding.
Bei Quake3 zeigt sich aber deutlich, dass DDR1 noch lange nicht tot ist.
Fazit
Bei DDR2-667 -> PC2 5300 könnte da die Differenz aber schon deutlicher ausfallen. Man darf gespannt sein, wie gross dann bei Spielen die Unterschiede ausfallen.
Bei diesem Test muss am aber auch berücksichtigen, dass mit einer leistungsstärkeren Grafikkarte eventuell bei den Spielen eine grösse Differenz festzustellen wäre.
Ich denke aber, dass da nicht wesentlich grössere Benches dabei herausgekommen wären. Spiele sind deutlich komplexer, was Speichernutzung angeht. Das zeigt der Quake3 Bench ja sehr gut, da konnte Spitzen PC3200 gut Anschluss halten mit den neuen derzeitigen DDR2 Spitzenmodellen PC2 4200.
Bei PC2 5300 hingegen wird es schon deutlich zugunsten DDR2 kippen, aber dann sind wir ja schon im Jahre 2006, wo AMD auch schon DDR2/DDR3/FB-DIMM in Planung hat. -> Analyst Day 2004 mit dem PDF von Fred Weber (Seiten 10 ff). Weiteres dort bei Tyan und AMD aus dem Thread Die Opteron Zukunft, kann AMD überleben? Seitenverzeichnis
Zur Benchmarkübersicht von Benchmarkmärchen
MFG Bokill
Testsystem
Das MSI 915P Mainboard ermöglicht einen Vergleich beider Speichersorten (aber nicht zugleich). Andere Boards geben Auskunft wie glaubwürdig die MSI 915P Benches sind.
Bei der Software ist mir aufgefallen, dass neben zwei Packern und einer dicken Office-Benchmarksuite Sysmark 2004 auch etwas seltenes drin ist.
mal was anderes, sogar aus der Praxis. Für Benchfetischisten sind aber auch die üblichen verdächtigen Benches auch drin.
SANDRA 2004 zeigt dezente Unterschiede:
Die Junxx von Sandra haben es geschafft Code zu schreiben, der Vorteile von DDR2 zeigt. Bei gleichem Takt im ungstigstem Fall bis zu ca. knapp 10% [DDR2-400 3-3-3-12 4.891 vs DDR400 3-4-4-8 4.516], mit DDR400 2-2-2-5 sind`s dann ca. 5%.
Bei einem Spiel schrumpfen die Unterschiede weg auf nahezu schlechtestens 2%.
Bei der Konvertierung SXW-Dokument mit OpenOffice zu einer PDF-Datei ist maximal eine Steigerung von ca. 8% zu sehen, in etwa vergleichbar mit SANDRA Speicher Benches.
Der Sysmark zeigt hingegen so gut wie keine Vorteile, da sind es bestenfalls [DDR400 3-4-4-8 3:30 vs DDR2-533 3-3-3-12 3:15] etwas um die 3%
Bei den Encodingbenches versprach ich mir deutliche Vorteile von DDR2, aber die sind gar nicht so gross. Bei der Konversion von vob-Format in ein DivX 5.1 sind es bestenfalls ca. 6%, von einer VOB-Datei eine SVCD sind es ca. bestenfalls 4%, bei Lame hingegen scheint DRR2 deutlichere Vorteile zu haben mit ca. 10%.
Details siehe Anwendungen und Encoding.
Bei Quake3 zeigt sich aber deutlich, dass DDR1 noch lange nicht tot ist.
, wie auch bei den anderen Spielen.
Fazit
Bei DDR2-667 -> PC2 5300 könnte da die Differenz aber schon deutlicher ausfallen. Man darf gespannt sein, wie gross dann bei Spielen die Unterschiede ausfallen.
Bei diesem Test muss am aber auch berücksichtigen, dass mit einer leistungsstärkeren Grafikkarte eventuell bei den Spielen eine grösse Differenz festzustellen wäre.
Ich denke aber, dass da nicht wesentlich grössere Benches dabei herausgekommen wären. Spiele sind deutlich komplexer, was Speichernutzung angeht. Das zeigt der Quake3 Bench ja sehr gut, da konnte Spitzen PC3200 gut Anschluss halten mit den neuen derzeitigen DDR2 Spitzenmodellen PC2 4200.
Bei PC2 5300 hingegen wird es schon deutlich zugunsten DDR2 kippen, aber dann sind wir ja schon im Jahre 2006, wo AMD auch schon DDR2/DDR3/FB-DIMM in Planung hat. -> Analyst Day 2004 mit dem PDF von Fred Weber (Seiten 10 ff). Weiteres dort bei Tyan und AMD aus dem Thread Die Opteron Zukunft, kann AMD überleben? Seitenverzeichnis
Zur Benchmarkübersicht von Benchmarkmärchen
MFG Bokill
Zuletzt bearbeitet:
derDUKE
Grand Admiral Special
Man darf auch nicht vergessen, dass es sich ja hier um ein Intel-System handelt.
Der A64 scheint ja generell auf bessere Latenzen zu stehen, sodass hier momentan DDR2 selbst in der aktuell schnellsten Stufe nichts bringen wird. Kein Wunder, dass AMD das nicht in seiner Planung für 2005 hat.
Der A64 scheint ja generell auf bessere Latenzen zu stehen, sodass hier momentan DDR2 selbst in der aktuell schnellsten Stufe nichts bringen wird. Kein Wunder, dass AMD das nicht in seiner Planung für 2005 hat.
Zuletzt bearbeitet:
G
Gast29012019_2
Guest
Hi..
Man muß aber auch wissen das HT sogesehen mit echten Dual-Prozessoren nichts am Hut hat. Intel hat hier nur ! das SSE ein wenig umstruckturiert, was dann HT ist. Alle Programme die SSE nutzen können, werden folglich schneller bearbeitet, bzw. können mehrere Prozesse zugleich verarbeitet werden. Dies hat Intel getan um die schwächen der P4 Technik ein wenig auszugleichen.
Das SSE beim AMD kommt natührlich nicht dagegen an, ist aber beabsichtigt. Währe er genauso schnell wie beim Intel, oder würde ähnlich optimiert werden, würde das für Intel das aus bedeuten, und Intel eingestehen müssen das HT nur mehr ein Marketing-Gag war.
Ich wollte es als P4 Benutzer nocht so recht glauben, aber nachdem ich mir mal angesehen habe was HT wirklich ist, kam dann doch die Erleuchtung.
Man muß aber auch wissen das HT sogesehen mit echten Dual-Prozessoren nichts am Hut hat. Intel hat hier nur ! das SSE ein wenig umstruckturiert, was dann HT ist. Alle Programme die SSE nutzen können, werden folglich schneller bearbeitet, bzw. können mehrere Prozesse zugleich verarbeitet werden. Dies hat Intel getan um die schwächen der P4 Technik ein wenig auszugleichen.
Das SSE beim AMD kommt natührlich nicht dagegen an, ist aber beabsichtigt. Währe er genauso schnell wie beim Intel, oder würde ähnlich optimiert werden, würde das für Intel das aus bedeuten, und Intel eingestehen müssen das HT nur mehr ein Marketing-Gag war.
Ich wollte es als P4 Benutzer nocht so recht glauben, aber nachdem ich mir mal angesehen habe was HT wirklich ist, kam dann doch die Erleuchtung.
Naja, nicht so ganz - HT bezieht sich schon auf alle Ausführungseinheiten. Falls das eine Programm mal einen Speicherzugriff tätigen muss, kann die CPU solange an dem anderen weiterrechnen.
Praktisch ist es aber extrem schwierig sowas effizient umzusetzen - soll heißen, nicht immer wenn die CPU mal auf den Speicher zugreifen muss, kann auch wirklich an einem anderen Thread weitergerechnet werden.
Außerdem sind Programme sowieso schon so optimiert, dass der Speicher so selten wie möglich zum Einsatz kommt. Zwar kommt HT nicht nur bei Speicherzugriffen zum Einsatz, aber da lohnt es sich am besten.
Insgesammt kann man zu HT/SMT also sagen, dass es zwar eine Technologie ist, die theoretisch wenn ideal umgesetzt wirklich viel bringt, sich aber praktisch einfach nicht ordentlich umsetzen lässt - vor allem bei x86 nicht, weil da der 'Weg' zu den Recheneinheiten länger ist (Decoder).
Praktisch ist es aber extrem schwierig sowas effizient umzusetzen - soll heißen, nicht immer wenn die CPU mal auf den Speicher zugreifen muss, kann auch wirklich an einem anderen Thread weitergerechnet werden.
Außerdem sind Programme sowieso schon so optimiert, dass der Speicher so selten wie möglich zum Einsatz kommt. Zwar kommt HT nicht nur bei Speicherzugriffen zum Einsatz, aber da lohnt es sich am besten.
Insgesammt kann man zu HT/SMT also sagen, dass es zwar eine Technologie ist, die theoretisch wenn ideal umgesetzt wirklich viel bringt, sich aber praktisch einfach nicht ordentlich umsetzen lässt - vor allem bei x86 nicht, weil da der 'Weg' zu den Recheneinheiten länger ist (Decoder).
Moin,
ich weiß nicht warukm das das in diesem Thread einbringst...aber das ist so nicht richtig
.
(Meiner meinung nach...)
SMT (Intels HT) hat eher weniger was mit sse zu tun. Es werden schlicht ein paar register verdoppelt ein 2. Instroktion pionter angelegt und dem System vorgegauckelt es seien 2 cpus.
Was jetzt wirklich passiert ist das 2 Threads "gleichzeitig" von der cpu bearbeitet werden.
D.h. sie werden beide zur selben zeit in die Pipeline der cpu geladen...Die einheiten im Rechenwerk sind aber die gleeichen geblieben. Einen geschw vorteil bekommt man dadurch das man jetzt den code 2 threads out of order ausführen kann und dadruch das rechenwerk besser auslastet.
Außerdem "fühlt" sich das system angeblich ein wenig runder an, das resultiert aus der besseren informationsverarbeitung wenn 1 thread 100% last erzeugt.
mfg
ich weiß nicht warukm das das in diesem Thread einbringst...aber das ist so nicht richtig
. (Meiner meinung nach...)
SMT (Intels HT) hat eher weniger was mit sse zu tun. Es werden schlicht ein paar register verdoppelt ein 2. Instroktion pionter angelegt und dem System vorgegauckelt es seien 2 cpus.
Was jetzt wirklich passiert ist das 2 Threads "gleichzeitig" von der cpu bearbeitet werden.
D.h. sie werden beide zur selben zeit in die Pipeline der cpu geladen...Die einheiten im Rechenwerk sind aber die gleeichen geblieben. Einen geschw vorteil bekommt man dadurch das man jetzt den code 2 threads out of order ausführen kann und dadruch das rechenwerk besser auslastet.
Außerdem "fühlt" sich das system angeblich ein wenig runder an, das resultiert aus der besseren informationsverarbeitung wenn 1 thread 100% last erzeugt.
mfg
Dresdenboy
Redaktion
☆☆☆☆☆☆
Noch etwas zum Dothan:
Der "Neue" mit 2,13GHz ist mit max. 1,372V spezifiziert - also wieder eine kleine Steigerung.
Und die Auslastung eines Dothans durch Prime95 wird, selbst bei Small-FFT und fast kompletter Abarbeitung innerhalb des L1-Caches, immer noch geringer sein, als z.B. auf einem K7 oder K8 oder gar einer Netburst-CPU. Der Grund ist einfach:
Die FPU ist etwas langsamer (speziell Multiplikation). Dadurch werden auch nicht so schnell Daten verarbeitet und damit benötigt, was den Cache auch weniger belastet. Insgesamt erreicht der Code damit nicht en Auslastungsgrad wie auf anderen CPUs.
BTW, George hat Prime95 für K7 um etwa 10-40% (abh. von FFT-Größe) durch Konzentration auf den L1-Cache beschleunigen können. Den L2-Cache wie beim P3/P4 einzubeziehen, hatte einige Leistungsreserven verhindert. Die optimierte Version nennt sich 24.6. Einen Thread dazu gibt es hier.
Der "Neue" mit 2,13GHz ist mit max. 1,372V spezifiziert - also wieder eine kleine Steigerung.
Und die Auslastung eines Dothans durch Prime95 wird, selbst bei Small-FFT und fast kompletter Abarbeitung innerhalb des L1-Caches, immer noch geringer sein, als z.B. auf einem K7 oder K8 oder gar einer Netburst-CPU. Der Grund ist einfach:
Die FPU ist etwas langsamer (speziell Multiplikation). Dadurch werden auch nicht so schnell Daten verarbeitet und damit benötigt, was den Cache auch weniger belastet. Insgesamt erreicht der Code damit nicht en Auslastungsgrad wie auf anderen CPUs.
BTW, George hat Prime95 für K7 um etwa 10-40% (abh. von FFT-Größe) durch Konzentration auf den L1-Cache beschleunigen können. Den L2-Cache wie beim P3/P4 einzubeziehen, hatte einige Leistungsreserven verhindert. Die optimierte Version nennt sich 24.6. Einen Thread dazu gibt es hier.
G
Gast29012019_2
Guest
Und für Alle die das mit HT nicht glauben wollen, hier ein sehr interessanter Thread dazu ->
http://www.forumdeluxx.de/forum/showthread.php?t=97395
Insbesondere die letzten Seiten sind sehr interessant.
AMD und P4-M brauchen dieses nicht, da die eben nicht die schwächen haben, die die schlechte P4 Architektur.
http://www.forumdeluxx.de/forum/showthread.php?t=97395
Insbesondere die letzten Seiten sind sehr interessant.
AMD und P4-M brauchen dieses nicht, da die eben nicht die schwächen haben, die die schlechte P4 Architektur.
G
Gast29012019_2
Guest
Link siehe hier -> http://www.forumdeluxx.de/forum/showthread.php?t=97395&page=3&pp=25
Des weiteren hatte ich einfach irgendwie das Bedürfnis es loszuwerden, aber da es hier scheinbar der falsche Thread ist, werde ich das im anderen passenden Thread fortsetzen.
Jedenfalls scheint laut dem verlinkten Thread wo eben genau diese Diskussion herscht, wohl ersichtlich das HT und SSE wohl sehr wohl was gemeinsam haben, auch wenn Intel es anders umgesetzt hat, und die erwähnte Schwäche des P4 auszugleichen. Und die Benchmarks dir ich bisher gesehen haben, zeigt deutlich das das SSE vom P4 optimierter ist als jene von AMD, ist aber eine Weile her. Aber ließ dir es dennoch mal durch, oder alles was im dem Thread diskuttiert worden ist, und dann kannst du ja nochmal darauf eingehen ob das stimmt oder nicht. Die mühe kannst du dir ja machen.
G
Gast29012019_2
Guest
Werde ich mir das dann mal zur Gemüte ziehen, mit einem Übersetzer *g*
Dann währe das letztere was ich noch gerne wissen würde wie es sich verhält mit HT gegenüber einem echten Dual-Prozessor-System, hier sollten ja unterstützte Anwendungen schneller abgerarbeitet werden können oder - unabhängig davon ob es jetzt Xeon, AMD-MP oder Opteron ist.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Eine Implementation einer Befehlssatzerweiterung kann nicht in einer auf irgendeine Weise "optimierten" Form vorliegen. Es wurde integriert unter bestimmten Gesichtspunkten und das wars. Desweiteren sind SSE und SSE2 noch zu unterscheiden, da sie auf verschiedenen Basiskonzepten beruhen.
Und mir ist in meiner Laufbahn bis jetzt nur ein SSE2-Code bekannt, der pro Takt auf dem Northwood deutlich schneller ist, als auf einem K8: Prime95 und andere Programme, die den gleichen Code nutzen (LLRP, OpenPFGW). Das liegt an der Optimierung per Hand über viele Monate hinweg (wurde in den folgenden Jahren noch fortgeführt).
Die Beobachtung eines deutlichen Effekts von SMT auf SSE/SSE2-Code (u. auch x87/MMX-Code) läßt sich gut auf die allgemein hohen Latenzen der Befehle zurückführen. Dadurch kommt es oft dazu, daß ein Folgebefehl auf das vorherige Ergebnis lange warten muß, weil es z.B. im bisher üblichen 32bit-Modus nur 8 Register gab, was nicht gerade viel parallel ausgeführten Rechnungen ermöglichte, und daher Pipeline-Bubbles entstanden. Diese lassen sich natürlich gut mit SSE/SSE2-Code eines anderen Threads via SMT füllen..
Edit:
Mir fällt noch ein: Durch oben genannte Punkte entsteht auch der Effekt, daß HT bei 2 parallel arbeitenden Prime95-Threads keinen Gewinn, sondern eher Verlust bringt, da die FPU schon durch einen Thread so gut ausgelastet wird, daß der zweite nur stört und nebenbei die Daten aus dem Cache schmeißt.
Zuletzt bearbeitet:
Also bei nicht spezifisch optimiertem SSE/2 ist der K8 pro Takt schneller als der P4. Nur bei den Taktunterschieden verliert sich der Effekt eben.
PS Mit Implementierung meint er die Umsetzung in Hardware. Aber es scheint hier ja allgemein so ein Problem zu sein, dass die Sachen gerade so interpretiert werden, dass die am wenigsten Sinn ergeben...
Allein schon wie man auf die Idee kommen kann, dass man SSE verändert wo SSE doch festgeschrieben ist...
PS Mit Implementierung meint er die Umsetzung in Hardware. Aber es scheint hier ja allgemein so ein Problem zu sein, dass die Sachen gerade so interpretiert werden, dass die am wenigsten Sinn ergeben...
Allein schon wie man auf die Idee kommen kann, dass man SSE verändert wo SSE doch festgeschrieben ist...
G
Gast29012019_2
Guest
Hi..
1. Prime95 ist aber SSE optimiert !
2. Desweiteren vermittelt aber HT den Eindruck das Prime95 erst in 2 Instanzen zugleich eine 100% CPU-Auslastung ergibt. Beim ocen habe ich bemerkt das 1x Prime für einen sog. Stabilitätstest nicht reicht, macht man 2 Prime95 an kackte 1 Instanz ab, so habe ich die Spannung erhöht etc, und dann habe ich es 48 Std laufen lassen, ohne Fehler.
@i_hasser,
Intel hat dies halt getan, und damit ihre Schwäche die der P4 numal hat ein wenig auszugleichen.
1. Prime95 ist aber SSE optimiert !
2. Desweiteren vermittelt aber HT den Eindruck das Prime95 erst in 2 Instanzen zugleich eine 100% CPU-Auslastung ergibt. Beim ocen habe ich bemerkt das 1x Prime für einen sog. Stabilitätstest nicht reicht, macht man 2 Prime95 an kackte 1 Instanz ab, so habe ich die Spannung erhöht etc, und dann habe ich es 48 Std laufen lassen, ohne Fehler.
@i_hasser,
Intel hat dies halt getan, und damit ihre Schwäche die der P4 numal hat ein wenig auszugleichen.
Kann die SSE Diskussion nicht in einem eigenständigen Thread geführt werden? Zumal hier bei der SSE1/2 Diskussion keine Benches gebracht wurden.
Sledge hatte an anderer Stelle ja mal SSE-Benches gebracht.
Ich pappe da noch mal meine Guides rein:
Seitenverzeichnis; Die Opteron Zukunft, kann AMD überleben? (Sledge`s SSE Hinweis)
Spezielle P3D Opteronlinksammlung (SIMD Threadhinweise)
Inhaltsverzeichnis Benchmarkmärchen mit Fortsetzung (Diverse Hinweise was auf den ersten 5 Seiten im Thread an Benchmarks genannt wurde)
Natürlich sind aktuelle SSE Benches hier gerne gesehen, aber über die SIMD-Technologie und Implementierung sollte hier weniger eingegangen werden
MFG Bokill
Sledge hatte an anderer Stelle ja mal SSE-Benches gebracht.
Ich pappe da noch mal meine Guides rein:
Seitenverzeichnis; Die Opteron Zukunft, kann AMD überleben? (Sledge`s SSE Hinweis)
Spezielle P3D Opteronlinksammlung (SIMD Threadhinweise)
Inhaltsverzeichnis Benchmarkmärchen mit Fortsetzung (Diverse Hinweise was auf den ersten 5 Seiten im Thread an Benchmarks genannt wurde)
Natürlich sind aktuelle SSE Benches hier gerne gesehen
, aber über die SIMD-Technologie und Implementierung sollte hier weniger eingegangen werden MFG Bokill
Dresdenboy
Redaktion
☆☆☆☆☆☆
@Bokill:
Ich fasse mich möglichst kurz, um hier nix aufzublähen und keine Diskussionen zu zerfetzen (über 5 Threads verteilt)
aber noch zu 2.:
Das Problem wird auf genanntem Forum oft diskutiert. Der Taskmanager zeigt 50% an, weil das das Maximum für einen einzelnen Thread auf der virtuellen "halben" CPU ist. Daß es in Wirklichkeit 100% (wenn sonstige CPU-Last nahe 0% ist) beträgt, erkennt man an den nahezu übereinstimmenden Iterationszeiten im Vergleich zu der gleichen CPU mit ausgeschaltetem SMT.
Was du mit den 2 Threads erreicht hast, ist keine höhere FPU-Auslastung, sondern eine zusätzliche Last verursacht durch Cache Thrashing und den erhöhten Datenverkehr zum Hauptspeicher (dank Cache Thrashing und zweier unterschiedlicher Datasets der zwei Instanzen).
Ich fasse mich möglichst kurz, um hier nix aufzublähen und keine Diskussionen zu zerfetzen (über 5 Threads verteilt
)zu 1.) mit single precision käme Prime95 nicht weit. Für SETI@home reichts (128K FFT), aber Prime95 muß x87 oder SSE2 nutzen, da sonst der Effekt der Handoptimierung sofort durch eine starke Verlangsamung durch single precision komplett verloren gegangen wäre. Du findest mich übrigens auch auf http://www.mersenneforum.org/, da ich mich auch mit der Optimierung von Prime95 beschäftige (für AMD64). Bezügl. Prime95-Diskussionen kannst du gern dort posten.
aber noch zu 2.:
Das Problem wird auf genanntem Forum oft diskutiert. Der Taskmanager zeigt 50% an, weil das das Maximum für einen einzelnen Thread auf der virtuellen "halben" CPU ist. Daß es in Wirklichkeit 100% (wenn sonstige CPU-Last nahe 0% ist) beträgt, erkennt man an den nahezu übereinstimmenden Iterationszeiten im Vergleich zu der gleichen CPU mit ausgeschaltetem SMT.
Was du mit den 2 Threads erreicht hast, ist keine höhere FPU-Auslastung, sondern eine zusätzliche Last verursacht durch Cache Thrashing und den erhöhten Datenverkehr zum Hauptspeicher (dank Cache Thrashing und zweier unterschiedlicher Datasets der zwei Instanzen).
G
Gast29012019_2
Guest
Original geschrieben von Dresdenboy
@Bokill:
Ich fasse mich möglichst kurz, um hier nix aufzublähen und keine Diskussionen zu zerfetzen (über 5 Threads verteilt
zu 1.) mit single precision käme Prime95 nicht weit. Für SETI@home reichts (128K FFT), aber Prime95 muß x87 oder SSE2 nutzen, da sonst der Effekt der Handoptimierung sofort durch eine starke Verlangsamung durch single precision komplett verloren gegangen wäre. Du findest mich übrigens auch auf http://www.mersenneforum.org/, da ich mich auch mit der Optimierung von Prime95 beschäftige (für AMD64). Bezügl. Prime95-Diskussionen kannst du gern dort posten.
aber noch zu 2.:
Das Problem wird auf genanntem Forum oft diskutiert. Der Taskmanager zeigt 50% an, weil das das Maximum für einen einzelnen Thread auf der virtuellen "halben" CPU ist. Daß es in Wirklichkeit 100% (wenn sonstige CPU-Last nahe 0% ist) beträgt, erkennt man an den nahezu übereinstimmenden Iterationszeiten im Vergleich zu der gleichen CPU mit ausgeschaltetem SMT.
Was du mit den 2 Threads erreicht hast, ist keine höhere FPU-Auslastung, sondern eine zusätzliche Last verursacht durch Cache Thrashing und den erhöhten Datenverkehr zum Hauptspeicher (dank Cache Thrashing und zweier unterschiedlicher Datasets der zwei Instanzen).
Habe das aber vor 1 Jahr getestet, da gabs die neue Prime Version noch nicht, wo man Ram CPU etc einzeln testen konnte, da habe ich einfach Tortune Test gestartet und fertig. Aber der Speicher war ja nicht das Problem, es muß ja was mit der CPU gewesen sein, erst mit 1,6V war dann stabil.
Aber gut, ist im Prinzip ja alles Offtopic, und bevor noch mehr User hier dies Anmerken, poste ich in den entprechenden Thread bzw. Foren weiter.
Crucial hat da nette PR Material angefertigt.
Zum einen wurde ein DOOM3-Bench angefertigt, der die Vorteile von PC 4000 ("DDR 500") gegenüber PC 3200 ("DDR 400") anzeigt. Zwar sind Unterscheide auszumachen, allerdings hat die CPU bei PC 4000 auch einen höheren Takt
da darf es auch etwas mehr sein.
Da sie es aber schön auflisten, darf man da einen Blick reinwerfen.
Für OC-Jünger kann das ja auch Hinweise geben, welche Kombinationen möglicherweise stabil laufen können.
Die Ausgangsbasis war ein P4 2,4 GHz vs P4 3 GHz (OC).
Das Board war Abit IC-7 Max 3.
Grafikkarte war eine ATi Radeon 9800 Pro.
Speicher war PC 3200 vs "PC 4000" (kein JEDEC Standard).
PDF CrucialDoom3
http://images.crucial.com/pdf/CrucialDoom3.pdf
Der Andere Bench mit Half Life2 ist eine hübsche Ergänzug zu den bisherigen Benches zu DDR2 vs DDR1.
Dort wurde dann aber dann auch ein Duell von AMD vs Intel daraus.
Derzeit hat AMD ja keine DDR2 Lösungen parat. Was die Benches aber auch gut erklären, es ist derzeit keine zwingende Notwendigkeit zum Wechsel von AMD.
Da hier der Vergleich notwendigerweise krumm bleibt, da unterscheidliche Plattformen antreten gehe ich auf die Benches nicht genauer ein.
System1
Mainboard: Intel 925 x CV.
Speicher: 2 GB PC2 5300 (DDR2 667).
CPU: Intel 3,4 GHz (Northwood?/Prescott?).
Festplatte: 37 GB Western Digital Raptor Serial ATA.
Grafikkarte: 256 MB Crucial Radeon X600 Pro PCI-Express.
System2
Mainboard Asus 8AV.
CPU: Athlon64 4000+ (2,4 GHz).
Speicher: 2 GB "PC 4000" ("DDR 500")
Festplatte: 74 GB Western Digital Raptor (Serial ATA?).
Grafikkarte: 256 MB Crucial Radeon X800 Pro AGP.
Zumindest das OS ist identisch. Microsoft XP Pro + SP1.
Crucial Half Life2 PDF
http://images.crucial.com/pdf/CrucialHalfLife2.pdf
Hübscher (und neutraler) wäre ein Bench gewesen, die den Nutzen vom Wechsel PC 3200 -> PC 4000 (AMD), sowie bei dem P4 den Wechsel PC2 4200 -> PC2 5300 zeigen.
MFG Bokill
Zum einen wurde ein DOOM3-Bench angefertigt, der die Vorteile von PC 4000 ("DDR 500") gegenüber PC 3200 ("DDR 400") anzeigt. Zwar sind Unterscheide auszumachen, allerdings hat die CPU bei PC 4000 auch einen höheren Takt
da darf es auch etwas mehr sein.Da sie es aber schön auflisten, darf man da einen Blick reinwerfen.
Für OC-Jünger kann das ja auch Hinweise geben, welche Kombinationen möglicherweise stabil laufen können.
Die Ausgangsbasis war ein P4 2,4 GHz vs P4 3 GHz (OC).
Das Board war Abit IC-7 Max 3.
Grafikkarte war eine ATi Radeon 9800 Pro.
Speicher war PC 3200 vs "PC 4000" (kein JEDEC Standard).
PDF CrucialDoom3
http://images.crucial.com/pdf/CrucialDoom3.pdf
Der Andere Bench mit Half Life2 ist eine hübsche Ergänzug zu den bisherigen Benches zu DDR2 vs DDR1.
Dort wurde dann aber dann auch ein Duell von AMD vs Intel daraus.
Derzeit hat AMD ja keine DDR2 Lösungen parat. Was die Benches aber auch gut erklären, es ist derzeit keine zwingende Notwendigkeit zum Wechsel von AMD.
Da hier der Vergleich notwendigerweise krumm bleibt, da unterscheidliche Plattformen antreten gehe ich auf die Benches nicht genauer ein.
System1
Mainboard: Intel 925 x CV.
Speicher: 2 GB PC2 5300 (DDR2 667).
CPU: Intel 3,4 GHz (Northwood?/Prescott?).
Festplatte: 37 GB Western Digital Raptor Serial ATA.
Grafikkarte: 256 MB Crucial Radeon X600 Pro PCI-Express.
System2
Mainboard Asus 8AV.
CPU: Athlon64 4000+ (2,4 GHz).
Speicher: 2 GB "PC 4000" ("DDR 500")
Festplatte: 74 GB Western Digital Raptor (Serial ATA?).
Grafikkarte: 256 MB Crucial Radeon X800 Pro AGP.
Zumindest das OS ist identisch
. Microsoft XP Pro + SP1.Crucial Half Life2 PDF
http://images.crucial.com/pdf/CrucialHalfLife2.pdf
Hübscher (und neutraler) wäre ein Bench gewesen, die den Nutzen vom Wechsel PC 3200 -> PC 4000 (AMD), sowie bei dem P4 den Wechsel PC2 4200 -> PC2 5300 zeigen.
MFG Bokill
Zuletzt bearbeitet:
Erst mal vorweg folgendes ...
Mir wurde etwas schlecht bei den folgenden Benches von legionhardware.com. Athlon64 vs Sempron. Which offers the best value for Gaming?
1. Wurde der Referenz-Systemtakt für Hypertransport und der CPU als "FSB" bezeichnet.
2. Wurde auch ein OC-Sempron zusätzlich gebencht, der Referenz-Systemtakt wurde dabei von 200 MHz auf 266 MHz übertaktet.
3. Ist unklar welcher Athlon 64 3200 da genau gebencht wurde. Der Takt des Athlon 64 3200+ wurde mit 2 GHz angegeben. Der Athlon 64 ist ja auch mit 0,13µm Technologie als Clawhammer sowie als Newcastle (512 kB L2 Cache) eingeführt worden. Eine ältere Übersicht kann man ja auch bei P3D sehen wo bei 2 GHz (2,2 GHz) Alt gegen Neu antritt.
Techreport hat da ein hübsches kompaktes Bildchen angefertigt, dort ist alles sehr übersichtlich angegeben Cache, Sockel, Takt.
AMD's Athlon 64 4000+ and FX-55 processors Rubbing it in.
Der Bench ist demnach ein Sempron mit 521 kB mit 1,8 GHz Takt und tritt als Gegner vom Sockel 754 Clawhammer mit 1 MB L2 Cache bei 2 GHz Takt an -> Athlon64 3200+
Der PCmark2004 zeigt ziemlich gut sogar das Ratingsystem von AMD. Halbierter Cache ergibt ca. eine Taktratingstufe -200 MHz Ratingpunkte.
So liegt der Sempron 1,8 GHz bei (Read Blocks MB/s) ca. 2960 MB/s.
Der 2,4 GHz Sempron hat ca. 3300 MB/s.
-> Ca 340 MB/s bei 3 Taktstufen -> Pro Sempron-Taktstufe ca. 110 MB/s
Der Athlon 64 hat hier Werte von 3180 MB/s
Wenn wir bei einem Sempron 1,8 Ghz auf den Wert 2960 MB/s dann 220 MB/s addieren dann haben wir ca. 3180 MB/s ... ups, das war zu erwarten bei einem Bench der gleichzeitig auf Speicher, sowie Cachegrösse skaliert.
Bei den Benches zu Spielen kann demnach in Spielen unterschieden werden, die eher Cachelastig sind (Doom3, FarCry, TombRaider) und Spielen die da auch gerne Speicherbandbreite nutzen (Unreal).
Ich hätte lieber Benches mit einem Newcastle Athlon64 als Gegner gesehen als einen Clawhammer. So muss ein krummer Bench herauskommen. Zumal AMD auch in dem Niedrigpreissektor auf kleine Dies umsteigt (Newcastle und/oder Winchester -> 512 kB L2 Cache) ist dies um so mehr wichtiger.
Andere Boards wie Computerbase können diese Feinheiten sehr wohl auch beschreiben und werten -> Quake 3 Arena - 1024x768 Max.
MFG Bokill
Mir wurde etwas schlecht bei den folgenden Benches von legionhardware.com. Athlon64 vs Sempron. Which offers the best value for Gaming?
1. Wurde der Referenz-Systemtakt für Hypertransport und der CPU als "FSB" bezeichnet.
2. Wurde auch ein OC-Sempron zusätzlich gebencht, der Referenz-Systemtakt wurde dabei von 200 MHz auf 266 MHz übertaktet.
3. Ist unklar welcher Athlon 64 3200 da genau gebencht wurde. Der Takt des Athlon 64 3200+ wurde mit 2 GHz angegeben. Der Athlon 64 ist ja auch mit 0,13µm Technologie als Clawhammer sowie als Newcastle (512 kB L2 Cache) eingeführt worden. Eine ältere Übersicht kann man ja auch bei P3D sehen wo bei 2 GHz (2,2 GHz) Alt gegen Neu antritt.
Techreport hat da ein hübsches kompaktes Bildchen angefertigt, dort ist alles sehr übersichtlich angegeben Cache, Sockel, Takt.
AMD's Athlon 64 4000+ and FX-55 processors Rubbing it in.
Der Bench ist demnach ein Sempron mit 521 kB mit 1,8 GHz Takt und tritt als Gegner vom Sockel 754 Clawhammer mit 1 MB L2 Cache bei 2 GHz Takt an -> Athlon64 3200+
Der PCmark2004 zeigt ziemlich gut sogar das Ratingsystem von AMD. Halbierter Cache ergibt ca. eine Taktratingstufe -200 MHz Ratingpunkte.
So liegt der Sempron 1,8 GHz bei (Read Blocks MB/s) ca. 2960 MB/s.
Der 2,4 GHz Sempron hat ca. 3300 MB/s.
-> Ca 340 MB/s bei 3 Taktstufen -> Pro Sempron-Taktstufe ca. 110 MB/s
Der Athlon 64 hat hier Werte von 3180 MB/s
Wenn wir bei einem Sempron 1,8 Ghz auf den Wert 2960 MB/s dann 220 MB/s addieren dann haben wir ca. 3180 MB/s ... ups, das war zu erwarten bei einem Bench der gleichzeitig auf Speicher, sowie Cachegrösse skaliert.
Bei den Benches zu Spielen kann demnach in Spielen unterschieden werden, die eher Cachelastig sind (Doom3, FarCry, TombRaider) und Spielen die da auch gerne Speicherbandbreite nutzen (Unreal).
Ich hätte lieber Benches mit einem Newcastle Athlon64 als Gegner gesehen als einen Clawhammer. So muss ein krummer Bench herauskommen. Zumal AMD auch in dem Niedrigpreissektor auf kleine Dies umsteigt (Newcastle und/oder Winchester -> 512 kB L2 Cache) ist dies um so mehr wichtiger.
Andere Boards wie Computerbase können diese Feinheiten sehr wohl auch beschreiben und werten -> Quake 3 Arena - 1024x768 Max.
MFG Bokill
Hier mal ein Bench zum Sinn und auch Unsinn von viel Speicher im Rechner. Dabei testete tbreak.com etwas ungewöhnlich. Es war kein Desktop sonder ein Schleppi.
Die Ausgangsbasis war dennoch nicht so schwach mit dem Ferrari 3200 Notebook.
Grafik: 128MB Radeon 9700
Prozessor: Athlon64 2800+
Speicher: 2x256MB PC 2700
Das einzige was verändert wurde waren die Speichermodule, bei gleicher Geschwindigleit.
Von 256 MB auf -> 512MB
Von 512 MB auf -> 1GB RAM
Die Benches waren PC Mark, SANDRA, 3D Mark, Aquamark, Counter-Strike: Source, DOOM3, Far Cry, UT2004, Office, Photoshop, Nero, Mozilla, Winzip usw.
Für die meisten Anwendungen reichen 512 MB immer noch ... unglaublich aber wahr.
Andererseits sind die aktuellesten Spieleshocker wie DOOM3, Far Cry doch so speichergierig, dass man sich doch noch nach fetteren Speichermodulen sehnt. Es ist schon erstaunlich dass bei 512 GB Doom fast eine Frameratensteigerung von fast 97% bekommt, bei 1 GB mit 113% ist aber doch keine wesentliche Steigerung mehr dabei.
Ähnliches gilt für Far Cry da ist 512 MB willkommen mit einem Gewinn von +35%, 1 GB werden auch noch gerne genommen, auch wenn der Gewinn von 256 MB zu 1 GB doch nicht wesentlich höher ist (+41%).
Der klassische Speicherfresser Adobe Premiere ist da schon vergleichsweise zahm (512 MB +27%, 1 GB +32%). Winzip honoriert auch Mehrspeicher (512 GB +17%, 1 GB +26%). Was mich persönlich doch erstaunte war, dass das Brennprogramm Ahead Nero doch auch extrem gerne Speicher mag (512 GB +18%, 1 GB +42%).
Aber wo viel Licht da auch viel Schatten. Bei vielen Benches ist so gut wie 0% Nutzen zu erkennen (klaro; 0% Bandbreitensteigerung -> 0% Nutzen), anderen Anwendungen tut es sogar weh. Discreet 3D Studio mag weder unter Direkt X (512 MB -25%, 1 GB -31%) , noch unter OpenGL (512 MB -18%, 1 GB -20%) besonders viel Speicher.
Text nachträglich korrigiert. THX andr_gin für die Nachfrage.
MFG Bokill
Die Ausgangsbasis war dennoch nicht so schwach mit dem Ferrari 3200 Notebook.
Grafik: 128MB Radeon 9700
Prozessor: Athlon64 2800+
Speicher: 2x256MB PC 2700
Das einzige was verändert wurde waren die Speichermodule, bei gleicher Geschwindigleit.
Von 256 MB auf -> 512MB
Von 512 MB auf -> 1GB RAM
Die Benches waren PC Mark, SANDRA, 3D Mark, Aquamark, Counter-Strike: Source, DOOM3, Far Cry, UT2004, Office, Photoshop, Nero, Mozilla, Winzip usw.
Für die meisten Anwendungen reichen 512 MB immer noch ... unglaublich aber wahr.
Andererseits sind die aktuellesten Spieleshocker wie DOOM3, Far Cry doch so speichergierig, dass man sich doch noch nach fetteren Speichermodulen sehnt. Es ist schon erstaunlich dass bei 512 GB Doom fast eine Frameratensteigerung von fast 97% bekommt, bei 1 GB mit 113% ist aber doch keine wesentliche Steigerung mehr dabei.
Ähnliches gilt für Far Cry da ist 512 MB willkommen mit einem Gewinn von +35%, 1 GB werden auch noch gerne genommen, auch wenn der Gewinn von 256 MB zu 1 GB doch nicht wesentlich höher ist (+41%).
Der klassische Speicherfresser Adobe Premiere ist da schon vergleichsweise zahm (512 MB +27%, 1 GB +32%). Winzip honoriert auch Mehrspeicher (512 GB +17%, 1 GB +26%). Was mich persönlich doch erstaunte war, dass das Brennprogramm Ahead Nero doch auch extrem gerne Speicher mag (512 GB +18%, 1 GB +42%).
Aber wo viel Licht da auch viel Schatten. Bei vielen Benches ist so gut wie 0% Nutzen zu erkennen (klaro; 0% Bandbreitensteigerung -> 0% Nutzen), anderen Anwendungen tut es sogar weh. Discreet 3D Studio mag weder unter Direkt X (512 MB -25%, 1 GB -31%) , noch unter OpenGL (512 MB -18%, 1 GB -20%) besonders viel Speicher.
Text nachträglich korrigiert. THX andr_gin für die Nachfrage.
MFG Bokill
Zuletzt bearbeitet:
andr_gin
Grand Admiral Special
- Mitglied seit
- 12.06.2003
- Beiträge
- 3.052
- Renomée
- 24
- Standort
- St. Pölten (60km westlich von Wien)
1.)
Anscheinend mögen die das bei techreport nicht so gerne wenn man direkt auf die Grafiken linkt
2.) So wie ich das sehe wurde bei tbreak immer mit nur einem Modul getestet. Die sprechen immer von 256MB, 512MB und 1GB RAM. Damit ist das Ergebnis auch ein ganz anderes. Dass 256MB RAM zu wenig sind bei aktuellen Spielen vor allem mit einem etwas aufgeblähten Windows ist irgendwie nichts neues
Viel interessanter ist, dass man sieht so überall mehr als 512MB gebraucht werden und da sieht man schon an einigen Stellen, dass es etwas bringt. So wirklich bemerkbar macht es sich auch nicht so in den Frameraten sondern beim Starten und Beenden des Programms und wenn man schnell mit Strg+Alt+Entf in Windows rauswechselt.
Original geschrieben von Bokill
Anscheinend mögen die das bei techreport nicht so gerne wenn man direkt auf die Grafiken linkt
2.) So wie ich das sehe wurde bei tbreak immer mit nur einem Modul getestet. Die sprechen immer von 256MB, 512MB und 1GB RAM. Damit ist das Ergebnis auch ein ganz anderes. Dass 256MB RAM zu wenig sind bei aktuellen Spielen vor allem mit einem etwas aufgeblähten Windows ist irgendwie nichts neues
Viel interessanter ist, dass man sieht so überall mehr als 512MB gebraucht werden und da sieht man schon an einigen Stellen, dass es etwas bringt. So wirklich bemerkbar macht es sich auch nicht so in den Frameraten sondern beim Starten und Beenden des Programms und wenn man schnell mit Strg+Alt+Entf in Windows rauswechselt.
Gebe aber zu dass es zweideutig ist, da müsste man die Junxx von tbreak noch mal anfragen
... Done! ... und entsprechend korrigiert.Tja zu TechReport ... ja das ist ne feine Seite
... Nachtrag: Links funzen doch wieder MFG Bokill
Zuletzt bearbeitet:
- Status
