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.'"

Comments

I'm thinking

[Nikron]

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.

Re:I'm thinking

[hrieke]

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.

Re:I'm thinking

[Phroggy]

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".

Re:I'm thinking

[Anonymous Coward]

AMD is making nothing, nothing, nothing!!! 0% of its software was put to the public!!!

Intel is more generous releasing software to the community: ORP, TBB, Harmony, ..

As if enough people weren't already confused...

[nokilli]

...by threading. That description makes me want to go back to my abacus.

--
Censored by Technorati and now, Blogger too!

Re:As if enough people weren't already confused...

[ookabooka]

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.

Re:As if enough people weren't already confused...

[Doctor Memory]

it makes programming easier by making the whole parallel thing a bit more transparent I'd argue that it makes things more opaque, by abstracting away the need to explicitly deal with threads. Instead, you just define "tasks" that can run concurrently, and the toolkit takes care of mapping the tasks to actual threads.

Agreed it does look to take a lot of the grunt work out of writing parallel-processing code. There are supposedly Java and .NET versions under development, it'll be interesting to see if they're able to implement the concepts as cleanly as in C++. My guess is both implementations will be a little "clunky" (cumbersome and less efficient).

Re:As if enough people weren't already confused...

[ookabooka]

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:As if enough people weren't already confused...

[Anonymous Coward]

C# has something called the CCR - Concurrency and Coordination Runtime.
As the developers themselves are well aware of, gluing "true" concurrency onto procedural languages such as C/C++/C#/Java will always be "ugly".
There is actually a microsoft labs-developed "fork" of C# called COmega which tries to integrate concurrent programming more tightly into the language.

Just to point out:
1) C# is actually further along in some ways to realizing true and easy-to-use concurrent programming (also ref C# 3.5).
2) Modern C++ could hardly be considered clean or simple -- It's a huge and complicated language, ever changing and with arguably the most dense syntax this side of perl. Not that there's anything wrong with that, but C++ is fast approaching a lisp-like state of unapproachability imho.

Re:As if enough people weren't already confused...

[Doctor Memory]

c++ abstracts away from ASM, so is it bad too? Um, I wasn't saying it was bad, I just meant that referring to something as "transparent" usually implies that it makes it easier to see the implementation beneath. I thought "opaque" was more appropriate, because TBB obscures the details normally associated with writing multi-threaded code. I'm all in favor of abstracting away any details that tend to be tedious or error-prone. Especially when it comes to multi-threading, since AFAIK there haven't been any real breakthroughs in parallel algorithms, so there aren't too many proven techniques to apply.

Re:As if enough people weren't already confused...

[maxwell demon]

Well, "transparent" is used in two different ways. One is to mean you can see inside, i.e. can see the inner workings, the other is to mean you hardly see it at all, like the transparent air you normally look through without noticing it. Here obviously the second meaning is used.

Re:As if enough people weren't already confused...

[stony3k]

I suggest you take a look at java.util.concurrent.* library to give you an idea how easy it is to use concurrent programming in Java.

Woohoo

[jshriverWVU]

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.

GPL 2

[raffe]

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....

Re:GPL 2

[phantomlord]

If the Program specifies a version number of this License which applies to it and "any later version", ... You can of course get it as GPL 3 If the program specifies a version number AND "any later version."

Try to take my very crappy and unimportant GPLv2 code (note, not GPLv2 or any later version) and relicense it/use it with GPLv3 code and you'll be getting a letter from my lawyer. I dare you to do it to IBM.

Re:GPL 2

[PhrostyMcByte]

The source explicitly says version 2. The "any later version" clause was left out.

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.

Re:GPL 2

[onecheapgeek]

Is the license 'GPL v2' or 'GPL v2 or later'?
Version 2, Changed by RANDY SMITH on 7/21/2007
Created by: RANDY SMITH
GPL v2. Later versions will be reviewed, when final, for future consideration.

No you can't.

Re:GPL 2

[ookabooka]

You actually reminded me of an interesting point, since it is released under GPL and not LGPL can you dynamically link to it? LGPL allows you to dynamically link but GPL doenst? I can't remember the technical differences between the two. Obviously the point being that is if you utilize the GPL version of the library can you make proprietary programs?

Re:GPL 2

[Aladrin]

It depends on which version of the GPL you use. There's a 'runtime exception' version (That Intel chose for this project) that allows you MORE freedom than the LGPL in the case of libraries.

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:GPL 2

[Anonymous Coward]

Intel notes that this is necessary for C++ libraries because of the way they have to be linked. Actually that's libstdc++ noting that - the Intel site linked straight through to GCC's page about the libstdc++ GPL-with-exception.

Re:GPL 2

[sumdumass]

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"

Actually it says (and "any later version").The part of the program that says this is licensed under the GPL would have to say the "OR" version. The portion you and many others who don't know the GPL well enough to discern the intent pick the part outside the GPL entitled how to apply this for reference. It isn't part of the GPL and it isn't anything other then how to apply the GPL to a new program. And to that point, it is only a guidline on applying it because you can specifically remove parts of the license, more specifically (and later version). The GPL is what you need to look at and be concerned with.

I'm starting to see this from a lot of novice GPL users and I'm wondering if it isn't the intent of the "how to apply section". It would appear they the wording difference is there to intentionally mislead people so little snots like this AC can jump up and grab your code on a technicality. I'm saddened to see that this is what the GPLv3 is becoming about, getting things on a technicality. Anyway, I would hope this is representative of a few mental midgets and not the entirety of the FOSS community.

Anyways, you couldn't pull this into GPLv3 because you would have to have the right to give everyone else the ability to use any patents that the GPLv3 mandates. You will find that pulling stuff over without this ability will lend yourself into severe legal distress if the owners decide to go back on it. Sure, your defense might be the latewr version clause, but they will says the same spirit and then note giving away their patent rights isn't in the spirit of the GPLv2. My suggestion is to tread lightly around issues like this and make sure you are in the clear on them. Else wise you may be poisoning anyone who uses the code after your changing of the license as well as finding yourself in a large bit of legal troubles. Buy placing the code under the GPLv3, according to the patent sections, you are the one authorizing the use of the patents, not the person who placed it under the GPLv2.

Re:GPL 2

[TheRaven64]

