Tim Peters <tim.one@comcast.net> writes:
> I've been telling people at Zope Corp that getting rid of SET_LINENO would
> speed pystone (which is said to be a good predictor of Zope performance) by
> at least 7%. If you can fudge up a test showing that, your performance work
> will be complete.
It's about 5%:
$ ../../build/python pystone.py
Pystone(1.1) time for 100000 passes = 8.11
This machine benchmarks at 12330.5 pystones/second
$ ../../build/python pystone.py
Pystone(1.1) time for 100000 passes = 7.69
This machine benchmarks at 13003.9 pystones/second
I can run the vanilla pystone whilst compiling or something if you
like :)
As I said, my patched Python is much more variable in pystone than
before. I'm going to try invoking the Cache Effect Demon on this one,
unless someone can come up with a real explanation.
> [Guido]
> > ...
> > What's the next step? I haven't had time to review your code. Do you
> > want to check it in without further review, or do you want to wait
> > until someone can give it a serious look? (Tim's on vacation this
> > week so it might be a while.)
>
> I'm really not the best person for this, since, e.g., I never use the
> debugger, so couldn't personally care less if it stopped working <0.9 wink>.
>
> The patch set looks very complete, so I'd encourage a checkin if nobody
> objects.
>
> I have one objection, but it's kind of vague: Michael, you're taking too
> much delight in how obscure this is!
It's the old boys club effect: I worked damn hard to get to the point
of understanding this stuff, so everyone else should bloody well have
to too!
> Two examples:
>
> + int instr_ub = -1, instr_lb = 0; /* for tracing */
>
> It takes a lot of effort to reverse-engineer that the line number has
> changed if and only if
>
> not instr_lb <= current_bytecode_offset < instr_ub
>
> -- or at least to reverse-engineer that this is what you believe <wink>.
> Paste the above in as a comment and save the next person the pain. I got
> hung up the first 5 minutes guessing that "lb" and "ub" referred to "lower
> byte" and "upper byte".
Ah, OK. Actually, taking the tracing code out of line makes me feel
less uneasy about adding hundred+ line comments explaining what's going
on.
> The other example:
>
> + /* I (mwh) will gladly buy anyone a beer who
> + can tell me off the top of their head why
> + the exception for POP_TOP is needed... */
>
> That's not going to be amusing two years from now when your unstated
> reasoning is no longer true, and this code breaks. Then someone will have
> to guess what you thought you meant by this comment, whether your reasoning
> was correct at the time, and what may have changed to invalidate it. Rather
> than tease, just explain why POP_TOP must be an exception. If you don't
> know why, I'll buy *you* a beer <wink>.
All I can say is that I'd been driven insane by co_lnotab and
Python/compile.c when I wrote that comment <wink>.
Cheers,
M.
--
I'm okay with intellegent buildings, I'm okay with non-sentient
buildings. I have serious reservations about stupid buildings.
-- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4