cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | Matti: I made a bit of progress, the tests now only segfault towards the end
glyph has quit [*.net *.split]
MiguelX413 has quit [*.net *.split]
rwb has quit [*.net *.split]
mannerism has quit [*.net *.split]
mattip has quit [Read error: Connection reset by peer]
mannerism has joined #pypy
rwb has joined #pypy
glyph has joined #pypy
mattip has joined #pypy
Alex_Gaynor has quit [Ping timeout: 255 seconds]
Alex_Gaynor has joined #pypy
tsraoien has joined #pypy
jcea has quit [Ping timeout: 272 seconds]
lritter has quit [Ping timeout: 276 seconds]
lritter has joined #pypy
lritter has quit [Quit: Leaving]
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
Julian has joined #pypy
Admin__ has joined #pypy
Admin__ is now known as j4at
j4at has quit [Read error: Connection reset by peer]
j4at has joined #pypy
Julian has quit [Quit: leaving]
mattip has quit [Ping timeout: 264 seconds]
mattip has joined #pypy
<j4at> Hey there, i'm trying to use machine learning to control the jit.
<j4at> I don't think I have enough experience to do it :( Is there any easy way to interact with the jit in runtime?
<j4at> Any suggestions are apprecicated :)
<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()`.
<cfbolz> j4at: hey! what kind of information would you want?
<mgorny> just for the record, these merge requests make following the history of changes so hard :-(
<mgorny> though maybe it's because i'm using the git mirror
<cfbolz> mgorny: "these merge requests", what do you mean? the fact that we merge default->3.8->3.9?
<j4at> cfbolz Let's see pycode, number of loops, times it was traced, guards, operations etc.. Anything that can help really
<cfbolz> j4at: right
<cfbolz> j4at: I'm indeed not quite sure which of these the hooks provide you with
<cfbolz> j4at: do you need to know this information in-process? or is it enough to get it after the process has finished?
<j4at> It is enough to get them after the of the process for now. But Will need to get in prcoess in future
<cfbolz> right
<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
<cfbolz> j4at: which part of the documentation is outdated?
<j4at> None, well there is some functions which are not documented and enable_debug()/disable_debug() are not public
<cfbolz> right
<cfbolz> do you get loop execution counts without enable_debug?
<j4at> no
<j4at> iloop_run_times returns an empty dict
<cfbolz> :-(
<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?
<cfbolz> maybe you can force it to produce loop times that way
<j4at> oh it works!
<cfbolz> nice
<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
jcea has joined #pypy
<mgorny> cfbolz: yes. but sorry, in this case i was wrong
<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 ;-)
<mgorny> that said, it seems redundant now
<mgorny> i mean, lib_pypy/_hashlib/ l190
<mgorny> i don't think name can be "blake2b512" anymore since _name_mapping replaces that
<mgorny> nor it can be "sha3-512" since we replace - with _ above ;-)
<mgorny> want me to report a bug for that?
<mgorny> (that's on py3.9 branch)
<cfbolz> mgorny: yes please, a bug would be great!
<j4at> asmaddr = info.asmaddr
<j4at> asmlen = info.asmlen
<j4at> asm = bytes((ctypes.c_uint8*asmlen).from_address(asmaddr))
<j4at> is this the right way to do read the asm ?
<cfbolz> j4at: sounds plausible, does it disassemble cleanly?
<j4at> cfbloz I don't think it does :(
<fijal> hey, I'm here if you want help with those APIs
<fijal> last time I worked on it (years ago) it did work
<fijal> PYPYLOG is the more "canonical" way to get the same info, but I'm happy to fix bugs too
<j4at> fijal: thank you, I appreciate it.
<j4at> I can't figure out how to read the asm
<j4at> it's different PYPYLOG's
Julian has joined #pypy
<j4at> Both PYPYLOG's asm and mine start with byte 0x48 but other than that they are different.
<j4at> Don't know anything about assembler btw
<cfbolz> j4at: grepping around in the code, the comments at least say your interpretation of asmaddr and asmlen is correct
<cfbolz> j4at: I didn't make it to the actual implementation yet ;-)
<cfbolz> j4at: yes, I tried this: print("".join(hex(e)[2:].zfill(2) for e in asm[:asmlen]))
<cfbolz> and I can find the resulting hex embedded in the jit log, if I run with this env var: PYPYLOG=jit:out
<cfbolz> in the section jit-backend-dump
<mgorny> ohshi
<mgorny> just field another bug :-(
<mgorny> it seems that something doesn't work correctly, and pypy-generated .pyc files use cpython's magic number instead of pypy's
<cfbolz> mgorny: argh, that's kind of bad indeed
<cfbolz> thanks for finding that
<mgorny> np
<mgorny> i've been working on improving file(1) to detect pypy3
<mgorny> and i was surprised to find it detects it... as cpython ;-)
<cfbolz> neat
<j4at> cfbolz They are different for me :(
<fijal> j4at: the pypy log assembler has a massive problem, which is that it's not "live"
<fijal> if it's patched later, you miss it
<j4at> Well, objdump doesn't work either. Maybe I'm dissembling incorretly ?
<fijal> there is a magic incantation that I usually use
<fijal> j4at: what do you mean "doesn't work" btw?
<j4at> objdump: result: file format not recognized
<fijal> rpython/jit/backend/tool/
<fijal> look there
<fijal> yes, you not gonna get any headers or anything like that, you need to be able to disassemble on the fly
<fijal> if you are running in gdb, you can always use the disassem of gdb (with memory addresses that you get from jit hooks)
<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
<j4at> thank you
<j4at> I will try my best
<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
<j4at> cfbolz you used my code right ?
<cfbolz> j4at: yeah
<j4at> very weird
<cfbolz> j4at: which program are you running? I basically added an empty loop
<j4at> a tiny benchmark
<cfbolz> Right
<cfbolz> j4at: I recorded what I did
<cfbolz> (sorry, I'm a bit busy the rest of the evening, happy to help you dig more in the next days)
<j4at> cfbolz thank you :) Ah I get the same result sometimes. But not all asms are in there
<cfbolz> j4at: they might be chunked up, I think
jcea has quit [Ping timeout: 268 seconds]
<j4at> Probably. How to solved it tho :-(
<j4at> solve* I'm done with this for today
<j4at> I will give it another try tomorrow
<cfbolz> j4at: I should be around
Julian has quit [Quit: leaving]
<j4at> I solved it I think. pypylog had "extra" bytes everywhere. fijal was correct
j4at has quit []
<fijal> cfbolz: no, because you get the address
<fijal> so when you disassemble the address, it'll be patched
j4at has joined #pypy
<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
Atque has quit [Ping timeout: 268 seconds]
j4at has quit []
Atque has joined #pypy
j4at has joined #pypy
<fijal> cfbolz: yes, but at that point in time, this is valid
<fijal> however if it's later patched and you read the same assembler, you gonna get the right response
<cfbolz> ok, but the problem is j4at is seeing different assembler between hook and PYPYLOG, despite reading *at the same time*
<fijal> that's a different problem indeed
<fijal> but you get the same?
<fijal> I wonder if it's an issue with preambles and stuff?
<cfbolz> yeah, but I tried a tiny tiny example
<cfbolz> no bridges
<fijal> right
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
tsraoien has quit [Ping timeout: 260 seconds]
tsraoien has joined #pypy
lritter has joined #pypy
j4at has joined #pypy
lritter has quit [Quit: Leaving]
jcea has joined #pypy
j4at has quit []
jcea has quit [Quit: jcea]
jcea has joined #pypy