[Martin v. Löwis] > Perhaps Tim Peters should also comment here - but if you can come up > with a patch that does that in a portable way, I would be in favor. > The challenge, ISTM, is to make it still compile on all systems > (regardless of how inefficient it might be on minor platforms).
I've just uploaded a patch to the issue tracker that allows Python to use 30-bit digits on platforms having a 64-bit integer type: http://bugs.python.org/issue4258 [Tim Peters] > Note that while 32x32->64 multiply is supported by x86 HW, that > doesn't mean there's a uniform way to get at this HW capability across > C compilers. In contrast, (at least) efficient HW 15x15->30 multiply > is universally spelled in C via "i*j" :-) If we're talking about standards and portability, doesn't "i*j" fail on those (nonexistent?) platforms where the 'int' type is only 16-bits? Shouldn't this be something like "(long)i * j" instead? And for 32x32 -> 64, can't this simply be replaced by "(uint64_t)i * j", where uint64_t is as in C99? I'd hope that most compilers would manage to turn this into the appropriate 32x32-bit hardware multiply. I agree that very-long-integer optimizations probably don't really belong in Python, but this patch should also provide significant benefits for short and medium-sized integers. I guess I need to go away and do some benchmarking... Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
