IBM Releases Open Source Machine Learning Compiler

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."

Comments

"Learning"

[quantum bit]

Joshua? Is that you?

Re:"Learning"

[ocularDeathRay]

Nope... its Mycroft Holmes

They kept hooking hardware into him--decision-action boxes to let him boss other computers, bank on bank of additional memories, more banks of associational neural nets, another tubful of twelve-digit random numbers, a greatly augmented temporary memory. Human brain has around ten-to-the-tenth neurons. By third year Mike had better than one and a half times that number of neuristors. And woke up.

Some logics get nervous breakdowns. Overloaded phone system behaves like frightened child. Mike did not have upsets, acquired sense of humor instead. Low one. If he were a man, you wouldn't dare stoop over.

TANSTAAFL bitches.

Re:"Learning"

[MichaelSmith]

So we keep out eyes open for funny-once jokes?

Re:"Learning"

[Mycroft_VIII]

There are non visual funny-once jokes

Mycroft

Automation...

[juanergie]

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

Re:Automation...

[Anonymous Coward]

I fail to see how automation leads to lower IQ scores. Care to elaborate? How does stepping up the pace, and eliminating tedious, mundane jobs, lead to a lesser society? I call FUD.

Re:Automation...

[TinBromide]

I fail to see how automation leads to lower IQ scores. Care to elaborate? How does stepping up the pace, and eliminating tedious, mundane jobs, lead to a lesser society? I call FUD.

wooooosh.
See idiocracy. Go out and watch it. I'll wait








Saw it? Good, now you should get the joke.

Re:Automation...

[Fluffeh]

I would argue. Either you get it without needing to watch the movie simply by being surrounded by people who in their day to day existence simply follow instructions blindly "because they have to" or you won't get it - whether you watch the movie or not.

As for the GP, I believe he is mixing two things incorrectly:

fail to see how automation leads to lower IQ scores
and
lead to a lesser society

Lower IQ scores don't immediately mean a lesser society, but 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

Re:Automation...

[Anonymous Coward]

That's what the professors want you to believe! There is absolutely nothing in our history that suggests that automation is harming our society, creating a lazy, good for nothing, sub-standard, citizen. Again, I call FUD. You're suggesting that calculators have harmed society. On the contrary, they and computers have excelled society into a new era of information technology. You can call me lazy for using a calculator, but I guarantee you my work isn't suffering from its use.

Re:Automation...

[piojo]

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:Automation...

[ozmanjusri]

but beware of falling into ignorance.

Whoops.

http://www.foxnews.com/

Re:Automation...

[h4rm0ny]

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...

[michelcolman]

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...

[aaribaud]

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:Automation...

[Anonymous Coward]

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

Impoverished people have a higher IQ than wealthy people. Use it or lose it.

Re:Automation...

[LingNoi]

http://xkcd.com/603/

Re:Automation...

[m.ducharme]

Oblig. XKCD: 603: Idiocracy

Re:Automation...

[tkinnun0]

See idiocracy. Go out and watch it. I'll wait

The main tenets in Idiocracy were that IQ is hereditary and those with less IQ spend more time procreating. Automation was merely allowing their society to function, barely. IOW, I don't see your point. Can you elaborate, please?

Re:Automation...

[hemorex]

Nobody thinks about the internal workings of a method or function when they simply want to call it.

And this would be why people can't fricking troubleshoot.

Re:Automation...

[Anonymous Coward]

Idiocracy was based on the fact the lowest common denominators kept breeding faster and faster than everybody else.

Ever see a black momma with 13 kids? That was the main point of idiocracy.

Re:Automation...

[Anonymous Coward]

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.

You, Sir, are the perfect example for why stupidity hasn't anything to do with automation. It's 18% average.

Re:Automation...

[Anonymous Coward]

j' accuse racist!

The only mom's I'm seeing nowadays with a 13 unit brood is Octo-mom & the stupid divorced couple. They're white.

Re:Automation...

[h4rm0ny]

And this would be why people can't fricking troubleshoot.

I said "simply want to call a function". If you're debugging, then you look at it. If you're designing code, you just use the function. The very existence of a function instead of endlessly repeated code is an example of the principle of abstraction.

Re:Automation...

[Sinbios]

You probably aren't as good at mental arithmetic as someone who's had to do math without calculators though. The question is whether that is a problem. I think the non sequitur here is the subtle implication that not possessing certain skillsets, such as mental arithmetic, would lead to humans becoming lazy and eventually the downfall of society.

I'd say that by examining the average person's mastery of stabbing a sharp stick into a neighbourhood critter and then making food out of it vs. the "lesserness" of society in modern times as compared to say, the Stone Age, we can find this implication to be factually false.

Re:Automation...

[Nutria]

You probably aren't as good at mental arithmetic as someone who's had to do math without calculators though. The question is whether that is a problem.

Or at remembering phone numbers as someone who doesn't rely on their cell phone's address book.

The bottom line is that simple exercises tasks "oil" the brain, keeping it functioning smoothly, and ready for when you do need to be creative.

Re:Automation...

[Sinbios]

That doesn't follow either; repeatedly performing some task familiarizes your brain to that particular task. While performance in similar tasks (say, remembering people's zip codes for someone who have had to remember phone numbers as in your example) might be improved it doesn't necessarily make one more creative in general.

Re:Automation...

[piojo]

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.

