11–20 of 40 posts
Why not just make all the abandon transactions into fake discarded transactions, discard them at the send later. E.g. by poisoning the frame checksum or setting something invalid on them, so they get discarded. Seems you'd be doing this anyway with the dummy transactions. Then you have no branch, though may want to add dummy transactions anyway to keep the code in cache.
last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. However I don't recall which CPU that was. Still this whole thing feels like a citation needed with me being suspicious it is false. CPU designers know this matters and sometimes compilers have information they don't that users care about: they document how it works. (This is the CPU not the instruction set)
This sucks.
> On modern x86 processors, those instruction prefixes are simply ignored This sucks.
Do cpus really track that much about branches? I know JIT does but where does a cpu find the needed memory to store those counters - and them how does reading those not result in a different miss because the cpu can't speculate until it does the if prediction? last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. However…
Do cpus really track that much about branches? I know JIT does but where does a cpu find the needed memory to store those counters - and them how does reading those not result in a different miss because the cpu can't speculate until it does the if prediction? last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. However…
Was that in the 80s? Modern performant CPUs all use dynamic branch prediction.
I’m not really sure I understand the “where does it get the memory” point. Yes, this requires some amount of memory per tracked branch. This memory is hardwired into the CPU, just like all the other memory a CPU needs to do its job (registers, L1 cache, TLB, various in-flight instruction state, etc.)
Do cpus really track that much about branches? I know JIT does but where does a cpu find the needed memory to store those counters - and them how does reading those not result in a different miss because the cpu can't speculate until it does the if prediction? last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. However…
> last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. Was that in the 80s? Modern performant CPUs all use dynamic branch prediction. I’m not really sure I understand the “where does it get the memory” point. Yes, this requires some amount of memory per tracked branch. This memory is hardwired into the CPU, just like al…
> I asked Claude if there is such a way to basically hard-code branch prediction rules into the machine code, and the answer was that there’s no way to do this on x86, but there is a way on ARM: the BEQP (predict branch taken) and BEQNP (predict branch not taken) instructions. > Those ARM instructions are just hallucinated, and the reality is actually the other way around: ARM doesn’t have a way of hard-coding ‘predi…
It was so detailed it makes me wonder if maybe it was in the training data somewhere. Maybe it ingested an internal MS doc for a proposed API or something. The case of the missing ARM instructions makes me wonder the same. Maybe someone on a forum proposed them and they were ingested.
I did actually verify on the OS that the calls do not exist in the kernel or any driver or DLL on the system.
Earlier quoted context omitted.
> last time I checked a cpu documentation they had a simple rule that branches are always taken, that would be easy for the compiler to code order first. Was that in the 80s? Modern performant CPUs all use dynamic branch prediction. I’m not really sure I understand the “where does it get the memory” point. Yes, this requires some amount of memory per tracked branch. This memory is hardwired into the CPU, just like al…
over the 15 million lines of code I maintain there are a lot of branches. the cpu can track the most common ones but as soon as the code spills out of cache where does that memory come from?