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

61–70 of 119 posts

Re: The Go Compiler Needs to Be Smarter

#61

Post by jagged-chisel »

atilaneves wrote: post #49
jagged-chisel wrote: post #42

Earlier quoted context omitted.

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.

We're not talking about scope. The scope is already decided. "Vars at the top of the block" doesn't mean "take those extra vars out of the while{} scope and elevate them to the next enclosing scope."

You've taken my "scratch space" too literally. Very few people need to count bytes for local vars. I'm talking about future maintainers reading and understanding code. Grouping the current block's variables at the top says nothing about how the compiler might organize the resulting code and storage. But it does inform future readers of the code.

Re: The Go Compiler Needs to Be Smarter

#63

Post by Someone »

atilaneves wrote: post #55
cesarb wrote: post #53

Earlier quoted context omitted.

> Why would humans care about how much scratch space is needed? In some contexts, it's important. For instance, each thread within the Linux kernel has a very limited fixed-size stack space (used to be 4K bytes, IIRC it's been increased to 8K and then 16K), which resides in physical memory (cannot be swapped out or lazily allocated). Avoiding large stack frames is necessary.

1. That's a rare use case 2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??

Also, unless your thread has only a single function that has local variables or arguments and that function doesn’t contain sub blocks that declare variables (say inside a while block), All variable declarations at top of block doesn’t help much in gauging stack space usage of a thread.

Actually, not even that helps, you would also have to know how much stack a function call takes (might be non-trivial in the presence of stack alignment rules), and which functions get inlined. Edit: if you declare all your locals at the start of a function, chances are the compiler will check whether it can make some of them share memory, so you’d have to take that into account, too.

If you’re concerned about stack overflows in your threading code, it is tooling is what you need, not manually counting stack usage.

Re: The Go Compiler Needs to Be Smarter

#64

Post by pjmlp »

jhoechtl wrote: post #48
pjmlp wrote: post #36

Earlier quoted context omitted.

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

Claims?!?

Anyone can get the compilers and try them for themselves (except for Ada, which you can only get the free GNAT one).

Language features are quite obvious, one just needs to look a language reference manual.

The only claim is being lazy to accept facts and acknowledge that even Turbo Pascal for MS-DOS did it before Go.

Re: The Go Compiler Needs to Be Smarter

#65

Post by pjmlp »

hu3 wrote: post #47
pjmlp wrote: post #18

Earlier quoted context omitted.

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.

Stating facts is hardly bashing.

Re: The Go Compiler Needs to Be Smarter

#67

Post by MaxBarraclough »

atilaneves wrote: post #55
cesarb wrote: post #53

Earlier quoted context omitted.

> Why would humans care about how much scratch space is needed? In some contexts, it's important. For instance, each thread within the Linux kernel has a very limited fixed-size stack space (used to be 4K bytes, IIRC it's been increased to 8K and then 16K), which resides in physical memory (cannot be swapped out or lazily allocated). Avoiding large stack frames is necessary.

1. That's a rare use case 2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??

That wouldn't work anyway. You could rewrite code to use fewer variables without changing the resulting assembly.

    i = get_thing();
    j = do_stuff(i);
vs

    j = do_stuff(get_thing());

Re: The Go Compiler Needs to Be Smarter

#68

Post by OnlyOneCannolo »

bitwize wrote: post #3

Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…

> Go is more about software engineering than programming language research. Or to rephrase, it is about language design in the service of software engineering. [1]

This isn't suckless philosophy applied for the sole benefit of compiler writers.

It's a compiler whose primary customers explicitly include tool developers.

[1] https://talks.golang.org/2012/splash.article

Re: The Go Compiler Needs to Be Smarter

#69

Post by hu3 »

pjmlp wrote: post #65
hu3 wrote: post #47

Earlier quoted context omitted.

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.

Stating facts is hardly bashing.

Vague statements without sources are not facts.

And even without sources comparing Go to Java and .NET doesn't even make sense in the context.

Re: The Go Compiler Needs to Be Smarter

#70

Post by pjmlp »

hu3 wrote: post #69
pjmlp wrote: post #65

Earlier quoted context omitted.

Stating facts is hardly bashing.

Vague statements without sources are not facts. And even without sources comparing Go to Java and .NET doesn't even make sense in the context.

Since it is so hard for you to use Google, here you go:

https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati...

https://www.codeproject.com/Articles/1223361/Benchmarking-NE...

https://clearlinux.org/blogs-news/performant-containerized-g...

Now go play with your facts.

Post reply on HN