intel compiler 11.1

[Wolfgang]

Menchar,

Now that you have ICL 11.1 up and running, would you mind to try and include one of the advanced math functions, i.e. dtrnlsp_init in your code? The latter requires to include

#include "mkl_rci.h"
#include "mkl_service.h"
#include "mkl_types.h"

to define a handle

_TRNSP_HANDLE_t tr_solver_handle;
 

and to link with mkl_core, mkl_intel_c, mkl_sequential, and mkl_solver_sequential. The latter library causes quite a few link errors in my case. Would be great if you could figure out how to solve my link problem, too 🙂

Thanks...

Wolfgang

[jr_2005]

---

menchar wrote:

And the reason was the evaluation order of the expression I was using to calculate elapsed time was different with the Intel compiler

---

I would be interested to see the section of code involved in the expression, here, to understand this difference between the compilers - the order of operator evaluation within an expression is fixed by the C standard, although of course side effects and the order of evaluation of function parameters is not. Is this what you are talking about?

JR

[menchar]

Good point on the C standard control of expression evaluation, though my H&S says "In general, the compiler can rearrange the order in which an expression is evaluated."  p 253 section 7.12.

Here's the expression that works:

    double                  dTime;
    long long              llPerformanceCounter;
    static long long *  pllPerformanceCounterStart;
    static long long *  pllPerformanceCounterFrequency;
   
    dTime = (double)((llPerformanceCounter - *pllPerformanceCounterStart) / (double)*pllPerformanceCounterFrequency);

This expression works on LCC release mode compiler (CVI native compiler) but not on the Intel 11. compiler:

   dTime = (double)((llPerformanceCounter - *pllPerformanceCounterStart) / *pllPerformanceCounterFrequency);

I guess the surprise is that the long long integer divide gets promoted to double by the CVI compiler.  The Intel compiler evaluates the long long int expression as long long int and then casts the result (which is zero due to large denominator) to double.  This might be more about the "usual binary conversions" than anything else.

Most casts are an indication of a design error anyway according to Mr Stroustrop.

This type of difference isn't all that uncommon - I've seen studies on expression evaluation comparison on popular C/C++ compilers and it's amazing how they differ from each other and the language spec itself in some cases.  I think NI posted one of these up in re floating point comparisons somewhere in the CVI help.  In that case the CVI compiler was  provably doing the "right thing" while the MS VC++ compiler did not.

Menchar 

[jr_2005]

One of the earliest C compilers I encountered (back in the 1980's - way before ANSI C) took it upon itself to automatically promote all components of an expression to double when it saw a cast of this type. Looks like the CVI compiler might have some of this philosophy left inside it, despite it supposedly being a full ANSI one.

Very odd that it risked a reduction in precision in this particular case - it is debatable as to whether a change from a 64 bit integer to a 80 bit double is actually a promotion, given the loss of significant bits.

Like most things that are powerful, casts can also be dangerous in the wrong hands. I always treat them as very sharp objects, when I cannot avoid them. (Just one reason why I prefer coding in C to C++ )

JR

[msaxon]

---

jr_2005 wrote:

Very odd that it risked a reduction in precision in this particular case - it is debatable as to whether a change from a 64 bit integer to a 80 bit double is actually a promotion, given the loss of significant bits.

---

? 80 bit (extended, or long) double has a 64 bit mantissa, so there would be no loss of significant bits. If, however, you meant 64 bit double I would agree.

Message Edited by msaxon on 11-11-2009 01:32 PM

[jr_2005]

Sorry yes of course I meant 64 bit double. Long day...

[menchar]

You have to be careful when making claims about precision and floating point.

64 bit doubles on an x86 are handled with 16 guard bits (80 bits total) to maintain precision during calculations.  So floating point expression values can have better precision than you would predict if you consider them as strictly 64 bits.

Menchar

[menchar]

And BTW a 64 bit IEEE 754-1985 double does not have a 64 bit mantissa, it has 52 bits of mantissa.