Slashdot Mirror
Intel Releases Threading Library Under GPL 2
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.'"
As the GPL 2 they link to says:
"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 attended a seminar about this at GDC (Game Developers Conference) this year. It is really nifty stuff, automatically parallelizes things for you and helps take the load off of the OS scheduler. It is also trivial to implement in many cases, for instance there are parallel loops that execute things in parallel, all you have to do is write it like a normal loop but use a different keyword (ok so it is a wee bit more involved, but you get the idea). If I recall correctly it is basically a thread-pool that manages scheduling itself better than the OS because it knows ahead of time the needs of the code. Also you don't have to know the # of cores or anything as it handles that transparently. Also it isn't limited to Intel processors, I'm pretty sure at GDC it was actually being demoed on some sparc machines. If I had the time and/or a reason to use it I would definately investigate further.
If you are about to mod me down, keep in mind that this post was most likely sarcastic.
Thats the thing, it makes programming easier by making the whole parallel thing a bit more transparent. Basically picture a foreach loop. This thing allows you to do the same thing but instead can do multiple instances of the loop at once and automatically uses the "optimal" number of threads based on the cores available, you just have to call parallel_for. It's not quite as simple as that but it certainly does take the grunt work out of parallelizing things.
If you are about to mod me down, keep in mind that this post was most likely sarcastic.
Believe it or not, but there is nothing stopping you from declaring structs and classes inside a function.
:P
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
The AMD question was raised on their Forums, and there is no issues with TTB running on AMD CPUs.
And, if there was, well it's under the GPL now, and I'm sure someone would have added / corrected that mistake.
III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIII
Agreed it does look to take a lot of the grunt work out of writing parallel-processing code. There are supposedly Java and
Just junk food for thought...
From the Development download src/tbb/Makefile:
# 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.
So.. it has come to this
No. Xen can only run on certain processes when using unmodified OS's (like XP since they don't have the source and can't modify it) because the older processes lack the hardware instructions required to make it possible. This threading library from Intel just makes it easier to write some multi-threaded software, it doesn't fix deficiencies in the VM support of older chips and of course nothing ever will.
I know this comes as a great surprise, but the OSes and processors this runs on are limited. 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
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
As near as I can tell, this is GPLv2 ONLY (without the "or any later version" clause). Checking a random source file in the distribution, there is no "later version" language present.
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.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Erm, yes, C++ has local classes, however there is a "BUT" and it's a big one:
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).
http://softwarecommunity.intel.com/tbbWiki/FAQ/60
Local classes are definitely standard, section 9.8 I think.
Local _functions_ aren't in C++, but may be a GCC extension - which might be confusing you.
That intel figured out that 5 percent market share mattered a whole lot when it's only a two player game, and it's running close. Obviously, if intel can control the entire *NIX world, AMD is in for some hurt.
It is neither Linux nor Intel specific
http://threadingbuildingblocks.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
C++ (or C) is where all the fast code is still written. Thus it is the most relevant place for this kind of thing. If you look at Intel's page, you'll see they sell compilers, but only for two languages: C/C++ and Fortran. The reason is that their compilers are specifically to get as much performance as possible on an x86/x64 chip. So they target the languages people use when they are performance oriented. There are lots of other great languages out there, but face it, you aren't (or at least shouldn't) be using a managed language like Java when every last clock cycle counts.
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.
Just junk food for thought...
No, not FORTRAN IV, or even 77 . . .
Fortran 90 and later already have the structures for this (Forall, etc).
*sigh*
hawk, who hasn't written a line in over two years
Sorry - the requirements are more about the likely memory needed on a system for that OS + a C++ program, etc. In other words - have a system with 512M in general, not for TBB. This is confusing me now!
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()