Achieving C/C++/Rust comparable performance with Golang

[Kursk]

Hi,

Go is a high performant garbage collected language, (considered) memory safe programming language, and as such its performance may not be comparable with other languages such as C/C++/Rust under certain application scenarios.

I was wondering, how much of the Go language could be stretched (or ignored) to produce as close as possible performance results if for example, we write a program whose garbage collector have no work to do, assuming that we can pre-allocate all required heap space, or that we could somehow work around memory safety control points such as, index boundary checking, etc.

- Which one those performance penalty points would exactly be?

- Which ones would be impossible to workaround?

- What instructions/operations would be generally speaking comparable?

I know this is a very abstract and theoretical question, I am of course not expecting a conclusive/concrete answer to my questions but just some general answer, to increase my understanding about language performance while providing some pointers to continue my research on the topic.

This will hopefully lead me to a better general understanding on where to seek for potential optimisation opportunities within the Go language itself vs scenarios where a port to C/C++/Rust would most likely be a better option.

Thanks in advance.

[Ian Lance Taylor]

It is possible to write Go code in which all memory allocation is
explicit (through calls to the new function). Parts of the runtime
package are written that way, for example. However, it's quite hard,
and it's quite easy to make a mistake. It's not really practical to
write real Go code that way, especially since the rest of the standard
library isn't written that way.

Ian

[Robert Engels]

Same holds true for Java. People have tried What you end up with is Java is name only - so why bother.

> On Dec 14, 2022, at 2:47 PM, Ian Lance Taylor <ia...@golang.org> wrote:

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVPChN%2BHT1h5D6v-BgTMDeHLo4ai6mxiR%2BxaWbnRGAMMA%40mail.gmail.com.

[Jason E. Aten]

two comments

a) use many cores. Suddenly your Go code runs circles around everything else-- i.e. those

languages you mention where doing multicore in a pain. The view

that other languages are faster comes from an age long ago of single core machines.

b) rather than pre-mature optimization, the general wisdom, and my specific heartfelt advice,

 is to measure where the time and memory is actually being spent, and then optimize from there.

 Generally this will 100x speed your development time, and

you may find it is plenty fast already, this is on top of the 10x - 20x development speed over C++ that you

already get with Go.  Should tuning be desired subsequently, when it comes to profiling,

 the Go tools are so vastly superior to anything else out there, that you can easily find the 

hot spots and focus your optimization with laser precision. This

is much more productive than trying to guess in general and over generalized terms about how a given 

application could perform under different languages.

[Rich]

Too often people look at one benchmark -- speed in execution to determine what the best language is. Is Rust better than Go because it can run a benchmark faster?  The problem the original developers were trying to solve wasn't that C/C++ or other languages couldn't run fast enough, Ken Thompson wrote the original Unix kernel in Assembly after all, then went on to write B to make it easier to write for the new kernel. Dennis Ritchie modified B which became C and so on.  Google had large codebases meant long development times when that code needed to be changed to meet business requirements, which resulted in long compile times. So, from epic to user stories, to executable code was taking too long. 

Go is far more agile.  Epic to user stories, to executable code is much shorter giving more time for lab testing.  Of course, no program is ever 'finished' upon release they'll be new business requirements, Epics, user stories and so on. When looking for a language, raw speed shouldn't be the only consideration. Go gives decent speeds, but ask yourself does the headache of C/C++ / Rust to get a program that may process each call 500ms faster worth it? I've tried C/ C++ / Rust --  Great languages, but I'll even use Go in place of Bash because I can get it done faster.

[Sven Nebel]

Thank you for all the insights!

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/WBnqwLjzTmE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9cee8bb2-3c63-4eb8-90df-917c592656a4n%40googlegroups.com.