I’m typically logged into the Threading Building Blocks IRC channel (#tbb on FreeNode.net IRC). Last week, a community member noticed AMD’s new open source initiative, Framewave. He took a quick look at the project, and came back to tell us that, despite the use of the words “multicore” and “performance,” the library really isn’t like TBB, it’s not a generic multithreading framework that can be applied to multithread applications and libraries to take full advantage of multicore computers. Still, the Framewave project is interesting in that it illustrates the kind of computational power that multicore is capable of bringing to standard home and office desktops.
People have frequently disagreed with my assessment that general users will ultimately find many uses for all the new processing power that multicore brings to the desktop. The Framewave project is an illustration of the type of computation libraries I believe people will definitely find useful, once they recognize the possibilities these libraries offer.
For example, the Sourceforge Framewave page tells us that Framewave is:
a free and open-source collection of popular image and signal processing routines designed to accelerate application development, debugging, multi-threading and optimization on x86-class processor platforms.
Image processing and signal processing entail significant computation. As a result, in the past, these libraries were not brought into common desktop applications: the data manipulations would take too long to complete; few users would have wanted to wait for the processing to complete, regardless of what results were possible. Hence, applications such as Photoshop Elements and PaintShop Pro have stayed with simple image transformations, that can be performed in a fraction of a second, so the user can see the results immediately.
Multicore systems change this. The Framewave project (which uses the Apache licensing model) is a starting point.
I haven’t studied Framewave enough yet to know exactly how the algorithms have been tuned for high performance on multicore systems. You would think full multithreading would be required. I’ll look at that soon. The AMD Framewave page tells us that the framework’s API is compatible with the Intel’s Integrated Performance Primitives (Intel IPP), which is:
an extensive library of multi-core-ready, highly optimized software functions for multimedia data processing, and communications applications.
Looking more closely, we see that Intel IPP is itself in the same space as Framewave, offering algorithms for image processing, signal processing, vector/matrix mathematices, cryptography, and quite a bit more. The Framewave “API compatibility” statement tells us, then, that developers can create applications that apply both Intel IPP and Framewave.
Mix and match design
That implementation is reminiscent of the design of Threading Building Blocks, where you can create applications that mix traditional threads or OpenMP with whatever components of TBB you need. Of course, in the case of a math library that’s a collection of distinct functions, that’s almost the expected design. In TBB’s case, a non-monolithic design was only one of the possibilities. The fact that you can use TBB’s threadsafe containers (or memory allocators, etc.) in a native threads application is an enormous benefit. The correct design decision was made by the TBB team!
I plan to take a closer look at Framewave. If it’s not multithreaded already, it will be interesting to see how readily TBB could be applied to enable the library to take full advantage of modern multicore computers.