On Tue, Nov 4, 2008 at 10:33 AM, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> 2. On platforms that support it, this is at least 64x64->64 multiplication,
> potentially much more expensive than the 32x32->64 (or 31x31->62?)
> flavor you /intend/ to move to.
Thats a good point, thanks!
I am not av
Here's the test code I was using, modeled on the basic operation
that longobject needs: multiply two digits together and extract
high and low digits from the result.
typedef uint32_t digit;
typedef uint64_t twodigits;
#define SHIFT 30
#define MASK (((digit)1 << SHIFT) - 1)
/* multiply a and b,
On Mon, Nov 10, 2008 at 4:26 PM, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>
> Looking at the assembler it produces (x86)
>
> mul:
>pushl %ebp
>xorl%edx, %edx
>movl%esp, %ebp
>movl12(%ebp), %eax
>imull 8(%ebp), %eax
>popl%ebp
>
Tim Peters <[EMAIL PROTECTED]> wrote:
> > 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.
>
> 1. That's C99, not C89, and therefo
Tim Peters wrote:
because /knowing/ whether it works requires staring at
generated code, there's probably no sane way to automate detection of
when, if, and under what conditions it breaks.
Maybe it could be tested by compiling two small test programs,
one using (uint64_t)my_uint32 * my_other_u
[Tim Peters]
>> ..
>> Whenever two digits are multiplied, the code intends to
>> cast (at least) one of them to "twodigits" first (if you
>> ever see a spot where this doesn't happen, it's a bug).
[Mark Dickinson]
> There are indeed one or two spots that seem to be missing a
> cast, for example th
On Tue, Nov 4, 2008 at 6:33 PM, Tim Peters <[EMAIL PROTECTED]> wrote:
> Whenever
> two digits are multiplied, the code intends to cast (at least) one of
> them to "twodigits" first (if you ever see a spot where this doesn't
> happen, it's a bug). "twodigits" is typedef'ed to C long. C89
> guarant
[EMAIL PROTECTED] wrote:
> >> OTOH, it should be no big deal to drop a zip archive of the GMP
> >> sources which correspond to the code bound into the DLL.
>
> Martin> How would end users then extract the sources from the DLL? How
> Martin> would they learn that they even have them
About 31, 32, 63 or 64 bits: I guess that you want to avoid integer overflow.
Intel has an "overflow" flag, changed for all instructions. For other CPUs,
you can use emulate this flag. Example with the type int that I used in my
GMP patch:
Add:
int a, b, sum;
sum = a + b;
exact = ((a < 0)
On 2008-11-04 18:38, Victor Stinner wrote:
> Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit :
>> Rather than that, what about patching Python's long implementation
>> to use GMP if it's available, and the default implementation if not?
>
> Yes, I like this suggestion of two flav
Hey, Mark -- let's establish some background here first. It's a fact
that the product of two N-bit integers can require 2N bits, and also a
fact that lots of HW supports NxN->2N bit integer multiplication
directly.
However, it's unfortunately also a fact that standard C has no
corresponding conce
Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit :
> Rather than that, what about patching Python's long implementation
> to use GMP if it's available, and the default implementation if not?
Yes, I like this suggestion of two flavors. Python with GMP and Python without
GMP (built
>> OTOH, it should be no big deal to drop a zip archive of the GMP
>> sources which correspond to the code bound into the DLL.
Martin> How would end users then extract the sources from the DLL? How
Martin> would they learn that they even have them in the first place?
I think you
Thomas Wouters writes:
> Ah, but not true according to who? [...]
> It is certainly the case that such a combination is enough to scare
> off corporate lawyers who aren't sure either (most of them, I bet)
> and would advise against using that build of Python because of the
> LGPL components.
2008/11/4 Greg Ewing <[EMAIL PROTECTED]>:
> Martin v. Löwis wrote:
>>
>> you *will* have to ship gmp.dll to your users, as well ... So then
>
>> you have to include the source (of GMP
>
> Are you sure? I thought the source-provision requirements
> of the *GPL licences only apply when you distribute
Martin v. Löwis wrote:
you *will* have to ship gmp.dll to your users, as well ... So then
> you have to include the source (of GMP
Are you sure? I thought the source-provision requirements
of the *GPL licences only apply when you distribute a
*modified* version of something. Here you're just sh
[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 ju
On Tue, Nov 4, 2008 at 07:32, Stephen J. Turnbull <[EMAIL PROTECTED]>wrote:
> "Martin v. Löwis" writes:
> > Stephen J. Turnbull wrote:
> > > Thomas Wouters writes:
> > >
> > > > Neither of those (shipping sources or dynamically linking to
> > > > GMP) would solve the LGPL issue. People who
Martin v. Löwis wrote:
On Windows, the GMP binaries would be incorporated into pythonxy.dll.
This would force anybody providing a copy of pythonxy.dll to also
provide the sources of GMP.
I thought the suggestion was to provide a way of optionally
compiling Python to use GMP. The standard Pytho
"Martin v. Löwis" writes:
> Stephen J. Turnbull wrote:
> > Thomas Wouters writes:
> >
> > > Neither of those (shipping sources or dynamically linking to
> > > GMP) would solve the LGPL issue. People who distribute that
> > > build of Python would still be held by the LGPL -- such as
> >
Stephen J. Turnbull wrote:
> Thomas Wouters writes:
>
> > Neither of those (shipping sources or dynamically linking to GMP) would
> > solve the LGPL issue. People who distribute that build of Python would
> still
> > be held by the LGPL -- such as shipping any sources that they embed that
> >
> Martin> On Windows, the GMP binaries would be incorporated into
> Martin> pythonxy.dll. This would force anybody providing a copy of
> Martin> pythonxy.dll to also provide the sources of GMP.
>
> As I understand it the proposal was to allow people to substitute GMP for
> Python's lo
[Gregory P. Smith]
>> One optimization that could be done to the existing Python longobject
>> code is to allow it to use larger digits. Currently it is hardcoded
>> to use 15bit digits.
>>
>> The most common desktop+server CPUs in the world (x86) all support
>> efficient 32bit*32bit -> 64bit mult
Thomas Wouters writes:
> Neither of those (shipping sources or dynamically linking to GMP) would
> solve the LGPL issue. People who distribute that build of Python would still
> be held by the LGPL -- such as shipping any sources that they embed that
> Python into.
No, that's exactly what the
On Tue, Nov 4, 2008 at 01:37, <[EMAIL PROTECTED]> wrote:
>
>Benjamin> The main objection is that GMP is licensed under LGPL which I
>Benjamin> believe conflicts with Python's very open license.
>
>>> If GMP itself isn't included with Python how can there be a licensing
>>> issue?
>
Benjamin> The main objection is that GMP is licensed under LGPL which I
Benjamin> believe conflicts with Python's very open license.
>> If GMP itself isn't included with Python how can there be a licensing
>> issue?
Martin> On Windows, the GMP binaries would be incorporated i
> One optimization that could be done to the existing Python longobject
> code is to allow it to use larger digits. Currently it is hardcoded
> to use 15bit digits.
>
> The most common desktop+server CPUs in the world (x86) all support
> efficient 32bit*32bit -> 64bit multiply so there is no good
On Mon, Nov 3, 2008 at 12:41 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit :
>> I've read some of the past discussion about including GMP into the
>> python core and understand the reasons for not doing so.
>
> Please, check
[EMAIL PROTECTED] wrote:
> Benjamin> The main objection is that GMP is licensed under LGPL which I
> Benjamin> believe conflicts with Python's very open license.
>
> If GMP itself isn't included with Python how can there be a licensing issue?
On Windows, the GMP binaries would be incorpo
Benjamin> The main objection is that GMP is licensed under LGPL which I
Benjamin> believe conflicts with Python's very open license.
If GMP itself isn't included with Python how can there be a licensing issue?
Skip
___
Python-Dev mailing list
Hi,
Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit :
> I've read some of the past discussion about including GMP into the
> python core and understand the reasons for not doing so.
Please, check this issue: http://bugs.python.org/issue1814
I patched Python3 to use GMP because I
On Mon, Nov 3, 2008 at 11:56 AM, Paul Miller <[EMAIL PROTECTED]> wrote:
> I've read some of the past discussion about including GMP into the
> python core and understand the reasons for not doing so. Rather than
> that, what about patching Python's long implementation to use GMP if
> it's availabl
I've read some of the past discussion about including GMP into the
python core and understand the reasons for not doing so. Rather than
that, what about patching Python's long implementation to use GMP if
it's available, and the default implementation if not? Are there any
philosophical or techni
33 matches
Mail list logo
