On Thu, 30 Nov 2006 18:59:32 -0800, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Nov 30, 2006, at 9:40 PM, William Stein wrote:
>>> If it's 1MB per ring, then I only have to be
>>> working modulo 500 or so integers simultaneously --- not at all a
>>> far-
>>> fetched situation --- before my typical desktop PC runs out of RAM.
>>
>> We could only automatically cache up to 50 rings, say. If the user
>> *wants* caching, they can always explicitly ask for it, and if they
>> don't they can always explicitly ask not to have it.
>>
>> sage: Integers(97, cache=False)
>> sage: Integers(97, cache=True)
>>
>> if you are explicitly about casting then either option should
>> be respected. If you don't specify anything for cache, it could
>> use some rules, such as suggested above.
>
> OK, I could live with that.
Robert: "make it so".
>> On the other hand, if you create a large number of elements modulo one
>> integer with the caching you won't run out of memory, whereas without
>> it you might very well run out.
>
> I'm not so sure about this. If you cache, then every IntegerMod is a
> Python object containing a pointer that points to the cached object.
> If you don't cache, then every IntegerMod is a Python object
> containing a single machine word describing which element it is. Am I
> missing something here?
Yes.
> Have I been spending too long away from
> python/pyrex?
Maybe.
If you cache, then every IntegerMod is a single PyObject*, i.e., it's
a machine pointer. Note that when this pointer is returned Robert (I
hope!)
was careful to increment the reference count to the actual cached
IntegerMod. If you don't cache, then ever IntegerMod is a struct
that contains all kinds of stuff:
* reference counting info
* type info (??)
* pointer to the parent
* actual value.
I think on a 32-bit machine it's something like 24 bytes versus 4 bytes.
>>> We got some of the way towards solving this problem at SAGE
>>> Days 2. Much of the work has been done for the Integer class. I hope
>>> that someone can put some effort into generalising and improving
>>> those efforts. I don't have the time right now to work on this.
>>
>> I pushed that same work through to most other compiled classes.
>> E.g., Python's own ints with their caching etc., do the benchmark
>> mentioned above in 0.70 seconds, so now SAGE's object creation isn't
>> that far off from Python's own built-in optimized object creation.
>
> I didn't realise that work had already been done. Thanks for doing that!
>
> It's really incredible that MAGMA goes faster than python ints here.
> From memory, at sage days 2, our Integer stuff was still a factor of
> 7-10 away from python ints, at least for addition.
I don't know what benchmark you were doing exactly, but now that the dust
has
settled here's what you actually accomplished for addition, which is better
than a factor of 7-10: http://modular.math.washington.edu:8101/benches2
{{{
def b_python(a,b):
a=int(a)
b=int(b)
t=cputime()
for i in range(int(10^6)):
c = a+b
return cputime(t)
}}}
{{{
def b_sage(a,b):
a=Integer(a)
b=Integer(b)
t=cputime()
for i in range(int(10^6)):
c = a+b
return cputime(t)
}}}
{{{
def b(a,b):
t_python = b_python(a,b)
t_sage = b_sage(a,b)
print len(str(a)), len(str(b)), t_python, t_sage, t_sage/t_python
}}}
{{{
b(3,4)
///
1 1 0.25 0.86 3.44
}}}
{{{
b(939834,290283)
///
6 6 0.26 0.88 3.38461538462
}}}
{{{
b(9023809823409823,239048230948023848)
///
16 18 0.26 0.86 3.30769230769
}}}
{{{
b(2903402834098234892034802,293048203948029384092834082340892)
///
25 33 0.33 0.87 2.63636363636
}}}
{{{
b(29023042903840923840928340982390482038,29038490283409238498230482390482038420)
///
38 38 0.35 0.86 2.45714285714
}}}
{{{
b(19^1000,1793^3939)
///
1279 12816 6.86 2.17 0.316326530612
}}}
{{{
}}}
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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/
-~----------~----~----~----~------~----~------~--~---