You actually reminded me of an interesting point, since it is released under GPL and not LGPL can you dynamically link to it?

I know reading the article is too much to ask for on Slashdot, but if you'd read the summary then you'd know that it is GPL'd with a specific exemption allowing linking. It's only in the first sentence though, so I can see you might have had problems getting that far.

Re:GPL 2

[Repossessed]

So does this mean it will or won't be compatible with upcoming GPL3 versions of GCC?

For that matter, will it or won't it be compatible with proprietary compilers?

Re:GPL 2

[Aladrin]

The fact that you ask that means you don't understand the GPL as it regards works created by GPL'd software.

Simply put, anything created BY the software does not matter. The GPL says nothing about that.

If you make a Word document in Open Office, is that document GPL'd? No. It's the same here. The binary that is created does not fall under the GPL as it is merely considered a document.

Again: The GPL3'd GCC can still compile programs that use ANY license, just as the GPL'd GCC can do today. The only difference is that you will not be allowed to run the GPL3'd GCC on a device that doesn't comply with the GPL V3's requirements.

Re:GPL 2

[phantomlord]

The compilers don't matter... what does matter is that GPL3 code is incompatible with GPL2 code so you cannot copy this code into GPL3 programs you write unless Intel re-licenses it as GPL2/GPL3 code. If they never change the license on it, welcome to the software divide created by the FSF in their zeal to make the GPL3 incompatible with GPL2.

Re:GPL 2

[Repossessed]

Um... I don't think you understand what I'm asking, or maybe I misunderstand what this thing is for. I was asking if it would be possible to incorporate Intel's code into GCC and make it a standard part of the compiler.

It occurs to me, upon further reading, that this may not be necessary though, and that Intel's code would become part of the final program instead of part of the compiler.

Re:GPL 2

[Aladrin]

While it might be possible to use the code to create a more efficient multi-processor aware compiler, that wouldn't mean much to the compiled programs.

You are correct that Intel's code would be used by the final program. (I hesitate to say 'become part of' because it's still a seperate library, just used by the program. When you wear glasses, they don't become part of you, no matter how necessary they are to your continued existance.)

Re:GPL 2

[Anonymous Coward]

If you'd read your post before clicking the "Submit" button, then you'd know that you had used two "<blockquote>" tags, when the second one should have been "</blockquote>".

But I guess that using the "Preview" button is too much to ask for on Slashdot, so I can see that you might have had problems getting that far.

Re:GPL 2

[DragonWriter]

The compilers don't matter... what does matter is that GPL3 code is incompatible with GPL2 code so you cannot copy this code into GPL3 programs you write unless Intel re-licenses it as GPL2/GPL3 code.

That depends on what you mean by "copy". Since it uses the "runtime exception", you can link to the library in a program released under any licensing models you want, you just can't modify the library itself and distribute it other than under the GPL.

Re:GPL 2

[phantomlord]

Which is why I said "copy this code into" rather than "link." As in, you can't copy portions of the code into the gcc compiler tree now that it is GPLv3. You are entirely free to link it, however.

Re:GPL 2

[mhall119]

The compilers don't matter... what does matter is that GPL3 code is incompatible with GPL2 code so you cannot copy this code into GPL3 programs you write unless Intel re-licenses it as GPL2/GPL3 code. If they never change the license on it, welcome to the software divide created by the FSF in their zeal to make the GPL3 incompatible with GPL2. It depends on if Intel licensed this code "under the GPL version 2" or "under the GPL version 2 or (at your option) any later version". If they included the "any later version" option, then it can be included into the GPLv3 GCC. If not, then your statement is correct.

Re:GPL 2

[mhall119]

The GPL3'd GCC can still compile programs that use ANY license, just as the GPL'd GCC can do today. The only difference is that you will not be allowed to run the GPL3'd GCC on a device that doesn't comply with the GPL V3's requirements. Just a minor correction to an otherwise informative post. You will be able to run GPLv3 code on a device that doesn't comply with the GPLv3's requirements, you just won't be able to distribute GPLv3 code on that device. The GPL (v2 or v3) doesn't stop you from modifying or running it however you want, it only puts requirements on your distribution.

Re:GPL 2

[phantomlord]

It depends on if Intel licensed this code "under the GPL version 2" or "under the GPL version 2 or (at your option) any later version". If they included the "any later version" option, then it can be included into the GPLv3 GCC. If not, then your statement is correct. Read the license... it is GPLv2 only at this time. They may release it under GPLv3 as well at a future date but I'm sure the license is under legal review atm and most companies aren't going to release code under a license that they haven't vetted yet.

Re:GPL 2

[mhall119]

Thanks for the clarification. I know I could have read the license, I was just being lazy. I knew someone would tell me anyway, that's what I love about slashdot.

Just great...

[doombringerltx]

I've been saving up for school lately and one of the hardest parts has been talking myself out of upgrading my aging Pentium 4 box. There goes my "not enough programs make use of the extra cores" arguement. Next they are going to start making DX10 only games and Vista will stop sucking and I'll really be in trouble

Re:Just great...

[CogDissident]

Some of those DX10 only games are actually compatable with DX9, if you patch them with some "independant" patches... I currently have shadowrun running on my 64bit XP computer.

Open-Source vs Commercial?

[malfunct]

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.

Re:Open-Source vs Commercial?

[Anonymous Coward]

I'm sure when writing "commercial", he meant "proprietary".

Re:Open-Source vs Commercial?

[littlefoo]

I'm sure when writing "commercial", he meant "proprietary".

Cheers - that would indeed be what I intended.. think my brain was still on the 'commercial' earlier in the paragraph.

Re:Open-Source vs Commercial?

[HiThere]

And that's wrong too.
The contrary of open source is closed source.
The contrary of commercial is non-commercial (too many angles on that one: not for profit, public, etc.)
The contrary of Free (libre) is enslaved.
The contrary of Free (gratis) is costly.

Proprietary is the contrary of public domain. (Note that public domain is ONE of the contraries of commercial...but not an exact match. Most commercial activity requires non-public-domain material or informational components.)

I'm glad to hear it

[ookabooka]

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.

Re:I'm glad to hear it

[Viol8]

"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."

I think you're getting confused. Once threads are created they're scheduled by the OS whether they like it or not. An app can't do its own scheduling other than simply halting or not halting a thread though obviously it can decide when to create/destroy threads or allocate data to specific threads.

