mathimf and windows

mathimf and windows

Hi,

I have a couple of questions on the usage of the math library in windows (64bit, vs2010).

In the documentation of the intel c++ compiler (12.1), in the article "Using Intel Math Library" a simple program appropriate for windows is presented and then the user is instructed to add the compilation flags /Qlong-double /Qpc80 . After adding them in the Additional Compile Options of project properties (there is no visual entry for this), I got a warning that the options are not recognized and therefore ignored . What am I doing wrong ?

Also, tried to go through the mathimf.h file and so some ppc macro __INTEL_COMPILER (or something very similar). Where is this defined ? Should I define it ? Also there seems to be __ICL etc. where can one obtain a list of the meaning of these macros ? Unfortunately the documentation shipped with the product (Parallel Studio 2011) leaves some to be desired..

Thank you in advance for your help,

Petros

98 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

>>.../Qlong-double /Qpc80. After adding them in the Additional Compile Options of project properties (there is no visual
>>entry for this), I got a warning that the options are not recognized and therefore ignored.

You could read a statement about support for long double floating point values on a page 707 in a Intel C++ compiler User and Reference Guide ( PDF Document number: 304968-023US ). Here is a quote:

...
Note that the Microsoft compiler and Microsoft-provided library routines (such as printf) do
not provide support for 80-bit floating-point values
. As a result, this option should only be used
when referencing symbols within parts of your application built with this option or symbols in
libraries that were built with this option.
...

>>...macro __INTEL_COMPILER (or something very similar). Where is this defined?

__INTEL_COMPILER is internal predefined macro of Intel C/C++ compiler.

>>...Unfortunately the documentation shipped with the product (Parallel Studio 2011) leaves some to be desired...

If you found some error or some subject is not clearly described ( in a PDF file or Online ) please provide a feedback. Thanks in advance.

You can access the .chm including description of the options you mentioned from the Start menu, in case you have difficulty with the installation of ICL documentation under the VS GUI.  Start>all programs>intel parallel studio....>documentation>

The ability to support long-double as wider than double, which was always incompatible with the Microsoft library/header usage, appears to have been removed, and /Qpc80 would then apply only to the IA32 compiler in /arch:IA32 mode.

As Sergey hinted, you should check the Additional Predefined Macros category in the documentation, and maybe file an issue to request restoration of fuller documentation on __INTEL_COMPILER.

imP and Sergey,

Thank you for your comments. However- Sergey- the documentation indeed says that the long double in printf is not supported. aturally, since MS crt does not -really-know long doubles  . However this in no way means, that the option to the compiler should not be recognized ! This has nothing top do with what I use it for .Also, I do not know the page reference you are offering since I only have the chm which I view from the Help menu in vs2010.However, (if this were somewhere else, then I don't know how to get to it - I have no pdf file with the compiler reference as you seem to suggest - would though be strange since  this is the place where the usage of the math library is described ).

At the end of the day, I still don't know how to use the 80bit long-double from the 12.1 intel c++ compiler within the vs2010 environment.

Also, TimP, I see in the documentation, under compiler reference, a topic named "Macros". I do not see any Additional Predefined Macros entry. Where is it ? (again, looking at the chm in vs2010)

Thank you in advance for the help (indebted that you came back to me on a Sunday!! -;)))

PS: Apologies if all this is too naive/pedantic, but the vs2010 help facility is the only documenattion I have. Is there something more that I could see on the internet ?

I would like to add that Microsoft compilers and run-time libraries provide backward compatibility for long double primitive type.This compatability is intended mainly to be used by 16-bit compiled code.

Here is the link :http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx

Apologies: to TimP for mis-spelling his name ( the evils of wireless keyboard ;-)).

Clarification: I only tried to compile the program that is presented in the documentation .Apparently I do not have documentation that responders refer to.

Question: Is there a more complete documentation for the intel c++ 12.1 compiler I could download ? Could it be that it is the C++ Compiler XE 2011 that supports this ?  (are they different ?)

