I know this is a joke - but there totally is hardware acceleration for some of this stuff in modern processors. There definitely is for JS, JSON and generally string stuff. It’s not even x86 only, ARM got these kinds of things as well (although likely less of it)
The 8088 CPU (the one from the original IBM PC) had special string scanning support with both instructions and registers. The SI (source index) and DI (destination index) were such registers, and a bunch of instructions related.
However, specialized instructions take die area on the CPU. In the 1980s a movement based on the observation that most sophisticated instructions were not used much, and it would be better to concentrate on making very common operations (like add, load, store, shift, or whatever) fast. That started reduced-instruction set computing (RISC).
RISC was so successful that x86 chips switched to the model with a RISC-like core and implementing more sophisticated fuctions in “microcode”. Today Linux can load microcode, which is basically patching the firmware of the CPU itself.
Anyway, of course the drive towards RISC ended as people realized that some advanced functionality is really useful. In the 1990s and 2000s this was focused around new limitations: it was impossible to get higher frequencies so running a single core couldn’t get faster. CPUs added SIMD (single instruction, multiple data) support as well as hyperthreading.
Now… revisiting string operations and adding CPU support would be possible. Engineers at CPU design shops look at how their chip space is used and optimize the die area for instruction sets and also registers, cache, and so on. But my guess is that it doesn’t make sense or it would have happened a decade ago already.
What’s amazing is that actually everything in there could be doable unironically.
But more amazing (and embarrasing) is the fact that we have reached to this point where optimization is that undervalued by most programmers. Horrible timeline to live in, when AI is messing up with hardware prices.
Hardware acceleration for an interpreted programming language? Can you point me to a specific example or clarify what you mean, because I find that hard to believe.
I’m not sure what they were going for, but I know that modern browsers do just in time compilation for regularly repeated code parts to allow much faster execution, so “interpreted programming language” may be a little of a blurry definition. See https://developer.mozilla.org/en-US/docs/Glossary/Just_In_Time_Compilation
I couldn’t find any info on any hardware specific to JS/JSON for clients but I’m no expert, maybe they will provide more info.
js isn’t really interpreted anymore, it’s all jit-compiled. instructions that help with common compiler operations are pretty standard.
but there have been cpu features for interactive languages for a long time. lispmachines and forth systems are the obvious ones, but there’s been a push towards software-specific cpu dev even in the mainstream. UltraSPARC could run java natively, and itanium was designed with object-oriented systems in mind.
Tbf, it’s not really like processors have ‘DO JS STUFF’ instructions, they are not made for one language or data format specifically of course. But ultimately, instructions are shaped by things people use.
JSON for example requires searching strings for structural characters: ,, {, } etc. Iirc you can use VPSHUFB (‘Packed Shuffle Bytes’ or so, AVX >=2) to map 32 bytes (or 64 on AVX-512 I guess) to any structural character in one instruction. That’s quite the speedup compared to comparing all of them to all special characters one at a time, even considering SIMD kinda moves on its own pace. And it’s exactly the kind of stuff you would use in your JS engine to make parsing JSON crazy fast, even when it’s plain text, which is obviously less than ideal for a computer.
I remember there was some instruction that was introduced specifically because of something JS does all the time tought. I forgot what it was, maybe someone else can help out.
I know this is a joke - but there totally is hardware acceleration for some of this stuff in modern processors. There definitely is for JS, JSON and generally string stuff. It’s not even x86 only, ARM got these kinds of things as well (although likely less of it)
Removed by mod
The 8088 CPU (the one from the original IBM PC) had special string scanning support with both instructions and registers. The SI (source index) and DI (destination index) were such registers, and a bunch of instructions related.
However, specialized instructions take die area on the CPU. In the 1980s a movement based on the observation that most sophisticated instructions were not used much, and it would be better to concentrate on making very common operations (like add, load, store, shift, or whatever) fast. That started reduced-instruction set computing (RISC).
RISC was so successful that x86 chips switched to the model with a RISC-like core and implementing more sophisticated fuctions in “microcode”. Today Linux can load microcode, which is basically patching the firmware of the CPU itself.
Anyway, of course the drive towards RISC ended as people realized that some advanced functionality is really useful. In the 1990s and 2000s this was focused around new limitations: it was impossible to get higher frequencies so running a single core couldn’t get faster. CPUs added SIMD (single instruction, multiple data) support as well as hyperthreading.
Now… revisiting string operations and adding CPU support would be possible. Engineers at CPU design shops look at how their chip space is used and optimize the die area for instruction sets and also registers, cache, and so on. But my guess is that it doesn’t make sense or it would have happened a decade ago already.
Removed by mod
What’s amazing is that actually everything in there could be doable unironically.
But more amazing (and embarrasing) is the fact that we have reached to this point where optimization is that undervalued by most programmers. Horrible timeline to live in, when AI is messing up with hardware prices.
HAJPAQUE: Hardware Accelerator for JSON Parsing, Querying and Schema Validation
Have fun
Hardware acceleration for an interpreted programming language? Can you point me to a specific example or clarify what you mean, because I find that hard to believe.
I’m not sure what they were going for, but I know that modern browsers do just in time compilation for regularly repeated code parts to allow much faster execution, so “interpreted programming language” may be a little of a blurry definition. See https://developer.mozilla.org/en-US/docs/Glossary/Just_In_Time_Compilation
I couldn’t find any info on any hardware specific to JS/JSON for clients but I’m no expert, maybe they will provide more info.
https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs
js isn’t really interpreted anymore, it’s all jit-compiled. instructions that help with common compiler operations are pretty standard.
but there have been cpu features for interactive languages for a long time. lispmachines and forth systems are the obvious ones, but there’s been a push towards software-specific cpu dev even in the mainstream. UltraSPARC could run java natively, and itanium was designed with object-oriented systems in mind.
I’ve been browsing with jit disabled for years now. No regrets.
Tbf, it’s not really like processors have ‘DO JS STUFF’ instructions, they are not made for one language or data format specifically of course. But ultimately, instructions are shaped by things people use.
JSON for example requires searching strings for structural characters:
,,{,}etc. Iirc you can use VPSHUFB (‘Packed Shuffle Bytes’ or so, AVX >=2) to map 32 bytes (or 64 on AVX-512 I guess) to any structural character in one instruction. That’s quite the speedup compared to comparing all of them to all special characters one at a time, even considering SIMD kinda moves on its own pace. And it’s exactly the kind of stuff you would use in your JS engine to make parsing JSON crazy fast, even when it’s plain text, which is obviously less than ideal for a computer.I remember there was some instruction that was introduced specifically because of something JS does all the time tought. I forgot what it was, maybe someone else can help out.