Forgot your password?

typodupeerror
Programming GNU is Not Unix IBM Software IT Technology

IBM Releases Open Source Machine Learning Compiler 146

Posted by timothy
from the what-you-meant-to-say-is dept.
sheepweevil writes "IBM just released Milepost GCC, 'the world's first open source machine learning compiler.' The compiler analyses the software and determines which code optimizations will be most effective during compilation using machine learning techniques. Experiments carried out with the compiler achieved an average 18% performance improvement. The compiler is expected to significantly reduce time-to-market of new software, because lengthy manual optimization can now be carried out by the compiler. A new code tuning website has been launched to coincide with the compiler release. The website features collaborative performance tuning and sharing of interesting optimization cases."
This discussion has been archived. No new comments can be posted.

IBM Releases Open Source Machine Learning Compiler

Comments Filter:
  • Automation... (Score:2, Insightful)

    by juanergie (909157) <superjuanelo@gmail.com> on Friday July 03 2009, @01:47AM (#28568681) Homepage Journal

    ... can create stupid humans. Let's embrace technology but beware of falling into ignorance.

  • Oh really? (Score:5, Insightful)

    by zmotula (663798) on Friday July 03 2009, @01:49AM (#28568689) Homepage

    The compiler is expected to significantly reduce time-to-market of new software, because lengthy manual optimization can now be carried out by the compiler.

    Oh, so new software takes too long to build because of lengthy manual optimization? That's news indeed. Even if it did, will the compiler find a better polygon intersection algorithm for me? Will it write a spatial hash? Will it find places when I am calculating something in a tight loop and move the code somewhere higher?

  • by TinBromide (921574) on Friday July 03 2009, @01:52AM (#28568703)

    The compiler is expected to significantly reduce time-to-market of new software, because lengthy manual optimization can now be carried out by the compiler.

    How about this: The coders take the time they would have used to "optimize" and instead better document, test, and debug the code. Instead of same quality, less money, make it better quality, same money? You know that the developer isn't going to charge less money for a new product because it took them less time to get it out the door.

  • Dumb Summary (Score:5, Insightful)

    by QuantumG (50515) * <qg@biodome.org> on Friday July 03 2009, @01:52AM (#28568705) Homepage Journal

    automatically learn how to best optimise programs for re-configurable heterogeneous embedded processors

    That's kinda important to mention no?

  • by walshy007 (906710) on Friday July 03 2009, @02:04AM (#28568763)

    it optimizes the translation of to assembly opcodes. When you code the stuff you type is not in the binary that's compiled/assembled/linked.

    I highly recommend you add a tiny amount of assembly programming dabbling to that list, and you will gain better understanding of how compiler optimization is not a simple affair. There are many ways to do the same thing.

    As for an example of a basic optimization method, removing dead code, code that is in there but never called by the main method.

    Another one is vector optimization, where certain routines or parts of routines where it's suitable use the vector units of a cpu to speed things up a little.

  • Re:Dumb Summary (Score:3, Insightful)

    by mozzis (231162) on Friday July 03 2009, @02:15AM (#28568819) Homepage
    Absolutely. This is not for the normal processors we all know and love, nor is it any good for javascript or python etc. Compilers for C++, C#, java etc. on normal CPUs all have pretty ferocious optimizers already. Not that an attentive human programmer can't make much more of a difference, usually.
  • by sydneyfong (410107) on Friday July 03 2009, @03:14AM (#28569045) Homepage Journal

    Assembly itself is not "hard". The language itself is simple. I'd argue that most of the "hardness" is due to its simplicity. There is almost none of the abstract structures and methods that high level languages provide you, and even for something something as "simple" as calling a function, you'll have to manually push data on a stack, jump to the new location, and then pop back the data afterwards, etc.

    Might be unnecessary for those programmers who has no interest in understanding how the computer actually works, but it's worth a look.

    Disclaimer: I've never really done any assembly programming, but only "dabbled" in it for a bit a few years ago.

  • by tbj61898 (643014) <andreNO@SPAMvellori.it> on Friday July 03 2009, @03:25AM (#28569079) Homepage
    It seems like You're computing a spatial Hash! Would You like to use the fastest subroutine I know or use your own?

    seriously... this post talk about machine learning optimization, will it be like "more stuff You compile, better luck with resulting machine code" ?

    It's like a new GPS navigation software thats not only capable of route optimization but also capable of destination suggestions. "It sounds like You're going to a grocery store to buy pizza... there's a pizza hut round the corner!"
  • by Another, completely (812244) on Friday July 03 2009, @03:26AM (#28569081)

    I agree that it's a good idea to learn assembly / machine language to understand what a compiler is doing, but learning the assembly language of the computer you use at home is not as reasonable a suggestion today as it once was. Learning to code to a 6802 wasn't bad; it only has a few instructions, and it's very instructive (and fun) to find out how many things you can do with just those. I think trying to write for your home PC in assembly is now beyond a beginner exercise though.

    Microcontroller manufacturers often provide emulators and assemblers for their products, so you might download one of those to try. Then, when you get the hang of it, maybe a developer board and some 7-seg LEDs to build a calculator or something. Coding to this year's Intel chips is best left to the compilers and the mystics.

    Anybody out there know a good emulator for teaching assembly programming?

  • Re:Automation... (Score:4, Insightful)

    by piojo (995934) on Friday July 03 2009, @03:44AM (#28569167)

    if you take the thinking out of a process and let a process/machine/program do all the thinking, your mind will inevitably get lazy and your work will suffer over time

    I think that it could very well free your mind to think about better things. Build systems are a good example. If I had to manually compile each translation unit, I couldn't spend as much time thinking about the code.

  • Re:Oh really? (Score:2, Insightful)

    by Fullers (1590483) on Friday July 03 2009, @03:54AM (#28569217)
    Highly optimized software does take a long time to build because of manual optimization. Plus, if anything changes, that optimization might need to be done again. And yes, a good compiler will move that loop for you.
  • Re:Automation... (Score:3, Insightful)

    by h4rm0ny (722443) <h4rm0ny@tard d e l l . n et> on Friday July 03 2009, @04:21AM (#28569337) Journal

    Abstraction is one of the foundations of higher thinking. There is something to be said for being able to do lower-level tasks, but you don't concern yourself with the internals of them when you want to treat them as discrete objects. Nobody thinks about the construction of an AND gate when they're designing something that uses AND gates. Nobody thinks about the internal workings of a method or function when they simply want to call it. In every area, the process is the same: You first learn the basic components, and then you assemble them into a composite of those components (whether a function, a muscial chord, a template in an MVC or whatever), and operate on a higher level.

    It's been too many years since I've really worked with compilers directly, but to me this looks impressive. Can someone who is more up to date with the field tell me if this is an appropriate moment to go: "Woah!" Because I feel like it might be.
  • Re:Automation... (Score:2, Insightful)

    by michelcolman (1208008) on Friday July 03 2009, @06:51AM (#28569993)
    Most programmers stopped "thinking about the code" long ago and just slap together a bunch of libraries. That's why my DVD/HD player takes about 30 seconds loading operating systems (I hope that last 's' is an exaggeration, but I fear it may even be correct) before it will even eject a disc. As for the supposedly huge performance improvement of 18% (that's all?!), I have regularly hand-optimised code that ran more than twice as fast.
  • Re:Automation... (Score:3, Insightful)

    by aaribaud (585182) on Friday July 03 2009, @06:58AM (#28570013)
    Joke aside, as for any rather absolute statement, there is only a part of truth both in the statement and in its opposite. Granted, automation does not necessarily lead to a lesser [level of intelligence in] society. However, not everything that automation can do must necessarily be done by automated means. For instance, calculators have automated calculus. I for one, welcome our key-laden overlords from arctangent, because I rarely have to compute arctangent and find it handy to have a calculator to do it for me. However, calculators can also do simple arithmetic like additions and multiplications ; and this can (and does, in the experience I can gather from my immediate vicinity) lead to a lessening of people's capability at doing additions and multiplications -- operations which are much more frequent than arctangents.
  • Re:Oh really? (Score:3, Insightful)

    by John Hasler (414242) on Friday July 03 2009, @08:20AM (#28570365) Homepage

    Thanks. That is very, very different from what the summary says.

  • by SpinyNorman (33776) on Friday July 03 2009, @10:53AM (#28571757)

    I always thought that testing and debugging were the lengthy manual steps

    Not if you wrote the code well! ;-)

    Seriously, as someone who's been doing this a long time (since '78, professionally since '82), and who is still at the top of his game, I nowadays spend *very* little time on debugging since it works first time - even the complicated multi-threaded, mutex type of stuff which is what I primarily write nowadays. After a while you stop making mistakes!

    But, anyways, it seems the main target for this adaptive optimization (from TFA) is embedded usage for novel targets. i.e the latest smart phone or maybe games console, where you don't have the typical "essentially infinite for the needs of the application" CPU resources of a desktop app, and you don't have the luxury of a fairly static target (PC architecture) that has had the benefit of years of code generator hand optimization. For this target usage, someone (either you or the compiler) may need to perform extensive low-level optimizations (in addition to the high level design and choice of algorithms), and it therefore helps if an off-the-shelf compiler is available that can do this, and does not rely on the code generator having to be hand-optimized for the hardware architecture you're targeting.

Many are called, few volunteer.

Working...