4 ms·

no, that's exactly what I was talking about in the first reply, i just reiterated it, because your reply wasn't taking any of that into account.

• P5fRxh5kUvp2th 4y ago
  Then you went for a strawman because the discussion was about performance, not expressiveness.
  • boltzmann-brain 4y ago
    No, my original comment is about performance, and out of that follows the necessity for expressiveness. Compilers and runtimes can perform more powerful optimizations when they have more semantics available to them. Meanwhile assembly is just a bunch of homogenous gunk to optimizers. At least until decompilers get way smarter than even the best ones are right now. Even IDA / HexRays don't reason about code at a level high enough to propose safe optimizations that can rival such optimizations as runtimes and compilers can perform when dealing with semantically rich code.
    • flohofwoe 4y ago
      > ...Meanwhile assembly is just a bunch of homogenous gunk to optimizers I wouldn't expect an assembler try to apply any further optimizations to my assembly code, that would be indeed quite pointless. For any specific problem, a human writing assembly code will almost always be able to exploit weird loopholes in a specific CPU instruction set that a compiler for a high level general programming language won't be able to (unless we're going into the realm of superoptimization via brute-force trial-and-error where an optimizer may eventually arrive at the same tricks that an anarchist assembly programmer would do).