Re:I'm glad to hear it

[High Hat]

This is not quite correct. There is so-called OS-level threading, which you are referring to, and runtime or language-level threading, which is not managed by the OS. It is well possible that the latter is the case here, although I'm too lazy to RTFA...

Re:I'm glad to hear it

[joib]

I think you need OS-level threads if you want to utilize multiple cores, so user-level cooperative threads sound a bit useless in this context.

Looks good, but a little hampered by C++

[TomorrowPlusX]

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:Looks good, but a little hampered by C++

[Anonymous Coward]

Believe it or not, but there is nothing stopping you from declaring structs and classes inside a function.

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 :P

Re:Looks good, but a little hampered by C++

[MassacrE]

See the proposal for the next gen of c++:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers /2007/n2329.pdf

Re:Looks good, but a little hampered by C++

[cheekyboy]

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.

Re:Looks good, but a little hampered by C++

[TomorrowPlusX]

I was under the impression that that's a non-standard extension to C++ in GCC.

Re:Looks good, but a little hampered by C++

[ray-auch]

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).

Re:Looks good, but a little hampered by C++

[Anonymous Coward]

You can of course declare your functors in an anonymous namespace, thus making them invisible to otehr translation units.

Re:Looks good, but a little hampered by C++

[gbjbaanb]

i rather have the other core free I don't know your setup, but you've made the schoolboy error of assuming that everyone has 2 cores. I suppose in the future, you'll be the guy complaining that your new 64-core CPU only uses 2 of them, "why can't app writers figure out how many cores I have and use them all"

You don't need a core free to run apps, and having functors is a well established C++ paradigm for creating code, they're not any worse than calling a simple C function (even if they look strange sometimes - the compiler does all the work to make them simple).

Re:Looks good, but a little hampered by C++

[Timothy Brownawell]

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.

Do you know why that restriction is there? I hadn't been aware that this was possible before now, probably entirely because that restriction makes them mostly useless.

(And yes, that restriction seems bizzare enough that I went and found someplace that quotes the standard to verify it.)

Re:Looks good, but a little hampered by C++

[Rakshasa Taisab]

But. As much as I love C++ ( and I do ) the real weakness is the lack of usable closures/lambda.

Then I guess you'll be happy to hear that the proposal for lambda expressions is well on its way to getting included in C++09.

Re:Looks good, but a little hampered by C++

[ray-auch]

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.

Re:Looks good, but a little hampered by C++

[ray-auch]

Do you know why that restriction is there

No - you'd need to ask someone close to the history of the standards process.

There are / have been proposal(s) to remove this limitation. The standards process grinds along pretty slowly - but it may happen, one day.

Re:Looks good, but a little hampered by C++

[ookabooka]

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. . .

Well with a library such as this your code doesn't have to keep track of how many threads it is supposed to use or how many are available. You just write some parallel loops/functions and the library will scale the # of threads accordingly. I don't believe it would be all too difficult to explicitly tell the lib the number of threads to use (N, N/2, N-1, etc. where N is # of cores on system). Trusting each programmer to individually code this dynamic number of max threads is a far worse option than having a lib you can tweak IMO.

Re:Looks good, but a little hampered by C++

[Anonymous Coward]

You should look at Phoenix. You really do not need to be that smart to use it. Check the examples here. Note that Phoenix and Boost.Lambda are planned to be merged in the near future.

Re:Looks good, but a little hampered by C++

[Nova77]

You still can do local functions using the lambda library in boost.

Re:Looks good, but a little hampered by C++

[smitty97]

public: void hello() { printf("hello world\n"); }

Hey! you're the iPhone Hacker!

Re:Looks good, but a little hampered by C++

[drxenos]

Yeah, except (1) your code is invalid (hello would have to be static), and (2) you cannot instantiate a template from such a class, thus invalidating its use for lambdas.

Re:Looks good, but a little hampered by C++

[Anonymous Coward]

Um, main returning void is an invalid form as far as the Standard is concerned.

Re:Looks good, but a little hampered by C++

[Anonymous Coward]

Informative??? Do you or the mods even know C++? Besides the problems already mentioned, your comment about using a namespace is just plain wrong. You cannot define a namespace inside a function.

Re:Looks good, but a little hampered by C++

[Anonymous Coward]

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).

Actually, Perl's syntax for closures is pretty readable!

Re:Looks good, but a little hampered by C++

[HiThere]

That number had BETTER either be an environmental variable, or something else that can be detected at run time. Otherwise you have to run the program on a machine with the same number of cores as you compiled on.

Re:Looks good, but a little hampered by C++

[Abcd1234]