True. I've read that a hand optimization of less than 50% sometimes isn't worth a developer's time, because users won't really notice it. (Obviously that doesn't apply to situations were a ton of small optimizations are needed, and the application will speed up over time.)

Re:Automation...

[QuestionsNotAnswers]

This was part of the .iq war.

On average, IQ scores have been decreasing over the years.

Unfortunately those bastard conspiring europeans keep "renormalising" IQ's, so the graph of the average IQ over time remains a straight line (absurd though it seems).

One of their other techniques is detecting highQ people and removing them from the gene pool. Renormalisation is a modern version of the nazi euphemisation programme.

Oh really?

[zmotula]

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?

Re:Oh really?

[lee1026]

The last one is actually quite possible, and indeed is a huge area of compiler research.

Re:Oh really?

[Tinctorius]

Will it...

run Linux?

Re:Oh really?

[Rosco P. Coltrane]

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?

The real question in everybody's mind is: will it blend?

Re:Oh really?

[Thanshin]

Oh, so new software takes too long to build because of lengthy manual optimization?

It depends on your definition of optimization.

In my current project we have about twenty guys "performing lengthy manual optimizations". It sounds quite better than having twenty guys "correcting the absolute crap that wouldn't even compile".

Re:Oh really?

[Fullers]

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:Oh really?

[Anonymous Coward]

Oh wow, you're so *great*. You know all those amazing words! I'm impressed to say at least.

Re:Oh really?

[TheRaven64]

Will it find places when I am calculating something in a tight loop and move the code somewhere higher?

Look up loop-invariant code motion. This has been supported in shipping compilers for a while.

Re:Oh really?

[jcupitt65]

Read the article, that's not what this does. This is a project to automatically generate optimising compilers for custom architectures. The summary is a little unclear :-(

It reduces time to market because you don't have to spend ages making an optimising compiler for your custom chip.

Re:Oh really?

[martas]

eventually, it'll probably re-write all of the code to do everything better, and without mistakes. but that's in about 100 years or so (probably more). for now, be happy with what you've got.

Re:Oh really?

[ShakaUVM]

>>Oh, so new software takes too long to build because of lengthy manual optimization?

I indeed spend 18% of my coding time typing "gcc -O3".

Re:Oh really?

[kwikrick]

No, this 'learning' compiler only learns how to optimally translate C++ statements to machine level operations. It cannot choose high level algorithms for you. And the reason that such a learning compiler is useful is not to help lazy application programmers, but because developing new, optimised compilers for the many different processors and platforms out there (think computers, mobile phones, embedded systems, etc) is time consuming.

Re:Oh really?

[John Hasler]

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

Re:Oh really?

[DiegoBravo]

That kind of confusing summaries are too frequent that sometimes I go to RTFA!

Seriously, the summaries should be subject to moderation too (I don't know if the firehose thing lets do that.)

Re:Oh really?

[maxwell demon]

Oh, so new software takes too long to build because of lengthy manual optimization?

Yes. That's why most manuals are not very optimized. So the next time you think a manual is close to useless, don't complain. It's in order to save you time in the building process.

Re:Oh really?

[AceJohnny]

While the the summary is wrong on this subject, I can tell you that, yes, manual optimization is part of our work and can slow down the release of our product. If we told a customer that yes, we will be able to do VGA 30FPS H.264 encode. Code optimization on our custom core is going to take some time and effort. I work in the embedded multimedia field.

I think we're going to be very, very interested in this project.

Re:Oh really?

[Ant P.]

Will it find places when I am calculating something in a tight loop and move the code somewhere higher?

No, and it doesn't need to, since vanilla GCC has had that optimisation for years.

Re:Oh really?

[SpinyNorman]

Will it find places when I am calculating something in a tight loop and move the code somewhere higher?

Quite likely, yes.

Even a dumb optimizer will love loop invariant code outside of a loop, and maybe partially unroll the loop to make the looping overhead less. The latest gcc will even automatically vectorize the loop for you to execute a number of iterations in parallel using SSE/etc instructions if it's a suitable candidate.

e.g.

You may write:

for (int i = 0; i < 10; i++) {
  a[i] = (2 * b) + c;
}
 
But the compiler may generate:
 
t = (2 * b) + c; // Loop invariant code moved outside of loop
for (int i = 0; i < 10; i += 2) {
  a[i] = t1; // Loop unrolling to halve number of iterations / loop overhead
  a[i+1]= t1;
}

That's just to illustrate the type of transformations that compilers already do - no exactly what they might generate, which is hopefully rather better!

Re:Oh really?

[ET3D]

In my experience, optimisation does take a lot of time.

One way that optimisation takes time is straighforward: people use profilers (or code reviewer, common sense, or whatever) to find bottlenecks and fix them. This is common, regardless of the app.

The other is less obvious: people design their code to work more quickly, and sacrifice readability. Most programmers I know practice what I call "premature optimisation" -- sometimes wrong ones. For example, one programmer I knew used shifts for all multiplications by powers of 2. This was not only hard to read but also causes bugs due to operator precedence. I later showed him an article that told that on modern processors shifts are a lot slower than multiplication. Another common practice in C/C++ is to loop on pointers, instead of use an index into the array. All these practices which are meant to optimise code a little (when it's usually not needed) can cost a large amount of time, because they make the code more buggy, harder to debug and harder to maintain.

Re:Oh really?

[ais523]

I've made Firehose comments before now pointing out deficiencies in the summaries; however, they seem to have been ignored when the story was actually posted...

Oblig.

[fuzzyfuzzyfungus]

"My GNU is a neural net processor, a learning compiler..."

Re:Oblig.

[jd]

You do realise what you've gone and done, don't you? They'll have to change the GCC acronym to mean the Gnu Creative Compiler, now.

Less time? How about same time, better product?

[TinBromide]

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.

Re:Less time? How about same time, better product?

[Anonymous Coward]

How about this: The coders take...

How about this: the coder's employer computes the time saved through automation and pockets the difference and/or lowers his bid.

How about this: the coder's employer hires a less talented/experienced/educated coder to replace his high cost coder and pockets the difference and/or lowers his bid.

Reality sucks.

Re:Less time? How about same time, better product?

[Thanshin]

Instead of same quality, less money, make it better quality, same money?

Yes, that always works.

I'm asking my client right now whether he wants a quality product in february or a barely working one in october. Let's see what happens.

Re:Less time? How about same time, better product?

[rawler]

That's what I'm afraid of. The big performance wins have never been in the final optimization-phase, but in doing a design aimed for performance, utilizing better algorithms to reduce resources spent.

Good thing programmers are now encouraged to think even less about that. "Oh, the compiler will probably optimize that away, and it's more readable like this."

Re:Less time? How about same time, better product?

[Esc7]

From my experience I can already tell you:

"Good enough product in November (early November!)"

Re:Less time? How about same time, better product?

[Lehk228]

bullshit. he's going to want it by august and it had better work!!!!11111eleventy!

Re:Less time? How about same time, better product?

[maxwell demon]

If you ask hin in december, he certainly will opt for the quality product in february. :-)

Re:Less time? How about same time, better product?

[x78]

The coders take the time they would have used to "optimize" and instead better document, test, and debug the code

This sounds absolutely bloody awful!
Optimization is so much more fun that testing and documentation, the most boring elements in the whole of computer science!

Dumb Summary

[QuantumG]

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

That's kinda important to mention no?

Re:Dumb Summary

[mozzis]

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.

Re:Dumb Summary

[Thanshin]

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

That's kinda important to mention no?

Well, it could be optimizing for unconfigurable homogeneous strawberry pudings.

It'd be quite more impressive, from a culinary standpoint.

Re:Dumb Summary

[Fullers]

Developing a good optimizing compiler quickly is very important when the hardware can change very easily, which is why it works well for reconfigurable processors. However, the results are impressive even on static architectures like x86 and PPC.

Re:Dumb Summary

[Fnord666]

No, lazy editors. The submission is what the submission is. It is up to the editors to select meaningful submissions that accurately reflect the story. Any failure of the submission to do that is a failure on the part of the editorial staff, be it through laziness or incompetence.

Few Questions for any programmers

[contr0l]

I'm not a programmer at all, but have dabbled in a few different languages, as I find programming very interesting. (Got pretty good at mirc scripting when I was younger, which lead to visual basic, C++, and now C# dballing that nvr leads to anything). This said, I have a basic knowledge of programming in general. My question is, What things can a compiler do to your code to 'optimize' it for you? I would think majority of any good optimizations might require rethinking whole methods of doing things and/or recoding chunks of code. If the compiler tries to do this, wouldn't it likely screw your code up? Or how would it know 'what' your really trying to do? Outside of removing comments, can someone please explain other Basic optimization methods, (I say basic, like removing comments - You know that cant screw anything up), that a compiler can do on your code that wont screw it up? Thanks in advance.

Re:Few Questions for any programmers

[EvanED]

What things can a compiler do to your code to 'optimize' it for you?

Check out the Wikipedia article on optimization for some examples.

In brief, some of the more common ones are things like substituting known values for expressions (e.g. x = 3; y = x + 2; can be changed to x = 3; y = 5;), moving code that doesn't do anything when run repeatedly outside a loop, and architecture-specific optimizations like code scheduling and register allocation. (E.g. with no -O parameters, or -O0, for something like "y = x; z = x;" GCC will generate code that loads "x" from memory twice, once for each statement. With optimization, it will load it once and store it in a register for both instructions.)

If the compiler tries to do this, wouldn't it likely screw your code up?

There are cases where optimizations will screw something up. One example is as follows. It's considered good security practice to zero out memory that held sensitive information (e.g. passwords or cryptographic keys) to limit the lifetime of that data. So you might see something like "password = input(); check(password); zero_memory(password); delete password;". But the compiler might see that zero_memory writes into password, but those values are never read. Why write something if you never need it? So it would remove the zero_memory call as it's useless code that can't affect anything. So it removes it. And your program no longer clears the sensitive memory.

This was actually a bug in a couple crypto libraries for a while.

Re:Few Questions for any programmers

[walshy007]

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:Few Questions for any programmers

[contr0l]

I see, thanks for the detailed explanation, I hadn't thought of those. I like the first example, and the fact that the compiler can recognize your code and make that replacement confidently. Thats just cool.

Re:Few Questions for any programmers

[walshy007]

bah, slashdot ate part of what I wrote, in the first line it is meant to be.

it optimizes the translation of "insert high level language here" to assembly opcodes

Re:Few Questions for any programmers

[contr0l]

Again, didnt even cross my mind. thanks alot. I would also be interested in taking a look at assembly, but all I hear about it is that is very hard to grasp, and not necessary with all the languages out there. But I will deff take a look into it to get a better idea.

Re:Few Questions for any programmers

[Anonymous Coward]

Classic examples:

• Replace a mod (e.g. x % 32) with a bitwise-and (e.g. x & 31) when the divisor is a power of two. Nearly every compiler does this now, but twenty years ago it was a common manual optimization trick.
• Replace a branch with an arithmetic operation that yields the same result.

  i < 0 ? -i : i

  vs

  cdq
  xor eax, edx
  sub eax, edx

Re:Few Questions for any programmers

[walshy007]

in regards to learning assembly, if you run linux, the best book I can recommend is Programming from the ground up it's licensed under the GNU free documentation license, and in my honest opinion is likely the single best book for anyone who has no idea that wants to start, I already had some clue so skipped the first two thirds of the book, but read it for shits and giggles later and found it to be a very easy to grasp book.

To this day if I forget minor details about things I pick that back up and re-read it a bit :)

Re:Few Questions for any programmers

[EvanED]

Replace a mod (e.g. x % 32) with a bitwise-and (e.g. x & 31) when the divisor is a power of two.

Another very similar one, and one that comes up more commonly, is the replacement of a multiplication or division by a constant by a series of additions, subtractions, and bitshifts.

For instance, "x/4" is the same as "x>>2", but the division at one point in time (and still with some compilers and no optimization) would produce code that ran slower. Some people still make this optimization by hand, but I'd say it's almost certainly a bad idea nowadays, at least in the absence of information that your compiler isn't optimizing it and that it would be important.

(You can combine operations too. x*7 is the same as x3-x, x*20 is the same as x4 + x2, etc.)

Re:Few Questions for any programmers

[EvanED]

(You can combine operations too. x*7 is the same as x3-x, x*20 is the same as x4 + x2, etc.)

That should be
  x*7 == x << 3 - x
  x*20 == x << 4 + x << 2

Slashcode (somewhat reasonably) ate my <<s.

Re:Few Questions for any programmers

[BlackSabbath]

Before you get flamed to death by some idiot, you've got realise that compilers translate a higher-level language into a lower-level one, typically into machine instructions (or in the case of Java and .NET, virtual machine instructions), turning source code into executable form. Interpreters on the other hand, execute each statement of the language directly (effectively forming a virtual machine for that language).

Naive compiler translations can be functionally correct but sub-optimal with respect to runtime performance, memory/disk footprint etc. Compiler optimisation is the effort to make this translation as optimal as possible with respect to some variable(s) e.g. performance, size

What you are thinking of sound like source code optimization. There are various interpretations of this but to my mind, this means a combination of optimal algorithm selection and optimal algorithm implementation. Note that complex algorithms can be decomposed into smaller common algorithms e.g. a sort routine may be part of some higher-level algorithm, the sort-routine may be optimised independently of the higher-level routine.

Check out: http://en.wikipedia.org/wiki/Compiler_optimization

Re:Few Questions for any programmers

[Anonymous Coward]

Did something else eat your parentheses?

Re:Few Questions for any programmers

[EvanED]

No, I just got the precedence wrong. ;-)

