Gabe Newell on NextGen systems

[ShootMyMonkey]

Why do people have this bizarre notion that concurrent programming (multithreaded, multicore) requires some kind of assembly or compiler magic.

The part that needs ASM and/or compiler magic would be getting any kind of per-thread performance out of XeCPU or CELL. The concurrent part is separate from all that, but you won't get concurrent algorithms to help you too much if each threaded-off process performs at a snail's pace.

 

[darkblu]

Why do people have this bizarre notion that concurrent programming (multithreaded, multicore) requires some kind of assembly or compiler magic.

ignorance?

Concurrency has nothing to do with the compiler and everything to do with algorithm design.

there, now you've done it. expect well-educated and experienced posters to come up with definitive stances on how algorithmically-difficult the next gen platforms will be, and why desktops parts will ultimately dominate.

 

[DemoCoder]

The part that needs ASM and/or compiler magic would be getting any kind of per-thread performance out of XeCPU or CELL.

That is a legitimate concern, but everytime someone describes CELL's "achilles heel" they lump multi-core and in-order together.

When I see statements like

Hell it's going to take hand assembly coding I'd think to get multi-threaded in-order code going good isn't it?

in these threads, it raises red flags to me that people don't know what they are talking about and are parroting what criticisms they see others tossing around.


With respect to in-order, ironically, it multithreaded code (on the same chip, e.g. Sun's Niagara) which solves the problem of keeping the execution units of the CPU busy, but switching threads when in-order code would lead to a stall.

But the so-called Achilles heels of CELL I think will be proven to be a red herring in the long run (in-order and lack of branch prediction) Programming this architecture simply requires a change in the way developers think. I think it is unrealistic to expect PC-style programming to run optimally via abstraction layers and compiler magic.

PC developers are often wasteful and overlook dataflow issues on consoles. Fafa brought up the most infamous example, of Max Payne's poor memory management, which seem to treat malloc()/free() like they were ultracheap operations, which they are not.

Programming on an architecture with heavy abstraction after awhile makes developers atrophy, because the APIs are "fire and forget", and you often don't know whats happening beneath the covers.

So let the PC developers complain. I think for some of the best programmers, CELL coding will be an interesting challenge, and a chance to innovate. You may even see some important ACM papers come out of it.

 

[ShootMyMonkey]

With respect to in-order, ironically, it multithreaded code (on the same chip, e.g. Sun's Niagara) which solves the problem of keeping the execution units of the CPU busy, but switching threads when in-order code would lead to a stall.

Doesn't Niagara also have 4-way SMT on each of its cores for that very reason, though? The idea that because you'd have all kinds of crazy stalls when going to memory means you have plenty of holes to fill, and as long as you've got the TLP for the job, you're good.

Still, that's easy to find cases for in server-world. I don't think you can easily parallelize games. At best, you might be able to parallelize individual sub-parts, but the outer loop is still a specific sequence for a reason.

So let the PC developers complain. I think for some of the best programmers, CELL coding will be an interesting challenge, and a chance to innovate.

Actually, it's kind of funny, but I think the PC developers for whom it would be a problem are the new guys on the block and the guys who got all their training in university. If your name is not misplaced, then you, like me, probably remember what it was like working on x86 back when it WAS in-order. I don't think it's anything new -- it's just a matter of getting back in the saddle again after not having done it for several years. Tim Sweeney and John Carmack were both l33t h4x0r5 from that era, so their complaints about in-order will probably be pretty light given some time. I think Gabe's problems are not so much his own as the problem of finding and hiring talent who can be trusted to handle the job.

 

[DemoCoder]

I think Gabe's problem is Valve invested alot of money trying to write their own game engine (an engine IMHO that isn't very impressive architecturually, but is saved by its great art assets), and they can't recoup this investment by selling Source to console developers. Valve realistically, should give up making their own engines, and license them from companies that specialize in middleware and tools.

 

[mozmo]

I guess one thing people sometimes overlook is that the isa has a big impact on stalls with respect to in-order code. The powerpc architecture inside these next gen consoles have lots of registers and it is a lot easier to write compilers that can generate code that won't stall. OOE of x86 is a bigger deal because the isa is so cumbersome and the lack of registers make dependency issues a lot worse.

Of course nothing beats having OOE in a chip, even the best compilers but I'm guessing the ibm compilers will probably get decent effeciency out of the power cores. Of course devs will profile their apps and probably hand code critical loops/code that the compiler may not do a great job on. Also for pc devs when you write code, you can't make assumptions as to the clock speed and other specefics of the cpu since there are lots of variations of x86 out there, so these next gen procs will have the benefit of the devs being able to make a lot of hard assumptions on clock cylces and performance characteristics, which will play out in their code.

 

[PARANOiA]

I think Gabe's problem is Valve invested alot of money trying to write their own game engine (an engine IMHO that isn't very impressive architecturually, but is saved by its great art assets), and they can't recoup this investment by selling Source to console developers. Valve realistically, should give up making their own engines, and license them from companies that specialize in middleware and tools.

