12:04 <j4at> Hey there, i'm trying to use machine learning to control the jit.

12:04 <j4at> I don't think I have enough experience to do it :( Is there any easy way to interact with the jit in runtime?

12:04 <j4at> Any suggestions are apprecicated :)

12:04 <j4at> I'm planning to make it VERY simple FOR NOW, I'm planning to use pypyjit library and make a NN finetune the jit parameters and stop retracing using `pypyjit.dont_trace_here` as it see fit(didn't test anything yet). The problem is that I don't think that pypyjit provides enough info for even that. Also the documentation is outdated? And there is no `pypyjit.enable_debug()`.

12:09 <cfbolz> j4at: hey! what kind of information would you want?

12:12 <mgorny> just for the record, these merge requests make following the history of changes so hard :-(

12:13 <mgorny> though maybe it's because i'm using the git mirror

12:13 <cfbolz> mgorny: "these merge requests", what do you mean? the fact that we merge default->3.8->3.9?

12:14 <j4at> cfbolz Let's see pycode, number of loops, times it was traced, guards, operations etc.. Anything that can help really

12:36 <cfbolz> j4at: right

12:37 <cfbolz> j4at: I'm indeed not quite sure which of these the hooks provide you with

12:37 <cfbolz> j4at: do you need to know this information in-process? or is it enough to get it after the process has finished?

12:39 <j4at> It is enough to get them after the of the process for now. But Will need to get in prcoess in future

12:40 <cfbolz> right

12:41 <cfbolz> j4at: there is definitely no super nice API to "just get all of that". out of process it's possible to enable log files that can be analyzed. in-process the hooks give you some info

12:42 <cfbolz> j4at: which part of the documentation is outdated?

12:44 <j4at> None, well there is some functions which are not documented https://doc.pypy.org/en/latest/jit-hooks.html and enable_debug()/disable_debug() are not public

12:47 <cfbolz> right

12:47 <cfbolz> do you get loop execution counts without enable_debug?

12:48 <j4at> no

12:49 <j4at> iloop_run_times returns an empty dict

12:49 <cfbolz> :-(

12:49 <cfbolz> so indeed seems this was either removed or never quite worked. can you try the following: start a pypy process with the env variable PYPYLOG=jit-backend-counts:/tmp/out set?

12:50 <cfbolz> maybe you can force it to produce loop times that way

12:52 <j4at> oh it works!

12:53 <cfbolz> nice

12:54 <cfbolz> so the API was probably removed because you kind of need to turn on debugging extremely early in the process, to prevent machine code being produced before it's enabled. of course the docs should be updated

13:18 <mgorny> cfbolz: yes. but sorry, in this case i was wrong

13:18 <mgorny> i was trying to figure out where blake2b512 special case disappeared... but it turns out i've accidentally removed it while cherry-picking merge requests ;-)

13:18 <mgorny> that said, it seems redundant now

13:19 <mgorny> i mean, lib_pypy/_hashlib/__init__.py l190

13:19 <mgorny> i don't think name can be "blake2b512" anymore since _name_mapping replaces that

13:20 <mgorny> nor it can be "sha3-512" since we replace - with _ above ;-)

13:20 <mgorny> want me to report a bug for that?

13:20 <mgorny> (that's on py3.9 branch)

13:50 <cfbolz> mgorny: yes please, a bug would be great!

14:04 <j4at> asmaddr = info.asmaddr

14:04 <j4at> asmlen = info.asmlen

14:04 <j4at> asm = bytes((ctypes.c_uint8*asmlen).from_address(asmaddr))

14:04 <j4at> is this the right way to do read the asm ?

14:07 <cfbolz> j4at: sounds plausible, does it disassemble cleanly?

14:18 <j4at> cfbloz I don't think it does :(

14:19 <fijal> hey, I'm here if you want help with those APIs

14:20 <fijal> last time I worked on it (years ago) it did work

14:20 <fijal> PYPYLOG is the more "canonical" way to get the same info, but I'm happy to fix bugs too

14:33 <j4at> fijal: thank you, I appreciate it.

14:36 <j4at> I can't figure out how to read the asm

14:37 <j4at> it's different PYPYLOG's

14:42 <j4at> https://codeshare.io/8pBZ9B

14:43 <j4at> Both PYPYLOG's asm and mine start with byte 0x48 but other than that they are different.

14:43 <mgorny> cfbolz: filed https://foss.heptapod.net/pypy/pypy/-/issues/3782

14:43 <j4at> Don't know anything about assembler btw

14:44 <cfbolz> j4at: grepping around in the code, the comments at least say your interpretation of asmaddr and asmlen is correct

14:45 <cfbolz> j4at: I didn't make it to the actual implementation yet ;-)

14:53 <cfbolz> j4at: yes, I tried this: print("".join(hex(e)[2:].zfill(2) for e in asm[:asmlen]))

14:53 <cfbolz> and I can find the resulting hex embedded in the jit log, if I run with this env var: PYPYLOG=jit:out

14:53 <cfbolz> in the section jit-backend-dump

14:55 <mgorny> ohshi

14:55 <mgorny> just field another bug :-(

14:56 <mgorny> it seems that something doesn't work correctly, and pypy-generated .pyc files use cpython's magic number instead of pypy's

14:57 <cfbolz> mgorny: argh, that's kind of bad indeed

14:57 <cfbolz> thanks for finding that

14:57 <mgorny> np

14:57 <mgorny> i've been working on improving file(1) to detect pypy3

14:57 <mgorny> and i was surprised to find it detects it... as cpython ;-)

14:57 <cfbolz> neat

14:59 <j4at> cfbolz They are different for me :(

15:01 <fijal> j4at: the pypy log assembler has a massive problem, which is that it's not "live"

15:01 <fijal> if it's patched later, you miss it

15:04 <j4at> Well, objdump doesn't work either. Maybe I'm dissembling incorretly ?

15:05 <fijal> there is a magic incantation that I usually use

15:05 <fijal> j4at: what do you mean "doesn't work" btw?

15:05 <j4at> objdump: result: file format not recognized

15:06 <fijal> rpython/jit/backend/tool/viewcode.py

15:06 <fijal> look there

15:06 <fijal> yes, you not gonna get any headers or anything like that, you need to be able to disassemble on the fly

15:06 <fijal> if you are running in gdb, you can always use the disassem of gdb (with memory addresses that you get from jit hooks)

15:07 <fijal> essentially if you are getting nothing, you are doing it wrong, you just get a dump on memory and on x86 any data is valid assembler

15:08 <j4at> thank you

15:08 <j4at> I will try my best

15:08 <cfbolz> fijal: I get that, but if you dump the assembler from the jit hook it should really be exactly the same as the assembler in the log, because that is dumped at the same time

15:10 <j4at> cfbolz you used my code right ?

15:10 <cfbolz> j4at: yeah

15:11 <j4at> very weird

15:11 <cfbolz> j4at: which program are you running? I basically added an empty loop

15:12 <j4at> a tiny benchmark

15:12 <cfbolz> Right

15:19 <cfbolz> j4at: I recorded what I did https://asciinema.org/a/11X08EVVSOvBU0RS5w7Xdbpvw

15:21 <cfbolz> (sorry, I'm a bit busy the rest of the evening, happy to help you dig more in the next days)

15:22 <j4at> cfbolz thank you :) Ah I get the same result sometimes. But not all asms are in there

15:25 <cfbolz> j4at: they might be chunked up, I think

15:27 <j4at> Probably. How to solved it tho :-(

15:28 <j4at> solve* I'm done with this for today

15:28 <j4at> I will give it another try tomorrow

15:33 <cfbolz> j4at: I should be around

15:50 <j4at> I solved it I think. pypylog had "extra" bytes everywhere. fijal was correct

15:52 <fijal> cfbolz: no, because you get the address

15:52 <fijal> so when you disassemble the address, it'll be patched

16:08 <cfbolz> fijal: I don't get it. the jit hook is called right after we emit the machine code, so if we inspect the memory right there in the jit hook call, we should see exactly what PYPYLOG dumps (because it runs just before or just after that). patching only happens the next time a bridge is produced, which is later

16:57 <fijal> cfbolz: yes, but at that point in time, this is valid

16:57 <fijal> however if it's later patched and you read the same assembler, you gonna get the right response

16:58 <cfbolz> ok, but the problem is j4at is seeing different assembler between hook and PYPYLOG, despite reading *at the same time*

16:58 <fijal> that's a different problem indeed

16:58 <fijal> but you get the same?

16:59 <fijal> I wonder if it's an issue with preambles and stuff?

16:59 <cfbolz> yeah, but I tried a tiny tiny example

16:59 <cfbolz> no bridges

17:02 <fijal> right