Attached is DOSBox 0.74/SVN and SDL.dll compiled by the Intel C++ compiler and optimized for speed/floating point precision.

I compiled versions of DOSBox 0.74/SVN by three different compilers: Intel C++ 10.x, MS Visual C++ 2008, and GCC 4.6.x (MinGW). In all these versions, they were optimized for speed (/O2) and SSE2 (where available). They all performed the same in PCPBench, between 48 and 49 frames per second in a low-end Core2Duo system. This suggested that either the optimizations were having no effect or that the compilers were equally advanced. I ruled out the first suggestion by compiling a binary with no optimizations and finding ~15% loss in fps in PCPBench. So, I believe that these compilers work equally well, or nearly so, with the DOSBox code.

However, the Intel C++ compiler is known for advanced optimizations. Enabling options such as /O3 or /fast did not improve the speed in the above benchmark. I then enabled /O2 and increased precision in floating point math. There have been posts that suggest this reduces audio noise under certain conditions. The attached SVN build was compiled with these settings. Also, the SDL.dll (1.2.15) was compiled using the same optimizations.

Although the artificial benchmark shows no difference among the compiled versions, the attached build seemed to run more smoothly in DOS games. If this Intel-compiled SVN build is of interest, please compare the video framerate and audio quality between it and the other compiled builds.

I have new results. Instead of measuring which compiled version is faster by PCPBench, this time I used Dhrystone 1 and 2 (unoptimized) speed tests. From the documentation, these tests measure CPU speed under a set of conditions while PCPBench also employs video.

Using the Dhrystone tests, both Intel and Visual C++ compiled DOSBox versions consistently had a "VAX MIPS rating" between 55 and 57. However, the MinGW compiled version (gcc 4.6.x) consistently had a rating between 60 and 63. This is about a 10% difference. This supports using the MinGW compiler for the win32 version of DOSBox.

I also compiled the SDL.dll files by these same three compilers. However, these different dll files had no obvious effect on the above benchmark tests.

Compile it with Visual C++ 2010...

I don't know if this directly related to your sample builds, but your build of DOSBox and SDL.DLL seems to avoid a problem I've seen in other builds. In other Windows builds (and in my OS X project) if I use keystrokes to switch an application between text and graphic modes, the last keystroke gets repeated after the mode switch. In other words, in WordPerfect 6.2, if I use Ctrl-F3, then G to switch to graphics mode, the program switches to graphics mode and then types a few dozen "G" characters. This doesn't happen with your build.

I downloaded an eval copy of the Intel compiler and installed it - it integrated into Visual Studio 2010, chose "use Intel C++" from the Project menu, and compiled. The resulting exe was much larger than with plain Visual C++ (3.6 MB with Intel, 2.5 with MS), and I have no way of knowing whether this build is faster or slower than with Visual C++. But if - if - the problem with characters repeating after mode-switching got solved by using Intel, then I'm very grateful to you.

(Now to try to figure out how to do this under OS X....)

emendelson wrote:

if I use keystrokes to switch an application between text and graphic modes, the last keystroke gets repeated after the mode switch.

Have you tried to write these two lines in a batch file: SDL_VIDEODRIVER=windib & dosbox.exe?

Also, it may be the SDL library compile, have you tried the other versions I posted on other threads? Some are compiled by mingw and others by VS. Perhaps pair the Intel compiled SDL.dll with the other versions of dosbox, too.

I don't think the difference is drastic, the 10% advantage of MinGW in one CPU speed test. The advantage was much less in real world games. However, I noted it because the dosbox code is different among compilers and I recall "wd" suggesting that VS is not compiling it as expected (a problem). Moreover, the gcc 4.6 version used is not current (4.8 is). However, I've not seen a difference in speed among VS2008 and 2010. In fact, I haven't found an optimization, beyond /O2, which makes an obvious difference in any of the compilers or benchmarks.

The main attraction of the Intel compiler, at least for us, is its floating-point math library and sophisticated optimizations. I wonder whether the MUNT project would benefit from that library, although it may be mainly integer math. Intel's compiler also provides a control for identifying compiler-related bugs. I have seen these occur, as may also have occurred in your case.

At the moment, I've got the problem of keystrokes repeating only under OS X, but I'll experiment with other versions of DOSBox and report any interesting results.

I spent some more time with the 30-day eval of the Intel compiler for OS X, but it's completely beyond my abilities. Meanwhile, thank you again for experimenting with this.

Thank you. I think the compiler optimizations (and the Intel math library) may have a larger effect on the Voodoo1 emulation since it is dependent on many mathematical calculations (and possibly the 3rd party audio drivers).

I'd like to eventually try a newer version of gcc with the existing MinGW libraries and headers, if possible. The newest headers were causing errors on compiling dosbox. I suspect the code has already been optimized so that the advanced compiler optimizations do no better.