What do you mean "even in Javascript"? Javascript is probably one of the most widely used mixed functional/OOP programming languages out there. Even more unusual, it's a prototype-based language (along the lines of Self), allowing you to do cool things like augment classes at run-time. It's actually remarkably powerful, and IMHO, a damn sight better than many of the more popular scripting languages out there (I'm looking at you, Python, with your crippled lexical closures). Pity few seem to understand this...

Re:Looks good, but a little hampered by C++

[Old Wolf]

void main() {
This is an error in C++ (although your compiler might support it as a non-standard extension)

class local {
                public: void hello() { printf("hello world\n"); }
        };
        local::hello();

Must either declare 'hello' static, or call it as:
    local().hello();

Oh, and if you are worried about cluttering up "the namespace", that's what namespace MySpace { } is for :P

Actually that's what the unnamed namespace is for:
    namespace {
        struct foo.......
    };

Re:Looks good, but a little hampered by C++

[Bill, Shooter of Bul]

Granted, javascript gets dissed cause its client side and the clients don't always agree on how things should work. Make it a server side content delivery lang and then we'll talk.

Re:Looks good, but a little hampered by C++

[Gotebe]

In java I can make an anonymous subclass within function scope.

Would this work even if the code is executed in another thread's context (i.e. another stack). I am asking because I can't see how anything function-scoped that, accesses stack objects of that function can work once function has finished, which is the case here?

Re:Looks good, but a little hampered by C++

[shutdown -p now]

But. As much as I love C++ ( and I do ) the real weakness is the lack of usable closures/lambda.

Good thing we will (relatively) soon have C++09 fix this problem.

Re:Looks good, but a little hampered by C++

[Abcd1234]

ROFL, by that metric, lisp and Smalltalk are poor languages (though, in the latter case, that's changing with Seaside). Different languages have different strengths and weaknesses. Would I use JS for server-side content delivery? I don't know. But I do know that's not the yardstick by which I judge the merits of a language.

Re:Looks good, but a little hampered by C++

[kabz]

I believe the answer would be that the stack frames live on the heap, and you have to bind in the appropriate stack frame to the code that accesses the capture variable.

The interesting paper on adding lambda/closures to C++ looks very like it maps a lambda to a function object. The key here, is that the function object cheats by being on the heap so you have access to copies of captured variables when you call the closure. Not sure how this would work if you tried to communicate between two closures using the same captured variable. It would need to be a reference in that case, so is probably not applicable to stack allocated vars in C++.

It's oddly comforting to know that my PS-Algol knowledge is still somewhat useful after all these years. It's a shame there doesn't seem to be an open source compiler for it out there. Java is way too baroque for my tastes.

Nice Offering

[coren2000]

This is a nice offering by Intel. I expect it will drive interest in the commercial product, as developers will learn on the GPL version, but develop proprietary software with the commercial (sounds fair to me).

Any reviews for:
1) benchmarking
2) development ease

Re:Nice Offering

[origin2k]

Actually you can build commercial products using this new library, taken from their FAQ

What is GPL v2 with the runtime exception?
Version 1, Changed by RANDY SMITH on 7/21/2007
Created by: RANDY SMITH
GPLv2 with the runtime exception is the license under which the source code of libstdc++ is distributed (see gcc.gnu.org/onlinedocs/libstdc++/17_intro/license. html). This 'runtime exception' is therefore a standard for distributing template libraries - and that is why TBB uses it.

http://softwarecommunity.intel.com/tbbWiki/FAQ/606 .htm

Re:Nice Offering

[coren2000]

Ohhh... groovy!

Re:Nice Offering

[spitzak]

With the "runtime exception", the GPL version *is* the commercial product (assuming by "commercial" you mean "can be used in closed source").

task based then thread based

[DrSkwid]

Intel are being curiously quiet about such a remarkable breakthough!

Re:task based then thread based

[Holi]

>There are 11 types of people in the world, those who know binaries and those who don't.

Obviously you are in the those who don't group.

Re:task based then thread based

[dubbreak]

I fixed it for him:

There are 11 types of people in the world: those who know binaries, those who don't and those who don't.

The then/than mixup is kind of funny though. Reminds me of something I read in the engineering faculty on a white board (I assume a first year engineer):
"I'd rather be retarded then do my engineering homework.."

Looks like he had the pre-requisite fulfilled and should have just got on with the homework.

Re:task based then thread based

[networkBoy]

> You might as well blame me, everyone else does.

And obviously it's your fault.

Re:task based then thread based

[Framboise]

Variation: There are 1 types of people in the world, those who program in C, and those who don't.

Re:task based then thread based

[DrSkwid]

Obviously you are a know-it-all prick that doesn't know as much as he thinks he knows, thanks for playing.

Re:task based then thread based

[sparcnut]

There are 11 types of people in the world, those who know binaries and those who don't.

s/binaries/Gray code/ ?

Re:task based then thread based

[Anonymous Coward]

There are 10 types of people in the world, those who know binary, those who don't, and those who mistake it as trinary.

There are 11 types of people in the world, those who know binary, those who don't, and those who are tired of this joke.

Re:task based then thread based

[Phroggy]

There are two types of people in the world:

1) those who don't use zero-based array indices, and
1) those who do

Re:task based then thread based

[GaryPatterson]

nice!

Re:task based then thread based

[Anonymous Coward]

Nah, he just meant uninary..

Re:task based then thread based

[Holi]

thanks i needed a laugh about now.

Re:task based then thread based

[Holi]

huh

0 = 0
1 = 1
10 = 2
11 = 3
and so on
  or am I mistaken?

Re:task based then thread based

[DrSkwid]

That is, indeed, one form of binary encoding. There are more.

Try it with the columns having 5,3,1,1 as their values instead of 8,4,2,1

Great news!

[jgarra23]

Hopefully their compiler will follow suit. This sounds like a great move for Intel especially since the lion's share of income is from processors & semi-conductors this will encourage more people to use their tools.

CS courses

[Anonymous Coward]

So does this encourage or discourage instruction on multi-threading in CS courses? In the courses I took there was very minimal discussion about designing multi-threaded applications. It would be interesting to know whether "modern" courses actually promote efficient techniques, or do such templates become a cop-out- "Let the system do it for you", rather than conscientiously designing an efficient program.

Re:CS courses

[IndieKid]

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 ;-)

Re:CS courses

[realthing02]

It'll be interesting to see what happens. I learned threading by building an OS in school, and i'd imagine many other have done or will do the same. As for thread specific coding, i'm not sure if classes will teach an intel approach, i suppose that will depend on how much money is donated to their school.

Re:CS courses

[gbjbaanb]

and that's why we have apps that use up so much memory they perform amazingly poorly (.NET included)

Re:CS courses

[the_greywolf]

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.

I'm still waiting for someone to explain to me why this isn't even touched on in most CS programs.

In fact, I'm still waiting for someone to help me understand it. :\

This and XEN

[WED Fan]

Question: With this now GPL2 and open source, will this fix one of the problems of XEN?

XEN can only be run on certain processors when used with particular OSes, XP, namely. And, as I understood it, it was because of the threading. If XEN incorporates this into their system, will this open the door?

Re:This and XEN

[Anonymous Coward]

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.

Re:This and XEN

[TheRaven64]

If you have a sensible architecture, then every instruction that modifies some bit of global scope will raise an exception if you try to execute it outside of privileged mode. This is not the case on x86, where there are 17 instructions that silently fail if run outside of ring 0 (the highest privilege level on x86). When you are writing a virtual machine monitor, or hypervisor, you need to emulate all of the privileged instructions so that a guest operating system can run without interfering with other guests.

Due to this limitation, virtual machines on x86 used one of two work-arounds:

• Binary re-writing, where the instruction stream is scanned for privileged instructions, and these are replaced by jumps to the emulated versions (and a lot of other tricks to get around side-effects of doing this). This is what VMWare does.
• Paravirtualisation, where you replace all of the occurrences of privileged instructions with something like a system call (a hypercall), which performs the operation on behalf of the guest. This is what Xen does.

Paravirtualisation is fast, and less error-prone than binary rewriting (which has a huge number of irritating corner cases you have to cover), but it has the disadvantage that it requires fairly considerable modification to the running guest, on a source-code level. You could, in theory, write a scanner that would read a binary and replace all privileged operations with jumps to a library that performed hypercalls, but no one has done this. This means, you can't run an operating system on something like Xen without access to the source code.

This changed somewhat recently. Both Intel and AMD added extra modes to their latest chips which can be used to trap all privileged instructions, allowing pure trap-and-emulated virtualisation. By using this, Xen can run unmodified guests, although they are slower than paravirtualised ones. Since this feature is highly dependent on hardware support, it will only work on chips with the correct hardware assistance mode.

None of this has anything to do with a threading library, however. I don't know quite where you got that idea from.

Re:This and XEN

[Abcd1234]

No, it has nothing to do with threading (or, if it does, only incidentally). As I understand it, on the IA-32, for the most part, instructions, memory accesses, etc, can be trapped by the hypervisor with the help of the CPU, which allows those instructions to be virtualized. However, there are certain CPU sensitive instructions (those which modify the system state in a way which must be virtualized) which are not properly virtualizable on old CPUs, as their execution cannot be trapped. Consequently, XEN takes the easy way out, placing restrictions on the instructions which may be executed, thus requiring modifications to the guest OS. See this page for a list of sensitive, non-virtualizable instructions on the IA-32.

Burning question... comparison to OpenMP?

[Anonymous Coward]

Aside form the fact that TBB semms to be C++ only, while OpenMP is available for C/C++ and Fortran77/9x (and obviously much more mature), can anybody comment on the
pros/cons between this new TBB thing and OpenMP? From what I've read so far, both seem to cater to a very similar niche...

Re:Burning question... comparison to OpenMP?

[Phatmanotoo]

This blogpost talks about OpenMP vs TBB: Threading Building Blocks: Solution Looking for a Problem?

GPL 2 only

[oneandoneis2]

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.

Re:GPL 2 only

[networkBoy]

Which is perfectly fine. I have a friend at Intel and based on what I've heard of the corporate culture, open ended licenses are a no-go. That doesn't mean they won't later release under GPL v3, just that they want their lawyers to have a chance to review any license they release under and don't want to be beholden to the unknown. Frankly I think that's a good thing. In theory GPLv4 could say: this can be used in closed source proprietary DRM schemes. and if they had the "or later" clause they would have to allow it.
-nB

Re:GPL 2 only

[CarpetShark]

they want their lawyers to have a chance to review any license they release under and don't want to be beholden to the unknown. Frankly I think that's a good thing. In theory GPLv4 could say: this can be used in closed source proprietary DRM schemes

Agreed. The real problem is that many projects lose touch with their contributors, and so can't contact them all and say, "what about moving to this new license?" Of course, even if they could, getting agreement on that would be tough.

Difficult to implement

[diehard2]

I've got a program that does benefit enormously from using multiple cores. I looked into the TBB first, and I have to say my head hurt for an hour after looking at their examples. It would have required a serious rewrite of my core numerical routines, and not in a pretty way. I've found the OpenMP pragmas to be the easiest way to maintain the structure of existing code while leveraging the multiple cores. Now, there are very few examples of OpenMP that do anything useful on the web, but after a couple of hours of reading, I was able to very easily integrate it with maybe an extra couple of lines of code and some very minor reworking of the existing code.

Re:Difficult to implement

[James_Intel]

Definitely use OpenMP if it works for you. We (at Intel) are going to keep supporting OpenMP - we do not see TBB lessening the need for OpenMP. Data parallel programs which have nice loop nests and code up in C and/or Fortran work very well with OpenMP, and do not need the extra complexities of using TBB. The extra complexity of TBB helps with task oriented and C++ code and data structures. TBB can also handle nested parallelism and irregular problems or more complex arrangements like pipelines.

Compatibility kinda sucks

[VGPowerlord]

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:

• Intel® Pentium® 4 processor
• Intel® Xeon® processor
• Intel Pentium D processor
• 64-bit Intel Xeon processor
• Intel® Core Solo processor
• Intel Core Duo processor
• Intel Core 2 Duo processor
• Intel® Itanium® 2 processor (Linux systems only)
• Non Intel processors compatible with the above processor

OSes:

• Microsoft Windows Systems
  • Microsoft Windows XP Professional
  • Microsoft Windows Server 2003
  • Microsoft Windows Vista
• Linux Systems
  • Red Hat Enterprise Linux 3, 4 and 5 (when using Red Hat Enterprise Linux 4 with Intel Itanium processors, operating system Update 2 or higher is recommended)
  • Red Hat Fedora Core 4, 5 and 6 (not with Intel Itanium processors)
  • Asianux 2.0
  • Red Flag DC Server 5.0
  • Haansoft Linux Server 2006
  • Miracle Linux v4.0
  • SuSE Linux Enterprise Server (SLES) 9 and 10
  • SGI Propack 4.0 (with Intel Itanium processors only)
  • SGI Propack 5.0 (not with IA-32 architecture processors)
  • Mandriva/Mandrake Linux 10.1.06 (not with Intel Itanium processors)
  • Turbolinux GreatTurbo Enterprise Server 10 SP1 (not with Intel Itanium processors)
• Mac OS X 10.4.4 (Intel) or higher

Compilers:

• Microsoft Visual C++ 7.1 (Microsoft Visual Studio .NET 2003, Windows systems only)
• Microsoft Visual C++ 8.0 (Microsoft Visual Studio 2005, Windows systems only)
• Intel® C++ Compiler 9.0 or higher (Windows and Linux systems)
• Intel® C++ Compiler 9.1 or higher (Mac OS systems)
• For each supported Linux operating system, the standard gcc version provided with that operating system is supported, including: 3.2, 3.3, 3.4, 4.0, 4.1
• For each supported Mac OS operating system, the standard gcc version provided with that operating system is supported, including: 4.0.1 (Xcode tool suite 2.2.1 or higher)

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

Re:Compatibility kinda sucks

[tlhIngan]

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.

