On Mon, Apr 26, 2010 at 1:08 AM, Sergey Bochkanov <[email protected]> wrote: > Hello, Case. > > You wrote 23 апреля 2010 г., 19:30:20: > >> (1) Python numeric values are assumed to be immutable. If not, they >> cannot be used as dictionary keys. This forces all results to be new >> objects, hence source/destination operands cannot overlap, etc. > > It is problem only when you want mpz/mpq to be value type. However, > they can be reference types too. > > I know that it may be considered non-Pythonic, but such approach is > much more efficient. And I think that output from high performance > library like GPM/MPIR will very rarely be used as dictionary key. > > What do you think about such data model - reference mpz/mpq types?
It should be possible to experiment with that behavior in gmpy 1.11 right now. If you pass -DMUTATE when compiling, many inplace operations (+=, *=, etc) do work inplace. I will be adding an xmpz type that supports inplace operations as much as possible. I've done a lot of work in 1.11 to minimize the performance penalty for creating new objects - when objects are deleted, they are held in a cache so they can be very quickly reused. This was a significant performance boost. > >> (2) ..... Anytime you accept a Python integer, you either need to >> just convert it to an mpz or test if it will fit in the _si/_ui >> range and call the appropriate function. (GMPY uses the later >> approach.) > > Very serious problem. And what should we do if we have Python-long > which doesn't fit into 32 bits? > > We can't transparently convert it into the mpz and call another > function because: a) it is hard to implement such semantics, > especially within automatic code generation framework, and b) > sometimes xxx_ui functions have slight differences from their mpz/mpq > counterparts. > > I think that the only thing possible is to raise an exception in such > cases. But it may be non-Pythonic too... I transparently convert to an mpz if the input is a PyLong that is larger than a C-long. But I'm trying to mimic Python's behavior. Trying to do this via a code generator would be very difficult. > >> (3) It wasn't any faster. :( > > What kind of tests you made? Have you tested it with relatively small > integers (up to 128 bits) or with really large ones? I will rerun the tests tonight. I grabbed a short sequence from mpmath but was only able to get about a 20% speedup. > > I think that low speed may be caused mostly by creation of new objects > after each operation (1) and (to a lesser extent) by conversion > penalty (2). However, when you work with really large numbers > (thousands of bits) MPIR should be significantly faster than Python > native implementation of long. I've found mpmath benchmark at > http://mpmath.googlecode.com/svn/bench/mpbench.html which confirms > this opinion. I meant "faster than gmpy using MPIR and taking advantage of caching of deleted objects". I'll rerun the tests tonight since I haven't done them for a while. > > > > -- > With best regards, > Sergey mailto:[email protected] > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > 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/mpir-devel?hl=en. > > casevh -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. 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/mpir-devel?hl=en.
