sutton036

Microsoft made all tuple types reference types in the interests of simplicity. Objectively, this was a mistake. Tuples with more than 4 fields are very unusual and should be replaced with a more typeful alternative anyway (such as a record type in F#) so only small tuples are of practical interest. My own benchmarks showed that unboxed tuples up to 512 bytes could still be faster than boxed tuples. Although memory efficiency is one concern, the dominant issue is the overhead of the garbage collector. Allocation and collection are particularly expensive on .NET because its garbage collector has not been very heavily optimized (e.g. compared to the JVM). Moreover, the default .NET GC (workstation) has not yet been parallelized. Consequently, parallel programs that use tuples grind to a halt as all cores contend for the shared garbage collector, destroying scalability. This is not only the dominant concern but, AFAIK, was completely neglected by Microsoft when they examined this probl...

GCs can pointer-bump allocate into a thread-local generation and then rely upon copying collection to handle the (relatively) uncommon case of evacuating the survivors. Traditional allocators like malloc often compete for global locks and search trees. GCs can deallocate many dead blocks simultaneously by resetting the thread-local allocation buffer instead of calling free on each block in turn, i.e. O(1) instead of O( n ). By compacting old blocks so more of them fit into each cache line. The improved locality increases cache efficiency. By taking advantage of extra static information such as immutable types. By taking advantage of extra dynamic information such as the changing topology of the heap via the data recorded by the write barrier. By making more efficient techniques tractable, e.g. by removing the headache of manual memory management from wait free algorithms. By making more efficient techniques tractable, e.g. by removing the headache of manual memory management from wait ...

Metaprogramming is a real weak point of C++. Most of your effort will be expended trying to manipulate trees. The core advantage of OCaml and F# in this context is pattern matching over union types (and not functional programming) precisely because this makes it so much easier to manipulate trees. Historically, OCaml and F# come from the ML family of languages and were bred specifically for this application domain. I used LLVM via its OCaml bindings to write  HLVM , which includes both standalone and JIT compilation to native code, multicore-capable garbage collection, foreign function interface, tail call optimization and many other features. The experience was very pleasant. My only advice would be to keep track of which LLVM features are tried-and-tested and which are experimental because you don't want to depend on anything experimental (e.g. the GC support when I wrote HLVM). You can easily use  System.Reflection.Emit  to generate CIL from F# but you obviously won't ...

Concurrent programming regards operations that appear to overlap and is primarily concerned with the complexity that arises due to non-deterministic control flow. The quantitative costs associated with concurrent programs are typically both throughput and latency. Concurrent programs are often IO bound but not always, e.g. concurrent garbage collectors are entirely on-CPU. The pedagogical example of a concurrent program is a web crawler. This program initiates requests for web pages and accepts the responses concurrently as the results of the downloads become available, accumulating a set of pages that have already been visited. Control flow is non-deterministic because the responses are not necessarily received in the same order each time the program is run. This characteristic can make it very hard to debug concurrent programs. Some applications are fundamentally concurrent, e.g. web servers must handle client connections concurrently. Erlang is perhaps the most promising upcoming la...

The fundamental limitation is simply that the JVM does not provide tail calls in its byte code and, consequently, there is no direct way for a language built upon the JVM to provide tail calls itself. There are workarounds that can achieve a similar effect (e.g. trampolining) but they come at the grave cost of awful performance and obfuscating the generated intermediate code which makes a debugger useless. So the JVM cannot support any production-quality functional programming languages until Sun implement tail calls in the JVM itself. They have been discussing it for years but I doubt they will ever implement tail calls: it will be very difficult because they have prematurely optimized their VM before implementing such basic functionality, and Sun's effort is strongly focused on dynamic languages rather than functional languages. Hence there is a very strong argument that Scala is not a real functional programming language: these languages have regarded tail calls as an essential ...

I believe the answer is certainly yes, ideally you should learn all three languages because each one has something to offer but F# is the only one with a significant future so, if you can only feasibly learn one language, learn F# by reading my  Visual F# 2010 for Technical Computing book  or subscribing to our The F#.NET Journal . Longevity Microsoft committed to supporting F# when they released it as part of Visual Studio 2010 in April. So F# is guaranteed a rosy future for at least a few years. With a powerful combination of practically-important features like a high performance native-code REPL, high-level constructs for parallelism built-in to .NET 4 and a production-quality IDE mode, F# is a  long  way ahead of any other functional programming language in terms of real world applicability now. Frankly, nobody is even working on anything that might be able to compete with F# in the near future. My own open source  HLVM  project is an attempt to do so b...

In 2005, the world's first multicore consumer CPUs became commercially available. In 2007, Intel introduced their first quad-core processors and predicted that the number of cores would continue doubling and reach 64 cores by 2011. The following graph shows this prediction and the actual number of cores that shipped on Intel's CPUs: Interesting to see how big the discrepancy is now. We were supposed to get 64-core CPUs last year but, instead, the widest Intel CPUs shipping in Dell desktops today have just 6 cores and the widest Intel CPUs available have just 10 cores. After Larrabee and the SCC, Intel are now hyping a Many Integrated Core (MIC) architecture but a consumer version has yet to materialise.