New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of C#? #1

Closed
t0yv0 opened this Issue Feb 21, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@t0yv0
Contributor

t0yv0 commented Feb 21, 2014

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

This comment has been minimized.

Contributor

polytypic commented Feb 21, 2014

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

This comment has been minimized.

Contributor

t0yv0 commented Feb 21, 2014

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

@t0yv0 t0yv0 closed this Feb 21, 2014

@dsyme

This comment has been minimized.

dsyme commented Apr 11, 2014

Hi Vesa,

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

Thanks, don

@polytypic

This comment has been minimized.

Contributor

polytypic commented Apr 11, 2014

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

This comment has been minimized.

dsyme commented Apr 15, 2014

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

@buybackoff buybackoff referenced this issue Oct 19, 2016

Closed

Migrate from F# to C# when possible #68

2 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment