Optimization to increase speed

[BetaTester]

Programing Optimization to increase speed software (compression/decompression)

http://www.agner.org/optimize/optimizing_cpp.pdf

http://www.agner.org/optimize/optimizing_assembly.pdf

http://www.agner.org/optimize/instruction_tables.pdf

http://www.agner.org/optimize/calling_conventions.pdf

[Intrinsic]

Yep we are well aware of agner for a long time now it's a very handy resource.

[Piotr Tarsa]

Too bad he hasn't covered AMD Bulldozer and AMD Piledriver yet.

[thorfdbg]

Thanks for the links, I was just browsing through the C++/C optimization manual and I have to say that I disagree on the choice of the compiler for windows. I've been in image compression for years, and despite what the GNU people say, the gcc/g++ compiler performs rather poorly on the windows platform (and also on the Linux platform) as far as the optimizations are concerned. I'm very much a fan of Linux and the GNU toolchain, but the optimizer is not worth much. It has a nice list of very high-level optimization methods, but the low-level code generator stinks. In all what I've done so far, VS outperforms GNU by quite a bit. Interestingly, the latter VS versions are getting worse and worse - VS 6.0 was a very lousy compiler as far as the C++ compliance was concerned, and it also happened that it optimized your code into trash (so you always had to check), but the overall code quality was better than what I get from VS 2010. VS2005(8.0) was again worse than VS2003 (7.1). I see quite an improvement in VS as far as C++ compliance is concerned, but the code generator quality is declining - probably because it doesn't matter that much anymore for most applications.

[Piotr Tarsa]

Which version of GCC you tested?

I haven't compared the compilers myself, but from what I can find on Internet, GCC is pretty stable and performant contender.
http://www.phoronix.com/scan.php?pag...idge_compilers
http://bvector.blogspot.com/2009/08/...vc-vs-gcc.html

[thorfdbg]

Which version of GCC you tested? I haven't compared the compilers myself, but from what I can find on Internet, GCC is pretty stable and performant contender. http://www.phoronix.com/scan.php?pag...idge_compilers http://bvector.blogspot.com/2009/08/...vc-vs-gcc.html

VS 2010 and gcc 4.4. I don't have any newer gcc's available right now. Besides, now that I continue reading the guide, it also contains false information:

The volatile keyword specifies that a variable can be changed by another thread.

Sorry, but that's just wrong. volatile is neither necessary nor sufficient for thread-safe access. For some architectures and some compilers you can get away with it, but that's the best that can be said. In general, access to a variable, regardless of volatile or not, is not guaranteed to be atomic, and you might also need a memory barrier to ensure that you read the correct value. C++11 has the necessary primitives, and POSIX mutexes and semaphores also include a memory barrier, but just putting volatile somewhere is just wishful thinking. The example will, for example, not work on ARM (a barrier is missing). Also, integer sizes are not guaranteed as listed in the document. One certainly has char < short

[Piotr Tarsa]

Which guide you're referring to?

As to volatile: I don't know exactly but volatile prevents caching of variable value in register, ie every time a variable is referenced in the source code, it is freshly fetched from memory (through cache or not). This way we always have fresh value of a variable at reference point. Particularly, double-checked locking would not work without volatile variables: http://en.wikipedia.org/wiki/Singlet...initialization

[thorfdbg]

As to volatile: I don't know exactly but volatile prevents caching of variable value in register, ie every time a variable is referenced in the source code, it is freshly fetched from memory (through cache or not). This way we always have fresh value of a variable at reference point. Particularly, double-checked locking would not work without volatile variables: http://en.wikipedia.org/wiki/Singlet...initialization

I'm referring to the C/C++ optimization guide. Not keeping variables in registers helps you nothing on multicore processors where threads are run on several cores at once. A statement like foobar += inc; is not threadsafe a) because it might, depending on the compiler, include a read and a write and any other thread in between might access "foobar", and b) it does not include a memory barrier, i.e. even *if* foobar is read and written to correctly by the CPU running in the current thread, it does not mean that this changed value is also visible by another core relative to its memory order. Even a foobar = 1; might still not have the desired effect on a second (or any other) core since the change might simply happen at a time where "you don't expect it" because memory accesses are reordered, or it might trigger more than one write such that atomicity (even of this simple expression!) is not ensured. As said, for that you need a memory barrier. x86 usually does not require such barriers since the cores snoop the accesses within the same die, but if you try the same on ARM, for example, you'll be surprised what would go wrong... Otherwise, go to comp.lang.c++.moderated and ask the experts there if you don't believe me. As said, volatile is neither sufficient nor necessary for the job.

[m^2]

Thanks for the links, I was just browsing through the C++/C optimization manual and I have to say that I disagree on the choice of the compiler for windows. I've been in image compression for years, and despite what the GNU people say, the gcc/g++ compiler performs rather poorly on the windows platform (and also on the Linux platform) as far as the optimizations are concerned. I'm very much a fan of Linux and the GNU toolchain, but the optimizer is not worth much. It has a nice list of very high-level optimization methods, but the low-level code generator stinks. In all what I've done so far, VS outperforms GNU by quite a bit. Interestingly, the latter VS versions are getting worse and worse - VS 6.0 was a very lousy compiler as far as the C++ compliance was concerned, and it also happened that it optimized your code into trash (so you always had to check), but the overall code quality was better than what I get from VS 2010. VS2005(8.0) was again worse than VS2003 (7.1). I see quite an improvement in VS as far as C++ compliance is concerned, but the code generator quality is declining - probably because it doesn't matter that much anymore for most applications.

I did a comparison of gcc 4.5.2 or 4.6.2 (don't remember) with MSVC8 on compression code and found that the results were shifting both ways, overall they were on par.