> This sounds like the easiest option, so the first thing to try..? Sure, go for it :)
> With the caveat that yesterday I looked at one loop, on one machine, *the* > loop is still doing a reasonable amount of vector number crunching, perf reports the overhead of load and compare as 18% and 10%, respectively. The branch doesn't register in the profile but the first instruction afterwards is 6%. I'm sure newer, bigger hardware, with more fancy predictors would do a better job though. Ok, so feels a like like "everything is a bit expensive" :'( On Fri, 13 Jun 2025 at 14:49, Sam Parker-Haynes <[email protected]> wrote: > > Do you mean a load from a memory region that we would protect when we > want an interrupt to happen so that the load traps then and we would rely > on the trap handler to process the interrupt request? If so: maybe, but > that's still a load, which isn't great. > > Yes, but because the subsequent instructions in the loop do not depend on > the loaded value, I would hope it would be relatively cheap. This sounds > like the easiest option, so the first thing to try..? > > > If you have insights on what is expensive in stack checks, I'm all ears > :) > > With the caveat that yesterday I looked at one loop, on one machine, *the* > loop > is still doing a reasonable amount of vector number crunching, perf reports > the overhead of load and compare as 18% and 10%, respectively. The branch > doesn't register in the profile but the first instruction afterwards is 6%. > I'm sure newer, bigger hardware, with more fancy predictors would do a > better job though. > > Cheers, > Sam > > On Friday, June 13, 2025 at 12:53:08 PM UTC+1 [email protected] wrote: > >> Hi, >> >> > what is the upper bound for interrupt latency? >> >> There is no clear official upper bound. LoopStackCheckElisionReducer >> removes stack checks from loops that have less >> than kMaxIterForStackCheckRemoval (= 5000) iterations, but I chose that >> number fairly arbitrarily, using the "meh, sounds vaguely reasonable" >> principle (and it doesn't even take into account the number of instructions >> in the loop). >> >> Regarding your initial proposal (splitting loops into an inner loop >> without stack checks and an outer part with stack checks): if you can get >> that to work, sure, why not. Doesn't sound super easy to do, but why not. >> Also, once you've implemented that, we can reuse the analysis to improve >> our loop unrolling (which is currently very trivial: it repeats the whole >> loop header (including the condition) in between the unrolled iterations): >> we should then be able to remove the in-between condition checking. >> >> > The runtime patching certainly sounds interesting, if more complicated >> that a loop transform. I had no idea what you were talking about though :) >> but Pierre has filled me in. >> >> For the readers that don't have Pierre nearby to fill them in: What I >> meant is that when we emit loops, we could add a few nops before the >> backedge jump (remember that loops only have a single backedge in >> Turbofan/shaft). When we want to trigger an interrupt and the main thread >> is executing a loop, we could patch the nops in-place to instead either >> call a specific function or jump to a trampoline that would take care of >> processing the interrupt. Details would need to be ironed out: the nops >> might not even be necessary as we could maybe patch the backedge itself to >> jump to a trampoline within the Turboshaft code; how to patch back to the >> original code safely is also a good question, etc, etc. >> >> The benefit of patching compared to your proposal is that it can apply to >> every loop, without requiring an analysis pass in Turboshaft to figure out >> the general shape of the loop, like what is the loop condition & co, and >> without increasing the size of Turboshaft graphs (it might slightly >> increase the size of the generated code because of a few nops, but >> hopefully not much). >> >> > could we not just always have a probing load in the loop? >> >> Not quite sure what you mean by that. Do you mean a load from a memory >> region that we would protect when we want an interrupt to happen so that >> the load traps then and we would rely on the trap handler to process the >> interrupt request? If so: maybe, but that's still a load, which isn't great. >> >> Also, it's not entirely clear to me why stack checks are expensive. In >> theory, there are 1 load + 1 comparison + 1 branch, and the branch is >> easily branch predictable, so this whole thing should be free on >> superscalar out-of-order CPUs... Yet it definitely isn't. If the load is >> the expensive part, then we could only do the stack check every 5000 >> iterations or so (which still requires 1 comparison + 1 branch, to know >> whether we are in an iteration where we need to do a stack check). If it's >> the comparison + branch part, indeed a trapping load might be helpful. And >> if it's simply the combination of load+compare+branch, then either code >> patching or your idea of splitting the loop into inner loop + outer loop >> are the only options I can think of. If you have insights on what is >> expensive in stack checks, I'm all ears :) >> >> Cheers, >> Darius >> >> >> On Fri, 13 Jun 2025 at 13:41, Jakob Kummerow <[email protected]> >> wrote: >> >>> what is the upper bound for interrupt latency? If we have an inner loop, >>>> without calls, I would assume we could have a reasonable number of >>>> instructions and iterations before that latency would be adversely >>>> affected? >>>> >>> >>> Yes, interrupting doesn't need to be immediate. There are situations >>> where users can observe the latency of interrupting a long-running loop, so >>> it should be something that a human perceives as fast. To give numbers, I'd >>> aim for no more than 10ms latency on fast hardware, so that it won't be >>> more than 100ms on slow hardware. If an order of magnitude less than this >>> upper bound can be achieved without significant drawbacks, that's even >>> better. >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/v8-dev/CAKSzg3Rj%2Bk8GwTsECE-mRDWweU5g_kAHm1QV2_K%3DBkjmf4zAUQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/v8-dev/CAKSzg3Rj%2Bk8GwTsECE-mRDWweU5g_kAHm1QV2_K%3DBkjmf4zAUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> Darius Mercadier >> >> Software Engineer >> >> [email protected] >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Liana Sebastian >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/ed4481f2-d40a-49bf-81d7-31903eae9877n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/ed4481f2-d40a-49bf-81d7-31903eae9877n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > Darius Mercadier Software Engineer [email protected] Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAKRYUpvVqMAKNr55ZgheddY4C-sO769PNz0StfkZHa%2BoKa-KfA%40mail.gmail.com.
