Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)?

For tight loops loading one or two things per iteration, maybe it'd be worth it; most other things, though, will result in code size explosion (as you'd have two paths for each load, potentially multiplying on multiple consecutive loads), and, depending on the implementation, wouldn't play well with branch prediction (though it'd be very fun to just let branch mispredictions happen, given that the check may be stale by the load time anyway).

And not everyone has given up on trying to defeat cache side-channels either - spectre didn't magically erase all reasons to want to be able to speculate loads without slow context switches.



not necessarily two per load: I was guessing that frequently all loads succeed would dispatch to a happy path and any load failing to a not-so-happy path.

(with the hopes that this might allow a software-defined rough equivalence to TFA's "An out-of-order machine starts off like the first example in early iterations, and transposes into the second example when a cache miss happens, or over many iterations of the loop if not decode limited." Or at least enough to be worthwhile given a factor of 2 power win from not using OoO?)

How temporally responsive is branch prediction these days? I'd guess there'd be a fair amount of locality, in that the $ status of one iteration's data would be highly correlated with another iteration's.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: