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

231–240 of 312 posts

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

#231

Post by jpcooper »

alquemist wrote: post #215
jpcooper wrote: post #210

Earlier quoted context omitted.

Why are MFC and QT inferior to the Javascript way? I don’t know much about either.

On top of my head: * Apps eventually degenerate in a mess of interconnected components triggering events on each other. Building UIs felt more like writing Verilog than writing functions. Nothing like chasing event ordering bugs through library components. With React I never saw 'enqueue a new event for component X' anti-pattern. All callbacks flow from children to parents in a fairly regular manner. * Related, there…

Thanks for the detailed explanation.

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

#232

Post by sharpneli »

scottlamb wrote: post #153
Someone wrote: post #134

Earlier quoted context omitted.

That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction). It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.

That doesn't sound so bad to me, in comparison to fixed-size instructions. One bit in each byte gone to have the most common instructions take one byte instead of four. I can imagine that allowing much denser code overall. Or it could be one bit out of every pair of bytes, to support 2-, 4-, and 6-byte instructions. I don't know much about ARM Thumb-2, except that it does 2- or 4-byte instructions, so clearly someone…

That's still a bit of dependency between instructions, not much but it is there, and that does make making parallel decoder harder.

It's not all in favor of fixed width encoding though. Variable length has an advantage of fitting more things into the cache. So it's all a balancing act of ease of instruction decoding vs space used.

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

#233

Post by austincheney »

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…

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.

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

#234

Post by saagarjha »

repiret wrote: post #195
saagarjha wrote: post #106

Earlier quoted context omitted.

The metal which largely respects C's semantics? For example, here are some instructions that exist to match C's atomics model: https://developer.arm.com/documentation/den0024/a/Memory-Ord...

I've done work on a proprietary embedded RTOS that has had high level versions of those barriers at least a decade before the C atomics model was standardized (and compiles them to the closest barrier supported by the target architecture). I suspect that the OS and Architecture communities have known about one-way barriers for a very long time, and they were only recently added to the Arm architecture because people…

Note that I am specifically pointing to those exact barriers, and not "any old barriers". C's memory orderings don't really lower down to a single instruction on any other platform that I'm aware of because of subtle differences in semantics.

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

#235

Post by erosenbe0 »

throwaway2048 wrote: post #212
pkulak wrote: post #209

Earlier quoted context omitted.

Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?

RISC is a misleading name, the concepts of its design are not really based around the idea of a "Reduced Instruction Set" as in "small" per se, nor are CISC machines necessarily a large size instruction set. It is much more about the design of the instructions, generally RISC instructions take a small, fixed amount of time and conceptually are based on a sort of minimum unit of processing, with a weak to very weak me…

Well, it's not like x86 unaligned access was some cute thing they did just to make it extra complex. It made complete sense in 1976 when designing an ISA that might support implementations with an 8 bit memory bus and no cache. Why eat more bus cycles than you need?

Fast forward a decade or so and all processors had cache and multi-byte memory bus so the unaligned access and compact instruction streams are no longer necessary.

But processors these days are complex multi core beasts with IEEE fpu, simd units, mmu, memory controller, cache controller, pci-e northbridge, all kinds of voltage/thermal interplay, and even iGPU. ISA is over emphasized.

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

#236

Post by sergeykish »

emteycz wrote: post #220
antonvs wrote: post #206

Earlier quoted context omitted.

You can compare Javascript to other languages and note that many of its notorious problems have no rational justification, and are unnecessary. That's what I call objectively terrible.

Normally JS devs don't really encounter these notorious problems, for many years now.

You sound like a complete novice, funboy or the one who knows only JS. There are many issues, it is possible not to touch or to work around them, TS and flow helps. JS solved just a few — 'use strict', strict comparison, arrow functions, string literals. Core problems still there — implicit types, prototype declarations, number is float, toString/inspect division, typeof null. Every javascript programmer has to walk that way of embarrassment.

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

#237

Post by mantap »

kortex wrote: post #179
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.

I dunno how you folks do it, but I admire anyone that can stick with JS. It's just so...bonkers, every aspect about it, from the obvious "wat" moments, lack of integers, to the mental overhead of libs, modules, frameworks, templates, and packing. But I'm glad I have coworkers that grok it. I like trying new languages and have played with dozens, and JS and Prolog are the only languages that have made me actually scre…

Honestly modern JS has far fewer "wat" moments than most languages, modern javascript is incredibly well designed. And JavaScript does have integers now.

Nowadays it feels like the opposite, the committee takes so long to dot the i's and cross the t's that features take multiple years to make it through the approval process be ready to use (I'm looking at you, optional chaining).

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

#238

Post by moksly »

goldenManatee wrote: post #163
secondcoming wrote: post #52

Earlier quoted context omitted.

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.

Huh? Python and powershell are all over the backend, and it’s hard to argue against JavaScript while you’re using those. At least in my opinion.

I think it has more to do with the amount of people who are bad at JavaScript but are still forced to sometimes work with it because it’s the most unavoidable programming language. But who knows, people tend to complain about everything.

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

#239

Post by [deleted] »

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

#240

Post by dis-sys »

throwaway2048 wrote: post #212
pkulak wrote: post #209

Earlier quoted context omitted.

Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?

RISC is a misleading name, the concepts of its design are not really based around the idea of a "Reduced Instruction Set" as in "small" per se, nor are CISC machines necessarily a large size instruction set. It is much more about the design of the instructions, generally RISC instructions take a small, fixed amount of time and conceptually are based on a sort of minimum unit of processing, with a weak to very weak me…

when the concerned ARM instruction is doing something perfectly capable by the software to just score 1-2% performance improvements, it is definitely CISC based on the definitions you listed above.
Post reply on HN