Nochmal 486er Bench
- Ersteller i_hasser
- Erstellt am
Hi
Ich werd den Bench wahrscheinlich doch machen - nun die Frage, was gebencht werden soll.
Mir ist erstmal folgendes eingefallen:
1. -> LinePack Bench
2. -> Meinen Primzahlalg aus dem entsprechenden Prog-Wettbewerb
3. -> Sortieralgorithmen (BubbleSort, vielleicht auch QuickSort)
4. -> PI Berechnungen
5. -> Fraktalberechnungen
Tja, die Frage ist nun was man da noch nehmen könnte. Die Benches da oben beziehen sich alle auch spezielle Bereiche, hier mal die Liste:
1. -> hauptsächlich FPU, ein bisschen MEM
2. -> hauptsächlich MEM, ein bisschen INT(eger)
3. -> hauptsächlich MEM, ein bisschen INT (bei Bubblesort)
4. -> sehr viel FPU
5. -> je nach alg sehr viel FPU/INT
Ah mir ist gerade nochwas eingefallen - Huffmann Kompression, ist hauptsächlich INT.
Habt ihr da noch ein paar ALGs die euch einfallen? ABER: Die müssen auch halbwegs einfach in der Umsetzung sein, mein Primzahl-Alg ist so ungefähr das Maximum.
Graphik fehlt auch noch, da werd ich vielleicht was mit Allegro machen, mal sehen.
Die Benches sollen übrigens auch auf einem 8086 laufen - also so extreme Speicheranforderungen sollten die auch nicht haben, mein Primzahlalg lässt sich relativ gut mit 512kb realisieren - ich denk mehr sollten die Benches net futtern (außer vielleicht einige spezielle für >=386, der hat ja den Protected Mode (ich werd kein EMS nutzen) - vielleicht bekomm ich auch was für den 286er im Protected Mode hin).
Ich werd den Bench wahrscheinlich doch machen - nun die Frage, was gebencht werden soll.
Mir ist erstmal folgendes eingefallen:
1. -> LinePack Bench
2. -> Meinen Primzahlalg aus dem entsprechenden Prog-Wettbewerb
3. -> Sortieralgorithmen (BubbleSort, vielleicht auch QuickSort)
4. -> PI Berechnungen
5. -> Fraktalberechnungen
Tja, die Frage ist nun was man da noch nehmen könnte. Die Benches da oben beziehen sich alle auch spezielle Bereiche, hier mal die Liste:
1. -> hauptsächlich FPU, ein bisschen MEM
2. -> hauptsächlich MEM, ein bisschen INT(eger)
3. -> hauptsächlich MEM, ein bisschen INT (bei Bubblesort)
4. -> sehr viel FPU
5. -> je nach alg sehr viel FPU/INT
Ah mir ist gerade nochwas eingefallen - Huffmann Kompression, ist hauptsächlich INT.
Habt ihr da noch ein paar ALGs die euch einfallen? ABER: Die müssen auch halbwegs einfach in der Umsetzung sein, mein Primzahl-Alg ist so ungefähr das Maximum.
Graphik fehlt auch noch, da werd ich vielleicht was mit Allegro machen, mal sehen.
Die Benches sollen übrigens auch auf einem 8086 laufen - also so extreme Speicheranforderungen sollten die auch nicht haben, mein Primzahlalg lässt sich relativ gut mit 512kb realisieren - ich denk mehr sollten die Benches net futtern (außer vielleicht einige spezielle für >=386, der hat ja den Protected Mode (ich werd kein EMS nutzen) - vielleicht bekomm ich auch was für den 286er im Protected Mode hin).
Oh oh...
das wird schwer, die aktuellen CPU frühstücken ja die Programme, da diese vermutlich komplett im Cache verschwinden...nicht die feine Art gleichartige Bedingungen zu schaffen.
Macht aber nichts, wäre schon nett da eine Abstufung der verschiedenen CPUs zu sehen!
das wird schwer, die aktuellen CPU frühstücken ja die Programme, da diese vermutlich komplett im Cache verschwinden...nicht die feine Art gleichartige Bedingungen zu schaffen.
Macht aber nichts, wäre schon nett da eine Abstufung der verschiedenen CPUs zu sehen!
Na das Problem kann ich wenigstens mit einigen Benches umgehen.
Meinen Prime-Bench lass ich einfach in einem größeren Bereich suchen, mit 512kb Ram kann ich im Bereich 0 bis 12'582'912 suchen lassen (dazu gibts auch noch 2 Algs, der eine frisst etwas mehr Speicher, der andere braucht die ALU ewas mehr), auf meinem großen hab ich den Alg auch schon bis 4 Milliarden suchen lassen (da braucht er ca. 166mb, bzw. mit dem eher Mem-belastenden Alg 250mb).
Das wird dann so aussehen, dass ich messe wie viele Durchläufe er in einer bestimmten Zeit schafft. Damit können die Benches auch auf aktuelleren Rechnern laufen, um mal den Unterschied zu verdeutlichen.
Also für den Prime Alg nehm ich einfach 2 verschiedene Bereiche, den 2. durchsucht er dann nur bei 386+ und der kann dann eben 8mb oder so für sich nehmen.
Beim Sortieralg ist es ähnlich, da erzeuge ich dann einfach mehr Zahlen, die dann sortiert werden.
PI kann man dann eben auf 10'000'000 statt auf 100'000 Stellen berechnen.
Fraktalberechnungen und LinePack werden schwierig.
EDIT
Der 486er kann übrigens mit mehr Cache umgehen als der Athlon
Meinen Prime-Bench lass ich einfach in einem größeren Bereich suchen, mit 512kb Ram kann ich im Bereich 0 bis 12'582'912 suchen lassen (dazu gibts auch noch 2 Algs, der eine frisst etwas mehr Speicher, der andere braucht die ALU ewas mehr), auf meinem großen hab ich den Alg auch schon bis 4 Milliarden suchen lassen (da braucht er ca. 166mb, bzw. mit dem eher Mem-belastenden Alg 250mb).
Das wird dann so aussehen, dass ich messe wie viele Durchläufe er in einer bestimmten Zeit schafft. Damit können die Benches auch auf aktuelleren Rechnern laufen, um mal den Unterschied zu verdeutlichen.
Also für den Prime Alg nehm ich einfach 2 verschiedene Bereiche, den 2. durchsucht er dann nur bei 386+ und der kann dann eben 8mb oder so für sich nehmen.
Beim Sortieralg ist es ähnlich, da erzeuge ich dann einfach mehr Zahlen, die dann sortiert werden.
PI kann man dann eben auf 10'000'000 statt auf 100'000 Stellen berechnen.
Fraktalberechnungen und LinePack werden schwierig.
EDIT
Der 486er kann übrigens mit mehr Cache umgehen als der Athlon
Zuletzt bearbeitet:
Die 8mb beim 386er bezogen sich auf den Ram - meintest du das?
Den Athlon gibts mit 64, 256 und 512 kb L2 Cache. Dem 486er kannst du problemlos auch 1mb Cache verpassen, viele Boards bieten auch die Möglichkeit an. Fehlen tuts eben nur an den 128kb Cache Modulen, die extremst selten sind
Mein 486er hat 512kb L2 Cache.
und Praxis!
Theoretisch konnte der Athlon Classic 8MB L2 Cache adressieren...allerdings dürften solche Serverprototypen irgendwo bei AMD ganz tief in den Enwicklersafes schlummern.
Allerdings gab es Roadmaps wo Cachemonster mit theoretischen MP- Betrieb aufgeführt waren.
Theoretisch konnte der Athlon Classic 8MB L2 Cache adressieren...allerdings dürften solche Serverprototypen irgendwo bei AMD ganz tief in den Enwicklersafes schlummern.
Allerdings gab es Roadmaps wo Cachemonster mit theoretischen MP- Betrieb aufgeführt waren.
So, die dämliche CPU Erkennungsroutine hab ich fertig
Ich denke die Benchmarks werd ich vom Compiler auf die Plattformen hier optimieren lassen:
8086, 286, 386, 486 und 586. Dabei wird neben der FPU Emulation auch der 287 und der 387 unterstützt.
Gebencht wird dann alles was möglich ist, also auf dem 386er auch die 286 und 8086 Versionen, da sieht man schön wie sich die Leistung durch Optimierungen verändert hat.
Vielleicht mach ich noch eine Extraversion für den Protected Mode (dann aber >=386), da würde man auch den Unterschied zwischen zb. Realmode 386 und Protected Mode 386 sehen.
Ich denke die Benchmarks werd ich vom Compiler auf die Plattformen hier optimieren lassen:
8086, 286, 386, 486 und 586. Dabei wird neben der FPU Emulation auch der 287 und der 387 unterstützt.
Gebencht wird dann alles was möglich ist, also auf dem 386er auch die 286 und 8086 Versionen, da sieht man schön wie sich die Leistung durch Optimierungen verändert hat.
Vielleicht mach ich noch eine Extraversion für den Protected Mode (dann aber >=386), da würde man auch den Unterschied zwischen zb. Realmode 386 und Protected Mode 386 sehen.
uiuiui, das geht jetzt ziemlich zur Sache.
Hab SourceTree soweit fertig. Das Blöde ist, dass jeder Bench 10mal compiliert werden muss, und dementsprechend haufenweise Funktionen und OBJs anfallen.
Jetzt baut er schonmal das Basisprog, sind immerhin schon 12 Compileraufrufe, 3 Libfunktionen und 1mal der Linker.
Dafür siehts mit der Unterstützung ziemlich gut aus, werden die Benches (erst einer zum Testen) auf die Plattformen einzeln optimiert:
8086 ohne FPU
8086 mit 8087
286 mit/ohne 287
386 mit/ohne 387
486 mit/ohne 387 (ist net auf den 487 optimiert, sondern eben nur auf den 387)
586 mit 587
und 686 mit 687.
Also der Bench reicht von sehr alt bis noch recht neu. Vorraussichtlich werden es 3 Progs werden, einmal für <386, einmal >=386 und dann für den Protected Mode (>=386). Den PM hab ich aber noch garnet implementiert, hab noch nichtmal ein passenden CPU Test dafür.
Hab SourceTree soweit fertig. Das Blöde ist, dass jeder Bench 10mal compiliert werden muss, und dementsprechend haufenweise Funktionen und OBJs anfallen.
Jetzt baut er schonmal das Basisprog, sind immerhin schon 12 Compileraufrufe, 3 Libfunktionen und 1mal der Linker.
Dafür siehts mit der Unterstützung ziemlich gut aus, werden die Benches (erst einer zum Testen) auf die Plattformen einzeln optimiert:
8086 ohne FPU
8086 mit 8087
286 mit/ohne 287
386 mit/ohne 387
486 mit/ohne 387 (ist net auf den 487 optimiert, sondern eben nur auf den 387)
586 mit 587
und 686 mit 687.
Also der Bench reicht von sehr alt bis noch recht neu. Vorraussichtlich werden es 3 Progs werden, einmal für <386, einmal >=386 und dann für den Protected Mode (>=386). Den PM hab ich aber noch garnet implementiert, hab noch nichtmal ein passenden CPU Test dafür.
die erste... nennen wir sie pre-alpha ist eben fertig geworden
Momentan hab ich nur einen rudimentären Bench drinnen (der dividiert einfach 1Mio mal einen Double), aber es läuft schonmal.
Ihr könnt ja mal testen in wie weit das mit den verschiedenen CPUs funktioniert. Habs nur auf meinem 486er getestet, da läuft er ganz gut (und schon bei dem einfachen Bench bringt die 486er optimierung ca. 27.5% mehr Leistung).
Momentan testet das Prog noch vom 8086 bis 686 (bzw. bis dahin, wo die CPU ausreicht) - auf einem <386 dürften die FPU Operationen aber den Rechner abschmieren lassen - wäre dankbar, wenn das einer testen könnte. Bin mir nämlich net sicher, möglicherweise brauch ich kein Extraprog für 8086 und 286 machen.
Aber hier nun der Link: http://home.arcor.de/intelhasser2/486bench/b386_0.exe
Einfach irgendwo speichern und ausführen, vielleicht stürzt ein <686 im Realmode ab (wenn aus irgend einem Grund der 686 Code drauf gestartet wird), aber ansonsten dürfte nix passieren.
Momentan hab ich nur einen rudimentären Bench drinnen (der dividiert einfach 1Mio mal einen Double), aber es läuft schonmal.
Ihr könnt ja mal testen in wie weit das mit den verschiedenen CPUs funktioniert. Habs nur auf meinem 486er getestet, da läuft er ganz gut (und schon bei dem einfachen Bench bringt die 486er optimierung ca. 27.5% mehr Leistung).
Momentan testet das Prog noch vom 8086 bis 686 (bzw. bis dahin, wo die CPU ausreicht) - auf einem <386 dürften die FPU Operationen aber den Rechner abschmieren lassen - wäre dankbar, wenn das einer testen könnte. Bin mir nämlich net sicher, möglicherweise brauch ich kein Extraprog für 8086 und 286 machen.
Aber hier nun der Link: http://home.arcor.de/intelhasser2/486bench/b386_0.exe
Einfach irgendwo speichern und ausführen, vielleicht stürzt ein <686 im Realmode ab (wenn aus irgend einem Grund der 686 Code drauf gestartet wird), aber ansonsten dürfte nix passieren.
funzt wunderbar, auch @ 386er... schreibt der auch die Werte irgendwohin ?
edit: ein 286er von meinem vadder (kein Plan was des für einer is ?! is in nem Laptop ähnlichen gebilde ?!!!! glaub aber intel) is abgeschmiert
edit2: des laptop ähnliche gebilde is nen Messgerät : Wandel & Goltermann ANT-16 oso
edit: ein 286er von meinem vadder (kein Plan was des für einer is ?! is in nem Laptop ähnlichen gebilde ?!!!! glaub aber intel) is abgeschmiert
edit2: des laptop ähnliche gebilde is nen Messgerät : Wandel & Goltermann ANT-16 oso
Zuletzt bearbeitet:
Der 286er will nicht?
Ich überlege gerade... ich denkde ich werd das doch alles in Einzelprogramme packen, für jeden CPU Typ eins.
Thx auf jeden Fall fürs Testen, werd heute wieder weitermachen - hab gestern leider nix geschafft.
Ich überlege gerade... ich denkde ich werd das doch alles in Einzelprogramme packen, für jeden CPU Typ eins.
Thx auf jeden Fall fürs Testen, werd heute wieder weitermachen - hab gestern leider nix geschafft.
So, hab jetzt den halben SourceTree zerlegt und wieder zusammengebastelt 
http://home.arcor.de/intelhasser2/486bench/b8086_1.exe
Kannst du das mal bitte auf dem 286er testen? Müsste jetzt eigentlich laufen. Die Benches dauern vielleicht ein bisschen, aber abschmieren sollte er net (siehst du daran, ob du noch Num umschalten kannst).
Die CPU Erkennung hab ich erstmal wieder rausgenommen, ich hoffe das alles so hinzubekommen, dass ich ein und denselben Source für 8086 bis 686 jeweils mit/ohne FPU im Realmode und im Protected Mode compilieren kann - und die Assembler-CPU Erkennungroutine würde das nicht so ganz zulassen
http://home.arcor.de/intelhasser2/486bench/b8086_1.exe
Kannst du das mal bitte auf dem 286er testen? Müsste jetzt eigentlich laufen. Die Benches dauern vielleicht ein bisschen, aber abschmieren sollte er net (siehst du daran, ob du noch Num umschalten kannst).
Die CPU Erkennung hab ich erstmal wieder rausgenommen, ich hoffe das alles so hinzubekommen, dass ich ein und denselben Source für 8086 bis 686 jeweils mit/ohne FPU im Realmode und im Protected Mode compilieren kann - und die Assembler-CPU Erkennungroutine würde das nicht so ganz zulassen
Kommando zurück!
Hab einen dicken Fehler entdeckt, er hat falsch gerechnet - daher gingen die Ergbenisse auch soweit auseinander.
Bin gerade dabei das zu fixen, die FPU Version hat immer richtig gerechnet (und lief desswegen so langsam).
Hab einen dicken Fehler entdeckt, er hat falsch gerechnet - daher gingen die Ergbenisse auch soweit auseinander.
Bin gerade dabei das zu fixen, die FPU Version hat immer richtig gerechnet (und lief desswegen so langsam).
och menno
Die Leute die WatCom gemacht haben könnt ich vielleicht treten!
Da hat die FPU Emulator Lib doch genau die selben Befehle wie die, die direkt auf die FPU zugreift
Wenn man dann natürlich ein Prog schreiben will, das abwechselnd mal die FPU nimmt und mal nicht geht das alles beim Linken wieder über den Jordan
- die Funktionsnamen in den Libs sind ja die Selben. Der Linker nimmt dann einfach die erstbeste Funktion diesen Namens, die er sieht.
Tja, nun darf ich den SourceTree nochmal auseinandernehmen. Das gibt dann ein Programm für speziell für jede CPU/FPU Kombination.
Na wenigstens kann ich da endlich alles komplett zusammenpacken, damit wirds nur eine große Batchdatei - nicht wie bisher ein Hauptprog und viele Bench-OBJs.
E: Natürlich kann man dann noch ein kleines Prog hacken, das die ganzen Benches unsichtbar laufen lässt und die Ergebnisse in einer Datei speichert, und das alles dann schön zusammenfasst und noch mit Graphiken/Vergleichen etc. versüßt.
Die Leute die WatCom gemacht haben könnt ich vielleicht treten!
Da hat die FPU Emulator Lib doch genau die selben Befehle wie die, die direkt auf die FPU zugreift
Wenn man dann natürlich ein Prog schreiben will, das abwechselnd mal die FPU nimmt und mal nicht geht das alles beim Linken wieder über den Jordan
- die Funktionsnamen in den Libs sind ja die Selben. Der Linker nimmt dann einfach die erstbeste Funktion diesen Namens, die er sieht.Tja, nun darf ich den SourceTree nochmal auseinandernehmen. Das gibt dann ein Programm für speziell für jede CPU/FPU Kombination.
Na wenigstens kann ich da endlich alles komplett zusammenpacken, damit wirds nur eine große Batchdatei - nicht wie bisher ein Hauptprog und viele Bench-OBJs.
E: Natürlich kann man dann noch ein kleines Prog hacken, das die ganzen Benches unsichtbar laufen lässt und die Ergebnisse in einer Datei speichert, und das alles dann schön zusammenfasst und noch mit Graphiken/Vergleichen etc. versüßt.
Zuletzt bearbeitet:
) vllt. liegts daran ?Ich werd nochmal extra eine Version für den 286er basteln, bei den letzten ist immer was mit der FPU Lib schiefgegangen.
Hab gestern nochmal vieles neu gemacht, jetzt hab ich eine Version die relativ gut läuft. Allerdings ist jetzt eben auch jedes Prog auf eine CPU/FPU Kombi zugeschnitten.
http://home.arcor.de/intelhasser2/486bench/b286e_rm_2.exe
Hab ich eben neu compiliert, hoffe die läuft. Hab inzwischen auch einige der benches reingepackt, 3x Primzahl, 2x Sortieren und 1x PI Berechnen.
Der 3. Primzahlbench könnte relativ lange dauern, so zwischen 60sek und 120sek.
Ich werd glaub ich mal meinen 286er aus dem Schrank holen und diensttauglich machen. Meinen 386er könnt ich da auch gleich noch mit nehmen, für den hab ich sogar einen FPU
E: Der Bench lief eben erfolgreich auf meinem 386er, einmal mit und einmal ohne FPU - also die FPU emulation schreint zu funktionieren.
Den Huge Prime Search Test nehm ich aber wieder raus, da braucht mein 386-40 schon 46 Sekunden für einen Durchlauf.
Hab gestern nochmal vieles neu gemacht, jetzt hab ich eine Version die relativ gut läuft. Allerdings ist jetzt eben auch jedes Prog auf eine CPU/FPU Kombi zugeschnitten.
http://home.arcor.de/intelhasser2/486bench/b286e_rm_2.exe
Hab ich eben neu compiliert, hoffe die läuft. Hab inzwischen auch einige der benches reingepackt, 3x Primzahl, 2x Sortieren und 1x PI Berechnen.
Der 3. Primzahlbench könnte relativ lange dauern, so zwischen 60sek und 120sek.
Ich werd glaub ich mal meinen 286er aus dem Schrank holen und diensttauglich machen. Meinen 386er könnt ich da auch gleich noch mit nehmen, für den hab ich sogar einen FPU
E: Der Bench lief eben erfolgreich auf meinem 386er, einmal mit und einmal ohne FPU - also die FPU emulation schreint zu funktionieren.
Den Huge Prime Search Test nehm ich aber wieder raus, da braucht mein 386-40 schon 46 Sekunden für einen Durchlauf.
Zuletzt bearbeitet:
1. Halberfolgreicher Plattformtest:
hab 2mal compiliert, einmal unter Nutzung der Emulation und einmal mit der FPU selbst. Um ganz sicher zu gehen hab ich einmal dem 386er die FPU entzogen.
hier einfach mal die Ergebnisse, sagen glaub ich alles.
Ich hab nur den 5. und 6. Bench genommen, die einzigen die wirklich die FPU strapazieren (5 ist PI Berechnung, 6 ist Fraktalberechnung).
Also sowie er eine FPU findet wird die auch genommen - auch wenn ich ihm sage er soll alles emulieren.
Hier sieht man endlich auch mal die Geschwindigkeitsunterschiede, also das + das eine FPU so bringt.
Mich stört es allerdings, dass er die FPU nimmt sowie sie da ist - da kann man nicht vergleichen. Mal sehen ob ich das noch wegbekomme.
Die FPU Variante ist da oben nur schneller als die Emu (mit 387), weil ich bei der Emu beim compilieren nicht gesagt hab, dass in dem Rechner ein 387 und kein 8087 steckt.
hab 2mal compiliert, einmal unter Nutzung der Emulation und einmal mit der FPU selbst. Um ganz sicher zu gehen hab ich einmal dem 386er die FPU entzogen.
hier einfach mal die Ergebnisse, sagen glaub ich alles.
Ich hab nur den 5. und 6. Bench genommen, die einzigen die wirklich die FPU strapazieren (5 ist PI Berechnung, 6 ist Fraktalberechnung).
Code:
Ohne 387, Emu:
#5 701.14
#6 0.179
Ohne 387, FPU - hier isser erwartungsgemäß abgeschmiert ;D
Mit 387, Emu:
#5 10688
#6 3
Mit 387, FPU:
#5 10738
#6 3.5Also sowie er eine FPU findet wird die auch genommen - auch wenn ich ihm sage er soll alles emulieren.
Hier sieht man endlich auch mal die Geschwindigkeitsunterschiede, also das + das eine FPU so bringt.
Mich stört es allerdings, dass er die FPU nimmt sowie sie da ist - da kann man nicht vergleichen. Mal sehen ob ich das noch wegbekomme.
Die FPU Variante ist da oben nur schneller als die Emu (mit 387), weil ich bei der Emu beim compilieren nicht gesagt hab, dass in dem Rechner ein 387 und kein 8087 steckt.
Langsam bekommt die Sache Form 
http://home.arcor.de/intelhasser2/486bench/bench_3.zip
Das ist irgendwo zwischen alpha, beta und pre-release. Konzeptionell wird sich auf jeden Fall nicht mehr viel ändern, bzw. besser gesagt so gut wie garnix 8)
Das Zip enthält einige Dateien, b[CPU][EMU/FPU].exe
Die CPU steht wie sich sicherlich ersehen lässt für eine bestimmte CPU, auf die der Bench optimiert wurde. EMU nutzt keine FPU, FPU nutzt dagegen die vorhandene FPU und ist auch darauf optimiert (jeweils zur CPU passend zb. auf den 387).
WICHTIG! Ihr müsst bevor ihr die Benchmarks laufen lasst SET NO87=1 eintippen!
Sonst greift die EMU Version in einigen Dingen auch auf die FPU (wenn vorhanden) zurück - die EMU Funktionen sind dann trotzdem deutlich langsamer als die FPU, aber trotzdem schneller als eine komplett emulierte FPU.
Zur Erklärung: Es gibt 3 Möglichkeiten die Mathematik mit Watcom umzusetzen,
1. Zugriff auf eine Hardware FPU
2. Zugriff auf die FPU - die FPU wird jedoch von der Software emuliert
3. Sämtliche Mathefunktionen werden anders übersetzt, sind dann FPU inkompatibel. Dadurch kann man zwar die Hardware FPU nicht wirklich nutzen, aber es ist trotzdem deutlich schneller als die 2. Version mit einer Software FPU.
Die FPU Progs nehmen die 1. Methode, die EMU Progs die 3.
Die anderen Mathefunktionen aus 3. scheinen aber doch hier und da von einer FPU gebrauch zu machen, falls vorhanden. Die Ergebnisse liegen dann irgendwo zwischen denen ohne FPU und denen mit FPU, sind also nicht zu gebrauchen.
Ich werd mich jetzt wahrscheinlich mal an die Protected Mode Versionen machen, glücklicherweise brauch ich da im Code fast nix ändern.
/e
und um hier gleich mal einen kleinen Anspurn zu geben die Werte die mein Am386DX-40 mit Ulsi Sys 387, 20mb Ram und 256kb L2 Cache im Turbo Mode 8) erreicht:
#1: 2.43
#2: 0.225
#3: 12.82
#4: 1.45
#5: 14663
#6: 3.48
Die Werte werden sich in der Final Version noch ändern, auf jeden Fall werd ich den PI Bench noch etwas modifizieren - auf meinem großen Spuckt er mir Inf durchläufe pro Sekunde aus
Kann auch sein, dass durch optimierungen hier und da alle Benches noch etwas schneller werden - das wird sich dann zeigen müssen.
Auf jeden Fall kommen noch ein paar Benches dazu. Hier mal eine Übersicht, was die einzelnen Benches so fordern:
(+ wird stark gefordert, - weniger - der rest weitestgehend überhauptnet)
#1: +MEM -INT
#2: +MEM -INT
#3: +MEM
#4: +INT +MEM (extren viel Zeigerarithmetik - tja, realmode eben)
#5: +FPU
#6: +FPU
Also FPU/MEM Benchmarks sind noch garkeine drinnen, und reine INT Benchmarks fehlen auch noch.
Irgendwo möchte ich auch noch eine Kombi reinpacken, die so ziemlich alles fordert - wie es eben in einem Spiel sein könnte.
/e Die erste Protected Mode Version hat soeben das Licht der Welt erblickt
/e Erste brauchbare Ergebnisse der Protected Mode Version:
#1 4.38
#2 0.4
#3 12.4
#4 4.98 (-> deutlich weniger Zeigerarithmetik, den Bench hab ich inzwischen aber auch deutlich überholt)
#5 14625
#6 4.6
Wie man sieht bringt der Protected Mode bei einigen Benches extreme Geschwindigkeitsvorteile (Primzahlen, Mandelbrot) und bei einigen anderen Benches ändert sich so ziemlich garnix.
Ich werd mir jetzt mal noch ein paar weitere Benches ausdenken. Mal sehen was mir noch so einfällt, einen LinPack will ich noch implementieren.
http://home.arcor.de/intelhasser2/486bench/bench_3.zip
Das ist irgendwo zwischen alpha, beta und pre-release. Konzeptionell wird sich auf jeden Fall nicht mehr viel ändern, bzw. besser gesagt so gut wie garnix 8)
Das Zip enthält einige Dateien, b[CPU][EMU/FPU].exe
Die CPU steht wie sich sicherlich ersehen lässt für eine bestimmte CPU, auf die der Bench optimiert wurde. EMU nutzt keine FPU, FPU nutzt dagegen die vorhandene FPU und ist auch darauf optimiert (jeweils zur CPU passend zb. auf den 387).
WICHTIG! Ihr müsst bevor ihr die Benchmarks laufen lasst SET NO87=1 eintippen!
Sonst greift die EMU Version in einigen Dingen auch auf die FPU (wenn vorhanden) zurück - die EMU Funktionen sind dann trotzdem deutlich langsamer als die FPU, aber trotzdem schneller als eine komplett emulierte FPU.
Zur Erklärung: Es gibt 3 Möglichkeiten die Mathematik mit Watcom umzusetzen,
1. Zugriff auf eine Hardware FPU
2. Zugriff auf die FPU - die FPU wird jedoch von der Software emuliert
3. Sämtliche Mathefunktionen werden anders übersetzt, sind dann FPU inkompatibel. Dadurch kann man zwar die Hardware FPU nicht wirklich nutzen, aber es ist trotzdem deutlich schneller als die 2. Version mit einer Software FPU.
Die FPU Progs nehmen die 1. Methode, die EMU Progs die 3.
Die anderen Mathefunktionen aus 3. scheinen aber doch hier und da von einer FPU gebrauch zu machen, falls vorhanden. Die Ergebnisse liegen dann irgendwo zwischen denen ohne FPU und denen mit FPU, sind also nicht zu gebrauchen.
Ich werd mich jetzt wahrscheinlich mal an die Protected Mode Versionen machen, glücklicherweise brauch ich da im Code fast nix ändern.
/e
und um hier gleich mal einen kleinen Anspurn zu geben die Werte die mein Am386DX-40 mit Ulsi Sys 387, 20mb Ram und 256kb L2 Cache im Turbo Mode 8) erreicht:
#1: 2.43
#2: 0.225
#3: 12.82
#4: 1.45
#5: 14663
#6: 3.48
Die Werte werden sich in der Final Version noch ändern, auf jeden Fall werd ich den PI Bench noch etwas modifizieren - auf meinem großen Spuckt er mir Inf durchläufe pro Sekunde aus
Kann auch sein, dass durch optimierungen hier und da alle Benches noch etwas schneller werden - das wird sich dann zeigen müssen.
Auf jeden Fall kommen noch ein paar Benches dazu. Hier mal eine Übersicht, was die einzelnen Benches so fordern:
(+ wird stark gefordert, - weniger - der rest weitestgehend überhauptnet)
#1: +MEM -INT
#2: +MEM -INT
#3: +MEM
#4: +INT +MEM (extren viel Zeigerarithmetik - tja, realmode eben
)#5: +FPU
#6: +FPU
Also FPU/MEM Benchmarks sind noch garkeine drinnen, und reine INT Benchmarks fehlen auch noch.
Irgendwo möchte ich auch noch eine Kombi reinpacken, die so ziemlich alles fordert - wie es eben in einem Spiel sein könnte.
/e Die erste Protected Mode Version hat soeben das Licht der Welt erblickt
/e Erste brauchbare Ergebnisse der Protected Mode Version:
#1 4.38
#2 0.4
#3 12.4
#4 4.98 (-> deutlich weniger Zeigerarithmetik, den Bench hab ich inzwischen aber auch deutlich überholt)
#5 14625
#6 4.6
Wie man sieht bringt der Protected Mode bei einigen Benches extreme Geschwindigkeitsvorteile (Primzahlen, Mandelbrot) und bei einigen anderen Benches ändert sich so ziemlich garnix.
Ich werd mir jetzt mal noch ein paar weitere Benches ausdenken. Mal sehen was mir noch so einfällt, einen LinPack will ich noch implementieren.
Zuletzt bearbeitet:
So, heute hab ich die Oberfläche endlich mal gemacht. Sieht schon viel besser aus
Den PI Benchmark hab ich gekickt. Dafür ist Dhrystone und Whetstone dazugekommen, einen Speicherbandbreitenbenchmark hab ich auch noch reingesetzt.
(für alle 3 muss aber noch der Code geschrieben werden
)
Dazu ist noch ein Vergleichssystem gekommen - zum Schluss wird aus den Integer Benches (Primzahlen, Bubblesort) und den FPU Benches (Mandelbrot, neuer Bildberechnungsbench den ich sogar schon fertig hab) jeweils eine Highscore errechnet, die dann auch noch zu einer Schlussendlichen Highscore zusammengefasst wird.
Orientieren soll sich die dann an meinem Am386-DX40 mit 387DX und 256kb Cache mit einem Via Chipsatz unten drunter - der Rechner bekommt überall eine Highscore von 1.
Die künstlichen Benches (Dhry/Whetstone und MEM) lass ich draußen, die bekommen zwar auch so einen Index, gehen aber net in die Endbewertung ein.
Vielleicht mach ich noch Versionen für WinNT, Win3.11, OS/2 und Linux - für die ersten 3 müsste ich nur die Makefile etwas modifizieren, bei Linux weis ich net ob der WatCom Compiler das kann.
Aber daran denk ich erst wenn die DOS Version draußen ist.
Ich hab auch mal die Compileroptimierungen ausprobiert - auf den alten Mühlen scheint das recht wenig zu machen, auf den neueren dagegen extrem viel.
Mein 386er hat den 286 Code praktisch genausoschnell ausgeführt (obwohl dann nur 16bit Register), mein P90 Notebook ist von 286 zu 586 43% schneller geworden (und war bei 386 Code pi*Daumen 10% schneller).
Schreibt doch auch mal was - ich brauch noch ein paar Anregungen für neue Benchmarks, bis auf den Primzahlalgorithmus sind die jetzigen Benches alle noch etwas einfach - da müssen noch ein paar richtige Wuchtbrummen rein
Mir fällt da spontan nur ein Packalgorithmus und vll JPEG ein - die werden aber auf 286 bis 486 sowieso selten zum Einsatz kommen, ich brauch eher sowas wie es auch wirklich in den alten Spielen vorkommen könnte.
Oder eben ein paar Office Benchmarks.
Den PI Benchmark hab ich gekickt. Dafür ist Dhrystone und Whetstone dazugekommen, einen Speicherbandbreitenbenchmark hab ich auch noch reingesetzt.
(für alle 3 muss aber noch der Code geschrieben werden
)Dazu ist noch ein Vergleichssystem gekommen - zum Schluss wird aus den Integer Benches (Primzahlen, Bubblesort) und den FPU Benches (Mandelbrot, neuer Bildberechnungsbench den ich sogar schon fertig hab) jeweils eine Highscore errechnet, die dann auch noch zu einer Schlussendlichen Highscore zusammengefasst wird.
Orientieren soll sich die dann an meinem Am386-DX40 mit 387DX und 256kb Cache mit einem Via Chipsatz unten drunter - der Rechner bekommt überall eine Highscore von 1.
Die künstlichen Benches (Dhry/Whetstone und MEM) lass ich draußen, die bekommen zwar auch so einen Index, gehen aber net in die Endbewertung ein.
Vielleicht mach ich noch Versionen für WinNT, Win3.11, OS/2 und Linux - für die ersten 3 müsste ich nur die Makefile etwas modifizieren, bei Linux weis ich net ob der WatCom Compiler das kann.
Aber daran denk ich erst wenn die DOS Version draußen ist.
Ich hab auch mal die Compileroptimierungen ausprobiert - auf den alten Mühlen scheint das recht wenig zu machen, auf den neueren dagegen extrem viel.
Mein 386er hat den 286 Code praktisch genausoschnell ausgeführt (obwohl dann nur 16bit Register), mein P90 Notebook ist von 286 zu 586 43% schneller geworden (und war bei 386 Code pi*Daumen 10% schneller).
Schreibt doch auch mal was
- ich brauch noch ein paar Anregungen für neue Benchmarks, bis auf den Primzahlalgorithmus sind die jetzigen Benches alle noch etwas einfach - da müssen noch ein paar richtige Wuchtbrummen rein Mir fällt da spontan nur ein Packalgorithmus und vll JPEG ein - die werden aber auf 286 bis 486 sowieso selten zum Einsatz kommen, ich brauch eher sowas wie es auch wirklich in den alten Spielen vorkommen könnte.
Oder eben ein paar Office Benchmarks.
Riza
Vice Admiral Special
Hallo Nicht Intel Liebhaber,
leider habe ich von den Interna der Programmierung NULL000NULL Ahnung,
finde es trotzdem stark, dass du dich mit soviel Einsatz (Oh Pisa-Gott, wie schreibt man Engagement
))?)
Ein Vergleich (Bench) sollte auch den Unterschied zwischen Alten und neuen PCs sichtbar machen. Hier habe ich den ZD Win 97 Bench verflucht, der auf meinem 2500er einfach nicht laufen will;-(((.
Inwieweit werden deine Benches für die praktische Arbeit aussagefähig sein?
Sorry dass ich nix fachliches beitragen kann.
Gruss
rene
leider habe ich von den Interna der Programmierung NULL000NULL Ahnung,
finde es trotzdem stark, dass du dich mit soviel Einsatz (Oh Pisa-Gott, wie schreibt man Engagement
))?)Ein Vergleich (Bench) sollte auch den Unterschied zwischen Alten und neuen PCs sichtbar machen. Hier habe ich den ZD Win 97 Bench verflucht, der auf meinem 2500er einfach nicht laufen will;-(((.
Inwieweit werden deine Benches für die praktische Arbeit aussagefähig sein?
Sorry dass ich nix fachliches beitragen kann.
Gruss
rene
Einfach so Resonanz zu zeigen ist auch gut - wenn es die Hitzahlen der einzelnen Threads net gäbe könnte man meinen, ich mach hier Alleinunterhalter
Auf die Systemübergreifende Kompatiblität hab ich großen Wert gelegt - also der Bench läuft auch auf aktueller Hardware, testen tue ich die Benches vorwiegend mit meinem großen (TBred2.2GHz).
Bisher sind nur praxisrelevante Benchmarks drinnen. Dhrystone und Whetstone werden wohl die einzigen synthetischen Benchmarks werden (mal von der Speicherbandbreite abgesehen).
Der erste Benchmark sucht nach Primzahlen - also sowas wie Prime95, nur ist die Methode völlig anders, so dass die FPU bei dem Bench keine Arbeit hat.
Der 2. Bench ist ein einfacher Sortieralgorithmus - der erzeugt immer die selbe Zufallsliste, die dann der größe nach sortiert wird.
Danach kommt momentan der Mandelbrot Benchmark, hier wird ein Fraktal berechnet - FPU Arbeit, sonst nix.
Und zu guter letzt kommt der Bench mit dem ich so ziemlich am zufriedensten bin (weil er am ehesten den Spieleanforderungen entspricht). Hier wird ein Bild erzeugt, um irgend einen Winkel rotiert und schließlich wird noch ein Transparenzeffekt mit einem anderen Bild berechnet.
Da fehlen eben noch so ein bisschen die Benches, die wirklich die Spieleleistung ermitteln. Momentan konzentrieren sich die Benches eher noch auf kleine Teilbereiche - FPU, INT oder Speicherbandbreite - die waren aber erstmal am einfachsten zu implementieren.
Was jetzt eben fehlt sind noch etwas komplexere Benchmarks, wo deutlich mehr Einzelschritte nötig sind. Vielleicht werd ich einen zip Algorithmus implementieren, aber das ist mir schon wieder fast zuviel Aufwand.
Tja... mir gehen eben die Ideen aus, was so noch an Benchmarks rein könnte. 4 sind a bisserl wenig
Auf die Systemübergreifende Kompatiblität hab ich großen Wert gelegt - also der Bench läuft auch auf aktueller Hardware, testen tue ich die Benches vorwiegend mit meinem großen (TBred2.2GHz).
Bisher sind nur praxisrelevante Benchmarks drinnen. Dhrystone und Whetstone werden wohl die einzigen synthetischen Benchmarks werden (mal von der Speicherbandbreite abgesehen).
Der erste Benchmark sucht nach Primzahlen - also sowas wie Prime95, nur ist die Methode völlig anders, so dass die FPU bei dem Bench keine Arbeit hat.
Der 2. Bench ist ein einfacher Sortieralgorithmus - der erzeugt immer die selbe Zufallsliste, die dann der größe nach sortiert wird.
Danach kommt momentan der Mandelbrot Benchmark, hier wird ein Fraktal berechnet - FPU Arbeit, sonst nix.
Und zu guter letzt kommt der Bench mit dem ich so ziemlich am zufriedensten bin (weil er am ehesten den Spieleanforderungen entspricht). Hier wird ein Bild erzeugt, um irgend einen Winkel rotiert und schließlich wird noch ein Transparenzeffekt mit einem anderen Bild berechnet.
Da fehlen eben noch so ein bisschen die Benches, die wirklich die Spieleleistung ermitteln. Momentan konzentrieren sich die Benches eher noch auf kleine Teilbereiche - FPU, INT oder Speicherbandbreite - die waren aber erstmal am einfachsten zu implementieren.
Was jetzt eben fehlt sind noch etwas komplexere Benchmarks, wo deutlich mehr Einzelschritte nötig sind. Vielleicht werd ich einen zip Algorithmus implementieren, aber das ist mir schon wieder fast zuviel Aufwand.
Tja... mir gehen eben die Ideen aus, was so noch an Benchmarks rein könnte. 4 sind a bisserl wenig
ericszb
Vice Admiral Special
respekt was du dir da für ne arbeit machst!
und alles nur für uns
sag mal mit was programmierst du den bench?
würde auch gerne als alpha tester für die neueren cpu's herhalten
mfg eric
und alles nur für uns
sag mal mit was programmierst du den bench?
würde auch gerne als alpha tester für die neueren cpu's herhalten
mfg eric
Zuletzt bearbeitet:
Der Bench ist komplett in C (ohne ++ ), und auch ohne inline Assembler etc (sonst müsste ich das für den Protected Mode komplett ändern).
Mundgerecht zugeschnitten für den WatCom C Compiler.
Ich werd wohl mal in der nächsten Zeit die Makefiles noch etwas umschreiben, theoretisch wäre es nämlich kein Problem da auch winnt und os2 Versionen drauszuzaubern (muss nur andere compiler und linker flags setzen).
Wenn sich mal wieder was großartig ändert ladt ich wieder eine Version hoch - schreibt einfach, ob und wie sie funktioniert hat
Was mich an der Sache reizt ist die dann (hoffentlich) entstehende Benchmarktabelle, wo von 8086 bis zu aktuellen CPUs alles dabei ist - dazu noch mit detaillierten Chipsatzangaben usw
/E: Ich denk ich werd das ganze jetzt doch auf DJGPP umstellen. Damit wirds auch gleich POSSIX kompatibel -> linux/win32/os2 ist auch kein problem (ok, wars bis jetzt auch net).
Aber DJGPP bietet einfach deutlich mehr Optimierungen, der Timer geht genauer (1MHz vs. 1KHz) und es ist eben im Protected Mode (ok, das bekomm ich mit WatCom auch hin).
Die 8086 und 286 Version werd ich aber weiter mit WatCom machen (müssen), die können ja keinen Protected Mode. Ab 386 reicht DOS mit Emm386 komplett aus. Idealerweise umgehe ich damit gleich einige Speicherprobleme, mit DJGPP sind > 1mb natürlich auch kein Problem mehr.
Damit werden die Benches auch weniger Cache-Lastig.
Den bestehenden Code müsste ich relativ einfach portieren können. Mal sehen was da rauskommt
/E2:
Jawoll! Das nenn ich doch mal eine erfolgreiche Portierung
Mal ganz davon abgesehen, dass die DJGPP Version auf meinem 386er im Schnitt 1.52mal so schnell läuft hat dich der Aufwand in den Makefiles extremst(!) verringert. Statt den 7 Compileraufrufen und dem einen Linker Aufruf vorher reicht nun ein einfaches gcc *.c -O3 -mhard_float -march=i386 und der compiliert gleich das gesamte Prog
/E:
- langsam komm ich mir dumm vor, jetzt darf ich schon wieder was am Konzept ändern ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Also ich werd 2 Kategorien machen - Realmode Benches und Protected Mode Benches.
Warum? Mir juckts seit djgpp in den Fingern, mit WatCom kann ich effektiv nur immer 64kb Speicher nehmen - danach muss ich noch irgendwelche Krepelroutinen für Segmentierung implementieren, von EMS/XMS will ich jetzt garnet erst reden.
Also werden das alles nette kleine Häppchen, die in den Cache meines 386ers passen - nicht gerade sooooo aussagekräftig - zumindest net für größere Dos Spiele etc. die ja praktisch alle einen protected mode extender nehmen.
Für die kleineren/älteren Spiele sind die benches dagegen garnet schlecht - die sind selbser auch im Realmode geschrieben, unterliegen also den selben Beschränkungen wie die Realmode Benches.
Tja, ist ja irgendwie klar, was da rauskommen muss. Ich will net, dass die Benches alle von den besseren CPUs im Cache abgespeißt werden, weil das dann keine Realitätsbezogenen Werte sind.
Andererseits kann ich die Realmode Benches auch net so ohne weiteres für >64kb verändern, weil die Programme dann alles andere als kompatibel zu irgendwelchen anderen Betriebsmodi/OS/Compiler sind.
Und zu guter letzt bringt der Protected Mode ja auch wirklich Speed. Und nicht wenige Spiele nutzen den auch.
Den 8086/286 will ich von den Benches auch net ausschließen, die Werte von denen sind ja auch sehr interessant - wie schnell ist zb. ein 286-16MHz im Vergleich zu einem 386-16MHz.
), und auch ohne inline Assembler etc (sonst müsste ich das für den Protected Mode komplett ändern).Mundgerecht zugeschnitten für den WatCom C Compiler.
Ich werd wohl mal in der nächsten Zeit die Makefiles noch etwas umschreiben, theoretisch wäre es nämlich kein Problem da auch winnt und os2 Versionen drauszuzaubern (muss nur andere compiler und linker flags setzen).
Wenn sich mal wieder was großartig ändert ladt ich wieder eine Version hoch - schreibt einfach, ob und wie sie funktioniert hat
Was mich an der Sache reizt ist die dann (hoffentlich) entstehende Benchmarktabelle, wo von 8086 bis zu aktuellen CPUs alles dabei ist - dazu noch mit detaillierten Chipsatzangaben usw
/E: Ich denk ich werd das ganze jetzt doch auf DJGPP umstellen. Damit wirds auch gleich POSSIX kompatibel -> linux/win32/os2 ist auch kein problem (ok, wars bis jetzt auch net).
Aber DJGPP bietet einfach deutlich mehr Optimierungen, der Timer geht genauer (1MHz vs. 1KHz) und es ist eben im Protected Mode (ok, das bekomm ich mit WatCom auch hin).
Die 8086 und 286 Version werd ich aber weiter mit WatCom machen (müssen), die können ja keinen Protected Mode. Ab 386 reicht DOS mit Emm386 komplett aus. Idealerweise umgehe ich damit gleich einige Speicherprobleme, mit DJGPP sind > 1mb natürlich auch kein Problem mehr.
Damit werden die Benches auch weniger Cache-Lastig.
Den bestehenden Code müsste ich relativ einfach portieren können. Mal sehen was da rauskommt
/E2:
Jawoll! Das nenn ich doch mal eine erfolgreiche Portierung
Mal ganz davon abgesehen, dass die DJGPP Version auf meinem 386er im Schnitt 1.52mal so schnell läuft hat dich der Aufwand in den Makefiles extremst(!) verringert. Statt den 7 Compileraufrufen und dem einen Linker Aufruf vorher reicht nun ein einfaches gcc *.c -O3 -mhard_float -march=i386 und der compiliert gleich das gesamte Prog
/E:
- langsam komm ich mir dumm vor, jetzt darf ich schon wieder was am Konzept ändern Also ich werd 2 Kategorien machen - Realmode Benches und Protected Mode Benches.
Warum? Mir juckts seit djgpp in den Fingern, mit WatCom kann ich effektiv nur immer 64kb Speicher nehmen - danach muss ich noch irgendwelche Krepelroutinen für Segmentierung implementieren, von EMS/XMS will ich jetzt garnet erst reden.
Also werden das alles nette kleine Häppchen, die in den Cache meines 386ers passen - nicht gerade sooooo aussagekräftig - zumindest net für größere Dos Spiele etc. die ja praktisch alle einen protected mode extender nehmen.
Für die kleineren/älteren Spiele sind die benches dagegen garnet schlecht - die sind selbser auch im Realmode geschrieben, unterliegen also den selben Beschränkungen wie die Realmode Benches.
Tja, ist ja irgendwie klar, was da rauskommen muss. Ich will net, dass die Benches alle von den besseren CPUs im Cache abgespeißt werden, weil das dann keine Realitätsbezogenen Werte sind.
Andererseits kann ich die Realmode Benches auch net so ohne weiteres für >64kb verändern, weil die Programme dann alles andere als kompatibel zu irgendwelchen anderen Betriebsmodi/OS/Compiler sind.
Und zu guter letzt bringt der Protected Mode ja auch wirklich Speed. Und nicht wenige Spiele nutzen den auch.
Den 8086/286 will ich von den Benches auch net ausschließen, die Werte von denen sind ja auch sehr interessant - wie schnell ist zb. ein 286-16MHz im Vergleich zu einem 386-16MHz.
Zuletzt bearbeitet:
So, das Vorgeplänkel für die B-Version ist fast fertig. Auf das neue Rating freue ich mich schon, das dürfte relativ praxisnah sein - aber auch deutlich komplexer.
Es wird 6 Teilratings geben, Integer, Float, Mem, Int/Mem, Float/Mem, Int/Float.
Für jeden Bereich 2 Benches, daher auch 12 Benches insgesammt.
Die zusammenfassung der Werte sieht so aus:
rI= rInt+(rIntMem-rMem/2)+(rIntFloat-rFloat/2) (Integer Rating)
rF= rFloat+(rFloatMem-rMem/2)+(rIntFloat-rInt/2) (Float Rating)
rM= rMem+(rIntMem-rInt/2)+(rFloatMem-rFloat/2) (Speicher Rating)
und das Gesamtrating ist dann r= rI*2/6+rF*1/6+rM*3/6
Sieht komplex aus, dürfte aber sehr viel mehr der Praxis entsprechen. Mir ist zb. bei meinem X5 aufgefallen (sitzt auf meinem Board ohne X5 Support - keine Burst Writes und kein Write Back L1 Cache), dass der im Dhrystone Bench deutlichst langsamer war als mit X5 Support - die praxisbenches waren aber nur mimminal geringer (7.x statt 8.x - das Dhrystone Rating viel von 80 auf 30).
Es wird 6 Teilratings geben, Integer, Float, Mem, Int/Mem, Float/Mem, Int/Float.
Für jeden Bereich 2 Benches, daher auch 12 Benches insgesammt.
Die zusammenfassung der Werte sieht so aus:
rI= rInt+(rIntMem-rMem/2)+(rIntFloat-rFloat/2) (Integer Rating)
rF= rFloat+(rFloatMem-rMem/2)+(rIntFloat-rInt/2) (Float Rating)
rM= rMem+(rIntMem-rInt/2)+(rFloatMem-rFloat/2) (Speicher Rating)
und das Gesamtrating ist dann r= rI*2/6+rF*1/6+rM*3/6
Sieht komplex aus, dürfte aber sehr viel mehr der Praxis entsprechen. Mir ist zb. bei meinem X5 aufgefallen (sitzt auf meinem Board ohne X5 Support - keine Burst Writes und kein Write Back L1 Cache), dass der im Dhrystone Bench deutlichst langsamer war als mit X5 Support - die praxisbenches waren aber nur mimminal geringer (7.x statt 8.x - das Dhrystone Rating viel von 80 auf 30).
