Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.
Disallowing smc is a significant perf/power win. For cpus that run a large variety of large code (e.g. a web browser or ux stack), being able to cache a large instruction footprint and fetch/decode it quickly is important. Having to have the icache snoop data writes and entangle the i-fetch with the store buffer machinery would be a huge penalty to pay for a niche use case. Unlike loads, which are a small fraction of instructions to disambiguate with stores, you'd have to disambiguate every single instruction.
JIT is important to Apple platforms, and they seem to manage to make it work well enough even with the need for explicit invalidation.
FWIW if you look at WebKit/JavaScriptCore, the trend has been towards less-frequent code modification, e.g. inline caches are mostly no longer repatched inline. Whole-function reoptimization is still worth the overhead of sys_icache_invalidate() + `ISB`'ing everyone involved, but at smaller granularities not so much.
So that is only true because we do it, there is a world where we optimize differently and that self modifying version works better, reread the synthesis kernel thesis(one, it is super easy, two they did this), we could have hardware that does this. Because we don't have hardware that does this we don't
If DRAM gets the ability to modify itself (computations), it doesn't eliminate the cache layer between the CPU and DRAM. For the CPU to see updated DRAM values it has to bring in the DRAM to cache. Now, if that's a large amount of data, like 1MByte of computations, it's worth it, but for a couple of source/destination addresses in code, probably not. There's also the fact instruction and data caches are separate.
Now, if the RAM in the CPU cache gets computational ability as well, that all changes, but not sure really that would be better than SIMD/SEE/AVX stuff or expanding what can be done with the new tile registers Intel's rolling out.
Yeah, that works okay, but really is a you shouldn't, with pipelining you lose all the predictive decoding. The Synthesis kernel did some cool ass shit with this, but failed in other architectures due to pipelining, which speeds up shit, but change the opcodes(with other instructions(ie selfmodyfing code)) and shit gets flushed.
Comments
Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.
Disallowing smc is a significant perf/power win. For cpus that run a large variety of large code (e.g. a web browser or ux stack), being able to cache a large instruction footprint and fetch/decode it quickly is important. Having to have the icache snoop data writes and entangle the i-fetch with the store buffer machinery would be a huge penalty to pay for a niche use case. Unlike loads, which are a small fraction of instructions to disambiguate with stores, you'd have to disambiguate every single instruction.
JIT is important to Apple platforms, and they seem to manage to make it work well enough even with the need for explicit invalidation.
FWIW if you look at WebKit/JavaScriptCore, the trend has been towards less-frequent code modification, e.g. inline caches are mostly no longer repatched inline. Whole-function reoptimization is still worth the overhead of sys_icache_invalidate() + `ISB`'ing everyone involved, but at smaller granularities not so much.
I love you, keep it up dude. Exactly the kinda shit I would say if I didn't want to lose more fake internet points now.
So that is only true because we do it, there is a world where we optimize differently and that self modifying version works better, reread the synthesis kernel thesis(one, it is super easy, two they did this), we could have hardware that does this. Because we don't have hardware that does this we don't
L take. RAM is too slow for self-modifying code to be anywhere but F tier. This isn't 6502 land.
But it could be, there are bits about doing computation in RAM, self modifying code could work.
If DRAM gets the ability to modify itself (computations), it doesn't eliminate the cache layer between the CPU and DRAM. For the CPU to see updated DRAM values it has to bring in the DRAM to cache. Now, if that's a large amount of data, like 1MByte of computations, it's worth it, but for a couple of source/destination addresses in code, probably not. There's also the fact instruction and data caches are separate.
Now, if the RAM in the CPU cache gets computational ability as well, that all changes, but not sure really that would be better than SIMD/SEE/AVX stuff or expanding what can be done with the new tile registers Intel's rolling out.
Well it was a hot take.
Are you unaware that you can write code to RW memory, remap it to RX and then run it? That's how all JIT works these days.
(Or did you confuse cache flushing with TLB flushing? The remap does the latter, not the former.)
Yeah, that works okay, but really is a you shouldn't, with pipelining you lose all the predictive decoding. The Synthesis kernel did some cool ass shit with this, but failed in other architectures due to pipelining, which speeds up shit, but change the opcodes(with other instructions(ie selfmodyfing code)) and shit gets flushed.