115

As we could see from The Computer Language Benchmarks Game in 2010:

  • Go is on average 10x slower than C
  • Go is 3x slower than Java !?

How can this be, bearing in mind that Go compiler produces native code for execution?
Immature compilers for Go? Or there is some intrinsic problem with the Go language?

EDIT:
Most answers deny intrinsic slowness of Go languge, claiming the problem resides in immature compilers.
Therefore I've made some own tests to calculate Fibonacci numbers: Iterative algorithm runs in Go (freebsd,6g) with the same speed as in C (with O3 option). The dull recursive one runs in Go 2 times slower than in C (with -O3 option; with -O0 - the same). But I haven't seen 10x fall as in the Benchmarks Game.

Taavi
  • 135
  • 2
  • 16
Oleg Razgulyaev
  • 5,757
  • 4
  • 28
  • 28
  • 38
    To be fair, C is ASM in disguise, and Java has some serious optimisations under the hood these days. – Matthew Scharley Apr 24 '10 at 12:23
  • 16
    Perhaps the benchmark also does not reflect the strengths of Go. It may be that other benchmarks are actually faster than this. Besides, often it's not the performance but the readability of the code that counts most. – extraneon Apr 24 '10 at 12:31
  • 7
    @extraneon: I agree. Remember, Go is designed for Google and Google routinely runs code on 2 *million* cores. The Benchmarks Game uses only 4 cores, I believe. – Jörg W Mittag Apr 24 '10 at 14:47
  • 4
    @extraneon: I agree in general, but Go was specifically designed with speed in mind, as in, "resulting programs run nearly as quickly as comparable C or C++ code." – shosti Apr 24 '10 at 15:47
  • @eman: What does "comparable C or C++ code" mean? C or C++ code that is only allowed to do the things that Go can do? – igouy Apr 24 '10 at 17:18
  • @igouy: I don't know what it means exactly, the quote comes from the Go website. (I think their goal is to get within 20% of C's speed for systems-oriented stuff.) – shosti Apr 24 '10 at 18:04
  • @eman go seems to be designed to stimulate highly parallel code. So a good benchmark for Go would use a problemen which can be parallelized (web server, mapreduce) and test it on 1000 cores. There it should shine (performance like C, less code) – extraneon Apr 25 '10 at 08:43
  • >> own tests to calculate Fibonacci numbers << One of the reasons that the benchmarks game exists is that people used to write 10 line fib programs and act as though a single 10 line program was a reason to think one language implementation was faster than another! (Measure ALL the programs in go/test/bench) Does your C program inline like these fib programs? http://shootout.alioth.debian.org/gp4/program.php?test=recursive&lang=gcc&id=1 – igouy Apr 26 '10 at 04:42
  • "igouy: i see, just raw estimation of languages, not compilers – Oleg Razgulyaev Apr 26 '10 at 09:06
  • @oraz: In that case you don't understand what you're looking at. You're told which language implementation was measured (in the case of compiled languages, which compiler). You're told the C compiler was GCC. You're told these measurements are for -Xint Java and those for -server Java. You're told these measurements are for CPython and those for PyPy - neither are for "Python the language". – igouy Apr 26 '10 at 15:46
  • @igouy: in general i agree: in extreme case for any language can be designed supercompiler to produce unbeatible machine code – Oleg Razgulyaev Apr 26 '10 at 19:45
  • 5
    Your question assumes too much: "Most answers deny intrinsic slowness of Go languge" is an incorrect phrase for use in a question. Do you have a question to ask, or a statement to make? Please see http://www.c2.com/cgi/wiki?HostileStudent to understand your error. – Chris Feb 02 '11 at 18:22
  • 2
    The reason why your Fibonacci-example is so much slower is simple; by design, Go imposes a little extra cost (about five ticks) on function call. Since a recursive Fibonacci example does little apart from calling functions, that might very well yield the performance differences you describe. Try again with something less recursive. – fuz Apr 04 '13 at 16:09
  • 4
    Also, as of now the benchmark game shows that the Go program is just about two times slower for most examples than the C code (and has about the same speed and much less memory than Java) – fuz Apr 04 '13 at 16:11
  • Go intended purpose was it being an "infrastructure language" for web and web service development. Go is way faster, more robust, and easier to use than most alternatives, in that applicative domain. Go is not optimized for recursion. Go tries to be "safe" and has constructs for light threads (Goroutines). You are probably comparing apple to oranges if you compare Go to C for simple tasks on a single core. – Michele Giuseppe Fadda Nov 17 '15 at 12:08
  • Please fix your question! —— "As we could see from The Computer Language Benchmarks Game in 2010" shows measurements made on **26 Feb 2019** with Go 1.12 — and the other links 404. —— https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html – igouy Feb 27 '19 at 18:49
  • this was / is the case under crippled commercial so called operating systems. my bad – Dan Marinescu May 17 '19 at 20:08

