6

Working on a problem that requires a GA. I have all of that working and spent quite a bit of time trimming the fat and optimizing the code before resorting to compiler optimization. Because the GA runs as a result of user input it has to find a solution within a reasonable period of time, otherwise the UI stalls and it just won't play well at all. I got this binary GA solving a 27 variable problem in about 0.1s on an iPhone 3GS.

In order to achieve this level of performance the entire GA was coded in C, not Objective-C.

In a search for a further reduction of run time I was considering the idea of using the "-O3" optimization switch only for the solver module. I tried it and it cut run time nearly in half.

Should I be concerned about any gotcha's by setting optimization to "-O3"? Keep in mind that I am doing this at the file level and not for the entire project.

Fattie
  • 27,874
  • 70
  • 431
  • 719
martin's
  • 3,853
  • 6
  • 32
  • 58
  • -O3 is still usually relatively safe as long as the code you wrote is "standard" and doesn't do any very specific trickery. Even then, since the iPhone's compiler only has to generate working code for a small handful of systems, it will likely be okay. – Adrian Petrescu Apr 10 '11 at 03:06
  • Just to add, if you're worried about the UI stalling, you may want to consider doing the computation on a concurrent thread. – David Apr 10 '11 at 03:13
  • I thought about adding a concurrent thread. The problem is that the way the code is written right now I don't have data to start the GA with until the user interacts with the UI. In order to launch a separate thread I would have to expand the main state machine to do some look-ahead work and predict what the GA will need. Not impossible, but if I can avoid it by having the GA go faster I'd rather move on to more pressing issues. I should add that the output of the GA determines what the next UI update will look like. – martin's Apr 10 '11 at 03:20

1 Answers1

5

-O3 flag will make the code work in the same way as before (only faster), as long as you don't do any tricky stuff that is unsafe or otherwise dependant on what the compiler does to it.

Also, as suggested in the comments, it might be a good idea to let the computation run in a separate thread to prevent the UI from locking up. That also gives you the flexibility to make the computation more expensive, or to display a progress bar, or whatever.

Tricky stuff

Optimisation will produce unexpected results if you try to access stuff on the stack directly, or move the stack pointer somewhere else, or if you do something inherently illegal, like forget to initialise a variable (some compilers (MinGW) will set them to 0).

E.g.

int main() {
    int array[10];
    array[-2] = 13; // some negative value might get the return address
}

Some other tricky stuff involves the optimiser stuffing up by itself. Here's an example of when -O3 completely breaks the code.

Community
  • 1
  • 1
evgeny
  • 2,564
  • 17
  • 27