[GiNaC-list] little optimization => lots of Memory usage

[Cristobal Navarro]

i kept investigating,

based on the test i've made, im almost sure, 99%, that the increase in
memory usage is due to the segmentation of the expressions.
based on this.... i can deduce that somehow having the ecuation system is
much economic than having the matrix form, up to an order of magnitude mor
economic,

can the developers confirm this??

On Wed, Oct 20, 2010 at 2:47 PM, Cristobal Navarro <axischire at gmail.com>wrote:

> yes, it adds some memoery usage, but doing the math i found that it isnt
> too much,
>
> for the 8000x8000 problem, each string should be in the worst case length
> 21 (for example string s = "Ld0x1d2x3d4x5d6x7d8x9" ), assuming std::string
> is 1 byte per length unit:
> stringMemory <= 21 bytes * 64M <=  1344Mbytes <= 1.3GB
>
> i was considering the equivalent situation but for the expressions, which
> now are 64M smaller ones compared to 8000 bigger ones from before
> could it be that they use so much memory?
>
>
> On Wed, Oct 20, 2010 at 1:27 PM, James Jackson <james.jackson at cern.ch>wrote:
>
>> If I understand correctly, previously you were storing N strings, now you
>> are storing N^2. This is 64M strings, as opposed to 8000. This might account
>> for at least some of the memory!
>>
>> Regards,
>> James
>>
>> On 20 Oct 2010, at 16:45, Cristobal Navarro <axischire at gmail.com> wrote:
>>
>> > Hello everybody,
>> >
>> > i've been using ginac for some months and is very optimum,
>> > but recently i've been facing a problem with the amount of memory used
>> to store some expressions.
>> > i have a linear system of ecuations, with the size of around 8000
>> elements.
>> >
>> > my first approach on building the matrix was use a map<string, ex*>
>> where each element would correspond to a row element of the matrix.
>> > and all incognints of that row would be inside the expression ex. for a
>> 4x4 system ecuaiton, the storage would be like this
>> >
>> > <"certainKey1", ex1* > = B1*symbol2 + A1*symbol1 + D1*symbol4
>> > <"certainKey2", ex2*> = D2*symbol4 + B2*symbol2 + C2*symbol3
>> > <"certainKey3", ex3* > = B3*symbol2 + A3*symbol1 + D3*symbol4 +
>> C3*symbol3
>> > <"certainKey4", ex4*> = A4*symbol1 + B4*symbol2 + C4*symbol3
>> >
>> > this method was using an acceptable ammount of memory, around 15% of
>> 32GB which was pretty good.
>> > the bad side of this approach was that when building the Ginac::matrix,
>> i had to sort the elements and search each of them on their corresponding
>> row, additionaly some where hidden because they had coefficient "0", so i
>> had a list of symbols and on each row i searched for them, in a sorted way
>> using the "coeff" method that Ginac provides.
>> > But i repeat, this was slow.
>> >
>> > The point is that i decided to search for other solution, aiming on
>> reducing the time needed to build the Ginac::Matrix.
>> > i came with the idea to use map< string, <string, ex> > mapMatrix, which
>> is actually the matrix but sorted automatically because of the strings which
>> are the incognits keyCode.
>> > now building the matrix is almost instant, no search needed, and all
>> elements already sorted.
>> >
>> > however, the program is using all the RAM = 32GB when doing the
>> 8000x8000 problem.
>> >
>> > i checked and rechecked for any memory leak, but havent found any so
>> far,
>> >
>> > now the question = why did memory increase so much for just segmenting
>> the expressions into separated smaller ones??
>> > is they same ammount of terms, just in separated sub-expressions., the
>> ex object is too expensive??
>> >
>> >
>> >
>> > _______________________________________________
>> > GiNaC-list mailing list
>> > GiNaC-list at ginac.de
>> > https://www.cebix.net/mailman/listinfo/ginac-list
>> _______________________________________________
>> GiNaC-list mailing list
>> GiNaC-list at ginac.de
>> https://www.cebix.net/mailman/listinfo/ginac-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20101021/68135a3f/attachment.html>