Slashdot Mirror
Intel Updates Compilers For Multicore CPUs
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."
The compiler worries about the cores so you don't have to. Is that too cretin?
>>>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.
If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.-TJ
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.
Well, back to rejecting software patent applications.
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?
Just junk food for thought...
the intel product has somewhat more detail. it can be found here.
...vividly encapsulates that post-Watergate/pre-punk/coked-up moment when you could trust no one, least of all yourself.
copy and pasted URL from the javascript non-link in the html source
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. This isn't helped by the fact that GCC targets many architectures where the ICC is only for one.
However don't expect Intel to help GCC out. Their answer will just be "buy the ICC".
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.
If it were open source you could modify it to work on AMD processors. In the past, I specced out an intel workstation rather than AMD specifically because my software used the Intel Math Kernel Libraries. Granted, it was only one computer many years ago (When AMD was faster than Intel) but when you see companies building big bewoulf clusters or considering processor/math intensive apps I bet there's a few extra sales to be made there.
And yes, the MKL gave me 60x speedup over hand-written matrix algebra. Big deal when things go from an hour to a minute.
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)
You're right - vectorization - by itself can't handle step 11 dependent on step 10... and assuming there isn't a magical way to rewrite the loop to remove the dependence (which it the first thing the ocmpiler will try todiscover and do for you - but usually it can't) - then you need to look at pipelining - software pipelining on a single core, or parallelism on multi-core... but you'll have to have the right interconnect processor to processor to match the work to get multiprocessor pipelining to do what you want. Software pipelining can be very effective on loops with dependencies loop to loop.
(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).
Checking for 'GenuineIntel' is fine, but the actual code emitted by the compiler goes straight to 'no additional capabilities' if it detects any other string. In other words, in the 32-bit compiler any non-intel chip is doomed to run the 'you are a bog-standard 386 with no MMX/SSE/SSE2 support' code path regardless of its actual capabilities. This 'feature' makes less difference in the 64-bit compiler (because the base level is a EM64T with SSE2, as opposed to a 386 with nothing for the 32-bit version), but as new instruction sets come online (SSE3, SSE4 and the like) this artificial crippling of AMD chips will start to show there as well.
And yes, you say you 'tell it like it is', but I've disassembled the actual code and it doesn't accord with your story. See http://www.swallowtail.org/naughty-intel.html for the gory details. The proof of the pudding is in the eating: if you patch one of our programs compiled with the Intel compiler to remove the Intel check it runs significantly slower on AMD chips (as in DOUBLE the runtime).
There is no technical reason for these checks to be there: they are purely a competitive ploy to cripple performance on AMD chips. If Intel released their compiler for free, then I'd say so what: they're allowed to make it a marketing tool. OTOH, they release it as a commercial product and charge me money for it: doing that and then deliberately crippling its performance is IMHO not acceptable.