I am using GAUSS 14 and Maxlik with threading to program simulated maximum likelihood. The threading helps greatly speed up the estimation, but the application gradually sucks up memory space. For example, for my current program with a large number of simulations, the memory (private working set) builds up from around 150k in the initial iterations towards several gigs in the end. Moreover, the memory space is not released after the program finishes. Any suggestions?
1 Answer
0
Maximum likelihood, using either Maxlik or MaxlikMT, can use quite a lot of memory. This is particularly the case in a threaded context in which your memory requirements will go up by a factor of the number of threads you are using. Typically the hessian calculation is the most memory intensive. It is not uncommon to use several gigabytes of data to calculate the hessian. If the maximum size is more than your computer can handle, then you can either decrease the number of GAUSS threads that you are using, or you can turn off the internal threads that GAUSS creates for medium to large matrix operations. Setting the OMP_NUM_THREADS environment variable equal to 1 will stop GAUSS from multi-threading large matrix operations internally. It will not, however, stop threadBegin or threadStat threading.
After the program run, the GAUSS memory footprint will most likely not be as small as it was before the run. While much of the memory will be released, there will be extra memory usage for: any new global variables that were created, buffers that are used internally to GAUSS for optimization purposes (these will not continue to grow on further program runs, however) and many small user-interface allocations (such as new entries in the data page for global variables, loaded graphs, text in the program/input output window, etc. etc).
In most cases, the new global variables should be the majority of the increase in GAUSS size. The internal buffers and gui items should not be very large, but may be a few megabytes worth.
If you need to clear out some memory, you can release all of your global variables with the GAUSS new command and you can clear out the program input/output window with the cls command.
In addition to the expected memory increases it is possible that you could cause memory leaks by writing to global variables from more than 1 GAUSS thread. The threading chapter in the manual refers to this as the "writer must isolate" rule. Here is a simple example illustrating what you must not do:
threadBegin;
x = 5;
threadEnd;
threadBegin;
x = 9;
threadEnd;
threadJoin;
Not only will the value of x be unpredictable, your operating system does not allow writing to the same memory location from two separate threads. Here is a still simple, but more subtle example of the same type of threading error:
_last_input = 0;
threadBegin;
x_1 = myProc(1);
threadEnd;
threadBegin;
x_2 = myProc(2);
threadEnd;
threadJoin;
proc (1) = myProc(a);
_last_input = a;
retp(a * a);
endp;
In this case, above, there is no writing to global variables between the actual thread statements. However, the program is still writing to the same memory location from separate threads.
Your Answer
1 Answer
Maximum likelihood, using either Maxlik or MaxlikMT, can use quite a lot of memory. This is particularly the case in a threaded context in which your memory requirements will go up by a factor of the number of threads you are using. Typically the hessian calculation is the most memory intensive. It is not uncommon to use several gigabytes of data to calculate the hessian. If the maximum size is more than your computer can handle, then you can either decrease the number of GAUSS threads that you are using, or you can turn off the internal threads that GAUSS creates for medium to large matrix operations. Setting the OMP_NUM_THREADS environment variable equal to 1 will stop GAUSS from multi-threading large matrix operations internally. It will not, however, stop threadBegin or threadStat threading.
After the program run, the GAUSS memory footprint will most likely not be as small as it was before the run. While much of the memory will be released, there will be extra memory usage for: any new global variables that were created, buffers that are used internally to GAUSS for optimization purposes (these will not continue to grow on further program runs, however) and many small user-interface allocations (such as new entries in the data page for global variables, loaded graphs, text in the program/input output window, etc. etc).
In most cases, the new global variables should be the majority of the increase in GAUSS size. The internal buffers and gui items should not be very large, but may be a few megabytes worth.
If you need to clear out some memory, you can release all of your global variables with the GAUSS new command and you can clear out the program input/output window with the cls command.
In addition to the expected memory increases it is possible that you could cause memory leaks by writing to global variables from more than 1 GAUSS thread. The threading chapter in the manual refers to this as the "writer must isolate" rule. Here is a simple example illustrating what you must not do:
threadBegin;
x = 5;
threadEnd;
threadBegin;
x = 9;
threadEnd;
threadJoin;
Not only will the value of x be unpredictable, your operating system does not allow writing to the same memory location from two separate threads. Here is a still simple, but more subtle example of the same type of threading error:
_last_input = 0;
threadBegin;
x_1 = myProc(1);
threadEnd;
threadBegin;
x_2 = myProc(2);
threadEnd;
threadJoin;
proc (1) = myProc(a);
_last_input = a;
retp(a * a);
endp;
In this case, above, there is no writing to global variables between the actual thread statements. However, the program is still writing to the same memory location from separate threads.