[Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2)

[noreply@sourceforge.net]

Patches item #617311, was opened at 2002-10-01 23: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: Armin Rigo (arigo)
Date: 2002-10-04 14: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 10: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