Hacker News Reader

Comment by kanox | Hacker News Reader

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.

According to this bug it was shipped six months after the bug was created and they didn't seem super familiar with it.

It was public knowledge that Apple had a shipped implementation using this instruction before that patch was merged.

https://news.ycombinator.com/item?id=18163433

I also don't really see any indication that the project maintainers don't know about the instruction.

Looks like an example of JSC not being developed in the open more than anything else.

are you referring to the tweet linked there? That tweet is wrong in a lot of ways, because that instruction gives you a 1-2% boost, not a 30% boost like they claimed.

They're talking about a 30% boost overall on a new release which is an amalgamation of many pieces, including use of this new instruction.

Can you give an example of something the maintainers said that made them seem "not super familiar with it"?

Don't sufficiently advanced compilers infer what the real type of a variable is, in the most important cases?

Many important cases are polymorphic so have to be able to handle both.

First comment on question: “The JavaScript engine has to do this operation (which is called ToInt32 in the spec) whenver you apply a bitwise operator to a number and at various other times (unless the engine has been able to maintain the number as an integer as an optimization, but in many cases it cannot). – T.J. Crowder”

Edit: From https://www.ecma-international.org/ecma-262/5.1/#sec-9.5

  9.5 ToInt32: (Signed 32 Bit Integer)

  The abstract operation ToInt32 converts its argument to one of 2 integer values in the range −2³¹ through 2³¹−1, inclusive. This abstract operation functions as follows:

  Let number be the result of calling ToNumber on the input argument.
  If number is NaN, +0, −0, +∞, or −∞, return +0.
  Let posInt be sign(number) * floor(abs(number)).
  Let int32bit be posInt modulo 2³²; that is, a finite integer value k of Number type with positive sign and less than 2³² in magnitude such that the mathematical difference of posInt and k is mathematically an integer multiple of 2³².
  If int32bit is greater than or equal to 2³¹, return int32bit − 2³², otherwise return int32bit.

  NOTE Given the above definition of ToInt32:

    The ToInt32 abstract operation is idempotent: if applied to a result that it produced, the second application leaves that value unchanged.

    ToInt32(ToUint32(x)) is equal to ToInt32(x) for all values of x. (It is to preserve this latter property that +∞ and −∞ are mapped to +0.)

    ToInt32 maps −0 to +0.

Remember not to refer to outdated specs; the modern version is at https://tc39.es/ecma262/#sec-toint32 . The changes look editorial modernizations (i.e., I don't think there have been any bugfixes to this low-level operation in the 9 years since ES 5.1 was published), but it's better to be safe than sorry, and build the right habits.

We do, but there are still times when a double -> int conversion is necessary, this is true in every other language as well.

The real problem is that JS inherited the x86 behavior, so everyone has to match that. The default ARM behavior is different. All this instruction does is perform a standard fpu operation, but instead of passing the current mode flags to the fpu, it passes a fixed set irrespective of the current processor mode.

As far as I can tell, any performance win comes from removing the branches after the ToInt conversion that are normally used to match x86 behavior.

Reply on news.ycombinator.com