Intel Comments on their Linux Compilers


by Scott Robert Ladd
2 October 2001
 

22 August 2004: In the last 18 months, this article has become somewhat obsolete, and the content is rather dated. However, I'm leaving it online for historical purposes.

I'm sitting here, broken foot propped up, listening to Weird Al Yankovic, and thinking about compilers. I'm still amazed at the intense interest in my first look at Intel's C++ and Fortran compilers for Linux. My e-mail is overflowing with interesting and helpful comments, the vast majority from the Fortran community. And Intel has also responded — so I'll start off by with what they had to say...

Installation

I didn't get one response from Intel — I got three. The first came in on the 19th, from Intel's John Oneill (that how his e-mail spells it), who works with the compiler technical marketing team. Here's what he had to say about my problems with the install:

We need to modify some of the glibc header files to work with the Intel compilers, because we currently do not support all of the gcc C language extensions. We will add additional info to our docs. BTW, it's Red Hat 6.2, not 6.1.

As for running the iccvars.sh script, we will make this more clear that it needs to be sourced. The docs should have explained this & I agree this is confusing. 

John also commented on my initial impressions of the compilers:

With the 5.0.1 version of the Intel C++, you cannot build the Linux kernel as not all of the gcc extensions are supported yet, including GNU inline asm support. Version 6.0 will include support for GNU inline asm, and it is a future goal to build the kernel. An advantage of using the Intel compiler would be improved system performance which is critical for certain applications and there is strong interest in this.

I'm very pleased to hear that kernel compilation is a goal for Intel; this would make Intel's C++ compiler a drop-in replace for gcc. Don't get me wrong — gcc is a terrific product and an essential tool, and a shining example of what can be accomplished in an open community development process. That given, I'm also a strong believer in having more than one tool for the job, if for no other reason than to provide sanity checks for my code. Intel's compiler appear to provide a highly-optimized solution for i386 Linux.

There are known issues with OpenMP support for C++ in the 5.0.1 compiler.  This will be improved in 6.0 with full support of OpenMP 1.0 in C++ including  support for threadprivate C++ objects. Also in 6.0, we will support automatic parallelization, similar to the automatic vectorizer.

All of my OpenMP work so far has been in Fortran, so I haven't encountered any problems with the C++. Thanks, John, for being up-front about the compilers, and letting us know what Intel's future plans are.

License Clarifications

In the original article, I was confused by the wording of Intel's license agreement. On 21 September, Intel's James R. Reinders gave me a rundown on what the license actually means; here's part of what he wrote:

I think you may have misread it (lawyer-speak can be challenging).

The second sentence says "The Materials may not be used for any other purpose"... note the word "other". I didn't read the right the first time or two either, but it makes sense the third time, esp. if a lawyer is helping you (I had help). ;-) The first sentence said "you as an individual may use the Materials for only personal, noncommercial and research purposes." The rest of the paragraph clarifies what all this means.

The intent here is to give the developers in the Linux community, focused on developing and distributing software for non-commercial purposes, a C++ and Fortran compiler to use to create high performance binaries. You should be able to grab "gnu emacs" and recompile it for your favorite Linux distribution, and give away the (emacs) binaries on the web for free... all with our good wishes, and without having to pay us to do that. If you or others find we've missed our objective - drop me a note, and I'll see what we can do.

I've never been good at lawyer-speak. I think James's statement gives us a very good idea of Intel's intentions for their compilers. Intel is being very smart; by giving away optimizing compilers for their chips, they provide value that makes people want to buy Intel-based hardware. That's capitalism at work, and companies like AMD need to consider how they're going to respond in kind.

Before I get myself into an AMD vs. Intel flame war: I have systems based on both architectures, and am well aware of the pros and cons of the two processor families. For example, AMD has better per-megahertz performance; Intel has greater reliability and (now) compiler support. I like having choices, because that creates competition, which improves products through natural selection.

Here's something else James told me:

We are very proud of our Linux compilers. We think you'll find them the best at generating high performance code. As it is our very first Linux release, we know it won't be perfect. We will listen, and we will improve it. I think our three biggest challenges going forward (other than fixing any bugs people may find) are:

(1) Full gnu C compatibility (we don't yet support all the extensions to C which gnu C has) - in particular our desire to build the Linux kernel. We did not hold up this release (nor the next one) to get this done - it is hard, and not required by most developers. My apologies to those who have to wait, we are working on this.

(2) Object compatibility with gnu C++ - this is also a challenge we will meet. When we meet it, mixing objects compiled in C++ between gnu and Intel's compilers will work. While I encourage people to just use our compiler - this is not a complete solution - and we know that. We are working on this.

(3) Supporting all Linux distributions. We'd like to support them all... but we are not that big of a team (we added Redhat 7.1 at the last minute (it was released during our beta testing) - and that shows a little in our web store and documentation). We are getting feedback from our own efforts and from users (inside and outside Intel) on what it takes to make the compiler work on various distributions... and we are putting that information on our web site. We will keep adding to that list as we become aware of issues and solutions. People with suggestions/solutions can drop a note to our technical support team - and they'll be appreciative.

That looks like an invitation, folks. At the time of this writing, I'm running the Intel compilers under Debian 2.2r3, Slackware 8.0, and Mandrake 8.0; once I got past the confusion about Intel's install, making the compilers work on various platforms was largely a matter of small tweaks.

Support

Intel hasn't been idle on the newsgroups, either. Their Michael Ross posted the following on comp.lang.fortran recently:

I've been informed that even if you are using the free Linux download compiler, you can register with customer support, and file problem reports. This is more reliable than posting to c.l.f. What this means is that  instead of sending  emails, you will be submitting and monitoring issues via a secure web interface.

To register, for Intel Premier Support.

Following are the URL's for registration and login

 http://support.intel.com/support/performancetools/support.htm to register,
 https://premier.intel.com>  to login ( after registration)

If you are registering a complaint/suggestion on a free, unsupported product, naturally, there are no promises about action, and little likelihood of any fix available to you before the next release. But it's better than depending on my reading the newsgroup and catching your post. I tend to read things that say Intel in the subject, but I do get busy, get sick, go on vacation, etc. So you're best off funneling requests through the usual channels.

People who've read my past writings know that I'm no big fan of corporate monopolies. And until recently, Intel has effectively been a monopoly when it comes to desktop computers; they're often referred to as "Chipzilla" by their detractors. But while I may have concerns about some of Intel's business practices, I am very pleased with the initial release of their non-commercial compilers.

Onward...

With the broken foot and other consideration, I just haven't had time to collate all the responses I've had from people who've tried the compilers out. Ugh, I hate getting hurt, especially when it's because I wasn't watching where I was going! As it is, I'll be putting together more comments in the coming week or so, as time permits.

I hope what's here is useful and interesting. If you have any questions or suggestions, please send me e-mail.