MCR_CACHE_ROOT not working with 2016

8 views (last 30 days)
Matt
Matt on 25 Jul 2019
Commented: Matt on 25 Nov 2019
I have a Matlab routine that I have compiled as a standalone executable for use on a Linux computing cluster running PBSPro. There can be thousands of instances running at a time. With version 2012a I found that setting `MCR_CACHE_ROOT=${TMPDIR}` would increase execution speed by an order of magnitude. Our cluster is removing support for some older applications so I am moving to Matlab 2016a with the same code, all that is changing is the compiler version. When I compile the code and set the MCR cache as before I get an error that says
Could not access the MATLAB Runtime component cache
The 2016 version of the code will then proceed to use system RAM until the node is out of memory and the job terminates with a memory failure. If I don't specify an `MCR_CACHE_ROOT` the job runs fine, albeit slowly and then finishes.
The compile command is `mcc -v -o Program -m mFiles`, where `mFiles` is a cell array of files to compile. The only difference is compiler, MCR and corresponding LD_LIBRARY_PATH. I use the exact same compile script with the exact same source.

Answers (1)

Ashish Bhatt
Ashish Bhatt on 25 Nov 2019
When launching or calling the same deployed component, deployed component instances share the same MCR_CACHE_ROOT directory. So if there are multiple instances running at the same time each instance could possibly read/write to the same file in MCR_CACHE_ROOT and end up conflicting. We could set MCR_CACHE_ROOT to a different folder every time when launching the component to avoid crashes due to read/write conflicts.
The deployed component could be a standalone application, .net assembly, python package, JAVA package, c/c++ library... Basically all the outputs of MATLAB Compiler and MATLAB Compiler SDK that utilize CTF.
1. User could change the MCR_CACHE_ROOT manually
2. User could create a script file to launch the application. For instance, on Windows platform, user could create a batch file with below commands. The script uses date-time to name folder, so that folder name will be unique every time.
  1 Comment
Matt
Matt on 25 Nov 2019
Thanks for the detailed answer. Was there a change in how the MCR works from 2012 to 2016? My job requests a single node with between 16 and 56 cores depending on the machine used. I then use a c++ code that runs 16 to 56 concurrent threads which each launches an instance of the Matlab executable. So for a 16 core node I get 16 instances of Program running.
Prior to starting my c++ code I do (for 2012):
XAPPLRESDIR=<path to matlab2012a>/X11/app-defaults
export LD_LIBRARY_PATH
export XAPPLRESDIR
export MCR_INHIBIT_CTF_LOCK=1
export MCR_CACHE_ROOT=${TMPDIR}
${TMPDIR} is a unique local location for each node assigned by PBS. LD_LIBRARY_PATH is copied from run_Program.sh that was generated by the Matlab compiler.
For 2016 my setup is the same, with the change of path to matlab 2016.
This approached worked in 2012 getting 16 to 56 simultanious instances running and running quickly. For 2016 I recieve the error I specified above. I can clear that error by removing the last export statement.
I built a version of Program that echos the CTFROOT upon starting. It shows that MCR_CACHE_ROOT is being set.
So using 2012 I can specify a single local location for MCR_CACHE_ROOT and the code runs fast. Using 2016 (v901) I can not. I have also tried 2017 (v92) with the same problem.
Some my question is, how do I specify a unique MCR_CACHE_ROOT for each instance when they are running on the same node in parallel?

Sign in to comment.

Categories

Find more on Get Started with MATLAB Compiler in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!