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

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

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

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

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

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

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

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

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

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