3 ms·

> Do you have any example of code No better than your own code. Why not put it to the test? In the end you will either know that you made the right choice, or

> Do you have any example of code No better than your own code. Why not put it to the test? In the end you will either know that you made the right choice, or have the better solution ready to swap in. You can't lose. The key takeaway from the previous comment isn't some pointless C# vs Go comparison, it is that performance can be hard to predict. Someone else's code isn't yours. It won't tell you anything about yours. Measure and find out!

neonsunset 2y ago
You did mention there exists an FFI scenario where Go supposedly performs better. It would be interesting to look at it, given the claim.
- randomdata 2y ago
  What, exactly, is interesting about arbitrary benchmarks? It might just be the C# code is slower because the developer accidentally introduced different, less performant, logic. It doesn't tell you anything. Only your own code can tell you something. I am not sure how to state this more clearly. What would actually be interesting is to see you gain those important nanoseconds of performance that is so critical to your business. We want to see you succeed (even if you don't seem the want the same for yourself?).
  - Capricorn2481 2y ago
    > It might just be the C# code is slower because the developer accidentally introduced different, less performant, logic That is why the user is asking for specific code. So they can audit whether this is a case when someone claims Go FFI is fine. As an outsider, all I see are two people saying "no it's not slow," just about different languages. But until I have a production app in either I'll never know.
    - randomdata 2y ago
      > So they can audit whether this is a case when someone claims Go FFI is fine. Of course nobody would claim such a thing. The cost is real. Whether or not Go is fine will depend entirely on what kind of problem environment you are dealing with and what your own code actually looks like. Someone else's code will never tell you this. There is no shortcut here other than to measure your own code. > As an outsider, all I see are two people saying "no it's not slow," just about different languages. It is slow, relatively speaking. But does that matter in your particular situation? Random internet benchmarks show that Python is always slower, way slower, yet people find all kinds of productive uses for Python – even in domains where computational performance is very important! And if it does matter for what you're doing, are you sure you actually picked the fastest option? Measure and find out. It is good to have rough estimates, but all of these languages are operating within the same approximate timescale here. It's not like Go, C#, or any other language is taking minutes to perform FFI. When you really do need to shave those nanoseconds off, guessing isn't going to get you there. Measure!
      - Capricorn2481 2y ago
        I'm in agreement, but it's even simpler than you're making it. If Go is slow in a certain context, I would want to know what that context is. If there's a certain task that takes a few more ms in goroutines due to some implementation detail, I would know not to use Go if that task needed to be 100,000 times. Perhaps I need to rethink the task itself, or maybe that's not possible for an organizational reason. It wouldn't be a "random internet benchmark" unless I didn't understand the context. What's random is saying this >It seems C# suffers the same problem as real-world benchmarks often show it to be slower than Go when performing FFI, even if it should be theoretically faster How is this better than asking for code examples?
        randomdata 2y ago
        > If Go is slow in a certain context, I would want to know what that context is. You'll know as soon as you measure it. Not exactly rocket science, just plain old engineering. Measuring is what engineers do. You wouldn't build a bridge without first measuring the properties of the materials, and you wouldn't build a program without measuring the properties of its 'materials'. You make a good point that it is strange we don't get better datasheets from 'material manufacturers' about the base measurements. That wouldn't fly in any other engineering discipline, but I guess that's the nature of software still being young. As unfortunate as that may be, you can't fight the state of affairs, you're just going to have to roll up your sleeves. Such is life. > How is this better than asking for code examples? Cunningham's law explains why it is better.

neonsunset 2y ago

You did mention there exists an FFI scenario where Go supposedly performs better. It would be interesting to look at it, given the claim.

randomdata 2y ago
What, exactly, is interesting about arbitrary benchmarks? It might just be the C# code is slower because the developer accidentally introduced different, less performant, logic. It doesn't tell you anything. Only your own code can tell you something. I am not sure how to state this more clearly. What would actually be interesting is to see you gain those important nanoseconds of performance that is so critical to your business. We want to see you succeed (even if you don't seem the want the same for yourself?).
- Capricorn2481 2y ago
  > It might just be the C# code is slower because the developer accidentally introduced different, less performant, logic That is why the user is asking for specific code. So they can audit whether this is a case when someone claims Go FFI is fine. As an outsider, all I see are two people saying "no it's not slow," just about different languages. But until I have a production app in either I'll never know.
  - randomdata 2y ago
    > So they can audit whether this is a case when someone claims Go FFI is fine. Of course nobody would claim such a thing. The cost is real. Whether or not Go is fine will depend entirely on what kind of problem environment you are dealing with and what your own code actually looks like. Someone else's code will never tell you this. There is no shortcut here other than to measure your own code. > As an outsider, all I see are two people saying "no it's not slow," just about different languages. It is slow, relatively speaking. But does that matter in your particular situation? Random internet benchmarks show that Python is always slower, way slower, yet people find all kinds of productive uses for Python – even in domains where computational performance is very important! And if it does matter for what you're doing, are you sure you actually picked the fastest option? Measure and find out. It is good to have rough estimates, but all of these languages are operating within the same approximate timescale here. It's not like Go, C#, or any other language is taking minutes to perform FFI. When you really do need to shave those nanoseconds off, guessing isn't going to get you there. Measure!
    - Capricorn2481 2y ago
      I'm in agreement, but it's even simpler than you're making it. If Go is slow in a certain context, I would want to know what that context is. If there's a certain task that takes a few more ms in goroutines due to some implementation detail, I would know not to use Go if that task needed to be 100,000 times. Perhaps I need to rethink the task itself, or maybe that's not possible for an organizational reason. It wouldn't be a "random internet benchmark" unless I didn't understand the context. What's random is saying this >It seems C# suffers the same problem as real-world benchmarks often show it to be slower than Go when performing FFI, even if it should be theoretically faster How is this better than asking for code examples?
      - randomdata 2y ago
        > If Go is slow in a certain context, I would want to know what that context is. You'll know as soon as you measure it. Not exactly rocket science, just plain old engineering. Measuring is what engineers do. You wouldn't build a bridge without first measuring the properties of the materials, and you wouldn't build a program without measuring the properties of its 'materials'. You make a good point that it is strange we don't get better datasheets from 'material manufacturers' about the base measurements. That wouldn't fly in any other engineering discipline, but I guess that's the nature of software still being young. As unfortunate as that may be, you can't fight the state of affairs, you're just going to have to roll up your sleeves. Such is life. > How is this better than asking for code examples? Cunningham's law explains why it is better.