Remove intel compiler support & testing

milljm commented 5 years ago

Rationale

Intel Compilers regularly require accommodations (ifdefs on the compiler type nested in the code) to compile templated code, creating a drag on resources and limiting the maintainability and readability of the code base. We also do not get access to the paid suscriber support, limiting our ability to have those fixed.

Even now when we do not support ICC officially, ICC issues still regularly come up on discussions because users have them installed on their HPC machines and loaded by default quite often

Description

We routinely run into "Internal Compiler Error" and the like. But is at the same time, not something easily reproducible. For now, we must discontinue support.

Impact

No longer offer official support for Intel compilers

no testing of ICC
no keeping track of working versions of ICC on the website

dschwen commented 5 years ago

Maybe a bit more serious rationale would state that the Intel compilers are buggy. This does not manifest often and in simple code bases, but with the introduction of automatic differentiation we are relying more and more on advanced templating techniques and we have hit an internal compiler error in https://github.com/idaholab/moose/pull/12703/commits/4f720c63730d11740cc4ba794a24c3c9ff0712ac . That particular bug can be circumvented but doing so causes a creep of unintuitive constructs that need to be documented each time.

jeffhammond commented 5 years ago

What efforts have you all made to address the ICC issues you have encountered?

I just looked in the ICC Jira and there are zero references to MOOSE. For comparison, there are 9 separate tickets associated with https://github.com/ParRes/Kernels/, which is a relatively small research project.

Full disclosure: I work for Intel but neither in software support nor compiler development.

dschwen commented 5 years ago

Hey Jeff, this is my personal opinion, and I don't speak for the MOOSE team. If we support a compiler stack, then I'd like that support to be there for pragmatic reasons. Forcing users to have a bleeding edge ICC (while a four year old GCC or clang does the job as well) narrows down our ICC userbase considerably. I agree that submitting a bug tracker entry is a noble thing to do, but I personally am much more inclined to do so for an open source project...

permcody commented 5 years ago

@jeffhammond - We've already found a workaround to the single issue that triggered this decision. However, we've been fighting the Intel compiler for some time on a variety of issues. This isn't the first time that we've had standard compliant code just fail to compile. I personally resisted dropping the compiler but the remainder of my team was adamant that we let it go until we find a specific customer that requires us to use it. If you are aware of any customers using MOOSE or a MOOSE-based code that would like to maintain Intel support, please let me know.

mangerij commented 5 years ago

Aren't a majority of the older supercomputer systems running Intel?

On Thu, Jan 17, 2019 at 6:03 PM Cody Permann notifications@github.com wrote:

@jeffhammond https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjeffhammond&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C8565442adb994cc26dfe08d67c9da663%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636833413877303599&sdata=j4%2FJbLmQtO28WLQlTIeuxiDVZRdnAnHuTNAVvjvHfmM%3D&reserved=0

We've already found a workaround to the single issue that triggered this decision. However, we've been fighting the Intel compiler for some time on a variety of issues. This isn't the first time that we've had standard compliant code just fail to compile. I personally resisted dropping the compiler but the remainder of my team was adamant that we let it go until we find a specific customer that requires us to use it. If you are aware of any customers using MOOSE or a MOOSE-based code that would like to maintain Intel support, please let me know.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fidaholab%2Fmoose%2Fissues%2F12713%23issuecomment-455249384&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C8565442adb994cc26dfe08d67c9da663%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636833413877313608&sdata=jJc68XsrpsCOKvuEK4tyvwsJ5GluJVYIbRSmUGLEpZA%3D&reserved=0, or mute the thread https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAHPulLZB_UgjC-VFSSZvGhzOtIZDS76yks5vEKzJgaJpZM4aDxih&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C8565442adb994cc26dfe08d67c9da663%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636833413877313608&sdata=XoBiGeC239aFoLtCHCY9URMSoO5C3ERPhX41MJQWVIQ%3D&reserved=0 .

jeffhammond commented 5 years ago

I agree that submitting a bug tracker entry is a noble thing to do, but I personally am much more inclined to do so for an open source project...

