Thanks for the suggestion. I have tried it with my version (which chunks the data in 5 MiB blocks to prevent running out of heap space), but the speed-up is not measurable. Compressing ~120 MiB takes 0.035 seconds for the custom typecast and 0.161 for the built-in function. In contrast, the java GZIP function takes 7 seconds (and uses only 1 thread).
However, sharing pointers is of course a much nicer solution.
This is hardly a replacement, as the original maxNumCompThreads is capable of actually setting the number of threads.
The planned removal of this capability has been bugging me for quite some time. I am thinking about reviving a custom function, using omp_set_num_threads:
http://www.mathworks.com/matlabcentral/newsreader/view_thread/170152 (see comment 12). This should work at least for the BLAS subsystem.
30 Sep 2010
SHAREDMATRIX Allows any Matlab object to be shared between Matlab sessions (w/o using file I/O).
Author: Joshua Dillon
No idea, but that should be more about (system) libraries than compiler, right? I am sorry, but I do not have a windows version of Matlab, nor do I have windows.
I had a question about how the flags 't' and 'c' are used by sparse matrix arguments. I assume that the flags are there to circumvent explicit transposes and its associated overhead. Yet, it doesn't appear that sparse mtimesx operations make use of them. In the test below, I see basically the same execution speeds in all 3 versions. Is it true that sparse operations can't make use of the flags, and is it deliberate/inevitable? It would be a great benefit to be able to avoid transposing tall sparse matrices because of the high memory consumption that comes with that.
From my understanding, the file "mex_C_win64.xml" replaces "mexopts.bat".
"Error using mtimesx_build (line 169)
A C/C++ compiler has not been selected with mex -setup". I replaced line 169 by : mexopts = [prefdir '\mex_C_win64.xml'];. It did work with a few warnings...