Aptech Systems, Inc. Worldwide Headquarters
Aptech Systems, Inc.
2350 East Germann Road, Suite #21
Chandler, AZ 85286
Ready to Get Started?
For Pricing and Distribution
Training & Events
Step-by-step, informative lessons for those who want to dive into GAUSS and achieve their goals, fast.
Have a Specific Question?
Q&A: Register and Login
Premier Support and Platinum Premier Support are annually renewable membership programs that provide you with important benefits including technical support, product maintenance, and substantial cost-saving features for your GAUSS System or the GAUSS Engine.
Join our community to see why our users are considered some of the most active and helpful in the industry!
Where to Buy
Available across the globe, you can have access to GAUSS no matter where you are.
Recent Tagsapplications character vectors CML CMLMT Constrained Optimization datasets dates dlibrary dllcall error error handling errors Excel FANPACMT file i/o floating network GAUSS Engine graphics GUI hotkeys installation Java API license licensing linux loading data matrices matrix matrix manipulation Maxlik MaxLikMT Memory Optmum output PQG graphics proc procs RAM random numbers string functions strings structures threading Time Series writing data
Time Series 2.0 MT
Find out more now
Time Series MT 2.1
Threading and memory usage build up
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?
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.