6 ms·

> Is Golang significantly slower than c++ ? > Depends the context, but in general, yes. I don't believe this is the case. Most optimized, natively compiled lan

> Is Golang significantly slower than c++ ? > Depends the context, but in general, yes. I don't believe this is the case. Most optimized, natively compiled languages all perform similarly. Go, C, CPP, Rust, Nim, etc. I'm sure there are edge-cases where this isn't the case, but they all perform roughly the same. The performance rift only starts when you introduce some form of a VM, and/or use an interpreted language. Even then, under certain workloads their optimizations can put them close to their native counter parts, but otherwise are generally slower. The real reason Google didn't re-write this in Go is likely because the library is already finished, it works, a re-write would require more extensive testing, etc. Why spend precious man-hours on a needless re-write?

spullara 7y ago
Golang and Java have similar performance characteristics. I would not put it in the same class as C/CPP/Rust. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- recursive 7y ago
  Presumably less startup time and JIT.
  - spullara 7y ago
    Depends on if the Java code is ahead of time compiled or not. The AOT compiler is included in the latest JDKs.
    - igouy 7y ago
      fwiw AoT with Substrate VM https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-substratevm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - spullara 7y ago
        Nice, good to know the JIT is doing something. Will be interesting to track the performance of this over time.
        igouy 7y ago
        And that's graalvm-ce not the enterprise edition.
  - igouy 7y ago
    The run times are seconds not micro-seconds. How many seconds do you suppose startup time is for those tiny programs? How many seconds do you suppose JIT is for those tiny programs?
- penagwin 7y ago
  I didn't realize Go was so far behind C in terms of performance. Like REALLY behind, this surprises me a lot actually. Thanks for showing me that awesome benchmark page :D
