[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Backported to trunk in r70479. Mario, thanks for the long multiplication tweaks you submitted: could you possibly regenerate your Feb 19th patch against the trunk (or py3k, whichever you prefer) and attach it to issue 3944? -- resolution: -> accept

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Great! > Committed 30bit_longdigit20.patch to py3k in r70460, with some minor > variations (incorporate Nick Coghlan's improved error messages > for marshal, fix some comment typos, add whatsnew and Misc/NEWS entries). --

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: That should be r70459, of course. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Committed 30bit_longdigit20.patch to py3k in r70460, with some minor variations (incorporate Nick Coghlan's improved error messages for marshal, fix some comment typos, add whatsnew and Misc/NEWS entries). Thanks all for your feedback. I might get around to

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: I tried the patch on a 64-bit Linux system and it's ok. -- ___ Python tracker ___ ___ Python-bugs-li

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor added the comment: 1 comment and 1 question about 30bit_longdigit20.patch: - I love fixed size type: you use them when PYLONG_BITS_IN_DIGIT == 30 (eg. digit=PY_UINT32_T) but not when PYLONG_BITS_IN_DIGIT == 15 (eg. digit=unsigned short). Even if short is always 16 bits, I would

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Okay, let's abandon 30-bit digits on 32-bit machines: it's still unclear whether there's any real performance gain, and it's trivial to re-enable 30-bit digits by default later. I'm also going to abandon the optimizations for now; it'll be much easier to w

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: It finally occurred to me that what might be killing 32-bit performance is the divisions, rather than the multiplications. To test this, here's a version of 30bit_longdigit17.patch that replaces just *two* of the divisions in Objects/longsobject.c by the appr

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Adding Tim Peters to the nosy list, mainly to give him an opportunity to throw up his hands in horror at my rewrite of his (I'm guessing) implementation of division. -- nosy: +tim_one ___ Python tracker

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Updated benchmarks results with 30bit_longdigit17.patch: * Victor's bench_int.py: - 32-bit with patch:1178.3 ms (24% speedup) - 64-bit with patch:990.8 ms (27% speedup) * Calculating 2000 digits of pi: - 32-bit with patch:2.16 s. (25% speedup) - 6

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Here's an updated patch that includes the x_divrem fixes and optimizations. I've also updated the Rietveld issue with these fixes. I think this is (modulo any requested changes) the version that I'd like to get into py3k. After that we can look at the possibi

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: http://codereview.appspot.com/14105/diff/1/2 File Python/marshal.c (right): http://codereview.appspot.com/14105/diff/1/2#newcode160 Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p); On 2009/02/18 21:27:04, Martin v. Löwis wrote: > Ok, so I'd waive this for

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: > Before such a version gets committed, I'd like to see it on Rietveld > again. Sure. My original plan was to get the structural changes in first, and then worry about optimizations. But now I think the x_divrem fix has to be considered a prerequisite for t

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Pernici Mario added the comment: The attached patch uses mul1 in long_mul in the version patched with 30bit_longdigit13+optimizations.patch Comparison between these two patches on hp pavilion Q8200 2.33GHz pybench patch new patch SimpleIntegerArithmetic 89 85 other tes

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Martin v. Löwis added the comment: > Obviously use the optimized version (but fix the configure stuff). Before such a version gets committed, I'd like to see it on Rietveld again. ___ Python tracker ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: Here are the results from 32-bit x86 on core2 duo gcc 4.0.1 using pydigits_bestof.py 4000: 30-bit digits (14): 15719 ms 30-bit digits + optimizations (13+ops): 12490 ms unpatched py3k: 13289 ms (again, i had to

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: attaching an updated pidigits benchmark script that does a warmup run before reporting the best result of 5. Added file: http://bugs.python.org/file13132/pidigits_bestof.py ___ Python tracker

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: new results after fixing my longdigit13 build to use 30 bits instead of 15 (the configure script in longdigit13+optimizations didn't work right, i had to manually add the #define to pyconfig.h) py3k: baseline longdigit14longdigit13+optimizations 3709

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: > Maybe configure didn't get updated properly? I'm almost sure I found a > case where autoconf and autoheader just reused the stuff in the > autom4te.cache directory even though configure.in had been changed. > I've been doing: rm -fr autom4te.cache; autocon

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Martin v. Löwis added the comment: > Maybe configure didn't get updated properly? I'm almost sure I found a > case where autoconf and autoheader just reused the stuff in the > autom4te.cache directory even though configure.in had been changed. > I've been doing: rm -fr autom4te.cache; autoco

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Martin v. Löwis added the comment: On all other follow-ups I agree, so no further comments there. http://codereview.appspot.com/14105/diff/1/2 File Python/marshal.c (right): http://codereview.appspot.com/14105/diff/1/2#newcode160 Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p); > Presuma

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: > apparently that used 15bit > digits despite --enable-big-digits on configure Maybe configure didn't get updated properly? I'm almost sure I found a case where autoconf and autoheader just reused the stuff in the autom4te.cache directory even though config

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: hmm yes, ignore my 13+optimize result. apparently that used 15bit digits despite --enable-big-digits on configure. attempting to fix that now and rerun. ___ Python tracker ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: And here are results from 64-bit builds on the same machine as above (OS X 10.5.6/Core 2 Duo, gcc 4.0.1 from Apple). ./python.exe ../pidigits_noprint.py 2000 gives the following timings: 30-bit digits: Time; 1245.9 ms 30-bit digits + optimizat

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Gregory, are you sure you didn't swap the 30-bit and 30-bit+opt results? On OS X/Core 2 Duo my timings are the other way around: 30bit is significantly slower than unpatched, 30bit+opt is a little faster than unpatched. Here are sample numbers: Macintosh-

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: On 32-bit x86 (1.4Ghz Efficeon) using gcc 4.3.2-1ubuntu12 I see the following perf with pidigits_noprint 2000: py3k: baseline longdigit14longdigit13+optimizations 3709 ms3664ms 4545ms Those were from the best of five runs after a warmup lo

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Le mercredi 18 février 2009 à 17:06 +, Mark Dickinson a écrit : > Looks like an autoconf 2.63/autoconf 2.61 difference. > Whoever previously ran autoconf and autoheader used 2.63; Sorry, that was me. autoconf seems unable to maintain reasonably similar outp

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Reviewers: Martin v. Löwis, http://codereview.appspot.com/14105/diff/1/11 File Doc/library/sys.rst (right): http://codereview.appspot.com/14105/diff/1/11#newcode418 Line 418: A struct sequence that holds information about Python's Agreed. All that's important

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith added the comment: > I would suggest to use 2^30 base only if sizeof(long)>=8 (64 bits CPU). Thats not the correct test. Test for an actual 64-bit build target. sizeof(long) and sizeof(long long) are not usefully related to that in any sort of cross platform manner. On windo

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Thanks very much for the timings, Victor. Just out of interest, could you try the pydigits script with the +optimizations patch on 32-bit? As mentioned above, there's a significant (for 30-bit digits) problem with x_divrem: the inner loop does a 32 x 64-bit

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor added the comment: New attachment: pidigits_noprint.py, hacked version of pidigits.py to remove the print and add the computation time in millisecond. Print was useless because we don't want to benchmark int->str conversion, especially when the integer is in [0; 9]. Added file

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor added the comment: Ok, let's try 30bit_longdigit14.patch: patch -p0 < 30bit_longdigit14.patch autoconf && autoheader ./configure && make I'm using two computers: - marge: Pentium4, 32 bits, 3 GHz (32 bits) - lisa: Core Quad (Q9300), 64 bits, 2.5 GHz (64 bits) Both u

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor added the comment: > Patch uploaded to Rietveld (assuming that I did it right): > http://codereview.appspot.com/14105 Hehe, your configure's patch is too huge for Rietveld which displays a "MemoryError" :-) Bug reported at: http://code.google.com/p/rietveld/issues/detail?id=87

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: It looks as though Visual Studio 2008 does the 'right' thing, too, at least in some circumstances. Here's some assembler output (MSVC Express Edition, 32-bit Windows XP / Macbook Pro). ; 3: unsigned long long mul(unsigned long x, unsigned long y) {

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Patch uploaded to Rietveld (assuming that I did it right): http://codereview.appspot.com/14105 ___ Python tracker ___ __

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: > unsigned long long m(unsigned long long a, unsigned long b) > { >return a*b; > } I think that's doing a 32 x 64 -> 64 multiplication; what's being used is more like this: unsigned long long m(unsigned long a, unsigned long b) { return (unsigned

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Martin v. Löwis added the comment: Has any conclusion been reached wrt. overhead of 30-bit multiplication on 32-bit systems? IIUC, the single-digit multiplication is equivalent to the C program unsigned long long m(unsigned long long a, unsigned long b) { return a*b; } (i.e. one digit

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Robert Schuppenies : -- nosy: +schuppenies ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Jeffrey Yasskin : -- nosy: +collinwinter, jyasskin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file13121/30bit_longdigit14.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson : Added file: http://bugs.python.org/file13122/30bit_longdigit14.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file13120/30bit_longdigit14.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Oops. Here's the correct patch. Added file: http://bugs.python.org/file13121/30bit_longdigit14.patch ___ Python tracker ___ ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: The last patch (30bit_longdigit14.patch) is obviously missing some stuff, but other than that I think everything's fine and you could commit. ___ Python tracker

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Updated non-optimized patch. The only real change is that I've moved some of the configuration stuff around (so not worth re-benchmarking this one); I hope that I've now got the division of labour correct: - configure script simply parses the --enable-big-d

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Thanks, Antoine. I've reworked the configure stuff anyway: the decision about what size digits to use should take place in pyport.h rather than Include/longintrepr.h. Updated patches will arrive shortly! ___ Python tracke

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Here's the py3k version of pidigits.py. Added file: http://bugs.python.org/file13119/pidigits.py ___ Python tracker ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Antoine Pitrou : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Some more benchmarks results (with 30bit_longdigit13.patch): * Victor's bench_int.py: - 32-bit without patch: 1370.1 ms - 32-bit with patch:1197.8 ms (23% speedup) - 64-bit without patch: 1357.6 ms - 64-bit with patch:981.6 ms (28% speedup) * calculat

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: As I said, I actually see a speedup as well on a 32-bit build on a 64-bit CPU. So the current patch (30bit_longdigit13.patch) is fine. ___ Python tracker ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file11986/30bit_longdigit6.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Here's a version of the patch that includes optimizations to basecase multiplication, and a streamlined x_divrem for faster division. With Victor's benchmark, I'm getting 43% speed increase on 64-bit Linux/Core 2 Duo. Note: the base patch is stable and ready f

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Actually, I still get a speedup on a 32-bit build. :) ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Actually, I think my previous results were in 64-bit mode already. By the way, I don't think unconditionally using uint64_t is a good thing on 32-bit CPUs. uint64_t might be an emulated type, and operations will then be very slow. It would be better to switch b

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Now with the latest patch, and under a 64-bit system (the same one actually, but with a 64-bit distro): * pybench is roughly 2% slower * timeit -s "a=1;b=77" "a//b" - before: 0.563 usec per loop - after: 0.226 usec per loop * timeit -s "a=1

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Mark, I think it was 32-bit at the time. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Antoine, were your posted results on a 64-bit or a 32-bit system? ___ Python tracker ___ ___ Python-bugs-list

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Forgot to mention: you'll need to rerun autoconf and autoheader after applying the patch and before doing ./configure ___ Python tracker ___ __

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file11976/30bit_longdigit4.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: Updated patch against py3k. I'm interested in getting this into the trunk as well, but py3k is more important (because *all* integers are long integers). It's also a little more complicated to do this for py3k (mostly because of all the small integer cachin

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson added the comment: The most recent patch is out of date and no longer applies cleanly. I'm working on an update. ___ Python tracker ___ __

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Gregory P. Smith : -- dependencies: +longobject.c: minor fixes, cleanups and optimizations ___ Python tracker ___ ___ Python

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor added the comment: I wrote a small benchmark tool dedicated to integer operations (+ - * / etc.): bench_int.py attached to issue4294. See also Message75715 and Message75719 for my benchmark results. Short sum up: 2^30 base helps a lot on 64 bits CPU (+26%) whereas the speedup i

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Antoine Pitrou added the comment: Just tested the patch, here are some benchmarks: ./python -m timeit -s "a=1;b=77" "a//b" -> 2.6: 0.253 usec per loop -> 3.1: 0.61 usec per loop -> 3.1 + patch: 0.331 usec per loop ./python -m timeit -s "a=1;b=77" "a*b" -> 2.6: 0.431

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a version of the 15-bit to 30-bit patch that adds in a souped-up version of Mario Pernici's faster multiplication. I did some testing of 100x100 digit and 1000x1000 digit multiplies. On 32-bit x86: 100 x 100 digits : around 2.5 tim

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: I like the idea of sys.int_info, but I would prefer a "base" attribute than "bits_per_digit". A base different than 2^n might be used (eg. a base like 10^n for fast conversion from/to string). ___ Python

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: Using 30bit_longdigit4.patch, I get this error: "Objects/longobject.c:700: erreur: "SIZE_T_MAX" undeclared (first use in this function)". You might use the type Py_ssize_t with PY_SSIZE_T_MAX. I used INT_MAX to compile the code. __

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11947/30bit_longdigit3.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a minor update to the patch, that does some extra cleanup: - don't include longintrepr.h in Objects/abstract.c or Objects/boolobject.c --- it's not needed. - fix several places in longobject.c where int should have been size_t or Py

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: And now the stat of Python patched with 30bit_longdigit3.patch. min/avg/max are now the number of bits which gives better informations. "bigger" is the number of arguments which are bigger than 1 digit (not in range [-2^30; 2^30]). make ==

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: I wrote a patch to compute stat about PyLong function calls. make (use setup.py): PyLong_FromLong: 168572 calls, min=( 0, ), avg=(1.4,), max=( 3,) long_bool:48682 calls, min=( 0, ), avg=(0.2,), max=( 2,) long_add:

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: > I'll investigate the slowdowns The problem may comes from int64_t on 32 bits CPU. 32x32 -> 64 may be emulated on your CPU and so it's slower. I improved your patch to make it faster, but I lost all my work because of a misuse of GIT... As

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Mark Dickinson <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11950/pybench_results.txt ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a pybench comparison, on OS X 10.5/Core 2 Duo/gcc 4.0.1 (32-bit non-debug build of the py3k branch). I got this by doing: [create clean build of py3k branch] dickinsm$ ./python.exe Tools/pybench/pybench.py -f bench_unpatched [apply 3

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Other responses... > It was an argument for changing the base used by the mashal :-) Ah. I think I'm with you now. You're saying that ideally, marshal shouldn't have to care about how Python stores its longs: it should just ask some func

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Yes, it uses base 2**15 but it's not the correct conversion to base > 2**15. You convert each PyLong digit to base 2**15 but not the whole > number. I don't understand: yes, each base 2**30 digit is converted to a pair of base 2**15 dig

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: PyLong_FromLong() doesn't go into the 1 digit special case for negative number. You should use: /* Fast path for single-digits ints */ if (!(abs_ival>>PyLong_SHIFT)) { v = _PyLong_New(1); if (v)

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: > marshal now uses base 2**15 for reading and writing Yes, it uses base 2**15 but it's not the correct conversion to base 2**15. You convert each PyLong digit to base 2**15 but not the whole number. As a result, the format is different than

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: Mark: would it be possible to keep the "2 digits" hack in PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 15". The base 2^15 slow, so don't make it slower :-) - /* 2 digits */ - if (!(ival >> 2*PyLong_SHIFT)

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11936/30bit_longdigit2.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Following Victor's suggestion, here's an updated patch; same as before, except that marshal now uses base 2**15 for reading and writing, independently of whether PyLong_SHIFT is 15 or 30. Added file: http://bugs.python.org/file11947/30bit_l

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: > > And why 30 bits and not 31 bits, or 63 bits, or 120 bits? > > Mostly laziness (...) It was an argument for changing the base used by the mashal :-) > 31 bits would involve rewriting the powering algorithm, which assumes that > PyLong_SHI

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: [Victor Stinner] > I saw that you choosed to use the base 2^30 for marshal. For a better > portability (be able to use .pyc generated without your patch), you > may keep the base 2^15. I implemented that in my GMP patch (manual > conversion

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: > As for marhsalled data and pyc compatibility, yes that is important to > consider. The problem is also that with the 30-bit digit patch, some Python will use 15 bits whereas some other will use 30 bits. The base in marshal should be the s

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Christian Heimes <[EMAIL PROTECTED]>: -- nosy: +christian.heimes priority: normal -> ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: oh yay, thanks. it looks like you did approximately what i had started working on testing a while back but have gone much further and added autoconf magic to try and determine when which size should be used. good. (i haven't reviewed your

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11935/30bit_longdigit.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

STINNER Victor <[EMAIL PROTECTED]> added the comment: > Note that to avoid "bad marshal data" errors, > you'll probably need to do a 'make distclean' > before rebuilding with this patch. I saw that you choosed to use the base 2^30 for marshal. For a better portability (be able to use .pyc gen

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's an updated patch, with the following changes from the original: - make the size of a digit (both the conceptual size in bits and actual size in bytes) available to Python via a new structseq sys.int_info. This information is useful fo

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Note that to avoid "bad marshal data" errors, you'll probably need to do a 'make distclean' before rebuilding with this patch. ___ Python tracker <[EMAIL PROTECTED]>

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

New submission from Mark Dickinson <[EMAIL PROTECTED]>: Here's an experimental patch, against the py3k branch, that makes Python represent its long integers internally in base 2**30 instead of base 2**15, on platforms that have 32-bit and 64-bit integers available. On platforms for which autoc