IBM To Release Cell Compiler

[Kamalot]

It isn't easy to write code for Cell, with its central processing core and eight accompanying special-purpose engines.

IBM plans on releasing a compiler designed to take a single program and break it down into multiple programs that can be spread across multiple cores on the Cell processor. The compiler, called Octopiler, has it's work cut out for it. It must divide the program in such a way that allows the programs to share resources and still allow them to communicate. It must also compile the results into two languages, one for the core and another language for the 8 SPEs.

IBM pledged in 2004 that Cell will be easy to program.

"Programming Cell is relatively hard," said Illuminata analyst Gordon Haff, in particular because programming tasks must be split into independent threads that execute in parallel. "Certainly a higher-level, more abstracted model makes programming a lot easier."
The article continues to cover special training courses for developing for the Cell, along with the complexity of the compiler and difficulty of getting programmers to think like the Cell processors.

"The programming approach for the Cell BE processor is a different paradigm for many software developers,"
With these first-generation cell tools and training scheduled for release in the future, what are PS3 developers doing today to write code for this new and very different processor, the Cell and how do these upcoming development tools compare to those offered by the competition?

CNet (http://www.cnet.com/) is the source for the article (http://news.com.com/Octopiler+seeks+to+arm+Cell+programmers/2100-1007_3-6042132.html?tag=nefd.lede).

[51|RandoM]

Cool.

Compilers should be doing all the dirty work anyways. :-)

[IIArchonII]

Octopiler

Doesn't that sound like a villian?

[Zanzibar]

The main Cell CPU and the SPEs have to be programmed in DIFFERENT LANGUAGES???

[Zeal]

In the panic, they tried to pull the plug.

[Schnoogs]

How long til the Octopiler becomes self aware and sends 2 cybernetic lifeforms back through time to kill Ken Kataguri

[Zipper114]

The main Cell CPU and the SPEs have to be programmed in DIFFERENT LANGUAGES???

It means the SPEs and CPU have different sets of supported machine opcodes, not that the programmer necessarily must use different high level programming languages. I assume :p

[TalkingOctopus]

It will be interesting to see how well it works. The itanium is another processor that relied heavily on compiler optimization and look how well that went...

[Schnoogs]

It will be interesting to see how well it works. The itanium is another processor that relied heavily on compiler optimization and look how well that went...

Apples and Oranges

[TalkingOctopus]

Apples and Oranges

I'm not so sure. Both were pitched as the ultimate computing solution. Both have pretty radical architectures. The only major difference I can think of is that the cell didn't invent a new ISA. I guess we'll find out how the good the cell really is soon enough.

[MaiXu]

So did Sony just not even consider the idea of developing a new processor that was easy to develop and easy to develop for?!

Say what you want about the 360 possibly being underpowered, but does totally over-powering the next gen create more problems than opportunities?

[Kamalot]

It means the SPEs and CPU have different sets of supported machine opcodes, not that the programmer necessarily must use different high level programming languages. I assume :p
That is a good question. Perhaps with the octopiler they can use the same high-level language, but what is one to do in the mean time? Octopiler isn't even out yet, let alone implemented into the workflow and development procedures of developers.

What are game companies doing TODAY to make sure their titles are ready by Spring, or even Fall?

[Demo_Boy]

You just press the "Make Game" button. Its right on the front of the PS3 Dev kit.

[Schnoogs]

I'm not so sure. Both were pitched as the ultimate computing solution. Both have pretty radical architectures. The only major difference I can think of is that the cell didn't invent a new ISA. I guess we'll find out how the good the cell really is soon enough.

The MASSIVE difference is the Itanium wasnt difficult to program for and didn't require a completely different approach to architecting an application.

But besides that they're the same ;)

[Steele Johnson]

The article is a bit unclear and really doesn't say too much. I'd think if you relied on the compiler to divvy up the code for each SPE, then it's probably just optimizing it by looking for pieces of code that do some heavy number crunching, and separates them evenly and compiles them down to machine code for each of the SPE's. The CPU is probably responsible for dispatching and controlling each of the SPE's, managing memory, and controlling the GPU.

To take full advantage of this processor, I'd assume that you would write code that dynamically creates threads and breaks down the machine code for each of the SPE's. That way, you can use one or two for a physics engine, one for managing sound, one to handle statistical data, etc, etc.

I can only imagine the possibilities. It may even bring on new genres... or at least, raise the bar for all of them.

Sony aside, it sounds like really cool technology. I just hope it takes off and doesn't slide of the map like some of the other cpu's that have come and gone.

[Mr.Green]

Here are two quotes from Carmack's keynote (http://www.next-gen.biz/index.php?option=com_content&task=view&id=760&Itemid=36) at Quakecon:

