Skip to content
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

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

Closed
1 task
realvictorprm opened this issue Aug 21, 2017 · 6 comments
Closed
1 task

Comments

@realvictorprm
Copy link
Contributor

realvictorprm commented Aug 21, 2017

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
Copy link

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
Copy link
Contributor

dsyme commented Aug 21, 2017

@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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor

dsyme commented May 18, 2018

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

@dsyme dsyme closed this as completed May 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants