Pre-loading M/MEX files for timing optimisation

Programming Help
1

Some of the timing-related functions in PTB contain the following hint:

TIMING ADVICE: the first time you access any MEX function or M file,
Matlab takes several hundred milliseconds to load it from disk.
Allocating a variable takes time too. Usually you’ll want to omit those
delays from your timing measurements by making sure all the functions you
use are loaded and that all the variables you use are allocated, before
you start timing. MEX files stay loaded until you flush the MEX files
(e.g. by changing directory or calling CLEAR MEX). M files and variables
stay in memory until you clear them.

With respect to loading M and MEX files, does this mean in practice I should be performing a ‘dummy-run’ of all timing-critical M files (such as WaitSecs, GetSecs, etc) ahead of them being used ‘for real’? i.e. just run them briefly during setup? Or is there some other way to tell MATLAB “I will need these functions later” without actually having to run them?

Also, regarding the Screen MEX file, I assume any call of Screen() is sufficient to pre-load all Screen() calls?

2

HI Matt,

To be safe, yes, just call these mex files once with any of their subfunctions (screen is indeed taken care of by, e.g., opening the screen).

Note that there aren’t that many mex files (e.g. all the keyboard and mouse functionality and such is PsychHID under the hood. See e.g. here https://github.com/kleinerm/Psychtoolbox-3/blob/master/PsychSourceGL/Source/windowsmakeit64_twisty.m for the different mex files.

3

Thanks Dee – but I’m not sure where to look in your linked file to deduce which MEX files cover which PTB scripts?

4

Hi matt,

Thats not in there, just a list (kinda) of the mex files themselves.

5

Thinking about it, except for getsecs and waitsecs, all other need some kind of setup, and are thus already called before high performance needs come into play. You should be good by just warming up getsecs and waitsecs

6

There’s no simple answer to this, only guidelines, and how slow “slow” is depends a lot on your hardware, e.g., amount of RAM and if you have a fast SSD or a slow disc drive, what operating system, what functionality you use… A warmup trial can still make sense for demanding paradigms.

E.g., initial loading of a mex file takes longer, and mex files with lots of library dependencies, e.g., Screen, will take longer. But then the slowness, e.g., for Screen will be mostly during startup / OpenWindow, as after openwindow most needed stuff will be in memory and linked/initialized. However, multi-media functions relying on GStreamer, like Screen(‘Openmovie / OpenVideocapture’) etc. will cause GStreamer to dynamically load and configure plugins, adding extra delay. But then, you won’t call openwindow or openmovie during the timing critical part of a trial…

On Linux, Priority(n) with n > 0 before the start of your actual trial loop will also trigger memory locking, a unique feature of Linux only, not supportable on Windows/macOS. Here the OS will keep any data/code from being paged out to disc until you voluntarily free that data, preventing other running applications from stealing valuable fast RAM. And other optimizations done… You can notice this if you measure the execution time of the Priority(1) call. It could take fractions of a second to seconds to complete when the system transitions Matlab/Octave from “regular app” to “get as much of the needed stuff into memory and keep it there”.

But it all depends on your task/os/hardware how much this matters, I guess if your study has some training trials at the beginning anyway to familiarize the subject, uses Priority, and a Linux system, that will be as good as it gets. There are further optimizations available for specific cases for texture preloading, flipping, movie playback from memory (preloading the movie) etc., useful on a case by case basis for demanding cases. This thing, e.g., The MPI CyberMotion Simulator - YouTube, also implemented some paradigms involving high performance playback of stereo high resolution video, where visual and audio stimulation was driven by Psychtoolbox, synchronized with robot motion controlled by a different computer etc., and on the ~2010-2012 ish hardware needed a lot of movie playback engine optimizations and special flags to make it happen, which are not the default for your typical “play a movie with PTB” use case.

So it depends, but choosing Linux as OS with recommended graphics hardware and drivers is one big step in the right direction for common cases…
-mario

7

The “Priority(n)” tip is really nice - thanks! Matt; if you present instructions at the start of an exp., you will generally invoke many of the MEX files. I just put in a short section first to do any that I use (before instructions), but opening a window and assessing your monitor’s specs will generally take care of the Screen issue.

8

If you also communicate with eyetrackers / recording systems then it is worth to include them in a 1 second warmup loop before the experiment starts where you should draw and animate all stimuli, collect eyetracker data and trigger digital I/O; by drawing a grey background on top the subject doesn’t see anything. This loads and executes all the experimental code, it only takes a second and the subject sees nothing (or you can include a message). I see in my timing logs this clearly reduces variance of the first trial or so…

For Linux you should also double-check that gamemode (Psychtoolbox-3 - LinuxGameMode) is working properly when Priority() triggers, this also really does improve timing reliability…

1 Like