XE 2011 and 12.0/12.1 are the same thing.  Current versions are 13.0, but 12.1 remains fully supported (but as you say, not strongly documented as to features which may have been dropped since earlier versions).

Perhaps you could quote a URL of documentation to which you refer.

XE 2011 and 12.0/12.1 are the same thing.  Current versions are 13.0, but 12.1 remains fully supported (but as you say, not strongly documented as to features which may have been dropped since earlier versions).

Perhaps you could quote a URL of documentation to which you refer.

>>...At the end of the day, I still don't know how to use the 80bit long-double from the 12.1 intel c++ compiler within the vs2010 environment.

Please do a very simple test:

- Enable all compiler options related to 'long double' ( even if they will be ignored, or unsupported, etc )
- Try that code:
...
printf( "Size of [ long double ] in bytes is: %d", sizeof( long double ) );
...
What is a result?

Here is my question: If the result is 8 bytes ( 64 bits ) or 10 bytes ( 80 bits ) how in these two cases 80-bit precision could be supported? At least 12 bytes ( 96-bits ) are needed.

Note: MinGW is the only C/C++ compiler I know ( actually it could be more... ) that allocates 12 bytes ( 96-bits ) when a long double variable is declared.

TimP,

I use the chm documentation that comes in vs2010. I checked it against the document Sergey suggested and is pretty much identical (especially when it comes to the specific topic) maybe a bit more skewed to Linux.

Sergey,

It is pretty clear to me that printf being a function from the ms rt will have no concept of an 80 bit long double. This is besides the point, though.

The compiler tells me that the options are NOT supported. As I mentioned before, I am using the example from the documentation, where in the printf line the 80bit floater is casted down. So the printf is not the problem. And the intel documentation does a very good job to warn the user, when it says that this has to be internal to the his/hers application.

Thank you for your help TimP and Sergey .

"Note: MinGW is the only C/C++ compiler I know ( actually it could be more... ) that allocates 12 bytes ( 96-bits ) when a long double variable is declared."

As far as I know, icc for linux follows the same practices as gcc: for 32-bit compilation, 80-bit long double is padded to 96 bits; for 64-bit mode, it's padded to 128 bits for (sometimes) improved performance.

>>>It is pretty clear to me that printf being a function from the ms rt will have no concept of an 80 bit long double. This is besides the point, though.>>>

For what kind of mathematical calculation do you need 80-bit long double primitive precision?

@Petros

If you are interested in arbitrary precision calculation(elementary functions mainly trigo) please let me know.I will kindly share with you my work.

>>...It is pretty clear to me that printf being a function from the ms rt will have no concept of an 80 bit long double. This is besides the
>>point, though.

Petros,

We're trying to help you and the test I've provided simply checks how many bytes will be allocated on your platform for a long double variable. Once again, could you run the test and tell us result, please:
...
printf( "Size of [ long double ] in bytes is: %d", sizeof( long double ) );
...

If your include files are in order (by no means assured), the contents of <float.h> would enable you to figure out how much of the storage space is padding.  If <float.h> is incorrect, http://homepages.cwi.nl/~steven/enquire.html would show you how to generate entries which match what your compiler actually implements for a given option set.

Sergey,

Apologies if I made your efforts more difficult. I followed your suggestion and ran the following little snippet :

(vs2010, intelc++ 12.1, win7 64bit)

#include "mathimf.h"
#include <iostream>

int main() {
    long double ld = (long double)(0) ;
    std::cout << sizeof( ld ) << std::endl ;
    return 1;
}

The result I got was 8 - i.e. like an ordinary double. My understanding is that if the 80bit long double was used, it would be 10.

I linked with libm.lib - and, of course, during the compilation phase I got the warnings :

1>  Building with Intel(R) C++ Compiler 12.1
1>ClCompile:
1>  ***** ClCompile (Win32 - Intel C++)
1>icl : warning #10148: option '/Qlong-double' not supported
1>icl : warning #10148: option '/Qpc80' not supported

Ilyapolak

Thank you very very much for your kind offer. Will not be needing it, but really thank you ! I mainly need this featutre for 2 reasons:

a) porting libraries from Linux that need a long double for their own thing

b) for reduction methods of very long arrays .

TimP

Not sure I understood.

I would like to thank everyone who has contributed to help ;-)

>>>Ilyapolak

Thank you very very much for your kind offer. Will not be needing it, but really thank you ! I mainly need this featutre for 2 reasons:

a) porting libraries from Linux that need a long double for their own thing

b) for reduction methods of very long arrays>>>

@Petros

I have forgotten to add that my arbitrary precision library is written in Java and is based on BigDecimal class.

Does Linux support long double primitive?

Ilyapolak

I think so - not a Linux person, so please don't quote me - oh, I forgot I just put this in writting ;-))

Again, thank you very much  for the kind offer to share your work.

Could it be possible that I would have to ignore one of the microsoft librray in order for libm to "pick" the right long double ?

I am thinking, maybe it is the sizeof from the ms crt that is somehow giving always 8 for long double (say was implemented as a template and this  is a specialization for pod-s ). And also, if I was to use a function, say exp (for an orinary double), from libm, why the linker would not complain that there is a required function found in two different input libraries ?

Does switching to the intel compiler tools take care of it ? Am I missing something/talking nonsense ?

>>>Again, thank you very much  for the kind offer to share your work.>>>

No problem.We are here to help each other.

OK, I think I understand some of what is happenning per the last question :  mathimf.h defines _INC_MATH which silences the ms cmath which delegates to the math.h. That does not solve the linking issue, though

>>The result I got was 8 - i.e. like an ordinary double.

Thank you! This is what I wanted to verify.

>>My understanding is that if the 80bit long double was used, it would be 10.

Or greater than 10.

>>
>>I linked with libm.lib - and, of course, during the compilation phase I got the warnings :
>>
>>1> Building with Intel(R) C++ Compiler 12.1
>>1>ClCompile:
>>1> ***** ClCompile ( Win32 - Intel C++ )
>>1>icl : warning #10148: option '/Qlong-double' not supported
>>1>icl : warning #10148: option '/Qpc80' not supported

Now, you've started your thread with expression '...on the usage of the math library in windows ( 64bit, vs2010)...'. Could you do a sizeof( long double ) verification for a 64-bit application ( for a 64-bit WIndows platform )?

>>...Could it be possible that I would have to ignore one of the microsoft librray in order for libm to "pick" the right long double ?

Please take a look at Linker Options of Visual Studio 2010. You could ignore any libraries, or even all of them for a project.

Sergey,

64bit was referring to the windows version - not the long double size !  know that ms uses double for long double. Also, I know that ms bundles its math library inside msvcrt10.dll. Finally I know that I can ignore libraries. Meanwhile I figured out how the clahes are avoided: the header files use the function names as aliases to  the ones exported by the library. Different header file results to different "aliasing" and therefore no name collision for the linker.

Having said all this and having done what you asked me to do, I still cannot get a long dopuble out of the libm librray !

In the end of the day, is it possible ? The documentation, before the example says :

"The following example programs illustrate the use of the math library on Windows* operating systems."

And after it says:

"Since the real_math.c program includes the long double data type, be sure to include the /Qlong-double and /Qpc80 compiler options in the command line:"

Now, it may be a not very well written documentation. But if this he case?

>>...Having said all this and having done what you asked me to do, I still cannot get a long dopuble out of the libm librray !

Here are a couple of more notes with regard to long double floating-point type:

- Some Open Source libraries don't use it at all ( example, OpenGL )
- You're not the first developer who wanted to use it due to some reason or project requirements ( by the way, Why do you need to use it? Could you exaplain? )
- Take a look at a float.h header file and you will see the following piece of codes:

...
#define LDBL_DIG DBL_DIG /* # of decimal digits of precision */
#define LDBL_EPSILON DBL_EPSILON /* smallest such that 1.0+LDBL_EPSILON != 1.0 */
#define LDBL_MANT_DIG DBL_MANT_DIG /* # of bits in mantissa */
#define LDBL_MAX DBL_MAX /* max value */
#define LDBL_MAX_10_EXP DBL_MAX_10_EXP /* max decimal exponent */
#define LDBL_MAX_EXP DBL_MAX_EXP /* max binary exponent */
#define LDBL_MIN DBL_MIN /* min positive value */
#define LDBL_MIN_10_EXP DBL_MIN_10_EXP /* min decimal exponent */
#define LDBL_MIN_EXP DBL_MIN_EXP /* min binary exponent */
...

and All LDBL_xxx are based on DBL_xxx macros ( you already mentioned '... that ms uses double for long double...' / also in many other posts related to that subject on different Intel forums ).

You referred to the article "Using Intel Math Library" in your first message. Could you post a web-link to that article? Sorry, but I can't find it...

>>The result I got was 8 - i.e. like an ordinary double.

>>>Thank you! This is what I wanted to verify.

>>My understanding is that if the 80bit long double was used, it would be 10.

Or greater than 10.>>>

Sometime compilers will allocate for 80-bit long double 12 bytes of memory in order   to be aligned on 4 bytes boundaries.

>>>- Some Open Source libraries don't use it at all ( example, OpenGL )>>>

There is also no need for such a high precision primitives in rendering operation.For example most display devices cannot handle more than 10-bit per signal component.

HDR rendering can benefit from high precision primitives because it is trying to approximate human vision in term of perceived dynamic range.

>>...Sometime compilers will allocate for 80-bit long double 12 bytes of memory in order to be aligned on 4 bytes boundaries.

Here is a quote from MinGW documentation for switches `-m96bit-long-double' and `-m128bit-long-double':

...
Modern architectures (Pentium and newer) would prefer `long double'
to be aligned to an 8 or 16 byte boundary. In arrays or structures
conforming to the ABI, this would not be possible. So specifying a
`-m128bit-long-double' will align `long double' to a 16 byte
boundary by padding the `long double' with an additional 32 bit
zero.
...

>>>Modern architectures (Pentium and newer) would prefer `long double'
to be aligned to an 8 or 16 byte boundary>>>

Could this be because of SIMD instructions which "prefer" to access data aligned on 16-byte boundaries.

>>Could this be because of SIMD instructions which "prefer" to access data aligned on 16-byte boundaries.

Unfortunately, that wasn't mentioned or explained in a doc file. Thanks for the note!

>>Could this be because of SIMD instructions which "prefer" to access data aligned on 16-byte boundaries.

Unfortunately, that wasn't mentioned or explained in a doc file. Thanks for the note!>>>

I have forgotten to mention that SIMD instructions can not work with 80-bit primitives.

Sergey,

Here you go ( the same document, in chm form shows, in the documentation in vs2010 under the Help  menu )

http://software.intel.com/sites/products/documentation/hpc/composerxe/en...

I don't hope/wish for a 128 bit long double ;-)

I saw this to be an option in the intel c++ compiler and since I had some problem with reduction on very long arrays ( suspected/wanted-to-exclude that had to do with numerical over/under-flow ).

Unix uses fully fledged 128 bit long doubles - just an example, to go together with the list of those you mention that don't.

I really did not think that this would end up being such a big discussion when I first asked - I regret that all this noise has been created ;-))

In the end of the day I get the feeling that it is a fluke of the documentation - was hoping that, you would tell me that I was doing something wrong.

Especially the comment -in the code exmple :

// printf() does not support the printing of long doubles

// on Microsoft Windows*, so fp80bits is cast to double in this example.

