View Full Version : Compiler switches for speed
mg262
21st August 2005, 16:10
So the plug-in I'm working on is not easily amenable to SIMD optimisation, which means that for the first time I have tried to fiddle with the VC 2003 compiler switches to speed up the code.
I've tried switching on global optimisations, in-line expansion of any suitable function, omit frame pointers, optimised for speed and optimise for P4... and if anything it slowed down slightly. (I've also tried a number of variants on these.) Does anyone have any recommendations?
IanB
23rd August 2005, 16:12
Rewrite the inner loop in assembler, think hard how to keep all the ALU paths busy.
Or use the Intel P4 compiler.
Guest
23rd August 2005, 16:28
Perform algorithmic optimization. :)
mg262
23rd August 2005, 16:35
Rewrite the inner loop in assembler, think hard how to keep all the ALU paths busy.Back when I first played with assembly, on a 486 or Pentium, I remember that just moving things into assembly typically gave a three-times speed up -- but these days compilers seem to be much better...
Or use the Intel P4 compiler.Will that screw things up for users with AMD units?
Perform algorithmic optimization.Been there, done that! There's a few more changes to make on that front, but not many.
I think the way forward may be to look at GPU stuff (which would involve buying a GPU...) Anyway, thanks for the thoughts!
MfA
23rd August 2005, 19:19
If you can do it on the GPU it can probably be done with SIMD ... GPUs are pretty limited. Biggest help on any algorithm these days tends to be to make sure you are working from cache if at all possible.
IanB
25th August 2005, 04:59
Back when I first played with assembly, on a 486 or Pentium, I remember that just moving things into assembly typically gave a three-times speed up -- but these days compilers seem to be much better...As I said "think hard how to keep all the ALU paths busy"
Yes the compiler (particularly the intel one) approximatly knows how to keep all the ALU paths busy. So start with the ASM listing from the compiler. Teach the code to track register correctly, neither compiler does even close to a reasonable job here. Make appropriate use of ah/al and ax style registers the compilers always want to movsx/movzx. Organize your algorithm to access memory aligned with cache lines (64byte aligned) if possible. One trick if you have enough registers, is to do your loops 2 at a time and interleve loop1 and loop2 code. Remember there is only 1 memory access cpu path so you may need to slip one of the loops around relative to the other to avoid lock stepping both loops. i.e. a1
a2
loop:
b1
a3
b2
a4
b3
a1
b4
a2
jmp loop[Intel compiler] Will that screw things up for users with AMD units?Possibly, depends on what you are doing, for normal algebraic/logical code the coding rules are quite similar. As a base for hand optimized ASM it won't matter (coz you will fix it, right).
IanB
mg262
25th August 2005, 08:28
Thank you!
mg262
31st August 2005, 11:19
On this thread (http://videoprocessing.11.forumer.com/viewtopic.php?p=310&sid=0c730183f062e28e72fc9d7afc37a65e#310) on kassandro's forum I had my attention drawn to this article
Suit: Intel Sabotaged Compiler for AMD (http://www.betanews.com/article/Suit_Intel_Sabotaged_Compiler_for_AMD/1121274628)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.