<fijal>
cfbolz: I'm happy to look at broken examples, I think
<cfbolz>
fijal: how does it work if a trace doesn't fit into the remaining allocated code block? Is there a jump and a new one allocated?
<fijal>
yes
<cfbolz>
Then that's a likely candidate?
<fijal>
then you would get, pretty obviously, the right assembler, with a jump somewhere
<cfbolz>
Ok, but if you just read the length of the assembler size, you will read past the jump?
<cfbolz>
And afterwards it's basically random memory
<cfbolz>
Depends how the size of the assembler is reported, of course
<fijal>
yeah we might not cover this particular corner case
mannerism has quit [Remote host closed the connection]
mannerism has joined #pypy
will1 has joined #pypy
j4at has joined #pypy
infernix has quit [Ping timeout: 256 seconds]
<j4at>
Pypylog's have the same asm as the one I get from the hook but with extra chunks of bytes embedded in it. I appreciate any help with that. But for now I decided to use operations instead. My next problem is that I need to disable jit from certain loops/force tracing other loops.
<j4at>
Is that possible as of rn ?
<cfbolz>
j4at: operations is probably better anyway, because less platform dependent
pbsds has quit [Quit: Ping timeout (120 seconds)]
pbsds has joined #pypy
infernix has joined #pypy
<j4at>
cfbolz: yeah I agree
<fijal>
why did you want assembler in the first place?
<j4at>
fijal: Well I thought my AI can use it to decide it's quality and if it's worth it or not.
<j4at>
So does anyone have an idea how to stop the jit from tracing a certain loop ?
<fijal>
do you have AI that specifically accepts assembler or can it learn on anything?
<j4at>
it can learn on anything
<j4at>
as long as i can encode it
<j4at>
so everything
<fijal>
right, I'm very interested in the results
<fijal>
I would definitely suggest using operations as it's a much better level of abstraction
<fijal>
what about pypyjit.dont_trace_here?
<j4at>
Didn't work
<fijal>
why not?
<fijal>
can you give me example of how it did not work?
<fijal>
you are getting called *after* you have been traced
<j4at>
I also tried to reset all traces
<fijal>
indeed does not seem to work
<j4at>
I also tried "pypyjit.set_param(retrace_limit=2)" so it stop it from retracing.
<j4at>
but that didn't work either :<
<fijal>
that should work, but retrace is something quite convoluted
<fijal>
you need to abort the traces in the first place
<fijal>
j4at: why do you want to stop tracing, while we are at it?
<fijal>
so personally an AI that can tell me where to look would already be super useful
<j4at>
Because I don't know how to get any info before tracing, which is probably possible with get_stats_snapshot and some pure python that gets the frames somehow.
<j4at>
Well my idea for now is the AI decides if a loop should be allowed to be retraced or not.
<j4at>
I think that adding a proper API is a good idea.
<j4at>
fijal: I really don't know what I'm doing :-( Encoding the operations doesn't seem easy as I don't really understand them either :p
<fijal>
ok, I can help
<fijal>
I'm trying to debug why dont_trace_here does not work, that will take a while btw (but I'm at least now on it)
<fijal>
j4at: so to give you some background. I wrote a tool once called vmprof which displayed resoperations and assembler etc.
<fijal>
there is a massive problem as to "how do we decide if there are repeating patterns that cause problems"
<fijal>
because as soon as you have anything semi-optimized and semi-big, profiling info is not that useful
<fijal>
j4at: I think, personally as an opinion, that automating it has a lower level of success than giving users more intel
<j4at>
fijal: what you mean by "giving users more intel?". They manually optimise their codes ?
<fijal>
to show what patterns give bad resoperations
<fijal>
and at the end of the day, manually optimize the code itself
<j4at>
I agree
<j4at>
But automating it has its advantages too, you can't manually optimize everything. I think we mix of both. I believe PyPy should make jit api publicish too like @final @inline @specialize @dont_trace etc.. (with CPython fallbacks aka identity decorators)
<j4at>
we need* mix of both
<fijal>
yeah maybe
<fijal>
I dont' know
<cfbolz>
j4at: some of these are hard, unfortunately
<fijal>
ok, so dont_trace_here does something else than we think it does
<fijal>
it disables inlining of the loop
<fijal>
er
<fijal>
of the function
<fijal>
I don't think it does the right thing for not tracing the loops
<j4at>
:'(
<fijal>
I can probably provide you with a hack
<j4at>
fijal: I will appreciate your help :-)
<fijal>
I mean, I would still try to understand *why* do you want to stop tracing
<fijal>
in all but few examples this is a terrible idea
<cfbolz>
yeah, stopping inlining actually sounds more useful
<j4at>
I really don't know. In some of my benchmarks retracing speed it by (x2-3) but cfbolz said that retracing slow down long code that's why its turned off. So I had the Idea to enable retracing and make an AI that stop it if needed.
<fijal>
can we start with a much simpler example than retracing?
<j4at>
You are the experts guide to what should be optimized.
<fijal>
hahaha
<j4at>
sure
<fijal>
j4at: there are no experts, just us is a more precise statement
<j4at>
alright
<cfbolz>
the expert is in another castle (irc room)
<fijal>
cfbolz: if you mean armin he's right besides me, but I don't know who you mean
<cfbolz>
fijal: it's a super mario joke
<cfbolz>
please say hi to armin though :-)
<fijal>
he is trying to understand where he put the bit of magic that very clearly does stuff that we have no clue about
<cfbolz>
in pypy or vr?
<fijal>
vr
<cfbolz>
in another castle? ;-)
<cfbolz>
fijal: does the unity sale affect you, btw?
<fijal>
eh, that's a very solid question
<fijal>
I think so? but this is quite a bit of farseeing
<fijal>
unity has been going downhill for a while. Merging with a malware company is *probably* going to accelerate the decline
<cfbolz>
shit
<fijal>
I don't know
<fijal>
it's a very solid question
jcea has joined #pypy
<fijal>
cfbolz: I would love to know *or* have alternatives
<leshaste>
sympy seems much slower in pypy than cpython. At least isprime is
<cfbolz>
leshaste: yes, sympy is a bit of a bad case for pypy (also a lot of it is written in cython now, isn't it?)
<leshaste>
ah ok
<leshaste>
it's great that it runs though!
<cfbolz>
focus: we're getting mac support, our warmup has gotten somewhat better (and might keep improving further), improved windows compatibility. some early work on 3.10 features
<cfbolz>
mac m1111
<cfbolz>
m1
<j4at>
fijal: markers ?
<fijal>
you can call it with arguments deduced from the bytecode
<fijal>
I agree that a better hook would be nicer :/ "don't trace anything in this functiuon and don't inline it, just leave it alone please"
<j4at>
The problem with bytecode is that it doesn't provide a lot of information unless we look to all the source code together.
<j4at>
Yeah but how can I can make it stop inlining tho
<j4at>
I mean inline some of the function but not all of it
<j4at>
fijal: we need a hook function that stop a function from being inlined. And then I can make 2 versions of the functions 1 inlined and other is not :p
<j4at>
I will start small for now. I will use only the bytecode
<fijal>
so dont_trace_here will stop inlining the loop part
<fijal>
I think
<fijal>
no, it should stop inlining the function alltogether, if called correctly, maybe with zero, but I'm not sure
<j4at>
OH I thought it means don't inline in this function
<j4at>
not don't inline this function
<j4at>
Well the problem I don't know how to get dont_trace_here (with the hook)
<j4at>
adont_trace_here args* (without* the hook)
j4at has quit []
j4at has joined #pypy
<j4at>
I think I made it work there is noway to verify tho.
<j4at>
fijal: Thank you for your help :) I will keep it simple for now. Better hooks will really be appreciated tho