Performance Test mit Dosbox 0.62

[dragonmaster]

Hi ho, ich brauche Hilfe bezüglich meines Upgrade Wunsches:
Ich weiß nicht ob ich mir einem Athlon64 oder einen P4 kaufen soll, daher würde ich gerne wissen wieviele cycles man mit einem A64 in Dosbox kriegen kann ohne die Vollauslastung d. h. 100% zu erreichen!

Folgende Spiele habe ich bisher geteste und zwar Duke3d und Descent:

Bei beiden Games habe ich mit einem P4 2,8Ghz(Pc auf der Arbeit) ungefähr 22.000 cycles gekriegt.
Mit meinem bisherigen Pc (Xp1.8rated) 13.500 cycles.
In Duke habe ich folgende Settings benutzt: High Details,Schatten an,Musik: General Midi,Effekt:Gravis Ultrasound,Nur Vga(kein Svga)
In Descent habe ich dieselben Soundeinstellungen wie in Duke gewählt.
In Dosbox habe ich den opengl-Renderer gewählt, und die Normal Core,64 Mb Ram und Frameskip=1 eingestellt
Außerdem habe ich die Performance im Fenster gemessen und zwar mit hwscale=1.10.
In Windows habe ich Dosbox auf Hohe Piorität eingestellt und die Grafigkarte auf 16bit eingestellt.

Vielen Dank im Voraus. Postet bitte eure Ergebniss mit Prozessortyp und Mhz-Zahl falls übertacktet ;)
Und nutzt auch nur diese beiden Spiel da in anderen das Cycleverhalten anders ist.

P.S. Solltet ihr eine Ati-Grafigkarte oder eine andere Grafigkarte haben, die opengl nicht mag, soll ddraw oder overlay besser funktionieren! Aber bitte mitposten wenn ihr einen anderen Renderer benutzt.

[A.Wesker]

mein P4 EE kommt auch bei 200000 cycles nicht auf über 50 %. HT machts möglich :>

[smoe82]

mein P4 EE kommt auch bei 200000 cycles nicht auf über 50 %. HT machts möglich :>


Falsch!

Die 50% sind nur virtuell.
Wenn ein Thread läuft, wird die CPU trotzdem zu 100% ausgelastet. Wenn dann ein 2ter dazukommt, erhält der erste einfach weniger Ressourcen (bzw. freie Res werden besser genutzt). das ist eine Multitasking-funktion á la Windows, nur in Hardware realisiert.

Verstanden?

[dragonmaster]

Bitte Ergebnisse posten und keine Fachsimpeleien. Danke! :biggrin:

[tombman]

Falsch!

Die 50% sind nur virtuell.
Wenn ein Thread läuft, wird die CPU trotzdem zu 100% ausgelastet. Wenn dann ein 2ter dazukommt, erhält der erste einfach weniger Ressourcen (bzw. freie Res werden besser genutzt). das ist eine Multitasking-funktion á la Windows, nur in Hardware realisiert.

Verstanden?

Du liegst flasch; zu 100% wird die cpu NIE ausgenutzt, wennst auf 80% kommst bist schon gut... google mal nach "perfwatch", dann weißt was ich meine.

[smoe82]

Du liegst flasch; zu 100% wird die cpu NIE ausgenutzt, wennst auf 80% kommst bist schon gut... google mal nach "perfwatch", dann weißt was ich meine.


Natürlich nicht. Aber bei einer non-HT-CPU werden hundert Prozent "genutzt", weil eben einem Thread die gesamte Leistung zur Verfügung steht. Durch die schlechte Ausnutzung der Pipelines und Caches, wird effektiv nur 80% genutzt. Da kann auch ein besseres Betriebssystem nichts ändern (welches nun mal nur "sieht", daß der Thread 100% "nutzt"). Multitasking im BS kann nur die vorhandene Prozessorzeit besser nutzen. Was der Prozessor dann macht, ist erst mal uninteressant.

Dort setzt HT an. Man versucht die Threads schon in der CPU besser zu managen. Dabei muß der 2. Thread eben nicht nur das bekommen, was beim ersten "übrig" ist. Und der 1. Thread verbraucht eben auch nicht "nur" 50% der Prozessorleistung, im besten Fall 100%.

Darauf wollte ich hinaus. o.k.?

[Shink]

Naja, ich wuerde mal sagen, ein Vergleich AMD/Intel-Performance in DosBox waer wirklich interessant; aber gibts da keine bessere Benchmark-Technik?

[dragonmaster]

Hmm von den Einstellungen die ich hier angegeben habe, beinflussen fast alle die
Geschwindigkeit, daher müssen sie genau gleich sein, z. B. ist die dynamic-core bei Athlonsystemen sehr viel schneller als bei p4system wo sie laut meinen Messungen gerade mal circa 1000 cycles mehr brachte.
Hinzukommt dass die dynamiccore sehr instabil ist und dosbox dabei öfters crasht.

