Forum
Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
mkytch

Junior Member
Registered:
Posts: 6
Reply with quote  #1 
Hi all,

The NIMH MonkeyLogic 2 provides a mechanism that users can bypass the condition file using a userloop script.

Because the userloop is called every time before a trial, I was wondering if there's any way to access taskobjects already loaded in previous call of the userloop function, such that loading time before each trial would be much shortened.

For example, if all the stimuli can be loaded as taskobjects before the first trial, then further userloop calls would only need to return those loaded taskobjects instead of creating new taskobjects each time.

Thanks a lot!
0
Jaewon

Senior Member
Registered:
Posts: 312
Reply with quote  #2 
That is actually a great idea! I would certainly do so if I program with C++. I was so buried in the structure of the old ML and it didn't occur to me.
0
Jaewon

Senior Member
Registered:
Posts: 312
Reply with quote  #3 
I implemented your idea and did some tests. To explain the results, I should start with three big factors that determine the minimum ITI.

1. data writing time
2. runtime generating time
3. stimulus loading time

In my tests, their relative impacts were roughly 2>=1 >>>>>>>>>>>>>>>>>>>> 3. Of course, this can differ from test to test. I just tested with a simplest timing code and two stimuli only. Nevertheless, the time taken to load a pic was just 2-3 ms and almost negligible in NIMH ML2. So the advantage of this pre-loading is not that big, if you use just a few pics.

However, if you use movie stimuli, pre-loading is great. One movie adds about 180-230 ms to the minimum ITI, but this additional cost becomes close to 0 with pre-loading.

The idea of pre-loading is actually effective in generating the runtime as well. When you run a task with a userloop file, the runtime is re-generated every trial, even though you use the same timing file over and over, and therefore the minimum ITI is much longer than when you run the same task with a conditions file where all runtimes are generated already before any trial starts. Pre-generating runtime, in addition to pre-loading stimuli, helps with it and makes the ITI required in a task composed with the userloop file the same as or less than that in the task composed with the conditions file.

In conclusion, your idea can be useful depending on the situation. I will update the package soon with an example.
0
mkytch

Junior Member
Registered:
Posts: 6
Reply with quote  #4 
Thanks so much Jaewon!!

I'm trying to use a big dataset as stimuli, so this should help improve the performance a lot! Btw, When you say generating runtime, what do you mean specifically? I guess it includes parsing the timing file and set the editable variables, but not sure about other stuff going on there.

I've seen the newly updated version, I'll try it as soon as possible and let you know how it goes. Thanks again!
0
Jaewon

Senior Member
Registered:
Posts: 312
Reply with quote  #5 
The biggest thing that happens during the runtime generation is to put together the timing file and the trialholder file (where the trial-specific functions, like toggleobject, eyejoytrack, etc., are defined) and minify them (removing all unnecessary blanks and remarks to reduce the size). Extracting the editable variables also occurs there, as you know.

When the conditions file is used, the runtime generation is finished before the task starts, so it doesn't affect the ITI. It used to be a big factor when the userloop file was used, but now you can pre-generate it in the userloop as well.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation: