IMO the biggest trap with optimizing is that often most of the time is NOT spent where you think it is spent. Profiling (we have a nice /PROFILE boot switch) helps to determine what you actually want to optimize. Just replacing random pieces of C code with asm is not what you (or rather, I <g>) want to do.
You're quite right. This is, in fact, one of the most troubling problems with optimiziation; most of the time you're just optimizing the wrong code!
And I agree, replacing random pieces of C code with asm is not very attractive either.
I really want optimized code. I've been wanting to write asm replacements for functions for a long time now, but I have very little spare time. I've brought the issue up so much that I'll have to write it eventually, even if only out of not losing face
.
I hope you arent referring to me
Not necessarily. I just mean people who don't realize the significance of assembly optimization.
Somehow Lots of developers wrongly believe that good C code can replace asm code. Nothing could be further from the truth (especially with a general purpose compiler like MinGW). In my experience (i'm not guessing; this is experience) even the poorest asm code can outrun the best-written C code easily.
Another thing which you might not be aware of is that in windows in kernel mode (and probably any other modern OS) you cannot simply use the FPU/MMX/SSE opcodes - you have to save the FPU/MMX/SSE state before using it and restore it afterwards which could produce so much overhead that the MMX optimizations become useless.
AFAIK, that's only true with MMX (because of conflicts with the FPU). I don't think that's needed with SSE; I believe the processor saves the SSE state automatically.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.