8 ms·

It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions

It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.

latchkey 1y ago
My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.
- dontlaugh 1y ago
  I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
  - latchkey 1y ago
    [flagged]
    - dontlaugh 1y ago
      I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port". But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-automated or not), it's an opportunity to future-proof as well. I don't understand why you're being so confrontational about mere technical disagreement.
      - latchkey 1y ago
        I'm not disagreeing with you and it is weird that my comment above got flagged given that I'm not attacking you. ¯\_(ツ)_/¯
        dontlaugh 1y ago
        I don't know, I didn't flag it. I'm disagreeing with MS's choice and you seemed to disagree with that, even claiming I hadn't read their rewrite plan and reasoning. Doesn't really matter.
throwaway2037 1y ago
FYI: I have no dog in this fight. > unavoidable costly abstractions in Go Can you share some?
- dontlaugh 1y ago
  Implicit struct copies, garbage collection, interface dispatch, etc.

latchkey 1y ago

My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.

dontlaugh 1y ago
I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
- latchkey 1y ago
  [flagged]
  - dontlaugh 1y ago
    I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port". But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-automated or not), it's an opportunity to future-proof as well. I don't understand why you're being so confrontational about mere technical disagreement.
    - latchkey 1y ago
      I'm not disagreeing with you and it is weird that my comment above got flagged given that I'm not attacking you. ¯\_(ツ)_/¯
      - dontlaugh 1y ago
        I don't know, I didn't flag it. I'm disagreeing with MS's choice and you seemed to disagree with that, even claiming I hadn't read their rewrite plan and reasoning. Doesn't really matter.

throwaway2037 1y ago

FYI: I have no dog in this fight. > unavoidable costly abstractions in Go Can you share some?

dontlaugh 1y ago
Implicit struct copies, garbage collection, interface dispatch, etc.