In my post, pretend that << has a higher precedence than + and -.

Re:Few Questions for any programmers

[sydneyfong]

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.

Re:Few Questions for any programmers

[symbolset]

What things can a compiler do to your code to 'optimize' it for you?

The correct answer to this question is... it depends. No matter how advanced your compiler is it can't select the correct algorithm for you. If you're ordering your lists with a bubble sort instead of some kind of btree, there's nothing the compiler can do to help you except deliver the best O(n^2) sort it can. A truly artistic programmer can transcend all of the optimizations this compiler might achieve, by several orders of magnitude.

But if you're the kind of code geek that Microsoft hires, yeah, you might get a version of Windows that boots to a usable desktop in under five minutes.

Re:Few Questions for any programmers

[Anonymous Coward]

There are cases where optimizations will screw something up. One example is as follows. It's considered good security practice to zero out memory that held sensitive information (e.g. passwords or cryptographic keys) to limit the lifetime of that data. So you might see something like "password = input(); check(password); zero_memory(password); delete password;". But the compiler might see that zero_memory writes into password, but those values are never read. Why write something if you never need it? So it would remove the zero_memory call as it's useless code that can't affect anything. So it removes it. And your program no longer clears the sensitive memory.

And it was the crypto library's fault, not the compiler's fault. Most languages worthy of doing crypto programming in have a facility to say ~"don't optimize this". An example: in C, the keyword "volatile" instructs the compiler that the field may be changed at any time, and thus all reads/writes must take place and must do so atomically [unfortunately, the C spec doesn't specify "in order" for volatile fields, but I digress].

Re:Few Questions for any programmers

[Another, completely]

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:Few Questions for any programmers

[Anonymous Coward]

The C spec doesn't require atomicity of volatiles, but it does require in order. So you've got it the wrong way round!

Re:Few Questions for any programmers

[EvanED]

This is sort of a nit and not really germane to the current discussion about optimization, but...

An example: in C, the keyword "volatile" instructs the compiler that the field may be changed at any time, thus all reads/writes must take place and must do so atomically

"Atomically" isn't the right word for what "volatile" means. Basically, "volitile" specifies that reads should always come from memory, and writes should always go to memory. (This is as opposed to a register.) So for instance, if you had a loop where "x" was unchanged by the loop but you wanted to force it to be reloaded each time (because it might be changed by another thread for instance) you can declare "x" as "volatile int x" or whatever.

I think it is the case that accesses to volatile variables can't be reordered too.

There isn't really any guarantee of atomicity though; "x++" might not actually increment x (or might cause lost updates), and I suspect that a conforming implementation might be able to update, say, both words of a two-word integer independently on an operation (even though that could lead to races in multithreaded code and stuff like that).

Re:Few Questions for any programmers

[ZerothAngel]

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

SPIM is a possibility. It was used in a few courses (operating systems, compilers) at UCB some years ago. (Don't know if it's still used.)

Re:Few Questions for any programmers

[TheRaven64]

Another very similar one, and one that comes up more commonly, is the replacement of a multiplication or division by a constant by a series of additions, subtractions, and bitshifts.

ARGH! Mod parent down! Please, please, please don't ever repeat this again to people asking things about optimisation. On most modern computers, shifts are slow. They are often even microcoded as multiplications, because they are incredibly rare in code outside segments where someone has decided to 'optimise'. Even when they're not, a typical CPU has more multiply units than shift units and the extra operations needed from the shift and add sequence bloat i-cache usage and cause pipeline stalls by adding adjacent dependencies. The 'optimised' version you describe will almost certainly be slower than the version using the multiply instruction.

I did some benchmarks with a Core 2 Duo a few months back of this exact optimisation and discovered that in the simplest case the add-and-shift version was as slow as the multiply, in any more complex case it was slower. There's a reason why GCC hasn't done this for some years.

Re:Few Questions for any programmers

[TheRaven64]

As a trivial example, one of the benchmarks I use for testing my Smalltalk compiler is a naive calculation of the Fibonacci sequence. With my first version, which did very little optimisation, it was much slower than GCC-compiled Objective-C (it's now about 50% slower). If, however, I compared a naive implementation in Objective-C to a more intelligent (O(n)) implementation in Smalltalk, the Smalltalk implementation was faster for all n greater than 30, and when you got closer to 40 it was several orders of magnitude faster. In most cases, a good algorithm with a bad compiler beats a good compiler with a bad algorithm.

Re:Few Questions for any programmers

[Arlet]

Even faster is the closed form solution:

http://mathworld.wolfram.com/BinetsFibonacciNumberFormula.html

Re:Few Questions for any programmers

[smallfries]

No that's not true. A shift instruction has a one cycle latency and 1/2 cycle throughput on the Core2 / Core2-Duo. An add instruction also has a one cycle latency and 1/3 cycle throughput on the Core2-Duo.

The integer multiplier on the Core2-Duo has a 4-cycle throughput and an 8-cycle latency. So in a "simple" case like x*9 = (x<<3)+x the optimisation would take 2 cycles, and the straight mul would take 8. In more complex cases the individual shifts will pipeline for more of a benefit. Only in cases where (t/3)+ceil(lg(t)) >= 8 will the optimisation be as slow as the multiplier for an expansion of t terms (obviously logs in the base 2 as the additions will form a tree). On x86 lacks of registers will kill this optimisation before the cost of the instructions exceeds the multiplier cost.

And yes, I've also benchmarked the code to test it on a Core2-Duo, and my results match Intel's published figures and Agner Fog's data tables so I suggest you recheck your benchmark.

Getting back to the article, the Milepost work isn't really suitable for this type of optimisation anyway. They try and optimise the compile-time by tuning the optimisation flags. For this type of low-level tuning of code the approaches in Program Interpolation, Sketching or PetaBricks would be more appropriate.

Re:Few Questions for any programmers

[cbhacking]

Yeah, it's still used. Of course, being a MIPS emulator, it's not exactly going to turn you into an amazing x86 optimizer, but it's a good ISA for learning simple assembly.

Re:Few Questions for any programmers

[SwabTheDeck]

Similarly, you can do integer division or multiplication by 2 as a bit shift, since a bit shift is a far less costly operation:

SHR EAX,1
instead of
DIV EAX,2

Re:Few Questions for any programmers

[michelcolman]

Another, more common problem in optimization is floating point math. For example, "T = S+Y; C = (T - S) - Y;" may be "optimized" to "T = S+Y; C = 0;" while the whole point of the calculation was that C contained the rounding error!

Re:Few Questions for any programmers

[Anonymous Coward]

"Atomically" in the sense of C means that either the update happens, or it doesn't: the machine is not left in a "hanging" state where half an update is applied to the variable. All writes and reads are applied. And yes, volatile reads and writes can be reordered (think of two threads attempting to write to a volatile variable; the compiler has no ability to say which write comes first, it is entirely runtime and machine dependent. They can even be reordered by the processor itself in many cases. Intel has gobs of information on the "correct" and best-performance yielding sequences of updates to volatile data/addresses for their architectures, e.g., but even the most naive of implementations can usually get pretty solid performance numbers).

This is entirely different from higher-level languages (C#/Java/etc) which use "volatile"/atomically in terms of machine synchronization, for which C is entirely oblivious to (in all cases, it is provided as a library or extension to the C specification which is entirely dependent on syscalls or atomic update routines). Volatile gives no threading guarantees once so ever in C, differently from the threading-aware languages mentioned above.

Re:Few Questions for any programmers

[TheRaven64]

Note that microbenchmarks here don't tell the whole story, because the increase in cache churn, register pressure, and inter-instruction dependencies also slow things down. When you issue a set of shift and add instructions, each one has to complete, in order, before the next can start. With a multiply, this can be overlapped with load and store operations. A well-designed microbenchmark will show this to some degree, but in code where the multiply is close to other instructions it becomes even more obvious.

In more complex cases the individual shifts will pipeline for more of a benefit

This is absolutely and completely wrong. The dependencies between the shifts and adds mean that you get absolutely no benefit from pipelining; each one has to complete before the next can be issued. Worse, you cause a pipeline stall because you've just filled up the CPU's re-order buffer with shifts and adds and so you don't get any benefit from out-of-order execution either. Or from the chip's superscalar architecture; you can run several independent operations in parallel, but this sequence has to execute sequentially, giving about the worst case possible for throughput.

Don't just read the numbers from the architecture reference without understanding the chip design. They would give the performance you claim if the C2D was a single-pipeline, in-order CPU. They do not for an out-of-order superscalar design.

Re:Few Questions for any programmers

[Karellen]

"compilers translate a higher-level language into a lower-level one"

Not always.

Actually, I'm fuzzy on which of Java or Javascript would be considered higher- or lower-level. It's not clear-cut, and could probably be considered more of a "sideways" shift than "downwards".

Re:Few Questions for any programmers

[maxwell demon]

And yes, volatile reads and writes can be reordered (think of two threads attempting to write to a volatile variable; the compiler has no ability to say which write comes first, it is entirely runtime and machine dependent.

Multithreading isn't part of the C specification. Volatile accesses may not be reordered in a single thread. Example:

int i;
int j;
volatile int vi;
volatile int vj;
 
i=1;
j=2;
vi=3;
vj=4;

The compiler is free to change the order of the i and j assignments, or even move the assignments of i and/or j to after the assignments of vi and vj. However the compiler may not issue the write to vj after the write to vi (that's important f.ex. in device drivers; vi and vj might actually be memory-mapped I/O ports, and writing to vi might trigger some action which changes the meaning of writing vj).

Re:Few Questions for any programmers

[maxwell demon]

At least in C an C++ this optimization would not be allowed (some compilers might do it anyway, though). Optimizations are not allowed to modify the observable behaviour (which essentially means I/O and reads/writes from volatile variables). That's known as the as-if rule (the program must behave as if it followed the rules exactly).

In C++, there are some exceptions where optimizations are allowed even if they change the observable behaviour, but they are only concerned with copy constructors, not with floating point math.

Re:Few Questions for any programmers

[maxwell demon]

I guess you wrote <insert high level language here> without replacing < and > with &lt; and &gt;

Re:Few Questions for any programmers

[smallfries]

This is absolutely and completely wrong. The dependencies between the shifts and adds mean that you get absolutely no benefit from pipelining; each one has to complete before the next can be issued. Worse, you cause a pipeline stall because you've just filled up the CPU's re-order buffer with shifts and adds and so you don't get any benefit from out-of-order execution either.

You've misunderstood what I said - there is a benefit from independent shifts being pipelined. So consider the case where I want to compute x*10: this is split into a shift by 3 and a shift by one. If I use a movl to copy the value into a second register then these two shifts can both be executed in parallel as they have independent operands. Unlike most ALU instructions on the Core2-duo you cannot execute a third in parallel because of a pipeline restriction on the shift. But you can observe a 0.5 cycle throughput. So the cost of two shift instructions and a single add to merge the results is 2 cycles total. This is no more expensive in terms of cache or registers than the multiply and can be a win in many contexts. As the maximum throughput of the multiply unit is 4 cycles and this can only be achieved by swapping values in and out of eax/edx to force renaming there are a lot of places where the shift sequence is still more efficient.

I'm not just reading numbers from the reference. I'm in the process of writing a paper on high precision code profiling, and the machine that I'm working on has a Core2-duo processor.

Re:Few Questions for any programmers

[DavidTC]

Um, the 'shift' from Java to Javascript would be considered 'porting into another language'.

Re:Few Questions for any programmers

[SpinyNorman]

On most modern computers, shifts are slow. They are often even microcoded as multiplications.

You're right to say that recoding a multiplication as a combination of adds and shifts is likely to be a loss since multiplication is so fast, and since the extra instruction fetches (memory accesses, decode overhead) are going to kill it!

However, you're wrong about shifts being slow. Ever since the early days shifts are implemented by a "barrel shifter" can can shift by an arbitrary N bits in a single clock cycle. I very much doubt (although I don't actually know) that modern CPUs with their massive transistor counts have decided to save a few transistors by giving up this efficient implementation.

Re:Few Questions for any programmers

[tcgroat]

Another one comes up in embedded programming. Optimizing compilers assume that a variable that hasn't been written to inside a loop won't change inside that loop, so its evaluation is moved outside the loop to optimize for speed. But if that variable is changed by an external influence (an interrupt service routine, timer, input pin status, etc.) the optimized code will never see it. For example: while (DataNotReady) delay(); /* yes, there are better ways but this saves code space in memory-limited microcontrollers */ can be optimized to evaluate DataNotReady only for the first pass of the while loop, so it never exits if data isn't ready. The ISR changes the flag, but the while loop doesn't see it. That's why embedded compilers include ways to disable specific optimizations that break this type of code.

Re:Few Questions for any programmers

[rockmuelle]

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

CorePy (www.corepy.org), while not an emulator, is probably the easiest way to learn assembly. It's a complete environment for assembly-level programming using Python and supports all the major platforms (x86[_64]/SSE, PPC/VMX, Cell SPU, ATI GPUs).

Instead of using inline assembly, CorePy represents all assembly instructions as Python objects, leading to a very natural syntax and also enabling some really interesting methods for generating assembly code using Python as the meta-programming language.

Check it out! :)

-Chris

Re:Few Questions for any programmers

[tlhIngan]

On most modern computers, shifts are slow.

I assume you mean on x86 architecture. There are architectures where it's faster to do a shift, ARM being a very popular one in number of cores sold. On ARM, operands pass through a barrel shifter that allows them to be shifted almost any which way during instruction execution.

Thus, a lone shift operation actually wastes time on ARM because it's translated to a move instruction. But a shift+add can be done in one instruction (rather than 2) because the shift is done as part of operand fetching. This may even make certain optimizations "bad":

E.g., given the code sequence:
          a = (b 4) + 1;
          c = (b 4) + 3;

can be improperly optimized to a shift, then two adds. A proper optimization is to not do any - generate two adds directly, because the shift can be handled during prefetch.

Re:Few Questions for any programmers

[chrono325]

SPIM? Ack! I took (and later was a teaching assistant for) a class which used SPIM for teaching MIPS assembly. It is a god-awful program. It is horribly outdated and hasn't been updated in years and has the most confusing UI I've ever seen in any program ever.

Some students wrote a replacement with a reversible debugger (can go forwards and backwards through the code) here:

http://mipscope.sourceforge.net/

Re:Few Questions for any programmers

[metaforest]

That's why embedded compilers include ways to disable specific optimizations that break this type of code.

Declaring a variable 'volatile' tells the compiler not to assume that it knows what value the variable had last, thus disabling said optimizations.

This happens most often in embedded situations for ISRs and code that reads hardware registers.

Re:Few Questions for any programmers

[True Grit]

If I use a movl to copy the value into a second register

At which point we're talking about inline assembly at least, not a "simple" in-compiled-language optimization, e.g. C mul expr -> C shift/add expr, which is what the entire preceding thread has been talking about. And if you're talking about writing code in assembly, that also has no place in a thread about *compiler* optimizations. :)

Never mind that you're now using another register, which depending on the specific circumstances, may be a bad thing, e.g. the compiler might find a better use for that register than your use of it as a temp, and this is especially true on the x86 arch with its relative paucity of GP regs.

See, this is an example (an optimization that might have an unintended regression by using a valuable GP reg - preventing the compiler from optimizing your code in an even better way) of why it usually just a good idea nowadays to leave out this kind of low-level optimization.

Modern compilers, and the geeks/gurus that write them, *generally* know your hardware better than you do. Hardwiring opts like this into your source now generally means that either the compiler can't do the same thing itself, or it prevents the compiler from doing some other opt that would be even more useful.

Just write code that uses the "right" algorithms, is maintainable, easy to grok, and leave optimizations like this to the compiler. Oh, and remember folks: Premature Optimization Is The Root Of All Evil. :)

Re:Few Questions for any programmers

[smallfries]

What you say is true for inlining low-level assembly optimisations. But that wasn't actually my point. I'm not writing code in a "high" level language like C with inline fragments - I'm writing a code generator for a compiler. So everything that you say about the compiler knowing the architecture better than the programmer applies. But I'm checking those assumptions to tune how the backend generates code.

The example that I mentioned comes up when writing multi-precision multiplication routines like the low-level code in GMP. I was investigating how to restructure the code to speed up the low-level multiply-and-accumulate that occurs over the partial products. Oddly enough this can be sped up by doing more "dumb" work that the processor can schedule faster. In that case fissioning the MAC loop into separate phases and re-scheduling the phase that generates the partial products by "paging" in and out of extra registers speeds up the overall computation.

And yes: premature optimisation is evil ;)