lead me to believe that this feature is avail on the windows platform. The discussion for why someone would need this - although, probably, a valid one, but not my own opinion - would seem, to me, to have been answered by the very fact that this was made avail by the library.

Thank you for your help,

P-

UPDATE: why would I ever need to cast down on windows, if the feature was not avail and the "long double" was an "ordinary" double ?

>>>Unix uses fully fledged 128 bit long doubles - just an example, to go together with the list of those you mention that don't.>>>

Intel hardwware does not support quadruple precision.Almost all implementation are software based.

I think that the quadruple precision will be mostly useful in obtaining or maybe preserving an accurracy in 64-bit fp arithmetic.Think about Pi which is represented as 128-bit quadruple precision value.

Citation :

Petros Mamales a écrit :

UPDATE: why would I ever need to cast down on windows, if the feature was not avail and the "long double" was an "ordinary" double ?

You do not need to cast 80-bit long double  double precision.Anyway 80-bit is not supported.

Personally I would prefer vectorization of my function over an attempt to achieve greater precision.

Illyapolak

Unix was an example on whether the 128bit double is deemed as useful. I clearly stated that I don't care for this.

My function is extremely vectorizable (using expression templates) this is not my problem.

So do I understand correctly your statement "Anyway 80-bit is not supported" to mean

-the intel c++ 12.1 for windows does NOT support 80bit long doubles despite what is said in theintel documentation-

?

Please, confirm so we can put an end to this long discussion.

Thank you for your help,

P-

>>>So do I understand correctly your statement "Anyway 80-bit is not supported" to mean

-the intel c++ 12.1 for windows does NOT support 80bit long doubles despite what is said in theintel documentation->>>

As it was already stated in this discussion VS 2010 and MSVCRT runtime library does not support 80-bit primitive.Windows keep it as backward compatibility with 16-bit code.

Link here:http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx

By vectorization I mean to be able to perform a calculation on 2-4 values.For example sine function calculation with the help of inline SSEn assembly instruction.

Example here :http://software.intel.com/en-us/forums/topic/278083?page=6

Look at my post from Sat, 11/10/2012 - 05:55

>>Here you go ( the same document, in chm form shows, in the documentation in vs2010 under the Help menu )
>>
>>http://software.intel.com/sites/products/documentation/hpc/composerxe/en...

Thank you and I'll take a look.

>>...
>>I really did not think that this would end up being such a big discussion when I first asked - I regret that all this noise has been created ;-))

