20 ms·

Bear in mind that this isn't a release build, so the generated assembly will not be optimized at all.

• Annatar 10y ago
  There isn't really much more to optimise: at higher optimization levels, the compiler will figure out whether that was a one time operation or not, and if he determines that it was, it will simply hardcode: moveq $52, %eax but all the extra cruft with stack and frame pointer setup will remain unchanged, and will still be there, if only to comply with the ABI calling conventions. I guesstimate that there are up to 50 clock cycles used for each setup and teardown of the stack and frame pointers; now multiply that with the number of times a function is called, and you can easily waste hundreds of thousands, or even millions of clock cycles pretty much doing no useful work, just housekeeping.
  • rasz_pl 10y ago
    -O2 will remove stack pointer setup
    • Annatar 10y ago
      You have to have stack and frame setup if the code is to be ABI / target platform's calling convention compliant. Which compiler are you referring to, because GCC won't remove it, as far as I could tell looking at the generated assembler code? You could purposely tell GCC to omit the frame pointer -fomit-frame-pointer, but then you just made the code extremely difficult to debug (and stack setup code will still be generated, as the compiler can't generate useful / functional code without it), so that's no solution either.
      • rasz_pl 10y ago
        you dont need to setup local stack if your code doesnt use stack
        • Annatar 10y ago
          Please provide instructions on how to reproduce / verify the assertion that GCC doesn't generate stack / frame pointer setup. I want to see this for myself.
          • olegolegovich 10y ago
            The x86-64 ABI does not require frame pointer setup: https://godbolt.org/g/10URYW https://godbolt.org/g/10URYW
            • Annatar 10y ago
              That's a contrived example of inlining; now watch what happens when you provide more than just a trivial function which can be inlined; look at all the futzing it does with the stack: https://godbolt.org/g/tjrKNO https://godbolt.org/g/tjrKNO without explicit direction from humans, compilers can't generate code which calls subroutines or functions without using the stack at the very minimum, and that was my point. And that's just GCC on intel; check out intel's compiler, it's even worse (click on "turn off intel syntax", and "compile to binary and disassemble the output"): https://godbolt.org/g/IjGdAP https://godbolt.org/g/IjGdAP ...and if you try other processors as well, it just gets worse and worse: https://godbolt.org/g/DZDLju https://godbolt.org/g/DZDLju https://godbolt.org/g/s47tlR https://godbolt.org/g/s47tlR
  • RX14 10y ago
    Most crystal programs make heavy use of inlining, at least from my experience profiling crystal programs, which removes the whole overhead entirely.
    • Annatar 10y ago
      Then you end up with huge code sizes, where calls like jsr ScrollRaster(pc) end up repeating the ScrollRaster code over and over and over again, basically leading to macro expansion. And depending on the processor, your code might end up being too large to fit into the instruction cache... and you just kissed instruction burst mode bye-bye. This is unlikely to be the case on modern 80x86 processors as they have staggering amounts of cache, but who knows what embedded platforms and targets people are targeting this very moment as I write this, and who knows how small the instruction and data caches might be on those.
      • RX14 10y ago
        It's LLVM's choice when it inlines, I'm sure it has some fancy heuristics.