j_ey: ping

sewardj: pong

j_ey: hey. I heard from cfallin some story about something that took 460 seconds to run

sewardj: yeah, I should figure out if I can share that

j_ey: and this was due to regalloc slowness? But I know nothing more

RA took 460s itself

That is a bit suboptimal for a JIT

sewardj: is there a reason you dont want to get on zulip?

I'm happy to get on zulip. I just don't know how. Chris told me I could log in using my github login, but I got confused by the user interface and failed to log in

anyway, the test was just some random benchmark I have

It wasnt anything hand crafted or anything

j_ey: to clarify .. my current tasking is: fix up coalescing a bit, then switch to dealing with RA run time

SortedRangeFx or something like that has a functions that domintae the profile

j_ey: also to clarify .. many of the data structures in the RA as it stands were only ever intended to be stand-ins for properly tuned/designed structures. They are there so I could bring up and validate the top level design ASAP

del(), can_add() and check() (this last one seems like a debug thing, so I commented it out)

SortedRangeFrags indeed being one of them. That needs to be replaced by a proper interval tree.

Cool, I did get that impression. I was running this stuff out of curiosity mostly

j_ey: so this stuff is all on my next-week-to-look-at list.

j_ey: what would be useful for me is to be able to reproduce your slow case, but only if it isn't too much hassle for you

try get on zulip again, since this irc will be gone by next week

uh, good point

I'll ask about the reproducer, pretty sure I can give it out

thanks.

IIRC del() was called 21 million times

took ~30% of the profile

Sounds entirely plausible

j_ey: don't bother to try fixing the current SortedRangeFrags implementation. Its new home will soon be /dev/null .. I'm aware it is unsuitable in a big-O sort of way

(not just constant-factor slowness)

fair

I tried a few simple things like with_capacity() instead of new()

but it didnt help much

no doubt

I never thought about it much because I knew it would have to be replaced

sewardj: this test case seems stuck in find_best_evict_VirtualRange

or at least everytime I stop it in gdb, it's in that

j_ey: hmm, that seems ungood

Can you get it to me?

its a function with 2800 blocks

j_ey: that's fine

I let it run over lunch, took 70minutes

hm, one of the problems was that I had to raise the number of ABI registers to get the code to lower properly

since stack arguments arent supported yet

j_ey: something that size would be very useful from the point of view of tuning the pipeline.

If you can get it to us that would be helpful.

sewardj: how can i send it to you?