Add support for future-less asynchronous calls on void methods

[TobiasWrigstad]

We currently implement async sends to void methods using standard futures which are fulfilled by (). This makes some sense -- it is possible to wait for the method to finish. On the other hand, it is highly suboptimal. Profiling the prime sieve program for example showed that ~30% of the entire program was spent creating and fulfilling Fut void.

We need a way to call void methods asynchronously without futures. For now, I think a good solution (given it is simple to implement) is to check whether the caller saves the result of the call or not. So, give the method foo() : void, the call

target.foo()

should generate a call without future overhead, whereas the call

x = target.foo()

should generate the same code as we currently do for both those cases.

(Someone might argue this is premature optimisation but currently that's not the case. Anything that makes our current key example run faster is important.)

@EliasC — I am assigning you to this task. If you can have this done before August 1st, we are good.

[supercooldave]

Doug Lea calls these one way message sends.

[EliasC]

It's a bit wonky to implement it that way since it would require adding machinery, either to the type checker or to the code generation, to know if the current thing being translated is being "captured" or not. It wouldn't be hard, but I would prefer to avoid adding that kind of complexity for just one thing.

What would actually be easier to implement is another operator for one way message sends. For example, x!foo() could mean call foo and ignore the results (making y = x!foo() illegal). On the C-level, this could tranlate to a normal message send with a future that is NULL.

[TobiasWrigstad]

For a first implementation of this feature, I am all for it.

[supercooldave]

Just one point on this issue. It applies to all kinds of methods, not just those returning void.

Sent from my iPhone

On 19/07/2014, at 10:09, EliasC [email protected] wrote:

It's a bit wonky to implement that way since it would require adding machinery, either to the type checker or to the code generation, to know if the current thing being translated is being "captured" or not. It wouldn't be hard, but I would prefer to avoid adding that kind of complexity for just one thing.

What would actually be easier to implement is another operator for one way message sends. For example, x!foo() could mean call foo and ignore the results (making y = x!foo() illegal). On the C-level, this could tranlate to a normal message send with a future that is NULL.

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[supercooldave]

I guess the difference between the two approaches boils down to whether one way sends are a language feature or an optimisation.

[TobiasWrigstad]

This is a good point. I like both actually. What I originally suggested is not visible to the user, which is nice — and in line with the project. But it is also good to be able to explicate what one wants. So I'd like both I guess. But I'd favour the first kind just to lower the number of concepts in the language.

[EliasC]

Just a reminder that nothing we do in mylittlepony needs to "leak" to the final language. It is fully possible to implicitly avoid creating futures, but when trying the language out like this I think there is a point in favoring low implementation complexity over user complexity.

[TobiasWrigstad]

Given the level of documentation of the current implementation, I agree with you 100% ;)

[albertnetymk]

I would guess the C optimizer is smart enough to remove the unused result.

Even if we capture the return value of one function call, 'x =
actor.function()', it's still possible that variable is not accessed
afterwards, and it's the job of optimizer to avoid the unnecessary code
generation. C should be able to optimize it away with '-O2'. Is the
profiling running with optimizing flag on?
On Jul 19, 2014 10:42 AM, "TobiasWrigstad" [email protected] wrote:

Given the level of documentation of the current implementation, I agree
with you 100% ;)

—
Reply to this email directly or view it on GitHub
#8 (comment).

[TobiasWrigstad]

The C compiler is really not that smart. Partially because we are generating code that looks very much like use, and because there are multiple use-sites and the creation-site is always different from at leaf one use-site.

I ran with -O1, -O2 and -O3 and saw roughly the same 30% time spent generating futures never used.

[EliasC]

This has been implemented and seems to work (i.e. it doesn't break anything obvious). Feel free to reopen this if new problems arise.

[TobiasWrigstad]

Can you just briefly write down how this works here for our perusal and inclusion in Stephan’s language spec?

[EliasC]

The expression x!foo(y) will call the method foo on x and immediately return unit. No futures will be generated, so this should be more efficient when calling methods of void-type (or when you don't care about the result).

[supercooldave]

Don't confuse methods of void return type with those whose result you don't care about. We may care to know when a void method returns.

Sent from my iPhone

On 23/07/2014, at 10:30, EliasC [email protected] wrote:

The expression x!foo(y) will call the method foo on x and immediately return unit. No futures will be generated, so this should be more efficient when calling methods of void-type (or when you don't care about the result).

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[EliasC]

@supercooldave Sure, and in that case we can still use x.foo(y) and get on that result. Mentally remove the "or" from the final parenthesis in my previous post (or parenthesise it one additional level).

[kaeluka]

I'll put it in the manual later today

[TobiasWrigstad]

Super!