ARM chips have an instruction with JavaScript in the name

Post by masklinn » Sun, Oct 18, 2020, 7:18 AM UTC

phkahler wrote: post #158

chubot wrote: post #60

Emery 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…

That's rather silly. He says: "For example, we should care less if a proposed mobile chip or compiler optimization slows down SPEC, and care more if it speeds up Python or JavaScript!" But anything that impacts SPEC benchmarks (and the others we use for C code) is also going to impact Python performance. If you could find a new instruction that offers a boost to the Python interpreter performance that'd be nice, but…

Post by TheDong » Sun, Oct 18, 2020, 7:50 AM UTC

pkulak wrote: post #209

bhawks wrote: post #177

Earlier quoted context omitted.

Would you say the same if the language was c or c++? Yes this is necessitated by some of JS's big warts, but the sheer amount of javascript in existence weights heavily when considering the trade-offs. You cannot ignore HTML/JS if you're targeting UI applications - it is table stakes.

Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?

Post by throwaway_pdp09 » Sun, Oct 18, 2020, 7:56 AM UTC

klelatti wrote: post #118

throwaway_pdp09 wrote: post #102

Earlier quoted context omitted.

The complex processors like the PDPs were followed by risc processors because they were simpler. The hardwrae has to run code, I get that, but VLIW didn't work. Risc did. The x86 decompiles its opcodes into micro-ops which are load/store risc-y simple things. Simplicity was always the way to go. I do take your point about VLIW, but I'm kind of assuming that the CPU has to, you know, actually run real workloads. So mo…

When RISC first appeared they really were simpler than competing designs. But today I think it's hard to argue that modern pipelined, out of order processors with hundreds of millions of transistors are in any sense 'simple'. If there is a general lesson to be learned it's that the processor is often best placed to optimise on the fly rather than have the compiler try to do it (VLIW) or trying to fit a complex ISA to…

Post by throwaway_pdp09 » Sun, Oct 18, 2020, 7:58 AM UTC

alquemist wrote: post #149

Athas wrote: post #128

Earlier 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…

> in Itanium's case at least partially because it was hard to write compilers good enough to exploit its VLIW design This is half true. The other half is that OOO execution does all the pipelining a "good enough" compiler would do, except that dynamically at runtime, benefiting from just in time profiling information. Way back in the day OOO was considered too expensive, nowadays everybody uses it.

Post by pjmlp » Sun, Oct 18, 2020, 8:08 AM UTC

phkahler wrote: post #151

Joker_vD wrote: post #76

Earlier quoted context omitted.

Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?

>> Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings? Because exposing that would be a huge burden on the compiler writers. Intel tried to move in that direction with Itanium. It's bad enough with every new CPU having a few new instructions and different times, the compiler guys would…