function multiple returned values signature, compiler optimisation/feature question

57 views
Skip to first unread message

simon place

unread,
Jun 10, 2020, 2:28:15 PM6/10/20
to golang-nuts
when you have functions that return multiple values, because its more efficient to generate in one go when you are using ALL returned values;

like in math, where you have Sin(), Cos() and Sincos()

and when you also don't use all the returned values (using '_') does the compiler optimise? does it compile multiple times so dead code is removed from the version used with some return values unneeded?

i would guess it doesn't, but i wanted to check, because i seem to keep coming over this, probably the way i think, seems to me to reduce the solution space.

also this seems to, in some ways, overlap with generics, particularly if there were new language features that let you specify some high level/simple code path changes, things specific to the problem that the compiler could never determine.

i guess with code generation its possible, but that doesn't feel like the best way to go.

i could have tested for this but am also interested in all architectures/future developments/other ways to achieve this.

thanks.

Ian Lance Taylor

unread,
Jun 10, 2020, 3:19:42 PM6/10/20
to simon place, golang-nuts
Currently the compiler does not do the kind of optimization you
describe. A function is compiled once, and computes all of its
results. The caller receives all the results, and ignores ones that
it does not need.

Of course, if the function is inlined, then any code leading to
results that are not needed will be discarded. But most functions are
not inlined.

We could implement the general optimization by compiling a function
multiple times, for each permutation of the possible results. But I
think it's clear that that effort would generally be wasted. So we
would need some way to decide when this optimization would be useful.
And note that any effort in this area would tend to go against the
overall goal of fast compilation time.

Ian

simon place

unread,
Jun 10, 2020, 3:41:56 PM6/10/20
to golang-nuts

Currently the compiler does not do the kind of optimization you
describe.  A function is compiled once, and computes all of its
results.  The caller receives all the results, and ignores ones that
it does not need.

yes, i suppose the code generation route might give some insight as to if this might be worth it, but you probably have to  code to it and so the results wouldn't then clearly differentiate.
 
We could implement the general optimization by compiling a function
multiple times, for each permutation of the possible results.  

i feel it might not be that bad; you only need the permutations that are actually being used and the feeling i have is that a given problem, and so a given program, will tend to only use a small selected subset of permutations.
 
But I think it's clear that that effort would generally be wasted.  So we
would need some way to decide when this optimization would be useful.
And note that any effort in this area would tend to go against the
overall goal of fast compilation time.

given above is correct you could probably just limit the number.

Michael Jones

unread,
Jun 10, 2020, 4:43:14 PM6/10/20
to simon place, golang-nuts
This is beyond most translation systems. 

Interestingly, the exceptions are themselves old in origin. 

The LISP compiler, emerging after interpretation was the universal environment for LISP, was able to “execute” the program being compiled to discover what could be evaluated to a static conclusion, or a simpler case of the general one. 

From about the same time, the early symbolic algebra systems had this same notion in their runtimes of iteritavely evaluating expressions until a fixed point In code terms was reached. REDUCE and MACSYMA are in my thoughts here. Mathematica has a sense of this too in some of its programming modes, an organic rule-driven rewrite system. (It is brilliant at the task)

Not something seen in general languages very much. Some flavor of it in C metaprogramming. 

On Wed, Jun 10, 2020 at 11:28 AM 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:
--
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/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com.
--
Michael T. Jones
michae...@gmail.com

simon place

unread,
Jun 10, 2020, 4:58:03 PM6/10/20
to golang-nuts
surely simply recompiling a chunk of code with particular result(s) unused, allows dead code removal from that version?
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages