When profiling my fortran program, Acxtrnal.dll is the part that uses most of the processor time! What is this dll?

Hi, I am profiling with VTUNE (extension for visual studio), which I wrote for my research in order to speed it up a bit. I have already accelerated my 1D model in this way (that is, identified a hot spot for my model). This time, although after starting the profiler, I see that the most time-consuming part is not the fortran routine that I wrote (as it was for my 1D model), but this is a DLL called Acxtrnal.dll. I googled the name of this dll, but I could not find better information. Does anyone know why this dll takes so much and what is it for? thanks A.

EDIT: Thus, I was able to add load symbols for the DLL from the Microsoft website, so now that debugging shows that CPU time is lost here. NS_FaultTolerantHeap :: APIHook_RtlFreeHeap. If I breed it, then (the heading routines are mine):

free <-for__free_vm
for_write_int_fmt_xmit <-for_write_int_fmt <-LIMITERSUBR <-RECMUSCL <-main __ <-main <-_ tmainCRTStartup <-BaseThreadInitThunk <- RtlUserThreadStart <-RtlUserThreadStart
for_release_lun <-for_write_int_fmt_xmit <-for_write_int_fmt <-LIMITERSUBR <-RECMUSCL <-main <-main <-tmainCRTStartup <-BaseThreadInitThunk <-_ RtlUserThreadStart <-_ RtlUserThreadStart <-_ RtlUserThreadStart <-_ RtlUserThreadStart <-_ RtlUserThreadStart <-_ RtlUserThreadStart

+1
source share
1 answer

Ok, you took a couple of stack samples shown here. Your RECMUSCL calls LIMITERSUBR, which calls for_write_int_fmt , which does a lot of things.

 free for__free_vm for_write_int_fmt_xmit for_write_int_fmt LIMITERSUBR <------ Look at the line in LIMITERSUBR that prints integers RECMUSCL because it appears on both stack samples MAIN__ main _tmainCRTStartup BaseThreadInitThunk __RtlUserThreadStart _RtlUserThreadStart for__release_lun for_write_int_fmt_xmit for_write_int_fmt LIMITERSUBR RECMUSCL MAIN__ main _tmainCRTStartup BaseThreadInitThunk __RtlUserThreadStart _RtlUserThreadStart 

You can see a sample stack in the line of code in LIMITERSUBR, where you write integers, and see if you need to do this.

(You see, you really don't need characters in the system DLL :)

Good thing you took two stack samples so you can see the problem twice. Seeing a problem once is not enough unless you know in advance that you have a really serious slowdown. Having seen this twice in so many samples, he is responsible for most of the time, for example, more than 50 percent and maybe about 100, so you should try to fix it. (This is actually a beta distribution, the most likely value of which is 2/2 = 100%.)

+1
source

Source: https://habr.com/ru/post/1240133/


All Articles