sutton036

After 15 years, Richard Jones has written a new monograph about garbage collection called The Garbage Collection Handbook . This supercedes his previous seminal book on the subject Garbage Collection: algorithms for automatic dynamic memory management . In particular, this new book covers state-of-the-art techniques including parallel, incremental, concurrent and real-time garbage collection algorithms. I'll post a review as soon as I've read my copy!

The advantages and disadvantages of the OCaml programming language. Pros: More powerful type inference than any other language: OCaml even infers union and class types! Powerful module system lets you parameterize modules over other modules easily and safely with full compile-time checking and minimal run-time overhead. Structural typing of modules, polymorphic variants and classes improves brevity, closing the gap with dynamic languages, but can obfuscate error messages. Powerful integrated macro system lets you alter the language's syntax on-the-fly and write parsers quickly and easily. Good serial performance from the x64 code gen. Easy-to-use REPL. Lots of high-quality tools and libraries. Cons: No overloading can make numerical code over many different types (e.g. complex numbers, vectors and matrices) tedious. Poor multicore support means poor performance on today's computers. Some basic functionality missing (e.g. no 32-bit floats, no try .. finally construct...

The Jet Propulsion Laboratory at Nasa once hosted an interesting web page listing better alternatives to the infamous book Numerical Recipes. Here is a copy courtesy of The Wayback Machine : There is no single alternative to Numerical Recipes. The authors of Numerical Recipes provide a superficial overview of a large amount of material in a small volume. In order to do so, they made many unfortunate compromises. It is naïve to hope that every computational problem can be solved by a simple procedure that can be described in a few pages of chatty prose, and using a page or two of Fortran or C code. Today's ambitions for correctness, accuracy, precision, stability, "robustness", efficiency, etc. demand sophisticated codes developed by experts with deep understanding of their disciplines. We have long ago outgrown the capabilities of the simplistic approaches of 30 years ago. Steve Sullivan has constructed a FAQ (Frequently Asked Questions) list on numerical analysis. ...

Back in August 2010, Martin Odersky raised eyebrows by stating that " Scala is foremost an industrial language ". We commented on this triumph of hope over reality at the time, citing Scala's poor IDE support as a major headache for industrial users that had deterred us from adopting this academically-interesting programming language. This rookie mistake of marketing a product months before it is ready is all too common. Several of our young client companies made the same mistake. One had even been paying an entire sales division not only salaries but bonuses for over a year before their first product was released! The problem is not just the wasted marketing effort but that potential customers are deterred by their bad experiences with the immature product. This is reflected in Jonathan Edwards' recent article " Switching to Plan J ", where he writes: " My experiment with Scala is not working out. It’s just not ready for prime time... " - Jonatha...

Almost exactly a year ago, we published a blog post stating that we had 345kLOC of production OCaml code and 171kLOC of production F# code. Today, we have 261kLOC of production F# code!

Our initial experiments using the new garbage collector design indicate that it dramatically improves the performance of the slowest GC phase (sweeping) as expected, to the extent that it brings the overall performance of our C++ prototype within 10% of OCaml without introducing any of the overheads of generational garbage collection: Moreover the algorithm is very simple and, in particular, parallel and concurrent variants should be much easier to design with this style of collector than with generational collectors because regions are a suitable granularity. The sweep phase of the GC accounted for around a third of the total running time of the entire program using the traditional algorithm with allocated and free lists, with each sweep taking around 70µs. Using the new bitwise algorithm, the sweep phase takes just 100ns and accounts for just 0.7% of the total running time of the program. Our prototype mark region collector using a fake marking phase is now between 2 and 10% slower ...

Our previous articles describing the disadvantages of generational garbage collection and our prototype mark-region memory management system designed for HLVM originally showed that region-based allocation and deallocation has the potential to be only 4-20% slower than OCaml's generational collector. However, our more recent work that was designed to be more realistic by deferring deallocations to bulk GC cycles was significantly slower, around twice as slow as OCaml. There are several differences between the stack-based deallocation scheme used in the first benchmark and the GC-like deallocation scheme used in the second benchmark that have the potential to account for this performance degradation: The mock GC introduced mark bytes into the allocated values and marked them as unreachable when they fell out of scope in the mutator. The mock GC allocated by popping a reference of the top of a region's free list. The mock GC deallocated by pushing a reference onto the free lis...