prboom+ timedemo performance slightly below my expectation

[noshutdown]

my computer is core2duo e8400 oc 3.6g and geforce gts250. yeah its a bit old for today but at least its equivalent to 2009's spec. and i run prboom+ with 8 bit software renderer, fullscreen 640*480 resolution(the lowest i can choose on this machine, probably related to videocard driver). i run timedemo with -nosound.

and when i ran timedemo speed of doom map30 nightmare speed for benchmark, it scored only 228fps. surely this score is still well beyond playable, but considering that doom was such an old game that could be run on 386 machines, i feel that the result is a bit below my expectation.

[BaronOfStuff]

Don't worry, you'll get over it.

[RUSH]

The struggle is real.

[mdmenzel]

...at least you didn't get sent to Post Hell :)

[VGA]

Should have been at least 245fps, this sucks :-(

[ReFracture]

I think you're overestimating the power of a 386. It barely ran Doom at a playable framerate at low detail, and Speed of Doom map30 is far more demanding than anything any of the vanilla iwad maps were.

Also my PC gets over 1100 fps in that timedemo :P

[scifista42]

I wish I could play modern 3D games with a stable framerate at least 25 fps on my computer, but I can't, practically any of them. :(

Nevermind, I'm happy enough with my smooth-playing and fun Doom wads. :)

[noshutdown]

ReFracture said:

I think you're overestimating the power of a 386. It barely ran Doom at a playable framerate at low detail, and Speed of Doom map30 is far more demanding than anything any of the vanilla iwad maps were.

Also my PC gets over 1100 fps in that timedemo :P

thats awesome, your computer must be over 4 times as fast as mine. is it a core i7?

[Maes]

I once had made a half-assed calculation according to which, vanilla doom.exe required about 32 CPU cycles/pixel on a 486 (made easy by the fact that a 486 had an ipc (instruction per clock) efficiency of about 1), assuming 64000 pixels per frame and 20 fps.

For 640*480, that's more than 4 times the pixels per frame (more like 5 times, actually) and 244 fps? Luxury :-D

That's like a 486 running at 2.6 GHz, not counting other factors, of course, like the possibly very different "IPC per pixel" efficiency of source ports vs vanilla Doom (probably higher number, so lower efficiency).

Interestingly, that 32 cycles/pixel performance was similar to what I had obtained in Mocha Doom when timedemoed at 320x200 on a Pentium 4.

[Sp00kyFox]

ReFracture said:

Also my PC gets over 1100 fps in that timedemo :P

with the same resolution as OP? that's impressive! and I thought I had a fairly recent CPU. I'm getting 470fps on this demo.

[driftyloon]

Sp00kyFox said:

I thought I had a fairly recent CPU. I'm getting 470fps on this demo.

I am getting there abouts, 450 actually but meh. My CPU is like 8 years old but it was a very good one for its time. It is a AMD Phenom 2 X6 1035. The CPU is not the problem with my computer, its the GPU which is a nvidia GT 430 -_- This is why I can't graphically beautiful games.

[ReFracture]

Sp00kyFox said:

with the same resolution as OP? that's impressive! and I thought I had a fairly recent CPU. I'm getting 470fps on this demo.

Confession: I left it in OpenGL mode at 640x480, my GTX 670 did a lot of the work.

532 fps in 8-bit mode with 640x480 -nosound.

noshutdown said:

thats awesome, your computer must be over 4 times as fast as mine. is it a core i7?

I run an i7 3770k @ 4.1ghz.

[Sp00kyFox]

does prboom-plus (or source ports in general for that matter) even take advantage of multicore cpus? judging from the responses here the pure clockrate alone is determing the performance but the number of cores seems irrelevant.

ps: I have a Xeon E3-1230v3 which is 3.3GHz x 4.

[Maes]

About the only thing that can be parallelized easily enough is the renderer (w/o BSP traversals, just the part that writes pixels to the screen), which on super-complex maps doesn't even account for the biggest part of the spent CPU time.

Even with an infinitely parallelizable renderer that runs in zero time, maps such as NUTS.WAD or stuff with very complex BSP trees would still be bottlenecked, with a maximum theoretical speedup of no more than 50%.

The actual game code/monster logic cannot be parallelized without losing determinacy/causality (and thus demo compatibility). Other than the renderer, the only other thing that MIGHT be parallelizable without other side effects is the BSP renderer (e.g. starting a thread for every main branch), which might give a few %.

[driftyloon]

BTW

I run on 1920x1080. At 640x480 I get 1000-1200 fps