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

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

#141

Post by asddubs » Sat, Oct 17, 2020, 10:20 PM UTC

domenicd wrote: post #113

goatlover wrote: post #103

Earlier quoted context omitted.

Isn’t modern JS backward compatible with 1.1?

Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec. Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g., > In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral n…

>Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...

can you explain what you mean? Did early js implementations not have functions inheriting the block scope?

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

#142

Post by saagarjha » Sat, Oct 17, 2020, 10:24 PM UTC

kps wrote: post #124

saagarjha wrote: post #110

Earlier quoted context omitted.

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?

It matches C's semantics exactly, to the point where ARM chose a specific acquire/release to match the "sequential consistency for data-race-free programs" model without requiring any global barriers or unnecessarily strong guarantees, while still allowing reordering.

(I should note that I believe this is actually C++'s memory model that C is using as well, and perhaps some other languages have adopted it too.)

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

#143

Post by innocenat » Sat, Oct 17, 2020, 10:27 PM UTC

klelatti wrote: post #138

OldHand2018 wrote: post #135

Earlier quoted context omitted.

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

I doubt it. Another major disadvantage of VLIW is instruction density. If compiler cannot fill all instruction slots, you are losing the density (thus wasting cache, bandwidth, etc).

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

#144

Post by bitcoinmoney » Sat, Oct 17, 2020, 10:29 PM UTC

marcusarmstrong wrote: post #14

If anybody else was curious, it appears that the performance win of use of this instruction looks to be about 1-2% in general javascript workloads: https://bugs.webkit.org/show_bug.cgi?id=184023#c24

I would argue a solid 1-2% can get you a promotion in HW companies. You put 5 of this improvements and that’s a generational improvement.

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

#145

Post by erikpukinskis » Sat, Oct 17, 2020, 10:40 PM UTC

secondcoming wrote: post #52

nichch wrote: post #49

Earlier quoted context omitted.

Is that significant enough to justify the instruction?

Nothing justifies the prolonging of Javascript torture.

This is like saying “nothing justifies the prolonging of capitalist torture”. On some level it’s correct, but it’s also being upset at something bordering a fundamental law of the universe.

There will always be a “lowest common denominator” platform that reaches 100% of customers.

By definition the lowest common denominator will be limited, inelegant, and suffer from weird compatibility problems.

If it wasn’t JavaScript it would be another language with very similar properties and a similar history of development.

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

#146

Post by monocasa » Sat, Oct 17, 2020, 10:42 PM UTC

why_only_15 wrote: post #69

kanox wrote: post #7

My guess is that this is what JIT people asked for.

The JSC JIT people seemed kind of surprised by this, which was weird. Maybe the V8 JIT people asked for it?

Is there a source for that? I was under the impression this initially shipped on iOS devices so it'd be weird for JSC to be surprised by it.

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

#147

Post by [deleted] » Sat, Oct 17, 2020, 10:46 PM UTC

nichch wrote: post #49

marcusarmstrong wrote: post #14

If anybody else was curious, it appears that the performance win of use of this instruction looks to be about 1-2% in general javascript workloads: https://bugs.webkit.org/show_bug.cgi?id=184023#c24

Is that significant enough to justify the instruction?

[deleted]

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

#148

Post by alquemist » Sat, Oct 17, 2020, 10:53 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).

We are no longer in 2005. Javascript, especially in its Typescript flavor, is a perfectly capable modern language.

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

#149

Post by alquemist » Sat, Oct 17, 2020, 10:59 PM UTC

Athas wrote: post #128

kps wrote: post #107

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

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

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

#150

Post by dialamac » Sat, Oct 17, 2020, 11:08 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?

> Why do you think modern CPUs still expose mostly C-abstract-machine-like interface

I don’t think that, because they don’t. Your premise is hogwash.

Modern RISC derived CPUs for the most part expose a load store architecture driven by historical evolution of that micro arch style and if they are SMP a memory model that only recently has C and C++ adapted to with standards. Intels ISA most assuredly was not influenced by C. SIMD isn’t reminiscent of anything standard C either.

Also you might want to look into VLIW and the history of Itanium for an answer to your other question.