Zum Videorender kann ich sagen das man grundsätzlich den schnellst nehmen kann: Was bei nvidea meist ddraw oder opengl, bei ati grakas weiß ich es nicht mit Bestimmtheit aber direct3d,overlay oder ddraw sollten sehr schnell sein. Nur den Surface-Modus sollte man meiden da er sehr langsam ist.

Die Speichereinstellung in dosbox sollte so hoch wie möglich sein: 63Mb ist die höchstmögliche Einstellung und sollte auch eingestellt werden auch wenn das Spiel davon nicht unbedingt profitiert.

Das ich Schreibe man sollte dosbox auf Hohe Priorität und den Grafikmodus auf 16bit einstellen und kein Antialaising und Antisotropische Filter soll nur dazu dienen möglichst alle Cpu-Reserven für dosbox zu nutzen.

Die größe dos dosbox Fenster kann man mit Hw-Scale in der dosbox.conf einstellen: Standart ist 1.00 und man sollte es möglichst nicht erhöhen dann ansonsten die Performance leidet gensau wie wenn man in Fulscrenn-Modus mißt. Ich habe mit 1.1 gemessen das macht keinen messbaren Unterschied zu 1.00.

Mit der Frameskip-einstellung kann man dosbox dazu bringen weniger Bilder zu rendern wie normal: Mit der von mir vorgeschlagen Einstellung von Frameskip=1 rendert dosbox genau 35 Bilder im Gegensatz zu den bei VGA übliche 70 Bildern. Bei Frameskip 2 stellt dosbox 23 Bilder da was unter der magischen 30 Framegrenze liegt und daher ruckelt.

Die beiden Games die ich ausgewählt habe sind sehr anspruchsvoll und produzieren mit der normalen Core sehr gleichbleibende Cycleraten.

Ebenso wichtig sind die Einstellung in den beiden Games bezüglich der Grafigkarteneinstellung und der Sondkarteneinstellung jeweils Gravis Ultrasound und VGA, da bei anderen Einstellung z.B. SVGA die Cycleraten ganz andere sind.

Allerdings habe ich eine Erleichterung der Messung gefunden: Auf dieser Webseite
http://home.amis.net/lkslavi/
kann man einen Dosbox-Mod finden bei dem es 2 wichtige Neuerungen gibt:
1.timesync.patch
2.direct3d.patch

Der direct3d.patch ermöglich die Unterstützung von direct3d als renderer , interessant vor allem für Ati Grafigkarten.

Der timesync.patch ermöglicht es das wenn man in der config timesync=true setzt und die normal cycle Rate sehr hoch setzt z. B. auf 100.000 oder höher dann berechnet Dosbox immer soviele Cycles wie möglich bei annähernd 100% Cpu-auslastung.

Das erleichtert das Messen ungemein.

[dragonmaster]

Ich poste einfacherhalber mein configfile des dosboxmod:

Dies ist die Adresse zum mod:
http://home.amis.net/lkslavi/bin/dosboxcvs-041025.zip

Und hier ist meine config:

[sdl]
# fullscreen -- Start dosbox directly in fullscreen.
# fulldouble -- Use double buffering in fullscreen.
# fullfixed -- Don't resize the screen when in fullscreen.
# fullresolution -- What resolution to use for fullscreen, use together with fullfixed.
# output -- What to use for output: surface,overlay,opengl,openglnb,ddraw.
# hwscale -- Extra scaling of window if the output device supports hardware scaling.
# autolock -- Mouse will automatically lock, if you click on the screen.
# sensitiviy -- Mouse sensitivity.
# waitonerror -- Wait before closing the console if dosbox has an error.
# priority -- Priority levels for dosbox: lower,normal,higher,highest.
# Second entry behind the comma is for when dosbox is not focused/minimized.
# mapperfile -- File used to load/save the key/event mappings from.

fullscreen=false
fulldouble=false
fullfixed=false
fullresolution=1024x768
output=ddraw
hwscale=1.10
autolock=true
sensitivity=100
waitonerror=true
priority=higher,higher
mapperfile=mapper.txt

[dosbox]
# language -- Select another language file.
# memsize -- Amount of memory dosbox has in megabytes.
# machine -- The type of machine tries to emulate:hercules,cga,tandy,vga.
# captures -- Directory where things like wave,midi,screenshot get captured.

language=
machine=vga
captures=capture
memsize=63

