[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by Mark Dickinson : -- status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson added the comment: Closing this. I like the PyLong_IS_NEGATIVE and PyLong_IS_ZERO macros, but I can't find anywhere outside longobject.c where they'd actually be useful (with the possible exception of marshal.c, but that currently depends on knowing lots about the long impleme

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson added the comment: [Mark] > PyLong_NDIGITS should stay in longintrepr.h, though, > since it's dependent on the representation. [Victor] >I don't understand why. [...] I expressed myself badly. I guess my point was that PyLong_SIGN and PyLong_EQUALS_ZERO (and PyLong_IS_NEGATIVE)

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11979/pylong_asscaleddouble.patch ___ Python tracker ___ ___ Python-bugs-l

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor added the comment: I created a decicated issue for my last unrelated patch: #5576: Don't use PyLong_SHIFT with _PyLong_AsScaledDouble() -- ___ Python tracker ___ _

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor added the comment: I removed my "optimization" patches: there were useless (no or low speedup). I also removed bench_int.py: I moved it to my own public SVN: http://haypo.hachoir.org/trac/browser/misc/bench_int.py -- ___ Python track

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11980/pylong_shift.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11981/bench_int.py ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11977/pylong_optimize.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file13369/pylong_macros-2.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11975/pylong_macros.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor added the comment: > I think PyLong_SIGN and PyLong_EQUALS_ZERO should go in > Include/longobject.h, not Include/longintrepr.h Yeah, it's better for 3rd party modules. > PyLong_NDIGITS should stay in longintrepr.h, though, > since it's dependent on the representation. I don't u

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by Mark Dickinson : -- assignee: -> marketdickinson components: +Interpreter Core priority: -> normal type: -> feature request ___ Python tracker ___ __

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson added the comment: A few comments: I think PyLong_SIGN and PyLong_EQUALS_ZERO should go in Include/longobject.h, not Include/longintrepr.h: these 2 macros have an unambiguous meaning for *any* representation of integers. And longintrepr.h is really supposed to be private, fo

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor added the comment: Updated version of my macros patch for PyLong type: - patch for Python trunk - define 3 macros: PyLong_SIGN(x), PyLong_EQUALS_ZERO(x), PyLong_NDIGITS(x) - just replace code by the equivalent macros The goal is the make the code easier to read. It would also

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor added the comment: We have now a benchmark tool (attached file "bench_int.py"), many patches to try, and 3.0 is released. Anyone interrested to work on it? ___ Python tracker

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I agree with Christian that we should wait until 3.0 is out. Using A DVCS should make this much easier if anyone needs an excuse to learn bzr. I think we should aim to commit the 30bit change (a pretty clear win by the looks of things) aft

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: More numbers! -- 64 bits CPU --- original: 885.0 ms fast long: 746.8 ms (+16%) -- issue #3944 -- +16% only with an optimized multiplicaton, great job Pernici :-) -- 32 bits CPU --- original: 1564.3

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: I'm unable to use pystone nor pybench to compare all integers patches. So I wrote my own tool: bench_int.py. Don't use to compare different computers or Python versions, it's just useful to test if a patch is faster or slower. Example (sti

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Christian Heimes <[EMAIL PROTECTED]> added the comment: It's probably easier to wait a couple of days until 3.0.0 is out. I don't know how the new branches will look like. By the way your work fits nicely in my plans to work on optimizations for 3.1. Go, Victor, go! ___

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson <[EMAIL PROTECTED]> added the comment: There are so many things going on here it's getting difficult to keep track of them all! Not only Victor's stuff, but also Mario's patches for faster multiplication, and for subquadratic division. And it might be interesting to experiment

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: More benchmark with py3k trunk on a Quad [EMAIL PROTECTED] GHz (64 bits): ./python Lib/test/pystone.py 25 (maximum value on 5 runs): - original: 58685.4 pystones/second - patched: 61274.5 pystones/second Don't trust pystones, results a

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: Other optimization for long_compare(), long_lshift() and long_rshift(). Note: with all my patches, Python is a little bit faster (but not slower, which is already a good thing ;-)). Added file: http://bugs.python.org/file11980/pylong_shift

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Christian Heimes <[EMAIL PROTECTED]> added the comment: I like the idea, Victor -- nosy: +christian.heimes ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: @marketdickinson: As you proposed, here is a patch for _PyLong_AsScaledDouble(): stores directly the number of bits in an unsigned int instead of the number of digits. Added file: http://bugs.python.org/file11979/pylong_asscaleddouble.patch

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Same: it's better to write a separated patch. Agreed. Unfortunately, I think all of this is going to have to wait for Python 3.0 to be released before we can consider committing anything. The first step is to commit the pure bugfixes (m

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: > What's the purpose of your sdigit? The type sdigit should be able to store a signed digit, so a number in [-(2^15-1); 2^15-1]. short may be enough, but I think that the CPU prefers (CPU is faster with) an int because it doesn't have to t

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: Second patch to optimize some PyLong operations: - Write special code for small (a, b) of long_true_div(), long_bitwise(), and l_divmod() (used by long_div(), long_mod() and long_divmod(), and long_pow()) - PyLong_FromLong(): don't go to t

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Another thought: macros that are going to be used elsewhere in Python (like the way you're using PyLong_SIGN in mathmodule.c) would probably be better off in longobject.h. The fewer places there are that have to include longintrepr.h, the

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Interesting. Incidentally, I'm already using sdigit for the signed version of digit--- this seems to fit with the current digit/twodigits/stwodigits typedefs. What's the purpose of your sdigit? Do you really want it to be type 'int'? __

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Changes by STINNER Victor <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith, marketdickinson ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

New submission from STINNER Victor <[EMAIL PROTECTED]>: It's hard to read Objects/longobject.c because the code depends to much on the implementation. I wrote macros to simplify the code: - PyLong_SIGN(x) - PyLong_EQUALS_ZERO(x) - PyLong_FITS_INT(x) - PyLong_GET_INT(x) - PyLong_NDIGITS(x)