- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am using Intel Fortran Compiler 10.1 for a computation intensive program that I want to optimize. When analyzing the program performance with VTUne, there is a report of an intensive use of the _CIpow function in the microsoft runtime module msvcrt. Indeed I have lot of pow functions (x**y) in my code. However I was expecting this to translate to _pow in the msvcrt module calls.
1) What is the performance of _CIpow vs _pow
2)If the performance of _pow is supposed to be better, is there a way to tell the compiler to translate x**y in the usage of _pow as I know that I am using any complex number.
3) Is there any other way to improve the fortran math library performance without moving to anything heavy like Intel MKL (which manages vector while I just want to manage double).
Regards
Fabien
I am using Intel Fortran Compiler 10.1 for a computation intensive program that I want to optimize. When analyzing the program performance with VTUne, there is a report of an intensive use of the _CIpow function in the microsoft runtime module msvcrt. Indeed I have lot of pow functions (x**y) in my code. However I was expecting this to translate to _pow in the msvcrt module calls.
1) What is the performance of _CIpow vs _pow
2)If the performance of _pow is supposed to be better, is there a way to tell the compiler to translate x**y in the usage of _pow as I know that I am using any complex number.
3) Is there any other way to improve the fortran math library performance without moving to anything heavy like Intel MKL (which manages vector while I just want to manage double).
Regards
Fabien
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As the Microsoft library is unlikely to have a complex exponentiation function, ifort, like any traditional Fortran compiler, would provide its own implementation of exponentiation functions.
1) It doesn't make a lot of sense to compare performance of (single precision?) complex (to integer power?) exponentiation against double precision to double precision power, at least not in the sense of attempting to find out which is implemented more efficiently. For small integer powers, you may want to allow the math function to multiply the operand against itself directly, rather than expanding real and imaginary components.
2) C math functions (and f2c or libgfortran Fortran math library support, which you apparently would require) may be called directly from Fortran via USE iso_c_binding. I suppose, if you are running the 32-bit library, you would have only x87 code math functions available, while the Fortran library should make good use of SSE3 for complex.
We continue to debate whether the Fortran library should switch into SSE3 by sensing SSE3 platform support, rather than in accordance with the /arch compile switch. For complex double precision support, SSE3 ought to be an advantage both for in-line code and to avoid extra overhead in calling math functions.
If you consider MKL heavy, I wonder why you prefer to write your own math functions in terms of C89 (and, presumably, libf2c, which you will have to build yourself) when Fortran and C99 have appropriate built-ins. The goal would have to be educational rather than performance.
1) It doesn't make a lot of sense to compare performance of (single precision?) complex (to integer power?) exponentiation against double precision to double precision power, at least not in the sense of attempting to find out which is implemented more efficiently. For small integer powers, you may want to allow the math function to multiply the operand against itself directly, rather than expanding real and imaginary components.
2) C math functions (and f2c or libgfortran Fortran math library support, which you apparently would require) may be called directly from Fortran via USE iso_c_binding. I suppose, if you are running the 32-bit library, you would have only x87 code math functions available, while the Fortran library should make good use of SSE3 for complex.
We continue to debate whether the Fortran library should switch into SSE3 by sensing SSE3 platform support, rather than in accordance with the /arch compile switch. For complex double precision support, SSE3 ought to be an advantage both for in-line code and to avoid extra overhead in calling math functions.
If you consider MKL heavy, I wonder why you prefer to write your own math functions in terms of C89 (and, presumably, libf2c, which you will have to build yourself) when Fortran and C99 have appropriate built-ins. The goal would have to be educational rather than performance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Tim,
Thanks for the answer. Your point 2 gives some hints on a possible way to go. However, i would like to clarify that my program does not use any complex number but only double values. However the analysis in VTUNe show a heavy usage of CIpow, which I was not expecting
In summary, your recommendation is to that for double precision to double precision power, I should call the C power function directly and this should force the compiler not to translate to CIUpow but rather to any function I have directly called.
Regards
Fabien
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recommended calling the C pow() function directly only if you are intent on evaluating that possibility. As I pointed out already, if you wish to handle complex, you could find public source code which implements the various Fortran math functions in terms of C libraries (in some cases C99, not implemented by Microsoft).
If you think C code would inherently perform better than ifort supplied libraries, you could verify your supposition by comparing ifort and gfortran.
If you think C code would inherently perform better than ifort supplied libraries, you could verify your supposition by comparing ifort and gfortran.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page