Journal GeckoFood's Journal: [geek] Windows Console App vs. DOS 32-bit app 8
Ok, not the most glamorous topic to kick off the new year but you get what you pay for. This is the first JE I have posted in several months, not because of ill will or dissatisfaction here, but simply because I do not have the time I once had to post.
Anyway... I decided to conduct a small experiment with one of my C++ compilers. I have a 32-bit application that has a benchmark test embedded in it and I have been recompiling the app over and over to isolate the optimal set of parameters for the compiler and linker to get the best performance. So far I have found that compiling for the i686 chipset with full compiler-provided optimization and stdcall linkage yields the very best performance. I am not sure why stdcall is best, to be honest, but that stems from my ignorance on the different linkage strategies. Also, the performance gain with stdcall is not large but it's noticeable. Once I got the application tuned as tightly as I could with the compile, I got curious - how would a DOS32 app compare against a Windows console application?
In a nutshell, the DOS32 application performed dreadfully. Where the Windows console application benchmarked around 1550 ms on average, the DOS32 application benchmarked just over 2000 ms. I assume this is a penalty relating to the translation layer of the DOS extender.
The problem is WIndows, not the DOS extender (Score:1)
Windows has to do backflips to get DOS extender apps to run. Try the DOS32 application on actual DOS [freedos.org] and you'll find the performance is very, very different.
Re: (Score:1)
He might also try on DOSBox... Just out of pure curiosity.
Re: (Score:1)
I don't know really know enough about how DOSBox works to really say if it would be faster or not. It seems like DOSEmu runs a real DOS, while DOSBox has some internal thing that acts enough like DOS to get by. I think DOSBox is a full-blown x86 emulator, while DOSEmu actually needs an x86 CPU. I suspect that since DOS gamers report that DOSBox works rather better for DOS games, and given that most of the later DOS games make use of DOS extender, that the DOS32 program might be faster under DOSBox, but
Re: (Score:1)
Neither do I. I was just suggesting he'd try it to see. Of course, the correct way is to go FreeDOS (which is excellent, yes, I tried)
Re: (Score:1)
Yeah, that reply was entirely stream of consciousness, just brain dumping what I know in case it helps. :)
Re: (Score:3)
Eh, this was just an exercise in curiosity with a dose of insomnia tossed in there for good measure. To be honest I do not think JtS's suggestion of using DOSBox will improve matters but there's little to lose by trying. At a minimum I will come away knowing more than I did when I started.
Of course, I could just compile it under Linux with gcc and watch it fly, but that's a different exercise.
Have you tried Windows Console 64-bit? (Score:2)
Have you tried Windows console 64-bit? (Assuming you're running a 64-bit version of Windows)
If you do, you should also try __fastcall. fastcall puts your function arguments in registers, whereas stdcall puts them on the stack. While fastcall doesn't help much in 32-bit x86, it should help a lot more in x86_64; AMD64 doubled the number of named GPRs.
Docs for the calling convention stuff here [microsoft.com].
Re: (Score:2)
Hardware is 32-bit so I can't even upgrade to Win64 - so, unfortunately, 64-bit console apps are not an option for now.