@dschwen If users do not submit bug reports against ICC, but do submit them against GCC and Clang, is it any surprise that the latter have greater standard compliance? How exactly are C++ parser bugs supposed to be found? Possibly related: https://www.edg.com/faq/customers.

In any case, compiler bugs are always fixed in the latest release. It is great that ancient GCC compiles everything perfectly, but if you want the most feature complete Intel C++ compiler, you need to use the latest releases (which are usually available on HPC systems). If access to the latest Intel C++ compiler is a problem for the MOOSE developers, I can give you licenses so you can address these issues.

@permcody In my experience, it is impossible to know what users are doing until downstream user experience is broken, at which point it is much harder to solve the problem. This was our experience with Elemental.

@mangerij If you mean the vast majority of the Top500 systems contain Intel Xeon processors, then yes, but these are supported by Intel, GCC, LLVM, Cray and PGI compilers (at least).

dschwen commented 5 years ago

@jeffhammond, submitting a bug report is not that straight forward. The website wants to direct me to "premium support". "icc jira" yields no Google results... I created an Intel Developer account and posted in the ICC forum now: https://software.intel.com/en-us/forums/intel-c-compiler/topic/803259 (post pending moderator approval).

jeffhammond commented 5 years ago

@dschwen Intel Premier Support is the official mechanism for filing a bug report. You can post to the IDZ Forums but I do not know how frequently those are monitored (probably frequently). ICC Jira is internal and is where external and internal bug reports land.

In any case, I'm willing to accept bug reports directly (jeff.r.hammond@intel.com) so long as they come in one of three forms:

1) Preprocessed i.e. standalone source file. If you don't already know how to generate these, do this:

# normal compilation
${CXX} ${CXXFLAGS} -c ${NAME}.c -o ${NAME}.o
# standalone source generation
${CXX} ${CXXFLAGS} -E ${NAME}.c -o ${NAME}.i

These files are system (OS+GCC) dependent, so it is ideal if they are generated on a platform with a fairly common configuration (see e.g. the list below).

2) Idiot-proof reproducer instructions:

# example
git clone ${GITHUB}
git checkout ${HASH}
mkdir build && cd build
${CONFIGURE} ${OPTIONS}
make

3) Proper MCVE.

I recognize that 3 is often highly non-trivial for C++ codes and do not expect this. The first two are sufficient. I will likely generate 1 from 2 but it takes longer.

You can assume that I have access to CentOS 6 and 7, Ubuntu 16 and 18, MacOS latest or latest-1, but never Windows. I have every version of ICC since 2015 although bug reports against older versions are less helpful, especially if they are fixed in a more recent release.

dschwen commented 5 years ago

Ok, let me try option 1. I'll email you shortly.

dschwen commented 4 years ago

I wonder if anything ever came out of that bug report. @jeffhammond, do you have any info?

permcody commented 4 years ago

Background: We are once again motivated to support Intel compilers if we can get them working so that we may interact with a customer who only supports compilation on the Intel compilers.

jeffhammond commented 4 years ago

I have no idea. I don't have access to email older than a year. I know I did something about it but don't see any JIRA references to MOOSE. Can you forward me any info on the Intel Premier Support ticket you created? I'll see if I can chase it down.

dschwen commented 4 years ago

Jeff, I never had access to "Intel Premier Support". As mentioned above I posted on the forum: https://software.intel.com/en-us/forums/intel-c-compiler/topic/803259 and I believe I sent you the same info per mail (you requested the preprocessor output - its on that post).

jeffhammond commented 4 years ago

@dschwen Thanks for the pointer. I'm sorry this was not addressed in a timely fashion. I must have dropped the ball at some point but, in any case, I've asked the compiler support team to look at your IDZ post. If you don't see action by next week, email my work address (see above) and I'll raise hell.

It would seem that the MOOSE developers should figure out who at INL can file IPS bugs on their behalf. I have no idea how to do that but will work with your account executive to see if we can figure it out.

jeffhammond commented 4 years ago

This bug is resolved in 2020.0.166 but is present in 2019.4.243. I asked someone from the compiler support team to take a look.

idaholab / moose