Someone 7y ago
“Most code” is debatable, but one of golang’s goals is ”Go compiles quickly to machine code” (https://golang.org/doc/ https://golang.org/doc/). Because of that, I can see it being slower than C++ on code that benefits a lot from optimization. That makes it not the right choice for code that runs a lot, as this code likely does (I expect this code runs for many CPU-years each day)
- penagwin 7y ago
  I didn't realize how far off Go's performance was from C/CPP, I have a feeling a lot of it is because of the 25+ years of optimization the c/CPP compilers have gotten.
  - dgellow 7y ago
    Go has a “stop the world” garbage collector, and some language features also have performance penalty (defer is well known for being slow). Just to say that’s not only a question of time, even if you wait and invest a huge amount of time and money you will see differences in performances because of language design choices.
    - qtplatypus 7y ago
      Go has a concurrent GC not a stop the world GC.
      - dgellow 7y ago
        Right, thanks for correcting. That doesn’t change my point though.
davismwfl 7y ago
> they all perform roughly the same. This argument to me is usually comes from people who have not done projects of significant scale or that required high performance, which is fine not everyone works on that level of a project. But the small difference of 10ms per operation when having to do a million operations is nearly 2.7 hours of extra time. Even 1ms is an extra 0.25/hr in time. These things start adding up when you are talking about doing millions of operations. And there is nothing wrong with Go or Rust or Python, just they aren't always the right tool in the toolbox when you need raw performance. Neither is C/C++ the right tool if you don't need that level of control/performance. When doing distributed systems or embedded work you generally learn these rules quickly as one "ok" performing system can wreck a really well planned system, or start costing a ton of money to spin up 10x the number of instances just because of one software component isn't performant.
- neetdeth 7y ago
  Rust was created by/for systems programmers who are in exactly that situation - where performance and control are not optional - and thus have been stuck writing C++ for decades. Although C++ has evolved over the years, there are pain points, particularly regarding modularity, that persist and may require a clean break. It's still somewhat early but I do already see software being written in Rust with best in class performance (take ripgrep for a prominent example), so lumping it in with Go and Python is really a category error in my opinion. Personally, I'm still writing C++ for the platform support, etc. but not pretending to like it.
  - davismwfl 7y ago
    Yea, I see your point, lumping Rust in with Python or Go isn't really fair nor accurate. Totally agree C++ definitely has pain points still, but I do love the fact C++ is getting pretty regular updates so it is getting better and less painful generally. Rust is something I want to use in production but haven't seen the right opportunity to do it where the risk to reward ratio was right, yet.
- penagwin 7y ago
  I concede that I mostly work on web applications that don't require that level of performance. You're certainly right, there IS a performance difference, and in high-computing workloads, such as the one this parser is used for. From a "regular" web developer perspective (ie. where you only a few servers/VPS's MAX) a lot of newcomers often worry about performance, and usually for most web development the answer with performance is "Yes language [here] is faster then Python/Javascript/Ruby/etc. But those languages/frameworks allow us to develop our application far faster, and ~10ms isn't an issue." Only after performance bottlenecks are discovered would we consider breaking out pieces into a lower level language. You're completely right though, in HPC it is totally worth worrying about every millisecond, I took the wrong perspective with the implications of the performance differences.
igouy 7y ago
> I don't believe this is the case. Please show why you don't believe this is the case.
- penagwin 7y ago
  I don't mean to be rude, but the rest of my comment explains why. If there's something about it that's confusing I'd love to clarify it.
  - igouy 7y ago
    > the rest of my comment explains why The rest of the comment makes some claims about performance, but does not show why we should believe those claims.

spullara 7y ago

Golang and Java have similar performance characteristics. I would not put it in the same class as C/CPP/Rust. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

recursive 7y ago
Presumably less startup time and JIT.
- spullara 7y ago
  Depends on if the Java code is ahead of time compiled or not. The AOT compiler is included in the latest JDKs.
  - igouy 7y ago
    fwiw AoT with Substrate VM https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-substratevm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - spullara 7y ago
      Nice, good to know the JIT is doing something. Will be interesting to track the performance of this over time.
      - igouy 7y ago
        And that's graalvm-ce not the enterprise edition.
- igouy 7y ago
  The run times are seconds not micro-seconds. How many seconds do you suppose startup time is for those tiny programs? How many seconds do you suppose JIT is for those tiny programs?
penagwin 7y ago
I didn't realize Go was so far behind C in terms of performance. Like REALLY behind, this surprises me a lot actually. Thanks for showing me that awesome benchmark page :D

Someone 7y ago

“Most code” is debatable, but one of golang’s goals is ”Go compiles quickly to machine code” (https://golang.org/doc/ https://golang.org/doc/). Because of that, I can see it being slower than C++ on code that benefits a lot from optimization. That makes it not the right choice for code that runs a lot, as this code likely does (I expect this code runs for many CPU-years each day)

penagwin 7y ago
I didn't realize how far off Go's performance was from C/CPP, I have a feeling a lot of it is because of the 25+ years of optimization the c/CPP compilers have gotten.
- dgellow 7y ago
  Go has a “stop the world” garbage collector, and some language features also have performance penalty (defer is well known for being slow). Just to say that’s not only a question of time, even if you wait and invest a huge amount of time and money you will see differences in performances because of language design choices.
  - qtplatypus 7y ago
    Go has a concurrent GC not a stop the world GC.
    - dgellow 7y ago
      Right, thanks for correcting. That doesn’t change my point though.

davismwfl 7y ago

> they all perform roughly the same. This argument to me is usually comes from people who have not done projects of significant scale or that required high performance, which is fine not everyone works on that level of a project. But the small difference of 10ms per operation when having to do a million operations is nearly 2.7 hours of extra time. Even 1ms is an extra 0.25/hr in time. These things start adding up when you are talking about doing millions of operations. And there is nothing wrong with Go or Rust or Python, just they aren't always the right tool in the toolbox when you need raw performance. Neither is C/C++ the right tool if you don't need that level of control/performance. When doing distributed systems or embedded work you generally learn these rules quickly as one "ok" performing system can wreck a really well planned system, or start costing a ton of money to spin up 10x the number of instances just because of one software component isn't performant.

neetdeth 7y ago
Rust was created by/for systems programmers who are in exactly that situation - where performance and control are not optional - and thus have been stuck writing C++ for decades. Although C++ has evolved over the years, there are pain points, particularly regarding modularity, that persist and may require a clean break. It's still somewhat early but I do already see software being written in Rust with best in class performance (take ripgrep for a prominent example), so lumping it in with Go and Python is really a category error in my opinion. Personally, I'm still writing C++ for the platform support, etc. but not pretending to like it.
- davismwfl 7y ago
  Yea, I see your point, lumping Rust in with Python or Go isn't really fair nor accurate. Totally agree C++ definitely has pain points still, but I do love the fact C++ is getting pretty regular updates so it is getting better and less painful generally. Rust is something I want to use in production but haven't seen the right opportunity to do it where the risk to reward ratio was right, yet.
penagwin 7y ago
I concede that I mostly work on web applications that don't require that level of performance. You're certainly right, there IS a performance difference, and in high-computing workloads, such as the one this parser is used for. From a "regular" web developer perspective (ie. where you only a few servers/VPS's MAX) a lot of newcomers often worry about performance, and usually for most web development the answer with performance is "Yes language [here] is faster then Python/Javascript/Ruby/etc. But those languages/frameworks allow us to develop our application far faster, and ~10ms isn't an issue." Only after performance bottlenecks are discovered would we consider breaking out pieces into a lower level language. You're completely right though, in HPC it is totally worth worrying about every millisecond, I took the wrong perspective with the implications of the performance differences.

igouy 7y ago

> I don't believe this is the case. Please show why you don't believe this is the case.

penagwin 7y ago
I don't mean to be rude, but the rest of my comment explains why. If there's something about it that's confusing I'd love to clarify it.
- igouy 7y ago
  > the rest of my comment explains why The rest of the comment makes some claims about performance, but does not show why we should believe those claims.