10 Answers10

104

The 6g and 8g compilers are not particularly optimising, so the code they produce isn't particularly fast.

They're designed to run fast themselves and produce code that's OK (there is a bit of optimisation). gccgo uses GCC's existing optimisation passes, and might provide a more pointful comparison with C, but gccgo isn't feature-complete yet.

Benchmark figures are almost entirely about quality of implementation. They don't have a huge amount to do with the language as such, except to the extent that the implementation spends runtime supporting language features that the benchmark doesn't really need. In most compiled languages a sufficiently clever compiler could in theory strip out what isn't needed, but there comes a point where you're rigging the demo, since very few real users of the language would write programs that didn't use that feature. Moving things out of the way without removing them entirely (e.g. predicting virtual call destinations in JIT-compiled Java) starts to get tricky.

FWIW, my own very trivial test with Go when I was taking a look at it (a loop of integer addition, basically), gccgo produced code towards the fast end of the range between gcc -O0 and gcc -O2 for equivalent C. Go isn't inherently slow, but the compilers don't do everything, yet. Hardly surprising for a language that's 10 minutes old.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • 7
    Moreover, it may be that Go programs in The Computer Language Benchmarks Game are not that optimized as C and Java ones are. – el.pescado - нет войне Apr 24 '10 at 12:58
  • What about between gcc -O0 and gcc -O3 ? Is there even the intention that the compilers will "do everything" ? – igouy Apr 24 '10 at 17:19
  • @igouy: well, I'm pretty sure that there's an intention gccgo will do garbage collection, which currently it doesn't. There are still some features to go into the g compilers too, for instance they don't currently use host threads particularly well (specifically, the goroutine scheduler isn't pre-emptive). Beyond that, I don't know Google's plans, whether the g compilers will ever be fiercely optimising, or if only gccgo will. – Steve Jessop Apr 24 '10 at 17:46
  • I disagree with your statements that "Benchmark figures are almost entirely about quality of implementation. They don't have a huge amount to do with the language as such ..." –  Sep 21 '11 at 18:12
  • I thought one of the main features of goroutines (and coroutines in general) was that they are cooperatively scheduled? – xitrium Mar 16 '12 at 17:06
  • 1
    @xitrium: I think the intention for Go is that implementations should not be required to schedule co-operatively, they can pre-empt if they want. See for example https://code.google.com/p/go/issues/detail?id=543, which hasn't been closed as "nonsensical, fixing this so-called bug would contradict the Go language definition", which it should be if Go implementations are forbidden to pre-empt :-) The issue was compounded by the fact that by default Go used only a single host thread no matter how many goroutines were runnable. – Steve Jessop Mar 16 '12 at 18:22
  • 6
    The answer might be a bit outdated as of now. Recently, the first beta of Go 1.1 was [released](http://tip.golang.org/doc/go1.1#performance), they state that performance of compiled programs increases by about 30% to 40%. Somebody please do these tests again. – fuz Apr 04 '13 at 16:06
  • @fuz the benchmarks game measurements have been updated for each Go release. – igouy Mar 05 '19 at 21:12
53

In the next release of the Go FAQ, something similar to the following should appear.

Performance

Why does Go perform badly on benchmark X?

One of Go's design goals is to approach the performance of C for comparable programs, yet on some benchmarks it does quite poorly, including several in test/bench. The slowest depend on libraries for which versions of comparable performance are not available in Go. For instance, pidigits depends on a multi-precision math package, and the C versions, unlike Go's, use GMP (which is written in optimized assembler). Benchmarks that depend on regular expressions (regex-dna, for instance) are essentially comparing Go's stopgap regexp package to mature, highly optimized regular expression libraries like PCRE.

Benchmark games are won by extensive tuning and the Go versions of most of the benchmarks need attention. If you measure comparable C and Go programs (reverse-complement is one example), you'll see the two languages are much closer in raw performance than this suite would indicate.

Still, there is room for improvement. The compilers are good but could be better, many libraries need major performance work, and the garbage collector isn't fast enough yet (even if it were, taking care not to generate unnecessary garbage can have a huge effect).

And here's some more details on The Computer Benchmarks Game from a recent mailing list thread.

Garbage collection and performance in gccgo (1)

Garbage collection and performance in gccgo (2)

It's important to note that the Computer Benchmarks Game is just a game. People with experience in performance measurement and capacity planning carefully match like with like over realistic and actual workloads; they don't play games.

igouy
  • 2,547
  • 17
  • 16
peterSO
  • 158,998
  • 31
  • 281
  • 276
  • 1
    And here some details from that same thread that you have excluded - http://groups.google.com/group/golang-nuts/msg/2e568d2888970308 – igouy Apr 24 '10 at 17:22
  • 3
    It's important to note that "benchmarks are a crock" - not just the benchmarks published as the benchmarks game - http://shootout.alioth.debian.org/flawed-benchmarks.php – igouy Apr 24 '10 at 17:24
  • 18
    (and everybody...) Sure it's a *"game"*, but when I see that Go is *only* two times slower than the fastest on these benchmarks, my first impression is *"wow, Go seems fast"*, because I know these benchmarks are flawed. On the contrary, when I see Ruby being 65 times slower than the fastest, I think to myself *"not gonna use Ruby for my next concurrent-numerically-intensive endeavour"*. So it may be a "game", but there's some truth in it if you take it with a grain of salt. – SyntaxT3rr0r May 13 '11 at 09:02
  • Capacity planning has a very important aspect: cost. Whether you will need X boxes or 2*X makes a huge difference in the end. And since no one can estimate just what is going to run in the future on those, the best bet is to take a look at different workloads. I've checked a few implementations of these and found them to be mostly OK. I think the results can be used as a base for estimations. – Agoston Horvath Apr 07 '16 at 15:11
  • Generally, real world systems are constrained by IO not by CPU. Therefore, whether Go is 2x or 5x is slower hardly makes as much as a difference to capacity planning as failover, load balancing, caching, database topology and the like. This is why apps at the scale of YouTube can afford to run many of their systems in Python. – Sujoy Gupta Sep 22 '16 at 22:00
35

My answer isn't quite as technical as everyone else's, but I think it's still relevant. I saw the same benchmarks on the Computer Benchmarks Game when I decided to start learning Go. But I honestly think all these synthetic benchmarks are pointless in terms of deciding whether Go is fast enough for you.

I had written a message server in Python using Tornado+TornadIO+ZMQ recently, and for my first Go project I decided to rewrite the server in Go. So far, having gotten the server to the same functionality as the Python version, my tests are showing me about 4.7x speed increase in the Go program. Mind you, I have only been coding in Go for maybe a week, and I have been coding in Python for over 5 years.

Go is only going to get faster as they continue to work on it, and I think really it comes down to how it performs in a real world application and not tiny little computational benchmarks. For me, Go apparently resulted in a more efficient program than what I could produce in Python. That is my take on the answer to this question.

Darshan Rivka Whittle
  • 32,989
  • 7
  • 91
  • 109
jdi
  • 90,542
  • 19
  • 167
  • 203
  • 3
    How much slower do you think you will be writing Go code than Python? – Erik Engheim Apr 08 '13 at 09:56
  • 7
    @AdamSmith - I would say I would write Go code more slowly than Python only because I have been coding Python for 7+ years and only a little Go. But in terms of Go versus other statically typed, compiled languages, I wager I would write Go faster than others. Personally, I feel its the closest thing to the simplicity of Python with speed between C and C++ – jdi Apr 09 '13 at 22:01
  • 5
    I have similar story. I just started learning Go, and according to Benchmarks Game, Go is SLOWER than JavaScript V8. Turns out that my program that is binary operations intense runs 10x faster with unoptimised Go code than in highly optimised V8 VM. Go may be slower than C in many operations, however noone is writing websites in C. Go is a perfectly viable option already, and should only get better, as new libraries, frameworks and tools pop up. – if __name__ is None May 30 '13 at 23:37
  • go is not fast enough for any decent project and/or software engineer. it is slow, redundant and the so called easy multi-threaded (go routines) are muddy and generally error prone and cans of worms for any serious project. you do not have to take my words on faith, just write a simple program to generate the very first 200,000 prime numbers in c, c++, java and go, run it and see for yourself. also search on youtube for go presentations, you will see how complicated it is to do real life multi-threading correctly. so, if you budget to waste, "go with it" :-) –  Feb 25 '19 at 03:12
  • 1
    @user962247 this is a crazy and false blanket statement. I've been writing Go for years now and it is blazing fast. No one claims it will beat C/C++/Java on every synthetic benchmark possible. But it wins on some (see the benchmark game site). Take it from someone who has actually been writing production Go code for years. It's fast and productive. – jdi Feb 25 '19 at 06:28
  • 1
    [Your application is the ultimate benchmark](https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#ultimate-benchmark) – igouy Mar 04 '19 at 16:52
  • The question is entirely about typical benchmarks, number generation etc. It is impossible to answer for speed for every use-case known to the world, so a general set of unbiased benchmarks are used to determine this. – Jimbo Feb 17 '20 at 14:42
8

Things have changed.

I think the current correct answer to your question is to contest the notion that go is slow. At the time of your inquiry your judgement was justified, but go has since gained a lot of ground in terms of performance. Now, it's still not as fast as C, but is no where near being 10x slower, in a general sense.

Computer language benchmarks game

At the time of this writing:

source  secs    KB      gz      cpu     cpu load

reverse-complement
1.167x
Go      0.49    88,320  1278    0.84    30% 28% 98% 34%
C gcc   0.42    145,900 812     0.57    0% 26% 20% 100%

pidigits
1.21x
Go      2.10    8,084   603 2.10    0% 100% 1% 1%
C gcc   1.73    1,992   448 1.73    1% 100% 1% 0%

fasta
1.45x
Go      1.97    3,456   1344    5.76    76% 71% 74% 73%
C gcc   1.36    2,800   1993    5.26    96% 97% 100% 97%

regex-dna
1.64x
Go      3.89    369,380 1229    8.29    43% 53% 61% 82%
C gcc   2.43    339,000 2579    5.68    46% 70% 51% 72%

fannkuch-redux
1.72x
Go      15.59   952 900 62.08   100% 100% 100% 100%
C gcc   9.07    1,576   910 35.43   100% 99% 98% 94%

spectral-norm
2x
Go      3.96    2,412   548 15.73   99% 99% 100% 99%
C gcc   1.98    1,776   1139    7.87    99% 99% 100% 99%

n-body
2.27x
Go      21.73   952 1310    21.73   0% 100% 1% 2%
C gcc   9.56    1,000   1490    9.56    1% 100% 1% 1%

k-nucleotide
2.40x
Go      15.48   149,276 1582    54.68   88% 97% 90% 79%
C gcc   6.46    130,076 1500    17.06   51% 37% 89% 88%

mandelbrot
3.19x
Go      5.68    30,756  894 22.56   100% 100% 99% 99%
C gcc   1.78    29,792  911 7.03    100% 99% 99% 98%

Though, it does suffer brutally on the binary tree benchmark:

binary-trees
12.16x
Go      39.88   361,208 688 152.12  96% 95% 96% 96%
C gcc   3.28    156,780 906 10.12   91% 77% 59% 83%
Taavi
  • 135
  • 2
  • 16
tiffon
  • 5,040
  • 25
  • 34
  • 1
    It is now on par with Java, but wasn't Go created explicitly to be faster than Java, while being used for the same things (server side networking apps)? – MWB Jul 21 '17 at 18:04
  • 1
    @MaxB no it was not created with the goal of being faster than Java. It was created with a goal of having good performance, faster compilation than C++, and easier and native concurrency to enable developers to be more productive. Beating the runtime speed of other languages was not a driving factor. – jdi Nov 14 '18 at 17:52
5

Despite the not so good efficiency of Go about the CPU cycles usage, the Go concurrency model is much faster than the thread model in Java, for instance, and can be comparable to C++ thread model.

Note that in the thread-ring benchmark, Go was 16x faster than Java. In the same scenario Go CSP was almost comparable to C++, but using 4x less memory.

The great power of Go language is its concurrency model, Communicating Sequential Processes, CSP, specified by Tony Hoare in 70's, being simple to implement and fit for highly concurrent needs.

DLopes
  • 567
  • 2
  • 6
  • 13
2

There are two basic reasons that that Java is faster than Go and C++, and can be faster than C in many cases:

1) The JIT compiler. It can inline virtual function calls through multiple levels, even with OO classes, based on the runtime profile. This is not possible in a statically compiled language (although the newer re-compilation based on recorded profile can help). This is very important to most benchmarks that involve repetitive algorithms.

2) The GC. GC based memory allocation is nearly free, as compared to malloc. And the 'free' penalty can be amortized across the entire runtime - often skipped because the program terminates before all garbage needs to be collected.

There are hundreds (thousands?) of extremely talented developers making the GC/JVM efficient. Thinking you can "code better than all of them" is a folly. It is a human ego problem at its heart - humans have a hard time accepting that with proper training by talented humans, the computer is going to perform better than the humans that programmed it.

Btw, C++ can be as fast as C if you don't use and of the OO features, but then you are pretty close to just programming in C to begin with.

Most importantly, the "speed differences" in these tests are usually meaningless. The IO costs are orders of magnitude more than the performance differences, and so proper designs that minimize IO costs always win - even in a interpreted language. Very few systems are CPU bound.

As a final note, people refer to the "computer language benchmarks game" as a "scientific measure". The tests are completely flawed, For example, if you view the Java tests for nbody. When I run the tests on the same OS/hardware, I get roughly 7.6 secs for Java, and 4.7 secs for C - which is reasonable - not the 4x slowness the tests reports. It is click-bait, fake news, designed to generate site traffic.

As a final, final note... I ran the tests using Go, and it was 7.9 secs. The fact that when you click on Go, it compares it to Java, and when you click on Java it compares it to C, should be a red flag to any serious engineer.

For a real world comparison of Java, Go, and C++ see https://www.biorxiv.org/content/10.1101/558056v1 spoiler alert, Java comes out on top in raw performance, with Go coming out on top with combined memory use and wall time.

  • wrong. C++ IS as fast as C, especially when you use OOP, that's is his birth certificate pell. more abstraction (as in classes) WITHOUT ANY RUNTIME PERFORMANCE DEGRADATION, WITH ZERO EXTRA BYTES MEMORY. if you do not know that, keep frolicking with java, c#, go, python, et cetera –  Feb 26 '19 at 08:43
  • //Btw, C++ can be as fast as C if you don't use and of the OO //features, but then you are pretty close to just programming in C //to begin with. if you say that, you have very little clue about c++, for your own sake, do not use it. c and c++ hate magic and medieval minds, superstitious in nature, like oh i heard that, read it over the internet, it must be true... stay away from c and c++, they will byte you back my friend (honest advice) –  Feb 26 '19 at 08:44
  • c is the ancestor of c++. many people still use it... c++ is a better c, where you can do more without paying the price. the java, c# and go authors did not get it, well, of course, they did, but what can they do about?!? same about being compatible with existing (c) code. real life oceans of c code! python is a nice toy, enjoy, i wish they got it right, but nah, zen of python should have started with "compiler is your friend"... –  Feb 26 '19 at 08:48
  • >>shows the CPU utilization at 30% for the Java program<< No —— "1% 0% 0% 100%". – igouy Feb 27 '19 at 19:09
  • >> … when you click on Go, it compares it to Java, and when you click on Java it compares it to C… << —— When you click on Go you have the choice of comparison with C++ C# .NET Core Java JavaScript Python —— When you click on Java you have the choice of comparison with C C++ C# .NET Core Substrate VM. – igouy Feb 27 '19 at 19:14
  • >> … not the 4x slowness the tests reports. It is click-bait, fake news, designed to generate site traffic. << The website does not report Java n-body 4x slower than GCC. —— The benchmarks game website does not make money from site traffic. – igouy Feb 27 '19 at 19:23
  • @user962247 you are incorrect here for most C++ programs. Investigate v-table and inlining - you will see that MOST C++, when written in an OO style, is slower than equivalent C (I think the benchmarks games bear this out, and since both are native pre-compiled it is a pretty fair comparison). Your other comments are just non-sensical, and I would suggest further study. –  Mar 02 '19 at 21:30
  • @igouy They have since changed the CPU utilization. Still all of the tests are pretty much CPU bound, but almost none are near 100% - they are flawed... You can compare to others, I was referring to the default comparisons. The author is not anonymous - they derive economic benefit in other ways. –  Mar 02 '19 at 21:38
  • really robert?!? vtables are arrays of pointers to (member) functions, also called VMT. my examples have NOTHING to do with vtables –  Mar 03 '19 at 22:05
  • robert, it is useless to continue this talk, engineer here, you probably are a manger or something. unless member functions are virtual, which in c++ is not mandatory, the extra memory and runtime performance degradation comming from c++ oop is ZERO. this is not the case with go, java, scala, kotlin, c# and other high level aberations for invoice flipping coders. –  Mar 03 '19 at 22:08
  • @robert, this has nothing to do with inlining, what do you do for a living, managing it shops working for banks or medical establishment?!? if a class has at least one virtual member function, then vmt(s) are engaged, which means an extra indirection, instead of having the address of a method as a compile time (constant) fact, at run time, your read it from a super fast O(1) lookup table, you call it v-table, in c++ is called virtual method table. this is the only difference. the zero overhead principle is well known in the civilized / technical world, when people use source instead of news –  Mar 03 '19 at 22:14
  • >> The author is not anonymous - they derive economic benefit in other ways. << For example? – igouy Mar 04 '19 at 16:58
  • >> but almost none are near 100% << Robert, you refer specifically to the sequential nbody program and that shows one-core [maxed-out at 100%](https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/java.html). What you wrote is **demonstrably untrue** — perhaps the most charitable explanation is that you saw something like `35% 2% 66% 1%` and did not understand the program was bouncing between 4 cores. – igouy Mar 04 '19 at 17:51
  • @user982650 You are incorrect. If you use OOP in C++, with dynamic polymorphism, not templates, you will have a vtable - which is an extra indirection on every function call. Java with dynamic inlining avoids this indirection when making the call. You should read more about the JIT. –  Mar 04 '19 at 23:55
  • @igouy economic benefit can be as simple as 'name recognition' when applyingfor work, research grants, etc. –  Mar 04 '19 at 23:57
  • 1
    @igouy I concede that that is an error I probably made - when I saw load, I was interpreting in 'system load' terms, and assuming, user/system/io/idle - my mistake, and it was a substantial one. –  Mar 04 '19 at 23:58
  • Also, as to why they are flawed - see the description under binary trees: "Use default GC, use per node allocation or use a library memory pool." So, the top-performing C++ uses a custom memory pool (see the source), but you can't tailor the GC to the task at hand (and the Java just uses standard allocations) - completely flawed - I can probably tailor the GC a lot faster than a developer can write the custom memory pool. They don't show a C++ version that uses malloc/free or standard allocators/de-allocators for every node - they're not comparing apples to apples. –  Mar 05 '19 at 00:13
  • @user9826550 and if these tests are valid, and C++ is as fast as C, why does C beat C++ for every test ? –  Mar 05 '19 at 00:20
  • One last comment, as other answers have pointed out, even if "the game" was accurate, the most important performance factor is limiting IO, and so the better design (usually obtained via refactoring) will win out - so the languages that are the most maintainable probably deliver the most performant real world solutions in the end. Properly written micro-benchmarks for a particular solution have value - these "games" do not. –  Mar 05 '19 at 00:32
  • >> an error I probably made << Please correct your post. – igouy Mar 05 '19 at 18:39
  • >> They don't show a C++ version that uses malloc/free or standard allocators/de-allocators for every node << [C++](https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gpp-2.html) & [C malloc](https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-1.html) & [C malloc](https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-5.html) – igouy Mar 05 '19 at 18:52
  • >> *It is click-bait, fake news, designed to generate site traffic — The author is not anonymous - they derive economic benefit in other ways. — economic benefit can be as simple as 'name recognition' when applyingfor work, research grants, etc.* << **Ad hominem** – igouy Mar 05 '19 at 20:58
  • @igouy I edited the post, the cpu utilization was not relevant anyway. Also I added a link to real world tests that are a much better indicator of the performance profiles IMO. –  Mar 06 '19 at 13:28
  • @igouy I meant the top performing ones that are shown in comparison to Java don’t use standard allocators. That there are other implementations available matter little in the click-bait headline oriented world. If you review those you will see that they are many times slower, while Java version is much faster than those and does nothing special. –  Mar 06 '19 at 13:31
  • You can't edit comments after 5 minutes... anyone that read this chain I hope understands that. –  Mar 06 '19 at 23:49
  • compared to c, c++ offers higher level abstraction, more type safeness and more programming paradigms (oop, generic, concepts) at ZERO OVERHEAD. it is totally inaccurate to say "c++ is as fast as c, unless you use oop". c++ is as fast as c (this is what ZERO stands for) regardless on what you do with it. this is NOT the case with Go (because of garbage collector). this is also true with RUST. just to let you know. – Dan Marinescu Sep 23 '19 at 21:29
  • also, java is NOT faster (not even comparable with) c++. period. the quality of stack based code (vs registered) is inferior. no matter what you and other blue collar java developers think (git, etc). java (and any other vm related language) is slower because of unacceptable garbage collection, which is: 1. completely unnecessary, see RAII, being unable to deal with type unsafe circular references && 2. slow and nondeterministic. – Dan Marinescu Sep 23 '19 at 21:38