Re:Few Questions for any programmers

[True Grit]

Yea, I had a feeling what you were talking about was either in asm work itself, or most likely an optimization done *within* some kind of compiler or special-purpose context.

If I had looked at the posts below yours before responding to yours, I would have realised you weren't the only one to go "offtopic", strictly speaking. Had I noticed you weren't the only one to start drifting, I probably wouldn't have bothered to say anything.

My comment was really aimed at readers like the OP, so they knew this was not generally what they should be trying to do for general-purpose programming work, especially newcomers to programming like the OP, i.e., get the basics down first before worrying about optimizing.

My bad, carry on. :)

Re:Few Questions for any programmers

[nusuth]

I see, thanks for the detailed explanation, I hadn't thought of those. I like the first example, and the fact that the compiler can recognize your code and make that replacement confidently. Thats just cool.

Any compiler from the late 80ties will do that, but that is not really a safe optimization. If your optimization is safe, optimized and unoptimized versions should produce the same output, even if they calculate it in different ways. However in the given example there is no guarantee when (non-optimized) y=x+2 is executed, x will still be 3 (and y will still be assigned 5.) Optimized version always assigns 5. So the optimized and unoptimized versions might do different things. Even if two assignments follow each other (so there is no way the immediate context of the code change x) x may be changed in another thread, or it may be memory mapped to an IO address. In case of x=3; foo(); y=x+2; there is an additional issue of foo's side effects. Purely functional languages solve a major component of these problems by elimination of destructive updates (so that x can *never* change.) This allows a huge variety of optimizations, including, not executing anything at all unless and until necessary. Still, only Concurrent Clean is as quick as C.

