FAQ
Executive summary: Has the SET_LINENO removal been tested with the HAP
debugger, and wouldn't a breakpoint instruction give much larger benefits?


As a partial author of the HAP Python Debugger (available on source
forge) I read about the imminent removal of SET_LINENO with some worry.
It *sounds* like it has been done in such way to not cause debugger
problems, but I'm curious if anyone has tested HAP with 2.3.

Also, it sounds like the reason for removing SET_LINENO was to improve
the performance of Python scripts. However one of the posts on this
topic (can't find it now) suggested that the hoped for improvements had
not actually materialized.

It seems to me (from the sidelines/peanut gallery/wherever) that the
biggest performance problems in the SET_LINENO area are when debugging,
not when running free, and that therefore this optimization is targeting
the lesser problem.

The need to check for breakpoints at each line has always made Python
debugging performance poor at best. Technically the performance under
the debugger doesn't matter, and yet sometimes it does. Having just
helped complete a Python based sports game for PC, where real-time
performance was critical, I can say that the slowdown in HAP was
definitely annoying.

So, wouldn't a break-point opcode be a more substantial improvement than
removing SET_LINENO? Just bringing up that old topic again to see if it
gets any more traction :-)

Bruce Dawson
Humongous Entertainment

P.S. For reference I include the canonical? link to the SET_LINENO
discussion.

http://mail.python.org/pipermail/python-dev/2000-July/007652.html

P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
love to be able to stop on the assert when running under a debugger, to
see what is wrong before the stack frame unwinds.