This is actually a hot topic for developers working on scientific projects ( for example, multiply two 8192x8192 matrices with 'double' ( 53-bit precision ) and a result won't be perfect at all ).

Thanks to everybody and I personally stop posting unless I find something really helpfull and interesting that could help to Petros.

Best regards,
Sergey

>>>This is actually a hot topic for developers working on scientific projects ( for example, multiply two 8192x8192 matrices with 'double' ( 53-bit precision ) and a result won't be perfect at all ).>>>

I think that I will run some 2D matrix multiplication test on arbitrary precision sine function.It would be interesting to observe and measure the time needed to accomplish such a memory-expensive task.I will post results later.Code is written in Java.

Iliyapolak,

We have been over the ms treatment of "long double"s. But this says nothing.

Here is an example: Say I want to calculate the curtosis of a statistical sample , of a vector of size say 1,000,000 elements -curtosis because it involves powers of the element up to fourth. Then I choose to tun this accross threads for efficiency. The (partial)sums of the elements can be declared as long doubles and in the end of the day, when diided by the -long double'd- size of 1,000,000 be casted down to the familiar old friend the ms double, saving the user the headache of worrying about over/underflow and compromise of precision.

As you can see, the inability of ms to offer long doubles has nothing to do with the potential usefulness of intel's 80 bit double.

I think the documentation is simply wrong - there is no other windows run time for intel to offer the etension to- and misleading.

PS: yes the additions of long doubles and divisions in my example would have to be provided too..

Could you try using option /Qlong_double instead of /Qlong-double? I have a newer version of the compiler on my windows 64-bit server, and it does recognize this option. Test case attached that passes when compiled with /Qlong_double but fails with either default options or with the microsoft compiler.

Fichiers joints: 

Fichier attachéTaille
Télécharger test.c1.17 Ko

HI Melanie,

Thank you for the suggestion.  No, it did not pass :

1>MessageBuildingWithCompiler:
1>  Building with Intel(R) C++ Compiler 12.1
1>ClCompile:
1>  ***** ClCompile (Win32 - Intel C++)
1>icl : warning #10148: option '/Qlong_double' not supported
1>icl : warning #10148: option '/Qpc80' not supported
1>  main.cpp

Addition : Melanie's testimony could serve as proof beyond doubt that, the availability of 80 bit long doubles on windows has nothing to do with the ms rt.

>>>Here is an example: Say I want to calculate the curtosis of a statistical sample , of a vector of size say 1,000,000 elements -curtosis because it involves powers of the element up to fourth. Then I choose to tun this accross threads for efficiency. The (partial)sums of the elements can be declared as long doubles and in the end of the day, when diided by the -long double'd- size of 1,000,000 be casted down to the familiar old friend the ms double, saving the user the headache of worrying about over/underflow and compromise of precision.>>>

This is obvious that we have a different projects and different needs.As I told you earlier for my project  I would choose a 2D double precision or 4D  single precision vector of scalar values instead of increased precision of the single scalar result.

>>>I think the documentation is simply wrong - there is no other windows run time for intel to offer the etension to- and misleading.>.>>

Sorry I can not understand what do you mean by writing this sentence.

>>>Addition : Melanie's testimony could serve as proof beyond doubt that, the availability of 80 bit long doubles on windows has nothing to do with the ms rt.>>>

Intel compiler supports long double type,but when Intel compiler calls Micrososft implementation of printf() which in turn does not support long double.

Iliyapolak,

Understood that different people have different projects/needs. So, the question is very simple:

does the compiler support an 80bit long double as the documentation states?

The answer to this, as is becoming increasingly clear, is negative.

Noone cares about the silly printf, noone ever intended to call it - except from the very unfortunate test in

the documentation- I mean, who really wants to show a new feature by focussing on what it cannot do ;-))

Please, let's not keep revisiting what we have already covered.

Thank you for your help,

P-

At this point, I think I should put the whole thing to rest. We have been trying to get to a legit answer since last Saturday, almost a week.

If there is some kind of a workaround I would like to know, but do not wish to "debate" no matter how well- intended - and I trully belive the are -

people are.

The good news is that in a next release - as Melanie said- the issue is solved and I will have to wait until the next release and I meet in the same environment ;-))

Thank you very much everyone for your kind efforts to help,

P-

At this point, I think I should put the whole thing to rest. We have been trying to get to a legit answer since last Saturday, almost a week.

If there is some kind of a workaround I would like to know, but do not wish to "debate" no matter how well- intended - and I trully belive the are -

people are.

The good news is that in a next release - as Melanie said- the issue is solved and I will have to wait until the next release and I meet in the same environment ;-))

Thank you very much everyone for your kind efforts to help,

P-

Hi Petros,

>>...If there is some kind of a workaround I would like to know...

I'll provide another simple test-case for you and if it doesn't work then we will need to simply wait for another version of Intel C++ compiler ( absolutely right point of view... ).

Hi Melanie,

Thank you for the test-case. Unfortunately, I don't think that Petros wanted to verify all these constants. Instead, Petros wanted to improve accuracy of calculations of some algorithm on a data set with ~1,000,000 elements declared as 'long double'. By the way, I didn't understand what version of Intel C++ compiler you're using. You informed everybody '... I have a newer version of the compiler ...'.

Best regards,
Sergey

Pages

Connectez-vous pour laisser un commentaire.