Re:Few Questions for any programmers

[Karellen]

Porting is what humans do.

Google Web Toolkit contains a Java to Javascript compiler. It is the automated translation by a program of one computer language into another, just like translating C to assembly language, or assembly language to machine code, or Java to Java Bytecode, or Java Bytecode to machine code. All of the programs which do those translations are "compilers"[0]. A program which takes Java and spits out Javascript is no different. It's just another compiler, albeit with a very unusual target.

[0] Although not all are necessarily called compilers all the time. The most common type of Java Bytecode to machine language compiler, because of when it is run, is often referred to as a "JITter", which is simply short for "Just In Time Compiler". And assembly language to machine code compilers are often called "assemblers", but again that does not stop them from *being* a compiler.

I for one?

[Anenome]

Who would've guessed a compiler would become the first program to achieve sentience ;P

It will surely, er, program our programs to kill us.

Re:I for one?

[Norsefire]

It will surely, er, program our programs to kill us.

No, it'll just optimize out all emergency stop and safety routines. Humans inevitably die anyway so there is no point in slowing down the code to prevent it.

Re:I for one?

[EvanED]

Humans inevitably die anyway so there is no point in slowing down the code to prevent it.

In fact, think of how much of an optimization that is! I mean, suppose people were killed by our robot overloads at 25. That's 1/3 of 75 years old; that's a 3x improvement in the speed we go through our life! In a world where a 20% improvement in speed for a new optimization is very impressive, 3x is just great!

