Bashmohandes

F# another sharp brother

F# is an ML language truly at home on .NET with smooth interop with other .NET languages. For example, C# and F# can call each other directly. This means that F# has immediate access to all the .NET Framework APIs, including, for example, WinForms and DirectX. Similarly, libraries developed in F# are available for use from other .NET languages.

F# is also compatible with core Caml; and many Caml libraries and applications can cross-compile either directly or with minor conditionally-compiled changes. This provides an easy path for cross-compiling and/or porting existing Caml code to .NET.

Some F# features:

• F# is the first ML language where all the types and values in an ML program can be accessed from some significant other languages (e.g., C#) in a predictable and friendly way.

• F# was the first released .NET language to produce Generic IL, and the compiler was designed partly with this language in mind. The compiler can also produce (non-generic) v1.0 or v1.1 .NET binaries.

• F# supports features that are often missing from ML implementations such as Unicode strings, dynamic linking, preemptive multithreading and SMP machine support.

F# for developers:

• The interactive environment fsi.exe supports top-level development and exploration of the dynamics of your code and environment.

• The command line compiler fsc.exe supports separate compilation, debug information and optimization.

• F# comes with F# for Visual Studio, an extension to Visual Studio 2003 and Visual Studio 2005 that supports features such as an integrated build/debug environment, graphical debugging, interactive syntax highlighting, parsing and typechecking, IntelliSense, CodeSense, MethodTips and a simple project system.

• F# can be used with tools from the .NET Framework, Microsoft's Visual Studio and many other .NET development tools. 

• F# comes with an ML compatibility library that approximates and extends some of the OCaml 3.06 libraries. This means you don't have to use .NET libraries if it is not appropriate.  It is possible to write large and sophisticated applications that can be cross-compiled as OCaml code or F# code, and we take this mode of use very seriously.

F# uses the compilation facilities of the .NET CLR to generate high performance native code via the Common IL intermediary form. F# has the succinctness of a scripting language, and yet static type-checking and type-inference ensure that compact data representations are used and high performance efficient code is generated for all language constructs.

This page gives further tips on improving the performance of your F# code.

Faster code is produced by using the cross module optimizer (the "-O" options).  Not all optimizations are on by default.

Good profiling tools are essential for achieving good performance in practice. F# works seamlessly with a range of memory and CPU profiling tools (see tool support). It is important to learn to use a profiler when developing code for high performance scenarios.

Applications will start-up faster if you produce .NET install-time compiled binary images using ngen.exe. This will work with both verifiable and non-verifiable code, and both debug and non-debug images. 

When using .NET 2.0 use a single invocation of ngen.exe for the final exe of the application:

    ngen install myprogram.exe

When using .NET 1.1 (or 1.0) use:

    ngen mylibrary.dll
    ngen myprogram.exe

• Use profiling tools to identify the key time and space performance characteristics of your code.

• Exception handling is implemented relatively inefficiently on many virtual machines. As a result, do not use exceptions for control within ML programs. This is the primary cause of poor performance in F# code. You can determine if your program is raising and catching exceptions by running under an interactive debugger such as cordbg.exe or Visual Studio. These will typically display exceptions as they are generated, even if subsequently caught.

• The code generation works best with a .NET Common Language Runtime that supports generics. In order to run on non-generic CLRs, an erasure-to-Object model is used over the generated IL bytecode.  This results in some inefficient code sequences, especially when box/unbox operations need to be inserted on arguments in the middle of a complex call sequence. Another result is that some functions will generate many locals and intermediate unwrapping operations. This may also prevent tailcalls from being taken - this happens if the operation returns a polymorphic ('a) value that must be unwrapped/unboxed.

• Top-level values are not GC'd by the .NET CLR. If you have large objects which you wish to be collected then make them local to a function.

• Some corner constructs use implementation techniques that lead to slower execution than would be expected. These can be avoided by using the --fast-sublanguage-only compiler switch that prevents you from using these constructs.