6 ms·
FTA: > Which is odd, because you don't expect to see JavaScript so close to the bare metal. This seems to ignore all the work done on server-side javascript w
by barumi 6y ago
FTA:
> Which is odd, because you don't expect to see JavaScript so close to the bare metal.
This seems to ignore all the work done on server-side javascript with projects such as node.js and deno, as well as the fact that cloud service providers such as AWS have been developing their own ARM-based servers.
- orf 6y agoNo it doesn’t, it’s still surprising to see a CPU instruction added specifically to cater for such a high level language like JS. It does totally makes sense though, given the importance of JS and it’s common use in mobiles.
- barumi 6y ago> No it doesn’t, it’s still surprising to see a CPU instruction added specifically to cater for such a high level language like JS. It surprises you personally, but if you think about it it's easy to understand that widespread interpreters that use a specific number crunching primitive implented in software can and do benefit from significant performance improvements if they offload that to the hardware. You only need to browse through the list of opcodes supported by modern processors to notice a countless list of similar cases of instructions being added to support even higher-leve operations. I mean, are you aware that even Intel added instructions for signal processing, graphics, and even support for hash algorithms? And you're surprised by a floating point rounding operation?
- moritzwarhier 6y agoConsidering that JS is JIT-compiled and doesn't have an integer type, this is not suprising to me at all.. (but still interesting)
- imtringued 6y agoIt doesn't surprise me because we are supposed to expect commonly used programming languages to receive optimizations. If we didn't follow this logic there would be no reason to optimize C. Instead each processor company would optimize for their own proprietary language and expect everyone to use the proprietary language for high performance needs.
- est31 6y agoNot surprising to me to see CPU instructions being added for widely used use cases. Basically, a CPU instruction set maker's job is to perform clustering of the tasks that the CPUs do and accelerate commonly used tasks. If people do a lot of AES, the instruction set maker adds AES extensions. If people do a lot of CRC, they add CRC instructions. If people convert doubles to integers all day in a very JS specific way, then that's the instruction they add.
- orf 6y agoCan you name any other instructions with the name of a programming language in the actual instruction name? No? Then it seems way more specific than the other examples you listed. So specific that it’s only applicable to a single language and that language is in the instruction name. That’s surprising, like finding an instruction called “python GIL release”.
- diggan 6y agoNot necessarily programming languages (in similar vain as what est31 said) but cryptography has made its way into instructions, see SHA1RNDS4, SHA1NEXTE, SHA1MSG1 and more. They are not general cryptographic primitives but specific instructions for computing a specific cryptographic hash, just because SHA became popular. Also has SHA in it's name :)
- est31 6y agoYes, the examples I quoted AES and CRC all have dedicated instructions in x86 processors (at least the ones that implement the extensions). https://en.wikipedia.org/wiki/AES_instruction_set#Instructions https://en.wikipedia.org/wiki/AES_instruction_set#Instructio... https://www.felixcloutier.com/x86/crc32 https://www.felixcloutier.com/x86/crc32 As does ARM: https://developer.arm.com/documentation/ddi0514/g/introduction/about-the-cortex-a57-processor-cryptography-engine https://developer.arm.com/documentation/ddi0514/g/introducti... https://developer.arm.com/documentation/dui0801/g/A32-and-T32-Instructions/CRC32 https://developer.arm.com/documentation/dui0801/g/A32-and-T3... You could say that these are language-agnostic, and indeed they are, but in a certain way they are more specific than the JavaScript operation, because the JavaScript operation is likely used in many different algorithms. I'd argue that from the point of view of a chip manufacturer, the difference matters only little. Both are tasks that the CPUs do often and thus cost energy. By implementing them natively, the CPU manufacturer reduces the cost of those workflows for their clients.
- yjftsjthsd-h 6y agoJust because a language is used on servers / at scale / in enterprise, doesn't make it any closer to the metal. I mean, look at Python, Java, or Ruby: All used on servers for "serious" applications, but certainly not any sort of "bare metal" languages still.
- joshuaissac 6y agoSome ARM chips used to have bare-metal Java bytecode support, called Jazelle.