Well, yeah, considering it's an Intel software product, that Intel originally released under a closed-source license and probably charged a nominal fee for. (Intel's software is used to promote their hardware, after all, so even if they give it away for free, they don't lose out since their licenses typically mandate that you use it on Intel chips).

So it is a surprise when Intel open-sources a formerly commercial program, that it only supports Intel processors? The big deal is that it's open-source. Intel cannot tell you that you can't make it work on AMD processors, since the terms of the GPL prevent Intel from doing so. They may not vouch for its support, but there's nothing stopping anyone from adding AMD processor support, BSD support, etc.

Complaining about compatibility on a just-open-sourced program is like complaining when a Windows app gets open-sourced that it doesn't support Linux/BSD/OSX. Or when a new Linux app is open-sourced, complaining it doesn't work on Windows. It doesn't support it yet because whoever released the code didn't think it was necessary. But now it's open source, someone else (or you) can add that "missing" functionality.

Re:Compatibility kinda sucks

[DragonWriter]

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.

Since its GPLv2 rather than closed, to the extent that it is a useful library and easier to adapt to other processors/OS's than implement the API or an equally useful one from scratch, there is at least the potential of community-driven implementations for other environments.

Re:Compatibility kinda sucks

[VGPowerlord]

Your sarcasm detector is busted.

Re:Compatibility kinda sucks

[lbft]

"Supported" doesn't necessarily mean "will only run on" - it's just what they explicitly say it'll run on, and probably rigorously test against. The fact is that it advertises working in GCC on Linux and OS X, and so I'd expect it to work anywhere icc or gcc and pthreads or OpenMP is available (i.e. anywhere where threading matters to anyone writing new software.)

Just don't expect Intel to advertise their product working on AMD or Sun processors, even if it does.

Re:Compatibility kinda sucks

[sumdumass]

Is this a limitation of the program itself or is it just a limitation of what Intel is willing to validate it on. I mean, I can understand Intel not testing other people's processors and only making a claim to thier current crop that is available.

If there is not technical limitation to the use on other processors and Intel just didn't warrant or claim it works on them, then it might work well with them, you just need a way to find out for sure. I ma guessing this might lead to a designed and tested for Intel processors logo or something.

Re:Compatibility kinda sucks

[VGPowerlord]

"Supported" doesn't necessarily mean "will only run on" - it's just what they explicitly say it'll run on, and probably rigorously test against. The fact is that it advertises working in GCC on Linux and OS X, and so I'd expect it to work anywhere icc or gcc and pthreads or OpenMP is available (i.e. anywhere where threading matters to anyone writing new software.)

While that's true, I assume that they would have listed one of the BSDs if they knew it worked on it. As far as I know, it required specific things in the Mach and Linux kernels, or something specific in glibc (I didn't know if the BSDs used glibc, I just assumed that they didn't).

Just don't expect Intel to advertise their product working on AMD or Sun processors, even if it does.

"Non Intel processors compatible with the above processors" would cover AMD processors, I'm not sure about Sun processors.

(Oops, I cut off the s in processors in the original post.)

Re:Compatibility kinda sucks

[VGPowerlord]

Is this a limitation of the program itself or is it just a limitation of what Intel is willing to validate it on. I mean, I can understand Intel not testing other people's processors and only making a claim to thier current crop that is available.

If there is not technical limitation to the use on other processors and Intel just didn't warrant or claim it works on them, then it might work well with them, you just need a way to find out for sure. I ma guessing this might lead to a designed and tested for Intel processors logo or something.

I know that AMD processors would largely fall under "Non Intel processors compatible with the above processors."

I took these lists from the TBB Product Overview page (linked as the word limited in the original post). These are Intel's words, not mine.

Re:Compatibility kinda sucks

[the eric conspiracy]

Does anyone know if there is a functional equivalent to this for SPARC or even Solaris / Intel?

Re:Compatibility kinda sucks

[pjabardo]

From the faq http://softwarecommunity.intel.com/tbbWiki/FAQ/591 .htm : FAQ
What compilers, operating systems and processors are supported?
Version 2, Changed by RANDY SMITH on 7/23/2007
Created by: JAMES REINDERS
The project is dedicated to supporting all compilers, all OSes and all processors as a cornerstone objective of the project. Up to date information on status is available on the web site.

Re:Compatibility kinda sucks

[GooberToo]

I compiled and ran the examples on my AMD system. They run without issue.

Re:Compatibility kinda sucks

[James_Intel]

We've been supporting Linux, Windows and Mac OS X for x86, x86-64 and Itanium processors in the commercial product for a year. And, yes, those include Intel and AMD processors. The commercial product information only lists those.

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 ;-) We're talking about what to do together to add SPARC support to - which shouldn't be too hard but will take some work.

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:Compatibility kinda sucks

[James_Intel]