…Multiprocessing with the CPUs is much more challenging [to harness than the parallelism provided by graphics cards]. It’s one of those things where it’s been a hot research topic for decades, and you’ve had lots academic work going on about how you parallelize programs and there’s always the talk about how somebody’s going to somehow invent a parallelizing compiler that’s going to just allow you to take the multi-core processors, compile your code and make it faster, and it just doesn’t happen.

…But it’s not a problem that I actually think is going to have a solution. I think it’s going to stay hard, I don’t think there’s going to be a silver bullet for parallel programming. There have been a lot of very smart people, researchers and so on, that have been working this problem for 20 years, and it doesn’t really look any more promising than it was before.

Makes you wonder...

[abso]

Granted Carmack has done some very cool things, but the guy does not have a CS degree and should get off the academic soap box. He is very good at reading other people's research and implementing those ideas, but he doesn't do anything original.

Anyway, on to the topic of multi-core programming. It is my opinion that the 'hard to develop for' idea comes from two things: first, the very high turnover in the game dev business, and second, that the programmers replacing the former have no solid multi-threading background. Writing code that can properly utilize multiple cores is a design issue. You set up the threads, and the OS of the system says 'this thread should be run here.' That is multi-core programming at its heart. Since it is a design issue, it should be dealt with thoroughly BEFORE ANY CODE IS WRITTEN. Rookie programmers have horrible design skills (I know this from experience working with them for several years) and are not prepared to properly program for multiple cores because of it.

Now, what DOES make the PS3 more difficult to develop for is that the 7 SPEs are vector processors, so they function very much like a GPU does today (just with a more general instruction set). So you have to use the same techniques to get the most out of it. The CPU controller is then responsible for saying 'thread 1 go to SPE 3' and so on. I'm not going to say that I know the PS3 architecture inside and out, but from my understanding of threaded programming, it isn't the clusterfuck people are making it out to be. Besides, PCs are going multiple multi-core soon, so learning how to write threaded code is going to be required to do anything useful.

[Groo]

Here are two quotes from Carmack's keynote (http://www.next-gen.biz/index.php?option=com_content&task=view&id=760&Itemid=36) at Quakecon:

Makes you wonder...

Those points are probably valid. However, if with this compiler, you can write PS3 games entirely in C++, and still have good performance (although naturally not as good as doing it yourself), it will be a lot easier for smaller development houses to do work on PS3.

[Stooby]

Most developers have difficulty programming for 2 cores let alone 8 cores.

It might not sound like a difficult task. You have 2 cores you can just split the workload between the two, right? Not quite, when the game world is updating you have to worry about a lot of different things and the order of execution is critically important.

Currently, when something says it takes advantage of multi core processors the developers just forked the main thread in areas where it can be done easily without worry of messing up the order of execution. For instance you could save a marginal amount of processing time by forking some of the physics processing. The reason most games that are upgraded to utilize multiple cores only has a very slight improvement in performance is because all they did was fork physics and maybe some object processing.

In order to take advantage of multiple processors you have to spend a lot of extra time designing where the code will be processed.

[NACIONAL]

He is very good at reading other people's research and implementing those ideas, but he doesn't do anything original..

Yeahh sure.. he has done nothing.... keep dreaming. The reason people listen to him is because he has done a lot for the industry, like it or not, he has pushed the boudaries of technical game development....


now, if we are talking game design....

[crashedout]

The comparison with the Itanic(!) is valid. The high level coding was easy but they relied on the compiler to pull out the performance of the chip. This did not happen for a very long time , if ever. Maybe it was the isa, maybe not. That is why the statement does not date the release of the compiler, it could be years before it actually works well. So far the cell is not impressive however the cell blades are interesting, cannot wait to see some real-world benchmarks on those.

[Schnoogs]

Granted Carmack has done some very cool things, but the guy does not have a CS degree and should get off the academic soap box. He is very good at reading other people's research and implementing those ideas, but he doesn't do anything original.

Well I have a CS degree and I'll take Carmacks word over any of my colleagues.

[Schnoogs]

The comparison with the Itanic(!) is valid. The high level coding was easy but they relied on the compiler to pull out the performance of the chip. This did not happen for a very long time , if ever. Maybe it was the isa, maybe not. That is why the statement does not date the release of the compiler, it could be years before it actually works well. So far the cell is not impressive however the cell blades are interesting, cannot wait to see some real-world benchmarks on those.

The comparison is not valid because the architecture of the application can be indentical on an Itanium or say an Athlon 64. In the case of Cell the architecture has to be fundementally different so that it can work in parallel across so many cores.

I've written applications for the Itanium and didnt have to do anything fundementally different other than deal with new instructions. How many apps have you written for it???

Apples and Oranges.

[SaintArnold]

Granted Carmack has done some very cool things, but the guy does not have a CS degree and should get off the academic soap box. He is very good at reading other people's research and implementing those ideas, but he doesn't do anything original.