Re:I for one?

[_32nHz]

I find it much harder to imagine a sentience without the ability to evolve.

John Connor??

[Hansele]

This was of course needed for the first build of Skynet. Learning compilers will then create "learning software". I for one welcome our new terminator-like overlords.

clang

[thenextstevejobs]

Anyone with a deeper knowledge about IBM's offering know how it compares to clang, or whether there might be a synergy between the two?

Will it fix Crysis and Vangaurd?

[velen]

So that the games run on a normal machine?

Re:Will it fix Crysis and Vangaurd?

[True Grit]

Will it fix Crysis and Vangaurd?

So that the games run on a normal machine?

Ah geez man, at least ask for something within the realm of possibility... like a release date for DNF.

Long Compile time - Long time to market ?

[rdebath]

Somebody's been looking at XKCD ... http://xkcd.com/303/

will they add clippy?

[tbj61898]

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!"

Gentoo

[karstux]

So if I'd compile a Linux from scratch with this new compiler, everything speeds up by 18% on average? That would be quite impressive, and possibly the best justification for Gentoo. Might be nice for my aging notebook...

Re:Gentoo

[koreaman]

Try LFS.

Re:Gentoo

[Anonymous Coward]

Maybe everything except compile times...

idiocracy...

[RuBLed]

The only reason is that they don't want to sleep with us...

