10 ms·
Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.or
by chubot 6y ago
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-irrational-exuberance/ 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 (server-side JavaScript), Python web servers, and more. This is where cycles are being spent today, and we need evaluation that matches modern workloads. 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!
- FullyFunctional 6y agoPersonally 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 has failed before (ie. Jazelle, picoJava, etc).
- sterlind 6y agomaybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.
- FullyFunctional 6y agoWASM is _designed_ to be easily jitted, without the expensive machinery we had to put in place to do this for x86, so the whole point is not require a new architecture. Because of this I find WASM to be the best direction yet for a "universal ISA" as it's very feasible to translate to most strange new radical architecture (like EDGE, Prodigy, etc). (Introducing a new ISA is almost impossible due to the cost of porting the world. RISC-V might be the last to succeed).
- repiret 6y agoIs there really reason to believe that "porting the world" has gotten that much harder in the decade since RISC-V was released?
- kevingadd 6y ago"WASM is _designed_ to be easily jitted, without the expensive machinery we had to put in place to do this for x86" I'm not sure this is actually true, given that the original intent was for WASM to be easy to compile using existing JS infrastructure, not in general. So given that, it would make sense to carry over JS fp->int semantics into WASM. WASM is in effect a successor to asm.js. It's certainly also not too hard to compile/jit for new architectures, but that was not the initial intent or what guided the early/mid-stage design process. If you examine the current WASM spec, it doesn't appear to specify semantics at all for trunc. I would expect it inherits the exact behavior from JS.
- FullyFunctional 6y agoTrue, but wasn't my point with "expensive machinery". By that I was referring to * discovering which instructions are executed (tracking control flow), * mapping x86 code addresses to translated addresses, * discovering the shape of the CFG and finding loops, * purging translations that get invalidated by overwrites (like self-modifying code), * sprinkling the translated code full of guards so we can make assumptions about the original code etc. All this is unnecessary for WASM and you can in fact make a quick and dirty one-pass translation for the 1st gear. I don't know, but it seems reasonable that they would keep the same FP->Int semantics as JS, but you rarely do that in non-JS code. EDIT: fail to make bullets, oh well.
- dimeatree 6y agoIt would mean JavaScript would have to compile to the same byte code less there are multiple instruction sets.
- FullyFunctional 6y agoUnlike Java there's no official bytecode and all implementation do it differently. I don't think any high performance implementation use bytecodes, but instead uses threaded code for their 1st tier, and native code for all others.
- masklinn 6y agoThe quote isn't really saying that JS-specific instructions need be added to the ISA though.
- FullyFunctional 6y agoIn that sense it's not saying anything different from what we have been doing for the past 60 years. The only significant thing that has changed is that power & cooling is no longer free, so perf/power is a major concern, especially for datacenter customers.
- masklinn 6y ago> In that sense it's not saying anything different from what we have been doing for the past 60 years. Yes it is? The essay's point is that "standard" hardware benchmark (C and SPEC and friends) don't match modern workloads, and should be devaluated in favour of better matching actual modern workloads.
- FullyFunctional 6y agoYou think Intel designs processors around SPEC? (Hint: they don't). ADD: It was an issue a long time ago. Benchmarks like SPEC are actually much nicer than real server workloads. For example, running stuff like SAP would utterly trash the TLB. Curiously, AMD processors can address 0.25 TB without missing in the TLB, much better than Intel.
- randomsearch 6y agoYeah WASM killing JS is an outside bet for this decade. Could happen. (Please Lord).
- doteka 6y agoCurious, have you actually written production software targeting WASM? Because I have, in Rust, the language with the best toolchain for this by an order of magnitude. Despite all that, and me being very familiar with both Rust and JS, it was a big pain. WASM will remain a niche technology for those who really need it, as it should be. No one is going to write their business CRUD in it, it would be a terrible idea.
- FullyFunctional 6y agoI don't dispute it, but could you elaborate on the painful parts? I find the crossing in and out of JavaScript to be less than ideal. However, I don't see why WASM couldn't evolve to require less of that, ie. expose more of what you need JavaScript for today.
- monoideism 6y ago> However, I don't see why WASM couldn't evolve to require less of that, ie. expose more of what you need JavaScript for today It can, and it is. Designers are already doing all they can to make it an appealing target for a variety of languages on multiple platforms.
- alquemist 6y agoWe are no longer in 2005. Javascript, especially in its Typescript flavor, is a perfectly capable modern language.
- StillBored 6y agoIts not that it isn't capable, its that it has more gocha's than most other languages of it size (and no, just because the gocha is well defined doesn't mean that it doesn't trip programmers up). Its also despite a couple decades of hard work by some very good compiler/JIT engineers at a considerable disadvantage perf wise to a lot of other languages. Third its most common runtime environment, is a poorly thought out collection DP and UI paradigms that don't scale to even late 1980's levels, leading to lots of crutches. (AKA, just how far down your average infinite scrolling web page can you go before your browser either takes 10s of seconds to update, or crashes?).
- masklinn 6y ago> 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).
- FullyFunctional 6y agoPray tell in which way this will help WASM?
- masklinn 6y agoWASM would have at least one f64 -> int32 conversion routine with the same semantics as JS, if possibly not the only one.
- austincheney 6y agoI partially agree. I wish TypeScript compiled directly into a JIT without compiling into JavaScript and I wish TypeScript has a strict mode that always actively requires type definitions.
- lights0123 6y agoThere is https://www.assemblyscript.org/ https://www.assemblyscript.org/
- throwaway_pdp09 6y agoPlease No. Let the hardware do best what it's good at, being simple and running fast. Let the interpreter/compiler layer do its thing best, flexibility. There have been attempts to move the hardware 'upwards' to meet the software and it's not generally worked well. No special purpose language supporting hardware exists now that I'm aware of - lisp machines, smalltalk machines, Rekursiv, stretch, that 1980s object oriented car crash by intel whose name escapes me... Edited to be a touch less strident.
- matthewmacleod 6y agoLet the hardware do best what it's good at, being simple and running fast. Let the interpreter/compiler layer do its thing best, flexibility. Yeah, this is pretty much the opposite of what actually works in practice for general-purpose processors though – otherwise we'd all be using VLIW processors.
- throwaway_pdp09 6y agoThe 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 move the complexity out of the languages. Or strongly, statically type them. Or just don't use JS for server-side work. Don't make the hardware guys pick up after bad software.
- klelatti 6y agoWhen 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 match the high level language you're running.
- klelatti 6y agoIt's obviously interesting to understand performance on real life JS and Python workloads and maybe to use this to inform ISA implementations. I don't think that it's being suggested that ISAs should be designed to closely match the nature of these high level languages. This has been tried before (e.g. iAPX 432 which wasn't a resounding success!)
- FridgeSeal 6y ago“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.
- pwdisswordfish4 6y ago> “fast” languages What are those?
- FridgeSeal 6y agoC++, Rust, .Net would qualify, Go (doesn’t have a “release mode as such, but achieved decent speed), Julia, etc Anything that makes an actual attempt at optimising for performance.
- pwdisswordfish4 6y ago> .Net Not a programming language. (And you seemed to have missed the point; a "fast language" is essentially a nonsense term.) > Anything that makes an actual attempt at optimising for performance. So something like any of the modern JS engines...?
- phkahler 6y agoThat'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 it's not going to change the bigger picture of where the language fit in.
- masklinn 6y ago> But anything that impacts SPEC benchmarks (and the others we use for C code) is also going to impact Python performance. Say you work on an optimisation which improves SPEC by 0.1%, pretty good, it improves Python by 0.001%, not actually useful. Meanwhile there might be an optimisation which does the reverse and may well be of higher actual value. Because spec is a compute & parallelism benchmark, python is mostly about chasing pointers, locking, and updating counters.