Porsche Monty Posted June 14, 2010 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. 0 Share this post Link to post
entryway Posted June 14, 2010 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 0 Share this post Link to post
david_a Posted June 14, 2010 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. 0 Share this post Link to post
entryway Posted June 14, 2010 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. 0 Share this post Link to post
Maes Posted June 14, 2010 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. 0 Share this post Link to post
Quasar Posted June 15, 2010 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. 0 Share this post Link to post
entryway Posted June 15, 2010 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. 0 Share this post Link to post
Maes Posted June 15, 2010 You infidels, how dare you pick on GCC? Richard "RMS" Stalman will have yo closed-source corporate ass!!! 0 Share this post Link to post
Porsche Monty Posted June 15, 2010 Heh, makes you wonder how that piece of shit still manages to live with himself. 0 Share this post Link to post
fraggle Posted June 15, 2010 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. 0 Share this post Link to post
MP2E Posted June 15, 2010 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 0 Share this post Link to post