I am using pardiso with ARPACK's Arnoldi eigensolver. The code has been in use by over 100 users for several years. I'm getting reports that the code crashes on AMD Ryzen systems. Is there anything in particular that might be causing this? I sent a DEBUG build to a user, but this didn't reveal anything as it simply crashed in identical fashion with no messages.
I'm using visual studio 2019. My ifort compiler command line is as follows:
/nologo
/O2
/I"C:\Users\Me\Documents\Visual Studio 2019\Projects\Xlrotor\ARPACK\LAPACK\x64\Debug"
/I"C:\Users\Me\Documents\Visual Studio 2019\Projects\Xlrotor\Umfpack\x64\Debug"
/I"C:\Users\Me\Documents\Visual Studio 2019\Projects\Xlrotor\ARPACK\BLAS\x64\Debug"
/I"C:\Users\Me\Documents\Visual Studio 2019\Projects\Xlrotor\ARPACK\UTIL\x64\Debug"
/I"C:\Users\Me\Documents\Visual Studio 2019\Projects\Xlrotor\ARPACK\SRC\x64\Debug"
/extend_source:132
/module:"x64\Release\\"
/object:"x64\Release\\"
/Fd"x64\Release\\vc160.pdb"
/libs:static
/threads
/cI've read about a compiler option /Qimf-arch-consistency in this thread. If I try this option, should I set it to true or false?
Thanks,
Brian Murphy
I am happy to report that my user with a Ryzen 9 7950X has reported that the crash was eliminated with the myMKL_x64.DLL built with IVF 19.1.
In addition, my user with a Ryzen 7 PRO 5875U has reported the same success.
链接已复制
The Debug build (hopefully with all runtime checks enabled, and no optimizations) should provide some error information.
>>this didn't reveal anything as it simply crashed in identical fashion with no messages.
This would seem to indicate that the program simply exited without a programmed message to indicate why.
You might use the System Event log to see if any system event was posted as to why the program terminated.
A compiler based issue with AMD is code generation containing an instruction supported by Intel but not AMD. However, in this case an Illegal Instruction error would be reported.
Also, can your user run this from Visual Studio? In VS there is an Output Window (not the command window) that logs activities of the program. In particular the loading of .DLL files. Should the program abort immediately/shortly after a DLL load, then the issue may reside in the DLL.
Jim Dempsey
I'm with Jim here - a silent exit is not likely to be caused by a compiler problem, and a review of the event log would indeed be useful.
You can try /Qimf-arch-consistency, which you should set to true, but I'm skeptical that it would have any effect on non-Intel processors. The options you're using don't generate instructions AMD doesn't support. The math library, if it does CPU dispatch, will treat the Ryzen as if it were a Pentium 4 as far as instruction selection goes.
Brian,
I should not need to state the obvious, but here goes anyway:
Should your user launch the application via Shortcut/Double-Click .AND. your program is a console application (usually is), then upon an abnormal exit, the CMD window with disappear at that time. IOW your user may not have noticed the error message displayed then evaporated. If this be the case, then instruct your user to launch a CMD window, and run the program from the command line (may have to tell the user to CD to proper folder).
Jim Dempsey
Thanks for the replies. The subject code is compiled to a DLL which is called from an Excel VBA routine. Typically, unhandled run-time errors in a DLL called this way cause Excel to vaporize with no messages of any sort, and that is what happens.
Where does one look in the Windows Event Viewer for relevant entries?
Unfortunately, I don't have a computer with an AMD processor. I may need to get one.
In situations such as this, it may help to replace the Excel VBA call by a call from a short Fortran main program with the same arguments. Are you able to create such a reproducer, along with the relevant portions of the code for the library?
You did not mention a model number for the AMD CPU that is giving you trouble. I have a PC with a Ryzen 7 4800U CPU, running Windows 11.
I am fairly certain these are Ryzen processors, but I don't know their specifics.
To create a Main program executable to replicate the crash in the DLL would be a major undertaking. At the moment, I'm looking for a Ryzen computer so I can reproduce the crash for myself, as well as test both 32 and 64 bit versions. I know for sure that the 64 bit version crashes on AMD chips, but I don't know about the 32.
You could consider performing a remote desktop into/onto the problematic system.
Microsoft Teams has a feature to permit remote control.
There are additional products see: https://heimdalsecurity.com/blog/free-remote-desktop-software/
Jim Dempsey
I asked him to run System Information from the Start button and send me what it shows for Processor. I expect it will be a few days or more before I hear back.
Where does one look in the Windows Event Viewer for relevant entries?
One fellow who has reported crashes has the following AMD processor in a desktop he built himself:
AMD Ryzen 9 7950X 16-Core Processor, 4501 Mhz, 16 Core(s), 32 Logical Processor(s)
You are running into the problem of multiple systems using sofware developed on one system. As Jim notes, remote access is the best method, I use ZOHO assist, it takes 10 minutes to install at each end, create a fake outlook account and use it as the login control. Free for five computers, the paid version gives you a lot better screen
You get directly and safely onto their desktop, install VS and one api and run it and you will learn a lot. It will be something simple and you will find out how to fix it. I bet it is not your program but something in how your program interacts with their setup.
Statistics has a horrible way of catching up with all, as noted by someone he had one NUC10 at home not giving problems, statistically that is not a representative set, but 15 NUCS of three types scattered at remote locations and the same type of the three gives problems and none of the others that is statistically significant. NASA does not let you get to TRL Level 9 without remote testing, home or lab testing is only level 6.
Good hunting.
John
Look for crashes in the event view under Windows Logs > Application.
(I strongly second mecej4's suggestion of a DLL test driver program that is independent of Excel - even if it takes a while to put together this sort of thing ends up being practically required to do adequate software testing.)
I had a chance to do some testing on a relative's laptop with a Ryzen 5 cpu. I successfully reproduced the crash and was able to learn a little about conditions required to cause a crash, I believe it likely a bug in my fortran code is the root cause, but am mystified as to why intel cpu's have no trouble, but amd cpu's do. I consider the most likely bug is overstepping array bounds, but a Debug build should have revealed this, and both intel and amd chips should behave the same. I will get my own amd computer, install VS and intel fortran, and try to track down the bug in the debugger. That will take me a week or so.
The math library takes different paths for current Intel CPUs and non-Intel CPUs.
When I get the computer with a Ryzen processor, I intend to install visual studio community 2022 which I think is done from https://visualstudio.microsoft.com/vs/community/
Once I get that done, how do I install Intel Fortran Compiler Classic?
BEWARE! Intel has only validated up to VS 2022 17.6.4. See this article. Developers on this Forum are reporting issues with 17.7 and newer. The engineering team is validating newer versions of VS for the next release.
@Barbara_P_Intel , you need to allow for the Intel Paradox, the latest Intel Compiler was released on the 20th day of the Month and requires version X of VS 2022, but on the 13th of that month MS updated VS 2022 to Version X+1 and I although I have hunted for X using the links on this forum and there are several, for community VS it is a forlorn hope. The original concept forlorn hope comes from the British Army, naming the first group to storm a city wall, ie a high death rate, but automatic promotion on success. The concept is discussed in some detail in the Sharpe's Novels of the Peninsular War.
A similar parabox is Hambly's where if a 400 lb man sits on a chair, what design load is required for each leg and the correct answer is 400 lbs and not the 100lbs taught in civil engineering school. One can apply the same principle to earthquake design. (I fully expect a useful comment from Jim on this point, I love his comments, they make my day, I also love mecej4's comments as they are always pithy and correct, unlike my pathetic ramblings.)
One can succeed using VS Pro, but who in their right mind would buy Pro when community is free and there is still beer in the world to be bought.
Warm regards
John
I have never experienced this paradox. The latest intel compiler usually just integrates into the VS you already have and if you want a new install you just run the full VS installer that you downloaded the last time you updated your VS version. If you are using Fortran only there is very little/no benefit in VS "upgrades". You can normally skip alternate VS generations and thus spend more time on development and less on messy around with VS problems that you always get with a new version.... simples.
I assume Intel has a working relationship with Microsoft. Would you (Intel) be able to obtain from Microsoft, a link to VS 2022 17.6.4 download, that you can share on this website? Note, there are links to older versions available to Enterprise users, but this is not suitable for individual users instructed to use the Community Edition.
Jim Dempsey
