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

[noreply@sourceforge.net]

Patches item #617311, was opened at 2002-10-02 00: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.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
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: Michael Hudson (mwh)
Date: 2002-11-08 12:56

Message:
Logged In: YES 
user_id=6656

I got lazy and checked in all the psyco patches at once:

Include/pystate.h revision 2.21
Modules/pyexpat.c revision 2.76
Python/ceval.c revision 2.340
Python/pystate.c revision 2.22


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-10-09 14:20

Message:
Logged In: YES 
user_id=4771

Attached an updated diff for 2.3.  This one doesn't have
Windows line endings and includes the initialization of
tick_counter to 0 that was added by Guido in the latest
2.2.2.  (I thought it was unnecessary to initialize it to
anything because profilers would only be interested in
differences.)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-10-07 15:17

Message:
Logged In: YES 
user_id=4771

Uploaded the 2.3 patch (this one cleanly generated -- for the 
other one I just cat'ed two patches in one).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-07 10:42

Message:
Logged In: YES 
user_id=6656

Done in

Include/pystate.h revision 2.18.16.1
Python/ceval.c revision 2.301.4.7

Armin, I don't know how you generated this patch, but it
would have been easier to apply if it had been rooted in the
"src" directory, like e.g.:

$ cvs diff Include/pystate.h Python/ceval.c > ~/diff



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-06 21: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 15: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 11: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