Search Discussions

  • Martin v. Löwis at Sep 26, 2002 at 6:36 am

    Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:

    Executive summary: Has the SET_LINENO removal been tested with the HAP
    debugger, and wouldn't a breakpoint instruction give much larger
    benefits?
    To my knowledge: no, and no.
    It *sounds* like it has been done in such way to not cause debugger
    problems, but I'm curious if anyone has tested HAP with 2.3.
    It was definitely designed to not cause problems for debuggers. If you
    want to find out, you probably can easily test it yourself.
    Also, it sounds like the reason for removing SET_LINENO was to improve
    the performance of Python scripts. Correct.
    However one of the posts on this topic (can't find it now) suggested
    that the hoped for improvements had not actually materialized.
    I think this suggestion is incorrect; the improvements can be
    demonstrated.
    It seems to me (from the sidelines/peanut gallery/wherever) that the
    biggest performance problems in the SET_LINENO area are when
    debugging, not when running free, and that therefore this optimization
    is targeting the lesser problem.
    No. Performing the SET_LINENO instruction if there is no debugging
    going on contributed significantly to execution speed, which is the
    reason for not emitting them under -O.
    So, wouldn't a break-point opcode be a more substantial improvement
    than removing SET_LINENO? Just bringing up that old topic again to see
    if it gets any more traction :-)
    No. Removal of SET_LINENO does improve performance in a "free-running"
    application, which adding a breakpoint instruction would not.

    That said: it might be still worthwhile to add a breakpoint
    instruction. There are a number of issues to be considered, such as
    getting the breakpoint instruction into the byte code, and getting the
    original instruction back in. So if you'ld like to see one, you
    probably have to write a PEP.
    P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
    love to be able to stop on the assert when running under a debugger,
    to see what is wrong before the stack frame unwinds.
    I can't see how this helps. Wouldn't you have to set a breakpoint on
    all asserts for that? And wouldn't that require finding all asserts in
    the first place?

    Regards,
    Martin
  • Bruce Dawson at Sep 26, 2002 at 3:34 pm
    Thanks for all the replies - including the link to the unhandled
    exception handling option.

    Martin v. L?wis wrote:
    Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:

    Executive summary: Has the SET_LINENO removal been tested with the HAP
    debugger, and wouldn't a breakpoint instruction give much larger
    benefits?
    ...

    So, wouldn't a break-point opcode be a more substantial improvement
    than removing SET_LINENO? Just bringing up that old topic again to see
    if it gets any more traction :-)
    No. Removal of SET_LINENO does improve performance in a "free-running"
    application, which adding a breakpoint instruction would not.
    A breakpoint instruction would be intended to improve performance in
    debuggers. My point was that the improvement there would be larger
    (probably 100% or more) than the improvement from SET_LINENO. But the
    improvement would not, as you say, affect "free-running" applications at
    all.

    That said: it might be still worthwhile to add a breakpoint
    instruction. There are a number of issues to be considered, such as
    getting the breakpoint instruction into the byte code, and getting the
    original instruction back in. So if you'ld like to see one, you
    probably have to write a PEP.

    Some day I will do that. I have to dig deeper in the Python source
    before I can do that.

    P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
    love to be able to stop on the assert when running under a debugger,
    to see what is wrong before the stack frame unwinds.
    I can't see how this helps. Wouldn't you have to set a breakpoint on
    all asserts for that? And wouldn't that require finding all asserts in
    the first place?
    If assert was implemented with a hard-coded breakpoint then it would
    work very nicely. Under a debugger this would stop you on the relevant
    line. Not under the debugger it would throw an exception as before.

    On x86 processors int 3 is the hard-coded breakpoint instruction. If you
    hit one it stops your program. If you're running under a debugger you
    can then step right over it. I was imagining something like that.

    Asserts are great, but they are easier to interpret if when you trigger
    one you are dropped onto the assert statement. Just a mad idea...
  • Tim Peters at Sep 26, 2002 at 3:51 pm
    [Bruce Dawson]
    However one of the posts on this topic (can't find it now) suggested
    that the hoped for improvements had not actually materialized.
    [Martin v. Lowis]
    I think this suggestion is incorrect; the improvements can be
    demonstrated.
    It was platform-dependent, and was a real loss on Windows. I'm not worried
    about that, though, because it's just "ceval disease": the performance of
    the eval loop goes up or down approximately at random. MSVC6 has, for
    years, done better than gcc on it, and seemingly by accident. I figured
    that MSVC had been knocked out of a local minimum by accident here, and
    that, over time, other people making other random changes to ceval would
    eventually nudge it pack in to the same-- or an even better --local minimum.

    As of today, on a rather noisy box,

    C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.81114
    This machine benchmarks at 13119.4 pystones/second

    C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.78183
    This machine benchmarks at 13221.1 pystones/second

    C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.79681
    This machine benchmarks at 13169 pystones/second


    C:\Code\python\PCbuild>python ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.41775
    This machine benchmarks at 14629.5 pystones/second

    C:\Code\python\PCbuild>python ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.41381
    This machine benchmarks at 14646.4 pystones/second

    C:\Code\python\PCbuild>python ../lib/test/pystone.py
    Pystone(1.1) time for 50000 passes = 3.40596
    This machine benchmarks at 14680.1 pystones/second

    C:\Code\python\PCbuild>

    Now lots of things have changed, but performance is so much better under 2.3
    now on Windows without -O than it used to be with -O in 2.2 that "pinning
    the blame" isn't an interesting game anymore.

    Still, for peak speed over time, it would obviously have been better to
    remove SET_LINENO via a method that *didn't* add new instructions to the
    eval loop's critical path. That was much harder to do, though. I'm quite
    happy with the compromise Michael crafted.
  • Thomas Heller at Sep 26, 2002 at 6:59 am

    Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:


    P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
    love to be able to stop on the assert when running under a debugger,
    to see what is wrong before the stack frame unwinds.
    Have you seen this?
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65287

    Thomas
  • Richie Hindle at Sep 26, 2002 at 2:28 pm
    Bruce,
    As a partial author of the HAP Python Debugger (available on source
    forge) I read about the imminent removal of SET_LINENO with some worry.
    I've been working on a Python debugger of my own, and having briefly
    tested it with 2.3a0, I'm nothing but delighted with the results. It
    fixes a number of minor niggles - stopping twice on block-start lines,
    stopping on 'def' lines and stopping on docstrings, to pick some
    random examples.
    wouldn't a break-point opcode be a more substantial improvement
    This would be very nice too!

    --
    Richie Hindle
    richie at entrian.com
  • Michael Hudson at Sep 27, 2002 at 10:18 am
    I'm the one responsible for SET_LINENO going away in 2.3, so here's
    my take...

    Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:
    Executive summary: Has the SET_LINENO removal been tested with the HAP
    debugger,
    No. I'd never heard of it for one thing!
    and wouldn't a breakpoint instruction give much larger
    benefits?
    I fail to see how.
    As a partial author of the HAP Python Debugger (available on source
    forge) I read about the imminent removal of SET_LINENO with some
    worry. It *sounds* like it has been done in such way to not cause
    debugger problems, but I'm curious if anyone has tested HAP with 2.3.
    I tried really hard to make it transparent to debuggers. There are a
    few very small differences, but unless you're actually scanning for
    SET_LINENO instructions they shouldn't bite. I'd invite you to test,
    of course.
    Also, it sounds like the reason for removing SET_LINENO was to improve
    the performance of Python scripts. However one of the posts on this
    topic (can't find it now) suggested that the hoped for improvements
    had not actually materialized.
    It speeds programs run without -O. On Windows, programs run with -O
    got somewhat slower after this patch (on Linux it made essentially no
    difference, maybe a very slight speedup). See Tim's post.
    It seems to me (from the sidelines/peanut gallery/wherever) that the
    biggest performance problems in the SET_LINENO area are when
    debugging, not when running free, and that therefore this optimization
    is targeting the lesser problem.
    You've got my motivation entirely backwards there.
    The need to check for breakpoints at each line has always made Python
    debugging performance poor at best. Technically the performance under
    the debugger doesn't matter, and yet sometimes it does. Having just
    helped complete a Python based sports game for PC, where real-time
    performance was critical, I can say that the slowdown in HAP was
    definitely annoying.
    You're faced with a hard problem. Good luck :)
    So, wouldn't a break-point opcode be a more substantial improvement
    than removing SET_LINENO? Just bringing up that old topic again to see
    if it gets any more traction :-)
    How would a breakpoint opcode differ from what SET_LINENO was?
    P.S. For reference I include the canonical? link to the SET_LINENO
    discussion.

    http://mail.python.org/pipermail/python-dev/2000-July/007652.html
    Note that what I did bears little resemblance to the scheme sketched
    in that post. I hack stuff out of co_lnotab.
    P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
    love to be able to stop on the assert when running under a debugger,
    to see what is wrong before the stack frame unwinds.
    Well, you break on the exception, don't you?

    Cheers,
    M.

    --
    The "of course, while I have no problem with this at all, it's
    surely too much for a lesser being" flavor of argument always
    rings hollow to me. -- Tim Peters, 29 Apr 1998
  • Martin v. Löwis at Sep 27, 2002 at 10:37 am

    Michael Hudson <mwh at python.net> writes:

    So, wouldn't a break-point opcode be a more substantial improvement
    than removing SET_LINENO? Just bringing up that old topic again to see
    if it gets any more traction :-)
    How would a breakpoint opcode differ from what SET_LINENO was?
    This is easy to answer: a breakpoint instruction could be inserted in
    the code at the points where the user wishes to have a
    breakpoint. Thus, with a breakpoint instruction, you could disable all
    tracing, and wait for the breakpoint callback.

    With such a scheme, you can have zero-overhead debugging, for
    breakpoints. If your debugger supports watchpoints, you get overhead,
    again.

    Regards,
    Martin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedSep 26, '02 at 6:09a
activeSep 27, '02 at 10:37a
posts8
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase