Stanford super runs million-core calculation

Re: Quite impressive in term of size but am I alone in wondering.

"Shouldn't this SIMD thing just work by now instead needing lots of twiddling?"

That's sort of like asking why there's still bad software in the world--shouldn't compilers just produce good software?

Making software run on multiple cores (not SIMD, but whatever) is more art than science, no matter how many compilers come along promising to do it for you automatically.

Re: Quite impressive in term of size but am I alone in wondering.

It's a little simplistic to say that this SIMD thing should just work. A friend of mine used to write code for multi-core systems. She said it's relatively simple to code for 2 or 4 cores. When that code has to scale to thousands (or even a million, in this case), then scheduling and managing communication between the threads running on each core becomes both a massive job and a nightmare.

Re: Quite impressive in term of size but am I alone in wondering.

@John Smith 19: The SIMD thing _does_ just work. Out of the box, no prob.

It's when you insist that you want every last bit of performance from your hardware that things get difficult. Running a computer at a couple percent efficiency isn't hard and for many situations is plenty good enough. Running your home PC at anything approaching full throttle is an interesting engineering task. Running a million CPU super at efficiency is a serious challenge.

So, it's not that there aren't tools. There are and they do a decent job. But a team of specialists piling on the man-months can do better. So it becomes economics: is the cost of the specialists worth the additional performance? This is really no different from programs like Photoshop containing a few hand-coded pieces of assembly. The compiler is good, but sometimes it's worth it to do better.

Re: supersonic flight

John Smith 19, this simulation is not about supersonic flight but about gas coming out of the engine at supersonic speeds. A very common thing among jet engines...

Re: At what point

not at this point, clearly.

Even if the simulation takes longer than a physical test would, the physical test cant tell you what is going on inside the engine at every point. And I would think that a virtual design is quicker to virtually build than whole or part of a real, physical, jet engine.

Re: At what point

At what point is it cheaper and simpler to build several dozen jet engines, each to a one-off specification, rather than build a simulation of just one and tweak its parameters?

"There, fixed that for you" as they say.

But yes, this beastie would be fairly close to that point. I assume it can also be used for other things, and I also assume that its builders have learned a fair bit about architecture and so the next one will be cheaper.

Perhaps you looked at the picture at the bottom of the article.

Take.

Mind.

Out.

Of.

Gutter!

Re: So it's partly the communcations overhead and the synchronosation that's the problem.

Sure, you can do that (and I expect they have done just that). But, if your calculation cannot continue until you have received the new input values from the neighboring CPU, then it doesn't matter if the hardware is decoupled, your software will stall.

So, what you need is not just well-balanced hardware, but well-balanced software that plays precisely to the strengths and weaknesses of that hardware. That's tough.

Re: So it's partly the communcations overhead and the synchronosation that's the problem.

You're thinking of Transputers. Which were certainly the right idea for CFD, not so much on account of the architecture but because of the good balance between compute and communication speeds, and especially the very low communication latency. Low latency meant that relatively little time was wasted hanging around at the end of an iteration, waiting for data to arrive from neighbouring processors. But they had their problems too - especially absence of any kind of global/broadcast communication.

I don't know how things have changed since those days, but at that time there was a tension between algorithmic efficiency and parallel processing - the more efficient CFD algorithms coupled cells across the whole domain, which was generally OK to parallelise on a shared-memory system but was no-go on a distributed-memory architecture where less efficient algorithms could be used.

So... real kudos to the guys & gals, both system architects and software developers, who have pulled off the feat of building a system and a real-world application that scale across 1^^6 processing elements.

Re: This release makes it sound like Stanford engineered it

I believe, having actually read the article, that this is the first time they have used over a million cores in the same calculation. Usually they are spread over multiple jobs.