Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang on ARM

github.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Golang on ARM

#41

Post by pcwalton »

tptacek wrote: post #40
vox_mollis wrote: post #32

Earlier quoted context omitted.

Group (3), of which I am a member: If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles. I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. Wh…

"Entirely dishonest". "Dishonesty and hypocrisy". In a discussion about compiler performance. Do you understand that framing things like this makes it seem like discussing things with you is intractable? Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Re: Golang on ARM

#43

Post by arthurbrown »

frame_perfect wrote: post #24
IshKebab wrote: post #23

This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…

What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…

Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration.

"Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with actual runtimes.

For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

"... the custom toolchain is one of the key reasons we've accomplished so much in so little time. I think the author doesn't fully appreciate all the reasons that C tools don't work well for languages that do so much more than C. Most other managed languages are doing JIT compilation and don't go through standard linkers either."

[1] https://news.ycombinator.com/item?id=8817990

Re: Golang on ARM

#44

Post by zik »

frame_perfect wrote: post #27
kyrra wrote: post #10

Earlier quoted context omitted.

Go already has 2 compiler implementations. There is gc (Go Compiler) and gccgo[0]. [0] https://golang.org/doc/install/gccgo

But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?

It's mostly because the Go compiler was developed out of the plan9 compiler code base, which is unrelated to llvm.

The other aspect is that the Go compiler is intended to be very fast. That's not an explicit design goal of llvm - using llvm would slow the compiler down although it would have other advantages.

Re: Golang on ARM

#45

Post by biomcgary »

dekhn wrote: post #17

One of the funniest experiences I had was building an ARM go binary on an x86-64 linux box using a cross compiler (nothing new there). Then, by accident I tried to run the ARM binary on my x86-64 box, instead of on the ARM box. It ran like a normal executable, which confused me until I realized I had installed QEMU-arm, which installed a linux binary format handler for ARM binaries, and it emulated ARM to run my bina…

Did you benchmark performance on QEMU vs bare metal?

Re: Golang on ARM

#46

Post by pcwalton »

arthurbrown wrote: post #43
frame_perfect wrote: post #24

Earlier quoted context omitted.

What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…

Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration. "Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with…

> For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

LLVM now supports both segmented stacks [1] and precise garbage collection with patchpoints [2].

Tweaking support for segmented stacks is quite easy—I added the support for it on x86 Mac. You simply adjust the prolog emission code in X86FrameLowering.cpp and likewise for the other targets.

[1]: http://llvm.org/docs/SegmentedStacks.html

[2]: http://llvm.org/docs/StackMaps.html http://llvm.org/docs/Statepoints.html

Re: Golang on ARM

#47

Post by bassislife »

pcwalton wrote: post #35
bassislife wrote: post #34

Earlier quoted context omitted.

Compile times ? Flexibility over the backend ? That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : http://llvm.org/viewvc/llvm-project/llgo/

> Compile times ? There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact. > Flexibility over the backend ? Writing to LLVM in no way rest…

> Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like.

It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.

Re: Golang on ARM

#48

Post by [deleted] »

bassislife wrote: post #47
pcwalton wrote: post #35

Earlier quoted context omitted.

> Compile times ? There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact. > Flexibility over the backend ? Writing to LLVM in no way rest…

> Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.

[deleted]

Re: Golang on ARM

#49

Post by tedunangst »

pcwalton wrote: post #41
tptacek wrote: post #40

Earlier quoted context omitted.

"Entirely dishonest". "Dishonesty and hypocrisy". In a discussion about compiler performance. Do you understand that framing things like this makes it seem like discussing things with you is intractable? Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Why not consult the go faq to find their reasoning for omitting generics?

> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

The word performance doesn't appear in that paragraph.

Re: Golang on ARM

#50

Post by [deleted] »

tedunangst wrote: post #49
pcwalton wrote: post #41

Earlier quoted context omitted.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Why not consult the go faq to find their reasoning for omitting generics? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. The word performance doesn't appear in that paragraph.

[deleted]
Post reply on HN