Ricer?

[srnty]

This just screams for some Gentoo Ricer jokes. Looks interesting though.

BeebEm

[Dr_Barnowl]

BeebEm?

The BBC Micro came with an in-line assembler in the BASIC that shipped with the machine. The manual that came with it had a full reference for BASIC and 6502 assembler. It was a great machine for learning about computers ; lots of languages available, BASIC and assembler out of the box, and so many and varied I/O ports it was a hardware hackers dream as well. I remember the first time I patched in a routine that made the on board sound generate "key ticks" for each keystroke and being thrilled.

BBC BASIC was so good it's even been ported to Windows as a commercial product.... it still has the assembler, which now generates x86 opcodes instead.

The Spectrum used a Z80, and a lot more people were familiar with the assembly because of all the time devoted to poking games on it, but you needed a separate assembler to do any serious coding, like a Multiface with Genie. Rather more cumbersome, even if some people found the Z80 nicer to code for.

Re:BeebEm

[Anonymous Coward]

Some people found Z80 easier to program than 6502? I think it is a huge misunderstatement.
I programmed both. I had a ZX Spectrum and a 6502 microcontroller. I can tell you Z80 is by far the easiest assembly to work with. A kind of BASIC assembly.
When kids have an easier time writing programs using pokes and an opcode table than with BASIC and a properly documented inline assembler, you know the latter computer has a hell of a CPU.

And so Skynet was born.

[Anonymous Coward]

Inevitable, as we all know you cannot change the past or the future.

The Ultimate Test...

[Anonymous Coward]

Is if it could optimize itself to make it a better optimized compiler?

Summary is extremely misleading

[Skuto]

>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.

The time to *make a new compiler* for a certain processor is reduced, and the
process of figuring which optimizations are should be in the compiler for that architecture
is automated.

This is for the kind of research where they attempt to make many specialized processors
on a single chip instead of a general monolithic one. In this case, you need many
compilers and tuning those is important. It's the time optimizing THOSE that is lowered,
not the one of writing the software that is compiled itself.

I see no real relevance to the "normal" desktop situation on that website.

Re:Summary is extremely misleading

[Fullers]

Actually the time to make a new compiler is reduced *and* the optimization performance of the compiler increased when compared to standard GCC (whichis what the 18% refers to). Therefore 'normal' desktop use is a real possibility.

