Cheney on the MTA

[justinethier]

Hi! I'm Nikodemus, and I'm not a Cyclone user, but I'm really curious about your experiences with Cheney on the MTA., since I'm considering using it in my own project, and I am having trouble finding discussions on its performance characteristics.

If you find the spare time to enlighten me, I would be very happy!

My main worry is the cost of CALL vs RET, but the upsides of CotMTA seem very attractive. Did you quantify the costs at any point? Any other major caveats or other experiences - including positive ones - you would like to share?

Thank you for your lovely writeup on the Cyclone GC, by the way.

[justinethier]

Thanks @nikodemus let's move this over to its own discussion.

[justinethier]

Glad you enjoyed the GC write up :)

The consideration is not just CALL vs RET - the problem is that you are going to need to constantly check to see if you have exceeded your allowed stack space so you can initiate a RET / LONGJMP. It is difficult to quantify the exact overhead of these checks but it adds up since they are running all the time.

There are significant speedups to be had if portions of your code can be "inlined" into iterative loops. Though in Cyclone this also eliminates CPS functions (and thus additional overhead) so there are other considerations.

That said, CotMTA is an elegant way to get guaranteed tail call optimization, generational GC, and cross platform support (no need for any assembly/bytecode hacks).

What are you planning to build using CotMTA and what other alternatives have you considered?

[nikodemus]

Thank you for your insights!

I'm working on https://github.com/nikodemus/foolang

The ease of cross platforms support you mention is what attracts me, as coroutines are on my roadmap, but perhaps even more importantly CotMTA is seems like a reasonable way to steal native code actors from one executor thread to another. (The only other option I can think of is to allow stealing only when the stack is empty, and that doesn't as easily fit the language model I have in mind for actors.) Additionally, for actors CotMTA means I can allocate a small stack to start with and grow it later, even though a good heuristic seems like a fantasy there.

Similar to what you say about inlining iterative loops, I was thinking that I could recognize known non-recursive, non-stack-capturing subtrees of functions, where stack requirements are statically known and compile them using regular call/return with stackchecks done by the caller - or at least leaf functions if the full thing seems too much like work. 😃

[nikodemus]

Ah, almost forgot to ask about stack size! Only performance discussion I was able to find on CotMTA was this: http://computer-programming-forum.com/40-scheme/8b6605ed64e4237b.htm from 1997 where Baker suggests that stack should be close to cache in size, which absolutely boggled my mind, and doesn't match my intuition (or Baker's opponent's findings) at all.

What kind of effects have you found with different stack sizes?

[justinethier]

Regarding stack sizes, on the one hand a large stack size means minor GC (evacuating the stack) happens less frequently. But when it does there are more objects to trace so there is a longer delay. On the other hand a small stack will have a faster GC but that GC will run more frequently. So there is a trade-off rather than a clear winner. For Cyclone we ended up going with a "medium" stack threshold of 500 K before running GC.