Forgot your password?
typodupeerror
Intel

Intel Releases Threading Library Under GPL 2 158

Posted by CmdrTaco
from the of-interest-to-some-of-you dept.
littlefoo writes "Intel Software Dispatch have announced the availability of the Threading Building Blocks (TBB) template library under the GPL v2 with the run-time exception — so this previously commercial only package is now open for all the use, whether for open-source projects or commercial offerings (although they are explicitly encouraging open source use). The interface is more task-based then thread-based, but with a somewhat different view of things than, e.g. OpenMP. From the Intel release: 'Intel® Threading Building Blocks (TBB) offers a rich and complete approach to expressing parallelism in a C++ program. It is a library that helps you leverage multi-core processor performance without having to be a threading expert. Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that abstracts platform details and threading mechanism for performance and scalability.'"
This discussion has been archived. No new comments can be posted.

Intel Releases Threading Library Under GPL 2

Comments Filter:
  • Woohoo (Score:3, Insightful)

    by jshriverWVU (810740) on Wednesday July 25, 2007 @10:07AM (#19982825)
    If it's as smooth as the Intel C compilers this ought to be a treat. Now if only they'd release the icc under a similiar license.
  • by malfunct (120790) * on Wednesday July 25, 2007 @10:12AM (#19982875) Homepage
    I find it interesting that the original poster took the trouble to differentiate between open source and commercial offerings as if there has to be a difference.
  • by TomorrowPlusX (571956) on Wednesday July 25, 2007 @10:15AM (#19982897)
    I looked at some of the tutorials yesterday, and I believe I'm going to dip my toes in this.

    But. As much as I love C++ ( and I do ) the real weakness is the lack of usable closures/lambda. The parallel_for example requires you to pass a functor to execute on ranges, which is fine, it makes sense, but since you can't define the closure in the calling-scope in C++ you end up filling your namespace with one-off function objects.

    This is not a critique of TBB, but rather of C++. In java I can make an anonymous subclass within function scope. In python and hell even javascript I can make anonymous functions to pass around. But in C++ I can't, and this means that my code will be ugly.

    Not that this is new news. I use Boost.thread for threading right now, and most of my functors are defined privately in class scope ( which is, at the very least, not polluting my namespace ) but it's too bad that I don't have a more elegant option in C++.

    That being said, Boost.lambda makes my brain hurt a little, so my complaints are really just a tempest in a teacup. If I were smarter and could really grok C++ I could probably use Boost.Lambda and this would be a non-issue.
  • Re:CS courses (Score:2, Insightful)

    by IndieKid (1061106) on Wednesday July 25, 2007 @10:39AM (#19983143) Journal
    Like most things in CS, I think it's important to understand the theory of writing multi-threaded applications before letting software do it for you.

    That said, I'm sure most CS courses teach at least the basics of memory management, but people are still happy to rely on the Java garbage collector ;-)
  • by cheekyboy (598084) on Wednesday July 25, 2007 @10:58AM (#19983419) Homepage Journal
    How many stupid generic functions do you need to 'multi-core' jeez man!

    Besides how hard is it to multicore manually, you can either subdivide a major loop, if its warranted, if it lasts 1us then its useless or
    you might as well subdivide at the highest level. ie AI/AUDIO/3D

    Javascript, even if running on 16 5ghz cores, would still be slower than 1 core 3ghz, so its a mute benefit of its 'magic functions'

    I wouldn't want to depend on a generic system to make my random function appear faster, rather design it well in the first place.

    You can always use random function pointers to do your 'magic extensions' if you want, but why not design it well first.

    The last thing the industry again needs, is lots of lame code SUCKING both cores and making PCs slow again, i rather have the other core free
    to do my background OS or ripping or encoding or anything other. I dont care if said function takes 12ms vs 7ms.

    If its specialized, like video encoding or hours of maths, then yes, multi-core your code properly, but not lame 100x slow functions to run 2x faster, when better
    coding might make it 50x faster. Remember, excessive memory movement and reinitilization in each iteration is what causes more waste.

  • by ookabooka (731013) on Wednesday July 25, 2007 @12:26PM (#19984775)
    Well. . .c++ abstracts away from ASM, so is it bad too? Abstraction isn't a problem really, especially when it handles a bunch of grunt work correctly and efficiently. Yeah some programmers might not understand exactly what they are doing, but tools that add a layer of abstraction are OK in my book so long as they don't make things more complicated or grossly inefficient. Besides, if you really wanted to do it differently you could either modify the GPL code or write it from scratch. Hopefully, handling threads manually will become like inline assembly, there for people that need that low-level access but an easier and more abstract way of doing things is readily available (regular C/C++ code). Honestly I think libraries like this are going to be more and more common, multi-core is definitely the way of the future and it will take a whole new set of tools and programming paradigms to really harness it. Most programming languages weren't designed with the notion of parallelizing everything.
  • Re:I'm thinking (Score:3, Insightful)

    by Phroggy (441) <slashdot3 AT phroggy DOT com> on Wednesday July 25, 2007 @01:50PM (#19985971) Homepage
    Intel wants TBB to be ubiquitous. Not only can you run it on AMD, you can run it on PPC. However, they did say that they don't have very many G5 Macs at Intel, so the engineers say the PPC port is "alpha quality".

After an instrument has been assembled, extra components will be found on the bench.

Working...