On comparing languages, C++ and Go

http://blog.grok.se/2013/10/on-comparing-languages-c-and-go/

by abelsson • 13 years ago

126 127 13 years ago

blog.grok.se

tptacek4• 13 years ago

I've been following this whole business card raytracer story and wonder if people might be missing the forest for the trees.

It would be a little nutty to suggest that Golang 1.1 is going to give optimized C code a run for its money. Nobody could seriously be suggesting that.

What is surprising is that the naive expression of an "interesting" compute-bound program in both languages are as close as they are.

Most C/C++ code --- the overwhelming majority, in fact --- is not especially performance sensitive. It often happens to have performance and memory footprint demands that exceed the capabilities of naive Python, but that fit squarely into the capabilities of naive C.

The expectation of many C programmers, myself included, is that there'd still be marked difference between Go and C for this kind of code. But it appears that there may not be.

This doesn't suggest that I'd want to try to fit Golang into a kernel module and write a driver with it, but it does further suggest that maybe I'd be a little silly to write my next "must be faster than Python" program in C.

noelwelsh2• 13 years ago

Ray-tracing, especially the simple kind in this example, is all about vector maths. CPUs are extremely good at this type of task. Finding Go performs well at this shouldn't be surprising. Any decent compiler will be able to produce good code for this task as it maps very closely to what CPUs do best, meaning you don't need much fancy analysis.

I think the majority of languages in popular use are faster than Python. I believe that Go is popular with the Python / Ruby crowd because idiomatic Go is quite close to what they do already. I.e. you don't need to learn much to shift from Python or Ruby to Go. Using a language like Scala, for instance, is a much bigger jump.

kid0m4n3• 13 years ago

Actually, looking deeply at Go from a performance perspective (as I have been, the last couple of days) has revealed a bunch of low hanging fruits/missed optimization opportunities in the Go compiler. That was 50 % the intent of the grand father blog post

corresation8• 13 years ago

Finding Go performs well at this shouldn't be surprising.

Go doesn't do SIMD at all (see note 1). Personally I leverage Go coupled with the Intel Compiler (Go happily links with and uses very high performance C-built libraries, where I'm rocking out with SSE3 / AVX / AVX2).

To respond to something that Ptacek said above, many of us do expect Go to achieve C-level performance eventually. There is nothing stopping the Go compiler from using SIMD and automatic vectorization, it just doesn't yet. There is nothing about the language that prohibits it from a very high level of optimization, and indeed the language is generally sparse in a manner that allows for those optimizations.

*1 - For performance critical code you are supposed to use gccgo, which uses the same intermediary as the C compiler, allowing it to do all of the vectorization and the like. Unfortunately for this specific code gccgo generates terrible code, yielding a runtime that is magnitudes slower (albeit absolutely tiny). Haven't looked into why that is.

plorkyeran• 13 years ago

It would be a little nutty to suggest that Golang 1.1 is going to give optimized C code a run for its money. Nobody could seriously be suggesting that.

AFAICT, the entire situation started only because the article was submitted to /r/Golang and /r/C++ with the trollbait title "Business Card Ray Tracer: Go faster than C++", and not because of anything in the article itself (which was actually a pretty good article).

frozenport4• 13 years ago

I don't think its nutty at all. Ideally the language shouldn't be tied to performance - the compiler and optimizer will do it. His method of optimization hints that the compiler is still immature.

From another angle, consider that in HPC FORTRAN codes will often get the best performance - and FORTRAN doesn't have real pointers.

npalli3• 13 years ago

That's interesting. I had the opposite reaction regarding Golang capabilities while following this saga. Not sure how 'idiomatic' the Golang code is, at first glance it just seems less expressive (more lines of code) than either c++ or java!. I didn't think that was possible.

So whenever people talk about expressiveness of Golang it just seems like a design gone bad. The designers wanted a programming language with the expressiveness of python and the speed of C, they ended up with a language with the expressiveness of C and the speed of python.

pbsd3• 13 years ago

