On Thu, 16 Nov 2006 10:12:13 -0800, Martin Albrecht
<[EMAIL PROTECTED]> wrote:
>
>> NO!! I'm referring to the full 24 byte Python object! Most users are
>> going to just create Python objects that wrap Givaro elements. Without
>> caching, every single one takes 24 bytes. With caching, every
> NO!! I'm referring to the full 24 byte Python object! Most users are
> going to just create Python objects that wrap Givaro elements. Without
> caching, every single one takes 24 bytes. With caching, every one takes
> only 4 bytes (+initial table), since all one is doing is storing a pointer
On Thu, 16 Nov 2006 01:16:17 -0800, Martin Albrecht
<[EMAIL PROTECTED]> wrote:
>
> 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
> siz
On Nov 16, 2006, at 7:45 AM, Martin Albrecht wrote:
>
>> Ah. Are you saying what you've done is a bit like the situation where
>> Python caches int object?
>
> Yes, but I can cache all elements and they have to maintain a FIFO or
> something similar. We might want some generic FIFO / dict hybrid
> Ah. Are you saying what you've done is a bit like the situation where
> Python caches int object?
Yes, but I can cache all elements and they have to maintain a FIFO or
something similar. We might want some generic FIFO / dict hybrid for this
kind of stuff (?).
What I've done is I changed mak
On Nov 16, 2006, at 1:53 AM, Martin Albrecht wrote:
>> But I can see why it would be faster, given all the crap that sits
>> between us and those 16 bits.
>>
>> I don't necessarily have a problem with what you're doing, but in the
>> long run, we're better off just bloody well implementing the f
> > 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) depen
On Wednesday 15 November 2006 23:50, David Harvey wrote:
> On Nov 15, 2006, at 5:00 PM, Martin Albrecht wrote:
> > Hi there,
> >
> > I've implemented a very naive cache for finite extension field
> > elements in the
> > Givaro wrapper. Basically, all elements are created when the field
> > is crea
On Wed, 15 Nov 2006 14:50:36 -0800, David Harvey
<[EMAIL PROTECTED]> wrote:
>
>
> On Nov 15, 2006, at 5:00 PM, Martin Albrecht wrote:
>
>>
>> Hi there,
>>
>> I've implemented a very naive cache for finite extension field
>> elements in the
>> Givaro wrapper. Basically, all elements are created
On Wed, 15 Nov 2006 14:00:11 -0800, Martin Albrecht
<[EMAIL PROTECTED]> wrote:\
> I've implemented a very naive cache for finite extension field elements
> in the
> Givaro wrapper. Basically, all elements are created when the field is
> created
> and references are returned by the arithmetic
On Nov 15, 2006, at 5:00 PM, Martin Albrecht wrote:
>
> Hi there,
>
> I've implemented a very naive cache for finite extension field
> elements in the
> Givaro wrapper. Basically, all elements are created when the field
> is created
> and references are returned by the arithmetic methods: Th
11 matches
Mail list logo
