octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch, Profiler] Profiling of operators


From: Daniel Kraft
Subject: Re: [Patch, Profiler] Profiling of operators
Date: Fri, 29 Jul 2011 20:20:19 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/29/11 20:02, John W. Eaton wrote:
> On 29-Jul-2011, Daniel Kraft wrote:
> 
> | this patch implements profiling of operators.  It was not that
> hard, | after all ... only now the profile_data_accumulator *only*
> works on the | strings identifying functions and never
> octave_function references. | This is necessary because (AFAIK)
> operators don't have any | octave_function corresponding to them.
> But it seems to work the way it | is now. | | I excluded
> short-circuit operators, but that is hopefully ok.  The | problem
> with those is (as mentioned in a comment) that evaluation of |
> operands and the operator itself is entangled and thus I didn't see |
> where to start/stop timing the operator to make it reasonable. | |
> Does this look good?  Then the next step is anonymous functions.
> 
> Would it be better overall to change the interpreter so that
> operators are simply converted to function calls?  Then you wouldn't
> have to do anything special to handle profiling for them.  Also, I
> think it would fix the problem pointed to by this comment in
> do_binary_op in ov.cc:

The current implementation (with the patch) also does nothing special
for operators -- it just handles everything based on the string.

IIRC, using the name instead of the function object (resp. its address
or something similar) was what you recommended in the beginning.

I don't know about overloading -- so yes, probably the profiler is
currently fooled if two different functions have the same name (I never
used that myself in Matlab/Octave code and am not really familiar on how
you would go for an overloaded method).

Do you think we should switch back and use the octave_function objects /
pointers instead for identifying functions?  Or continue with the names?
 But also for the user it does not make a lot of sense to display two
functions with the same name; how should (s)he now which is which?

Actually, it's not the function name which is used but
octave_function::profiler_name() -- so I suppose the best way to handle
overloads would be to make this function return something like
"myfunction(double)" vs. "myfunction(int8)" instead of just
"myfunction".  Then it is both clear to the user what an entry means and
also the string can again be used as identifier of the function for
collecting data.  Does that make sense?

Yours,
Daniel

- -- 
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
or use https://safesend.kraftware.de/
- --
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOMvnjAAoJEFJ+ebqjtTmYb0IP/iwy5P7Y7mtUrQTlXbCznbn0
IA+K5i/40hY1YHbLtIH8+8y+NSIs6dJtAqd+LnMCWMUmQ1WSM6Bdrva3qKpiAAt+
5akaosIr5AZua8qcn7Eeno1kXsdNhoWopS/ZR+R4BjS4v62kKFwVkCeGdzGThgey
PB/FTdXyRUhPnNNVdwyfTZnc87lnyTTAsxoPQXh0sVWDt6ISONR/Su88xpKVQm+K
Zp8RBVIn0PIqP+3D+PQkHwP6/YZLrHDHs2w9N8+b+R3+fehyWunfP+SJPu4Ds85l
fcdr0pcAGkylB2ipVi4swULp8Jt8IJSis2/KmEGTfF0VICSp+1Jv22faHiNUvePL
oxGWhHHJk51dZkpwLmIWwZUyyFLK1bY6x+rugkBNc/JwOppjlXm+59VHn4NCbV9J
ly2YU8hXgW8JW7d2W7f+V1Br4F+gUo2rIJTgQwXGgZRc33DWbMtjxFvIk3HNyAD5
KrulDiI6D3IjkhOxVyVyvGosnqjIWkwfuo6yQFddT0aWTckL5axNuCWJTy04tHQq
FF4UqqNPTBSG+vWxscYL9RTo4ic+oigupm863Dn06sl7rTJ/nHg83JTcjJlLUGnf
u8APLUxrT/uPSDRtLLEDvH5JQdrK/zL3friq4Jg3k0OmTx8yZe5JQP07p9MKHV1L
jy2owtt24O2J5ag156yt
=fmzP
-----END PGP SIGNATURE-----


reply via email to

[Prev in Thread] Current Thread [Next in Thread]