Software Renderer (WinQuake-ish): Assembly Versus No

[Baker]

Resolution: 320x200

Commandline: -dibonly

Maxfps: Set to 999

Processor: 2.0 Ghz Dell from 2002


Non-assembly build maximum fps attained: 104 fps
Assembly build maximum fps attained: 572 fps (!)

Just wanted to test it. Yeah, assembly is relevant with the software renderer even today. I did a similar GL build test ... same FPS = irrelevant.

[leileilol]

well duh, they didn't hire Michael Abrash to cook up the asm for nothing. (check UT2004, his pixomatic software renderer there is his more recent work) It's all Pentium optimization, and it was controversial in 96-97 because the K5 and 6x86 didn't perform the same as the Pentiums despite being the same generation. They performed more closer to a 486 in Quake than the "better than Pentiums!! PEE ARE 200!!!" they were going for. Now, if Quake ever had MMX asm thrown in for the surfaces, things would get damn fast.

Assembly is always going to be faster that's a no brainer, but assembly is always CPU architecture specific, so don't expect it to be portable. Portability is all the rage these days, so you'll find a ton of advocates arguing against that.

Why don't you go to pouet, download a bunch of demos from 1992-1997 and just place your jaw on your desk so you don't break it from excessive dropping?

Makes me wonder, why hasn't a demoscener taken the Quake source and rewrite the renderer already... software quake needs reflective shiny toruses, credits scrollers, a decent 2d backend for the hud and menu that doesn't panic so easily, exploding menu graphics and specular shading and voxel water and lava surfaces and stencil shadows, with tracker soundtrack playback, and a random Deluxe Paint pixeled picture of a mythical creature for a loading screen with a colorful palette fade call. and a long list of greetz to a bunch of psuedonyms and groups that reside mostly in the Scandanavian regions of the world. and pack in some nfo files with bbs numbers on where to pick up the latest cracked warez. oh the cracktro too, even if quake doesn't need cracking. You gotta have a ghetto graffiti logo in everything too since you're so rebellious. While at it just inject the anarchy A in everything too, in blood because it's quake. and quakeguy's an anarchist, and shub should explode into a flag of Finland which turns to reveal Bill Gate's face which is then morphed and twirled to death because Quake is a big metaphor on how Microsoft is evil for Windows 95 because it doesn't allow coders to "directly tap into the hardware and make full use of it" like their precious DOS and that's why Windows 95 sucks and 3d cards are for lamerz who can't write a renderer or a raytracer and should be burned.

Ironically, the demoscene is all windows xp, dx9 dependant these days. So much for that "assembly defense" argument.

[Labman]

Doesn't some of the asm code use different algorithms to the C code?

[mh]

Well asm ain't necessarily always gonna be faster. Bad asm can perform much much worse than C code, and it doesn't have the benefit of an optimizing compiler to tune for a specific architecture and work out the fast paths (and today's optimizing compilers can be pretty damn good at that).

However the wildcard here is Abrash, who obviously knows what he's doing. So overall, yeah, good asm will always be faster, but it's a damn sight harder to do as well.

[Spike]

Baker, was that with full (profile guided) optimisations or 'lazy' optimisations?

Good asm may be faster, but its utterly unreadable, and takes longer to write, and is harder to debug too.

[frag.machine]

In the specific case of the Quake engine, I remember reading a long time ago how Abrash and Carmack abused of some undocumented features of the Intel FPU to move data faster than using asm. Interesting article, I'll try to find the URL to post here later.

[Ranger366]

Non-assembly build maximum fps attained: 104 fps
Assembly build maximum fps attained: 572 fps (!)

Amazing, how memory saving this is.

[leileilol]

Amazing, how memory saving this is.

No, you can't do this on your PSP. x86 assembly only.

[Downsider]

Amazing, how memory saving this is.

No, you can't do this on your PSP. x86 assembly only.

We've got hardware acceleration anyway.

[Baker]

Non-assembly build maximum fps attained: 104 fps
Assembly build maximum fps attained: 572 fps (!)

Amazing, how memory saving this is.

WinQuake is the version of Quake that doesn't use OpenGL so it has no 3D acceleration and looks very pixelated. So instead of using your video card, the renderer is literally part of the engine.

The PSP has hardware acceleration built in and [well written] assembly language code is generally faster but it never saves any memory.

There isn't new in this thread, the original WinQuake (and DOSQuake) always have used assembly language. However, I decided to test an assembly language using build versus a non-assembly language build just to see if the speed difference "mattered".

Baker, was that with full (profile guided) optimisations or 'lazy' optimisations?

I didn't use any special optimizations at all, I just simply did a normal build of my engine with the assembly and one using the C code.

If there some compiler option or something special I could be doing to make the C code version more optimized in the speed department, I'd like to know.

I wasn't expected such a speed disparity.

Code: Select all

/nologo /G5 /ML /GX /O2 /I ".\scitech\include" /I ".\dxsdk\sdk7\include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /FR".\Release/" /Fp".\Release/WinQuake.pch" /YX /Fo".\Release/" /Fd".\Release/" /FD /c

[Spike]

so lazy optimisations then :)
try whole program optimisations, and profile-guided optimisations. should help pure-c pathways a bit more