Source Ports and the Intel Compiler

I was wondering, how much would whichever port you're developing benefit from an Intel compiler?

Here's something interesting. A few years ago I had the opportunity to get close to an arcade cabinet built from scratch by a coworker from whom I had received an invitation for a small party that took place in his "pinball room" It featured a 600-something mhz P3 CPU and if I recall correctly, 256mb of ram. It was running a long-discontinued third-party variant of DOS MAME called "FastMAME" allegedly built with an Intel compiler. Point to all this? it could run a game called "Mortal Kombat 2" at full speed (piece of crap game anyways) but according to him, the regular MAME build (exact same version) couldn't handle it nearly as well, as I later confirmed.

Around the same time, I was handed a source code for DosBox which had been converted for use with Intel compilers. I managed to compile this thing applying some aggressive optimizations and I couldn't be any more amazed with the results. I benchmarked both the official build and my custom Intel build, and the later performed nearly 50% faster on my computer, no kidding (that's either horrendous code or kickarse compiler)

I also remember prBoom becoming about 19% faster at some point, and I believe an Intel compiler had something to do with it.

Last year I attempted to build Chocolate Doom with the Intel compiler and it worked right away, no modifications were needed, but the maps that would normally bring limitless ports to a crawl are supposed to crash this port so it's not that you can benchmark any potential improvement here.

Finally, I tried luck with (G)ZDoom but to no avail. Too many errors. Nailed like half of them, but I'm not a programmer and I gave up, though I don't think it would have helped much, if at all. This port seems to be very well optimized already, and someone told me that adding optimizations where not needed can sometimes be counterproductive.

PrBoom-Plus releases compiled with Intel Compiler (/O3 or /Ox) + /IPO + PGO. It's about 10%-15% faster than MSVC build. You can test it himself, both versions are included.

params: -geom 640x480 -window -nosound -file epic.wad -timedemo epic.lmp -config testp.cfg

glboom-plus: 220 fps
glboom-plus_safe: 190 fps

prboom-plus: 164 fps
prboom-plus_safe: 145 fps

ICC has a reputation for producing code that (intentionally or not) runs badly on AMD chips and, in some cases, is just broken.

I think LLVM would be a more interesting experiment.

Also Intel Compiler has no problems with PGO in comparison with MSVC. At least for prboom-plus. MSVC compiler produces EXE which desynches on demos or even crashes.

btw, GCC can't generate executable correctly even with -O3 sometimes.

Yeah, Intel C++ and Fortran compilers have a good reputation in some fields (mainly number crunching) but are pretty much balanced on general computing.

FastMAME vs MAME is another issue as well: the main MAME branch was never about speed (it was always the slowest emulator around) and newer versions get slower and slower due to their aim for high accuracy, rather than speed. To this day, it's still a bannable offense to complain about MAME's speed on its official forums. FastMAME is a special branch that replaces certain parts of the code with faster analogues etc. at the expense of compatibility and keeping up with more recent drivers/newly added games.

entryway said:

btw, GCC can't generate executable correctly even with -O3 sometimes.

I can second that. Can't tell you how many times I've had to warn Linux users not to go overboard on the optimization options. Stack corruption is often the tale-tell result when gcc hits such a compiler bug.

Quasar said:

I can second that. Can't tell you how many times I've had to warn Linux users not to go overboard on the optimization options. Stack corruption is often the tale-tell result when gcc hits such a compiler bug.

They even have defined some structures incorrectly. IMAGE_NT_HEADERS64 as example.

You infidels, how dare you pick on GCC? Richard "RMS" Stalman will have yo closed-source corporate ass!!!

Heh, makes you wonder how that piece of shit still manages to live with himself.

david_a said:

I think LLVM would be a more interesting experiment.

I tried that with the gcc frontend, the results when testing with -timedemo were almost identical to vanilla gcc, very very slightly slower (~1-2%)

That was about a year ago, it has probably improved since then.

fraggle said:

I tried that with the gcc frontend, the results when testing with -timedemo were almost identical to vanilla gcc, very very slightly slower (~1-2%)

That was about a year ago, it has probably improved since then.

I would suggest Clang instead of the GCC frontend. Also, try playing around with Link-Time Optimization :P