Solaris for x86 yes with gcc - download it and it will build. We think it all works (we've tested some) - but we'd obviously love feedback if we missed something (we don't think so - but it hasn't been ported for as long as others for TBB). We're working on making sure the Sun compiler works too - and SPARC is something we're hoping to get some help with (some Sun engineers are in touch and want to help us with it - so hopefully we'll have that working in time).

GPLv2 only

[starseeker]

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.

Re:GPLv2 only

[debrain]

That's interesting, since the first bit of license of the GPLv2 is:

"Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."

Thus, I expect that a court would find that Intel would be bound to the verbatim GPLv2 (which has "or any later version") unless they specifically say something of the kin of "modified GPLv2" wherever they mention the license they're using, and particularize the modifications prominently in their version.

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.

As the sole copyright owner they could unilaterally revoke and amend the license and its references appropriately for future versions. However, anyone with a copy of this existing version would seemingly have the GPLv2 license in its original glory (and hence GPLv3 may apply).

I haven't looked at the details; this is based on what you've just said. It's very interesting.

Re:GPLv2 only

[DRJlaw]

Thus, I expect that a court would find that Intel would be bound to the verbatim GPLv2 (which has "or any later version") unless they specifically say something of the kin of "modified GPLv2" wherever they mention the license they're using, and particularize the modifications prominently in their version.

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.

Re:GPLv2 only

[DragonWriter]

Thus, I expect that a court would find that Intel would be bound to the verbatim GPLv2 (which has "or any later version")

No, if anything, in that case, Intel would be guilty of copyright violation on the license. Forcing them to adhere to the original license (assuming their product doesn't incorporate anything licensed under the unmodified license) would be an extraordinarily improbable remedy, in that case.

But, anyway, you're wrong: the GPLv2 doesn't contain an "or any later version" clause, it has a provision (in Section 9) that, among other things, specifies what rules apply if a Program released under the GPLv2 itself specifies "or any later version". IOW, it gives those using the license the option of including an "or any later version" clause. But, since this Intel release chooses not to take that option, those rules don't apply. Intel has chosen not to buy into future versions of the GPL sight-unseen.

Re:GPLv2 only

[debrain]

Gotcha; I misunderstood the parent's post.

No, if anything, in that case, Intel would be guilty of copyright violation on the license. Forcing them to adhere to the original license (assuming their product doesn't incorporate anything licensed under the unmodified license) would be an extraordinarily improbable remedy, in that case.

Incidentally, adherence to the original license would be a shield against litigation by Intel. In other words, Intel would not be permitted to rely upon modifications to the contract (in equity, under the doctrine of estoppel / detrimental reliance).

The copyright violation is incidental.

Re:GPLv2 only

[Anonymous Coward]

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.

It's not surprising because Intel is THE kingpin behind trusted computing and DRM -- something the GPL v3 is dead set against. Intel is the major mover in the computing world behind the idea of ubiquitous Trusted Computing, zero privacy, secret code execution, DRM etc etc. So no... Intel won't be supporting the GPL v3.

Re:GPLv2 only

[DragonWriter]

Incidentally, adherence to the original license would be a shield against litigation by Intel. In other words, Intel would not be permitted to rely upon modifications to the contract (in equity, under the doctrine of estoppel / detrimental reliance).

I don't think that works if the original license wasn't the one Intel distributed. If Intel distributed the original license and tried to foist a modification off, promissory estoppel might limit the effect given to the revision (or at least a shield against some remedies for violation of it), given the irrevocability term in the license.

Re:GPLv2 only

[debrain]

I don't think that works if the original license wasn't the one Intel distributed. If Intel distributed the original license and tried to foist a modification off, promissory estoppel might limit the effect given to the revision (or at least a shield against some remedies for violation of it), given the irrevocability term in the license.

I think you understand and are getting at what I was hoping to be able to convey.

If Intel said it was using the unmodified GPLv2, someone relied upon the unmodified GPLv2 even though the actual license being distributed was a modified GPLv2, then promissory estoppel ought to apply (all else being equal) insofar as the modifications give rise to Intel's right to make claims against parties who agreed to the software license where it would otherwise not have such a right, as Intel ought not to be able to rely upon its misrepresentation. Only estoppel the shield, though.

That's still not a very eloquent explanation. But I think the analysis, while a tad convoluted, is not unreasonable (common law applying and relevant legislation notwithstanding). And I'm speculating that you've got a grasp of this anyway (and hopefully it doesn't mislead passers-by).

Meta comment

[AltEnergy_try_Sunrei]

This discussion to me is pure propaganda for Apple. Buttons are a design choice, who cares if the Iphone has them or not..

Memory requirements - bummer

[ohell]

I read on their FAQ that TBB requires 512MB to run, though they recommend 1GB. This appears to be very high, especially when compared to Boost.Threads etc. I can't think of a reason why they need to allocate this much - and it would probably be a problem for consumer applications.

Also from the FAQ, the so-called concurrent containers still need to be locked before access. So no change from normal STL containers there.

But I will download it just for the memory allocator they supply, since it can be plugged into STL, and claims to hand out cache-aligned memory. It can apparently be built independently of the rest of TBB.

Re:Memory requirements - bummer

[idiot900]

I wonder if that memory requirement is only for compiling the library? 512MB of heap memory as a minimum requirement at runtime is completely absurd - what's the point of performance gains from better threading when the user's machine is swapping like mad?

The easy way to answer this question is to compile and run a sample application I suppose...

Re:Memory requirements - bummer

[James_Intel]

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()

"open-source" != "non-commercial"

[4e617474]

previously commercial only package is now open for all the use, whether for open-source projects or commercial offerings

The antonym of "open-source" is "closed-source" or "proprietary". Anyone telling you you can't use and distribute GPL'ed software commercially is in violation of the GPL.

Re:"open-source" != "non-commercial"

[Anonymous Coward]

Anyone saying you can is in violation of the laws of reality, which trump the GPL significantly. Go on spreading the fiction that it's somehow possible to actually run a business selling something that your customer is then free to copy and distribute at no cost to them.

Re:"open-source" != "non-commercial"

[david_thornley]

There is more in the laws of reality than is dreamt of in your philosophy, Horatio.

While I don't know of any company that makes its revenue mostly from selling free software, there are plenty of successful companies that have free software as a large and vital part of their business model.

One very common one is to sell free software and support, like Red Hat and IBM. Another is to sell free software as part of a larger product, such as MacOSX or devices with embedded Linux. MySQL will happily give you their flagship products on GPL terms, and will happily sell them if you want them under a different license.

These companies would make a lot less money if it weren't for the availability of high-quality free software; hence, the software is commercially important, and I'd call it commercial.

Re:"open-source" != "non-commercial"

[maxwell demon]

Anyone saying you can is in violation of the laws of reality, which trump the GPL significantly. Go on spreading the fiction that it's somehow possible to actually run a business selling something that your customer is then free to copy and distribute at no cost to them. What does Red Hat do, again?

Re:"open-source" != "non-commercial"

[DragonWriter]

Anyone telling you you can't use and distribute GPL'ed software commercially is in violation of the GPL.

Anyone telling you that is wrong, perhaps, but the GPL doesn't impose a universally-applicable limit on free speech which makes anyone who says it a violator of the GPL. (Someone distributing software that they got under the GPL who asserts a license term say you can't use their distribution/modification of that GPL software in commercial software might be in violation of the GPL, but most people who say that you can't do that aren't in that class, or doing so in that context.)

Re:"open-source" != "non-commercial"

[spitzak]

I didn't know Intel was out of business. Thanks for pointing that out.

Re:"open-source" != "non-commercial"

[krischik]

While I don't know of any company that makes its revenue mostly from selling free software, there are plenty of successful companies that have free software as a large and vital part of their business model. Well there is AdaCore (http://www.adacore.com/home). All there software is GPL (get your free copy from https://libre.adacore.com/ and they still sell a five seat GNAT/Pro for 15'000 (last I heard).

And what a funny coincidence: Ada does not need a theading library - tasking as it's called is build right into the language itself ;-) .

Martin

Intriguing

[Anonymous Coward]

So...What are the chances this suite could be used/integrated with GCC and/or GAS?

Re:Intriguing

[James_Intel]

It is fully compatible with gcc - and has been tested with gcc on Linux, Mac OS X and Windows for Intel/AMD processors as well as G5 processors on Mac OS X. I think the FreeBSD and Solaris build on gcc too, but I'm not 100% sure. That's just so far - no reason to expect it to be hard to port/build for other systems.

Neither Linux nor Intel specific

[AHumbleOpinion]

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

Performance Comparison?

[keithjr]

Has there been any work done on comparing how well TBB performs using simple benchmarks? As in, compared to existing solutions like OpenMP or MPI? The website is rather uninformative as far as benchmarks are concerned.

Re:Performance Comparison?

[James_Intel]

TBB's not a replacement for OpenMP or MPI. If either work for you - you should use them. OpenMP is usually use as a shared memory programming model, and works well for Fortran and much C code. TBB is aimed for C++ and C programs, also shared memory. MPI is a distributed memory programming model.

First and foremost - TBB is easy to use, and still high performance.

A critical item for high performance in parallel programs is scaling - and TBB helps get better scaling more easily than you would find with hand coding. But OpenMP and MPI generally encourage/lead to scaling.

Another key on shared memory machines is managing caches well. TBB, again, does very well.

Benchmarks... it would be good to get ideas on what we should show. Here is what we have looked at / seen:
(1) Comparing with code written using pthreads/windows threads, TBB code is much easier to write and debug. We've seen serious programmers who don't write lots of parallel code be unable to get the hand threaded code to work, but get TBB to work. In each case I've seen - the programmer had to stop with hand threading because they just had to go work on something else after their effort to add pthreads to a big program didn't work well enough. We've seen experienced programmers get good scaling with TBB the first time, something they have to spend time on with hand coded threads.
(2) If a program can be written with OpenMP, we've seen comparable performance between OpenMP and TBB on first implementations of code - but then further tuning can lead to OpenMP out performing TBB if the OpenMP dynamic scheduling can be turned off as an advantage (use 'static scheduling' for a boost in speed). TBB is always dynamic, and will get beat in such cases. Of course, dynamic scheduling can be a huge win for many cases with problems that are even a little bit irregular.
(3) Distributed memory code (using MPI or a 'cluster' version of OpenMP) - usually out performs everything else. This is because, as a developer, you need to work out how to write a program with minimal dependencies between code running on each node of the computer. This work, is not easy... but once done (if it can be done) - the program has few synchronizations, not memory contention, etc. I don't recommend MPI for anyone thinking of coding for 2-4 cores and starting parallelism for the first time.

PS3?

[LinuxGeek]

I checked the site and forum, but no search results on PS3. Having just bought a shiny new 60gig PS3, this release makes me wonder just how easy it could be to take fairly good advantage of all the cores.

Hmmm, it may be one of my first projects; six cores running @ 3.2GHz and an easy method of putting them to use. It would be interesting to parallelize pi calculation and see how long it would take to get one million digits.

Re:PS3?

[Doctor Memory]

Having just bought a shiny new 60gig PS3, this release makes me wonder just how easy it could be to take fairly good advantage of all the cores. That should be interesting, since the Cell is a non-orthagonal multi-core CPU (sort of like a PPC core with multiple AltiVec units). Opcodes for the main core (the PPE) are Power/PowerPC, while the satellite processors (the SPEs) run a vector (similar to the AltiVec or VMX) instruction set. I believe the PPE can also execute the vector instructions, so maybe it would be possible to just target that. I'm not sure how general-purpose those opcodes are, though, and since I don't believe the PPE has the SPE's complement of 128 registers, you might wind up to just supporting whatever register set the PPE has.

Re:PS3?

[Vader82]

Just about forever. Typically you need to increase the number of calculations by an order of magnitude for another decimal place. Kinda makes sense, you move the decimal over on the # of calcs and the decimal place for accuracy moves too.

I'd guess it won't work too well. Intel likely has made some assumptions like "All processors in the system are the same" and the like. Additionally, using C++ on the Cell isn't all that great. I talked to a guy from IBM who said they were having decent success using straight C but due to the classes in C++ the local store (programmer managed cache) would fill up with application code rather than data bringing things to a crawl.

The Cell is a great system, but using it efficiently requires either an expert at low-level algorithm development who isn't scared to know what the hardware is doing, or a significantly more advanced framework.

Re:PS3?

[Phroggy]

They do not support PS3 or any other game console currently. They said the Cell architecture doesn't lend itself to a port of TBB being easy, but if someone can figure out how to do it, they'd like to see it happen. So if you think you can contribute, do so.

Re:PS3?

[Anonymous Coward]

I agree that Intel's framework almost certainly won't work well at all on the Cell.

However, the calculation of pi to a given number of decimal places is nowhere near exponential in time. There are plenty of algorithms that are subquadratic, and some that are very close to linear. A million decimal places is pretty trivial really, a matter of seconds on any modern computer. Try a few billion.

The current record for digits of pi is more than a trillion.

Re:PS3?

[Vader82]

Yeah, you're right. I was thinking about calculating pi via monte-carlo simulation. Highly parallel, but super inefficient.

But the thing is

[Sycraft-fu]

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.

A job for Fortran . . .

[hawk]

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

Knowing 2 from 3 makes you a know-it-all now!?

[Anonymous Coward]

I may not be a know-it-all, but I know the difference between two (10b) and three (11b), even in binary.

Or are you going to claim that that number was supposed to be in unary?

Pythonify all

[voidy]

Mix this up with python, and I'm there!

Still so certain of the one true way,

[DrSkwid]

even in binary. I shall claim no such supposition.

HEY STUPID!

[Anonymous Coward]

It's "moot", not "mute", you dildo. You're right about everyfuckingthing else, though.

I know who doesn't

[Anonymous Coward]

for (i = 0; i<NUMBER_OF_TYPES; i++) printf("type %i\n", i);