"Optimizing" Compiler

[jj2007]

Neil,
With that level of confusion, wouldn't it be an option to put the critical parts into an OS-specific dll? Or into *obj files that you assemble separately every now and then?

[dedndave]

...or write .6..5 assemblers that all use the same syntax   :lol
(you can use one that already exists as "master")

[Slugsnack]

here is a simple and fun little exercise   :P
this appears to be some type of "assignment" code (guessing)
try writing the same assignments inside a loop
for the iteration count, use a variable
assign that variable a value of 1 (single loop pass)
then, disassemble it and see if they optimized it differently because it's inside a loop   :U
you could even take the next step and put it in a function as well

this may change the way you write compiled code entirely - lol
maybe you could write a paper and get published !! (Forcing Compiler Optimization)
i will happily take 10% of any profits you might make   :bg

that is harder. if what you mean is to say doing something like :

Code Select Expand

for( int i = 0; i < 5; i++ )
  x = i;

and you want to make it just do x = 5 instead. well that is tricky for a compiler to do. however having something like this :

Code Select Expand

for( int i = 0; i < 5; i++ ) {
  ...................
  x = 5;
}

would be entirely different and easily optimised. it is known as loop invariant code motion. you hoist out all invariants. this is really easy for a compiler to change. it can just check livein/liveouts at a given point. i wrote a compiler a few months ago and i wanted to implement the first case too. and sort of decided it was too much work :-P

[dedndave]

writing a compiler - big undertaking, Mike - way over my head, i am sure - lol
but, i think you highlight a point i was trying to make...

... and i wanted to implement the first case too. and sort of decided it was too much work

and, it probably wouldn't have helped make a better executable very often
guys that write these things (including you  :bg ) tend to focus their efforts toward things that make better EXE's, and more often

i am still trying to think of an easy way to help Neil get through 6 versions of code...
... maybe write a program that generates the alternate modified source files from a single input file ???

[KeepingRealBusy]

Dave,

i am still trying to think of an easy way to help Neil get through 6 versions of code...
... maybe write a program that generates the alternate modified source files from a single input file ???

Macros come to mind.

Dave.

[jj2007]

i am still trying to think of an easy way to help Neil get through 6 versions of code...
... maybe write a program that generates the alternate modified source files from a single input file ???

Macros come to mind.

Dave.

Right, especially if combined with conditional assembly

Code Select Expand

if OS eq Win32
   ...
elseif if OS eq Linux
   ...
elseif if OS eq Mac
   ...
else
   .err <no such OS, sorry>
endif

[Neo]

Macros alone work, unless you have macros for generating object files in ELF (for Linux) or MachO (for Mac) formats, since Windows OBJ files are in a variant of PE format, and the Linux and Mac assemblers have a completely different syntax for conditionally including/excluding pieces of code.  That counts out the two ideas along those lines I'd looked into a few months ago.  :(

[BogdanOntanu]

Solar Assembler works on Windows, Linux/Unix and MacOSX and it has the same syntax for all platforms including #ifdef #endif.

The idea is that you should use an assembler that works and has the same syntax on all target platforms. If you do not like my assembler then you could try NASM or FASM.

Warn: Solar Assembler still has some bugs and it is in alpha stages but I usually fix those fast if asked nicely :))

About your compiler optimization issue: we can not decide unless we see the source code. You might use #pragms's or intrinsic in such a way as to effectively disable compiler optimizations.

Compilers are dumb conceptually because they have no clue about algorithms ... BUT they are not that dumb at all when it comes to small tricks and instruction level optimizations. Hence IMHO you must be doing something wrong in your C code :D :D :D

[Slugsnack]

I'm agreeing with Bogdan on the last part. These small things should nearly definitely be handled in the peephole optimization part of the compiler.

[hutch--]

I have learnt this much that some algorithms cannot be further optimised from their compiled output and it is for a very simple reason, if you find the memory read/write boundary, nothing will make it faster. I had a test piece I used a couple of years ago that was a Sedgewick radix quicksort hybrid that I used as the test piece for a tool I was designing and while I thought the VC output code was scruffy, multiple complete rewrites would not go faster than the compiled output. With practice you could get it as fast using less registers, lower call overhead to its helper functions, individually the helper function were measurably faster but the overall algo hit the wall and just would not go faster.

I think this is the case with at least some algos and with code that does not hit anything hard in any particular place, compiler optimisation theory does do the job but it hangs together a lot differently to a manually written algorithm. Much of modern compiler optimisation theory is simple stuff that makes sense and you normally do this when you lay out an algorithm, keep un-necessary variables out of loops, plan the register use to reduce memory read/writes etc ... but it is here where manually written code is simply more flexible and with code that can be made faster, you pick up the benefit in areas where it matters.

I have long had the view that for a one off usage that optimisation rarely ever matters but as code reuse increases where an algorithm may be run trillions of times in its lifetime, it starts to pay off in terms of effort to do the work to make it faster or smaller or both as the unit cost of creating the algorithm diminishes at the increase of its usage.