D and multicore

[Sean Kelly]

parallel noob Wrote:
> 
> I fail to map these concepts discussed here with the things listed on those pages. I found MPI, POSIX Threads, TBB, Erlang, OpenMP, and OpenCL there.
> 
> Sean mentioned:
> 
> "In the long term there may turn out to be better models, but I don't know of one today."
> 
> So he's basically saying that those others listed in the wikipedia pages are totally unsuitable for real world tasks? Only Erlang style message passing works?

I was saying that message-passing is the most easily understandable concurrency model.  But answering the rest of your question is somewhat tricky.  Data parallelism (ie. OpenMP) is the optimal approach for processing large datasets, but data parallelism can be achieved (at an API level) in a variety of ways, from POSIX Threads to message passing.  A specialized API is best though, and in fact there's a data parallelism package under consideration for Phobos right now.  I don't know if that clarifies or confuses things however.

> The next machine I buy comes with 12 or 16 cores or even more -- this one has 4 cores. The typical applications I use take advantage of 1-2 threads. For example a cd ripper starts a new process for each mp3 encoder. The program runs at most 3 threads (the gui, the mp3 encoder, the cd ripper). More and more applications run in the browser. The browser actively uses one thread + one thread per applet. I can't even utilize more than 50% of the power of the current gen!

Software takes a long time to change.  And the apps you picked aren't easily parallelizable anyway.  I think Russel is exactly right when he says that future systems will have a collection of heterogeneous cores... a few traditional ones for apps like the above (say 16) and clusters of others for different purposes.  Seems like the trick will be dispatching work to the appropriate one.

> The situation is different with GPUs. My Radeon 5970 has 3200 cores. When the core count doubles, the FPS rating in games almost doubles. They definitely are not running Erlang style processes (one for GUI, one for sounds, one for physics, one for network). That would leave 3150 cores unused.

Graphics are an ideal application for data parallelism.  But those cores are all organizing their operations via messages passed on the system bus :-)  I know, that's kind of a lame out, even if it's true.