4 ms·

https://developer.arm.com/docs/100069/latest/a64-floating-point-instructions/fjcvtzs https://developer.arm.com/docs/100069/latest/a64-floating-po... (FJCVTZS: F

https://developer.arm.com/docs/100069/latest/a64-floating-point-instructions/fjcvtzs https://developer.arm.com/docs/100069/latest/a64-floating-po... (FJCVTZS: Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero) is the instruction they're talking about. One main difference (vs FCVTZS) is that it sets the Z flag depending on whether the conversion was exact, and it's mod 2^32 on overflow.

wruza 8y ago
Let’s count how many of js users did know about this “feature” before this thread (those who don’t understand what it “does” count too). Anyone can point to where it is used?
- untog 8y ago
  This isn't something a JS developer uses. It's something the CPU uses with JS someone wrote
  - kbenson 8y ago
    A less confusing way to put it might be this: This isn't something a JS developer uses. It's something as JS VM/engine developer uses to make JS faster on that platform in general.
- mikeash 8y ago
  It’s an implicit part of every bitwise operation in JS.
deleted 8y ago
[deleted]
kbumsik 8y ago
This explains everything. BTW does float=>int conversion a lot in JS other than the implicit 32bit bitwise operation?
- olliej 8y ago
  it really does not - if you’re running js that spends enough time doing double->integer conversion that that is a major bottleneck you might get some win. The instruction is not intrinsically faster than a regular float->integer conversion, the only real changes are to behavior around sentinel values. The biggest cost in floating point to integer conversion is the conversion itself, not handling of edge cases. In reality the big win from this instruction is not performance, it’s code size. So no, this instruction does not explain 40% perf improvement. It’s very easy to see why: for it to be a 40% (or any significant %) win your code would already have to be spending at least 40% of the time doing just double to int conversions. Not even micro benchmarks manage that level of insanity.
  - olliej 8y ago
    Ooh follow on demonstrating that this instruction is not making js faster: JSC does not currently emit that instruction. So given it’s never used it seems unlikely to be the reason.
simias 8y ago
I think this is the point where it starts being hard to argue that ARM is RISC anymore. x86 has BCD support and special facilities to handle NUL-terminated strings (i.e. C-strings) but now ARM has instructions with "javascript" in the name. At least Jazelle was a separate extensions. I mean I suppose it makes sense for them to do that, especially if the performance benefits are as huge as outlined in this tweet, but damn it feels dirty. I assume the reason for this is that in JS, as far as I know, all numbers are stored as floats right? So you keep casting everywhere when you need an integer? I assumed that JS implementations where a bit more clever and kept them as ints whenever possible but maybe it's not as simple as I had imagined.
- zbjornson 8y ago
  Not all numbers are stored and operated on as doubles, no. They are treated as if they were though. V8 and Spidermonkey (idk about the others) store and handle integers that fit in 32 bits as 32-bit integers.
- kccqzy 8y ago
  That's not the right metric for determining whether it's RISC or CISC. See my earlier comment at https://news.ycombinator.com/item?id=18074292 https://news.ycombinator.com/item?id=18074292

wruza 8y ago

Let’s count how many of js users did know about this “feature” before this thread (those who don’t understand what it “does” count too). Anyone can point to where it is used?

untog 8y ago
This isn't something a JS developer uses. It's something the CPU uses with JS someone wrote
- kbenson 8y ago
  A less confusing way to put it might be this: This isn't something a JS developer uses. It's something as JS VM/engine developer uses to make JS faster on that platform in general.
mikeash 8y ago
It’s an implicit part of every bitwise operation in JS.

deleted 8y ago

[deleted]

kbumsik 8y ago

This explains everything. BTW does float=>int conversion a lot in JS other than the implicit 32bit bitwise operation?

olliej 8y ago
it really does not - if you’re running js that spends enough time doing double->integer conversion that that is a major bottleneck you might get some win. The instruction is not intrinsically faster than a regular float->integer conversion, the only real changes are to behavior around sentinel values. The biggest cost in floating point to integer conversion is the conversion itself, not handling of edge cases. In reality the big win from this instruction is not performance, it’s code size. So no, this instruction does not explain 40% perf improvement. It’s very easy to see why: for it to be a 40% (or any significant %) win your code would already have to be spending at least 40% of the time doing just double to int conversions. Not even micro benchmarks manage that level of insanity.
- olliej 8y ago
  Ooh follow on demonstrating that this instruction is not making js faster: JSC does not currently emit that instruction. So given it’s never used it seems unlikely to be the reason.

simias 8y ago

I think this is the point where it starts being hard to argue that ARM is RISC anymore. x86 has BCD support and special facilities to handle NUL-terminated strings (i.e. C-strings) but now ARM has instructions with "javascript" in the name. At least Jazelle was a separate extensions. I mean I suppose it makes sense for them to do that, especially if the performance benefits are as huge as outlined in this tweet, but damn it feels dirty. I assume the reason for this is that in JS, as far as I know, all numbers are stored as floats right? So you keep casting everywhere when you need an integer? I assumed that JS implementations where a bit more clever and kept them as ints whenever possible but maybe it's not as simple as I had imagined.

zbjornson 8y ago
Not all numbers are stored and operated on as doubles, no. They are treated as if they were though. V8 and Spidermonkey (idk about the others) store and handle integers that fit in 32 bits as 32-bit integers.
kccqzy 8y ago
That's not the right metric for determining whether it's RISC or CISC. See my earlier comment at https://news.ycombinator.com/item?id=18074292 https://news.ycombinator.com/item?id=18074292