On 8/22/2011 9:35 AM Emile van Sebille said...
On 8/22/2011 2:55 AM Richard D. Moores said...
Coincidence?
Naaa.. I just ran it twice -- once per ... _this_ is coincidence. :)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Emile>pyt
On 8/22/2011 2:55 AM Richard D. Moores said...
I couldn't resist giving it a try. Using Python 3.2.1 on a 64-bit
Windows 7 machine with a 2.60 gigahertz AMD Athlon II X4 620
processor, I did 18 tests, alternating between n=n+1 and n+=1 (so 9
each).
The fastest for n+=1 was
C:\Windows\System32>
On Sun, Aug 21, 2011 at 18:12, Steven D'Aprano
wrote:
> But really, we're talking about tiny differences in speed. Such trivial
> differences are at, or beyond, the limit of what can realistically be
> measured on a noisy PC running multiple processes (pretty much all PCs
> these days). Here are
On 2011-08-21, Andreas L?scher wrote:
> Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
>> In article ,
>> Christian Heimes wrote:
>> > I don't think that's the reason. Modern compiles turn a switch statement
>> > into a jump or branch table rather than a linear search like chained
>>
On 8/21/11 9:37 PM, Stephen Hansen wrote:
> But, += is Python itself adding an unpredictable behavior into the core
> language, with its own base types behaving
... very differently to fundamental, basic appearing operators.
Editing fail on my part.
Similarly:
> But for Python, all by itself, w
On 8/21/11 9:14 PM, Steven D'Aprano wrote:
>> That said: my advice is always to avoid += like a plague. It is magic
>> and impossible to predict without intimate knowledge of exactly what's
>> on the left-side.
>>
>>i += 1
>>n += x
>>
>> Those two things look very similar, but they may do -
On Aug 21, 10:27 am, Andreas Löscher wrote:
>
> from Python/ceval.c:
>
> 1316 case BINARY_ADD:
> 1317 w = POP();
> 1318 v = TOP();
> 1319 if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
> 1320 /* INLINE: int + int */
> 13
On Mon, 22 Aug 2011 12:08 pm Stephen Hansen wrote:
> Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta
> kinda crazy. The difference in speed is probably related to churn and
> cache as much as anything else (its not as consistent on my machine, for
> example): or the ceval l
On 8/21/2011 7:49 PM, Laurent Payot wrote:
I made Python my language of choice because of its readability and
simpleness, and not because of its speed. But it's always good to
know what is the fastest sometimes when you don't want to write a
module in C. So I was just wondering if there was a dif
On 8/21/2011 7:41 PM, Chris Angelico wrote:
Agreed. If Python needed a faster alternative to "a=a+1", then I would
recommend an "a.inc()" call or something
But looking up the method name, creating a bound method wrapper, and
making the call would probably be slower than the syntax;-).
--
Te
On 8/21/11 12:53 PM, Laurent wrote:
>
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
>> floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot. I
> would never have thought an interpreter would have differences like this
Am 22.08.2011 01:25, schrieb Andreas Löscher:
> It's not as bad as you think. The addition of two integers is a cheap
> task (in terms of computation power). If you have two way's to to it,
> every little think (jumps in the code etc. ) will have a larger impact
> on the execution time than on an e
Chris Angelico wrote:
> 2011/8/22 Andreas Löscher :
>> But every improvement on your algorithm will easily result in a
>> significant shorter execution time than replaceing a+=1 with a=a+1 will
>> ever do. :-)
>>
>
> Agreed. If Python needed a faster alternative to "a=a+1", then I would
> recomme
Laurent wrote:
>
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
>> floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot.
> I would never have thought an interpreter would have differences like this
> in syntax for someth
On 8/21/2011 5:07 PM, Nobody wrote:
If the value on the left has an __iadd__ method, that will be called;
Correct
the value will be updated in-place,
Not necessarily correct. The target is rebound to the return from the
__iadd__ method. Augmented *assignment* is always assignment. This tr
Am Sonntag, den 21.08.2011, 19:38 -0400 schrieb Terry Reedy:
> On 8/21/2011 7:17 PM, Andreas Löscher wrote:
> > Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
> >> In article,
> >> Christian Heimes wrote:
> >>
> >>> Am 21.08.2011 19:27, schrieb Andreas Lscher:
> As for using Int
I made Python my language of choice because of its readability and simpleness,
and not because of its speed. But it's always good to know what is the fastest
sometimes when you don't want to write a module in C. So I was just wondering
if there was a difference. There is, of a few percent. Anywa
2011/8/22 Andreas Löscher :
> But every improvement on your algorithm will easily result in a
> significant shorter execution time than replaceing a+=1 with a=a+1 will
> ever do. :-)
>
Agreed. If Python needed a faster alternative to "a=a+1", then I would
recommend an "a.inc()" call or something;
On 8/21/2011 7:17 PM, Andreas Löscher wrote:
Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
In article,
Christian Heimes wrote:
Am 21.08.2011 19:27, schrieb Andreas Lscher:
As for using Integers, the first case (line 1319 and 1535) are true and
there is no difference in Code. H
2011/8/22 Andreas Löscher :
> How would such an jump table work to behave the same liek a
> switch-case-statement?
If your switch statement uses a simple integer enum with sequential
values, then it can be done quite easily. Take this as an example:
switch (argc)
{
cas
Am Sonntag, den 21.08.2011, 12:53 -0700 schrieb Laurent:
> > With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
> > floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot. I
> would never have thought an interpreter would have di
Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
> In article ,
> Christian Heimes wrote:
>
> > Am 21.08.2011 19:27, schrieb Andreas Lscher:
> > > As for using Integers, the first case (line 1319 and 1535) are true and
> > > there is no difference in Code. However, Python uses a huge s
On Sun, 21 Aug 2011 09:52:23 -0700, Laurent wrote:
> I did many tests and "i = i + 1" always seems to be around 2% faster
> than "i += 1". This is no surprise as the += notation seems to be a
> syntaxic sugar layer that has to be converted to i = i + 1 anyway. Am I
> wrong in my interpretation?
I did the test several times with floats on my machine and the difference is
not as big as for integers:
==> "i = i + 1.0" is 0.732% faster than "i += 1.0".
It seems normal as the float addition is supposed to be slower than integer
addition, thus the syntaxic difference is comparatively less
> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
> floats (0.0 and 1.0), 6%
For floats it is understandable. But for integers, seriously, 4% is a lot. I
would never have thought an interpreter would have differences like this in
syntax for something as fundamental as add
Actually 6% between float themselves is just as not-understandable.
--
http://mail.python.org/mailman/listinfo/python-list
On 8/21/2011 1:27 PM, Andreas Löscher wrote:
What the precise difference (semantics and speed) is between the
BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
code or maybe someone knows it from memory :-)
Irmen
from Python/ceval.c:
1316case BINARY_ADD:
1317
In article ,
Christian Heimes wrote:
> Am 21.08.2011 19:27, schrieb Andreas Löscher:
> > As for using Integers, the first case (line 1319 and 1535) are true and
> > there is no difference in Code. However, Python uses a huge switch-case
> > construct to execute it's opcodes and INPLACE_ADD cames
Am 21.08.2011 19:27, schrieb Andreas Löscher:
> As for using Integers, the first case (line 1319 and 1535) are true and
> there is no difference in Code. However, Python uses a huge switch-case
> construct to execute it's opcodes and INPLACE_ADD cames after
> BINARY_ADD, hence the difference in spe
Well 2% more time after 1 million iterations so you're right I won't consider
it.
--
http://mail.python.org/mailman/listinfo/python-list
On 21/08/11 19:14:19, Irmen de Jong wrote:
What the precise difference (semantics and speed) is between the
BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
code or maybe someone knows it from memory :-)
There is a clear difference in semantics: BINARY_ADD always produces
Thanks for these explanations. So 2% speed difference just between "B..." and
"I..." entries in a huge alphabetically-ordered switch case? Wow. Maybe there
is some material for speed enhancement here...
--
http://mail.python.org/mailman/listinfo/python-list
> What the precise difference (semantics and speed) is between the
> BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
> code or maybe someone knows it from memory :-)
>
> Irmen
>
from Python/ceval.c:
1316case BINARY_ADD:
1317w = POP();
1318
On 21-08-11 19:03, Laurent wrote:
Well I agree with you about string concatenation, but here I'm talking about
integers incrementation...
Seems the two forms are not 100% identical:
>>> import dis
>>> def f1(x):
... x=x+1
...
>>> def f2(x):
... x+=1
...
>>>
>>> dis.dis(f1)
2 0 L
Well I agree with you about string concatenation, but here I'm talking about
integers incrementation...
--
http://mail.python.org/mailman/listinfo/python-list
as the += notation seems to be a syntaxic sugar layer that has to be
converted to i = i + 1 anyway.
That has always been my understanding. The faster way is to append to
a list as concatenating usually, requires the original string,
accessing an intermediate block of memory, and the memory for th
Hi Folks,
I was arguing with a guy who was sure that incrementing a variable i with "i +=
1" is faster than "i = i + 1". I couldn't tell if he was right or wrong so I
did a little benchmark with the very useful timeit module.
Here are the results on my little Linux Eeepc Netbook (using Python 3.
37 matches
Mail list logo
