“Intel announced today that they’re open-sourcing their cross-platform Thread Building Blocks 2.0 (TBB) template library. While the company contributes code to open-source project like the Linux kernel and drivers, the opening of TBB marks the first time that Intel has taken a commercial tool and open-sourced it, making it Intel’s largest open-source commitment to date.”
intel just keeps making the right moves in my book. keep it up intel. open threaded aplications are teh future, lets get there together.
Pervasive multithreading is a must if we are going to see significant performance improvements. And it’s something very important for Intel to get it common because Intel is focusing on producing multicore chips obviously.
It’s a wise move for Intel to help everyone to start writing multithreaded code.
What would it mean for GNU/GPL3 if intel also released their compiler as open source under GPL2? gcc is the biggest hurdle to anyone not using the gnu tools.
I’m not sure what you mean.
Intel currently sells their compiler for $$$. It’s not a bad compiler. I’m not sure it would be to their advantage to open source.
Their compiler is optimized for their cpus and the x86 market isn’t just a one horse race, although generally amd cpus also get a boost from the intel compiler.
From a cross platform/cross system standpoint gcc is still the best compiler out there, supporting generally well many different architectures and OS’s.
One thing REALLY annoying about this library is that there’s plenty of access to a bunch of marketing fluff, but you have to go through the mess of downloading the code in order to look at any examples. I’d like to see some hard core simple examples of how to use their stuff. Their marketing material almost implies that the library itself goes through the trouble of implementing yet another scheduler in addition to the one the OS already has.
Edited 2007-07-25 16:39 UTC
Their marketing material almost implies that the library itself goes through the trouble of implementing yet another scheduler in addition to the one the OS already has.
Ohhh, another M:N threading model. When are they going to learn that userspace thread scheduling just doesn’t perform very well? Why can’t they just split the process into threads and let the kernel schedule them?
How so? M:N threading is complex to implement, but when done right, it can out perform the competition. Take Tru64 for instance, which uses M:N threading.
Its one of those things in the IT world, great on paper, a real bitch to implement in real life, but when done well, does perform well.
First, you’re OT.
Second unless GCC doesn’t really matter for GPLv3, as it isn’t usually redistributed, only binaries created by GCC are (usually) distributed.
As an aside, I’ve checked and TBB is compatible with GCC.
Intel will probably never release their compiler as free and/or open source software simply because they couldn’t even if they wanted to. As with several other compilers (e.g. Comeau, Portland Group, etc.), the front-end is licensed from the Edison Design Group. I don’t believe that it would be possible (in a reasonable time frame) to rewrite the backend to use an open-source front-end.
More info:
http://www.edg.com/
http://support.intel.com/support/performancetools/c/windows/sb/CS-0…
This is a great move on Intel’s part. Clearly multicore processors are the way forward, and it’s in Intel interest that software performs well on such systems (after all, benchmarks showing their latest and greatest processor not being any faster than a 3 year-old Pentium 4 aren’t what they want). Happily, everyone else gets to benefit to.
What I do wonder though it where this fits in with other C++ parallel schemes. A lot of work has been done in this area by the Boost people, and I recall reading that “easy” thread-level parallelism was one of the major goals of the next C++ standard (though as ever, “easy” and the C++ standards committee are not words that sit well near one another!). And then there’s OpenMP as well. It’s all a bit confusing…
Mirko’s ThreadWeaver library, based on Qt4. It’s also task-based and makes pervasive multithreading incredibly easy. I use it everywhere in Krita.
If I understand correctly TBB also provides a STL-like library which is multi-threading “friendly/compatible”, whereas ThreadWeaver is just a “threaded batch scheduler”.
So they’re not really the same thing..
Edited 2007-07-25 19:11
Personally, I’d perfer to see Intel release their vtune code profiler for free to help developers write code that will run faster (see interview with Con Kolivas where he complains about hardware getting faster, but software getting slower). Amd already make their Code Analyst available for free…
I was at the release party Monday where James Reinders announced the release (and I scored a complementary copy of his book as an attendee). I was going to write an article but the draft showed I had too long a day and too many cocktails.
First off about license Mr. Reinders addressed the subject of forking and stated that Intel had no objections and that the code base should run its course naturally. Second it is encouraged to port to different OS/CPU architectures (but I assume a bias toward Intel CPUs).
The code examples where impressive, from my notes: The original demonstration ray tracer single threaded was 182 lines, Pthreads version added 143 lines and TBB added 17 lines. There was a brief reference to Lamda functions but he never came out and said that TBB is a FUNCTIOAL language addition, I guess it was too obvious given the audience.
I spoke with one of the other Intel engineers after the conference and he confirmed that the library is a set of functional programming templates combined with an actual back ground library that allocates threads across cores implicitly optimizing at run time.
I hope I understood what I said (I know, it is some heavy stuff) But that is what I can report as an attendee of the release party.
Edited 2007-07-26 04:14