11 ms·

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

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 https://bugs.webkit.org/show_bug.cgi?id=184023#c24

nichch 6y ago
Is that significant enough to justify the instruction?
- lstamour 6y ago
  It is if it also increases battery life by a similar amount ;-)
- secondcoming 6y ago
  Nothing justifies the prolonging of Javascript torture.
  - Joker_vD 6y ago
    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?
    - wnoise 6y ago
      It's not like other languages are well-adapted to that either. That's a hard target to code for.
      - goatlover 6y ago
        Why couldn’t Haskell compilers make good use of that?
        jerf 6y ago
        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-technical-reasons-behind-the-itanium-fiasco-if-any https://stackoverflow.com/questions/1011760/what-are-the-tec... (For context, the essential Itanium idea was to move complexity out of the chip and into the compiler.) Also, don't overestimate Haskell's performance. As much fun as I've had with it, I've always been a bit disappointed with its performance. Though for good reasons, it too was designed in the hopes that a Sufficiently Smart Compiler would be able to turn it into something blazingly fast, but it hasn't succeeded any more than anything else. Writing high-performance Haskell is a lot like writing high performance Javascript for a particular JIT... it can be done, but you have to know huge amounts of stuff about how the compiler/JIT will optimize things and have to write in a very particular subset of the language that is much less powerful and convenient than the full language, with little to no compiler assistance, and with even slight mistakes able to trash the perfromance hardcore as some small little thing recursively destroys all the optimizations. It's such a project it's essentially writing in a different language that just happens to integrate nicely with the host. [1]: https://duckduckgo.com/sufficiently https://duckduckgo.com/sufficiently smart compiler
        DavidSJ 6y ago
        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.
        failuser 6y ago
        You can stuff Haskell-drived bluespec into FPGA.
    - atq2119 6y ago
      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 Gentoo, the tradeoffs would be different and CPUs would most likely expose many more micro-architectural details.
      - hobby-coder-guy 6y ago
        Just like JavaScript
    - dialamac 6y ago
      > 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.
      - Dylan16807 6y ago
        > Also you might want to look into VLIW and the history of Itanium for an answer to your other question. There's only one question. What do you mean? But Itanium wasn't out of order. How does that even come close to answering a question about exposed out-of-order machinery?
    - phkahler 6y ago
      >> 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 revolt if they had to care how many virtual registers existed and all the other stuff down there. But why C? If you want languages to interface with each other it always comes down C as a lowest common denominator. It's even hard to call C++ libraries from a lot of things. Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently.
      - still_grokking 6y ago
        > 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. As there is no alternative hardware available nobody invests in alternative software runtime models. Which makes investing in alternative hardware models again unattractive as no current software could profit from it. Here we're gone full circle. It's a trap. 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, but the computing model of C is inherently sequential and it's quite problematic to make proper use of increasingly more parallel machines. What we would need to overcome this would be a computer that is build again like the last time many years ago, as a unit of hard and software which is developed hand in hand with each other form the ground up. Maybe this way we could finally overcome the "eternal PDP-7" and move on to some more modern computer architectures (embracing parallelisms in the model from the ground up, for example).
        phkahler 6y ago
        >> 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.
    - rvp-x 6y ago
      There is one CPU that exposes its out of order inner workings, the VIA C3 ("ALTINST"). The unintended effects are so bad that people that accidentally discovered it referred to it as a backdoor: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set
      - ithkuil 6y ago
        > [..] referred to it as a backdoor Because it was implemented in a flawed way. > "In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.["
    - erosenbe0 6y ago
      Well it turned out that for running scalar code with branches and stack frames exposing too much to the compiler was not helpful, especially as transistor budgets increased. So as long as we program with usual functions and conditionals this is what we have. I can swap out a cpu for one with better IPC and hardware scheduling in 10 minutes but re-installing binaries, runtime libraries, drivers, firmware to get newly optimized code -- no way. GPU drivers do this a bit and it's no fun.
  - erikpukinskis 6y ago
    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.
  - goldenManatee 6y ago
    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.
    - antonvs 6y ago
      So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.
      - leptons 6y ago
        And that's your opinion. I find javascript quite enjoyable and easy to use, without producing errors. YMMV.
        MereInterest 6y ago
        I'd love to have a way to take a `Date` object and set it as the value of a `datetime-local` input. Sure feels like that should be straightforward to do, without requiring any weird conversions like it does.
        mr_toad 6y ago
        You might be interested in http://tc39.es/proposal-temporal/docs/index.html http://tc39.es/proposal-temporal/docs/index.html
        MereInterest 6y ago
        Wow. `zonedDateTimeISO` looks like exactly what I was hoping for. I'm kind of surprised that there isn't anything analogous to `strftime`, though.
        6y ago
  - irrational 6y ago
    Why whine about it? No matter your age, JavaScript will almost certainly still be in use until you retire.
  - toast0 6y ago
    So you're saying we should applaud reducing it by 1-2% right? To answer the question of if it's worth it to add this specialized instruction, it really depends on how much die space it adds, but from the look of it, it's specialized handling of an existing operation to match an external spec; that can be not too hard to do and significantly reduce software complexity for tasks that do that operation. As a CE with no real hardware experience, it looks like a clear win to me.
- marcusarmstrong 6y ago
  A great question for the folks who actually do CPU design! As somebody who writes JS rather frequently I’m not complaining.
  - Taniwha 6y ago
    it depends on the cost (in gates and timing) looks like this might be just a few gates
- johntb86 6y ago
  It increases the die area, power consumption, and instruction set size by a miniscule amount, so probably.
- moonchild 6y ago
  A recent AMD microarch was 10-20% faster than the previous one, despite running on the same physical process. No single component was responsible; there were changes to several components, each of which increased speed by only 1-4%.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
bitcoinmoney 6y ago
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.
- dis-sys 6y ago
  1-2% for a single language at the cost of polluting an entire instruction set.
  - deleted 6y ago
    [deleted]
  - bhawks 6y ago
    Would you say the same if the language was c or c++? Yes this is necessitated by some of JS's big warts, but the sheer amount of javascript in existence weights heavily when considering the trade-offs. You cannot ignore HTML/JS if you're targeting UI applications - it is table stakes.
    - pkulak 6y ago
      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?
      - throwaway2048 6y ago
        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 memory model (with delay slots, pipeline data hazards, required alignment of data etc) with the compiler/programmer combining them into usable higher level operations. CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models (x86 in particular is infamous here, you can pretty much safely access memory, without any alignment, at any time, even thought often the result will be slow, it wont crash) As an example, the PDP-8 has fewer than 30 instructions, but is still definitely a CISC architecture, some ARM variants have over 1000 instructions but are still definitely RISC. RISC is about making building processors simpler, not about making instruction sets and programming with them necessarily simpler.

nichch 6y ago

Is that significant enough to justify the instruction?

lstamour 6y ago
It is if it also increases battery life by a similar amount ;-)
secondcoming 6y ago
Nothing justifies the prolonging of Javascript torture.
- Joker_vD 6y ago
  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?
  - wnoise 6y ago
    It's not like other languages are well-adapted to that either. That's a hard target to code for.
    - goatlover 6y ago
      Why couldn’t Haskell compilers make good use of that?
      - jerf 6y ago
        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-technical-reasons-behind-the-itanium-fiasco-if-any https://stackoverflow.com/questions/1011760/what-are-the-tec... (For context, the essential Itanium idea was to move complexity out of the chip and into the compiler.) Also, don't overestimate Haskell's performance. As much fun as I've had with it, I've always been a bit disappointed with its performance. Though for good reasons, it too was designed in the hopes that a Sufficiently Smart Compiler would be able to turn it into something blazingly fast, but it hasn't succeeded any more than anything else. Writing high-performance Haskell is a lot like writing high performance Javascript for a particular JIT... it can be done, but you have to know huge amounts of stuff about how the compiler/JIT will optimize things and have to write in a very particular subset of the language that is much less powerful and convenient than the full language, with little to no compiler assistance, and with even slight mistakes able to trash the perfromance hardcore as some small little thing recursively destroys all the optimizations. It's such a project it's essentially writing in a different language that just happens to integrate nicely with the host. [1]: https://duckduckgo.com/sufficiently https://duckduckgo.com/sufficiently smart compiler
        DavidSJ 6y ago
        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.
      - failuser 6y ago
        You can stuff Haskell-drived bluespec into FPGA.
  - atq2119 6y ago
    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 Gentoo, the tradeoffs would be different and CPUs would most likely expose many more micro-architectural details.
    - hobby-coder-guy 6y ago
      Just like JavaScript
  - dialamac 6y ago
    > 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.
    - Dylan16807 6y ago
      > Also you might want to look into VLIW and the history of Itanium for an answer to your other question. There's only one question. What do you mean? But Itanium wasn't out of order. How does that even come close to answering a question about exposed out-of-order machinery?
  - phkahler 6y ago
    >> 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 revolt if they had to care how many virtual registers existed and all the other stuff down there. But why C? If you want languages to interface with each other it always comes down C as a lowest common denominator. It's even hard to call C++ libraries from a lot of things. Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently.
    - still_grokking 6y ago
      > 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. As there is no alternative hardware available nobody invests in alternative software runtime models. Which makes investing in alternative hardware models again unattractive as no current software could profit from it. Here we're gone full circle. It's a trap. 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, but the computing model of C is inherently sequential and it's quite problematic to make proper use of increasingly more parallel machines. What we would need to overcome this would be a computer that is build again like the last time many years ago, as a unit of hard and software which is developed hand in hand with each other form the ground up. Maybe this way we could finally overcome the "eternal PDP-7" and move on to some more modern computer architectures (embracing parallelisms in the model from the ground up, for example).
      - phkahler 6y ago
        >> 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.
  - rvp-x 6y ago
    There is one CPU that exposes its out of order inner workings, the VIA C3 ("ALTINST"). The unintended effects are so bad that people that accidentally discovered it referred to it as a backdoor: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set
    - ithkuil 6y ago
      > [..] referred to it as a backdoor Because it was implemented in a flawed way. > "In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.["
  - erosenbe0 6y ago
    Well it turned out that for running scalar code with branches and stack frames exposing too much to the compiler was not helpful, especially as transistor budgets increased. So as long as we program with usual functions and conditionals this is what we have. I can swap out a cpu for one with better IPC and hardware scheduling in 10 minutes but re-installing binaries, runtime libraries, drivers, firmware to get newly optimized code -- no way. GPU drivers do this a bit and it's no fun.
