Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Intel Releases Threading Library Under GPL 2

Posted by CmdrTaco on Wed Jul 25, 2007 09:02 AM
from the of-interest-to-some-of-you dept.
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.'"
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • by nokilli (759129) on Wednesday July 25, @09:05AM (#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]
  • Woohoo (Score:3, Insightful)

    by jshriverWVU (810740) on Wednesday July 25, @09:07AM (#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 (Score:3, Informative)

    by raffe (28595) * on Wednesday July 25, @09:08AM (#19982835)
    (Last Journal: Thursday November 20 2003, @05:55AM)
    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 by phantomlord (Score:2) Wednesday July 25, @09:13AM
      • Re:GPL 2 by ookabooka (Score:2) Wednesday July 25, @09:50AM
        • Re:GPL 2 (Score:4, Informative)

          by Aladrin (926209) on Wednesday July 25, @10:02AM (#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.
          [ Parent ]
          • Re:GPL 2 by Repossessed (Score:1) Wednesday July 25, @01:12PM
            • Re:GPL 2 by Aladrin (Score:2) Wednesday July 25, @02:56PM
              • Re:GPL 2 by Repossessed (Score:1) Wednesday July 25, @04:00PM
              • Re:GPL 2 by mhall119 (Score:2) Thursday July 26, @09:39AM
              • Re:GPL 2 by Aladrin (Score:3) Wednesday July 25, @04:51PM
            • Re:GPL 2 by phantomlord (Score:1) Wednesday July 25, @03:04PM
              • Re:GPL 2 by DragonWriter (Score:2) Wednesday July 25, @07:03PM
              • Re:GPL 2 by mhall119 (Score:2) Thursday July 26, @09:33AM
              • Re:GPL 2 by phantomlord (Score:2) Wednesday July 25, @07:12PM
              • Re:GPL 2 by phantomlord (Score:1) Thursday July 26, @02:05PM
              • Re:GPL 2 by mhall119 (Score:2) Thursday July 26, @02:18PM
          • 1 reply beneath your current threshold.
        • Re:GPL 2 by TheRaven64 (Score:2) Wednesday July 25, @12:13PM
          • 1 reply beneath your current threshold.
      • Re:GPL 2 by sumdumass (Score:3) Wednesday July 25, @11:12AM
      • 1 reply beneath your current threshold.
    • Re:GPL 2 by PhrostyMcByte (Score:3) Wednesday July 25, @09:45AM
    • Re:GPL 2 by onecheapgeek (Score:2) Wednesday July 25, @09:49AM
    • GPL 2 only by oneandoneis2 (Score:3) Wednesday July 25, @10:14AM
      • Re:GPL 2 only (Score:5, Interesting)

        by networkBoy (774728) on Wednesday July 25, @10:54AM (#19984289)
        (http://www.networkboy.net/)
        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
        [ Parent ]
        • Re:GPL 2 only by CarpetShark (Score:2) Thursday July 26, @06:45AM
  • Just great... (Score:1)

    by doombringerltx (1109389) on Wednesday July 25, @09:09AM (#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
  • Open-Source vs Commercial? (Score:3, Insightful)

    by malfunct (120790) * on Wednesday July 25, @09:12AM (#19982875)
    (http://programmers.malfunct.net/)
    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.
  • I'm glad to hear it (Score:5, Informative)

    by ookabooka (731013) on Wednesday July 25, @09:13AM (#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.
  • by TomorrowPlusX (571956) on Wednesday July 25, @09:15AM (#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.
  • Nice Offering (Score:1)

    by coren2000 (788204) on Wednesday July 25, @09:15AM (#19982899)
    (Last Journal: Monday June 14 2004, @06:43PM)
    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
  • Intel are being curiously quiet about such a remarkable breakthough!
  • Great news! (Score:2, Interesting)

    by jgarra23 (1109651) on Wednesday July 25, @09:23AM (#19982969)
    (http://www.deadeyeinside.com/)
    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.
  • 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?

  • Difficult to implement (Score:2, Interesting)

    by diehard2 (1132885) on Wednesday July 25, @10:15AM (#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 (Score:2, Informative)

    by VGPowerlord (621254) on Wednesday July 25, @10:29AM (#19983881)
    (http://powerlord.livejournal.com/)

    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 by tlhIngan (Score:2) Wednesday July 25, @10:46AM
    • Re:Compatibility kinda sucks by DragonWriter (Score:2) Wednesday July 25, @11:05AM
    • Re:Compatibility kinda sucks by lbft (Score:1) Wednesday July 25, @11:25AM
    • Re:Compatibility kinda sucks by sumdumass (Score:2) Wednesday July 25, @11:38AM
    • Re:Compatibility kinda sucks by the eric conspiracy (Score:2) Wednesday July 25, @11:56AM
    • Re:Compatibility kinda sucks by pjabardo (Score:1) Wednesday July 25, @01:09PM
    • Re:Compatibility kinda sucks (Score:4, Informative)

      by James_Intel (1082551) on Thursday July 26, @12:47AM (#19993055)
      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.
      [ Parent ]
  • GPLv2 only (Score:3, Informative)

    by starseeker (141897) on Wednesday July 25, @10:30AM (#19983901)
    (http://www.axiom-developer.org/)
    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.
  • Memory requirements - bummer (Score:3, Interesting)

    by ohell (821700) on Wednesday July 25, @10:45AM (#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.

  • by 4e617474 (945414) on Wednesday July 25, @11:12AM (#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.

  • by keithjr (1091829) on Wednesday July 25, @12:32PM (#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.
  • Pythonify all (Score:1)

    by voidy (1003912) on Wednesday July 25, @04:15PM (#19988561)
    (http://t0mb.net/)
    Mix this up with python, and I'm there!
  • Re:CS courses (Score:2, Insightful)

    by IndieKid (1061106) on Wednesday July 25, @09:39AM (#19983143)
    (Last Journal: Sunday September 02, @04:01AM)
    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 ;-)
    [ Parent ]
  • Re:I'm thinking (Score:5, Informative)

    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.

    [ Parent ]
  • Re:CS courses (Score:1)

    by realthing02 (1084767) on Wednesday July 25, @09:50AM (#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.
    [ Parent ]
  • by Phatmanotoo (719777) on Wednesday July 25, @10:45AM (#19984143)

    This blogpost talks about OpenMP vs TBB: Threading Building Blocks: Solution Looking for a Problem? [intel.com]

    [ Parent ]
  • Neither Linux nor Intel specific (Score:3, Informative)

    by AHumbleOpinion (546848) on Wednesday July 25, @12:10PM (#19985425)
    (http://slashdot.org/)
    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
    [ Parent ]
    • PS3? (Score:4, Interesting)

      by LinuxGeek (6139) * <linuxgeek.djand@com> on Wednesday July 25, @12:58PM (#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.
      [ Parent ]
      • Re:PS3? (Score:4, Informative)

        by Doctor Memory (6336) on Wednesday July 25, @01:45PM (#19986725)
        (http://randomcoolzip.blogspot.com/)

        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.
        [ Parent ]
      • Re:PS3? by Vader82 (Score:1) Wednesday July 25, @04:03PM
        • Re:PS3? by Vader82 (Score:1) Thursday July 26, @09:24PM
        • 1 reply beneath your current threshold.
      • Re:PS3? by Phroggy (Score:2) Wednesday July 25, @07:12PM
  • Re:Intriguing (Score:1)

    by James_Intel (1082551) on Friday July 27, @09:48AM (#20010741)
    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.
    [ Parent ]
  • 5 replies beneath your current threshold.