4 ms·
I fancy myself of having a good understanding of modern uarch. But i have to agree with @Marthinwurer. This branch predictor structure with parallel predictor a
by soulbadguy 2y ago
I fancy myself of having a good understanding of modern uarch. But i have to agree with @Marthinwurer. This branch predictor structure with parallel predictor and fake branch address is quite wild.
Do you know how this compare to what AMD/AppleM/Qualcom is doing ? This seems super effective, but seems pretty power hungry as opposed to just increasing the chase size and predictor precision. Plus i would assume it makes the cost of miss-predict even higher.
- phire 2y agoI'm pretty sure the patten of allowing the branch predictor to run ahead is pretty common. At least, it's common to have multi-level branch predictors that take a variable number of cycles to return a result, and it makes a lot of sense to queue up predictions so they are ready when the decoder gets to that point. But I doubt the idea of parallel decoders makes any sense out side of x86's complex variable length instructions. It (probably) makes sense on x86 because x86 cores were already spending a bunch of power on instruction decoding and the uop cache. > Plus i would assume it makes the cost of miss-predict even higher. It shouldn't increase the miss-predict cost by too much. The new fetch address will bypass the branch-prediction queue and feed directly into one of the three decoders. And previous implementations already have a uop queue between the decoder and re-name/dispatch. It gets flushed and the first three uops should be able to cross it in a single cycle.
- gpderetta 2y agoIt is actually probably cheaper than the alternative of attempting to decode at all possible instruction boundaries in parallel!