7 ms·

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 me

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 has failed before (ie. Jazelle, picoJava, etc).

sterlind 6y ago
maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.
- FullyFunctional 6y ago
  WASM 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 ago
    Is 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 ago
      True, 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 ago
It would mean JavaScript would have to compile to the same byte code less there are multiple instruction sets.
- FullyFunctional 6y ago
  Unlike 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 ago
The quote isn't really saying that JS-specific instructions need be added to the ISA though.
- FullyFunctional 6y ago
  In 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 ago
      You 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 ago
Yeah WASM killing JS is an outside bet for this decade. Could happen. (Please Lord).
- doteka 6y ago
  Curious, 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 ago
    I 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 ago
  We are no longer in 2005. Javascript, especially in its Typescript flavor, is a perfectly capable modern language.
  - StillBored 6y ago
    Its 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 ago
  Pray tell in which way this will help WASM?
  - masklinn 6y ago
    WASM would have at least one f64 -> int32 conversion routine with the same semantics as JS, if possibly not the only one.
austincheney 6y ago
I 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 ago
  There is https://www.assemblyscript.org/ https://www.assemblyscript.org/

sterlind 6y ago

maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.

FullyFunctional 6y ago
WASM 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 ago
  Is 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 ago
    True, 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 ago

It would mean JavaScript would have to compile to the same byte code less there are multiple instruction sets.

FullyFunctional 6y ago
Unlike 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 ago

The quote isn't really saying that JS-specific instructions need be added to the ISA though.

FullyFunctional 6y ago
In 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 ago
    You 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 ago

Yeah WASM killing JS is an outside bet for this decade. Could happen. (Please Lord).

doteka 6y ago
Curious, 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 ago
  I 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 ago
We are no longer in 2005. Javascript, especially in its Typescript flavor, is a perfectly capable modern language.
- StillBored 6y ago
  Its 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 ago
Pray tell in which way this will help WASM?
- masklinn 6y ago
  WASM would have at least one f64 -> int32 conversion routine with the same semantics as JS, if possibly not the only one.

austincheney 6y ago

I 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 ago
There is https://www.assemblyscript.org/ https://www.assemblyscript.org/