Surprising result while transpiling C to Go
blog.nobugware.com
blog.nobugware.com
I think too many here read the story as some kind of competition between Go and C, when it should be more read as how well the conversion process went. For anyone interested in going down this route, surely this is useful information.
We don’t have unlimited time in this industry and thus if something like this can be done with minimal effort while retaining expected performance , then I would say that we s a good thing.
Stop nitpicking as if the author tried to have final word on which language is faster.
> A lot of snarky and petty comments here I must say.
"Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community." https://news.ycombinator.com/newsguidelines.html
First I did not post it here, the intent was to promote ccgo to the Go community.
I did recreate geoToH3 using the transpiled code and it is outperforming the helper tool provided by the C version see https://github.com/akhenakh/h3-bench/blob/main/cmd/geoToH3/m....
I hoped it was clear in the blog post: this is a very specific case where I only needed to convert coordinates to h3 index, with this specific goal this transpiled version outperform the cgo version.
The comment "probably due to Go runtime scaling on multiple cores" was me still seeing very close performance with GOMAXPROCS set to 1, but observing the process behaving differently than the pure C version. The fact it was not thread safe has been discussed already on Reddit and is not relevant nor an issue when used in a batch scenario like this.
ccgo is awesome, but feel free to discuss something else ;)
Would be interesting to see how (horrifically?) the garbage collector would fare in performance once it's transpiled to a garbage collected language like Go.
It would be fun to see Go with a terser syntax, better type inference, nicer error handling, etc.
I agree that everything Haskell does would be hard, but everything e.g. Clojure does should be possible
I'm always taken aback by "why bother" questions when it comes to hacking.
I say this as someone who loves F#.
Common Lisp stuff like LispWorks and Allegro, run the installer, done.
Why are you compiling F# AOT to binary all the time?
I'm not saying there's nothing left - channels, maybe the standard library. But putting a Lisp on top of Go feels like going strongly against the grain.
I know many don’t feel that way, but functional stream manipulation is a very good example for that — I much rather deal with filter.map.reduce whatever, than 3 nested for loops with random breaks inside, even though the latter may be easier to reason about line-by-line
That is one selling point. Another is that it's a GC'd language that compiles to native on all major platforms, and is more popular than the alternatives, like OCaml, Haskell, D, Common Lisp. Just like Java was used as a platform on which to build languages, like Groovy, Scala, Clojure and Kotlin t otake only the most popular.
And network applications can be written without relying on async.
JVM: 'bloated' or at least the perception of it. Now improving quite fast but also Oracle.
Dot net: still Microsoft.
C/C++: Not similarly high level languages
Scripting languages: lol slow.
Turns out Go ecosystem isn't that tiny at all. Yeah java is larger but also comes with a bad perception among other programming language users. So after Java, if you're targetting a general purpose audience, it's Go I think.
(Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?)
Not this ignorant myth again - it isn’t a new word, been in use since mid 60s. A transpiler is a form of compiler from high-level language to high-level language. A compiler didn't even originally translate, but just link.
The same way ‘navy’ is a kind of blue but we can say navy and add a little more specific information. Nobody rails against navy saying ‘but it’s just a shade of blue!’
> Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?
The answer is... the old word ('compiler') didn't mean what it does today, back in the 60s, when 'transpiler' was coined. Compiler with its current meaning isn't a much older word than transpiler - they're near contemporaries (50s and 60s). Before that a compiler meant a linker.
Your criticism doesn't match up with the history.
Of course, if we had more rational vocabulary, we'd call them 'translators' instead. (In fact, that's what German does. Perhaps they coined their corresponding term a bit later, when things had already shaken out a bit more.)
The word “compiler” actually doesn’t do that (like, say, “translator” would). “Compiler” originally referred to something more like what is today called a linker. It “compiled” (put together) a set of subroutines (in assembly/machine code) into a combined executable.
Furthermore, translating from (say) JSON to XML is also “translating from one formal language into another”, but that’s not an example of what we mean by “compiler”.
So what do we mean? That’s actually not easy to define. Defining it as translating from one programming language into a different programming language isn’t quite correct, because machine-code binaries aren’t a programming language. Defining it as translating from a programming language into a different representation preserving the program semantics is also not quite correct, because e.g. pretty-printing to HTML would arguably fit that definition.
Clearly there’s some general definition of what we mean by “compiler”, even if I’m failing to find a precise and correct wording for it here. But there’s also the more narrow meaning of “translating from a programming language into object code”, which is what is usually meant in the majority of cases. Because we don’t have a separate word for that narrower definition, there is some ambiguity. The word “transpiler” resolves the ambiguity in one direction. In the other direction, the ambiguity is usually resolved by assuming that “compiler” means “to object code” by default when the context doesn’t specify otherwise.
Machine-code binaries aren't (they are programs), but ISA of a CPU is.
I'd plug in a requirement of Turing-completeness for the source and destination language, and at that point the "semantics-preserving" variant makes perfect sense to me. Although canonically textbooks and Wikipedia don't seem to require that, so I'm fine accepting a definition not requiring Turing-completeness, just preservation of semantics.
Perhaps the most practical example: just-in-time compilation of regular expressions to native code via LLVM. Regular expressions are not Turing complete.
Another example: take Agda as a source language. Agda is deliberately not Turing-complete, but can express almost any program you might be interested in. (Basically, Agda only allows you to express terminating programs. That's why it's not Turing complete.)
I'd be perfectly happy to describe that as a compiler.
I don't think anyone would say Unity's il2cpp is a transpiler even though it compiles .net bytecode into C++: producing readable C++ is a non-goal for il2cpp.
The fact that Go has a nice compiler doesn't really help, because the code generated by the functional compiler will have usage patterns that are very different from what the Go compiler is designed around.
I have a large C codebase for an embedded device, and I've often thought about the work involved in one day porting it to Embedded Linux with a higher level & safer language.
This kind of tool is a game changer.
Go also let's you hand-write assembly and link it in, usually for performance reasons, which very much lacks safety guarantees, but has proven to be incredibly useful for optimizing hot code paths.
> The reference hardware platform is the PC Engines™ apu2c4 system board. It features a 1 GHz quad core amd64 CPU, 4 GB of RAM, 3 Ethernet ports and a DB9 serial port.
And BTW, my reply was mostly because of the context: people were talking about binary sizes for Go, but if you're using PC-like hardware you wouldn't care about binary sizes anyway (you can simply put more storage, even something like a 1GB SD Card would be way bigger than something like OpenWRT that can run with hardware as low as 8MB of Flash memory).
> The result library is often slower than pure C (~2x magnitude) but still having a native Go port could simplify some aspects of the workflow like testing.
Agreed if it's gonna double the time spent per unit of work, compromise. Do not care about the architect's pretty picture, he's not solving clients' problem, you are.
Difficulty testing also creates a higher barrier to adding new features. If you can't test something, it reduces confidence that your change won't break it.
If it's an extremely performance-sensitive component, then you'd obviously want to be very cautious about big changes. However, that's usually not the case.
The C version calls latLngToCell() and the Go version calls FromGeo().
What an amazing tool that can completely change function names when it converts from C to Go.
> probably due to Go runtime scaling on multiple cores.
I'm sure that's it... on a single-threaded microbenchmark not running the same code.
"The analysis appears to be flawed. The C code and Go code ultimately call different functions, making performance comparisons unreliable at best. Furthermore, the code is single-threaded and will not benefit from 'Go runtime scaling on multiple cores.'"
I’m not surprised this is a 90% perf gain. The issue is not initialising the libc.
How can one read the code of the benchmark, then switch into virulent sarcasm mode without trying to understand the code? And seeing "+1" comments without any effort to understand is also disheartening.
The blog post had a link about the Go helper functions the author used. It lands on https://github.com/akhenakh/goh3/blob/main/h3.go This shows that the `FromGeo()` function used by the Go benchmark is a helper that calls transpiled functions. The benchmark code itself was of course not transpiled, so the sarcasm was unneeded and wrong.
If anyone wants to dig in deeper, the C function `latLngToCell()` calls 2 functions, see https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index... The Go function `XgeoToH3()` allocates a TLS then calls the same functions, see https://github.com/akhenakh/goh3/blob/main/ch3/a_linux_amd64...
The C and Go code may not be strictly identical, but they seem pretty close. Enough to suppose the blog post was sincere.
I believe the right thing to do is to ask the author why they used a custom rewrite of `latLngToCell()` in Go instead of calling the transpiled function.
And when author 'batches' the thread local storage he changes the code from thread-safe (C version) to not thread safe. The transpiled code is littered with TLS alloc and free calls to emulate stack variables that must be matched in order and that use the heap for temporary storage rather than the stack, with different cache access patterns that can very much affect tiny benchmarks. Contrary to what the author supposed about the performance, the fast Go version can't even be run over multiple threads.
This is analogous to converting locks to NOPs and improving performance on a single-threaded microbenchmark, but doing so isn't an appropriate comparison even though the code may look identical except for one or two lines.
It's a real drawback to this transpiler that it takes thread-safe, purely functional code and turns it into code with side effects that have to be carefully managed. Probably due to Go not having a fixed in place stack guarantee.
Look ultimately what we have is a C version and cgo version that are roughly the same speed and a transpiled version that is 1/6th the speed - and the caller can be in any thread in any of those. Then there's a different API where the caller has to manage storage that's on par with the first two, but that's not the same thing. If you jump through these hoops you can be on par is a different claim from what the blog author made.
Now it's possible that the wrapper functions could be made fast by storing the TLS object in a Go thread local storage so the API is the same, but the author didn't do this.
Since go deliberately fully hides the os threads, this TLS emulation would be per green thread (per go-routine).
I don't see why the go code could not spin up say N goroutines, each one with one NewBatch() call to initialize the simulated TLS for that green thread, followed by repeatedly calling XgeoToH3() (which should be cleaning up its TLS usage to be back to 0 bytes used upon return).
Needing to call NewBatch one per thread changes the API a little from the cgo API, but I don't think it is otherwise not thread safe.
The secret is the garbage collector. In high memory allocation applications a GC can be more efficient than direct heap allocations. This is especially true if the C/C++ application is making heavy use of reference counting. A GC will ultimately have lower overhead than managing the reference counting.
All that said, in pure CPU calc scenarios with low allocations, C will almost certainly beat the pants off of go. Go's compiler is... subpar. Yes, it compiles fast, but it does that by ditching optimizations (perhaps this changes with LLVMGo).
GC will win when heap allocations are frequent, short lived, and unavoidable.
Anybody who cares about allocation speed in C or C++ (or Rust or <insert low level language>) will use arena / bump / slab allocators. GC is more efficient when you're writing naive code and you don't get to write naive code if you care about speed / memory usage.
I'm not saying it's not possible to reach or surpass C-like speeds with Go, but when comparing C to higher level languages with GC there should be an asterisk next to the statement you're making.
But it is hard to manage memory effectively everywhere in C without creating a lot of overhead for the programmer.
While not always the case, it is often the case that a good GC will beat all of those. A generational copying GC with parallel collection will treat most allocations as pointer bumps. Giving them the speed of a bump allocator with periodic fragmentation fixes when collection happens. It will beat both slab and arena allocators.
> naive code and you don't get to write naive code if you care about speed / memory usage.
I mean, you can certainly always implement a GC in C (most GCs are implemented in C/C++). Which does suggest that anything you can do with a GCed language can ultimately be replicated in a memory managed language.
However, the point of a GC is that naive code IS faster and easier to reason about. You don't have to create and manage elaborate data specific object pools in order to get the same speeds as if you did.
The other thing to consider about GCs is they enable algorithms that are really hard to replicate in memory managed languages. Concurrent algorithms are WAY easier to reason about because you don't have to wrap your head around object lifetime with thread lifetime.
That said, I've definitely seen use cases, particularly in games, where memory pools are clearly optimal. And certainly the deterministic nature of such pools has advantages as well.
Unfortunately Go's allocator is none of those. It has slow allocation performance because they don't do generational GC.
Wouldn't memory barrier add a significant overhead in this case? (compared to an arena not needing any memory synchronization at all if it's only needed on a single thread)
https://dzone.com/articles/thread-local-allocation-buffers
The short answer is that for java at least (and I suspect other GCs in other languages, but haven't confirmed) there's a thread local allocation buffer which is just the pointer bumps.
Unoptimised, naive allocations perhaps. I'm old enough to still remember when Microsoft used similar line of reasoning to create artificial cases where C# beat C++ performance.