ARM chips have an instruction with JavaScript in the name • Hacker News Board

Re: ARM chips have an instruction with JavaScript in the name

#121

Post by masklinn » Sat, Oct 17, 2020, 9:28 PM UTC

FullyFunctional wrote: post #73

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…

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).

Re: ARM chips have an instruction with JavaScript in the name

#122

Post by FullyFunctional » Sat, Oct 17, 2020, 9:29 PM UTC

masklinn wrote: post #120

FullyFunctional wrote: post #116

Earlier quoted context omitted.

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.

> 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.

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.

Re: ARM chips have an instruction with JavaScript in the name

#123

Post by doteka » Sat, Oct 17, 2020, 9:30 PM UTC

randomsearch wrote: post #114

FullyFunctional wrote: post #73

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

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

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.

Re: ARM chips have an instruction with JavaScript in the name

#124

Post by kps » Sat, Oct 17, 2020, 9:35 PM UTC

saagarjha wrote: post #110

kps wrote: post #107

Earlier quoted context omitted.

What aspect of currently popular CPU instruction sets ‘exists to support C’?

Here's a (doubly-indirected) example: https://news.ycombinator.com/item?id=24813376

And what about that has anything to do with C specifically? Every useful programming language requires cause precede effect, and every architecture that allows load-store reordering has memory barrier instructions. Specifically, where would code written in C require the compiler to generate one of these instructions, where code hand-written for the process's native instruction set would not?

Re: ARM chips have an instruction with JavaScript in the name

#125

Post by FullyFunctional » Sat, Oct 17, 2020, 9:38 PM UTC

doteka wrote: post #123

randomsearch wrote: post #114

Earlier quoted context omitted.

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

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.

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.

Re: ARM chips have an instruction with JavaScript in the name

#126

Post by atq2119 » Sat, Oct 17, 2020, 9:39 PM UTC

Joker_vD wrote: post #76

secondcoming wrote: post #52

Earlier quoted context omitted.

Nothing justifies the prolonging of Javascript torture.

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?

CPUs expose a "mostly-C-abstract-machine-like" interface because this allows chip designers to change the internal workings of the processor to improve performance while maintaining compatibility with all of the existing software.

It has nothing to do with C, specifically, but with the fact that vast amounts of important software tend to be distributed in binary form. In a hypothetical world where everybody is using Gentoo, the tradeoffs would be different and CPUs would most likely expose many more micro-architectural details.

Re: ARM chips have an instruction with JavaScript in the name

#127

Post by scottlamb » Sat, Oct 17, 2020, 9:45 PM UTC

sharpneli wrote: post #81

Joker_vD wrote: post #72

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

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?

Re: ARM chips have an instruction with JavaScript in the name

#128

Post by Athas » Sat, Oct 17, 2020, 9:49 PM UTC

kps wrote: post #107

saagarjha wrote: post #94

Earlier quoted context omitted.

You do understand that current hardware exists to support C, right?

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 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.

It's not like current CPUs are completely crippled by having to mostly run C programs, and that we'd have 10x as many FLOPS if only most software was in Haskell, but there are certainly trade-offs that have been made.

It is interesting to look at DSPs and GPU architectures, for examples of performance-oriented machines that have not been constrained by mostly running legacy C code. My own experience is mostly with GPUs, and I wouldn't say the PTX-level CUDA architecture is too different from C. It's a scalar-oriented programming model, carefully designed so it can be transparently vectorised. This approach won over AMDs old explicitly VLIW-oriented architecture, and most GPU vendors are now also using the NVIDIA-style design (I think NVIDIA calls it SPMT). From a programming experience POV, the main difference between CUDA programming and C programming (apart from the massive parallelism) is manual control over the memory hierarchy instead of a deep cache hierarchy, and a really weak memory model.

Oh, and of course, when we say "CPUs are built for C", we really mean the huge family of shared-state imperative scalar languages that C belongs to. I don't think C has any really unique limitations or features that have to be catered to.

Re: ARM chips have an instruction with JavaScript in the name

#129

Post by elevenoh » Sat, Oct 17, 2020, 9:54 PM UTC

qball wrote: post #33

rhacker wrote: post #19

It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.

>But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development. I think that day might be sooner than anyone thinks- Chromium is dominant enough now that their including Dart as a first-class language (or more likely, a successor to Dart) will likely be a viable strategy soon. Of course, the wildcard is Apple, but ultimately Dart can compile down to JS- being ab…

Dart is weak for functional programming / functional way of thinking. Right there, dart lang loses me as a potential user.

Re: ARM chips have an instruction with JavaScript in the name

#130

Post by monoideism » Sat, Oct 17, 2020, 9:55 PM UTC

FullyFunctional wrote: post #125

doteka wrote: post #123

Earlier quoted context omitted.

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.

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.

> 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.