Hi Geoffroy, To answer your question, yes, many of my users do some use some specific compiler options beyond the defaults for optimization. I have a counterpart in my group here who is extremely strong on the applications side, and he works with our users to optimize the performance of their code -- his usual first step is to try to optimize the compile to see how much performance he can get out of it before going back to muck with the application itself. I don't think we here have any numbers on performance gain of Intel over GCC; most of our users have a history of using the Intel compiler because at some point in the past, it was (much?) better than GCC for them. I can give one anecdote, which may be more amusing than useful. We had a user who had a bioinformatics type code that was built in Python with C extensions. When my friend went to help him try to get some better performance, he wanted to recompile with the Intel compiler instead of GCC. However, Python will use the compiler that it was built with, so he had to build Python from source with the Intel compiler before he could get it to use the Intel compiler for the extensions. After all that, it did run twice as fast with nothing more than the SSE enabled Intel compiler. As a data point, it's not real helpful, but it was a good speed-up, after a crazy amount of effort. :) I haven't been following GCC very much, since everyone we work with just likes to use the Intel compiler. I'll have to go check out their auto-vectorization plans to see what's up. Thanks for that tip, btw. I agree that Intel licensing is a problem. Unfortunately, not all users are going to be non-commercial, so assuming that and hacking in the download/inclusion of the free non-commercial version might not be the safest idea. I honestly don't know how to get around this in a generic case beyond the possibility of doing the 30 day evaluation version and forcing the user to go out and get a long term license on their own afterwards. All the licensing stuff gets very sticky. I agree that a better first step might be figuring out how to offer Intel compilers/tools, rather than offering Intel optimized packages. If OSCAR can figure out how to integrate offering Intel tools (compilers, libs like CMKL, tools MPI, etc?), then offering tools built with the Intel offerings (OFED) would likely be a lot easier. --Joe
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wed 3/26/2008 10:13 AM To: [email protected]; Greenseid, Joseph M. Subject: Re: [Oscar-devel] OFED Hi Joe, Thanks for the details, it is actually very interesting to have some return of experience. However, my question was actually very unclear (my bad), I was actually looking for more details about the performance gain (10% in average for MPI applications?). I also know that if you start to play with the compiling options you can improve the global performance of your app (both with gcc and the Intel compiler). I am just curious, are your users only using the default compiling options? or do they try to tune the compiling procedure for each compiler? I also wonder if the latest version of GCC will improve performance compared to the Intel compiler; it is supposed to include some auto-vectorization mechanism). But that's another story, i digress here. :-) On the OSCAR side, the problem with the Intel compiler is the license: we cannot install automatically the Intel compiler without asking the user to agree with Intel licensing stuff, and clearly, currently the only solution to do so is via a hack (we do not have a well-defined method for that). To summarize, my concern is the following: why should we ship OFED compiled with the Intel compiler if you do not have a good support of the Intel compiler by default. My feeling is the usage of the Intel compiler will really be a plus if we can also compile the application. In other term, it seems to me that instead of working on a OFED OPKG compiled with the Intel compiler we should be better off working on a OPKG for the Intel compiler. Do you agree with that? Selon "Greenseid, Joseph M." <[EMAIL PROTECTED]>: > My users find that using the Intel compilers do increase application > performance for them over GCC (especially with x86_64 architecture, because > of the auto-vectorization you can get with the SSE aware compilers). > > Given the choice, none of the folks using my system choose GCC over Intel > (currently, all my users use Intel compilers and Intel flavors of MPI, even > though GCC is also available). > > I would say that the ability to use the Intel compilers with MPI would be > valuable, if OFED is would be considered in OSCAR. If Intel flavors aren't > included, I would probably have to choose to not install it via OSCAR, but > instead do it myself by hand to get them. > > Just the thoughts of one user... > > --Joe > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of > [EMAIL PROTECTED] > Sent: Tue 3/25/2008 12:03 AM > To: [email protected]; Paul Greidanus > Subject: Re: [Oscar-devel] OFED > > > > Hi, > > Just another idea: instead of focusing on the support of multiple compiler > (does > it really improve the global performance for all applications?), why not > working > on the virtualization stuff that are today included in OFED (Panda team work > typically), i.e., VMM-bypass and efficient VM migration? > > That's should be fun to do and it fits perfectly the OSCAR-V extension > (which, i > hope, will be very soon integrated directly into OSCAR). > > My 2 cents, > > Selon Paul Greidanus <[EMAIL PROTECTED]>: > > > Hi All, > > > > I was just looking and thinking about OFED, and how to package it into > > OSCAR, and I'm thinking it might be possible to just copy the SRPMS in, > > and have the oscar build scripts build the RPMS, like the rest of > > oscar? Also, we could use an Intel/pgi compiler to build the RPMS > > pretty easily as well, and have the option of installing optimized > > libraries, rather then just GCC.. > > > > Or do I not know what I'm talking about.. > > > > Paul > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Oscar-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/oscar-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oscar-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oscar-devel > > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