I agree, I honestly don't see where the expressiveness claims of Go come from. I've always put it in the Java-like bin of languages (which is not necessarily a bad thing).

I suppose the one thing that Go does well (compared to C++ or Java) is builtin concurrency and communication across tasks.

myg204• 13 years ago

A lot of the verbosity in Go comes from error handling; the language forces you to deal with errors (I think it's a good thing, some may disagree). Expressiveness is real, 'duck typing' does give it a feel of scripting language like Python, and it is way less verbose than Java (apart from error handling). And to be fair, Go is faster than Python (the numbers tell you that), and (slightly?) more expressive than C --and just in a league of its own for concurrency.

kkowalczyk• 13 years ago

You're empirically wrong.

I actually did write a fair amount of Go code (my primary languages are C++ and Python).

On real, non-toy programs it is significantly more concise than C++, in the ballpark of Python code.

This isn't visible on code snippets (less than 500 loc) like the toy raytracer, but trust me: you'll see a big difference on 10k loc codebase.

nly2• 13 years ago

I think the reason both versions lack conciseness is because they're faithful translations of one another. I wouldn't call either well structured, but maybe that's because I don't understand the problem domain well enough. T() in the C++ versions especially looks awful.

corresation8• 13 years ago

To concur with what kkowalczyk, there is little expressiveness advantages to be gained for this specific example -- math is math, and outside of compressing it down to a couple of library calls, what could possibly be done better?

"they ended up with a language with the expressiveness of C and the speed of python."

This is just pure troll. Apparently you have a Python variant of this renderer that matches the already impressive Go performance? Please reveal it.

cgag2• 13 years ago

I'm not sure if it's because the JVM has a bad rep or people like the familiar feeling of Go (smaller learning curve) or some other reason, but it surprises me so many people jump to Go for performance similar to what you'd get on a modern JVM language (Clojure, Scala), but with less expressiveness, fewer libraries, and (I believe) less tooling.

Of course this only really applies to long running apps (web servers), if startup time matters then certainly Go wins.

Perhaps I need to try Go out, but I just don't see what the selling point is.

bluecalm• 13 years ago

C++ code is 5x faster after some standard optimizations so it's not really the same league. Faster than Python for sure but still unusable for anything CPU bound is the message I get from all of this.

This doesn't show anything new though, programming math/graphics is perfect use for C/C++ and you won't really benefit from anything Go has to offer and some of its features actually become annoyance for this kind of application. The biggest strength of of Go doesn't really really shine either as simple parallelism needed for ray tracer is matter of few lines of code in both C and C++.

corresation8• 13 years ago

C++ code is 5x faster after some standard optimizations

There is nothing standard about the optimizations -- direct AVX use is enormously uncommon, even among extremely high performance code.

samth2• 13 years ago

There have been languages in this space for a very long time. Pascal and Algol 68 are both very old examples (see the Go vs Brand X comparison). Then there's Modula or Oberon not quite as long ago. In the last 20 years, everything from Java to OCaml to Scala to C# to F# to Haskell to Common Lisp to Lua have been developed.

So it's not especially interesting that Go is in this space as well. The most surprising thing about Go is that its developers seem never to have heard of any of the above languages (with the exception of Java).

tptacek4• 13 years ago

I don't think it's interesting that Go has this combination of attributes. I think it's interesting that the "right" boring systems programming language got a degree of tooling and traction sufficient to make it, unlike Modula and Oberon, a viable mainstream choice.

I am fine with boring languages. The first language love of my life is C. It's hard to get more boring than C. If a system I build is going to be clever or sophisticated, I'm fine with that being expressed in my code, rather than as the product of the environment I happen to be working in.

icambron• 13 years ago

Personally, I’m hoping for Rust.

That was my thought while reading article; Rust seems like the answer here. I'm coming from the opposite direction than the OP: I'm unwilling to give up the expressiveness of Ruby and friends in order to write micro-optimized C++ code, and I'm hoping Rust will give me the best of both worlds.

evincarofautumn2• 13 years ago

Yeah, everyone’s got their eye on Rust as far as low-level expressive programming goes. Nimrod[1] also looks quite good:

Nimrod is a statically typed, imperative programming language that tries to give the programmer ultimate power without compromises on runtime efficiency.

In my spare time, I’m working on a statically typed concatenative language called Kitten[2] with similar goals.

[1] http://nimrod-code.org/

[2] http://github.com/evincarofautumn/kitten

Dewie2• 13 years ago

Does Kitten also try to not make (too many) compromises on runtime efficiency?

flogic• 13 years ago

Even for non performance critical code, Rust is looking like it'll be a winner.

yoklov• 13 years ago

Speaking as a C++ programmer, Rust appeals to me a great deal over Nimrod because you can turn off (or just not use) Rust's GC and still have memory-safe code.

I believe you can turn off Nimrods GC as well, but you lose any guarantee of memory safety when you do. Not to mention -- aren't all pointers in Nimrod reference counted? That's going to take a fairly significant performance toll due to cache effects alone.

abelsson4• 13 years ago

It feels like a very modern language overall, I particularly like the memory management ideas. It's refreshing to see something which tries to find a middle ground between error prone manual handling and unpredictable GC. Now someone just needs to write a good Rust IDE.

steveklabnik• 13 years ago

There was actually some work done over the summer with... DWARF? So that Eclipse can use its debugger on Rust code. I'm on mobile or I'd find you a link.

corresation8• 13 years ago

Rust seems like the answer here.

How so? To me the callout to Rust diminished the entire article because it made it almost anti-Go for no particular reason (ala "Go is poopy anyways, but maybe [some other unproven option] will be the savior]". This same sort of nonsense occurred with the statement "on my not-very-fast-at-all Core i3-2100T" regarding the C++ performance, which is just narrative nonsense given that the same circa-2012, AVX-equipped processor was what yielded his Go numbers).

The author demonstrated C code that was 2x faster than Go code run through the standard Gc chain, when the C code is run through a very mature, hyper-optimized C compiler, which is actually really impressively good for Go. They then try to pound home the point by inlining AVX which is absolutely ridiculous for such a language comparison. It borders on pure troll, and I'm really surprised that so many people are falling for this.

theatrus2• 13 years ago

Both Rust and C/C++ sit squarely in the "no GC" or "optional GC" camp, which has very important implications for certain applications which strongly favor that compared to a generalized system-wide GC.

Dewie2• 13 years ago

How so? To me the callout to Rust diminished the entire article because it made it almost anti-Go for no particular reason

It might seem that way if Go and Rust were competitors, but given that they seem to have pretty different philosophies and goals, that doesn't seem to be the case.

qznc• 13 years ago

Rust has a great approach to safe regions. That's a hard problem, and Rust has had to expend a considerable amount of firepower on it (four kinds of pointers etc). D does not offer safe regions; I believe the language design precludes that without at least an amount of discipline. So Rust is better than D at safe regions. However, like in chess, good language design is to not sacrifice the whole for the beauty of the part. I think D is better than Rust at a lot of other things, because it has firepower it can afford to expend at problems that are also hard, and just as important.

http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_o...

AYBABTME• 13 years ago

I think all there's to get from these posts is that:

Presumption: Writing Go code is more fun than C++ code.

Demonstration: You can write performance Go code that's not too far from C++ code.

Result: Cool, here's a more fun than C++ language I can use as a step down the complexity path when I need performance.

Or like tptacek said.

kybernetyk• 13 years ago

Fun is really very subjective.

kid0m4n3• 13 years ago

One correction:

Presumption: Writing correct Go code is more fun that C++

tinco• 13 years ago

Ofcourse, if you want your site to be up when it has 25 upvotes on hacker news, it's best not to worry if your web application is written in C++, Go or in Ruby (or sadly but likely, PHP), but that it doesn't actually have to spawn hundreds of processes and hundreds of connections and allocate hundreds of megs of ram to accomodate your visitors.

So, please just use nginx to host some static html files for your blog, and fetch your discussion boards asynchronously..

kid0m4n3• 13 years ago

Yep. Octopress really helps with that

corresation8• 13 years ago

So, please just use nginx to host some static html files for your blog

Wordpress + W3 Total Cache can handle a hundred HNs with ease. There is absolutely no reason to go to the past, and poorly configured blogs don't justify that Luddite argument.

frozenport4• 13 years ago

Leave Britney alone!

I don't see why people feel that C++ needs to be replaced, when I write C++ I have many levels of scope - and while dangerous it is not impossible and the empowerment makes me feel like a god.

Programming is not incremental. If we spend all day writing a python back-end and when it doesn't give the performance numbers that day was a complete waste. When I think about C++ I know that a code written in C++ will take me 100% of the way - even if it takes longer to write.

betterunix3• 13 years ago

"I don't see why people feel that C++ needs to be replaced"

Here are some of my reasons:

1. It is impossible to write high-level code without dealing with (and often getting bogged-down by) low-level issues in C++. Why should I be forced to choose between different "smart" pointer types? Why should I be forced to decide how variables should be captured by a lexical closure? Sure, such decisions might make sense when you want to squeeze out a constant-factor improvement in performance, but they do nothing to help you get things done in the first place.

2. Error handling and recovery is needlessly and pointlessly complicated. You can throw exceptions, except for the places where you cannot, and once caught you there is not much you can do to fix the problem. It is so bad that the C++ standard library actually requires certain errors to not be reported at all.

3. Extending the language is impractical. Look at what it took just to add a simple feature, lexical closures, to the language: modifications to the compiler. At best C++ gives you operator overloading, but you do not even have the ability to define new operators. Lisp, Scala, and numerous other high-level languages give programmers the ability to add new syntax and new features to the language without having to rewrite the compiler.

I am not familiar enough with Go to say that it addresses any of this, but I know why I stopped using C++ and why I have not regretted that decision. All the above make writing reliable code difficult. I actually switched away from C++ when I needed my code to scale better, because improving the scalability required a high-level approach and I did not have time to debug low-level problems. Even C++ gurus wind up having to deal with dangling pointers, buffer overflows, and other needless problems with their code -- that takes time and mental effort away from important things in most cases.

"When I think about C++ I know that a code written in C++ will take me 100% of the way - even if it takes longer to write."

The same is true of any programming language if the amount of time spent on the program is irrelevant. I am not sure what sort of work you do, but for what I have been working on, getting things done is considered higher-priority than squeezing out a constant factor improvement. Nobody complains about faster code, but everyone complains about late, buggy, and incomplete code.

chetanahuja2• 13 years ago

"The same is true of any programming language if the amount of time spent on the program is irrelevant."

No it's not. That's what the original post was arguing (I think successfully).

lttlrck• 13 years ago

C++ does not force you to use smart pointers.

nly2• 13 years ago

-- Why should I be forced to choose between different "smart" pointer types

If you don't want to decide then write all your types with value semantics and pass by value. How types are going to behave when passed should be decided before you write 'class{}'. It's a semantic decision. For types that you're borrowing, and not writing yourself, pass a shared_ptr or refer to the documentation.

-- Why should I be forced to decide how variables should be captured by a lexical closure?

Same thing applies. Auto capture[=] everything by value. If you're type doesn't have any (sane) value semantics, use a shared_ptr or a reference.

-- You can throw exceptions, except for the places where you cannot, and once caught you there is not much you can do to fix the problem.

You can throw an exception anywhere safely in correct code. The default assumption in the language is "anything can throw, any time, anywhere", so if your code doesn't at least provide the basic or weak exception guarantee you're swimming against the tide. Doing so usually improves the encapsulation and structure of code imo anyway.

-- once caught you there is not much you can do to fix the problem.

Exceptions are more like hardware exceptions or page faults than typical error states. You should only throw when you cannot reach a state expected by the caller. Ultimately, it comes down to API design, not philosophy.

    // Clearly the only sane thing to do here if you 
       can't stat() the file is throw an exception.
    size_t get_file_size(string filename);

    // Some flexibility. Could probably avoid throwing. 
    optional<size_t> get_file_size(string filename);

    // Better still, and easy to overload with the above
    optional<size_t> get_file_size(string filename, error_code&);

... the better your API the better you can avoid having to throw. This isn't a new problem either, if you look at the C standard library there are many deprecated functions that provide no means of reporting an error at all except to return undefined results.

-- extending the language is impractical.

Writing STL-like generic algorithms is trivial. Writing new data structures is trivial. Existing operators can be overloaded to augment scalar types or, more ambitiously, re-purposed to create DSLs. You have user-defined literals. Initializer lists and uniform intialization.

How would you like to extend further without it being completely alien to the existing language?

-- I actually switched away from C++ when I needed my code to scale better, because improving the scalability required a high-level approach and I did not have time to debug low-level problems

You should write more about this.

-- C++ gurus wind up having to deal with dangling pointers, buffer overflows, and other needless problems with their code

Not really bad pointers and buffer overflows these days. More slogging through pages and pages of compiler errors and hunting for library solutions to problems that should really be solved in the standard library (For me lately: ranges, matrices, more complex containers).

In any case, all languages have their share of friction. Look at that new Bitcoin daemon written in Go that hit the front page a few hours ago. The author had to debug 3 separate Go garbage collector issues.

PeterisP• 13 years ago

If a python back-end doesn't give the performance numbers, then you find the bottleneck and write that 1% of code in C++. Tada - you get the performance anyway, but gain in development speed (which often is more valuable than the cheap processors).

Jayschwa• 13 years ago

If you want to "poke at the processor" with Go, its toolchain makes it pretty easy to use assembly in your package.

pbsd3• 13 years ago

Go uses an assembly syntax completely different from everyone else. That's mighty annoying.

RamiK3• 13 years ago

Ha? Doesn't it work through the 'import "C"' and then it's just regular C?

corresation8• 13 years ago

You can use C files and GCC syntax in your Go project. Go will use Cgo and compile it with GCC.

_ak• 13 years ago

Where "everyone else" is at least two different syntaxes in the first place, Intel and AT&T.

frozenport4• 13 years ago

C++ does it automatically, I think this is a call for Google to spend some more time optimizing floating point workloads.

zxcdw• 13 years ago

The article doesn't mention reasoning for using -O2 instead of -O3 or -Ofast. It seems that they give better performance in this case, as does adding -funroll-all-loops(when combined with -Ofast gives almost 10 % speedup). I am compiling with GCC 4.8.1, so perhaps authors 4.6.3 (what?) behaves differently.

eonil• 13 years ago

I don't think ray-tracer is a good example for Go.

Ray-tracer workload can be fully split into each hardware core. Only input data needs to be shared, and even the input mostly doesn't make any race condition. The algorithm even can run on GPU.

This is handicap for Go. Go wants to solve - safe and easy concurrency without race condition for complex logic. So (IMO,) Go needs to make some overhead (or sacrifice some performance feature) for its goal. But in ray-tracer example, this ability mostly not required.

z3phyr• 13 years ago

C++ cant be so easily replaced by Rust, even though rust seems to be a better language. The more possible case is that Rust's great ideas get ported into C++NewX standard. Even if Rust is to be our new systems labguage, we will have to wait for 12-15 years for it to actually happen.

pjmlp6• 13 years ago

"On comparing languages, gcc vs 6g"

Yet again the fallacy that comparing implementations equals to comparing languages.

On the left corner the 6g compiler toolchain, which the authors admit that has yet to suffer lots of improvements in the optimizer.

On the right corner, the battle tested gcc optimizer, with circa 30 years of investment, aided by language extensions not part of any ANSI/ISO standard, that are not language specific.

Of course "C++" wins.

People, just spend time learning about compiler design instead of posting such benchmarks. And before someone accuses me of Go fanboy, I think my complaints about Go's design are well known by some here.

On comparing languages, C++ and Go

Related Stories