What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Igor Yemelianov]

Link to the article.

The question is - is it possible that the issues described in the article can be solved in for example next major version?

Thanks.

[Ian Lance Taylor]

On Thu, Jun 4, 2020 at 12:34 PM Igor Yemelianov <cybe...@gmail.com> wrote:
>
> The question is - is it possible that the issues described in the article can be solved in for example next major version?

Yes, it is possible.

As Go is an open source project, you or anyone can make that much more
likely to happen by doing the work and contributing the changes.

Thanks.

Ian

[Robert Engels]

The author either doesn’t know Java or had significant editing errors - Java determines uses the runtime processor type to optimize - it is not done at compiler time. It has different implementations based on processor - like Go - and it does JIT optimizations based on processor as well. 

More importantly, these micro benchmarks with fractions of a percent are meaningless. All powerful systems are distributed to scale, not micro optimized. 

On Jun 4, 2020, at 2:34 PM, Igor Yemelianov <cybe...@gmail.com> wrote:



Link to the article.

The question is - is it possible that the issues described in the article can be solved in for example next major version?

Thanks.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7aef8f47-8834-4cd3-9ba0-67e51728a110o%40googlegroups.com.

[Andy Balholm]

I think by “at compile time” he means at JIT time (when converting bytecode to machine language).

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com.

[Michael Jones]

When he writes "you expect a good, optimizing compiler to..." he is implicitly stating that he wants more  than good optimizing compilation, he wants (understandably, but let's be explicit) iterated compile-time evaluation -- he wants fun() to be an integer value of 60. 

It is true that the gc Go compiler lacks this. I like it as a feature, it is like invoking "reduce()" in a symbolic algebra system. I hinted at it a while back by asking if Go should notice when a function returns a pure value and do substitutions -- clearly "x := math.Sqrt(4)" suggests "x := 2.0" or "const x = 2.0" depending on context. But this is a non-trivial step from compilation in the direction of metaprogramming via Turing-complete macro processors. It will make the compiler bigger and slower, and intellectually larger. 

It is an open issue decision wise, and a great deal of work implementation wise.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAD4A4F7-0C56-430F-AF54-86993C704655%40gmail.com.

--

Michael T. Jones
michae...@gmail.com