Intel juices parallel programming for the masses

if only my tasks were parallel

If I could just type all the letters of this message at one time, I could exploit the parallelism in my multicore chip. The sad fact that Intel doesn't want to hear is that a great majority of tasks are serial. Sure you can embed brilliant bits of parallism into searches and such, and a few tasks can run in parallel, like page updating and networking, but honestly, it's a serial world.

That means Intel won't be able to charge more and more each year for chips unless it finds a way to make uniprocessor performance continue to increase. Sucks for them, great for us.

The Professor vs. the Thread Monkeys

The strange thing about Intel's addiction to multithreading is that Professor Edward Lee, the head of UC Berkeley's Parallel Computing Lab, which is partially funded by Intel and Microsoft (another infamous bastion of thread monkeys), is known for rejecting threads as a viable solution to parallel programming. The Professor made big news a couple of years ago when he published his now famous "The Problem with Threads".

One is left to wonder, will Professor Lee cave in to the thread monkeys (like the gutless cowards at Stanford's Pervasive Parallelism Lab) or will he have enough huevos to tell them in their faces that they're full of crap? Time will tell.

UC Berkeley’s Edward Lee: A Breath of Fresh Air

http://rebelscience.blogspot.com/2008/07/uc-berkeleys-edward-lee-breath-of-fresh.html

Misconceptions

Getting the disclaimers out of the way first. I work for Intel and know the team working on TBB, so you're completely free to believe that I'm biased and ignore me completely.

There are some misconceptions in other comments which I can't let pass.

1) TBB adds nothing which you can't do with threads.

In a mathematical sense this is blatantly true, since TBB is itself built on threads. However it misses the point that TBB provides a major advantage over "raw" threads in that when you use TBB you think about how to split your problem into tasks and then let TBB choose how to execute the tasks for best effect on the current machine. You don't have to worry about how many threads to create, or how to distribute work to them. (Indeed you shouldn't even know how many threads are being used). Instead you focus on your problem and let TBB handle all of that complexity.

2) "Don't need vendor-specific help from Intel"

TBB is Open-Source (under one of the GPL licenses). Ports already exist for AIX/Power, Sun/SPARC, Cell etc. So "vendor specific" is just plain wrong.

3) Threads are a bad programming model

I agree, but given where we are, what do you suggest?

We all stop writing code for ten years while the academics sort it out? We all switch to Erlang? Occam? Prolog (which can be executed in parallel without requiring user input)?

The reality is that we have the machines we have. People are writing threaded code now and will continue to do so. TBB is an attempt to make that easier for them by lifting the level at which they do it, making it easier for them to get it right and have codes which scale as more hardware resources become available. We don't claim it's the ultimate solution (heck, it's in C++ and that's not the ultimate solution either :-). However it is available now, easy to add to existing code and provides simplifications and significant benefits over raw threads.

-- Jim

@Louis Savain

You still don't get it do you?

Threads are an efficient means of exposing potentially higher performance from processors with ever-increasing transistor budgets but per se are neither good nor bad; treating threads as a programming *model* is arguably bad. Hiding them away behind more sophisticated *models* is arguably much better. The threads are still there and being used, just in a controlled way.

You still haven't understood the difference between a *model* and an *implementation*, which is what that paper (thanks for that reference) was all about. To quote from the paper which you clearly haven't read (why should you, after all it was written by one of your reviled academics):

"The implementations shown in figures 3 and 4 both use Java threads. However, the programmer’s model is not one of threads at all."

And you could be a little more polite what with monkey comparisons and accusations that someone's 'full of crap'.

When your S2N improves I'll start looking forward to your posts.

@Hey Mr Intel: "we are where we are"

Hey Louis (cos I'm sure I recognise that cocky yet clueless style). They are different hence complementary. EPIC was instruction-level parallelism, threading is process-level parallelism. Entirely disjoint and orthogonal concepts.

@BlueGreen

Why be a Wintel anonymous coward? You are a gutless thread monkey and you're full of crap, that's all. See you around.

@Jim Crownie

"I agree, but given where we are, what do you suggest?"

Jim, I suggest we do away with threads altogether and there is no need to wait for the academics to sort it out. The academics are the ones who gave us the damn threads in the first place. However, it's good to see that not all academics are clueless arse kissers. UC Berkeley's Professor Edward Lee is a case in point.

There is a simple and infinitely better way to implement parallelism that does not involve threads at all. The only thing is that it will require a reinvention of the computer as we know it and a repudiation of the Turing machine as a viable computing model. This is the future of computing. Whether you or Intel like it or not, there is no stopping it.

Read "Parallel Computing: Why the Future Is Non-algorithmic" at the link below to find out why multithreading is not part of ther future of computing.

http://rebelscience.blogspot.com/2008/05/parallel-computing-why-future-is-non.html

@BlueGreen: "different yet complementary"

Hey BlueGreen, Louis didn't write the question you replied to (though he's been here since), I did.

But thanks for the compliment, and for showing that you have no real answer to the question I asked.

@AC: @BlueGreen: "different yet complementary"

Then I must apologise to you.

Nonetheless, I thought I answered the question, so I'll try again.

Modern processors can execute multiple instructions in parallel. They do this by examining the instructions stream and where possible, packing multiple instructions into a single box (like eggs in an egg carton) and then executing those instructions in parallel. All instructions in a box are executed together and it takes as long as the longest instruction and clearly those instructions must calculate unrelated results; you can't have instruction A in a box relying on instruction B in the same box. You also regularly have empty holes in the box which you can't safely fill.

Reordering and packing instructions this way *on the fly* has to be done at incredible speed. It makes sense to actually do this at compile time instead, which allows you to lose the complex and ultra-high-speed circuitry, and hopefully allow a bigger box more efficiently filled. This is the old idea of VLIW, which is what the (failed) EPIC processor was a type of. It allows a single thread to theoretically run faster. However, even with all that, it has its limits - you can rarely find more than a handful instructions to fit per box, so speedup is limited [*]

Threads - well, they work at the task/process level. You can have/not have threads with/without VLIW, in any combination. They are orthogonal concepts. Personally I guess both would be nice but intel fluffed it despite decades of VLIW research. Pity.

[*] even processors that dynamically reorder instructions on the fly like to have instructions somewhat pre-boxed, for easy recognition.