Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel Releases Threading Library Under GPL 2

CmdrTaco posted about 7 years ago | from the of-interest-to-some-of-you dept.

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

cancel ×

158 comments

I'm thinking (2)

Nikron (888774) | about 7 years ago | (#19982793)

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 (5, Informative)

hrieke (126185) | about 7 years ago | (#19983247)

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 (2, Insightful)

Phroggy (441) | about 7 years ago | (#19985971)

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

Neither Linux nor Intel specific (2, Informative)

AHumbleOpinion (546848) | about 7 years ago | (#19985425)

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/ [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

PS3? (3, Interesting)

LinuxGeek (6139) | about 7 years ago | (#19986077)

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? (3, Informative)

Doctor Memory (6336) | about 7 years ago | (#19986725)

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.

As if enough people weren't already confused... (1, Troll)

nokilli (759129) | about 7 years ago | (#19982799)

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

--
Censored [blogspot.com] by [blogspot.com] Technorati [blogspot.com] and now, Blogger too! [blogspot.com]

Re:As if enough people weren't already confused... (3, Informative)

ookabooka (731013) | about 7 years ago | (#19982945)

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... (3, Informative)

Doctor Memory (6336) | about 7 years ago | (#19983541)

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... (2, Insightful)

ookabooka (731013) | about 7 years ago | (#19984775)

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

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

Doctor Memory (6336) | about 7 years ago | (#19986473)

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

maxwell demon (590494) | about 7 years ago | (#19987679)

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... (2, Interesting)

Anonymous Coward | about 7 years ago | (#19985865)

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.

Woohoo (2, Insightful)

jshriverWVU (810740) | about 7 years ago | (#19982825)

If it's as smooth as the Intel C compilers this ought to be a treat. Now if only they'd release the icc under a similiar license.

GPL 2 (2, Informative)

raffe (28595) | about 7 years ago | (#19982835)

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 (1, Offtopic)

phantomlord (38815) | about 7 years ago | (#19982881)

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

Nikron (888774) | about 7 years ago | (#19983067)

Actually the language says 'or', so yeah you can get it under GPL3 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version

Re:GPL 2 (2, Interesting)

sumdumass (711423) | about 7 years ago | (#19984555)

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

ookabooka (731013) | about 7 years ago | (#19983257)

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 (3, Informative)

Aladrin (926209) | about 7 years ago | (#19983481)

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

Anonymous Coward | about 7 years ago | (#19983709)

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

Repossessed (1117929) | about 7 years ago | (#19986259)

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

Aladrin (926209) | about 7 years ago | (#19987611)

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

TheRaven64 (641858) | about 7 years ago | (#19985465)

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 (2, Informative)

PhrostyMcByte (589271) | about 7 years ago | (#19983205)

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 (2, Informative)

onecheapgeek (964280) | about 7 years ago | (#19983245)

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.

GPL 2 only (2, Informative)

oneandoneis2 (777721) | about 7 years ago | (#19983649)

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 (4, Interesting)

networkBoy (774728) | about 7 years ago | (#19984289)

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

Just great... (1)

doombringerltx (1109389) | about 7 years ago | (#19982847)

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

CogDissident (951207) | about 7 years ago | (#19984373)

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? (2, Insightful)

malfunct (120790) | about 7 years ago | (#19982875)

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

Anonymous Coward | about 7 years ago | (#19982927)

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

Re:Open-Source vs Commercial? (1)

littlefoo (704485) | about 7 years ago | (#19984111)

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.

I'm glad to hear it (5, Informative)

ookabooka (731013) | about 7 years ago | (#19982889)

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

Viol8 (599362) | about 7 years ago | (#19986553)

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

Looks good, but a little hampered by C++ (4, Insightful)

TomorrowPlusX (571956) | about 7 years ago | (#19982897)

I looked at some of the tutorials yesterday, and I believe I'm going to dip my toes in this.

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

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

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

That being said, Boost.lambda makes my brain hurt a little, so my complaints are really just a tempest in a teacup. If I were smarter and could really grok C++ I could probably use Boost.Lambda and this would be a non-issue.

Re:Looks good, but a little hampered by C++ (1, Informative)

Anonymous Coward | about 7 years ago | (#19983099)

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

TomorrowPlusX (571956) | about 7 years ago | (#19984013)

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++ (2, Informative)

ray-auch (454705) | about 7 years ago | (#19984905)

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

Nova77 (613150) | about 7 years ago | (#19985237)

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

Re:Looks good, but a little hampered by C++ (3, Informative)

ray-auch (454705) | about 7 years ago | (#19984145)

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

Timothy Brownawell (627747) | about 7 years ago | (#19984619)

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 [www.gotw.ca] to verify it.)

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

ray-auch (454705) | about 7 years ago | (#19984943)

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

Anonymous Coward | about 7 years ago | (#19986573)

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 [perl.com] !

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

smitty97 (995791) | about 7 years ago | (#19985581)

public: void hello() { printf("hello world\n"); }
Hey! you're the iPhone Hacker!

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

drxenos (573895) | about 7 years ago | (#19985977)

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

Anonymous Coward | about 7 years ago | (#19986047)

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

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

Anonymous Coward | about 7 years ago | (#19986485)

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++ (1, Insightful)

cheekyboy (598084) | about 7 years ago | (#19983419)

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

gbjbaanb (229885) | about 7 years ago | (#19984597)

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

ookabooka (731013) | about 7 years ago | (#19985009)

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

Anonymous Coward | about 7 years ago | (#19984203)

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

Rakshasa Taisab (244699) | about 7 years ago | (#19984743)

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 [open-std.org] for lambda expressions is well on its way to getting included in C++09.

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

Anonymous Coward | about 7 years ago | (#19985043)

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

But the thing is (3, Informative)

Sycraft-fu (314770) | about 7 years ago | (#19986197)

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 . . . (2, Informative)

hawk (1151) | about 7 years ago | (#19986907)

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

Nice Offering (1)

coren2000 (788204) | about 7 years ago | (#19982899)

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 (2, Informative)

origin2k (302035) | about 7 years ago | (#19984245)

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 [intel.com]

Re:Nice Offering (1)

coren2000 (788204) | about 7 years ago | (#19984517)

Ohhh... groovy!

task based then thread based (1)

DrSkwid (118965) | about 7 years ago | (#19982911)

Intel are being curiously quiet about such a remarkable breakthough!

Re:task based then thread based (5, Funny)

Holi (250190) | about 7 years ago | (#19983185)

>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 (3, Funny)

dubbreak (623656) | about 7 years ago | (#19984283)

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

networkBoy (774728) | about 7 years ago | (#19984365)

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

And obviously it's your fault.

Re:task based then thread based (2, Funny)

Framboise (521772) | about 7 years ago | (#19984963)

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

DrSkwid (118965) | about 7 years ago | (#19987077)

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

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

Anonymous Coward | about 7 years ago | (#19987525)

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?

Great news! (2, Interesting)

jgarra23 (1109651) | about 7 years ago | (#19982969)

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

Anonymous Coward | about 7 years ago | (#19983033)

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 (2, Insightful)

IndieKid (1061106) | about 7 years ago | (#19983143)

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

gbjbaanb (229885) | about 7 years ago | (#19984891)

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

Re:CS courses (1)

realthing02 (1084767) | about 7 years ago | (#19983261)

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.

This and XEN (1)

WED Fan (911325) | about 7 years ago | (#19983215)

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 (1, Informative)

Anonymous Coward | about 7 years ago | (#19983875)

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 (2, Interesting)

TheRaven64 (641858) | about 7 years ago | (#19985837)

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.

Burning question... comparison to OpenMP? (0)

Anonymous Coward | about 7 years ago | (#19983625)

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

Difficult to implement (2, Interesting)

diehard2 (1132885) | about 7 years ago | (#19983661)

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.

Compatibility kinda sucks (2, Informative)

VGPowerlord (621254) | about 7 years ago | (#19983881)

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:

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

tlhIngan (30335) | about 7 years ago | (#19984165)

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

VGPowerlord (621254) | about 7 years ago | (#19984565)

Your sarcasm detector is busted.

Re:Compatibility kinda sucks (1)

DragonWriter (970822) | about 7 years ago | (#19984471)

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

lbft (950835) | about 7 years ago | (#19984761)

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

VGPowerlord (621254) | about 7 years ago | (#19984987)

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

sumdumass (711423) | about 7 years ago | (#19984945)

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

VGPowerlord (621254) | about 7 years ago | (#19985029)

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 [intel.com] page (linked as the word limited in the original post). These are Intel's words, not mine.

Re:Compatibility kinda sucks (3, Informative)

GooberToo (74388) | about 7 years ago | (#19986679)

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

Re:Compatibility kinda sucks (1)

the eric conspiracy (20178) | about 7 years ago | (#19985223)

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

Re:Compatibility kinda sucks (1)

pjabardo (977600) | about 7 years ago | (#19986231)

From the faq http://softwarecommunity.intel.com/tbbWiki/FAQ/591 .htm [intel.com] : 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.

GPLv2 only (2, Informative)

starseeker (141897) | about 7 years ago | (#19983901)

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

debrain (29228) | about 7 years ago | (#19986237)

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 (2, Informative)

DRJlaw (946416) | about 7 years ago | (#19986841)

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

DragonWriter (970822) | about 7 years ago | (#19986857)

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.

Meta comment (0, Offtopic)

AltEnergy_try_Sunrei (1121435) | about 7 years ago | (#19983947)

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 (3, Interesting)

ohell (821700) | about 7 years ago | (#19984131)

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

idiot900 (166952) | about 7 years ago | (#19984993)

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

"open-source" != "non-commercial" (1)

4e617474 (945414) | about 7 years ago | (#19984547)

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

Anonymous Coward | about 7 years ago | (#19986927)

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.

Intriguing (0)

Anonymous Coward | about 7 years ago | (#19985007)

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

Performance Comparison? (1)

keithjr (1091829) | about 7 years ago | (#19985725)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...