6 ms·
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
by Nail2680 10d ago
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.
- RiverCrochet 10d agoL take. RAM is too slow for self-modifying code to be anywhere but F tier. This isn't 6502 land.
- Nail2680 10d agoBut it could be, there are bits about doing computation in RAM, self modifying code could work.
- RiverCrochet 9d agoIf 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.
- Nail2680 10d agoWell it was a hot take.
- eqvinox 10d agoAre 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.)
- Nail2680 10d agoYeah, 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.
- neerajsi 10d agoDisallowing 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.
- Nail2680 10d agoSo 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
- achierius 10d agoFWIW 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.
- Nail2680 10d agoI 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.