View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Fri Jun 25, 2010 3:36 pm Post subject: Software Renderer (WinQuake-ish): Assembly Versus No |
|
|
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. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Sat Jun 26, 2010 12:07 am Post subject: |
|
|
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. _________________
 |
|
Back to top |
|
 |
Labman
Joined: 05 Nov 2004 Posts: 51 Location: Brisbane, Australia
|
Posted: Mon Jun 28, 2010 9:23 am Post subject: |
|
|
Doesn't some of the asm code use different algorithms to the C code? |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Mon Jun 28, 2010 10:43 am Post subject: |
|
|
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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Jun 28, 2010 11:40 am Post subject: |
|
|
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. _________________ What's a signature? |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Mon Jun 28, 2010 1:34 pm Post subject: |
|
|
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. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Ranger366

Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany)
|
Posted: Mon Jun 28, 2010 3:21 pm Post subject: Re: Software Renderer (WinQuake-ish): Assembly Versus No |
|
|
Baker wrote: |
Non-assembly build maximum fps attained: 104 fps
Assembly build maximum fps attained: 572 fps (!) |
Amazing, how memory saving this is. _________________
 |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Mon Jun 28, 2010 8:18 pm Post subject: Re: Software Renderer (WinQuake-ish): Assembly Versus No |
|
|
Ranger366 wrote: | Amazing, how memory saving this is. |
No, you can't do this on your PSP. x86 assembly only. _________________
 |
|
Back to top |
|
 |
Downsider

Joined: 16 Sep 2008 Posts: 478
|
Posted: Tue Jun 29, 2010 3:41 am Post subject: Re: Software Renderer (WinQuake-ish): Assembly Versus No |
|
|
leileilol wrote: | Ranger366 wrote: | Amazing, how memory saving this is. |
No, you can't do this on your PSP. x86 assembly only. |
We've got hardware acceleration anyway. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jun 29, 2010 4:24 am Post subject: |
|
|
Ranger366 wrote: | Baker wrote: |
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".
Spike wrote: | 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: | /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 |
_________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Jun 29, 2010 9:21 am Post subject: |
|
|
so lazy optimisations then :)
try whole program optimisations, and profile-guided optimisations. should help pure-c pathways a bit more _________________ What's a signature? |
|
Back to top |
|
 |
|