1

I think an often overlooked fact is, that JIT compilation can be > static compilation especially for (runtime) late bound functions or methods. The hotspot JIT decides at RUNTIME which methods to inline, it even might adjust data layout to the cache size/architecture of the CPU it is currently running on. C/C++ in general can make up (and overall will still perform better) by having direct access to the hardware. For Go things might look different as its more high-level compared to C, but currently lacks a runtime optimization system/compiler. My gut tells me, Go could be faster then Java as Go does not enforce pointer chasing that much and encourages better data structure locality + requires less allocation.

R.Moeller
  • 3,436
  • 1
  • 17
  • 12
1

As a matter of fact, Go is not only elegant and efficient at design time, but also super performant at run-time. The key is to use the right operating system i.e. LINUX. Performance profiling result under Windows and Mac OS are, for lack of a better word, one or two orders of magnitude inferior.

Rishabh Agarwal
  • 1,988
  • 1
  • 16
  • 33
Dan Marinescu
  • 111
  • 5
0

under linux, the go runtime is super fast, perfectly comparable with c/c++. the go runtime under windows and unix are not in the same league

comparison with java is not so important, go is for both system and application development (as java is more like blue collar for application development only). will not enter in details, but when things like kubernetes are written in go, you realize that is not an enterprise consultant friendly toy

