sutton036

An old post from Stack Overflow : In short, even with the fix in the latest GHC, Haskell is still incapable of providing a dictionary (mutable or immutable) that is competitively efficient. Haskell's hash tables were  32× slower than alternatives like C++ and .NET  with GHC 6.10. That was partly due to a  performance bug in the GHC garbage collector that was fixed for GHC 6.12.2 . But Simon Marlow's results there show only a 5× performance improvement which still leaves Haskell's hash tables many times slower than most alternatives. Purely functional alternatives are also much slower than a decent hash table. For example,  Haskell's IntMap  is 10× slower than .NET's hash table . Using F# 2010 and  the latest Haskell Platform 2010.2.0.0  (released yesterday!) with GHC 6.12.3 on this 2.0GHz E5405 Xeon running 32-bit Windows Vista to insert 20M int->int bindings into an empty hash table we find that Haskell is still 29× slower than F# in real time and ...

I've started a new Google Group to discuss issues surrounding the practical use of former research around functional programming including issues such as designing purely functional data structures to leverage mainstream virtual machines (JVM and CLR) and garbage collectors, wrapping mainstream libraries (e.g. Windows Presentation Foundation) to improve productivity from modern functional languages and so on. Please join us here .

The Raspberry Pi uses an older ARMv6 core which is not well supported by modern software. In particular, Mono's JIT apparently doesn't support the hardware-accelerated floating point instructions used by that version of the ARM instruction set. The solution is apparently to use the soft-float version of Raspian that emulates floating point instructions in software (which will be extremely slow). However, trying to compile the current version of the F# sources on Github using the stock Mono (2.10.8) fails with the following null reference exception from within the F# compiler: error FS0193: internal error: Object reference not set to an instance of an object Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object   at Microsoft.FSharp.Core.FSharpFunc`2[Microsoft.FSharp.Collections.FSharpList`1[System.String],System.String].InvokeFast[CcuThunk] (Microsoft.FSharp.Core.FSharpFunc`2 func, Microsoft.FSharp.Collections.FSharpList`1 arg1...

Functional languages require infrastructure that inevitably adds overheads over what can theoretically be attained using assembler by hand. In particular, first-class lexical closures only work well with garbage collection because they allow values to be carried out of scope. Beware of self selection. C acts as a lowest common denominator in benchmark suites, limiting what can be accomplished. If you have a benchmark comparing C with a functional language then it is almost certainly an extremely simple program. Arguably so simple that it is of little practical relevance today. It is not practically feasible to solve more complicated problems using C for a mere benchmark. The most obvious example of this is parallelism. Today, we all have multicores. Even my phone is a multicore. Multicore parallelism is notoriously difficult in C but can be easy in functional languages (I like F#). Other examples include anything that benefits from persistent data structures, e.g. undo buffers are triv...

I want to learn the theory behind garbage collection. How do i go about it? I am also a dabbler interested in garbage collection (to the point that I wrote my own garbage collected VM called  HLVM ). I learned by reading as many research papers on garbage collection as I could get my hands on and by playing with the ideas myself, both raw in my virtual machine and also by writing memory-safe high-level simulations. The obvious answer is - a compiler textbook... The question is, is it necessary to learn lexical analysis, parsing and other stuff that usually precedes garbage collection in a text? The lexical analysis, parsing and other stuff is not relevant to garbage collection. You might get an outdated cursory overview of garbage collection from a compiler book but you need to read research papers to get an up-to-date view, e.g. with regard to multicore. In short, what are the prerequisites to learning about Garbage collection theory? You need to know about basic graph theory, poi...

GCs work by tracing reachable heap blocks starting from a set of global roots (global variables, thread stacks and CPU registers). GCs lie on a sliding scale from snapshot to on-the-fly. Snapshot GCs work from a snapshot of the global roots and heap topology. On-the-fly GCs incrementally update their interpretation of the heap as the mutators run. Wholly snapshot GCs attain high throughput because the collector runs almost entirely independently of the mutators but have high latency because taking a snapshot incurs a pause. Wholly on-the-fly GCs attain low latency because everything is done incrementally but low throughput because of the fine grained communication between the mutators and GC. In practice, all GCs lie somewhere between these two  extremes.  VCGC  is primarily a snapshot GC but it uses a write barrier to keep the collector apprised of changes to the heap topology.  Staccato  was the world's first parallel and concurrent and real-time GC but it sti...

From this Stack Overflow question: If I understand it correctly, functor gives you a new set of functions from a type you provide More generally, functors map modules to modules. Your  Set  example maps a module adhering to the ORDERED_TYPE  signature to a module implementing a set. The  ORDERED_TYPE  signature requires a type and a comparison function. Therefore, your C# is not equivalent because it parameterizes the set only over the type and not over the comparison function. So your C# can only implement one set type for each element type whereas the functor can implement many set modules for each element module, e.g. in ascending and descending order. Even if functors are just generics-for-namespace, what's the significant advantage of that approach? One major advantage of a higher-order module system is the ability to gradually refine interfaces. In OOP, everything is public or private (or sometimes protected or internal etc.). With modules, you can gradua...