Forgot your password?
typodupeerror
Intel

Intel Releases Threading Library Under GPL 2 158

Posted by CmdrTaco
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.

Intel Releases Threading Library Under GPL 2

Comments Filter:
  • ...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]
    • by ookabooka (731013) on Wednesday July 25, 2007 @09:20AM (#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.
      • by Doctor Memory (6336) on Wednesday July 25, 2007 @10:06AM (#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: (Score:3, Insightful)

          by ookabooka (731013)
          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 thr
          • 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

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

          by 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) Moder
          • by stony3k (709718)
            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 (Score:3, Insightful)

    by jshriverWVU (810740) on Wednesday July 25, 2007 @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, 2007 @09:08AM (#19982835) Journal
    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: (Score:2, Offtopic)

      by phantomlord (38815)

      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.
      • by ookabooka (731013)
        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 (Score:4, Informative)

          by Aladrin (926209) on Wednesday July 25, 2007 @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.
        • 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: (Score:3, Informative)

      by PhrostyMcByte (589271)
      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: (Score:2, Informative)

      by onecheapgeek (964280)

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

      by oneandoneis2 (777721) *
      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 (Score:5, Interesting)

        by networkBoy (774728) on Wednesday July 25, 2007 @10:54AM (#19984289) Homepage Journal
        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
        • 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.

  • by malfunct (120790) * on Wednesday July 25, 2007 @09:12AM (#19982875) Homepage
    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, 2007 @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 Viol8 (599362)
      "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: (Score:2, Informative)

        by High Hat (618572)
        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...
        • by joib (70841)
          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.
  • by TomorrowPlusX (571956) on Wednesday July 25, 2007 @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.
    • Re: (Score:2, Insightful)

      by cheekyboy (598084)
      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 we
      • by gbjbaanb (229885)

        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 wo

      • by ookabooka (731013)
        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. wh
        • by HiThere (15173)
          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.

    • 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.
    • But the thing is (Score:4, Informative)

      by Sycraft-fu (314770) on Wednesday July 25, 2007 @01:06PM (#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.
    • by hawk (1151)
      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
    • by Abcd1234 (188840)
      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
      • 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.
        • by Abcd1234 (188840)
          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.
    • 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 [open-std.org] this problem.
  • Great news! (Score:2, Interesting)

    by jgarra23 (1109651)
    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?

    • Re: (Score:3, Interesting)

      by TheRaven64 (641858)
      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 g
    • by Abcd1234 (188840)
      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
  • by diehard2 (1132885)
    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 ho
  • 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
    • by tlhIngan (30335)

      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 li

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

    • by sumdumass (711423)
      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 Inte
      • 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 Inte

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

    • by James_Intel (1082551) on Thursday July 26, 2007 @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.
  • GPLv2 only (Score:3, Informative)

    by starseeker (141897) on Wednesday July 25, 2007 @10:30AM (#19983901) Homepage
    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.
    • by debrain (29228)
      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
      • Re: (Score:3, Informative)

        by DRJlaw (946416)
        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 eithe
      • 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 pro

        • by debrain (29228)
          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 contr
          • 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 som

            • by debrain (29228)
              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 e
  • by ohell (821700) on Wednesday July 25, 2007 @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 idiot900 (166952) *
      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: (Score:2, Informative)

      by James_Intel (1082551)
      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 scal
  • 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.

    • 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

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...