This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients ArneBab, mark.dickinson, r.david.murray, skrah
Date 2011-09-29.17:14:18
SpamBayes Score 0.00012325923
Marked as misclassified No
Message-id <1317316459.16.0.909290734396.issue13060@psf.upfronthosting.co.za>
In-reply-to
Content
> If the C accelerator for decimal gets decimal performance close to
> floats (which I doubt, because it has to do much more), it could be
> very useful for me. What is its estimated time to completion?


It is finished and awaiting review (See #7652). The version in

   http://hg.python.org/features/cdecimal#py3k-cdecimal

is the same as the version that will be released as cdecimal-2.3
in a couple of weeks.

Benchmarks for cdecimal-2.2 are over here:

http://www.bytereef.org/mpdecimal/benchmarks.html#pi-64-bit


Typically cdecimal is 2-3 times slower than floats. With
further aggressive optimizations one *might* get that down
to 1.5-2 times for a fixed width Decimal64 type, but this is
pure speculation at this point.

If you look at http://www.bytereef.org/mpdecimal/benchmarks.html#mandelbrot-64-bit ,
you'll see that the Intel library performs very well for that specific
type. Exact calculations are performed in binary, then converted to
decimal for rounding. Note that this strategy _only_ works for
relatively low precisions.
History
Date User Action Args
2011-09-29 17:14:19skrahsetrecipients: + skrah, mark.dickinson, r.david.murray, ArneBab
2011-09-29 17:14:19skrahsetmessageid: <1317316459.16.0.909290734396.issue13060@psf.upfronthosting.co.za>
2011-09-29 17:14:18skrahlinkissue13060 messages
2011-09-29 17:14:18skrahcreate