12:09 <smvv> is it possible to see how often a pypy trace is hit? I'm trying to correlate vmprof's profiler output with the traces. I'm seeing multiple traces of the same code (which is expected) but I'm not sure how I can see *if* a trace is used and how long it is used. It could be that the trace is compiled, ran only once and pypy proceeds with running in the interpreter

12:15 <smvv> in ionmonkey (optimizing jit of spidermonkey), they use a single inc instruction on x64 per basic block to have an idea of how often code is actually executed. It allocates some memory next to the generated code where they store the counters for each basic block. When pretty printing the basic blocks (after the code has run), the hit counters are read and dumped as well

12:15 <smvv> (the inc instruction uses an absolute address to find the right hit counter)

12:20 <smvv> I was thinking of jit-backend-counts but I'm not sure how to read that section

13:05 <cfbolz> smvv: yes, it's that section

13:05 <cfbolz> it gives you the id of the trace, and an entry count/loop count

13:05 <cfbolz> the id of the trace is usually written as a hex number in the rest of the log, so it's annoying to correlate :-(

15:52 <ronan> smvv: backend counts are a bit dodgy, especially with counter decay on, and I'm not sure what they mean exactly

15:53 <ronan> smvv: the profile does record which traces it hits, but that information isn't shown in the web app

15:56 <fijal> ronan: it does count how many times it hit the loop. It *might* be a clash if something else occupies the same place

16:05 <ronan> fijal: yes, but when you have multiple counters in the same trace, they don't always seem consistent with each other

16:06 <fijal> oyu have exits

16:07 <ronan> yes, but not all exits are recorded

16:11 <fijal> no

16:22 <abrown> Can I ask an RPython question?

16:23 <abrown> I have an interpreter with Python-native functions; I want to be able to call 0-arg, 1-arg, etc. versions of these functions but RPython only allows me to have one of these--at least the way I am doing it

16:24 <abrown> Here is an example: https://pastebin.com/7kFPCBY4

16:26 <abrown> I'm trying to use virtual method dispatch to determine which way to call the native functions; I've had no luck with *args.

16:26 <antocuni> abrown: you can't use the same field name, function, for all the NativeFunction subclasses

16:27 <antocuni> because each subclass needs to have a function with a different type

16:27 <Alex_Gaynor> well, you can use the same field name, but it just can't be a field on the base class

16:27 <abrown> so if I did this without a base class all would be well

16:28 <Alex_Gaynor> this is legal https://www.irccloud.com/pastebin/ADodP2qg/t.py

16:28 <antocuni> Alex_Gaynor: oh, can you nowadays? I remember there was a time in which RPython tried to move it to the base class anyway

16:28 <antocuni> abrown: you still need the base class, else you don't know how to call "call()"

16:28 <Alex_Gaynor> antocuni: using `_attrs_` to make sure it never moves to the base class works; maybe it fails without that

16:28 <antocuni> but you need distinct __init__ for each of them

16:29 <antocuni> Alex_Gaynor: right, I remember now :)

16:29 <Alex_Gaynor> antocuni: classic RPython: everything works, and it's sort of nice, but extremely obscure

16:29 <antocuni> :)

16:30 <abrown> cool; so why is this the case? why is the type of `function` getting pulled in to the base class?

16:30 <antocuni> abrown: because you are setting it in NativeFunction.__init__

16:30 <antocuni> where else should it go?

16:30 <abrown> yeah... makes sense

16:31 <antocuni> think like in Java

16:31 <antocuni> if you write in Java, you have to declare the field inside NativeFunction: what type do you assign?

16:31 <abrown> yeah... so `function` is a field of the base class and the sub-classes don't re-type that field

16:32 <antocuni> (modulo the fact that in java you can't have functions as fields)

16:32 <antocuni> yes, they try to "unify" it

16:33 <abrown> thanks

16:33 <antocuni> you're welcome

18:56 <fijal> abrown: generally speaking the answer to "can I ask an RPython question" is always yes :-)