Shaving Ping

The article is way too biased for Intel chipsets and the Intel optimizing compiler. It doesn't focus on actually solving the problems in the code.

I have used the IOC several times in the past, and it is good -- when running on Intel chips. It is somewhat less good when running on the latest AMD chips. There is an AMD compiler for that. But an optimized bad algorithm is often worse than an unoptimized good algorithm.



Applying a good optimizing compiler won't compensate for bad design.



Choice of algorithms and actual implementation details are more important than the compiler optimizations. A well-optimized bubble sort will still be slower than a badly-compiled quicksort. Computing the optimal spanning tree is much slower than a simpler monte-carlo algorithm. A multi-pass convolution algorithm is much slower than a similar single pass algorithm. Discovering that a frequently called function is very slow when it should be very fast will enable you to pick a faster function.

Profile your code to find the actual problems. The article briefly mentions vtune, which is a fairly good profiler, but it certainly isn't the only good one. There are profilers such as AMD's CodeAnalyst, the .net profiler nprof, in-game profiling that you write yourself, the GNU profiler gprof, and countless others.

Get yourself a good profiler first, and solve the actual bottlenecks. Don't assume that an optimizing compiler will solve all your problems.

Quote:

Original post by frob The article is way too biased for Intel chipsets and the Intel optimizing compiler. It doesn't focus on actually solving the problems in the code. I have used the IOC several times in the past, and it is good -- when running on Intel chips. It is somewhat less good when running on the latest AMD chips. There is an AMD compiler for that. But an optimized bad algorithm is often worse than an unoptimized good algorithm. Applying a good optimizing compiler won't compensate for bad design. Choice of algorithms and actual implementation details are more important than the compiler optimizations. A well-optimized bubble sort will still be slower than a badly-compiled quicksort. Computing the optimal spanning tree is much slower than a simpler monte-carlo algorithm. A multi-pass convolution algorithm is much slower than a similar single pass algorithm. Discovering that a frequently called function is very slow when it should be very fast will enable you to pick a faster function. Profile your code to find the actual problems. The article briefly mentions vtune, which is a fairly good profiler, but it certainly isn't the only good one. There are profilers such as AMD's CodeAnalyst, the .net profiler nprof, in-game profiling that you write yourself, the GNU profiler gprof, and countless others. Get yourself a good profiler first, and solve the actual bottlenecks. Don't assume that an optimizing compiler will solve all your problems.

While all of this is true, you're commenting is geared towards the initial development. The article is more geared towards post-morten quick optimization for the specific platform the hosting company is using. These people do not want to rewrite algorithms, they want to get a quick speed boost. Which can apparently be achieved by using another compiler (or at least other compile options).

Quote:

Original post by rick_appleton These people do not want to rewrite algorithms, they want to get a quick speed boost. Which can apparently be achieved by using another compiler (or at least other compile options).

I wonder why the original devs wouldn't have compiled their code with -O2? Under most development systems that would automatically be enabled for a release build, and quite frankly, any developer working on a major software product should know how to use his/her compiler properly.

You should really be comparing a commercial game as released to various self compiled ones. The devs will have made their baby as fast as possible on a wide range of hardware. Sure, it's probably possible to get it faster on your system (and slower on others) but you havn't actually shown that.

Quote:

Original post by swiftcoder Quote: Original post by rick_appleton These people do not want to rewrite algorithms, they want to get a quick speed boost. Which can apparently be achieved by using another compiler (or at least other compile options). I wonder why the original devs wouldn't have compiled their code with -O2? Under most development systems that would automatically be enabled for a release build, and quite frankly, any developer working on a major software product should know how to use his/her compiler properly.

I was referring to compiling the code to take advantage of a single platform, ie. the one the host will be running. The original developers can't do that, since it needs to run best an all platforms.

Quote:

Original post by rick_appleton Quote: Original post by swiftcoder Quote: Original post by rick_appleton These people do not want to rewrite algorithms, they want to get a quick speed boost. Which can apparently be achieved by using another compiler (or at least other compile options). I wonder why the original devs wouldn't have compiled their code with -O2? Under most development systems that would automatically be enabled for a release build, and quite frankly, any developer working on a major software product should know how to use his/her compiler properly. I was referring to compiling the code to take advantage of a single platform, ie. the one the host will be running. The original developers can't do that, since it needs to run best an all platforms.

Since C executables can't typically run on multiple platforms, they are usually compiled separately for each platform with whatever compiler and settings provides the best performance.

For instance, my projects are compiled under GCC 4 under Mac OS X, because this is the best free compiler there, and under Microsoft's Compilers on Windows, because they are the best free compilers I have found there.
Obviously, before I released a commercial app for either platform I would get every available compiler for each platform and run performance stress testing.

Quote:

Doug Helbling is a software engineer for Intel's software development product deployment team. He works to develop Linux product delivery solutions, various game mods and case studies. His latest project includes an optimization study of GarageGames' Torgue engine.

I'd like to know more about the results of the Torque study...

I'd also be interested in knowing why they didn't use gcc -O3 and the -march tuning flags, particularly when they seemed to make a difference for the intel compiler, as well as trying on an AMD processor, seems like that'd be a more informative and balanced test.

I know the author works for Intel, but as it stands this article doesn't actually suggest anything novel other than basic flags you can pass ICC, and doesn't even compare them to GCC. Booo.