help with memory usage

Christ Schlacta aarcane at gmail.com
Tue Mar 10 20:31:46 CET 2009


On Tue, Mar 10, 2009 at 12:21 PM, Marc Glisse
<marc.glisse at normalesup.org> wrote:
> On Mon, 9 Mar 2009, Christ Schlacta wrote:
>
>> I've got the following simple struct:
>> class prime_t { //prime list element type.
>>  public:
>>    prime_t();
>>    mpz_class *value;
>>    prime_t *next;
>> };
>
> I believe you should store the mpz_class directly, not a pointer to it (a
> mpz_class is not much more than a pointer itself). It will save some amount
> of overhead and simplify the code (no need for new/delete).

I tried storing an mpz_class inside the prime_t class, and I
experienced string corruption throughout the program.  when I switched
to using a pointer and a new in the constructor, the problem went
away.

>
>> The problem:  I can get several hundred megabytes worth of prime
>> numbers..  250MB at my last count.  But in memory, 250MB of prime
>> numbers (stored as newline-delimited strings) ends up being more than
>> 1600MB in memory using this structure.
>
> That is a lot...
>
> Are many of your prime numbers small enough that they could be stored as
> unsigned long?
I think almost all of them could be unsigned long longs at this point,
but having to decide at load time to use mpz_class or unsigned long
long would be alot of overhead, and even more in the main loop.
>
> You could also stop relying on the default memory allocator and either tell
> gmp to use some other allocation function or allocate the buffers yourself
> (for read-only never-deallocate numbers like your prime numbers seem to be
> this should not be hard).
>
I have no clue how I would even do that :(
>
> --
> Marc Glisse
>



-- 
 (\_/)  This is Bunny. Copy and paste Bunny
(='.'=) into your signature to help him gain
(")_(") world domination.


More information about the gmp-discuss mailing list