Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Intel Updates Compilers For Multicore CPUs

Posted by kdawson on Tue Jun 05, 2007 02:46 PM
from the what-about-gcc dept.
Intel Programming IT Technology
Threaded writes with news from Ars that Intel has announced major updates to its C++ and Fortran tools. The new compilers are Intel's first that are capable of doing thread-level optimization and auto-vectorization simultaneously in a single pass. "On the data parallelism side, the Intel C++ Compiler and Fortran Professional Editions both sport improved auto-vectorization features that can target Intel's new SSE4 extensions. For thread-level parallelism, the compilers support the use of Intel's Thread Building Blocks for automatic thread-level optimization that takes place simultaneously with auto-vectorization... Intel is encouraging the widespread use of its Intel Threading Tools as an interface to its multicore processors. As the company raises the core count with each generation of new products, it will get harder and harder for programmers to manage the complexity associated with all of that available parallelism. So the Thread Building Blocks are Intel's attempt to insert a stable layer of abstraction between the programmer and the processor so that code scales less painfully with the number of cores."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Intel Updates Compilers For Multicore CPUs 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Anyone want to... (Score:5, Funny)

    by u-bend (1095729) on Tuesday June 05 2007, @02:49PM (#19402129) Homepage Journal
    ...briefly translate this article into cretin for me, so that I can understand a bit more of why it's so cool?

    • Re:Anyone want to... (Score:5, Informative)

      by Trigun (685027) <[xc.hta.eripmelive] [ta] [live]> on Tuesday June 05 2007, @02:54PM (#19402197)
      The compiler worries about the cores so you don't have to. Is that too cretin?
      • haha! Maybe a little too cretin. I might be able to handle information that's a *tiny* bit more technical.
        :)
        Soooo, at the risk of sounding really stupid, wasn't this sort of thing happening with previous compilers?

    • Re:Anyone want to... (Score:5, Informative)

      by BecomingLumberg (949374) on Tuesday June 05 2007, @02:55PM (#19402221)
      >>>So the Thread Building Blocks are Intel's attempt to insert a stable layer of abstraction between the programmer and the processor so that code scales less painfully with the number of cores.

      They found a way to make the computer be able to determine how to use its many CPU cores automagically when you compile a program. It is cool, since it is really to figure out how to share a given workload 16 even ways.
      • Sounds like snake oil to me.

        I can't speak for Fortran but what standard C++ mechanisms are there for threading? If they added stuff to the CLR, shouldn't it have gone through the organizations that maintain them? Weird compiler extensions are bad for cross-compatiblity. (Which I guess is the point since Intel compilers -> Intel CPUs -> No other CPU manufacturers).

        Besides, threading is still an OS specific venture. Do these optimizations just work by looking for calls to fork() or the Windows alternati

        • Re:Anyone want to... (Score:5, Informative)

          by James_Intel (1082551) on Tuesday June 05 2007, @07:08PM (#19405243)
          Automagical - we try. Vectorization, paralellization - I dare say the Intel compilers are at least as good at it as any compiler ever has been. Bold statement - yeah. I believe it is true.

          A more interesting question is "Is that good enough?" For vectorization, the answer is 'usually' - so some additional work/headaches happen when it isn't enough. For parallelization - the answer is at best 'sometimes.' So I'll get flamed two ways: (1) by people very happy with it - and say that I've understated how good it is - and it is all they need, (2) by people with programs which don't get magical auto-paralleism to solve there needs. There are more people in #2 than #1 - but this ain't a 1-size-fits-all-world. Not a bad deal if it solves you problems - otherwise - you got work to do... but that ain't the compiler's fault... parallelism requires work for most of us.

          About languages...
          Virtually every Fortran, C and C++ compiler these days support OpenMP, which is not part of the official standard - but is there to use. It is loop oriented, and is very Fortran-like and fits into C well enough... but is definitely not C++ like.

          Fortran and C/C++ don't support threading in the language, you need to write your code to be thread-safe, and you need to use a threading package like Windows threads or POSIX threads (pthreads). Boost thread offer a portable interface to hit on the key threading needs - essentially wrappers for pthreads and Windows threads, etc. - the standards are likely to add a portable interface officially in the future. One thing Java did from the start.

          Intel compilers -> Intel CPUs -> all compatible processors
          The Intel compilers and libraries aim to beat other compilers and libraries regardless of the processor it is run on. No one will get it right all the time - so this is not a dare to find single examples of little code sample to prove me wrong. But if a real program doesn't get the best results from Intel - we want to know. (yeap - I work at Intel - I post for myself)

    • Re: (Score:2, Informative)

      by CaptainPatent (1087643)
      essentially the compiler will automatically optimize thread splitting (time and number of splits if I'm reading this correctly) which is very handy feature as it will quickly become nearly impossible to manage future processors with 16+ cores. They do seem to hide a lot of the true features underneath market-speak though.

      • Re: (Score:3, Interesting)

        by James_Intel (1082551)
        The compiler will try like crazy to do that - and sometimes it does a great job. Most of the time - you'll have work to do (it won't do it for you). What we've found though - is that anything a programmer can do to express tasks that are splittable - makes the automation more and more possible. OpenMP (11 years old now) has carried that into the multicore world from the world of supercomputing - for loops. Don't have loops? Well, that's there would be a tough one.
        Threading Building Blocks is a good op

    • Re:Anyone want to... (Score:5, Funny)

      by Mockylock (1087585) on Tuesday June 05 2007, @02:58PM (#19402271) Homepage
      The parallelism of the Compiler Fortran and Professional Edition of the uranium core both sport improved auto-vectorizationalism of the fortran and format that can target Intel's new SSE4 extensionalism. For thread-level parallelismisitic quantum theory, the compilers support the use of Intel's Threadtastic Building Block nationalism for objectionism for automatic thread-level optimizationalism that takes place simultaneously with auto-vectorization of parellel universes... Intel is encouraging the widespread use of its Intel Threading quantum physics parallel vectorizationistic Tools as an interface on the enterprise bridge to its Spock multicore processors. As the parallel company raises the vectorized core count with each multitudinal generation of new vector parallel products, it will get harder and harder for programmers to manage the complexity associated with all of that available parallelismistic forces.

      See, it's not that hard to understand.

    • Re:Anyone want to... (Score:5, Interesting)

      by LWATCDR (28044) on Tuesday June 05 2007, @03:09PM (#19402463) Homepage Journal
      SSE4 the latest and greatest vector instruction set from Intel. MMX->SSE->SSE2->SSE3->SSE4. These instructions speed up things like trans-coding video and audio. They are also good for anything that does a lot of Floating-Point. The downside is very few systems have CPUs that support SSE4 and selecting it may hurt systems that don't have SSE4 or the program might not run at all depending on how the compiler is written. My bet is it will degrade gracefully. Over all SSE4 is most useful for people that are writing custom software right now and will become commonplace in off the shelf software once AMD supports it and systems that support it are more common.
      The Threading Building Blocks are yet another attempt to make writing multithreaded code easier. Frankly I don't find pthreads hard but maybe I am just odd.
      Threading is very important because we are not going to see an endless increase in clock speed anymore. Intel, AMD, and IBM are all pushing multiple cores. While adding an extra core or three really does help modern systems at least a little since we are often running multiple tasks current software will not scale as well when the cores start growing in a Moore like fashion. Right now we are at four cores if Moore's law holds in two years we might see eight, then 16, then 32... As you can see it gets out of hand pretty quickly. Your average desktop will not use four cores very well much less eight until software is written to take advantage of more cores.
      Yes I know that Moore said 18 months but I was going for a nice round numbers.

  • Intel - The Software Company (Score:5, Insightful)

    by Necroman (61604) on Tuesday June 05 2007, @02:56PM (#19402251)
    We see Intel mainly as a CPU/chipset maker, but don't pay much attention to their software side. I believe they are one of the largest software development companies in the world. Between drivers, compilers, and all the other goodies to support all their hardware, they spend a lot of time doing software development.

    And as much as they develop compilers to optimize code for Intel CPUs, the code most of the time will also see a speed increase on AMD CPUs as well. Who else do you want developing a compiler but the people who made the hardware it's running on.

    • Re: (Score:3, Insightful)

      by Tribbin (565963)
      "Who else do you want developing a compiler but the people who made the hardware it's running on."

      You mean like nvidia making nvidia drivers for linux?
    • I have not tried their compiler, but for the Intel Performance Primitives (IPP), a library of useful MMX/SSE-optimized functions written by Intel, they explicitly fall-back to slow versions of the code if it detects an AMD processor, even if the AMD processor has MMX/SSE/SSE2. This kind of behavior is one reason that you may not want to trust Intel for your compiler needs if you are planning on doing development for more than just Intel-branded CPUs.
      • From the viewpoint of Intel, this is actually good practice. They don't know what features that AMD actually supports (through possibly intentional ignorance), and they don't want to cause someone's system to lock up. While I'd rather see my AMD CPU be supported by Intel's compiler, I can understand why they might be reticent to support certain features, even though the CPU reports support for that feature.

        Anyways, it's not like MMX/SSE are really used for much of anything but benchmarks and voice synthes

        • Try using a VIC 20 or TI 99/4a for a few hours, then tell me how important it is to have your competitor design a compiler that optimizes for your CPU.
          Noob. Try punchcards. At the very least, the Commodore PET. The VIC-20 was an awesomely powerful piece of hardware compared to that.
        • So if an Intel processor reports SSEn support you assume that it works, but if an AMD processor reports the same feature, you assume that it doesn't work? Great idea.

          This matters because the whole purpose of IPP is to take advantage of newer instructions. If you say "new instructions don't matter because no one uses them" it becomes a self-fulfilling prophecy. Optimized libraries could break out of that cycle, but only if they aren't used as competitive weapons.

        • Re: (Score:3, Insightful)

          by Bert64 (520050)
          On the contrary, they should check for the presence of the appropriate feature, and then use it...
          They should also let you build binaries without those fallback code paths, as a lot of code will never run on older machines (eg x86 macs, which all have at least sse3).
          If someone's system lock up because AMD claimed to support a feature which they dont actually support, that's AMD's fault and intel could claim the moral high ground instead of the other way round.

      • Re:Intel - The Software Company (Score:5, Informative)

        by James_Intel (1082551) on Tuesday June 05 2007, @07:39PM (#19405505)
        (Yes - I work for Intel - post for myself - tell it like it is) Cute story if it was true. However - Intel compilers and libraries, are designed to use features - but we don't come out every day with an update. The new compilers support SSE 4, but Intel only. AMD support comes after the processors exist that support it. Libraries aren't quite there yet with SSE 4 (I guess we hate Intel processors too - flame us). But AMD support for SSE 3 is there - now that it is in their processors. It wasn't there when we developed version 9 of the compilers. We do test our compilers/libraries on other implementations - because believe it or not - we care if it works. It doesn't always - and we adjust the compiler/library to make it work. We had a beta a few years ago which blew up on Intel processors and worked on AMD processors (yeap - I said it right - imagine the embarrassment when a customer told us about that combination). Opps. I heard that was because we released support before we tested that it worked on that processor. So we learned not to do that too often. By the time we release product - it should work on all procesors. I would say "does" or "guaranteed to" - but the lawyers would freak - because nothing in life is guaranteed. We are clearly not trying to screw our customers though - you know... the developers who count on our software. It is annoying when people suggest that might be our goal.

        My favorite complaint: Intel checks "CPUID"
        No duh - that's where the feature information is.

        Next favorite: Intel checks for "GenuineIntel".
        Another "no duh" - RTFM from Intel or AMD - the features flags checking has to come AFTER you determine the manufacturer AND family of the processor...
        unless you don't care about running on all processors
        (spare pointing out to be that you can skip the first two checks - look at the SSE flag - and it is usually right - unless say you pick just the right older processor)
        We do the checks the way Intel and AMD manuals say we have to... if that is evil... so be it.
        We even start by testing if the CPUID instruction exists (it didn't before Pentium processors).

    • Re:Intel - The Software Company (Score:4, Interesting)

      by Chandon Seldon (43083) on Tuesday June 05 2007, @03:10PM (#19402481) Homepage

      It's really useful for a CPU company to develop an optimizing compiler for their hardware. It forces them to understand how their CPU features actually speed up software, and it gives them the opportunity to prove that certain hard optimizations actually work. It would probably be best for everyone if the compiler were open source, but if Intel thinks they need to sell it as a commercial product to justify it financially we still get all of the benefit on their future processor designs.

    • You can say the same for most of the other major chip makers - IBM and Sun both do the same, and in years gone by DEC used to make an arse-kicking Fortran compiler for the Alpha. In fact, probably the only major chip producer that doesn't make compilers is AMD.

    • Who else do you want developing a compiler but the people who made the hardware it's running on.

      My goodness... you can't mean... that the company which developed the hardware is in a strong position to get a few people from the hardware dev team onto the team developing software for it?! And that these people are well placed to know what's worth optimising, where and how?

      No shit, Sherlock.

      The only amazing thing about this is that it is such a novel insight that it is necessary for you to be modded as such.

  • GCC (Score:3, Insightful)

    by Anonymous Coward on Tuesday June 05 2007, @02:56PM (#19402255)
    Will they add these features to GCC or make docs available so others can?
    • No, they won't add them to GCC. Intel's compiler competes with GCC and it is the best there ever was. In every test I've ever seen on Intel chips, it comes out ahead and I'm sure they've no interest in changing that. However yes, the docs are out there. Intel's processors are extremely well documented and you can get everything you need. The problem isn't that the GCC people are having to guess how the processors work, the problem is that their coders aren't as good as Intel's at optimising their compiler.

      • Re:No and yes (Score:5, Informative)

        by smallfries (601545) on Tuesday June 05 2007, @06:31PM (#19404957) Homepage
        Well, no actually you can't. If you've ever spent any time going through the 1000 page Intel Optimisation Guide for the x86 then you would know that they don't spell out all of the trade offs explicitly. They describe enough to point you in the right direction but they keep a lot back. Partially because the behaviour of these chips in certain usage patterns isn't even defined by the design - it's a side-effect of several other parts of the chip design interacting. So the best that you can do is suck it and see - and in general it changes not between major ISA revisions but on individual models.

        Now, if you're Intel then you have the time and the money to work out exactly how to exploit these tradeoffs to schedule threads effectively. But you don't want to give that away for free. From the (very scanty) marketing bullshit that was linked to, it would appear that they've appear an Intel-specific threading library (probably with a POSIX interface). Separate to this is a profiling tool and a multi-threaded debugger (the latter of which is non-trivial). While any debugger will let you skip across threads allowing you do it in a deterministic manner to look for race hazards is much harder.

        The analysis tools sound nice, but the bolton library is nothing special. It's purely to win a few synthetic benchmarks and gain some marketshare for ICC and therefore more "Made for Intel" applications in the market. I'm cynical about the library because what is broken about the threading model in C/C++ would take more than a library to fix. It would require redesigning the language down to the ground and choosing a different set of control constructs.

        So finally, when you claim that it's because Intel has "better" coders. You don't know what you're talking about. I know a few guys who code GCC for a living, and they are grade A coders. It is because Intel has moved the goalposts. It's not so much that GCC targets multiple architectures, it's that they are trying to stick to (relatively) standard C where-as Intel is willing to redefine where the semantic gap sits if they can squeeze out a little more performance. Their attitude is screw portable code - talking across different compiler vendors here, rather than chip vendors. If what they need to squeeze into their compiler is no longer "C" strictly speaking, then they don't care. The gcc guys do.

        Ah yes, and portable code can be a smaller window than you expect. That weighty 1000 page Intel document is sitting comfortable next to the AMD equivalent, which differs in suprising places.
  • If compilers keep abstracting away the interface between the programmer and the cpu, programmers will be less likely to write better code or learn new techniques that take advantage of all the power a few extra cores can provide right? That's just my take on it. Then again, I also think learning parallel programming techniques is fun, and a little more academic than most career programmers might like.

    • Re: (Score:2, Insightful)

      by BoChen456 (1099463)

      If compilers keep abstracting away the interface between the programmer and the cpu, programmers will be less likely to write better code or learn new techniques that take advantage of all the power a few extra cores can provide right?

      If compilers keep abstrating away the programmer and the cpu, and getting better at optimization, programmers won't need to write better code or learn new techniques to take advantage of all the power a few extra cores can provide.

      Instead the programmer can concerntrate on writing more understandable code.

    • Actually, I've always thought that telling the compiler what you wanted to do, instead of how to do it, would result in the compiler being able to determine the best path to take for a given task.
      Even more so for interpreted/compiled on the fly languages. They can be dynamically compiled to take advantage of whatever hardware is available on each machine, without the developer having to code for it.
    • Aside from the auto-vectorizing stuff, most of Intel is advertising does not happen automatically. Instead, they provide abstractions that make it easier to write high performance multithreaded code. But programmers will still have to do the hard stuff, which is figure out how best to parallelize their algorithms, distribute their data, and synchronize their threads.

    • Re: (Score:3, Insightful)

      by 644bd346996 (1012333)
      Almost everybody who can write better assembly than GCC is already working on compilers and optimization. Even GCC is better than most programmer's hand-optimized assembly. I've seen many times over the past several years where open source projects have thrown away assembly source because it is faster and more readable in C. (WINE in particular benchmarked their hand-optimized routines and found themselves soundly beat by GCC.)

      These days, a similar thing is happening with vectorization. If programmers try t
      • have you run windows? Yep that's C with poorly utilised memory.

        Good programmers can write good highly optimized and mostly bug free code.

        unfortunately good programmers are like good Car Drivers. Everyone says they are good, but very few really are.

  • Looks like something they rushed out (Score:4, Informative)

    by Doctor Memory (6336) on Tuesday June 05 2007, @03:01PM (#19402337) Homepage
    I was looking at the Thread Building Blocks paper, and it reads like it was somebody's hastily-scribbled draft:

    "The Intel Threading Tools automatically finds correctness and performance issues" (The tools finds?)
    "Along with sufficient task scheduler and generic parallel patterns" (Who has insufficient task scheduler?)
    "automatic debugger of threaded programs which detects many of thread-correctness issues such as data-races, dead-locks, threads stalls" (Sarcasm fails me...)

    And that's just in the first few paragraphs, I haven't even gotten to the real meat of the article!

    I'm used to informative, well-written and reasonably complete technical documentation from Intel — WTF is this?

    • "The Intel Threading Tools automatically finds correctness and performance issues" (The tools finds?)

      No, the "Intel Threading Tools" is a product, in the singular -- it finds. Maybe Intel threading tools would find, but notice the subtle difference?

      "Along with sufficient task scheduler and generic parallel patterns" (Who has insufficient task scheduler?)

      OK, sso it's a bit awkward to parse, but isn't it obvious by the grammar that "sufficient" modifies both "task scheduler patterns" and "generic parallel

    • Re: (Score:3, Informative)

      by presearch (214913) *
      The Intel Compiler Lab is based in two Russian cities - Moscow and Novosibirsk.
      Probably the source of the less than optimal text.

      How's the documentation on -your- compiler coming along?

    • WTF is this?


      WTF? No, this is SPARTA!

  • OK, I'll Byte (Score:3, Interesting)

    by Skjellifetti (561341) on Tuesday June 05 2007, @03:06PM (#19402409) Journal
    As the company raises the core count with each generation of new products, it will get harder and harder for programmers to manage the complexity associated with all of that available parallelism.

    As a programmer, I already have abstractions such as Active Objects [wustl.edu]. While this may make it easier for compiler writers or kernel hackers, what benefits does it bring to us ordinary mortals?

  • The inevitable... (Score:4, Funny)

    by R2.0 (532027) on Tuesday June 05 2007, @03:06PM (#19402411)
    Cue "Fortran is Dead" comments in

    30
    20
    10

  • intel's product page (Score:4, Informative)

    by non (130182) on Tuesday June 05 2007, @03:07PM (#19402431) Homepage Journal
    the intel product has somewhat more detail. it can be found here [intel.com].

  • I dont understand this statement: (Score:5, Insightful)

    by JustNiz (692889) on Tuesday June 05 2007, @04:07PM (#19403387)
    >> As the company raises the core count with each generation of new products, it will get harder and harder for programmers to manage the complexity associated with all of that available parallelism.

    I'm very surprised and dissapointed by the pervasiveness of the incorrect myth thats being promoted even amongst supposedly technically knowledgeable groups that:
    a) Writing multithreaded code is terribly difficult
    b) You need to implement code to have the same number of threads as your target hardware has cores
    Both of these is completely not true at least for the PC marchitecture.

    The way to develop multithreaded code is to exploit the natural parallelism of the problem itself. If the problem decomposes down most neatly into one, three or 6789 threads, then design and write the implementation that way. Consequently the complexity of the problem does not increase as the number of cores available increases.

    In the PC architecture case, attempting to design your code based on the number of cores in your target hardware just leads to a twisted and therefore bad and also non-portable design.

    I'm surprised how few developers seem to understand that in fact its OK, normal and often desireable to have more than one application thread running on the same core. In fact you really can't even ensure or even assume that your multi-threaded app will get one core per thread even if the hardware has enough cores, or work best if it does, as core/thread allocation is dynamically scheduled by the OS depending on loading. Not to mention there's all sorts of other apps, drivers and operating system tasks running concurrently too, so depending on each core's load, one app-thread per core may actually not be the most optimal approach anyway.

    • Re: (Score:3, Insightful)

      by ratboy666 (104074)
      A couple of points:

      1 - If the communication or thread switching overhead exceeds the thread computation, it is not worth threading.

      2 - It is (unfortunately) easy to build in "lock stepping" into otherwise independent threads. These systems scale from 1..n cores; after n cores no further scaling is seen.

      3 - It *is* difficult to build correct parallel systems. Especially with points 1 and 2 in mind (and, yes, I *have* built parallel high-speed device drivers that are lock-free to avoid switching).

      4 - *Proving
  • I know OS X is compiled using GCC but I wonder if Apple would see performance gains by using it? If they did, would it somehow introduce problems? Basically, I'm wondering if there would be a downside to using the Intel optimized compilers as opposed to all-purpose GCC compiler.

    As an aside, Linux is obviously compiled using GCC but I wonder if Microsoft compiles Windows using the Intel compilers?
      • The problem with a multi-horse harness, if not configured properly, is that the extra manure from the horses can cause the stagecoach to slide around and force the driver to do more work to keep everything in line. Plus it can stink to high heaven. ;)

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.