Anyway, on to the topic of multi-core programming. It is my opinion that the 'hard to develop for' idea comes from two things: first, the very high turnover in the game dev business, and second, that the programmers replacing the former have no solid multi-threading background. Writing code that can properly utilize multiple cores is a design issue. You set up the threads, and the OS of the system says 'this thread should be run here.' That is multi-core programming at its heart. Since it is a design issue, it should be dealt with thoroughly BEFORE ANY CODE IS WRITTEN. Rookie programmers have horrible design skills (I know this from experience working with them for several years) and are not prepared to properly program for multiple cores because of it.

WTF? Carmack is widely respected in the graphics industry, and is consulted heavily by ATI and Nvidia. That matters way more than any piece of paper. And he *does have* academic cred- several SIGGRAPH papers have cited his techniques and their novelty.

And no matter how experienced the programmer, writing multithreaded code is very difficult. It's difficult because program execution is no longer deterministic, leading to "heisenbugs" that occur in one run, but not another with identical inputs. This is because the execution of the program is affected by thread scheduling decisions made by the OS (or thread library), depending on current system conditions that may not be reproducible. These heisenbugs make debugging a nightmarish time-consuming process.

So Carmack is right. Multithreaded programming is very, very hard. I've written enough multithreaded code to have first-hand experience with this. Sure, experience and training help as you say, but they do not solve the fundamental problem.

[NACIONAL]

This is because the execution of the program is affected by thread scheduling decisions made by the OS (or thread library), depending on current system conditions that may not be reproducible. These heisenbugs make debugging a nightmarish time-consuming process.

You are absolutely rigth... add to that an enourmus quantity of flags so the threads don't mess with themselves... and debugging... ohh god..

I've doing some work with threads on multicore machines, and damn, the debugging process is really a Nightmare.

[Schnoogs]

WTF? Carmack is widely respected in the graphics industry, and is consulted heavily by ATI and Nvidia. That matters way more than any piece of paper. And he *does have* academic cred- several SIGGRAPH papers have cited his techniques and their novelty.

And no matter how experienced the programmer, writing multithreaded code is very difficult. It's difficult because program execution is no longer deterministic, leading to "heisenbugs" that occur in one run, but not another with identical inputs. This is because the execution of the program is affected by thread scheduling decisions made by the OS (or thread library), depending on current system conditions that may not be reproducible. These heisenbugs make debugging a nightmarish time-consuming process.

So Carmack is right. Multithreaded programming is very, very hard. I've written enough multithreaded code to have first-hand experience with this. Sure, experience and training help as you say, but they do not solve the fundamental problem.

finally a sensible post...Carmack is living proof that for some people they don't need a PHD to reflect their genius.

Carmack is a bonified genius. I don't care if you don't like id's games...their engines are superb and thats all because of one man...Carmack. There's a reason he's in the Academy of Interactive Arts & Sciences Hall of fame which only has like 9 memebers and he was the 4th inducted.

[DrDocker]

small -> medium -> large -> gonzo -> octo

[TalkingOctopus]

The comparison is not valid because the architecture of the application can be indentical on an Itanium or say an Athlon 64. In the case of Cell the architecture has to be fundementally different so that it can work in parallel across so many cores.

I've written applications for the Itanium and didnt have to do anything fundementally different other than deal with new instructions. How many apps have you written for it???

Apples and Oranges.

I have actually written an application for hte Itanium and you're right it really wasn't any different or very difficult. But the whole point of the Octo whatever compiler is so you don't have to do anything different. The article states:

"The software development tool converts a single, human-written program into several different programs that run simultaneously on Cell's various cores."

I assume this means it takes a single threaded program and seperates it into several different processes.

[Kamalot]

The article states:

"The software development tool converts a single, human-written program into several different programs that run simultaneously on Cell's various cores."

I assume this means it takes a single threaded program and seperates it into several different processes.
Which begs the question, WTF are people doing TODAY, before Octopiler's release?

[bobbler]

Which begs the question, WTF are people doing TODAY, before Octopiler's release?

The same thing everyone else is on multicore systems? Creating different threads -- it's just that the SPEs are a little different (in that they have a few different instructions for the VMX/SIMD usage and DMA engine -- DMA engine can be turned into a software cache, but I imagine most will do manual DMA'ing ahead of time).

Octopiler is a research project... things like this are a pipedream or a magic bullet and I sure as fuck wouldn't trust a compiler to properly split things into threads for me (not on PC, or X360, or PS3, not anywhere). I can't imagine how much work the compiler would have to do to properly (with any efficiency, I mean) split up something into multiple threads -- if the compiler can do it, then a person can too, and likely would do it much better. If any dev's working on Cell of any sort are hoping for some magic compiler to do the work for them, they are likely to be out of a job soon (same on any multicore system, really).

With that said, GCC3 (I think that's what they are using on PS3) is rather solid as far as PPC compilers go (actually, it's likely equal or better than MS' current PPC compiler -- of course MS' has been in the shed for the last several years). IBM also has their XLC compiler as well (for Cell).