By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - PC Discussion - Compiler to get automatic multi-threading

The free software/open-source compiler gcc is to get automatic, compile-time multi-threading.

http://www.phoronix.com/scan.php?page=news_item&px=NzEzNA

This is huge. It's the first step towards multi-core PCs and consoles being utilised effectively.The big problem with the move to multi-core (which was a R&D and manufacturing cost saving technique by CPU makers) was that it required a lot of extra effort to properly take advantage of the additional cores, and all previous programs need a rewrite. As core counts increase (AMD plans a 12-core chip in 2010; Intel an 80-core one in the future) the problem will get worse.

What we need is a compiler-level (i.e. automatic) program to multi-thread apps for you on compile. Even if it's very inefficient it will provide large performance increases to currently single-threaded apps.



Around the Network

That's an amazing feat. Good to see all that hardware that exists in today's tech will be put to (hopefully) more efficient use.

P.S. I love Linux too! I have Ubuntu installed on both my desktop and netbook! I'd still consider myself a noob with Linux for the most part but I've been using it for a few years now and have no plan of going back to Windows or even trying Mac OS.



Soleron said:

The free software/open-source compiler gcc is to get automatic, compile-time multi-threading.

http://www.phoronix.com/scan.php?page=news_item&px=NzEzNA

This is huge. It's the first step towards multi-core PCs and consoles being utilised effectively.The big problem with the move to multi-core (which was a R&D and manufacturing cost saving technique by CPU makers) was that it required a lot of extra effort to properly take advantage of the additional cores, and all previous programs need a rewrite. As core counts increase (AMD plans a 12-core chip in 2010; Intel an 80-core one in the future) the problem will get worse.

What we need is a compiler-level (i.e. automatic) program to multi-thread apps for you on compile. Even if it's very inefficient it will provide large performance increases to currently single-threaded apps.

I am bit sceptic about this for current consoles as they are IoE, which means that you must customize code for them strictly if you want to make anything. PC however is OoOE so its way easier to make programs as you can freely program the way you want to do without thinking does these logical paths kill this platform & so on. So its easier to make it automatically code for it too. :P



Deneidez said:
Soleron said:
...

I am bit sceptic about this for current consoles as they are IoE, which means that you must customize code for them strictly if you want to make anything. PC however is OoOE so its way easier to make programs as you can freely program the way you want to do without thinking does these logical paths kill this platform & so on. So its easier to make it automatically code for it too. :P

Since gcc compiles for all kinds of processors including POWER like the Xenos and Cell, I'm sure that would be taken into account. In-order vs. out-of-order isn't relevant at the software development level as it's implemented in hardwaee. But i don't expect this for consoles yet (I think you have to use their official devkit compiler anyway). I'm talking about this as a general advancement - one day all compilers will feature similar technology.

 



Trust me, it's not as amazing as you think it is. This well help those that don't bother to multi-thread at all, but those that already do will receive minimal performance gains at best.



Good news Everyone!

I've invented a device which makes you read this in your head, in my voice!

Around the Network

This will probably just improve the loops which are embarassingly parallel... Any real-time or performance-critical application would already have the most important loops parallelized.

And of course it will only work if the functions called in the loop are purely functional (i.e. not accessing volatile or global variables, and only calling equally clean functions).

Still pretty cool but nothing revolutionary, this optimization is just picking the low-hanging fruit. The real optimizations lie in fundamentally restructuring programs around the idea of multi-core, which is where it gets hard or impossible to do.



My Mario Kart Wii friend code: 2707-1866-0957

NJ5 said:
This will probably just improve the loops which are embarassingly parallel... Any real-time or performance-critical application would already have the most important loops parallelized.

And of course it will only work if the functions called in the loop are purely functional (i.e. not accessing volatile or global variables, and only calling equally clean functions).

Still pretty cool but nothing revolutionary, this optimization is just picking the low-hanging fruit. The real optimizations lie in fundamentally restructuring programs around the idea of multi-core, which is where it gets hard or impossible to do.

Well, I'm not an expert, so I'll agree with you.

Could there be any sort of compiler-level software in the future that could do that restructuring?

 



Soleron said:
NJ5 said:
This will probably just improve the loops which are embarassingly parallel... Any real-time or performance-critical application would already have the most important loops parallelized.

And of course it will only work if the functions called in the loop are purely functional (i.e. not accessing volatile or global variables, and only calling equally clean functions).

Still pretty cool but nothing revolutionary, this optimization is just picking the low-hanging fruit. The real optimizations lie in fundamentally restructuring programs around the idea of multi-core, which is where it gets hard or impossible to do.

Well, I'm not an expert, so I'll agree with you.

Could there be any sort of compiler-level software in the future that could do that restructuring?

I guess I went a bit too far. If thats the case, its no miracle as NJ5 said. If they make it better than that, it would mean more logical paths and that would mean problems on IoE platforms(Too complex = it would run slower than on one core.). Thats what I ment in my first post.



Soleron said:
NJ5 said:
This will probably just improve the loops which are embarassingly parallel... Any real-time or performance-critical application would already have the most important loops parallelized.

And of course it will only work if the functions called in the loop are purely functional (i.e. not accessing volatile or global variables, and only calling equally clean functions).

Still pretty cool but nothing revolutionary, this optimization is just picking the low-hanging fruit. The real optimizations lie in fundamentally restructuring programs around the idea of multi-core, which is where it gets hard or impossible to do.

Well, I'm not an expert, so I'll agree with you.

Could there be any sort of compiler-level software in the future that could do that restructuring?

 

That kind of restructuring would require human-level (or above) AI, generally speaking. At that point we will probably not be using compilers, since our AI friends will be writing programs for us (if they don't exterminate us of course).

There are languages more suited to automatic parallelization than C, I'd imagine that most C programs have loops which this compiler trick won't touch due to having potential side effects that the compiler can't reason about (so it will assume it's too dangerous to do parallelization). I can provide simple examples if anyone is interested.

Still this is useful in that it will make code more readable, and automate some of the work behind making loops parallel. This makes for faster programming and less bugs.

 



My Mario Kart Wii friend code: 2707-1866-0957

well, maybe this is new to gcc, but the sun compiler for instance already has this. so it's nothing new. by and large this is very restrictive, i don't know how much use game programmers will find for it.



the Wii is an epidemic.