forum.alglib.net

So, it is NET restriction which prevents you from utilizing all accessible memory.

Yeah, i've figured that myself, the problem is in function sparsecreate as far as i understand.

Btw alglib uses everywhere multidimensional arrays A[i, j], not jaged arrays A[i][j]. Under Windows jagged array performance is
greater than multidimensional, and crashes as vell (multidim .Net array also have < 2GB limit), so it seems like a huge problem for 64 bit .Net applications which rely on big matrices/vectors?

P.S. Just found http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx

It was very hard design choice between jagged and non-jagged arrays. The problem with jagged arrays is that all subarrays can have different sizes, thus: a) check for input array size becomes too slow, b) without checks it is very easy to accidentally corrupt memory when processing invalid input data, c) it becomes harder to exchange data between ALLGIB versions in different languages.

And I think that it is too late to change ALGLIB approach to arrays :( We already have a lot of (commercial) projects which depend on ALGLIB, so any changes which break backward compatibility are not welcomed.

I've managed to run my test under .Net 4.5 with 400 000 points and Program consumed about 8GB RAM :-).

This solution should work for double precision arrays less than 32GB, which is quite big for present computers :) BTW, thanks for your suggestion - I think that I should add it to ALGLIB Reference Manual.