Hacker News Reader

Comment by andrewstuart | Hacker News Reader

"X outperforms C/C++/Rust/Golang".

Only if the code design in C/C++/Rust/Golang is bad.

Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.

Golang's compiler is so fast though that I can iterate much faster so I'm willing to accept slightly worse performance than C++. C++ I waste so much time just waiting (esp. if I'm using a lot of templatized header only libraries)

But by that logic ruby is faster still since the compile time is 0. Less than zero really because it can be modified in flight.

The trade offs between the two are huge.

Go programs compile in less than a second, or several seconds for huge projects, where idiomatic Go gets you within the same order of magnitude to that of C(++), with some memory overhead. Concurrency is first class, GC pauses exist but are seldom an issue.

Idiomatic Ruby runs several orders of magnitude slower, with a huge memory overhead, and is rife with runtime gymnastics. Concurrency is an expensive hack, with stop-the-world GC.

Only if the compilation speed difference is worth the loss of performance. That seems unlikely for most use cases because the speed gain is small while the performance loss is severe.

Somehow I can't find a source for this but it's well known that Go prefers compilation speed over runtime performance. Doesn't help that they implement the entire compiler stack themselves so it definitely misses optimisations that other compilers can already do.

Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?

I've done it for a c++ parser. I grabbed the compiled c++ and disassembled it into assembly, then reworked it. Got a massive increase in speed when I tweeked the registry use.

> Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?

It's in the standard library. It's also how you write parsers and formatters with acceptable performance if you don't have SIMD intrinsics.

Perhaps gcc-go is better?

gcc-go, gollvm there’s actually no difference in comparison to the go compiler, heck in some cases gcc-go perform worse, Go internals are built with a different mindset and architecture there’re certain features that’s can perform worse than just hard coded assembly

As well as differences in code gen, as I understand it Go also has worse tail latencies than servers written in C/C++/Rust because of the GC.

In this context, they are not talking about GC but the compiler

Yeah it's not fair to put Go in the same bracket as fast langs tbh.

It's a lang to ship MVPs quickly without much thought & cheaper devs - not a high perf one.

If this was 4 years ago I would say “fair enough” but now Go 1.21 ? This claim is no longer Valid, just like saying CGO is slow, just because one language uses LLVM or GCC doesn’t mean they have state of the compiler

Not at all. The main way is to reduce pressure on the GC by reducing allocations, which is a fairly straightforward process thanks to good support from the tooling.

Past that, you either call out to C via FFI or give up and rewrite in C/C++/Rust. Nobody really bothers with the asm.

For the time being. But C on x86 hasn't been a good model of what the CPU is actually doing for a while now and eventually we'll have a better way to harness the computing power available to us.

C was never intended to be a model of what the CPU is actually doing.

This is purely an optimization issue and the article compares apples to oranges for clicks.

I want to be optimistic and agree that ‘we’ll have a better way to harness the computing power available to us’, but at this point it’s been years or maybe decades of propping up the x86 ISA while actual operation of the computing device drifts further away. I certainly understand the desires of processor manufacturers to want to be able to maintain an ISA and then be able to implement a machine that can change underneath it to realize performance gains. However, this has left the status quo utterly entrenched and I can not see what would make them change this behavior.

I really would get onboard with an alternative ISA that was more in line with actual architectural features of modern processors and I often wonder why we could not have an extra compilation (jit or aot) step from x86 to some other format. But the trend seems to be going the opposite direction for all the large scale processor manufacturer/designers toward a more abstracted interface at the lowest level.

I’ve seen various comments that basically boil down to “you can’t change the ISA because then C/C++/Rust programs would loose performance in benchmarks in the short term”, and this resistance only reinforces maintaining current trends. So… what are you assuming happens that prompts the shift toward a better way to harness computing power?

What architectural features would you like to surface that are currently papered over in x86?

My particular interests would see me appreciating access to cache structure, cache behavior, prefetching, cache coherency, memory management unit control, instruction pipelining, and maybe register renaming control.

I am not particularly qualified to try and design a better ISA, I just know there are some things I would like the option to control at some times (or at least I imagine I would). A lot of the list above is about exposing more of the architecture to user control as a general principle. However, I’d rather see some areas of hardware design change to facilitate something other than coding paradigms and practices that stretch back nearly 40 years. Chisnall’s ‘C is not a Low Level Language’ article discusses several architectural directions I would like to see happen, but also talks about how as long as the ISA remains the same moving to new programming styles/philosophies continues to be a difficult proposition.

I see. These things sound swell, though for stuff like controlling register renaming it sounds hard for the instruction decode overhead to be worth it. Currently you can use prefetch intrinsics for prefetching and the level of cache management available is mostly non-temporal stores and explicit allocation of L3 space to specific cores (which ends up meaning specific processes if you are careful).

The world has mostly not adopted existing tools for writing 10-100x faster software (simd, huge pages, computing both branches then using a blend or cmov when this is sufficiently cheap, software prefetching, collection APIs that support bulk updates so that they can use all of these things instead of adding totally unnecessary dependency chains to the resulting program, etc.) so i'm not optimistic about things getting better if CPUs grow a thousand times more memory bandwidth and cores and begin to support very wide scatter/gather like GPUs.

ARM seems like it's destined to only grow in importance.

I don’t know for certain, or in any great specificity, but in this context (i.e. ISA representing a more accurate or concrete mapping to hardware functionality/capabilities) I don’t know that ARM is particularly different to x86. The both present a relatively single core, flat memory architecture to programmers; while the actual processor is absolutely not that.

The memory model is a bit different on arm64, but it is not Alpha.

Other than that they are very similar

You may be right about that, though I had the impression that less wasteful parallelism was possible because of fixed-size instructions.

immintrin.h seems tough to beat.

C is a pretty good model in part because all ISAs were designed with C in mind.

(Edit: my mistake, I misread the comment I was replying to assuming it claimed these languages themselves were equivalent.)

Why would the performance of these languages be identical? These languages aren’t the same in lots of ways.

Golang has a GC and gives you much less control over memory layout than any of the other languages you mentioned. It also has a very different concurrency model, which will vastly change the performance characteristics of multithreaded code.

Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc)

Rust has much better noalias analysis - which allows the compiler to make optimizations that aren’t available in general purpose C or C++ code. (Since nobody adds noalias to all their variables in C, for a variety of reasons).

Unlike the others, C doesn’t support monomorphization (without disgusting macro tricks). Monomorphization cuts both ways with performance - since it bloats executables (and thus hurts the branch predictor and cache) while generating more efficient code.

These languages aren’t the same. There’s lots of reasons they will perform differently both at the limits of what we can optimize and in the average case of everyday code. It’s wild that you would consider them to all be the same.

> Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc)

There's a rust front-end for gcc as well.

Is it ready for use? Last I saw it was far from feature complete.

Afaik the borrow-checker is missing - please correct me if I am wrong - but that doesn't stop you from using it. You could very well use `rustc` for the borrow-checker and compile with GCC on any other backend. The borrow-checker only expresses that your code is sound according the rust spec.

> The borrow-checker only expresses that your code is sound according the rust spec.

Doesn’t the borrow checker also track when things fall out of scope, and thus control when Drop is called?

Afaik it tracks when objects go out of scope as that deals with ownership and lifetimes, but that's also part of the rust spec.

The drop is there for stuff that you can't just release the memory for, such as closing files and connections.

No. Drop has straightforward rules.

Find the scope you can refer to the variable in, i.e. the curly brackets it is contained in. That variable is dropped right before the closing curly bracket. Things are dropped in reverse order of creation.

(Similar rules apply to dropping temporaries)

https://doc.rust-lang.org/reference/destructors.html

Reply on news.ycombinator.com