Intel Releases Threading Library Under GPL 2 158
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.'"
GPL 2 (Score:3, Informative)
"Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation"
You can of course get it as GPL 3....
I'm glad to hear it (Score:5, Informative)
Re:As if enough people weren't already confused... (Score:4, Informative)
Re:Looks good, but a little hampered by C++ (Score:1, Informative)
void main() {
class local {
public: void hello() { printf("hello world\n"); }
};
local::hello();
}
Oh, and if you are worried about cluttering up "the namespace", that's what namespace MySpace { } is for
Re:GPL 2 (Score:3, Informative)
Re:GPL 2 (Score:2, Informative)
No you can't.
Re:I'm thinking (Score:5, Informative)
And, if there was, well it's under the GPL now, and I'm sure someone would have added / corrected that mistake.
Re:GPL 2 (Score:4, Informative)
Simply put, you can link in the code as a library without worrying about LGPL's library requirements. (Namely the need to be able to replace the library with an upgraded version.) Intel notes that this is necessary for C++ libraries because of the way they have to be linked.
For the parent's code, I doubt he chose to have this clause in the GPL he chose, and it wouldn't be possible with his.
Re:As if enough people weren't already confused... (Score:4, Informative)
Agreed it does look to take a lot of the grunt work out of writing parallel-processing code. There are supposedly Java and
GPL 2 only (Score:3, Informative)
# Copyright 2005-2007 Intel Corporation. All Rights Reserved.
#
# This file is part of Threading Building Blocks.
#
# Threading Building Blocks is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public License
# version 2 as published by the Free Software Foundation.
There's no "Or Later" in there. This is GPL v2 only.
Re:This and XEN (Score:1, Informative)
Compatibility kinda sucks (Score:2, Informative)
I know this comes as a great surprise, but the OSes and processors this runs on are limited [intel.com]. If you want your programs to run on non-Intel platforms, or on any of the BSDs, I suggest you skip it and use something else.
Processors:
OSes:
Compilers:
P.S. Slashdot pulled out all the trademark symbols, and doesn't support the sup tag, so you'll just have to picture them in all the appropriate spots. :P
GPLv2 only (Score:3, Informative)
This doesn't surprise me much, actually - I imaging Intel wouldn't want to commit their code to an unknown future license, and I expect they're still evaluating GPLv3. Even if they were done with that evaluation, the process for releasing this under v2 probably took a LONG time to complete - Intel is after all a large corporation. Restarting with GPLv3 probably would have just delayed it, although I suppose the only ones who would actually know that work for Intel.
Re:Looks good, but a little hampered by C++ (Score:4, Informative)
Local classes / structs do not have external linkage and therefore can't be used as template arguments. So, for functors etc., which is precisely where you'd want something like a local class (ie. because you really want a closure), they are useless.
Hence why we have Boost lambda. Expect, and I agree with the GP, the syntax ends up so horrible (due to the constraints of C++, not in any way the fault of the Boost devs) that you end up not using it. Not a lot of point in trying to do something because it is technically cleaner and neater if it ends up unreadable and therefore unmaintainable (for that, there is always Perl).
Re:Nice Offering (Score:2, Informative)
http://softwarecommunity.intel.com/tbbWiki/FAQ/60
Re:Looks good, but a little hampered by C++ (Score:3, Informative)
Local _functions_ aren't in C++, but may be a GCC extension - which might be confusing you.
Neither Linux nor Intel specific (Score:3, Informative)
It is neither Linux nor Intel specific
http://threadingbuildingblocks.org/ [threadingb...blocks.org]
Cross platform support:
* Provides a single solution for Windows*, Linux*, and Mac OS* on 32-bit and 64-bit platforms using Intel®, Microsoft, and GNU compilers.
* Supports industry-leading compilers from Intel, Microsoft and GNU.
Threading Building Blocks supports the following processors:
* Non Intel processors compatible with the above processors
But the thing is (Score:4, Informative)
You'll find that this is rather evident in most games. While it is increasingly common to write large portions of the game in a scripting language since that make it easier to write and perhaps more importantly easier to mod, you'll find that the high speed stuff is still C++. Take Civ 4 for example. They wrote almost the whole damn game in XML and Python. All data (like unit definitions, technology tree, etc) is stored in XML files, all the scripting necessary to make them work is Python. Makes the game extremely easy to mod. However, the AI code, which they also released to end users, is in C++. The reason is that the AI is highly intensive and would have run too slow in Python. Also, the core engine of the game (not released to users) is C++ as well.
So it isn't surprising this is where Intel is targeting their optimisations. Also, I'd argue that to a large degree any of this kind of thing for a managed language is the responsibility of the runtime itself. If Java is to have better support for automatically threading things, the JRE is probably where that should be done.
Re:Compatibility kinda sucks (Score:4, Informative)
Re:PS3? (Score:4, Informative)
Re:GPLv2 only (Score:3, Informative)
I would not. The verbatim GPLv2 states:
If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
The verbatim GPLv2 does not prevent the licensor from specifying GPLv2, and programs licensed under "GPLv2" without "any later version" are expressly contemplated by the terms of the license.
They would also be in violation of the GPLv2 by having modified the version they are distributing, contrary to the terms of the license for distribution.
But they haven't.
However, anyone with a copy of this existing version would seemingly have the GPLv2 license in its original glory (and hence GPLv3 may apply).
And they do but it doesn't.
I haven't looked at the details; this is based on what you've just said. It's very interesting.
That is not an excuse. Your speculation concerning the terms of the GPLv2 had no basis in the grandparent's post.
A job for Fortran . . . (Score:3, Informative)
Fortran 90 and later already have the structures for this (Forall, etc).
*sigh*
hawk, who hasn't written a line in over two years
Re:I'm glad to hear it (Score:2, Informative)
Re:Compatibility kinda sucks (Score:4, Informative)
The commercial product information quoted does not include some ports which were completed for the open source project only days before the open source release.
Preparing for open source, we were able to get G5 for Mac OS X as well as support for Solaris and FreeBSD (both x86 and x86-64) working before releasing on Tuesday. It was tight - but they made it. I wasn't sure until the week before what we would have - but the team got them working. I think it will be easier now that the project is started - and we can let other join in to help us.
I should also say we got a bunch more Linux distributions working for builds too. We have tested them enough to see no issues - but we haven't enough experience to call them supported on the product pages (commercial product). Please look for the latest ports on the open source project threadingbuildingblocks.org. We'll work with anyone who has processors/system expertise and needs any advice we can offer. Understandably, we don't have a lot of non-Intel hardware inside Intel to test upon and we are hoping others can help a bit with that.
For compilers - we have gcc, Intel, Microsoft and Apple (gcc in Xcode environment) compilers all working with the builds. It seems like we may have something to do for Sun's compilers and/or environment working - some Sun engineers are in touch and helping us double check this. No schedule - just working together - which I have faith will get results to put out in an updated open source copy in the not too distant future - non-binding wish - this is not a promise
The biggest issues from processor to processor is knowing how to implement a few key locks, and atomic operations, best in assembly language. Since we have support for processors with both weak and strong memory consistency models - we know TBB is up to the task.
TBB is very strongly tied to shared memory, and so a port to a Cell processor (or a GPU) would be a bit more challenging - but might be doable for the Cell. We've had only a few discussions/thoughts - no progress I know of figuring out a good approach there. That will almost certainly take someone with more Cell experience than we have at this time. I'm open to learning - but I'd need a teacher for sure.
Re:Memory requirements - bummer (Score:2, Informative)
TBB really has minimal requirements of its own... using TBB won't really change the memory needs enough to worry about it.
I'll see if we can find a way to update the web page so it makes sense. Sorry for the confusion.
The concurrent containers are much more scalable than those in STL - much more scalable. The queue, vector and hash table we provide are much better choices in a threaded application (with or without the other features of TBB) than using STL containers.
The scalable memory allocator is definitely a gem. The library for it is completely separate from the rest of TBB - so definitely a good place to start if you have a threaded application which still calls malloc()