3 ms·
The thing is, now we use and pay the price for both - memory is managed in software, and yet CPU MMU and caches have to sacrifice space on the die for complex m
by pzmarzly 3y ago
The thing is, now we use and pay the price for both - memory is managed in software, and yet CPU MMU and caches have to sacrifice space on the die for complex memory mappings. Instead we could get extra transistors for better performance (or, like in Apple CPUs, dedicated instructions for GC languages).
- SkiFire13 3y ago> like in Apple CPUs, dedicated instructions for GC languages Could you expand on this?
- pzmarzly 3y agoI was trying to refer to this https://news.ycombinator.com/item?id=25233554 https://news.ycombinator.com/item?id=25233554 (https://threadreaderapp.com/thread/1331735383193903104.html https://threadreaderapp.com/thread/1331735383193903104.html) but I didn't have time to look it up, sorry.
- masklinn 3y agoThere’s no instructions for GC’d languages. That was the old Jazelle ARM extension (which could microcode some of java’s bytecode for direct execution). The “javascript instruction” is FJCVTZS, which is a rounding mode matching x86 semantics, which is incidentally what JS specifies for double -> int32 conversions, and soft-coding it on top of FCVTZS it is rather expensive (it requires a dozen additional instructions to fix up edge cases). This is beneficial to javascript (on the order of a percentage point on some benchmarks suites, however pure javascript crypto can get high double digits gains), but it’s also beneficial for any replication of x86 rounding on ARM, including but not limited to emulating x86 on arm (aka Rosetta 2).