Documentation on chkstk and for_cpstr?

[croucher]

I couldn't find documentation for these functions in IVF or online. Who provides them?

VTune says chkstk is either my #1 or #2 time hog, so I'd sure like to know what it does!

[Steven_L_Intel1]

chkstk is a MSVC routine that checks for stack overflow when allocating space on the stack. for_cpstr is an Intel Fortran run-time routine that copies a string.

[croucher]

Cool, but even knowing for_cpstr is an Intel run-time, I couldn't find where it is documented. Can you point me to the documentation for at least the Intel function? Online help said 'no hits', and browsing r-t sections didn't help either.

Is getting 20% of my CPU_CLK_UNHALTED in chkstk a reasonable thing or a suspicious thing?

[Steven_L_Intel1]

We do not document the routines called by generated code.

A figure of 20% is not meaningful without knowing the context of the application - for example, if all it does is call a routine that does little, but it is called many times, one might see such a result.

[commbank]

Quoting - Steve Lionel (Intel)

We do not document the routines called by generated code.

A figure of 20% is not meaningful without knowing the context of the application - for example, if all it does is call a routine that does little, but it is called many times, one might see such a result.

Hi

I came across the for_cpstr too - during analysis using VTune. It was called in libifcoremd.dll. I understand that it is an internal function and hence not documented for the public - that's ok. But can anyone tell use roughly, what it is used for?

My application is a large MonteCarlo application and does extremely little "strings processing" which I am guessing what for_cpstr does. The Monte Carlo simulation is calculation intensive and hence I cannot understand why for_cpstr or any strings operation takes about 26% of the CPU_CLK_UNHALTED.

I hope I am wrong in assuming for_cpstr has something to do with string operations. Please give me a rough idea of what it does.

Cheers,
Clinton

[TimP]

Normally, this would indicate that you have CHARACTER string assignments in your source code (possibly something related, such as WRITE to CHARACTER string). Apparently, you and VTune disagree on how much string processing you are doing.

[Steven_L_Intel1]

for_cpstr copies a string, applying Fortran character semantics as needed (trailing blanks, etc.)

[commbank]

Quoting - croucher

I couldn't find documentation for these functions in IVF or online. Who provides them?

VTune says chkstk is either my #1 or #2 time hog, so I'd sure like to know what it does!

Hi All,

In reply to my own question which had previously been added to this thread as well as the original and general question about the time hog function "for_cpstr" and its associated functions, this is what I have found.

For my particular application which showed about 40% CPU_CLK_UNHALTED via VTune for the for_cpstr, it turns out the culprit is an IMSL function. Note your problem with for_cpstr could be due to other code. But for my problem, another interesting fact is that besides libifcoremd.dll(for_cpstr), another module imslmkl_dll.dll also has about 40%. If you have these two time hoggers, chances are the for_cpstr is being used by an IMSL function, nothing wrong with your code itself.

For more details, I nailed down the culprit to DANORIN in IMSL to do inverse standard normal CDF. I replaced it with MKL's own vdcdfnorminv and one particular test scenario for my application reduced from 34 seconds to 6 seconds. That's over 80% reduction in time.

Perhaps there is some IMSL configuration which I have missed, but that is not apparent to me. If you know why IMSL does so much "writing to strings using fortran" please reply here. In the meantime, I'm going to bring this up with Intel Premier Support to see if they can refer to IMSL about why IMSL is so slow.

Cheers,
Clinton C.

[Steven_L_Intel1]

IMSL's priority is not ultimate performance, it's breadth of solution and good mathematics. It does not make any special attempt at optimization the way MKL does.

I cannot find an IMSL function named DANORIN. I assume you mean DNORIN. Can you provide a small test case, perhaps similar to the example in the IMSL manual, that shows the performance issue? I'm wondering if IMSL is trying to report an error which is why it is moving strings.