Nice. Also useful is a set of integer operations that raise an exception on overflow.
ARM chips have an instruction with JavaScript in the name
131–140 of 312 posts
Re: ARM chips have an instruction with JavaScript in the name
#132Earlier quoted context omitted.
To understand RISC, ignore the acronym it stands for, instead just think fixed-instruction, load-store architecture. That's what RISC really means today. No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.
What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?
All sorts of boundary issues occur when you're near the end of a page or cache line. How many instruction bytes should you load per cycle? What happens when your preload of a byte that happens to be in a subsequent page trips a page fault?
By comparison, 4byte instructions that are always aligned have none of those problems. Alignment is a significant simplification for the design.
(Somewhere I have a napkin plan for fully Huffman coded instructions, but then jumps are a serious problem as they're not longer byte aligned!)
Re: ARM chips have an instruction with JavaScript in the name
#133Earlier quoted context omitted.
It's not like other languages are well-adapted to that either. That's a hard target to code for.
Why couldn’t Haskell compilers make good use of that?
The "sufficiently smart compiler" [1] has been tried often enough, with poor enough results, that it's not something anyone counts on anymore.
In this case, the most relevant example is probably the failure of the Itanium. Searching for that can be enlightening too, but heres a good start: https://stackoverflow.com/questions/1011760/what-are-the-tec... (For context, the essential Itanium idea was to move complexity out of the chip and into the compiler.)
Also, don't overestimate Haskell's performance. As much fun as I've had with it, I've always been a bit disappointed with its performance. Though for good reasons, it too was designed in the hopes that a Sufficiently Smart Compiler would be able to turn it into something blazingly fast, but it hasn't succeeded any more than anything else. Writing high-performance Haskell is a lot like writing high performance Javascript for a particular JIT... it can be done, but you have to know huge amounts of stuff about how the compiler/JIT will optimize things and have to write in a very particular subset of the language that is much less powerful and convenient than the full language, with little to no compiler assistance, and with even slight mistakes able to trash the perfromance hardcore as some small little thing recursively destroys all the optimizations. It's such a project it's essentially writing in a different language that just happens to integrate nicely with the host.
[1]: https://duckduckgo.com/sufficiently smart compiler
Re: ARM chips have an instruction with JavaScript in the name
#134Earlier quoted context omitted.
Fixed width instructions allow trivial parallel instruction decoding. With variable length instructions one must decode a previous one to figure out where the next one will start.
> With variable length instructions one must decode a previous one to figure out where the next one will start. People said the same thing about text encodings. Then UTF-8 came along. Has anyone applied the same idea to instruction encoding?
That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction).
It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.
Re: ARM chips have an instruction with JavaScript in the name
#135Earlier quoted context omitted.
What aspect of currently popular CPU instruction sets ‘exists to support C’?
Strong sequential consistency is a big one. Most architectures that have tried to diverge from this for performance reasons run into trouble with the way people like to write C code (but will not have trouble with languages actually built for concurrency). Arguably the scalar focus of CPUs is also to make them more suited for C-like languages. Now, attempts to do radically different things (like Itanium) failed for v…
> Now, attempts to do radically different things (like Itanium) failed for various reasons, in Itanium's case at least partially because it was hard to write compilers good enough to exploit its VLIW design. It's up in the air whether a different high-level language would have made those compilers feasible.
My day job involves supporting systems on Itanium: the Intel C compiler on Itanium is actually pretty good... now. We'd all have a different opinion of Itanium if it had been released with something half as good as what we've got now.
I'm sure you can have a compiler for any language that really makes VLIW shine. But it would take a lot of work, and you'd have to do that work early. Really early. Honestly, if any chip maker decided to do a clean-sheet VLIW processor and did compiler work side-by-side while they were designing it, I'd bet it would perform really well.
Re: ARM chips have an instruction with JavaScript in the name
#136Earlier quoted context omitted.
You do understand that current hardware exists to support C, right?
Yep. They have a compiler to bring it down to the metal so IDK what you're saying. --- EDIT --- @saagarjha, as I'm being slowposted by HN, here's my response via edit: OK, sure! You need some agreed semantics for that , at the low level. But the hardware guys aren't likely to add actors in the silicon. And they presumably don't intend to support eg. hardware level malloc, nor hardware level general expression evaluat…
[0] Close, it was the VAX-11 and is the poster child for CISC madness.
Re: ARM chips have an instruction with JavaScript in the name
#137Earlier quoted context omitted.
Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and…
> Adding hardware support for this is naive and has failed before (ie. Jazelle, picoJava, etc). The hardware support being added here would work just as well for WASM (though it might be less critical).
Pray tell in which way this will help WASM?
Re: ARM chips have an instruction with JavaScript in the name
#138Earlier quoted context omitted.
Strong sequential consistency is a big one. Most architectures that have tried to diverge from this for performance reasons run into trouble with the way people like to write C code (but will not have trouble with languages actually built for concurrency). Arguably the scalar focus of CPUs is also to make them more suited for C-like languages. Now, attempts to do radically different things (like Itanium) failed for v…
> Now, attempts to do radically different things (like Itanium) failed for various reasons, in Itanium's case at least partially because it was hard to write compilers good enough to exploit its VLIW design. It's up in the air whether a different high-level language would have made those compilers feasible. My day job involves supporting systems on Itanium: the Intel C compiler on Itanium is actually pretty good... n…
Thank you for an interesting comment - seems to imply that Intel have markedly improved the Itanium compiler since they discontinued Itanium which is interesting!
I guess any new architecture needs to be substantially better than existing out of order, superscalar implementations to justify any change and we are still seeing more transistors being thrown at existing architectures each year and generating some performance gains.
I wonder if / when this stops then we will see a revisiting of the VLIW approach.
Re: ARM chips have an instruction with JavaScript in the name
#139Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irra... We need to incorporate JavaScript and Python workloads into our evaluations. There are already standard benchmark suites for JavaScript performance in the browser, and we can include applications written in node.js (serv…
“We need more performance, should we fix the underlying performance problem in our software? No, we should design our CPU’s to accommodate our slow, bottlenecked language!”
Asking for CPU features to speed up Python is like trying to strap a rocket to horse and cart. Not the best way to go faster. We should focus on language design and tooling that makes it easier to write in “fast” languages, rather than bending over backwards to accommodate things like Python, which have so much more low-hanging fruit in terms of performance.
Re: ARM chips have an instruction with JavaScript in the name
#140Earlier quoted context omitted.
What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?
All sorts of boundary issues occur when you're near the end of a page or cache line. How many instruction bytes should you load per cycle? What happens when your preload of a byte that happens to be in a subsequent page trips a page fault? By comparison, 4byte instructions that are always aligned have none of those problems. Alignment is a significant simplification for the design. (Somewhere I have a napkin plan for…
> What happens when your preload of a byte that happens to be in a subsequent page trips a page fault?
spectre