[Python-Dev] Re: SET_LINENO killer

[Michael Hudson]

"Tim Peters" <tim@zope.com> writes:

> [Michael Hudson]
> > Beats me.  I still see a healthy speed up:
> >
> > Before:
> >
> > $ ./python ../Lib/test/pystone.py
> > Pystone(1.1) time for 50000 passes = 3.99
> > This machine benchmarks at 12531.3 pystones/second
> >
> > After:
> >
> > $ ./python ../Lib/test/pystone.py
> > Pystone(1.1) time for 50000 passes = 3.65
> > This machine benchmarks at 13698.6 pystones/second
> >
> > (which is nosing on for 10% faster, actually).
> >
> > You're not testing a debug vs a release build or anything like that
> > are you?
> 
> I'm not, but I was comparing -O times (in release builds).

Ah.  FWIW gcc makes my patch a small win even with -O.

> Three runs before patch:
[...]
> This machine benchmarks at 14295.7 pystones/second
[...]
> Three runs after patch:
[...]
> This machine benchmarks at 13351.6 pystones/second

Ouch!

> Three runs after commenting out the new
[...]
> on the eval-loop critical path:
[...]
> This machine benchmarks at 13910.4 pystones/second

This makes no sense; after you've commented out the trace stuff, the
only difference left is that the switch is smaller!

Actually, there are some other changes, like always updating
f->f_lasti, and allocating 8 more bytes on the stack.  Does commenting
out the definition of instr_lb & instr_ub make any difference?

> OTOH, MSVC 6 has been generating faster ceval.c code than gcc for a long
> time; given how touchy this is, maybe it's just time for gcc to win 587 coin
> flips in a row <wink>.

Does reading assembly give any clues?  Not that I'd really expect
anyone to read all of the main loop...

I'm baffled.  Perhaps you can put SET_LINENO back in for the Windows
build <1e-6 wink>.

Cheers,
M.

-- 
  Programming languages should be designed not by piling feature on
  top of feature, but by removing the weaknesses and restrictions
  that make the additional features appear necessary.
               -- Revised(5) Report on the Algorithmic Language Scheme