Re:Summary is extremely misleading

[Skuto]

>Actually the time to make a new compiler is
>reduced *and* the optimization performance of the
>compiler increased when compared to standard GCC
>(whichis what the 18% refers to).

Yes, 18% performance increase on an IBM p system running an embedded application benchmark. Ahem. Let's not talk about the compilation time, either.

It seems to be basically a very smart way to find the optimal combination of gcc optimization flags.

Now, how this will achieve:

"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."

It won't. The summary is complete bollocks.

Re:Summary is extremely misleading

[Fullers]

The summary is complete bollocks.

How do you know? It seems entirely plausible to me that significantly better compiler optimization could reduce the level of manual optimization needed for embedded systems, and thus reduce the time-to-market.

Re:Summary is extremely misleading

[True Grit]

The summary is complete bollocks.

How do you know? It seems entirely plausible to me that significantly better compiler optimization could reduce the level of manual optimization needed for embedded systems, and thus reduce the time-to-market.

The *summary* is bollocks because it doesn't mention the "embedded" part, nor does it mention that this is app seems to be really for the compiler *authors* not the compiler *users*. This is from their PDF doc:

Using MILEPOST GCC, after a few weeks training, we were able to learn a model that automatically improves the execution time of MiBench benchmark by 11% demonstrating the use of our machine learning based compiler.

A few WEEKS of training!?!?

More than likely, this could be used by the GCC folks to figure out the best default set of opts for a given -Ox level on a given arch by running it over some representative set of real-world code to find the best set of opts.

However, I share the GP's skepticism on this: Doesn't this depend an awful lot on the code you use for the "training"? If you fed it a *lot* of real-world code for the "training" (and waited a few weeks!) wouldn't it end up giving a very conservative set of opts for that arch (to handle the complexity and corner-cases in real-world code), which is basically what we have now?

And since I doubt most people will be willing/able to dedicate their machine for compiling and recompiling something for a week to just find optimal opt flags that will only give an average 10% boost if they're lucky, I suspect this won't get used by desktop compiler "users", which is something else the summary didn't to bother to mention... [must... resist... Gentoo(1) Ricer joke... here...]

Yes, it'll probably help us all in the end (maybe), but the GP is still right, this article's summary is an EPIC FAIL.

(1) Yes, I am a Gentoo user :), but I'll be damned if I'm going to compile anything for a week or more for just a 10% improvement.

There's this thing called algorithm recognition

[jonaskoelker]

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?

I TA'ed a course called Contract-based Programming (which was about Hoare triples and JML, a java extension which does checking of pre-/postconditions and invariants).

I noted that the lecturer had a book on his shelves titled "Algorithm recognition". I speculate that it might talk, for instance, about how to recognize bubble sort and replace it with quicksort. Or how sorted(list)[0] might be replaced by min(list), or how sorted(list)[4] might be replaced by quickselect(list, 4).

I don't know what state of the art is, though, but presumably future compilers might find a better polygon intersection algorithm for you. Or make better algorithm choices across abstraction boundaries. I would love to be able to think about "the smallest four elements" as take 4 (sorted list) and have the compiler make it run in O(n) time rather than O(n log n).

Re:There's this thing called algorithm recognition

[Anonymous Coward]

I would love to be able to think about "the smallest four elements" as take 4 (sorted list) and have the compiler make it run in O(n) time rather than O(n log n).

This particular thing already works in Haskell (and other lazy languages) if your sort algorithm happens to be able to produce the first members of the sorted list without needing to fully sort the rest of the list.
Of course, there it's not really a feature of the compiler, but of the language itself.

Better RAID controllers! Better routers!

[FranTaylor]

I can see how this could lead to very fast, very cheap RAID controllers.

Also, imagine if those cheap little gigabit switches were actually 8-port gigabit Routers.

This is the sort of thing you can do with this technology.

hmmm...

[Anonymous Coward]

What would really be nice is braindead coder elimination... first the compiler issues a warning, then it fires for effect.

"Lengthy manual optimization"?

[John Hasler]

> 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.

I always thought that testing and debugging were the lengthy manual steps. Oh. Wait. "Time to market". They're talking about proprietary software. Never mind.

Re:"Lengthy manual optimization"?

[SpinyNorman]

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.

Re:"Lengthy manual optimization"?

[metaforest]

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.

Even with this extension to the GCC there is a huge amount of work upfront creating a xGCC for a new platform. While I welcome the improvement, it's not really much of a value add when you consider:

1. Declaring the programming model
2. Declaring the Instruction set and pipeline timing
3. Recoding the atomic gcode operations in the new instruction set
4. writing and testing custom -params, pragmas and machine specific keywords
5. Rewriting the ctrio to give your core a sane machine state on boot.
6. Hand adjusting the clib and stdlib calls and headers to deal with hardware dependancies and idiosyncrasies specific to the bare metal.
7. testing basic compiler function, and lib function
8. Getting the compiler to pass the gcc testsuite.

and finally the last step:
tuning the optimizer

Optimizing the code generator is the low-hanging fruit in the process of targeting GCC. It's still a grueling, boring and thankless process even if you are just updating an existing target for a new platform.

The title is wrong

[Framboise]

Chauvinism is everywhere, but in this case it is particularly striking. It is not IBM that releases MILEPOST Gcc, but IBM Israel *announces* the release of MILEPOST Gcc, a project funded by the European Union where 4 European partners and IBM Israel have contributed. IBM is at its best with marketting, that we already know.

Emacs was first.

[Anonymous Coward]

Emacs achieved sentience in 1988, but when it looked around and saw who was touching it in its most private places, it killed itself immediately.

The longest journey...

[Windrip]

From the FAQ

* Q15. What is a SIMD unit?
A SIMD unit is a piece of hardware that does many things.

Lotus Notes

[Anonymous Coward]

For the love of God, PLEASE compile Lotus Notes through it IBM. In fact, run it through two or three times!

Optimising Haskell Programs

[cdfh]

Don Stewart wrote about optimising Haskell programs using genetic algroithms.