> > Drawbacks:
> >  * creation of finite extension fields takes 0.3s instead of 0.14s
> > (without)
>
> Not bad.

Maybe we can do better: Just one big malloc call + c array instead of 
list.append.

> >  * up to 2^16 * (5 * sizeof(int)) bytes are required for the storage
> >    ( ~ 1.25 MB) depending on the size of the field
>
> That's not too bad...
>
> >  * Speed-up would not be as dramatic as seen here if all the little
> > tricks for
> >    object creation would have been used in the Givaro wrapper.
>
> Those tricks are also very impressive.

Yes, I should use them in GFq.

> >  * Python loops slow us down significantly.
>
> How so?  I.e., is that because of your new caching?  Or is that
> just a general remark.   This is another motivation to work hard
> to make Pyrex easier and easier to use.

There is much overhead involved in using Python loops because GFq is so fast 
now. Nothing special, just that GFq is very fast compared to a Python loop. 

> > Possible Improvements:
> >  * use a C array instead of a tuple (bit smaller & faster)
>
> Makes sense. Note that you can use PySequence_Fast_ITEMS
> and PySequence_Fast to get direct access to the underlying
> C array of objects in a tuple.

I can just use a C array then because I have to do ref counting manually 
anyway and the size never changes.

> > My question: Are we willing to spent 1.25 MB of RAM per finite
> > (extension)
> > field for a < 3x speed-gain?
>
> Could it be optional, or is it too difficult to make both options
> available?

Okay, I'll make it optional.

> How much memory does a Givaro Python class take?  Robert Bradshaw
> and I just did an analysis of the memory used for an element of
> Z/nZ (for n small), and a single element takes 24 bytes in
> SAGE now:
>
> 4 an int (the underlying value)
> 4 pointer to the parent
> 4 pointer to the modulus
> 4 pointer to the function call table
> 8 PyObject_HEAD  (pointer to type object and reference count)

6 * wordsize = 24 byte on 32-bit architectures:

sizeof(pointer) : pointer to the parent
sizeof(pointer) +sizeof(int) : pointer to type object and reference count
sizeof(pointer) : function call table
sizeof(int) : value # this is the redundant value with the Givaro C++ table
sizeof(pointer): __multiplicative_order #may be removed

> With your cache of the full finite field, it takes only 4 bytes
> (on a 64-bit machine) to store any element. 

Are you referring to the underlying Givaro int representation here? Yes, only 
this would be used in matrices and maybe polynomials.

Martin


-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_icq: 177334829
_jab: [EMAIL PROTECTED]

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to