Tracking corner edge cases of F# performance / Usage of new CLR features

[realvictorprm]

Hello fellows!

Very sorry for disturbing you all with a more general issue / topic.

I would like to discuss / track here possibilities for performance improvements in the F# compiler and about how most likely new upcoming CLR features can be used for this.

---

Current list contains:

• Discussing stack allocation, see here

---

First point by me is referring to this issue from the CoreCLR repository. It's discussing about implementing new features and or routines which allow stack allocations for small object or rather for objects which are obviously only alive for a single method (and therefore can be cleaned up automatically without GC).

PS:
If this is wrong here I'm sorry, I thought it's right here because the compiler is located here and it's more about improving existing language features instead of adding new language features. Please give me feedback!

[zpodlovics]

It seems that the object stack allocation feature is commited, but may require other changes to work:
dotnet/coreclr#6653

My guess is that most of the clr performance improvement will be somehow memory related (eg.: allocation, representation, prefetch, etc). The other side of the story is the language and the language compiler itself. However no amount of of clr performance improvements will save you from crafting performance critical code properly in F#.

It would be good to have something like this for F# for performance critical code, to track down the unwanted allocations:
https://github.com/Microsoft/RoslynClrHeapAllocationAnalyzer

This language "cost" is under heavy research, with significant results:
POPL 2017: Towards Automatic Resource Bound Analysis for OCaml
O’Camelot: Adding Objects to a Resource Aware Functional Language
http://www.raml.co/publications.html
http://lambda-the-ultimate.org/node/5021

[dsyme]

@realvictorprm @zpodlovics I think it is good to have regular discussions about how new CLR features and/or performance improvements interact with F# code.

Probably the best way to do this is through an individual "discussion" item for each such feature, and an individual language-suggestion/RFC/PR/issue for each concrete problem identified.

Getting F# input into the CLR discussions themselves is also highly valuable.

[realvictorprm]

Its great to have positiv feed back @dsyme!

So should I make a separate one on the language suggestion repository?

@dsyme It would be awesome, if you show up in the Core CLR repository issue!

[zpodlovics]

Several updates mostly from C# land:

Interop:

C# 7.2: Expose the CLR protectedAndInternal accessibility level in C# as private protected
https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/private-protected.md

C# 7.2: Ref extension methods on structs
dotnet/csharplang#186
dotnet/roslyn#165

Safety:

C# 7.2: The "readonly references" feature is actually a group of features that leverage the efficiency of passing variables by reference, but without exposing the data to modifications.
https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/readonly-ref.md

C# 7.2: Compile time enforcement of safety for ref-like types. The main reason for the additional safety rules when dealing with types like Span and ReadOnlySpan is that such types must be confined to the execution stack.
https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/span-safety.md

Performance:

C# 7.2:
https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/conditional-ref.md

Proposal: Struct Lambdas
dotnet/csharplang#1060

Proposal: Static Delegates
https://github.com/dotnet/csharplang/blob/master/proposals/static-delegates.md

Proposal: Blittable Types
https://github.com/dotnet/csharplang/blob/master/proposals/blittable.md

[realvictorprm]

Thanks @zpodlovics

Support for Span etc. Would be nice too

I'm not into the plan of Microsoft with F# and C# Interop and or eventual usability of those C# features. @dsyme can you elaborate?

[dsyme]

Closing this in favour of the specific RFC on Span. Other issues shuold be tracked by language suggestions