Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[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.

On Thu, Jun 4, 2020 at 1:20 PM Andy Balholm  wrote:

> I think by “at compile time” he means at JIT time (when converting
> bytecode to machine language).
>
> Andy
>
>
>
> On Jun 4, 2020, at 1:02 PM, Robert Engels  wrote:
>
> 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  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+unsubscr...@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
> 
> .
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com
> 
> .
>
>
> --
> 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+unsubscr...@googlegroups.com.
> 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. jonesmichael.jo...@gmail.com *

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyKs8WQHx01pDOLoOM0PkPtua%2Bbcg%3DnxnEx%3DjidbnWVjA%40mail.gmail.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Andy Balholm]

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

Andy



> On Jun 4, 2020, at 1:02 PM, Robert Engels  wrote:
> 
> 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  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+unsubscr...@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
>>  
>> .
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com
>  
> .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAD4A4F7-0C56-430F-AF54-86993C704655%40gmail.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[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  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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Ian Lance Taylor]

On Thu, Jun 4, 2020 at 12:34 PM Igor Yemelianov  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUAEZi2N1xG2L5b0oTjsXWpt1mwR17KUeoBekrUCpphhA%40mail.gmail.com.