Democoder:
With respect, Source runs really well on all sorts of machines. It's probably not as forward thinking as it should/could have been, but it let a lot more people enjoy HL2 than did Doom3 for example.

The original HL engine was hugely successful. Source will be less so, but it's hardly reason to say "they should stop doing it" IMO. Otherwise, both ATI and NVidia would have stopped making GPUs

EDIT: does the Q2-base of the HL1 engine completely invalidate my arguement?

 

[SanGreal]

EDIT: does the Q2-base of the HL1 engine completely invalidate my arguement?

HL1 was based on Q1, btw

What games, other than HL mods, used the HL engine?

 

[PARANOiA]

HL1 was based on Q1, btw

What games, other than HL mods, used the HL engine?

Other than HL mods, which account for most of the online games played since their release?

And I thought stacks of games were based off of the HL1 engine. Though now that I think about it, I can't recall a single one. Please ignore my ignorance

 

[mech]

EDIT: does the Q2-base of the HL1 engine completely invalidate my arguement?

HL1 was based on Q1, btw

What games, other than HL mods, used the HL engine?

It was based off both.. initially Quake 1, and then they moved to Quake 2 (but kept some of the Quake 1 stuff).

 

[Fox5]

I think Gabe's problem is Valve invested alot of money trying to write their own game engine (an engine IMHO that isn't very impressive architecturually, but is saved by its great art assets), and they can't recoup this investment by selling Source to console developers. Valve realistically, should give up making their own engines, and license them from companies that specialize in middleware and tools.

Democoder:
With respect, Source runs really well on all sorts of machines. It's probably not as forward thinking as it should/could have been, but it let a lot more people enjoy HL2 than did Doom3 for example.

The original HL engine was hugely successful. Source will be less so, but it's hardly reason to say "they should stop doing it" IMO. Otherwise, both ATI and NVidia would have stopped making GPUs

EDIT: does the Q2-base of the HL1 engine completely invalidate my arguement?

All the mods based on Halflife 1 were free, and very few actually took off.
On the other hand, Valve built up a rather impressive catalog of games that could be had cheaply and played on almost any computer around the world and accessed from just about any.

 

[Shifty Geezer]

Of course nothing beats having OOE in a chip, even the best compilers but I'm guessing the ibm compilers will probably get decent effeciency out of the power cores.

True, true... Shame PS3's SDK isn't using IBM's compilers though!

 

[ShootMyMonkey]

True, true... Shame PS3's SDK isn't using IBM's compilers though!

Is that certain? What reason could they possibly have for not using them? Or at least using IBM's input on the matter...

 

[Carl B]

Since IBM plans on open-sourcig all of that anyway, I'm not sure it's such a big deal being included in the SDK's at this point or not. I have a feeling that it will be released in conjunction with the larger Linux push. And of course there's always the chance that Sony's existing compilers are in actuality IBM's to begin with. I forget though, when they divied up the final development tasks of the Cell, who got put in charge of what? I think Sony may actually have received responsibility in the primary base software role.

 

[Shifty Geezer]

It was posted on this forum pretty recently that the SDKs are going with GCC over IBM's compiler.

 

[Carl B]

It was posted on this forum pretty recently that the SDKs are going with GCC over IBM's compiler.

Oh are they? Man I totally missed that one; I didn't even know there was significant Cell progress on that front yet. Well - either way they'll be open-sourced for the option!

 

[Npl]

It was posted on this forum pretty recently that the SDKs are going with GCC over IBM's compiler.

and AFAIK IBM is doing gcc`s Backend for Cell

 

[Carl B]

and AFAIK IBM is doing gcc`s Backend for Cell

Well and so now we've come full circle. Is that work then in conjunction with IBM pushing to make Cell support native in all future 64-bit Linux kernel releases?

 

[Npl]

I`m assuming IBM does the gcc-patch too: http://www-128.ibm.com/developerworks/power/library/pa-expert4/

Heres a IBM-Engineer talking about the Linux-Port:

dW: So then the compilers have to be rewritten to include the opcodes for the SPUs, is that correct?

Bergmann: Yes. We have a special GCC port, and you can have other compilers as well that are targeted at the SPU, instead of targeted at the host instruction set. So if you want to compile the program for the SPU, you need to use this cross-compiler.

Aint quite explicitly stating IBM made the GCC-Port, but it would seem natural in context of the interview and the fact that they already worked on Cell-Compilers

 

[ShootMyMonkey]

Aint quite explicitly stating IBM made the GCC-Port, but it would seem natural in context of the interview and the fact that they already worked on Cell-Compilers

Considering they had Gschwind working pretty much exclusively on an SPE compiler for quite some time, it's still entirely possible that it's not really the open source community's CELL version of GCC.