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

The Go Compiler Needs to Be Smarter

lemire.me

Post reply on HN
Print view View original

41–50 of 119 posts

Re: The Go Compiler Needs to Be Smarter

#41

Post by _urga »

JTenerife wrote: post #35

No benchmarks or any other numbers. I wonder how much faster some typical Go code (some CLIs, Hugo or webservices) will run? Around 1%, 5% or 10%? The Go compiler doesn't need to be smarter for Go's usecase. If it can be made smarter, fine. For best possible performance look at C/C++ or Rust.

"No benchmarks or any other numbers."

And yet plenty of logical argument. The author assumes a level of optimization experience on the part of the reader, for example that the reader appreciates the physical cost of branch mispredictions.

Re: The Go Compiler Needs to Be Smarter

#42

Post by jagged-chisel »

MaxBarraclough wrote: post #30
dgellow wrote: post #8

Earlier quoted context omitted.

Suckless is promoting C99 and disregards anything with a GC. https://suckless.org/coding_style/

> All variable declarations at top of block. And they say they want their C code to suck less ? Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.

But can't the compiler work that bit out? Source code is for humans. Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" and then let the compiler observe "var x is only used twice, so let's optimize that lifetime..."

Re: The Go Compiler Needs to Be Smarter

#43

Post by rob74 »

mrath wrote: post #10
sitkack wrote: post #7

It will be a whole lot smarter on June 8th at 7am pacific, https://www.youtube.com/watch?v=Dq0WFigax_c

I skimmed over the paper once. I could not get all of it but whatever I understood seemed nice. Hopefully it can be implemented to full(not subset) golang and I hope it can be implemented soon. I started learning golang recently. I already have few places of `interface{}`. Having done lot of Java and a little Rust, I appreciate the simplicity and quick compile of golang, but I do feel it much more verbose than both.…

More verbose than Java? Is that even possible?

Re: The Go Compiler Needs to Be Smarter

#44

Post by flohofwoe »

panpanna wrote: post #38
MaxBarraclough wrote: post #30

Earlier quoted context omitted.

> All variable declarations at top of block. And they say they want their C code to suck less ? Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.

Doesn't C99 warn you if you make such mistakes?

On some compilers (gcc and clang at least) only when the warning is enabled (e.g. with -Wall).

But I agree that it's a bit silly to on hand recommend C99, and on the other hand, not take advantage of C99 features. It seems like the rules have been written against C89, and the "use unextended C99" only slipped in later.

Re: The Go Compiler Needs to Be Smarter

#45

Post by entha_saava »

pjmlp wrote: post #34
drej wrote: post #26

A frustrating thing about inlining in Go is that there's a fairly arbitrary cost model and you sometimes end up fighting it (lookup George Tankersley's talks on YouTube). There have been tons of discussions about whether or not it should be user configurable, if inlining hints should happen at the call sites or function definitions etc. It's quite a nice discussion that helps people understand the toolchain. It also…

Those optimizations could be taken advantage of via gccgo. Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics.

> Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics.

Attribute it to LLVM monoculture.

Re: The Go Compiler Needs to Be Smarter

#46

Post by entha_saava »

rob74 wrote: post #43
mrath wrote: post #10

Earlier quoted context omitted.

I skimmed over the paper once. I could not get all of it but whatever I understood seemed nice. Hopefully it can be implemented to full(not subset) golang and I hope it can be implemented soon. I started learning golang recently. I already have few places of `interface{}`. Having done lot of Java and a little Rust, I appreciate the simplicity and quick compile of golang, but I do feel it much more verbose than both.…

More verbose than Java? Is that even possible?

Nice try Pike.

Re: The Go Compiler Needs to Be Smarter

#47

Post by hu3 »

pjmlp wrote: post #18
gautamcgoel wrote: post #16

The optimization I care about most is vectorization. A lot of ML and data science basically boils down to numerical linear algebra and optimization; vectorization is the key optimization for these kinds of problems. I bet if Go got a better autovectorizer it would compare more favorably against languages like Rust and C++ for numerical tasks. The trade-off, of course, is longer compile times, which I suspect will be…

Even Java and .NET do better on auto vectorization. Intel has recently published an article on using Go, their advice? Manually use cgo or Go Assembly for the AVX.

Apples to orange comparison. Java and .NET have different goals, around 2 decades of optimization and a lot more money thrown at them.

Also, hi again pjmlp! Another Go thread, another nonconstructive Go bashing coming from you. From your other comments here I see you got pretty combative this time.

Re: The Go Compiler Needs to Be Smarter

#48

Post by jhoechtl »

pjmlp wrote: post #36
ldeangelis wrote: post #22

Correct me if I'm wrong but comparing Go against Swift, C, C++, and Rust isn't really fair since one of Go's goals is compilation speed, in which it seems to shine against these other languages. From what I understand, you're going to trade performance against compilation speed, and Go is on the opposite side of these choices compared to the other languages.

We could compare it with D, Ada, Object Pascal or Delphi, and it would lose on compilation speed, language features and quality of generated code.

Claims without a proof are just - claims

Re: The Go Compiler Needs to Be Smarter

#49

Post by atilaneves »

jagged-chisel wrote: post #42
MaxBarraclough wrote: post #30

Earlier quoted context omitted.

> All variable declarations at top of block. And they say they want their C code to suck less ? Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.

But can't the compiler work that bit out? Source code is for humans. Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" and then let the compiler observe "var x is only used twice, so let's optimize that lifetime..."

> Source code is for humans

The reason why making the scope as local as possible is important is for humans, not compilers.

> Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block"

Why would humans care about how much scratch space is needed? That's for the compiler to know.

Re: The Go Compiler Needs to Be Smarter

#50

Post by vips7L »

rob74 wrote: post #43
mrath wrote: post #10

Earlier quoted context omitted.

I skimmed over the paper once. I could not get all of it but whatever I understood seemed nice. Hopefully it can be implemented to full(not subset) golang and I hope it can be implemented soon. I started learning golang recently. I already have few places of `interface{}`. Having done lot of Java and a little Rust, I appreciate the simplicity and quick compile of golang, but I do feel it much more verbose than both.…

More verbose than Java? Is that even possible?

I honestly don't understand how anyone thinks go is LESS verbose than java. Go is full of manually iteration loops and doesn't have anyform of pattern matching/switch expressions.
Post reply on HN