Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

[geek] Windows Console App vs. DOS 32-bit app

GeckoFood (585211) writes | more than 3 years ago

User Journal 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.

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.

cancel ×

8 comments

The problem is WIndows, not the DOS extender (1)

morgan_greywolf (835522) | more than 3 years ago | (#34729780)

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:The problem is WIndows, not the DOS extender (1)

jawtheshark (198669) | more than 3 years ago | (#34729892)

He might also try on DOSBox... Just out of pure curiosity.

Re:The problem is WIndows, not the DOS extender (1)

morgan_greywolf (835522) | more than 3 years ago | (#34730688)

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 I don't really know for sure.

Re:The problem is WIndows, not the DOS extender (1)

jawtheshark (198669) | more than 3 years ago | (#34730872)

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:The problem is WIndows, not the DOS extender (1)

morgan_greywolf (835522) | more than 3 years ago | (#34730906)

Yeah, that reply was entirely stream of consciousness, just brain dumping what I know in case it helps. :)

Re:The problem is WIndows, not the DOS extender (2)

GeckoFood (585211) | more than 3 years ago | (#34732570)

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? (1)

Short Circuit (52384) | more than 3 years ago | (#34730086)

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:Have you tried Windows Console 64-bit? (1)

GeckoFood (585211) | more than 3 years ago | (#34730894)

Have you tried Windows console 64-bit? (Assuming you're running a 64-bit version of Windows)

Hardware is 32-bit so I can't even upgrade to Win64 - so, unfortunately, 64-bit console apps are not an option for now.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...