i do not remember google mentioning even once about the compromise you refer to. go is well design, simple, elegant and efficient for for designing system and application level programs, has pointers, efficient memory allocation and deallocation, avoids complications arising from oh so easy to miss-use implementation inheritance, giving you co-routines and other modern ways to write high performance applications in time and budget. again, go is super fast under linux, which is exactly what it was designed for (very happy that it does)

Dan Marinescu
  • 111
  • 5
-4

Both Java and C are more explicit with their data and method (function) definitions. C is statically typed, and Java is less so with its inheritance model. This means that the way the data will be handled is pretty much defined during the compilation.

Go is more implicit with its data and function definitions. The built in functions are more general in nature, and the lack of a type hierarchy (like Java or C++) gives Go a speed disadvantage.

Keep in mind that Google's goal for the Go language is to have an acceptable compromise between speed of execution and speed of coding. I think they are hitting a good sweet spot on their early attempt, and things will only improve as more work is done.

If you compare Go with more dynamically typed languages whose main advantage is speed of coding, you will see the execution speed advantage of Go. Go is 8 times faster than perl, and 6 times faster than Ruby 1.9 and Python 3 on those benchmarks you used.

Anyway the better question to ask is Go a good compromise in ease of programming versus speed of execution? My answer being yes and it should get better.

Bill C
  • 43
  • 2
  • 20
    "lack of a type hierarchy (like Java or C++) gives Go a speed disadvantage" —wut? – Erik Kaplun Feb 20 '13 at 01:47
  • 6
    "Go is more implicit with its data and function definitions." Incorrect. Do you mean how types can implement methods without being explict about it? The compiler detects type - interface membership. This is fast. "The built in functions are more general in nature" no, the builtins are, like everything else, compiled. Same thing happens with C++ templates. "the lack of a type hierarchy (like Java or C++) gives Go a speed disadvantage" -- incorrect, a type hierarchy has nothing to do with runtime execution. – Malcolm Nov 07 '13 at 14:48