[render]
# frameskip -- How many frames dosbox skips before drawing one.
# aspect -- Do aspect correction.
# scaler -- Scaler used to enlarge/enhance low resolution modes.
# Supported are none,normal2x,advmame2x,advmame3x,advinterp2x,interp2x,tv2x,hq2x.
# hq2x_threshold_adaptive -- The adaptive threshold used to detect edges in hq2x
# Possible values are 0-100, can be modified with Ctrl+Alt+F5/F6
# hq2x_threshold -- The static threshold used to detect edges in hq2x
# Possible values are 0-255, can be modified with Ctrl+Alt+F3/F4

frameskip=1
aspect=false
scaler=normal2x
hq2x_threshold_adaptive=75
hq2x_threshold=0

[cpu]
# core -- CPU Core used in emulation: simple,normal,full,dynamic.
# cycles -- Amount of instructions dosbox tries to emulate each millisecond.
# Setting this higher than your machine can handle is bad! (unless timesynched is set)
# cycleup -- Amount of cycles to increase/decrease with keycombo.
# cycledown Setting it lower than 100 will be a percentage.
# timesynched -- Do not emulate more cycles than possible.
# showcycles -- Display the number of emulated cycles in the titlebar (uses some CPU).

core=normal
cycles=100000
cycleup=500
cycledown=500
timesynched=true
showcycles=true

[mixer]
# nosound -- Enable silent mode, sound is still emulated though.
# rate -- Mixer sample rate, setting any devices higher than this will
# probably lower their sound quality.
# blocksize -- Mixer block size, larger blocks might help sound stuttering
# but sound will also be more lagged.
# prebuffer -- How many milliseconds of data to keep on top of the blocksize.

nosound=false
rate=22050
blocksize=2048
prebuffer=10

[midi]
# mpu401 -- Enable MPU-401 Emulation.
# intelligent -- Operate in Intelligent mode.
# device -- Device that will receive the MIDI data from MPU-401.
# This can be default,alsa,oss,win32,coreaudio,none.
# config -- Special configuration options for the device.

mpu401=true
intelligent=true
device=default
config=

[sblaster]
# type -- Type of sblaster to emulate:none,sb1,sb2,sbpro1,sbpro2,sb16.
# base,irq,dma,hdma -- The IO/IRQ/DMA/High DMA address of the soundblaster.
# mixer -- Allow the soundblaster mixer to modify the dosbox mixer.
# oplmode -- Type of OPL emulation: auto,cms,opl2,dualopl2,opl3.
# On auto the mode is determined by sblaster type.
# oplrate -- Sample rate of OPL music emulation.

type=sb16
base=220
irq=7
dma=1
hdma=5
mixer=false
oplmode=auto
oplrate=22050

[gus]
# gus -- Enable the Gravis Ultrasound emulation.
# base,irq1,irq2,dma1,dma2 -- The IO/IRQ/DMA addresses of the
# Gravis Ultrasound. (Same IRQ's and DMA's are OK.)
# rate -- Sample rate of Ultrasound emulation.
# ultradir -- Path to Ultrasound directory. In this directory
# there should be a MIDI directory that contains
# the patch files for GUS playback. Patch sets used
# with Timidity should work fine.

gus=true
rate=22050
base=240
irq1=5
irq2=5
dma1=3
dma2=3
ultradir=C:\ULTRASND

[speaker]
# pcspeaker -- Enable PC-Speaker emulation.
# pcrate -- Sample rate of the PC-Speaker sound generation.
# tandyrate -- Sample rate of the Tandy 3-Voice generation.
# Tandysound emulation is present if machine is set to tandy.
# disney -- Enable Disney Sound Source emulation.

pcspeaker=true
pcrate=22050
tandyrate=22050
disney=true

[bios]
# Nothing to setup yet!


[dos]
# xms -- Enable XMS support.
# ems -- Enable EMS support.

xms=true
ems=true

[directserial]
# directserial -- Enable serial passthrough support.
# comport -- COM Port inside DOSBox.
# realport -- COM Port on the Host.
# defaultbps -- Default BPS.
# parity -- Parity of the packets. This can be N, E or O.
# bytesize -- Size of each packet. This can be 5 or 8.
# stopbit -- The number of stopbits. This can be 1 or 2.

directserial=false
comport=1
realport=COM1
defaultbps=1200
parity=N
bytesize=8
stopbit=1

[autoexec]
# Lines in this section will be run at startup.

[dragonmaster]

Also einfach die normale config durch die obengenannte config ersetzen und duke und oder descent1 mit den obengenannten Einstellung starten und schau wieviele cycles bei herumlaufen bei Duke bzw herumfliegen bei descent der pc durchschnittlich schafft.( müßen keine genauen Werte sein: auf 1000 gerundet)

Noch ein kleiner Tip wer Testen will aber kein Decent oder Duke hat dem kann ich sagen wo er es findet. ;D

Happy Benchmarking :D