Slashdot Mirror


Genetic Algorithms and Compiler Optimizations

mfago writes "Scott Robert Ladd has written an enlightening article and accompanying software package that utilizes genetic algorithms to optimize the optimization flags fed to a compiler. Those who have tried to squeeze the last drop of performance from a code know that it can be very difficult to determine the set of optimization flags beyond -O3 (with gcc for example) that yields the best performance. Lots of background links included in the article."

222 comments

  1. Beware the simple, elegant solution. by Thinkit3 · · Score: 3, Insightful

    Toss around terms like genetic algorithm and neural networks, and some are dazzled by the elegance and simplicity of it. Well, then there's reality, which is often neither elegant nor simple. In Go, there is a computer player that utilizes neural networks, yet it is near the middle of the pack.

    A good dose of skepticism should accompany any examination of the dazzingly elegant solution.

    --
    -Libertarian secular transhumanist
    1. Re:Beware the simple, elegant solution. by Anonymous Coward · · Score: 0

      Yep, a genetic algorithm is no more than a toaster with a phone attached to it.

    2. Re:Beware the simple, elegant solution. by Anonymous Coward · · Score: 5, Insightful

      Yes, a good dose of skepticism should accompany such things... however, this particular example is one in which the search-space is finite, and you're using a genetic algorithm to cleverly navigate this space.

      Neural networks are good when there is a massive amount of unknowns to deal with, and you're better off handling any patterns you can detect, but this is just a simple case of using a new(-ish) method to compare runs with (nearly?) all parameters. Nothing to be skeptical about, really.

    3. Re:Beware the simple, elegant solution. by tessaiga · · Score: 4, Funny
      In Go, there is a computer player that utilizes neural networks, yet it is near the middle of the pack.

      Wait, I'm confused; I thought on Slashdot we're supposed to wait for someone to mention Chess before we bring up Go?

      --
      The bold print giveth, and the fine print taketh away ...
    4. Re:Beware the simple, elegant solution. by koekepeer · · Score: 4, Funny

      anyways think about the overkill of developing such an elegant solution for such a minor problem. i mean those few percentages of performance enhancement...

      anyway, i think it *is* really cool this guy finds it interesting to tackle this 'problem' with a genetic algorithm. why not try some bayesian networks next? support vector machines? improbability drives...

      ooops, i'm getting carried away. sorry 'bout that. /me bows in admiration

      (not intended as flamebait but mod me to hell anyway *evil grin*)

    5. Re:Beware the simple, elegant solution. by zanerock · · Score: 4, Funny

      Neural networks != genetic algorithms

      Slow Go player != inelegant solution

      I was going to dissagree with you, but I'm not even sure what your arguments are. Do you have any reason to believe that the solution for the problem discussed in the article is inelegant or innefficient, or did you just get a bad grade in your AI class?

    6. Re:Beware the simple, elegant solution. by pnatural · · Score: 3, Interesting

      Because you have a single data point from a related problem domain (that does not even use the same solution!) and the single data point does not perform well, the concepts presented in this article are what? Flawed?

      I suspect you either do not understand genetic algorithms, or that you do not have experience in a problem domain where GA could have been successfully used.

      Just because you don't understand GA doesn't mean that GA isn't applicable to this problem. I recently had a problem to solve similar to the problem outlined in the article (optimizing results with N variables, where N > 5) and the GA solution beat the pants off the brute-force solution.

      Note that I'm actually not saying that GA is a panacea; rather, I'm saying that for some problem domains, like the one in the article, it makes a whole lot of sense.

    7. Re:Beware the simple, elegant solution. by mfago · · Score: 4, Interesting

      anyways think about the overkill of developing such an elegant solution for such a minor problem. i mean those few percentages of performance enhancement...

      I'm sure some people would love a few percent improvement in their SPEC results...

      Personally, I have an algorithm that I'm running hundreds of millions of times as part of a larger calculation for my PhD research. I'd love a "few percent" improvement simply by changing the compiler flags.

      Acovea is curently a research tool in its own right, and not quite ready for application to general problems. Some issues that require modest effort to resolve:

      1) Code currently is pentium3/4 centric
      2) Optimizes flags for gcc 3.4 or intel's compiler
      3) Cannot easily handle code residing in more than one file.

    8. Re:Beware the simple, elegant solution. by greg_barton · · Score: 1

      Beware the kneejerk skeptic. :)

    9. Re:Beware the simple, elegant solution. by Khomar · · Score: 1

      Apparently the news items were released out of order.

      --

      I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!

    10. Re:Beware the simple, elegant solution. by Tet · · Score: 2, Funny
      In Go, there is a computer player that utilizes neural networks, yet it is near the middle of the pack.

      All the top of the pack human players use neural networks. Your point?

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
    11. Re:Beware the simple, elegant solution. by Randolpho · · Score: 1

      Well.... I think it's elegant, and I *did* get a bad grade in AI. ;)

      --
      "Times have not become more violent. They have just become more televised."
      -Marilyn Manson
    12. Re:Beware the simple, elegant solution. by The+Madpostal+Worker · · Score: 1

      Someone once said: "A genetic algorithm is the second best solution to any problem"

      --

      /*
      *Not a Sermon, Just a Thought
      */
    13. Re:Beware the simple, elegant solution. by orangesquid · · Score: 1

      Yah, I agree.. I've been noticing many /.'ers seem to have little-to-no idea what "genetic algorithm" means, and don't understand the first thing about genetic optimization techniques. Oh well. I appreciate the article, anyway :)

      --
      --TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
    14. Re:Beware the simple, elegant solution. by JaredOfEuropa · · Score: 3, Informative

      Neural networks are well-suited for tweaking the (possibly numerous) parameters of an established algorithm. It's good for finding good local maxima on n-parameter functions. Another technique for this is simulated annealing.

      It's the cleverness of the algorithm that makes a computerised Go player good. Using a simple stinky algorithm and tweaking its parameters isn't going to turn a mediocre Go player program into a great one.

      As always, you pick the solution that fits the problem.

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
    15. Re:Beware the simple, elegant solution. by sfe_software · · Score: 1

      A good dose of skepticism should accompany any examination of the dazzingly elegant solution.

      Have you read the article? Personally I think it's an interesting method to determine, for a specific program or algorithm, what compiler options produce the fastest results. Survival of the fittest certainly works in this case.

      Sure, he didn't provide a specific set of optimization flags that are "best", but that's because it's highly implementation-specific. To imply that it's all about "buzz-words" indicates you didn't really read (or understand) the article...

      Personally, his method is elegant, IMO. It's definitely something I'll be looking into for my own software, at least for specific algorithms where speed is important (FFT analysis, for example).

      --
      NGWave - Fast Sound Editor for Windows
    16. Re:Beware the simple, elegant solution. by Dachannien · · Score: 4, Interesting

      What we should be most skeptical about is that Mr. Ladd wanted to study the effects of using a GA on optimization, yet he neglected to run a control sample involving random perturbation of options from the start case (-O1 or -O3), without selection.

      If, as I suspect, the search space is disorderly, then random perturbation should, among the same number of test compilations, be able to find a solution comparable to that which his GA finds.

    17. Re:Beware the simple, elegant solution. by Dachannien · · Score: 1

      [i]I recently had a problem to solve similar to the problem outlined in the article (optimizing results with N variables, where N > 5) and the GA solution beat the pants off the brute-force solution.[/i]

      I would indicate that Ladd's article sets up an invalid comparison between brute force and his GA search, because he seeds his search with the flag set for -O1 or -O3.

      I'm not saying he should make the GA start from scratch. I'm saying that he should permit brute force to start from -O1 or -O3 and perturb the solutions from there (in essence, run the GA but without selection, and take the best individual found at the end).

    18. Re:Beware the simple, elegant solution. by Anonymous Coward · · Score: 0

      I recently had a problem to solve similar to the problem outlined in the article (optimizing results with N variables, where N > 5) and the GA solution beat the pants off the brute-force solution.

      That's impossible, by definition. The brute force method will always result in the optimal solution. There is no such guarantee with GA.

    19. Re:Beware the simple, elegant solution. by Anonymous Coward · · Score: 1, Insightful

      THERE IS NO GENERAL SOLUTION to THE GLOBAL OPTIMIZATION PROBLEM!!!

      There simply is no general way to find the "best" of something. I would actually argue that genetic algorithms are in fact not the most elegeant, but rather the most brute force way to find a solution. But this is often quite appropriate. For the code optimization case, you can either optimize your code from first principles, and hope to untangle all the implications of your choices to find the best combination of compiler flags, or you can brute force your way through the combinations using genetic principles to propagate better choices (and hope you don't get stuck in local minima...) The former analysis may give you better results, but it is probably not general enough to work on anyones code.

      For another of example, take the Slashdot lameness filter. It should have filtered my yelling, but it didn't. Can you see why? Malda and co. could have used a (genetic|bayesian|stochastic) algorithm to characterize their filter!

      (Sorry about the yelling)

    20. Re:Beware the simple, elegant solution. by KingRamsis · · Score: 1

      yes there is :-)
      but will require some good deal of math.

    21. Re:Beware the simple, elegant solution. by vv2 · · Score: 2, Insightful

      Alternatively:- Add up the number of hours spent running optimisations on compiler flags, deduct actual time savings, times hourly rate and then see if it would be cheaper to add (scrounge) some more processors....

    22. Re:Beware the simple, elegant solution. by Hard_Code · · Score: 2, Insightful

      Pretty attractive if the first best solution takes longer than the age of the universe to compute, I'd say.

      --

      It's 10 PM. Do you know if you're un-American?
  2. Isn't this the Windows technique? by Anonymous Coward · · Score: 4, Funny

    That is, fiddle with settings at random until it's acceptable?

    1. Re:Isn't this the Windows technique? by mgoodman · · Score: 0

      don't be silly. you can't fiddle with nearly enough settings in windows to yield drastic improvements of any kind... ...not unless you like frequent bluescreens and reboots.

      --
      01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
    2. Re:Isn't this the Windows technique? by LoztInSpace · · Score: 2, Funny

      I think by the time it emerged from marketing it would be a "stochastic process".

  3. I did for this for my Ph.D. defense by Anonymous Coward · · Score: 4, Interesting

    It turns out that hand tuning will ALWAYS get you the best optimizations, but human nature dictates that a certain portion of optimizations will never be found. Genetic algorithms will find some of these optimizations in a reasonable time, but not all. So the bottom line is, no code can ever be 100% optimized, unless it is compiled for weeks.

    1. Re:I did for this for my Ph.D. defense by Anonymous Coward · · Score: 1, Interesting

      yeah, genetic algorithms generally need to have a good idea about when they're getting closer to the 'right' answer. there is so much interplay between compiler optimizations that it's generally regarded as a bad idea to use a genetic algorithm.

      the Liberty group at Princeton wrote an interesting paper on the topic and proposed a different solution:
      http://liberty.cs.princeton.edu/Publica tions/index .php?abs=1&setselect=cgo1_ose

    2. Re:I did for this for my Ph.D. defense by trolleri · · Score: 0

      ...no code can ***ever*** be 100% optimized, ***unless*** it is compiled for weeks.

      Oh I see!

    3. Re:I did for this for my Ph.D. defense by Anonymous Coward · · Score: 0

      So the bottom line is, no code can ever be 100% optimized, unless it is compiled for weeks.

      did you fail your defense when someone pointed out that there is no such thing as 100% optimized?

    4. Re:I did for this for my Ph.D. defense by DrSkwid · · Score: 1

      you can only get 100% optimized code on known data

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    5. Re:I did for this for my Ph.D. defense by laird · · Score: 1

      This is an interesting sounding post, but I just can't make any of it make sense. "It turns out that hand tuning will ALWAYS get you the best optimizations, but human nature dictates that a certain portion of optimizations will never be found. Genetic algorithms will find some of these optimizations in a reasonable time, but not all. So the bottom line is, no code can ever be 100% optimized, unless it is compiled for weeks."
      If genetic algorithms can find better optimizations than hand tuning (which has been proven on a variety of cases for a decade or so), then it's clearly NOT the case that hand tuning will ALWAYS get you the best optimization. And compiling code for weeks won't optimize it at all (unless you're using HotSpot, I suppose).

      Even the phrase "100% optimized" doesn't make sense, because there's no such thing as perfectly optimized code -- someone could always come along with a clever trick, or even a better way to solve the problem.

      So close to making sense...

    6. Re:I did for this for my Ph.D. defense by Jah-Wren+Ryel · · Score: 1

      It turns out that hand tuning will ALWAYS get you the best optimizations

      Given the rest of your post, I think you meant, "that hand waving will always get you the best optimizations."

      --
      When information is power, privacy is freedom.
    7. Re:I did for this for my Ph.D. defense by sangdrax · · Score: 1

      It is indeed impossible in general to optimize code 100% (even on known input) because it would solve the halting problem, which is impossible.

    8. Re:I did for this for my Ph.D. defense by Anonymous Coward · · Score: 0
      It is indeed impossible in general to optimize code 100% (even on known input) because it would solve the halting problem, which is impossible.
      That's just for the "general" case. For example, the Merge Sort has the best worst case performance of any sort, and thats been proven. Also despite the halting problem, automated theorem provers still prove theroems every day.
    9. Re:I did for this for my Ph.D. defense by laird · · Score: 1

      "That's just for the "general" case. For example, the Merge Sort has the best worst case performance of any sort, and thats been proven. Also despite the halting problem, automated theorem provers still prove theroems every day."

      Right, but to get back to the original point of the discussion, you can't ever prove that a given program CANNOT be further optimized. And as long as it's possible for someone or something to improve the optimization of the "100% optimized" code, there's no such thing as "100% optimized" code.

  4. SRL has been doing GA's for a loooong time! by toybuilder · · Score: 1, Informative

    I met SRL when I was teenager visiting Gunnison Colorado for the Rocky Mountain SOG. That was over 15 years ago. He was well into GA's then. Good to see he's still at it!

    1. Re:SRL has been doing GA's for a loooong time! by Wakkow · · Score: 1

      SRL? As in Shift Right Logical? Sounds like he was born to optimize code.

  5. cool application for GA by millette · · Score: 4, Interesting

    This is a very neat application of genetic algoriths! Haven't seen something so interesting since this Tron cycle game.

    1. Re:cool application for GA by Anonymous Coward · · Score: 0

      The game is /.ed

  6. I have a better idea by termos · · Score: 1, Interesting

    Why now just write faster code, and use inline assembler when needed, possibly with SIMD and MMX instructions?

    Those compilers are helpful, but as stated in article, squeeze the last drop of performance from a code is what they do.

    --
    Note to self: get smarter troll to guard door.
    1. Re:I have a better idea by IWannaBeAnAC · · Score: 2, Informative
      Because assembly language is fragile and not portable.

      A scheme for automating optimization choices is not fragile (when the code changes, just re-run the optimizer) and portable (when compiling on another machine, just re-run the optimizer). Beats assembly hands down.

    2. Re:I have a better idea by termos · · Score: 1

      I wasn't meaning everything entirely in assembly language, my bad.

      Those compilers are helpful is suppose to be Those compiler FLAGS are helpful, acually.

      And, when using it combined with C og C++ (or any other programming language) you can avoid using operating system specific stuff :-)

      --
      Note to self: get smarter troll to guard door.
    3. Re:I have a better idea by pmz · · Score: 2, Interesting

      A scheme for automating optimization choices is not fragile...

      Perhaps, someone should consider a GA for autoconf...

    4. Re:I have a better idea by Anonymous Coward · · Score: 0

      I totally agree with what you are saying, but I think the parent meant something different. If you isolate the most time-critical sections of the code then you can get the best of both worlds - you provide a high-level, portable implementation (which is also easier to write and likely to have fewer bugs - if nothing else this is useful during testing and as a starting place for a new port), and also provide a highly optimized version that takes advantage of things like SIMD instructions.

      In many cases, you should be able to get significant speed improvements this way. The trick is figuring out what parts are time-critical enough to make the extra effort worth it. One other advantage of this scheme is that you can skip writing the highly optimized version completely if you find that the portable version is good enough for your purposes.

    5. Re:I have a better idea by Anonymous Coward · · Score: 0

      And, when using it combined with C og C++ (or any other programming language) you can avoid using operating system specific stuff :-) ... which doesn't enhance portability between arcitechtures any.

      Or, to put it another way, MMX assembler runs really badly on my MIPS/Alpha/SPARC/PPC system...

    6. Re:I have a better idea by Short+Circuit · · Score: 1

      Except that the whole testing process took 21 hours. And there was a way to unit-test the performance of the resulting code.

      Unless there's a way to benchmark the code, it's nearly impossible to apply a GA for performance improvement.

      I want to see someone build an X-benchmarking tool. Then use a cluster to find the best compiler options for XFree86.

      I can definately see ATI and NVIDIA using this to improve their driver performance.

    7. Re:I have a better idea by pmz · · Score: 1

      Except that the whole testing process took 21 hours.

      Well, that might be an improvement...when autoconf breaks, it breaks hard. I'd rather leave and come back to something that works rather than waste a weekend digging through 10000 lines of moldy spaghetti.

    8. Re:I have a better idea by Short+Circuit · · Score: 1

      ouch. He was also testing relatively small programs on large machines. You're still looking at a pretty nasty performance hit.

      I wouldn't, for example, try this on the Linux kernel. It'd require serious hardware to compile within a reasonable time, and enough identical machines with virtualization software to benchmark the compiles within a reasonable time.

      All in all, I'd say it's something for IBM to try, not me.

  7. MISPRINT by Anonymous Coward · · Score: 0

    optimization flags beyond -O3 (with gcc for example) that yields the best performance.

    Should actually read - optimization flags beyond -O3 (with gcc at least) that yields the best performance.

  8. Skepticism by wdavies · · Score: 5, Interesting

    It actually seems like a good idea.Some problems I can imagine are optimization flags may have non speed related side-effects?

    However, this seems like a great candidate for GA's - a fitness function (ie speed of execution), and a nice binary vector of atributes (flags).

    Interesting that the gains aren't that great it would seem to sugges that the flags don't do much :) or maybe the base-line is already close to optimal, and so it isnt a hard problem?

    But Kudos nevertheless. No expert in the GA field, so its possible someones tackled this before, but if they haven't, extra Kudos.

    Winton

    1. Re:Skepticism by bill_mcgonigle · · Score: 1

      Some problems I can imagine are optimization flags may have non speed related side-effects?

      The algorithm described benchmarks code segments for speed; it's implied that it tests for correctness as well before accepting the 'gene', but if not it easily could and should do so.

      It might actually be a good way to test gcc releases, as testing all the optimization interdependencies is probably quite a big project (the author mentioned 27 quadrillion permutations?).

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  9. fragile GA, and what this is and isn't by kisrael · · Score: 5, Informative

    An important thing to note is that this isn't coming up with new optimizations, but rather finding the optimal mix of pre-existing gcc optimizations.

    It's an important distinction. When you're trying to do breed some really new system using Genetic Algorithms, it's possible to get some very fragile results, i.e. systems that do the job incredibly efficiently, but only under certain conditions...

    For instance, I remember reading some folks were trying to "breed" a circuit using Genetic Algorithm like techniques that created a "pulser" using as few gates as possible. They got something that used like one tenth the number of logic gates of the previous low record...but didn't work when they moved the setup away from their desktop PCs. Turned out what they "discovered" was a sensitive RF receiver that picked up (I think) something like the normal 120V cycling, and utilized. Similarly, a lot of the bred ciruits are extremely sensitive to temperature and other conditions.

    So breeding for efficiency can be a bit dangerous, you get things that rely on odd side-effects and environmental states. Though I think the method the article describes isn't much more dangerous than normal optimization selection, though admittedly more likely to stumble over some unusual flag combination that might break under certain circumstances.

    In short, *if* GA is ever going to let software development become more like gardening than engineering, (something I've herd as a goal) we're going to have to find ways to apply very general evolutionary pressures, complex test environments.

    --
    SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
    1. Re:fragile GA, and what this is and isn't by elmartinos · · Score: 3, Informative
      When you're trying to do breed some really new system using Genetic Algorithms, it's possible to get some very fragile results, i.e. systems that do the job incredibly efficiently, but only under certain conditions...
      This is not a problem of the Genetic Algorithm in general, this is the problem of the fitness function: The GA always tries to produce something wich gets the best out of the fitness function (e.g, a pulser with as few gates as possible). If the fitness function also uses the stability of the result in its calculations, (which it should!), the GA will try to create very stable solutions.
    2. Re:fragile GA, and what this is and isn't by hibiki_r · · Score: 1

      "Classic" genetic algorithms are little more than a pretty efficient search algorithms. They are pretty useful only if it is easy to recongize the level of "quality" of all individuals. When "growing" programs finding such a fitness function is hard. Really hard.

      The simplest approach is to come up with test cases, and rate the programs based on how many test cases they fulfill. There is a problem with this approach though: if all requirements are hard to fulfill (let's say, only 1 in 10 million random program fulfills at least one of them), there is no way that approach to program fitness is ever going to work. The complexity of any modern programming language is so high that using genetic algorithms to search for "a program in C that calculates fibonacci numbers" seems completely outlandish. The cost in electricity to find such a program would be higher than just giving the same specifications to a programmer.

    3. Re:fragile GA, and what this is and isn't by Anonymous Coward · · Score: 0

      yoda say :
      not think stack of hay. think stack of lego.

    4. Re:fragile GA, and what this is and isn't by bruthasj · · Score: 1

      It justs goes to show that the scientific method is still very important even with genetic engineering methods. One cannot rely on experiments happening in a single environment, rather they must run the GA to breed circuits in several labs around the world and diversify internal environments. Possibly, a local GA could try to breed optimal circuits and then a global GA would take the results of all the labs' local GAs and re-GA it to balance the system.

    5. Re:fragile GA, and what this is and isn't by xenocide2 · · Score: 1

      Unfortunately, its very difficult to automate the fitness function to include "stability" in GA circuit design. Even a binary "does it still work when I move it five feet from this CRT?" is time consuming, especially when you're planning on running large populations or generations.

      The fact that these GAs are exploiting electric interference and other phonomena that aren't easily applied to design by humans to achieve new and lower cost designs isn't unexpected. But I don't envy the people whose job is to push the frontier of computer part design, and understand how these work.

      Stability is a great idea, but measuring it automatically is equally difficult. I guess that just means more job security for those aforementioned researchers.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

    6. Re:fragile GA, and what this is and isn't by Max+Webster · · Score: 1

      Right, any given solution might turn out to be non-optimal on a machine with just slightly different specs (more or less memory; different amount of cache memory; faster or slower hard drive; more or less contention from other programs).

      Seems like most useful where the program itself is crucial, e.g. code whose innards are fairly stable, and that takes a long time to run. You can probably also draw some generalizations to say that certain options are recommended for programs "like" Linpack. This is the area that interests me more, to find the similarities between programs that make them amenable to certain options.

      Back in the '90s I worked at IBM documenting compilers. Also, I wrote a kind of expert system for the XL Fortran compiler that would ask some yes/no questions and recommend sets of likely options.

      Often the advice in the documentation boiled down to "try a a bunch of combinations and see what helps". The technique in this article sounds like a better mousetrap when someone is actually willing to take the time and effort to do that analysis. I don't know if, by knowing it, we could have offered any more practical advice though to J. Average User with an arbitrary program.

  10. Gentoo... by Anonymous Coward · · Score: 0, Offtopic

    Gentoomen, start your compilers.

  11. Optimized Code? by Anonymous Coward · · Score: 0

    Man, I say we need this 'cause my "Hello World" CRAWLS and the teacher needs it by tomorrow.

    1. Re:Optimized Code? by Trelane · · Score: 1
      Man, I say we need this 'cause my "Hello World" CRAWLS and the teacher needs it by tomorrow.


      Then you shouldn't be using C#1
      --

      --
      Given enough personal experience, all stereotypes are shallow.
    2. Re:Optimized Code? by Trelane · · Score: 1

      1Microsoft Fans can safely substitute "Java" in place of "C#".

      --

      --
      Given enough personal experience, all stereotypes are shallow.
    3. Re:Optimized Code? by Anonymous Coward · · Score: 0

      java fans can safely substitute "perl" in place of "java"

    4. Re:Optimized Code? by Anonymous Coward · · Score: 0

      Perl fans can safely substitute "Visual Basic" in place of "Perl".

  12. Re:Go see a doctor to get the Kangaroo removed by Anonymous Coward · · Score: 0

    I'm not French, you insensitive Claude-hopper!

  13. Important questions... by t4b00 · · Score: 1

    " Yet, despite that complexity, we need answers to important questions about modern, large-scale software. What sort of important questions? Well, consider the GNU Compiler Collection. I write articles that benchmark code generation, a task fraught with difficulties due to the myriad options provided by different compilers. For my benchmarks to have any meaning, I need to know which combination of options produces the fastest code for a given application."

    I thought we already knew, the answer is "42", of course we would have to build a computer the size of earth to test it...

  14. ... :P by rylin · · Score: 2, Funny

    Sadly, these genetic algorithms only work for blue-eyed developers

    1. Re:... :P by identity0 · · Score: 1

      Yes, it can only be used by those pure-blooded Aryans... Wait, weren't Aryans a tribe in India!? Oh, shit.

  15. French Kangaroos??? by Anonymous Coward · · Score: 0

    Thank you. I enjoyed that intercourse immensely.

    1. Re:French Kangaroos??? by Anonymous Coward · · Score: 0

      Alert the media!

      Dateline Geekland
      AC /.er claims to have enjoyed intercourse.

  16. Re:but, but by mgoodman · · Score: 0

    you poor bastard.

    --
    01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
  17. Disappointing by DogIsMyCoprocessor · · Score: 0

    I would have liked to have seen genetic algorithms that optimize the generated object code, not the compiler flags. I never really thought those needed optimizing.

    --

    "And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."

  18. How about optimizing compiler options? by Not_Wiggins · · Score: 1, Interesting

    The concept is good in that it can take a predefined set of available optimizations and "figure out" (via some AI magic) optimal settings. This is good.

    But, a more interesting problem might be more of a meta-compiler problem. Sure, we can optimize a set of options that we humans have determined/guessed are most influential in the building of efficient code. But what about running an analysis on the options themselves?

    If we want to get real optimization, why not apply some data-mining theory to the different switches available within the compiler to generate the set of option switches selection?

    Then, post selection of switches that are most influential in the compilation process, you can run this genetic algorithm to select "best switches" for the program you're compiling.

    --
    Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
    1. Re:How about optimizing compiler options? by Anonymous Coward · · Score: 0

      While an interesting idea, the amount of time it would take to investigate compilers themselves to find which switches should be used would be unacceptably large. It is similar to the old class scheduling problem faced by universities; there's no practical way to develop a best schedule, but good enough works fine and is usually done by people. By the time we had the computing power to do that analysis, we wouldn't need that level of optimization anymore.

  19. Re:Get your fucking President by Anonymous Coward · · Score: 0

    I was lucky and the fucker never did come here. If he had I would have taken the day off of work and tried my best to throw a pie at his face. Failing that I would have just stared at him and called him names.

  20. Re:Skepticism: KARMA WHORE by Anonymous Coward · · Score: 0

    Whenever I see the word "Kudos" in a /. post, I instantly think the poster is a karma whore. It sounds like "wdavies" has something interesting to say, but he's damaging his credibility by using Kudos.

  21. Some Problems by Anonymous Coward · · Score: 1, Interesting

    There are a couple problems you can come into when getting this deep into compiler optimization flags. 1. Flags will optimize certain parts of code well,but may make other parts slower. 2. There is no guarantee the optimization carries over to other computers.

  22. GAs wrong tool for the job by Sanity · · Score: 0, Informative
    I am as big a fan of GAs as the next guy, but I don't see the point in using them for this. Why couldn't he just measure performance with and without each optimization and see which had the greatest improvement? Yes, this might not take into account interactions between different optimizations, but to the extent such interactions occur, it would probably be specific to his test cases anyway.

    The use of GAs here seems like more of a gimmick, the same thing could have been achieved using conventional benchmarking.

    Lastly, 10% or 20% improvements in compiler performance are of largely academic interest only these days most software's time is spent waiting on user input, disk IO, or network activity anyway?

    1. Re:GAs wrong tool for the job by nukey56 · · Score: 1

      Good luck benchmarking a few billion (more?) possible combinations. Even if you had an iterative solution for this, the GA would probably find a decent solution much faster than it would take for the iterative solution to complete.

    2. Re:GAs wrong tool for the job by MisanthropicProggram · · Score: 1
      .....I don't see the point in using them for this.

      One word - marketing

      --

      There is no spoon or sig.

    3. Re:GAs wrong tool for the job by MattRog · · Score: 1

      Because this is an NP-complete problem and would take about 850-million (according to the article) years to brute-force every option. Personally, I'm not going to wait that long to get the *most efficient* compilation method for one of my programs.

      --

      Thanks,
      --
      Matt
    4. Re:GAs wrong tool for the job by pimpinmonk · · Score: 2, Funny
      I am as big a fan of GAs as the next guy
      So, you mean you have little or no idea of what GA stands for, let alone what it means and what its applications in computer science are?

      Sorry, couldn't resist :-)
    5. Re:GAs wrong tool for the job by GlassHeart · · Score: 3, Insightful
      Why couldn't he just measure performance with and without each optimization and see which had the greatest improvement? Yes, this might not take into account interactions between different optimizations, but to the extent such interactions occur, it would probably be specific to his test cases anyway.

      That's exactly the point. The goal is not to find a set of gcc switches that will work best on any program on any supported platform. The goal is to find the set that works best with this particular input, without human guidance.

      10% or 20% improvements in compiler performance are of largely academic interest only these days most software's time is spent waiting on user input, disk IO, or network activity anyway?

      First of all, what if you can get the 10% or 20% basically for free? That is, simply run your compile for a few unattended days to get the optimization? What is not worth human tweaking time can easily be worth machine time. Gentoo, although I do not use it myself, appears to be a vibrant Linux distribution based exactly on this point.

      Secondly, most existing software are running on small CPUs all around you, not on your desktop. The constraints of memory usage and CPU power are still very real for them.

      Finally, consider also that more efficient software may result in more idle hardware and lower power consumption. Imagine if all PCs in the world can get by with 5% less electrical power.

    6. Re:GAs wrong tool for the job by TMB · · Score: 1

      I regularly run several day computations. If I could lop half a day off of that, I'd be very happy.

      [TMB]

    7. Re:GAs wrong tool for the job by monique · · Score: 1

      [quote]
      Lastly, 10% or 20% improvements in compiler performance are of largely academic interest only these days most software's time is spent waiting on user input, disk IO, or network activity anyway?
      [/quote]

      What about embedded systems? What about the code that controls the disk I/O in the first place?

      --
      -monique
    8. Re:GAs wrong tool for the job by BCoates · · Score: 1

      I had good luck using automated hill climbing to (space) optimize the use of 'inline' for not-too-smart C compiler for an embedded system. In that environment, optimization is very useful, having to put another flash rom on every unit to fit your code is pricey.

      --
      Benjamin Coates

    9. Re:GAs wrong tool for the job by Event+Support · · Score: 1

      I am as big a fan of GAs as the next guy
      Gillian Anderson?

      I know I'M a big fan!

    10. Re:GAs wrong tool for the job by SWroclawski · · Score: 1

      You're making a number of assumptions which I don't think always hold true.

      You say that you could do these measurements without the GA. That's true, but the GA serves two purposes:
      1) To do the measruements of the combinations of
      optimizations (which you mention)
      2) To do the thing without human intervention

      The second one is the important one. The fact is that few people are going to spend the time and energy to do the optimizations "right". A few hours or days at some point figuring out "pretty good" compiler options seems very reasonable though and I can see a lot of my own users doing it.

      The issue of "is compiler optimization worth it?" depends on your problem domain. But if you're doing huge numbers of computations that may take hours to compete a single run, the answer is a resounding "yes" with a caviot.

      The caviot is that code optimization must come first. We know the compile can't fix bad code, and good code optimization can improve things in ranges we'll never see from simple compiler optimizations.

      Nonetheless, if a compiler optimization can shave, say 10 minutes from one run of a program that takes 3 hours to run- it's worth it. Why? Becuase that program is going to be run at least 1000 times. That ten minutes now becomes about six days of wall time. I can do a lot of processing in six days.

      - Serge

  23. Plus ca change, plus ca meme chose by Space+cowboy · · Score: 1

    ... now it's not that the compiler is too slow on the computer, but the super-optimiser that runs the compiler 2000 times on the code to get the speed as fast as possible, that runs too slow on the computer...

    That's all right then :-)

    Simon

    --
    Physicists get Hadrons!
    1. Re:Plus ca change, plus ca meme chose by NorthDude · · Score: 1

      It should have been: "Plus ca change, plu C'EST pareil." unless you wanted to say it in "Qebecois", then it would have been "Tabarnak, plusse ca change, plusse ce pareil sti". :-D

      --


      I'd rather be sailing...
    2. Re:Plus ca change, plus ca meme chose by Short+Circuit · · Score: 1

      I'm going to run it on GCC. (evil grin)

      kernel 2.4.22 in five minutes!

  24. A REAL PITTY by Anonymous Coward · · Score: 0

    I would really have enjoyed watching you get shot to death on CNN. Perhaps next time, you could make an effort, eh?

  25. Compiler optimisations don't win you much ... by MrDelSarto · · Score: 3, Informative
    Todd Proebsting has a "law" like Moore's law ... from his webpage
    Moore's Law" asserts that advances in hardware double computing power every 18 months. I (immodestly) assert "Proebsting's Law", which says that advances in compiler optimizations double computing power every 18 years.

    There is more information on his webpage. It's not strictly true -- compilers have moving targets (different architectures and hardware optimisations over time, greater complexity in languages, etc etc), and for important things like scientific applications compilers can really optimise code; but in general R&D towards compiler development seems to be sorely lacking compared to other areas.

    I work on IA64, which is fundamentally designed to take advantage of smarter compilers. While there are some interesting projects (ORC for example) nothing is really close to ready to take over gcc/intel compiler. We really want something that compiles once, can profile code execution and then recompile to optimise based on the execution profile; something along the lines of what this article talks about but built right into the compiler.
    1. Re:Compiler optimisations don't win you much ... by mi · · Score: 1
      We really want something that compiles once, can profile code execution and then recompile to optimise based on the execution profile; something along the lines of what this article talks about but built right into the compiler.

      Sun's compiler had this for years. From their man-page:

      -xprofile=p Collects data for a profile or use a profile to optimize. p must be collect[:name], use[:name], or tcov. This option causes execution frequency data to be collected and saved during execution, then the data can be used in subsequent runs to improve performance. This option is only valid when a level of optimization is specified. If compilation and linking are performed in separate steps, the same -xprofile option must appear on the compile as well as the link step.
      • collect[:name] Collects and saves execution frequency for later use by the optimizer with -xprofile=use. The compiler generates code to measure statement execution-frequency. The name is the name of the program that is being analyzed. This name is optional. If name is not specified, a.out is assumed to be the name of the executable. You can set the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR to control where a program compiled with -xprofile=collect stores the profile data. If set, the -xprofile=collect data is written to SUN_PROFDATA_DIR/SUN_PROFDATA. These environment variables similarly control the path and names of the profile data files written by tcov , as described in the tcov(1) man page. If these environment variables are not set, the profile data is written to name.profile/feedback in the current directory, where name is the name of the executable or the name specified in the -xprofile=collect:name flag. -xprofile does not append .profile to name if name already ends in .profile. If you run the program several times, the execution frequency data accumulates in the feedback file; that is, output from prior execu- tions is not lost.
      • use[:name] Uses execution frequency data to optimize strategically. The name is the name of the executable that is being analyzed. This name is optional. If name is not specified, a.out is assumed to be the name of the executable. The program is optimized by using the execution frequency data previously generated and saved in the feedback files written by a previous execution of the program compiled with -xprofile=collect. The source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program that generated the feedback file If compiled with -xprofile=collect:name, the same program name name must appear in the optimizing compilation: -xprofile=use:name.
      • tcov [...]
      --
      In Soviet Washington the swamp drains you.
    2. Re:Compiler optimisations don't win you much ... by topologist · · Score: 1

      gcc has something similar with -fprofile-arcs and so on, that can be used to supply branch prediction hints etc. after the profile run.

  26. Re:Gentoo by Anonymous Coward · · Score: 0

    No, really?

  27. Why use a GA? by eclarkso · · Score: 4, Interesting
    In general, the literature suggests that GAs tend to be a kind of 'jack of all trades, master of none' type approach. See, e.g., Russell & Norvig's AI: A Modern Approach textbook.

    As such, is there any justification for using a GA to do this rather than, say, simulated annealing? I'd would be interested to see a comparison of the two approaches. Especially in light of papers like this one.

    1. Re:Why use a GA? by Anonymous Coward · · Score: 0

      You wrote what I wanted to, but much nicer. I've seen a number of GA articles on Slashdot and every one leaves me thinking the writer doesn't understand what he's doing, so he throws a GA at it. In one case someone solve a simple linear problem with a GA. Maybe I'm just "old school", since it seems GA's are the lastest cool thing.

    2. Re:Why use a GA? by MattRog · · Score: 1

      Because GAs are typically a whole lot easier to write. What would a good cooling schedule be for this problem? Aye, there's the rub...

      --

      Thanks,
      --
      Matt
    3. Re:Why use a GA? by Anonymous Coward · · Score: 0

      I wondered about this too. However, I think there is some justification. There are a lot of opinions about what compiler flags are important and how they interact. You could say the effect of flag -mAAA is independent of flag -mBBB, and you might even be right, but can you get everyone to agree that they're independent? The fun of the GA approach is that it's pretty objective and comes up with its own answers independent of anyone's beliefs. So in that sense, it's valuable. Especially considering his comments about how he gets lots of e-mail with mutually-contradicting advice.

      Also, there were (at least) two goals to the experiment. The one was to find the best combination of compiler flags. The other was to find out which flags tended to make a difference and which were neutral. If the GA shows no bias towards a certain value in a dimension, then it means that flag doesn't make much difference for the particular test case. This is also interesting information. I would've liked to have seen a chart at the bottom listing the top ten flags that are most likely to make a difference in performance.

      However, having said that, I'm surprised / confused by one thing. All the charts showed five values: plain -O1, plain -O2, plain -O3, GA starting with -O1, and GA starting with -O3. I wasn't sure whether the search space for the GA with -O1 was the same set as for the GA with -O3. If it was the same set, why didn't they both come up with the same solution? Were there not enough generations run, or could other experimental parameters be improved?

      Conversely, if the two GA tests for each algorithm were in fact restricted to different sets of possible options, why did it make the difference that it did? If the first GA run was restricted to "never remove options present in -O1" and the second was restricted to "never remove options present in -O3", then it seems that the first GA had a larger space to explore and should have usually found a better solution than the second. But in almost every single case, the -O3 GA found a better solution! I can only assume that the -O3 GA won only because the GA parameters weren't ideal. It had a smaller set of possible solutions to choose from, so why did it do a better job?

      In either case, the results for the -O1 vs. the -O3 GA runs weren't what I'd expect ideally. I'm not sure if this means that the GA approach is not right for this problem or if it means that some better GA parameters should have been chosen (larger population and more generations). However, I do appreciate that it probably took quite a long time to run these GA tests! We're talking about tens of thousands of compiler runs. I guess that places a limit on the population size and on the number of generations. :-)

    4. Re:Why use a GA? by vrt3 · · Score: 1

      That's what I thought too.

      I understand that GA -O1 uses all the flags included in -O1 (those should never be removed) plus zero or more other flags. GA -O3 includes all -O3 flags plus zero or more other flags. Since -O3 is a superset of -O1, GA -O1 should be able to find any solution that is found by -O3.

      Apparently it doesn't, but I have no clue what that means. Not enough generations? Found a local maximum and can't get out of it? But it happens in almost all cases.

      What surprises me the most is that the author doesn't mention it anywhere. Surely he must have seen it, as he's quite thorough in analyzing the results.

      --
      This sig under construction. Please check back later.
  28. How bumpy is the problem? Do you need a GA? by Animats · · Score: 5, Insightful
    You could probably get equally good results with plain hill-climbing. Turn on all the optimizations. Then turn them off one at a time and see if things get better. Repeat until no improvement is observed.

    Any time you consider using a broad-front search algorithm like a GA, a neural net, or simulated annealing, try plain-hill climbing first. If you try any broad-front search, compare it with plain-hill climbing. Only if the space being searched is dominated by local maxima (but not too many of them) do the broad-front algorithms help. And they're always slower.

    If this guy had demonstrated that a GA did better than a plain hill-climber, he'd have an interesting result. But he hasn't demonstrated that.

    1. Re:How bumpy is the problem? Do you need a GA? by SmackCrackandPot · · Score: 3, Informative

      You could probably get equally good results with plain hill-climbing. Turn on all the optimizations. Then turn them off one at a time and see if things get better. Repeat until no improvement is observed.

      It is known that some optimisations can disable others. For example, "merge frequently called functions with parent" will penalise "store frequently used variables in registers" or "give priority to inner-most loop variables in registers". You could certainly build on the research in this article. What are the best types of optimisations for different types of algorithm (B-tree traversal, matrix-vector mathematics, text-editing). Does compiling different modules of an application provide improved performance over compiling all modules with the same set of flags?

    2. Re:How bumpy is the problem? Do you need a GA? by pmz · · Score: 1

      Does compiling different modules of an application provide improved performance over compiling all modules with the same set of flags?

      I would fear enabling different flags for different modules, except perhaps flags that are explicitly guaranteed to be only local in scope. Even then, I'm not so sure, as I've run into optimization-dependent bugs in programs that are a real PITA.

    3. Re:How bumpy is the problem? Do you need a GA? by sacrilicious · · Score: 1
      You could probably get equally good results with plain hill-climbing.

      Hill climbing algorithms are more susceptible to getting trapped in a local minima than genetic algorithms are. GAs tend to avoid this because of the cross-over breeding that occurs.

      --
      - First they ignore you, then they laugh at you, then ???, then profit.
    4. Re:How bumpy is the problem? Do you need a GA? by MoobY · · Score: 1

      You could probably get equally good results with plain hill-climbing.

      This problem is complex enough (the combinations you need for good optimization of your code are fragile when other chunks of options are taken out) for the hillclimber to get easily stuck in a local minimum. It's probably a good idea to use something different than the local search, and maybe add some annealing, tabus, or populations, and I think the choice of a GA is very suitable for the problem.

      If this guy had demonstrated that a GA did better than a plain hill-climber, he'd have an interesting result. But he hasn't demonstrated that.

      Whether this guy's algorithm is better than yours is up to you to show, not to him. The author of the article provided a very clear presentation of the problem, and the genetic algorithm can easily bring him a well performing result. The conclusions give insights that were not documented or explored before. At least, that is what I call a result.

      --
      --- Sigmentation Fault - Comments Dumped
    5. Re:How bumpy is the problem? Do you need a GA? by nobbis · · Score: 1

      I'll nitpick a bit: genetic algorithms are hill-climbing searches. Also, I'm not sure what you mean by "broad-front search algorithm" in terms of neural networks as backprop is gradient ascent (thus hill-climbing). Unless you meant something other than backprop?

      I guess you meant to say gradient ascent rather than hill-climbing but your argument is quite right: the performance of any search algorithm ultimately depends on the nature of the objective surface (something the GA people seem to casually ignore).

      It's interesting how GA seem to be a very contagious meme in terms of popular "AI" decades past any serious research into them. Guess it's the biological reference that gets the geeks' juices flowing...

    6. Re:How bumpy is the problem? Do you need a GA? by Animats · · Score: 2, Insightful
      Actually, I meant to say hill-climbing rather than gradient ascent. True gradient ascent implies you can evaluate the local gradient, i.e. you can compute the derivatives which represent the local slope direction. You can't do that for discrite problems like this one. Gradient ascent is more appropriate to problems expressed as differential equations. (Although, having struggled with nonlinear differential equation solving in high-dimensional spaces for several years, I can report that it's no panacea.)

      By "broad-front search" I mean one where you're searching the surface defined by the objective function from multiple starting points. GAs, neural nets, and simulated annealing all effectively do this. All three approaches are really special cases of a more general search operation. Because partisans of each approach use such different terminology, (much of it borrowed from biology) it's not obvious that this is the case.

    7. Re:How bumpy is the problem? Do you need a GA? by nobbis · · Score: 1

      GAs and simulated annealing are hill-climbing searches. The fact that they might be run from multiple starting points is neither here nor there. Their parallelism and stochasticity doesn't detract from the fact that they simply evaluate the objective function at certain points and then tend to move in the direction of best performance, i.e. they hill-climb.

      Non-hill-climbing optimisation methods (such as, say, treating the evaluations as samples from a Gaussian process and using regression to estimate a distribution model over the objective function from which new points are sampled) are fundamentally different.

      I'm still not sure what you mean when you say neural nets are a "broad-front search" as they are not a search algorithm but a representation.

  29. Wouldn't it be easier? by Anonymous Coward · · Score: 0

    Wouldn't it be easier to just ask Stallman what each one "optimizes" and which ones are the best to use? It would probably be a lot quicker... uh nevermind.

    1. Re:Wouldn't it be easier? by Anonymous Coward · · Score: 0

      RTFA. The researched guessed certain options would be the most efficient for certain types of code. Sometimes they were... sometimes they weren't.

      Half of Computer Science is learning to build all-capable machines... the other half is learning to understand them.
      -os

  30. -O3 by Kourino · · Score: 1

    I have a bone to pick with the summary. -O3 probably won't help your performance in the first place, and will likely degrade it. -O2 or -Os, with maybe a few -mxxxx or -fxxxx flags, would be better. Of course, optimizing your code by making it not do stupid things is the best. (Though compiling with -O2 is pretty much standard and a good thing.)

    1. Re:-O3 by Anonymous Coward · · Score: 0
      O3 probably won't help your performance in the first place, and will likely degrade it.

      I think that's a little too strong. Most times I've checked -O3 has been faster than -O2, so it's not likely to degrade performance. Generally the difference between -O2 and -O3 isn't enough to worry about. Of course there are always execptions.

    2. Re:-O3 by Anonymous Coward · · Score: 0

      I ususally use -Os. I want my code small.

    3. Re:-O3 by S.+Traaken · · Score: 1

      Just use -fno-exceptions

    4. Re:-O3 by shellbeach · · Score: 1

      -O3 probably won't help your performance in the first place, and will likely degrade it.

      Yes, you're right: -O3 is simply -O2 with -finline-functions and -frename-registers, neither of which are likely to make much difference and -finline-functions could actually slow things down.

      There's a fantastic freshmeat editorial from a year or two ago on all this here

  31. MOD PARENT DOWN by Anonymous Coward · · Score: 0

    +3 Interesting? The post is way off topic.

    1. Re:MOD PARENT DOWN by Anonymous Coward · · Score: 0

      Applications of genetic algorithms, perfectly on-topic.

  32. Genetic mumbo-jumbo by andy666 · · Score: 1

    Genetic algorithms are completely heuristic. It sounds cool that the idea of evolution is being used for optimization, but there is no real logic to it. I would like to see evidence that genetic algorithms produce any better results than other methods on a reasonably large class of problems.

    Call me grumpy, but I say they are a fad.

    1. Re:Genetic mumbo-jumbo by Anonymous Coward · · Score: 0
      I would like to see evidence that genetic algorithms produce any better results than other methods on a reasonably large class of problems.

      They work better when the person running them doesn't know other methods. The author talks about the size of the "number of potential combinations" and says, "Ah, complexity is associated with the problem domain! At times like these, I pull out a genetic algorithm." To me that shows a total lack of knowledge.

      I know I'm grumpy and I think they are a stupid lazy fad!

    2. Re:Genetic mumbo-jumbo by ChaoticCoyote · · Score: 1

      Certainly genetic algorithms have been over-hyped by some people; the same thing happens to any emerging technology.

      In practical terms, genetic algorithms have proven themselves valuable in searching and optimization routines; they've been used to design optimal jet wings, traffic flows, and to find shortest paths through networks. GAs are not the ultimate programming concept -- but they are very useful for certain problems.

    3. Re:Genetic mumbo-jumbo by Pentagram · · Score: 1

      A fad?? They were invented about 30 years ago. How long does something have to be around before they stop being a fad?

      There has been lots of research done on what class of problems evolutionary algorithms are good at - google for it or look on citeseer!

    4. Re:Genetic mumbo-jumbo by Short+Circuit · · Score: 1

      They're useful in this situation because they allow a reasonably accurate search through many possibilities (2^54, in this case), rather quickly. (21 hours, in this case)

    5. Re:Genetic mumbo-jumbo by spitzig · · Score: 1

      I've got a prof whose "big thing" is genetic algorithms. At one point, he had the best solution to Max-Clique, using genetic algorithms.

    6. Re:Genetic mumbo-jumbo by BobTheLawyer · · Score: 1

      This is most likely not possible.

      There are a number of "no free lunch" theorems proving that an optimisation algorithm which produces better results over one particular (and narrowly defined) class of problem will necessarily produce worse results over another class of problem.

  33. Zero by Anonymous Coward · · Score: 0

    At last! Someone who starts their graphs from zero!

  34. Shortcomings by hibiki_r · · Score: 5, Insightful

    Having worked on applying GAs to multi-objective optimization, I don't belive that this technique can be used effectively to optimize most programs.

    The main issue is to compare the individuals generated by the genetic algorithm. To do so, we need to both compile the program under the specified settings, and then to be able to benchmark its performance. In my current job, a full build of our main product takes over 12 hours on an 8 CPU machine. Using a pretty conservative estimate, 100 generations with 100 individuals each, we'd be talking about more than a year of CPU time for a single run of the algorithm!

    Even if we could ignore the amount of time required for compilation, we still have a second, more important flaw: Most programs out there are not really that easy to benchmark automatically. Database applications might need to go back to a known DB state to be able to run the benchmark faily. Also, server apps need to have the exact same load for every test if we want to be able to compare two executables fairly. This problem is increased when many compiler options will just create a 1% performance improvement or so. A poorly run system could lead the comparison function to just pick the wrong executable if the two executables didn't run in the exact same conditions.

    I see how using GE for this task has a high coolness factor, and how it might even be usable for applications that are by nature easier to benchmark, but don't expect this technique to be applicable to enterprise-sized server applications, or even most GUI based apps any time soon.

    1. Re:Shortcomings by pmz · · Score: 2, Funny

      12 hours on an 8 CPU

      100 million LOC, really crappy makefiles, or eight 60MHz CPUs?

    2. Re:Shortcomings by psavo · · Score: 2, Insightful

      a full build of our main product takes over 12 hours on an 8 CPU machine

      Err.. ever heard of rule that 5% of code does 99% percent of work?

      If your application does 'diverse' kind of things (you mention DB's), then most probably when optimizing one module, you're hurting others. The obvious solution is to optimize module by module. Starting from the most abysmally slow, your build environment.

      --
      fucktard is a tenderhearted description
    3. Re:Shortcomings by Anonymous Coward · · Score: 2, Interesting
      In my current job, a full build of our main product takes over 12 hours on an 8 CPU machine. Using a pretty conservative estimate, 100 generations with 100 individuals each, we'd be talking about more than a year of CPU time for a single run of the algorithm!

      True, but you can still get some improvement with a procedure like this:

      1. Profile the code
      2. Identify the bottleneck (probably less than 1% of your source, based on what you say)
      3. Apply the genetic algorithm to that 1%, and find the best optimization flags for it.
      4. Then try two combinations: (a) use those flags for it only and use your regular flags for everything else, (b) use those flags for your whole project. Pick the best combination.
      5. Repeat as necessary with other problem areas in the code, again as found by profiling.

      In fact, this might get you better results overall than running the genetic algorithm against the whole project. Sometimes the optimal thing is to have one set of optimizer flags for a certain chunk of code and then another set for another chunk.

      Having said all that, this article was mainly intended for research purposes. The goal seems to have been to find out more in general about which flags matter and how much than it was about producing a technique for everyday compiling.

  35. Correct code? by vondo · · Score: 1

    I've always found the largest problems with optimizers to be that they sometimes generate incorrect code. He doesn't seem to test for this. Of course, maybe the benchmarks are smaller/less kludgy than the n x 10,000 line codes I've tried to optimize with flags.

  36. Re:GENETIC ALGORYTHMS IS A GROSS MISNOMER by tomstdenis · · Score: 0, Flamebait

    Just because you don't understand where the term comes from doesn't means it's wrong.

    Tom

    --
    Someday, I'll have a real sig.
  37. Re:Speaking of compilers... by Anonymous Coward · · Score: 0

    It's because you don't know how to use a compiler, dipshit.

  38. VERMIN by Anonymous Coward · · Score: 0

    FUCK YOU YOU VERMIN!

    take you tratorous verminous garbage OUTTA HERE you SON OF A BITCH

  39. Code-generation bugs by Euphonious+Coward · · Score: 1
    To me, the most interesting facts about the various optimization options are which ones introduce bugs into my code. Sometimes -O2 introduces code-generation bugs that -O3 doesn't. Sometimes -O3 yields warnings that lead to fixing bugs somebody put in the source code, but which don't show up in testing.

    Of course, buggy code is more likely actually to fail under aggressive optimization. I've certainly had to maintain lots of buggy code, although of course I never write any of it myself. (Did you know that

    union { char c[8]; double d; } u;
    u.d = 1.0;
    char c = u.c[1];
    yields undefined results? The compiler is allowed (and under -O3, encouraged) to generate code that will erase your disk and impregnate your sister.)

    I wonder if Mr. Ladd checked the results of the programs he ran.

    1. Re:Code-generation bugs by Anonymous Coward · · Score: 0
      (Did you know that

      union { char c[8]; double d; } u;
      u.d = 1.0;
      char c = u.c[1];

      yields undefined results?
      That is only undefined in ANSI C because C must be platform specific.
      The code means c = "the second byte in the machine's representation of 1.0 as a double"
      If gcc generated code doesn't produce that, than gcc needs fixing.
    2. Re:Code-generation bugs by Markus+Registrada · · Score: 1
      The code means c = "the second byte in the machine's representation of 1.0 as a double" If gcc generated code doesn't produce that, than gcc needs fixing.

      Sorry, that's totally false. (I hope you don't get paid for writing C like this!)

      It doesn't just have "unspecified results", it is "undefined". The compiler is allowed to give you the second (or seventh!) byte of the double, but if you say -O3, you're asking it to generate the fastest code that is consistent with the standard. The fastest code, in this place, is to leave whatever is in that register already alone. If your code doesn't do what you wanted, then, it's because you didn't really say what you wanted.

    3. Re:Code-generation bugs by RML · · Score: 2, Informative
      Of course, buggy code is more likely actually to fail under aggressive optimization. I've certainly had to maintain lots of buggy code, although of course I never write any of it myself. (Did you know that

      union { char c[8]; double d; } u;
      u.d = 1.0;
      char c = u.c[1];

      yields undefined results? The compiler is allowed (and under -O3, encouraged) to generate code that will erase your disk and impregnate your sister.)


      Sorry, you're wrong, for two reasons:
      - A char* can be used to point to anything.
      - You can write to one member of a union and read from another.

      Both of those are implementation-defined, not undefined. Undefined means the compiler can blow up your computer. Implementation-defined means that the compiler must do something consistent and documented.

      If, however, you had written
      double d = 1.0;
      int i = *(int *)&d;
      you would have been correct.
      --
      Human/Ranger/Zangband
    4. Re:Code-generation bugs by Markus+Registrada · · Score: 1
      RML claims, "Sorry, you're wrong, for two reasons:
      • A char* can be used to point to anything.
      • You can write to one member of a union and read from another."
      Yes, a char* can point to anything. However, actually reading from uninitialized storage has undefined behavior. Writing a different member of a union doesn't count as initializing. Unions really cannot safely be used for type punning.

      Casting a pointer, as you say:

      double d = 1.0; int i = *(int *)&d;
      would be the correct way achieve that end (almost). The compiler would observe that the address of d had been taken, and not assume it was "dead" after the assignment. Then, i would get initialized via the pointer. No optimizer would damage such code. Note, though, that to be strictly defined (albeit not specified), i and the cast should be "unsigned int".

      With unions, though, all bets are off. If the Linux kernel has gaffes like that in it, it's no surprise that it breaks under newer compilers!

    5. Re:Code-generation bugs by raxx7 · · Score: 1

      Actually, there is no standard form of type punning in standard C.

      In the GCC domain, the union is the correct way. Doing it with pointers is undefined behaviour.

    6. Re:Code-generation bugs by RML · · Score: 1
      Casting a pointer, as you say:

      double d = 1.0; int i = *(int *)

      would be the correct way achieve that end (almost). The compiler would observe that the address of d had been taken, and not assume it was "dead" after the assignment. Then, i would get initialized via the pointer. No optimizer would damage such code.


      GCC can, will and does damage code that does type punning with pointers. Using a union is the only way guaranteed to work. Read the gcc documentation for -fstrict-aliasing, which is now enabled by default. It explicitly says that code using unions will work, while similar code using pointers will not. The example given for how to convert types correctly is
      union a_union {
      int i;
      double d;
      };

      int f() {
      a_union t;
      t.d = 3.0;
      return t.i;
      }
      --
      Human/Ranger/Zangband
  40. Look at top500 by hellstorm · · Score: 1

    If there are new entries to the top500 supercomputers list at every update, it is because there are still a HUGE amount of highly computational-intensive tasks to achieve

    --
    --------------------------------------------------
    Programming is good for health
  41. Speed Racer by joeytsai · · Score: 1

    Interestingly, I read a story in Debian Weekly News [1] where someone noticed that sometimes compiling a C++ program with -O3 is worse than with -O2.

    The moral of the story? Just because you're running Gentoo and you've compiled everything yourself doesn't mean you have the fastest possible system. You actually have to know what you're doing, too. :o)

    [1] http://www.debian.org/News/weekly/2003/44/

    --
    http://www.talknerdy.org
    1. Re:Speed Racer by Anonymous Coward · · Score: 0

      Oh shit, now there is going to be a version of Gentoo that builds your entire Linux system from scratch 100,000 times as it seeks an optimal Linux build custom-tailored for your hardware through the use of genetic algorithms.

      "I installed Gentoo last week. Man it took 36 hours to build, but now I have a super-fast distribution. You should see it -- it's awesome!"

      "Oh yeah? Well I started installing the new Gentoo Genetic Edition six weeks ago and it's going to be SO BITCHIN when it finishes optimizing. The progress bar says it's only going to be 4.5 more weeks, but you know it'll be less than that because it just keeps getting faster with every iteration!!!"

  42. No, GAs make great sense... by cduffy · · Score: 3, Interesting

    ...because they were able to pick out combinations of optimizations that measuring each optimization individually wouldn't have discovered.

    Consider the case in huffbench when
    -fmove-all-movables, -freduce-all-givs and -ftracer were discovered to result in great improvements when used with the other GA-selected optimizations -- but not when applied directly to -O3.

    Sure, these situations may be specific to the test cases -- but that's not to say his software can't be used to evaluate real-world scenarios as well, such that companies doing a final release compile of their code let a GA churn for a few days to determine the best flags to use.

    That's a Good Thing, no?

  43. Re:Speaking of compilers... by Anonymous Coward · · Score: 0

    I want to know why my tiny Hello World shows up at 45KB

    try visual c++, it'll be 45Mb and won't even work unless you reboot.

  44. Fix the Compilers by Gothmolly · · Score: 2, Insightful

    The compiler ought to optimize this stuff anyway! How about "set suck=(yes|no)" and "prefer=(speed|size)" as options. Let the compiler and its designers come up with what is required to meet (or approach) a programmer's wishes.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:Fix the Compilers by Anonymous Coward · · Score: 0

      Go ahead. Write such a compiler.

      You might encounter a problem or two with it, though, like for example the fact that you're compiling arbitrary code whose performance you have no way of evaluating. This is because performance happens at runtime, not at compile time. It's also because you don't know what data they're going to want to use, and often enough the correct optimization settings depend on the program's input as well.

      (Note, however, that this is part of the promise of run-time compiling systems like Java's JVM. Then the compiler can observe the running code, and it does have the information it needs to make optimization decisions.)

    2. Re:Fix the Compilers by unholy_sz · · Score: 0

      To me it seems that at least in the embedded domain the option should be something like (prefer=speed_over_size_as_long_as_the_size_is_acc eptable), i.e. even this is non-trivial, even if we could make this work easily... Perhaps something like: prefer=speed with-max-size=$XYZZY_BYTES.

  45. Anybody remember Green Hills C Compiler by BanjoBob · · Score: 2, Interesting

    The Green Hills C compiler had all kinds of optimization techniques but they also had a way to measure the assembler output. One method would eliminate all symbols and make huge code that ran inline. The code was fast but used up a lot of disk space. They had many optimization options and dozens of flags that could be set so that the compiler would actually give you what you wanted. Analyzing the assembly code was a great way to learn the ins and outs of their compiler.

    --
    Banjo - The more I know about Windoze, the more I love *nix
    1. Re:Anybody remember Green Hills C Compiler by red+floyd · · Score: 1

      I loved that compiler! The 68030/68882 compiler did some incredible optimizations!

      We looked at some of the code once, and it stored some (moderately complex) result in a register, and we couldn't figure out why, until about four pages of ASM later, it re-used it!

      We were very impressed....

      --
      The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
  46. Re:Speaking of compilers... by Anonymous Coward · · Score: 0
  47. Beyond -O3 by terminal.dk · · Score: 1

    Beyond -O3 we have -OS and -O2. Both generates better codes on workstations. And -OS might be the best on Celerons and VIA C3 CPUs.

    How will the synthetic algorithm determine if the app is for a server or a workstation ? And how to handle dual purpose machines ?

    1. Re:Beyond -O3 by pclminion · · Score: 1
      Considering that (for gcc at least) the only major difference between -O2 and -O3 is enabling function inlining and loop unrolling, that makes sense. -Os helps because small code is more likely to fit in cache. Similarly, -O2 outperformed -O3 because it doesn't inline functions and therefore increase code size.

      Optimization used to be all about straight-line execution and loop unrolling. These days, branch prediction pretty much obsoletes both. It's far more important to keep code size down and maintain cache coherence.

  48. The Golden Rule of Optimization by rhysweatherley · · Score: 3, Insightful
    Never forget the Golden Rule of Optimization: a quicksort compiled with no optimization will invariably beat the pants off a bubblesort compiled with the best optimizer in the universe.

    Optimizers change the constants in the algorithm running time. They cannot change the algorithm's order.

    With the exception of high-performance computing, no one needs a super-optimizing compiler any more. Instead, they need to (re-)learn basic algorithm and data structure theory.

    1. Re:The Golden Rule of Optimization by Anonymous Coward · · Score: 0

      Actually, a bubblesort on a small list is usually faster than a quicksort on the same list. I think the break-even point is usually in the neighborhood of 10 elements. I think bubblesort is also faster on a nearly-sorted list, but I'm not sure.

    2. Re:The Golden Rule of Optimization by Anonymous Coward · · Score: 0

      "Optimizers change the constants in the algorithm running time. They cannot change the algorithm's order."

      Actually that's not true. See Burstall & Darlington's paper about recursive function optimization (from around 1977 i think). I'm sure there are others as well.

    3. Re:The Golden Rule of Optimization by hh10k · · Score: 2, Insightful

      Perhaps you should re-learn basic algorithm and data structure theory, because bubblesort can beat the pants off quicksort when the data set is small enough. Anyway, if you're going to implement quicksort, don't you want a 20-30% faster quicksort?

    4. Re:The Golden Rule of Optimization by Bazouel · · Score: 1

      And CountSort could mop the floor with QuickSort if people would actually use it when possible.

      Inertia is the main obstacle to progress.

      --
      Intelligence shared is intelligence squared.
    5. Re:The Golden Rule of Optimization by AnalogousCoward · · Score: 1

      Well now, wouldn't it be grand if they could add an optimization that would recognize a bubblesort and change it to a quicksort. Or better yet, tell the programmer to use STL.

      --
      "I do not fear computers. I fear lack of them." ~ Isaac Asimov
  49. Mornington Crescent by BeerCat · · Score: 1

    I thought on Slashdot we're supposed to wait for someone to mention Chess before we bring up Go?

    Ah yes, but with the Kasparov reversal, you can jump from "Go" straight to "Mornington Crescent"

    --
    "She's furniture with a pulse"
  50. Other ideas by adjuster · · Score: 3, Interesting

    This gets me thinking about Nat Friedman's GNU-rope (Grope) project. I heard him talk at ALS back in '98 and then the project seemed to completely disappear. Searching on "gnu.rope" leads to a few mailing list postings asking "where'd it go", but no good information about the project.

    The basic idea was to reorder the functions in an executable so that locality of reference was maximized and cache hits were increased. The result is less paging and better performance and memory usage.

    The really interesting bit is that the optimization is based on the usage of the program being optimized-- that is to say that my Grope-optimized version of Mozilla might be different than yours based on my differences in usage (i.e. perhaps I browse with images turned off, etc).

    The tie-in to the article here is that Nat's system, Grope, used simulated annealing to traverse the n-dimensional space of potential function arrangements and profiled the memory paging of the application as a fitness function of the new arrangement. It's not a GA-- but it's functionally similar.

    So-- anybody know what happened to Grope? I'd imagine that a community would spring up around it fairly quickly given the relatively high number of "performance zealots" who are busy "tricking out" their Linux boxes by compiling everything from scratch (think Gentoo) optimized for their procesor. Now they can add the "spolier" or "racing stripe" of having exectuables specifically re-ordered for their personal usage patterns! *smirk*

    --
    The Attitude Adjuster, I hate me, you can too.
    1. Re:Other ideas by bloosqr · · Score: 3, Informative

      I think this is actually what most two pass compilers will do. The intel compilers have this option for instance. Basically you compile w/ profiling on and on the second pass it using the runtime profiling data to recompile source to a new object code. (btw the intel compilers are "free" for opensource/nonprofit use). W/ regards to using GA/SA as part of the optimization it would be (to be honest) a bit weird to have a nondeterministic compiler since in different runs you may end up w/ different optimizations.

      -bloo

    2. Re:Other ideas by RML · · Score: 1

      GCC implements two-pass compilation. Look at the documentation for -fprofile-arcs and -fbranch-probabilties.

      --
      Human/Ranger/Zangband
    3. Re:Other ideas by Anonymous Coward · · Score: 1, Informative

      I'm a good friend of Nat's,and I talked with him a lot about GROPE when he was doing it (as an undergrad back in 1998 at MIT). I recall many nights of him ranting:

      "So I'm actually sitting here writing a fucking toolchain."

      He says he's gotten several requests for code, mailed said code, and nothing happened. (i'm a physicist, so perhaps my thinking this prjoject was cool was misguided. Anyway, it brought back pleasant (?) memories. No, I don't really know what toolchains are.)

      I mentioned this thread to him this evening. He found it nice, but he's a bit busy with Ximian at the moment ... :-)

      For what its worth, I asked him if he'd put the code on nat.org, as at least one person is interested in it.

      So, for once I read a /. story and could do something about it ...

      (yeah, posting AC is weak ... but no one can accuse me of name dropping.)

    4. Re:Other ideas by gillbates · · Score: 1
      The basic idea was to reorder the functions in an executable so that locality of reference was maximized and cache hits were increased. The result is less paging and better performance and memory usage.

      I've been doing this with x86 assembly for years. The advantage of assembly is that I can get the executable size down to the point where the entire module fits into the on-chip cache. Which improves performance considerably.

      And while I do like C/C++, etc, there are simply some things which can't be done without assembly (hardware access comes to mind, bootstrap code, etc...).

      --
      The society for a thought-free internet welcomes you.
  51. Reliability, and porting to Macintoshes... by billstewart · · Score: 4, Insightful
    Doing lots of Pentium-specific tweaks in your code may be zero or negative help when somebody wants to run it on a Macintosh....

    More importantly, tweaking code for heavy optimization is not usually a good job for humans. It's fine if you've got a piece of hardware that you have to tweak the last few percent performance out of for an application that will run for many CPU-years, but you're almost always much better off if you

    • Pick good algorithms
    • Leave bit-bashing loop-twiddly optimization tricks to the compiler, and
    • Put your human creativity skills to work on the next revision of your code, or on your next project if this one is done.
    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    1. Re:Reliability, and porting to Macintoshes... by vivian · · Score: 1

      You said: Doing lots of Pentium-specific tweaks in your code may be zero or negative help when somebody wants to run it on a Macintosh....


      The beauty of this technique is that instead of having to be an expert on how the various switches affect the compile on each platform, or do multiple recompiles per platform to try and tweak the compiler by hand, you can use the GA to determine the best switches to use for each platform.

      I just hope that this work gets extended to the point where it can do similar tweaks on a per module level so that you can just let the thing run overnight or for a day or two and squeeze the fastest compile options for your code out of the compiler.

      Yes, of course using a better algorithm (eg. quicksort vs shellsort for sorting) will potentially improve performance much more than tweaking compile switches ever will, but that is a completely seperate issue and should not be used as an argument against this technique to produce faster code. I'd love to see this work get added to gcc (yes, as another compiler swtich :) )

  52. Incredibly pathetic. by aminorex · · Score: 0, Troll

    This is a new low. Next we'll see papers
    on using genetic algorithms to find the best
    channel on TV.

    What would be interesting is a genetic system
    to select meso-scale optimizations in a
    compile back-end, for example.

    --
    -I like my women like I like my tea: green-
    1. Re:Incredibly pathetic. by jhunsake · · Score: 1

      I agree. There really is not point to this work except to know that the work itself is useless. I say we leave compiler optimizations to the people that have a clue.

  53. Atlas :: empirically optimized blas/lapack by bloosqr · · Score: 2, Informative
    There is a variation of this that is very clever that optimizes BLAS and LAPACKroutines "empirically" called ATLAS that has been around a while, originally (and perhaps still) a research project by err Clint Whaley from tennessee (BLAS/LAPACK are numerical routines that do a slew of thing people generally find useful linear algebra and vectors). These routines will often time sit "under" many mathematical packages like matlab/octave/maple/mathematica/scilab as well
    as make up the core of much custom scientific computing packages (or even libraries like the "Gnu Scientific Library")


    Basically the jist is atlas "empirically" (read: use an optimizer for instance like GA, though empirical may actually mean brute force in this case) to optimize various parameters that will affect things like optimize the routine for the cache size of the processor etc. The cool thing about this, is they can get w/in 10% of hand machine coded BLAS/LAPACK libraries w/out the pain!

    1. Re:Atlas :: empirically optimized blas/lapack by Gandalf21 · · Score: 1

      Actually I know that Clint Whaley is still working on ATLAS and related topics, since he shares the same advisor as me at Florida State University.

      Perhaps more interesting (and relevant to the topic at hand) is some other research involving compiler optimization and genetic algorithms. (Please note that I am part of a group currently working in this area.) There have been several papers on the topic already from Rice University as well as from our group at FSU. These results have more to do with tuning the order of optimization phases in a compiler using a genetic algorithm, since certain phases may enable or inhibit other phases. Thus the big difference between these studies and the gcc study is the lack of a fixed optimization phase sequence, so certain phases may be skipped, repeated or just rearranged to provide greater benefit.

    2. Re:Atlas :: empirically optimized blas/lapack by bloosqr · · Score: 1

      Whoa that is very cool. I didn't realize Atlas was a MS project actually. Whaley should honestly get a lot more credit that I think he does (at least from the current sourceforge description). Admittedly, i'm a physicist and we tend to be a bit biased about the importance about these things :) But Atlas really epitomized one of the coolest ideas I'd seen in recent times.
      -avi

  54. GA exploit environments' flaws by Hjallli · · Score: 3, Informative

    The "folks" you refer to is Professor Adrian Thompson of the University of Sussex. A paper describing his interesting experiment can be found here. It was actually a flawed FPGA chip he was programming.

    Another example of this tendency of Genetic Algorithms to make use of helpful "flaws" in their environments can be found in the works of Karl Sims. A round-off error in his physics model resulted in some weird locomotion by a branch of virtual creatures.

    You will find details of both examples in this entry on my Wetware blog.

  55. compiler profiling by Anonymous Coward · · Score: 0

    Why not skip the recompile and perform profiling based optimization directly on the machine code?

  56. Dude, look at the numbers in the article. by Anonymous Coward · · Score: 0

    For the five benchmarks he used,
    -O3 was at least a little faster
    than -O2 in every one of them!

  57. Quantum-based compiler optimization by Anonymous Coward · · Score: 0

    You pusses and your classic computing algorithms. A quantum algorithm for optimizing compiler optimizations is the only way to go in Theta(1) time!

    Seriously, this genetic algorithm approach is like most other approaches using GAs: stupid.

  58. Roomba by Anonymous Coward · · Score: 0

    How about Roomba, I supect Roomba program is from GP (not GA) or some other evolution programming algo.

  59. No, it's the Mother Nature technique. by devphil · · Score: 1


    and yes, that really does consist of fiddling with the settings (each generation born counts as a twist to one of the control dials) until it's acceptable (Deer 2.0 can outrace Wolf 1.9, now Wolf needs to breed a 2.0 before they all starve).

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  60. And your point? by devphil · · Score: 3, Insightful


    While I don't disagree with your observations, I'm confused as to what they have to do with Ladd's project and the results shown.

    Okay, find, I've written my decent quicksort. I know my basic algorithms and data structures. Now I would very much like to squeeze every last drop out of them. Here's a project that will tell me a good combination of options to use as a starting point. Don't tell me that I should just ignore all that and go re-re-re-learn basic algorithms. GCC is used by more than students.

    More than that, it will tell the GCC maintainers which options should be on by default which currently might not be, and vice versa.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  61. Why not use a GA? by devphil · · Score: 1


    The first rule of evolutionary techniques is: if there is a better-known, more specific optimization technique for the problem at hand, use it instead. In this case, there wasn't one.

    Simulated annealing has a lot in common with GAs, but they tend to not do so well on multidimensional discontinuous fitness landscapes.

    I'm sure annealing could eventually be used to come up with a solution; I'm just amazed whenever somebody does something cool with Tool X, and all of slashdot immediately jumps all over it with, "why didn't they use [my favorite tool]? why this one?"

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    1. Re:Why not use a GA? by eclarkso · · Score: 1
      The first rule of evolutionary techniques is: if there is a better-known, more specific optimization technique for the problem at hand, use it instead. In this case, there wasn't one.
      Is that true? My point was that he didn't try any other algorithms, so we don't know one way or the other...
      Simulated annealing has a lot in common with GAs, but they tend to not do so well on multidimensional discontinuous fitness landscapes.
      I think the number of local optima and relative fitness of those optima are much more of a problem for SAs than the dimensionality or discontinuity. I did a project comparing GAs and SA on (among others) the k-color map problem, and found solution quality was similar--but the SA implementation was much faster. KC certainly qualifies as a multidimensional discontinous space.
      I'm sure annealing could eventually be used to come up with a solution; I'm just amazed whenever somebody does something cool with Tool X, and all of slashdot immediately jumps all over it with, "why didn't they use [my favorite tool]? why this one?"
      Considering I've posted about 20 comments in 3 years, I'm not sure I'm representative of /. And I'm not concerned he didn't use simulated annealing or any other algorithm in particular, I just would be curious to see it compared with any other implementation.

      I'm not trying to rain on someone's parade, I'm just looking at it from a research point of view: one of the first thing anyone asks about any project is the justification for the approach.

    2. Re:Why not use a GA? by devphil · · Score: 1
      My point was that he didn't try any other algorithms,

      Did you ask him?

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    3. Re:Why not use a GA? by eclarkso · · Score: 1
      Did you ask him?

      No--don't you think it's reasonable to assume that he would have written about it if he had?

  62. Not the point by devphil · · Score: 2, Informative
    Having worked on applying GAs to multi-objective optimization, I don't belive that this technique can be used effectively to optimize most programs.

    Good, because that's not the original intent of the project. When he first contacted the GCC maintainers about the project which would later be called Acovea, the idea was to see which underlying -f/-m options shod be turned on by the -O? options by default. More and more projects using 3.2 and 3.3 were using "-Osomething -fno-something -msomething" so he took the 3.4 (in development) code to see what should additionally be turned on and what should be turned off instead.

    While you can use it to tune for particular programs, and particular patterns of use, it will mostly be useful to GCC itself.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  63. PostgreSQL by Wolfier · · Score: 1

    The PostgreSQL optimizer has been based on GA for some time now.

  64. Of course by extrasolar · · Score: 1

    As we all know, if your code is too slow then your compiler isn't smart enough.

  65. Uh... by Rocky · · Score: 1

    ...I would expect that of this was really something to write home about, it would have been published somewhere like PLDI or Usenix. Was it?

    --
    "I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
  66. Simulated Annealing for Optimization by exp(pi*sqrt(163)) · · Score: 2, Interesting
    Years ago I wrote some code that could tell if a pair of instructions 'commuted' in the sense that they could be reordered without affecting the functionality. Eg. "mov eax,1" and "mov ebx,2" are likely to be swappable but "mov eax,2" and "add ebx,eax" almost certainly can't be. I then used simulated annealing to walk through the space of code segments equivalent under commutation in an attempt to find the reordering optimal for the CPU pipeline.

    In other words I randomly swapped pairs of instructions that could be swapped, if it saw an improvement it kept it and if it saw a degradation it rejected it with a probability depending on how bad it made things.

    After hours of running it would sometimes trim a clock cycle or two per loop off a short assembler routine.

    --
    Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
    1. Re:Simulated Annealing for Optimization by Marcus+Meissner · · Score: 1

      gcc already does this, using processor pipeline models.

      Ciao, Marcus

  67. Good solution to the wrong problem by WayneConrad · · Score: 2, Insightful

    There are domains where squeezing every last cycle out of the code matters. Many of us no longer work in those domains. Most of the code I've written in the last 4 years was developed and executed in an environment with essentially unlimited cycles, memory, and disk. The only exception was one project that got database bound, and compiler optimization won't help that.

    For programmers who are no longer resource limited, using a language that optimizes for the human rather than the computer is a good idea. A language with garbage collection, low syntactic sugar, functional constructs like closures, and no separate compile phase make for happy code and happy programmers.

    An interesting benefit of working in a humane language is that it can becomes easier to use a better algorithm. Many algorithms depend upon data structures that are difficult to implement in the land of DIY memory management, but a breeze in a more humane language. This can make a solution in the apparently unoptimal language outperform the solution in the optimal language. Of course, we *could* go faster using C or C++, but only if we have the extra time it takes to write the code.

    Don't optimize for the computer unless the computer is the critical constraint. And, even then, only optimize the part that is the actual constraint.

    Otherwise, optimize for the human. We're more important than the computer these days.

    1. Re:Good solution to the wrong problem by Viol8 · · Score: 1

      "Otherwise, optimize for the human. We're more important than the computer these days"

      Actually we're not. Programmers are ten a penny , but a large computer system costs a fortune. If a company can get as much performance out of a
      machine as it can in order to hold off on an upgrade they will. YOU may not work in a enviroment where performance matters
      but I can assue you that a whole lot of us still do.

  68. You do not know what you are talking about by Pentagram · · Score: 1

    "Classic" genetic algorithms are little more than a pretty efficient search algorithms.

    GAs are nothing more than search algorithms, but then pretty much all AI is search.

    The complexity of any modern programming language is so high that using genetic algorithms to search for "a program in C that calculates fibonacci numbers" seems completely outlandish.

    It may seem outlandish to you but using a form of GA known as Genetic Programming, programs to calculate Fibonacci numbers have already been evolved. It is certainly possible to generate C, assembly, and code from other languages in a meaningful way.

    The cost in electricity to find such a program would be higher than just giving the same specifications to a programmer.

    Remember, natural selection in the real world, which evolutionary algorithms are an abstraction of, have produced those programmers.

    1. Re:You do not know what you are talking about by Anonymous Coward · · Score: 0

      >The cost in electricity to find such a program would be higher than just giving the same specifications to a programmer.

      Remember, natural selection in the real world, which evolutionary algorithms are an abstraction of, have produced those programmers.


      How is that relevant? Most of modern applied science is about overcoming the limitations forced on us by the poor quality of our evolution. Genetics promises to let us take control of human development and fix all the bugs that evolution has created - that "old age" thing, for one.

  69. NP optimization by igny · · Score: 1

    While I applaud to using GA to optimize the compiler settings, which basically tweaking handling of loops and function calls, how about figuring out which is most optimal way to store different variables, in registers, caches L1 and L2, RAM, HDD, tape? FYI, that is a known NP-hard problem.

    --
    In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
  70. Sounds kind of scary by dido · · Score: 1

    Interesting but that sounds kind of scary. Once you attempt to find optimizations that actually try to find other equivalent algorithms, you start treading into the dangerous realm of undecidability and Turing completeness. Consider what optimizing Turing-complete systems like partial recursive functions or their equivalent Turing machines entails. The first, and most important thing you need to do is decide whether or not some Turing machine runs faster (or more generally has a better performance metric) than some other Turing machine. You run it, and do your measurements. But then, how do you know whether there might exist some input for which your TM's will eventually enter an infinite loop? You can't know that, it's undecidable. It's the halting problem, and I imagine you'll run into this all the time when you try to do this level of optimization.

    Any system that tried to optimize recursive functions or any other equivalent Turing-complete formalism according to some optimization metric (e.g. space or time complexity) is at most attempting to apply heuristics to decide the undecidable. I seriously doubt that such an approach would ever be useful enough to clean up after sloppy "programmers" who never bothered to study proper algorithms and data structures, and recode a quicksort where a bubble sort was originally written. At best, I imagine it would produce marginal improvement while increasing compile time dramatically, and would be totally impractical for any sort of useful work. I seriously doubt such techniques were ever used in anything but research compilers for toy languages.

    --
    Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
  71. You're being too pessimistic by cameldrv · · Score: 1

    The halting problem says that it is impossible to write a program that will decide halting for every single possible program. The real problem is a certain class of pathological problems. There's no reason to believe that a specific program devised by a GA could not be proven to halt. It is also quite possible to prove that certain optimizaitons will preserve certain properties, such as halting. It is not possible to prove whether any given optimization will preserve halting.

  72. Distributed Projects are a good immediate fit by Anonymous Coward · · Score: 0

    These projects tend to be CPU bound and
    every CPU cycle counts. I understand some
    have been hand coded into assembler...but
    not all.

  73. Not just compiler flags? by Ed+Avis · · Score: 1

    It should be possible to apply the same technique to other performance-tuning things like buffer sizes, or even choosing between two different algorithms for the same task. Perhaps a program could have a single header file performance.h containing // buffer size for reading
    const size_t read_bufsiz = 1000; // amount of new memory to allocate in a chunk
    const size_t chunk_size = 5000; // threshold for switching from quicksort to // merge sort when you have this few elements //
    const unsigned int merge_sort_thresh = 10;

    and then these values would be tuned at the same time as compiler flags.

    --
    -- Ed Avis ed@membled.com
  74. Know what? by Anonymous Coward · · Score: 0

    I'm with you 99%.

  75. A pending addendum... by ChaoticCoyote · · Score: 1

    Within the next few days, I'll be adding an appendix and FAQ to my article, in light of all the interesting comments I've received here and in other forums.

    Here's a big "Thank You" for the intelligent feedback I've received. And as for the doubters and naysayers: This is what peer review all about! If you think hill-climbing, or a completely random serach, or some other tool might work better than my creation, then, by all means, code and post it.

    Competition and diversity are the fuel of evolution, after all.

  76. compile time and more AI suff? by Anonymous Coward · · Score: 0

    i read this article before sumewhere few years
    back... *scratch head*

    really interessting! gcc is a compiler (never
    used it) for c ... hmmm ... anyway would have
    been interessting to note the compile time TOO
    for differen comipler flags used. maybe there's
    correlation between how-long it takes for
    compilation and the actual speed of the program.
    he did mention something about compiled program
    size which also should be taken into concideration.

    back to the compiler ... using a genetic
    algorithem approach to sort out comipler flags.
    dunno sounds like this guy is seriously standing
    at the edge of artificial intelligence. i dunno
    how this compiler flag optimization fits in to
    AI stuff but i def. got this gut feeling while
    reading the article.

    gen. algorithem + compiler(flags) + ? = AI?

  77. This is also being researched at Rice University by morton2002 · · Score: 1


    The AI folks and the Scalar Compiler folks at Rice are working on this project as well. Take a look, and scroll to the bottom for links to academic publications if you're interested.

    Their initial objective was to reduce the power consumption of compiled programs, but notably the GA-discovered compiler flags increase the performance of most programs as well. Additionally they have experimented with a hill-climbing search for a particular program and have discovered that the search space is very bumpy. However the GA can beat the hillclimber by 20% performance in 200 generations (genepool=100, so search 20,000 trials) versus 2.8 million trials in the hillclimber.

  78. Re:This is also being researched at Rice Universit by jacobm · · Score: 1

    I remember Andy McKay working with Keith on this at Rice in the summer of '98. Do you happen to know why the research has been going as slowly as it has? Are they just not very interested in pushing it, or are people just busy with cooler things, or what?

    By the way, nice to see you around. What are you up to these days? Send me an email sometime. My alumni address will still work.

    --
    -jacob
  79. support vector machine by benpark22 · · Score: 1

    A support vector machine is supposed to have no local-minima problem.