On 25 Nov, 13:11, Antoine Pitrou wrote:
>
> When you say "executing each kind of bytecode instruction", are you
> talking about the overhead of bytecode dispatch and operand gathering, or
> the total cost including doing the useful work?
Strip away any overhead (dispatch, operand gathering) and j
Le Tue, 24 Nov 2009 16:09:10 -0800, Paul Boddie a écrit :
>
> I'm referring to what you're talking about at the end. The enhancements
> in Python 3 presumably came about after discussion of "threaded
> interpreters", confirming that the evaluation loop in Python 2 was not
> exactly optimal.
An op
Le Tue, 24 Nov 2009 22:08:19 +, Benjamin Peterson a écrit :
>
>> Would it be worth in-lining the remaining part of PyObject_IsTrue in
>> ceval?
>
> Inlining by hand is prone to error and maintainability problems.
Which is why we like to do it :-))
--
http://mail.python.org/mailman/listinf
On 24 Nov, 19:25, Antoine Pitrou wrote:
>
> Sorry, I have trouble parsing your sentence. Do you mean bytecode
> interpretation overhead is minimal compared to the cost of actual useful
> work, or the contrary?
> (IMO both are wrong by the way)
I'm referring to what you're talking about at the end
Chris Rebert wrote:
On Tue, Nov 24, 2009 at 4:31 AM, Rob Williscroft wrote:
mk wrote in news:mailman.915.1259064240.2873.python-l...@python.org in
comp.lang.python:
def pythonic():
def unpythonic():
Decidedly counterintuitive: are there special optimizations for "if
nonevar:" type of state
Tim Wintle teamrubber.com> writes:
> Out of interest - has anyone else spotted that the call to
> PyObject_IsTrue in the XXX_JUMP_IF_ blocks performs two unnecessary
> pointer comparisons?
I doubt two pointer comparisons will make much of a difference.
> Would it be worth in-lining the remai
On Tue, 2009-11-24 at 18:25 +, Antoine Pitrou wrote:
> Le Tue, 24 Nov 2009 08:58:40 -0800, Paul Boddie a écrit :
> > As you
> > point out, a lot of this RISC vs. CISC analysis (and inferences
> drawn
> > from Python bytecode analysis) is somewhat academic: the cost of the
> > JUMP_IF_FALSE inst
Le Tue, 24 Nov 2009 08:58:40 -0800, Paul Boddie a écrit :
> As you
> point out, a lot of this RISC vs. CISC analysis (and inferences drawn
> from Python bytecode analysis) is somewhat academic: the cost of the
> JUMP_IF_FALSE instruction is likely to be minimal in the context of all
> the activity
On 24 Nov, 16:11, Antoine Pitrou wrote:
>
[JUMP_IF_FALSE]
> It tries to evaluate the op of the stack (here nonevar) in a boolean
> context (which theoretically involves calling __nonzero__ on the type)
> and then jumps if the result is False (rather than True).
[...]
> As someone pointed out,
Le Tue, 24 Nov 2009 15:11:29 +, Antoine Pitrou a écrit :
> Hello,
>
> Le Tue, 24 Nov 2009 14:41:19 +0100, mk a écrit :
>>
>> As Rob pointed out (thanks):
>>
>> 11 31 LOAD_FAST0 (nonevar)
>> 34 JUMP_IF_FALSE4 (to 41)
>>
>> I'm no good at py
On 2009-11-24, Antoine Pitrou wrote:
> It tries to evaluate the op of the stack (here nonevar) in a
> boolean context (which theoretically involves calling
> __nonzero__ on the type)
...or __bool__ in Py3K.
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Hello,
Le Tue, 24 Nov 2009 14:41:19 +0100, mk a écrit :
>
> As Rob pointed out (thanks):
>
> 11 31 LOAD_FAST0 (nonevar)
> 34 JUMP_IF_FALSE4 (to 41)
>
> I'm no good at py compiler or implementation internals and so I have no
> idea what bytecod
mk wrote in news:mailman.923.1259070092.2873.python-l...@python.org in
comp.lang.python:
> MRAB wrote:
>> In what way is it counterintuitive? In 'pythonic' the conditions are
>> simpler, less work is being done, therefore it's faster.
>
> But the pythonic condition is more general: nonevar or ze
MRAB wrote:
In what way is it counterintuitive? In 'pythonic' the conditions are
simpler, less work is being done, therefore it's faster.
But the pythonic condition is more general: nonevar or zerovar can be
'', 0, or None. So I thought it was more work for interpreter to compare
those, while
On Tue, Nov 24, 2009 at 4:31 AM, Rob Williscroft wrote:
> mk wrote in news:mailman.915.1259064240.2873.python-l...@python.org in
> comp.lang.python:
>
>>
>> def pythonic():
>
>> def unpythonic():
>
>
>> Decidedly counterintuitive: are there special optimizations for "if
>> nonevar:" type of statem
mk wrote in news:mailman.915.1259064240.2873.python-l...@python.org in
comp.lang.python:
>
> def pythonic():
> def unpythonic():
> Decidedly counterintuitive: are there special optimizations for "if
> nonevar:" type of statements in cpython implementation?
>
from dis import dis
dis( un
mk wrote:
#!/usr/local/bin/python
import timeit
def pythonic():
nonevar = None
zerovar = 0
for x in range(100):
if nonevar:
pass
if zerovar:
pass
def unpythonic():
nonevar = None
zerovar = 0
for x in range(100):
i
#!/usr/local/bin/python
import timeit
def pythonic():
nonevar = None
zerovar = 0
for x in range(100):
if nonevar:
pass
if zerovar:
pass
def unpythonic():
nonevar = None
zerovar = 0
for x in range(100):
if nonevar i
18 matches
Mail list logo
