Intel juices parallel programming for the masses
Affinity for threads
OSCON A year after open sourcing its cross-platform Threaded Building Blocks (TBB), Intel has released what it called a "significant" upgrade to is parallel programming template library.
Intel used the O'Reilly Open Source Convention (OSCON) to announce TBB 2.1, with improvements for building - among other things - graphical user interfaces, applications using artificial intelligence, and network I/O.
TBB, for Windows, OS X and Linux, simplifies development of parallelism for C++ 32- and 64-bit applications. That's important for Intel, rolling out multi-core chips. According to Intel, TBB "abstracts platform details and threading mechanism for performance and scalability."
Among the changes in TBB 2.1, there's an "affinity partitioner" class to implement soft task-to-thread affinity while Intel claimed a four-fold improvement in OpenMP static scheduling for cases over its inaugural version of TBB. Tasks can be canceled and threads can be created for the GUI, I/O or network interface that are independent of the TBB task-scheduler worker threads. Thread checking and profiling has been improved to reduce false positives.
For the Windows crowd, there's also a TBB plug in to Microsoft's Visual Studio integrated development environment. You can see the full list of features here.
TBB 2.1 is available under the GPLv2 and comes in free and commercial editions.®
@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.
@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.
"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.