Use of C#?

[t0yv0]

Hi, thanks for the library, it's looking very useful - fills a big hole in concurrency abstractions in F# :)

Just looking for the first time over the code, why did you settle on using C# for the Core library? Is it really for performance or? I find C# a bit harder to read.

I'll need more time to read/play with this lib. Are there areas where you'd like contributions? Documentation comes to mind..

Thanks!

[polytypic]

Hi,

I initially wrote the synchronization protocols using tail recursive F#
loops. As you know, tail recursive loops are much like gotos with
parameters. Unfortunately, it seems that, the F# compiler is unable to
rewrite tail recursive loops to use the equivalent of gotos except in
rather trivial cases. When I initially rewrote some of the core loops in
C#, it gave an order of magnitude performance improvement. It was quite
painful to write the synchronization logic in C# and I don't think that the
code is "beautiful", but it is an order of magnitude faster than what I was
able to come up with prettier F# code. Well, I also tried using lower
level while -loops in F# and could recover some performance, but then one
needs to use mutable flag variables and such and the code becomes rather
ugly - and doesn't perform as well as the tangled gotos one can write in C#.

Contributions, especially longer examples and documentation - perhaps in
the form of blog posts - are more than welcome. :)

-Vesa

On Fri, Feb 21, 2014 at 5:05 PM, Anton Tayanovskyy <notifications@github.com

wrote:

Hi, thanks for the library, it's looking very useful - fills a big hole in
concurrency abstractions in F# :)

Just looking for the first time over the code, why did you settle on using
C# for the Core library? Is it really for performance or? I find C# a bit
harder to read.

I'll need more time to read/play with this lib. Are there areas where
you'd like contributions? Documentation comes to mind..

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[t0yv0]

Hey, that's a real shame about F#/FSC.. Yeah good call using C# then. Will see what I can do for contributions. Thx..

[dsyme]

Hi Vesa,

if you could report this issue to visualfsharp.codeplex.com,with a few good repros we'd be grateful.

Thanks, don

[polytypic]

I probably don't have the initial F# code anymore, but when I have the time I'll implement the Ch type with pure F# code. I have extensive experience doing low level direct hardware access programming and optimization at assembly language level on multiple processors (MC68k family (Atari ST & Amiga graphics demo programming), x86 family (e.g. PC graphics programming), SH-4 (low level optimizations on the Dreamcast platform)). I never looked at CIL code generated by F# or C# before starting to optimize the Hopac library stuff and I was quite surprised to see how complex the CIL code generated by the F# compiler for the synchronization loops was. I recall that F# was not only unable to optimize the loops to use gotos, but in the worst cases it generated code to allocate closures for the local functions used in the loops. I've since then spend quite some time looking at CIL code and there are many places where F# generates suboptimal code that, IMO, could be fixed easily by the compiler. I spend some time tweaking the code in F#, but then rewrote the stuff in C# and the performance difference was dramatic (literally a factor of 10 or more). A subset of C# maps rather directly to CIL and I spend some time learning to understand how it goes. Later I've tweaked the implementation by observing the code generated by the JIT (the current 64-bit JIT and RyuJit CTP2) with a debugger.

[dsyme]

Hi @VesaKarvonen,

If/when you find time, it would be fantastic to pinpoint these issues. F# will optimize direct tailcalls from function F to itself into gotos, and other cases of tailcalls use the .tail instructions. So it would be really great to know which cases were not being represented in this way.

For IL codegen improvements it would also be great to have specific examples. So next time you're looking at IL, please do raise issues and we can work with the community to make fixes and incremental improvements.

thanks!
don