Hacker News Reader

Comment by jeffbee | Hacker News Reader

It's not really a language problem, it's a compiler problem, so at least in the future we might get a compiler that recognizes error-handling idioms. Or we just get llvm? The language problems, like the performance-hostile calling convention, are harder to fix.

View on HN

> like the performance-hostile calling convention, are harder to fix.

Can you elaborate on what you mean by this? I’m new to go and want to understand the performance implications.

not gp, but it looks like go's calling convention requires pushing all function args and return values to the stack [1]. thats always going to be less efficient than most C calling conventions, where (iirc) you put what you can in registers and only use the stack if registers aren't enough

EDIT: and all registers are caller-saved. so when calling a function, all register contents will be saved on the stack (and restored later) even if the function doesn't touch certain registers

[1](https://dr-knz.net/go-calling-convention-x86-64.html)

Wow, maybe they have some valid reason for that, but from where I'm standing it just seems like an extremely lazy and thoughtless design choice that belongs in a prototype and nowhere else.

it's not lazy, it's simple! ;)

i don't think its intended as a stable target and will probably change at some point. the top google hit was a 3rd party site, and this issue is still open [#16922 doc: document assembly calling convention](https://github.com/golang/go/issues/16922)

btw the source i linked in my original comment links to a proposal to allow passing args in registers

Does it help goroutines and the scheduler?

This is not a language problem, but a compiler problem also. gccgo uses registers like C.

It's more than a compiler problem: Go modules contain assembly routines which assume the Go calling conventions, so changing the convention is now quite breaking.

There's a lesson in there about success, or something...

How can that be true? Every assembly function in Go moves its arguments from memory relative to the stack pointer. If the arguments were in registers instead it would break every assembly function. Does gccgo not support asm?

> In contrast to 6g (the original Go compiler) gccgo tries to mimic the native calling convention.

https://dr-knz.net/go-calling-convention-x86-64.html#differe...

I just tried it and it won't build my existing Go packages that include x86 assembly files. So I conclude that it does indeed break compatibility with asm, which certainly is one way to change the calling convention.

true, thanks for pointing that out!

I think Go's calling conventions also don't allow for tail call optimization?

> It's not really a language problem, it's a compiler problem

This has never seemed like such a clear distinction to me. A language is essentially just an instruction set for a compiler.

Consider that a hobbyist C compiler isn't going to perform the same optimizations as gcc. Likewise, clang and gcc aren't totally equivalent, either, despite being based on the same language standard. Most languages don't have multiple compilers, but any non-commercial language can in theory have multiple competing compilers that don't give equivalent output for the same input.

Even commercial languages can have multiple competing compilers.

Well, there is a disctinction.

It being a compiler problem, you can just accept the performance/size penalty and leave your code as is, but hope that in the future it will eventually change and the eventually really smart compiler will accept your current code as is and produce output without the penalty.

Language problem would means you have to rewrite it differently.

A language is both the abstractions that it implements, and the way it implements them. Any problem in the code you write could be solved by changing the compiler as much as it could be solved by changing the code. The two parts of the system are inseparable. I’d say a language can only be as good as its best compiler.

But they are quite different. There are languages that are tightly coupled, but not true of all (like Go). You could write all your applications in the Go Language, but use a transpiler.

And as other comments call out, it is important to not conflate the two. A language issue is one that can't be easily fixed without breaking backwards compatibility. Compiler optimizations can be made (and is done all the time) without breaking the language.

Reply on news.ycombinator.com