Comments on: IronScheme does CPS!

By: leppie

leppie — Fri, 06 Feb 2009 15:44:11 +0000

Hi Jon

I kinda realised that, but after investigation, it appears the problem is with virtual calls only. I have changed my emitted code to call delegates non-virtual (as it’s not really needed according to the spec), but have not tested tail recursion on Mono recently.

How does F# cope on Mono? I see they use tail calls in all tail positions.

Cheers

leppie

By: Jon Harrop

Jon Harrop — Fri, 06 Feb 2009 10:17:33 +0000

Note that Mono’s implementation of tail calls is broken: they only eliminate direct self and mutual tail recursion and not general tail calls, i.e. to dynamic locations. Consequently, many conventional FP idioms (e.g. combinators) will leak stack space until the stack overflows on Mono.

By: leppie

leppie — Mon, 10 Nov 2008 20:01:00 +0000

Antonio :

I was just browsing the F# generated assemblies, and they use tail calls where possible it seems. I wonder how they deal with the performance impact. Perhaps .NET 4 will offer better performance in that aspect

By: leppie

leppie — Thu, 06 Nov 2008 17:47:06 +0000

OTOH, that gives us an interesting problem to solve

By: leppie

leppie — Thu, 06 Nov 2008 17:44:53 +0000

I applied the NoInlining option to the recursive calls, and it seems tail calls are never inlined (same time), probably intentional, but that still makes the tail call 6 times slower

By: Antonio Cuni

Antonio Cuni — Thu, 06 Nov 2008 13:00:21 +0000

@leppie

Ok, it seems that tail calls are indeed not an option for me at the moment. For scheme it’s even worse, because you *need* to use tail calls anyway, I suppose.

FWIW, mono behaves much better with tail calls: on my machine tail calls are about 30% faster than normal calls, so you maybe want to run your benchmarks also there.

By: leppie

leppie — Thu, 06 Nov 2008 12:20:44 +0000

@Antonio: Thanks for the information, my results are the same as yours. I did not realize the tail calls on .NET behave this badly

In my tests with the code, tail calls were roughly 10 times slower. Tried a few variations, it seems using an object type for a return value gets the best performance, but still very slow!

It also probably explains the 6 times slow down I get with the CPS version of IronScheme as every call should be a tail call.

By: leppie

leppie — Thu, 06 Nov 2008 11:58:53 +0000

@Antonio:
I have not tested it yet, but from the looks of it, I do something different. Due to the dynamic requirements of Scheme, types should be checked inside the procedure, hence I always use object types for parameters and return values, in the signature.

I will fiddle a bit with your code to see if some implicit boxing is occurring on the return value.

By: Antonio Cuni

Antonio Cuni — Thu, 06 Nov 2008 11:37:55 +0000

@leppie
uhm, I’m surprised that tail calls work so well for you, I wonder if I did something wrong.
I wrote a little benchmark that sums all the integers up to N using a loop, a normal recursive call and a tail call; the original C# source is here:
http://codespeak.net/svn/user/antocuni/cli-bench/tailcall.cs

then I patched the IL to add the tail. prefix to the call:
http://codespeak.net/svn/user/antocuni/cli-bench/tailcall.il

Here is the final .exe:
http://codespeak.net/svn/user/antocuni/cli-bench/tailcall.exe

With CLR 2.0.50727 the tail call is about 6.5 times *slower* than the normal call, which is by itself 2 times slower than the for loop.
Could you try to run the benchmark, please?

By: leppie

leppie — Thu, 06 Nov 2008 10:41:07 +0000

@Antonio (again): Wow, very impressive numbers! I think I should start looking into using PyPy in some or other way (I did have a look at it about a year back).