Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM chips have an instruction with JavaScript in the name

stackoverflow.com

Post reply on HN
Print view View original

161–170 of 312 posts

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

#161

Post by hobby-coder-guy »

atq2119 wrote: post #126
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?

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…

Just like JavaScript

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

#162

Post by alquemist »

StillBored wrote: post #154
alquemist wrote: post #148

Earlier quoted context omitted.

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

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…

Regarding gotchas, it's bearable. I only have a couple on my short list: == vs === and xs.includes(x) vs x in xs, and only the latter is not reducible to a trivial rule of thumb. TS is helpful in this regard, possibly there are more in plain JS.

Regarding performance, modern JS is plenty fast, but it's not in the 'terrible' category. It's memory usage, perhaps ;) https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For performance critical code JS is not the answer, but good enough for most uses, including UIs.

Regarding UI paradigms, I'm not sure what the problem is, or what significantly better alternatives are. I did MFC/C++ in '90s and C++/Qt in the '00s, and both were vastly inferior to modern browser development. React+StyledComponents is a wonderful way to build UIs. There are some warts on the CSS side, but mostly because Stackoverflow is full of outdated advice.

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

#163

Post by goldenManatee »

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.

For a long time I thought the JS hate was just a friendly pop jab. From working with backend folks I’ve realized it comes from at least a somewhat patronizing view that JS should feel more like backend languages; except it’s power, and real dev audience, is in browsers, where it was shaped and tortured by the browser wars, not to mention it was created in almost as many days as Genesis says the world was built.

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

#164

Post by irrational »

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.

Why whine about it? No matter your age, JavaScript will almost certainly still be in use until you retire.

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

#165

Post by pwdisswordfish4 »

goatlover wrote: post #103
tekromancr wrote: post #87

Earlier quoted context omitted.

Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.

Isn’t modern JS backward compatible with 1.1?

Modern JS really isn't even compatible with JavaScript. When people talk about "modern JS" it usually includes TypeScript and a bunch of NodeJS-isms, none of which are compatible with TC-39. It's only by proximity (and perversity) that it even gets to be considered JS.

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

#166

Post by barnacled »

It strikes me as ironic that an architecture that used to pride itself on being RISC and simple is heading in the same direction as intel-levels of masses of specialist instructions.

I don't mean this as a criticism, I just wonder if this is really the optimum direction for a practical ISA

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

#167

Post by phkahler »

still_grokking wrote: post #160
phkahler wrote: post #151

Earlier quoted context omitted.

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

> Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently. Exactly this hinders any substantial progress in computer architecture for at least 40 years now. Any hardware today needs to simulate a PDP-7 more or less… As otherwise the hardware is doomed to be considered "slow" should it not match the C abstract machine (which is mostly a PDP-7) close enough.…

>> Especially given that improvements in sequential computing speed are already difficult to achieve and it's known that this will become even more and more difficult in the future...

That's perfect. As performance stop increasing just by shrinking transistors, other options will have a chance to prove themselves.

>> but the computing model of C is inherently sequential and it's quite problematic to make proper use of increasingly more parallel machines.

IMHO Rust will help with that. The code analysis and ownership guarantees should allow the compiler to to decide when things can be run in parallel. Rust also forces you to write code that will be easier to do that. It's not a magic bullet but I think it will raise the bar on what we can expect.

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

#168

Post by pwdisswordfish4 »

StillBored wrote: post #154
alquemist wrote: post #148

Earlier quoted context omitted.

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

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…

Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being forced to do things a certain way.

But when it comes to JS and even other dynamic languages, people for some reason absolutely lose their minds, like a teenager whose parents are going out of town and are leaving them home by themselves overnight for the first time. I've seen horrendous JS from Java programmers, for example, that has made me think "Just... why? Why didn't you write the program you would have written (or already did write!) were you writing it in Java?" Like, "Yes, there are working JS programmers who do these kinds of zany things and make a real mess like this, but you don't have to, you know?"

It's as if people are dead set on proving that they need the gutter bumpers and need to be sentenced to only playing rail shooters instead of the open world game, because they can't be trusted to behave responsibly otherwise.

https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf

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

#169

Post by chubot »

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

Address generation units basically do C array indexing and pointer arithmetic, e.g. a[i], p + i, where a is a pointer of a particular size.

https://en.wikipedia.org/wiki/Address_generation_unit

In C, something like a[i] is more or less:

    (char*)(a) + (i * sizeof(*a))
And I think it will do a lot more than that for "free", e.g. a[i+1] or a[2k+1], though I don't know the details.

By having address calculations handled by separate circuitry that operates in parallel with the rest of the CPU, the number of CPU cycles required for executing various machine instructions can be reduced, bringing performance improvements.[2][3]

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

#170

Post by DavidSJ »

jerf wrote: post #133
goatlover wrote: post #100

Earlier quoted context omitted.

Why couldn’t Haskell compilers make good use of that?

The "sufficiently smart compiler" [1] has been tried often enough, with poor enough results, that it's not something anyone counts on anymore. In this case, the most relevant example is probably the failure of the Itanium. Searching for that can be enlightening too, but heres a good start: https://stackoverflow.com/questions/1011760/what-are-the-tec... (For context, the essential Itanium idea was to move complexity o…

This is reminiscent of my experience designing SQL queries to be run on large MySQL databases.

I had to write my queries in such a way that I was basically specifying the execution plan, even though in theory SQL is practically pure set theory and I shouldn’t have to care about that.

Post reply on HN