- erikpukinskis 6y ago
  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.
- goldenManatee 6y ago
  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.
  - antonvs 6y ago
    So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.
    - leptons 6y ago
      And that's your opinion. I find javascript quite enjoyable and easy to use, without producing errors. YMMV.
      - MereInterest 6y ago
        I'd love to have a way to take a `Date` object and set it as the value of a `datetime-local` input. Sure feels like that should be straightforward to do, without requiring any weird conversions like it does.
        mr_toad 6y ago
        You might be interested in http://tc39.es/proposal-temporal/docs/index.html http://tc39.es/proposal-temporal/docs/index.html
        MereInterest 6y ago
        Wow. `zonedDateTimeISO` looks like exactly what I was hoping for. I'm kind of surprised that there isn't anything analogous to `strftime`, though.
      - 6y ago
- irrational 6y ago
  Why whine about it? No matter your age, JavaScript will almost certainly still be in use until you retire.
- toast0 6y ago
  So you're saying we should applaud reducing it by 1-2% right? To answer the question of if it's worth it to add this specialized instruction, it really depends on how much die space it adds, but from the look of it, it's specialized handling of an existing operation to match an external spec; that can be not too hard to do and significantly reduce software complexity for tasks that do that operation. As a CE with no real hardware experience, it looks like a clear win to me.
marcusarmstrong 6y ago
A great question for the folks who actually do CPU design! As somebody who writes JS rather frequently I’m not complaining.
- Taniwha 6y ago
  it depends on the cost (in gates and timing) looks like this might be just a few gates
johntb86 6y ago
It increases the die area, power consumption, and instruction set size by a miniscule amount, so probably.
moonchild 6y ago
A recent AMD microarch was 10-20% faster than the previous one, despite running on the same physical process. No single component was responsible; there were changes to several components, each of which increased speed by only 1-4%.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

bitcoinmoney 6y ago

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.

dis-sys 6y ago
1-2% for a single language at the cost of polluting an entire instruction set.
- deleted 6y ago
  [deleted]
- bhawks 6y ago
  Would you say the same if the language was c or c++? Yes this is necessitated by some of JS's big warts, but the sheer amount of javascript in existence weights heavily when considering the trade-offs. You cannot ignore HTML/JS if you're targeting UI applications - it is table stakes.
  - pkulak 6y ago
    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?
    - throwaway2048 6y ago
      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 memory model (with delay slots, pipeline data hazards, required alignment of data etc) with the compiler/programmer combining them into usable higher level operations. CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models (x86 in particular is infamous here, you can pretty much safely access memory, without any alignment, at any time, even thought often the result will be slow, it wont crash) As an example, the PDP-8 has fewer than 30 instructions, but is still definitely a CISC architecture, some ARM variants have over 1000 instructions but are still definitely RISC. RISC is about making building processors simpler, not about making instruction sets and programming with them necessarily simpler.