[Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2)
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 06 Oct 2002 13:45:51 -0700
Patches item #617311, was opened at 2002-10-01 19:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470
Category: Core (C code)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Tiny profiling info (Psyco #2)
Initial Comment:
Psyco-friendly patch #2.
A very very small statistic-collecting patch.
pystate.h: added a field at the end of the
PyThreadStruct:
int tick_counter;
ceval.c: eval_frame():
tstate->tick_counter is incremented whenever the
check_interval ticker reaches zero.
The purpose is to give a useful measure of the number
of interpreted
bytecode instructions in a given thread. This
extremely lightweight
statistic collector can be of interest to profilers
(like psyco.jit()).
We can safely guess that a single integer increment
every 100
interpreted bytecode instructions will go entierely
unnoticed
in any performance measure. [This is true for
pystone.py.]
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-06 16:45
Message:
Logged In: YES
user_id=6380
I'd like to get this into 2.2.2. MWH, can you check it in?
----------------------------------------------------------------------
Comment By: Armin Rigo (arigo)
Date: 2002-10-04 10:36
Message:
Logged In: YES
user_id=4771
It is the only way I could work out so far that can
"predict" how much a function will be accelerated when run
under Psyco. This is a very precious indication for an
automatic Psyco-binder. The following table shows the
results with the various test functions of the
distribution's "test.py" file:
(fn name) (speed-up) (bytecode insns per second)
f1 106.00
2310545
f4 11.33
2819100
f5 12.08
2992445
f6 1.35
412022
f7 2.24
1331353
f7bis 10.29
1632296
The third column is '(tick_counter * check_interval) /
execution_time'. The correlation between the two columns is
admittedly not perfect, but still we can see that it was not
worthy to try and accelerate f6 because it didn't spend a
lot of time actually interpreting bytecodes.
Note that similar information could be obtained by setting a
line-tracing hook, counting not instructions but lines
(which is less precise but still a good approximation).
However, line tracing is *much* too slow for anything but
debugging usage.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-10-04 06:42
Message:
Logged In: YES
user_id=6656
I see no harm in this.
Are you sure it's actually going to be useful, though?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470