Functional languages, memory management, and modern language runtimes
At the Mostly Functional workshop at the Turing Festival in Edinburgh yesterday, I attended a very interesting presentation on the performance of compilers of functional languages for the JVM by Wing Hang Li and Jeremy Singer. The whole talk was interesting, but some of the graphs were electrifying.
What Wing had done was analyse the emitted code size of methods emitted by the different compilers (Scala, Clojure, Jython and JRuby). These showed that the code emitted by these compilers was systematically different — very different — from code emitted by the Java compiler. Typically, they generated smaller code units ('methods', in the terminology of the presentation) — this especially true of Scala — and made much more use of stack. But of more interest to me was this: "We examine the distribution of object sizes, weighted by their dynamic allocation frequency. The size of java.lang.Object is 16 bytes for the JVM we use. The boxplots in Figure 6 show that the object size for most non-Java JVM languages is dominated by only one or two sizes. This can be seen from the median object size in the unfiltered JRuby and Jython boxplots and the filtered Clojure and Scala boxplots. However, the median object size for Java varies between 24 to 48 bytes. By comparing the unfiltered and filtered boxplots, we see that Clojure and Scala use smaller objects more frequently than Java." This is kind of what one would expect. Functional languages should (hopefully) encourage programmers to use smaller units of code than imperative languages; and, because functional programming paradigms make much more use of recursion than typical imperative paradigms, you'd expect to see more use of stack. But more significantly, a great deal of the memory allocation is likely to be small fixed size objects (CONS cells, and other things like e.g. ints and doubles which will fit into the memory footprint of a CONS cell), and that furthermore these small objects are likely to be allocated and deallocated much more frequently than larger objects. And this takes me right back into ideas about the design of LISP runtimes that I was interested in twenty five years ago.
Given this pattern of a rapid churn of small fixed-size objects a naive heap allocator will tend to fragment the heap, as small but still-live objects become sparsely scattered through heap space, ultimately requiring a full mark-and-sweep before larger objects can be allocated. Now I'm certain that the Java heap allocator is anything but naive, but it's unlikely to be optimised for large numbers of rapidly allocated and deallocated equal sized objects.
Ultra-low impact housing and public policy
Politicians are once again talking openly about how to reduce the cost of housing. I know how to do this, and have a genuinely modest proposal.
This house, as I've described earlier, is almost entirely bio-degradable. Without maintenance, it would fairly rapidly collapse into a pile of rotted timber and straw on the forest floor, marked only by the stove, the bath, the water pipes and the glass; and, as these things are inherently valuable and recyclable, I would imagine someone else will rob them out long before the house gets to that state. With reasonable maintenance, I believe the house could last — and be comfortable and habitable — in the long term. Sixty years at least, perhaps twice that; as long as a conventional modern house is designed to.
This house would not pass building warrant, and there are some good reasons for that. It has no foundations; it is (intentionally) very close to trees; it has some fire safety deficits. Notably, it would be impossible to get a fire engine to it in the event of a fire, but also there is no fire separation between the walls and the roof structure, and I have not yet fitted the fire ladder which I intend to fit from the rear window. And it seems to me that it would be very hard to draw up building regulations which this house would pass which would not allow very unsatisfactory buildings also to pass.
Modelling the change from rural to urban
This essay is about software, not the real world! If you're interested in my thoughts on real world rural policy issues, check the Rural Policy category on the right.
In the real world — in Northern Britain particularly, but I think this holds for many other places — there are three essential layouts of rural communities:
- Non-nucleated settlements, where dwellings are scattered at least tens of metres apart over quite a wide area; highland crofting settlements are typically of this form.
- Nucleated settlements, where dwellings are grouped closely around a central feature such as a village green or a pond; villages of this form are typically older villages, especially in areas of Anglian settlement. Rhonehouse is a good example locally.
- Linear settlements, which are a special case of nucleated settlements, where dwellings line the sides of an (often broad) street. These settlements typically are medieval in origin and reflect the runrig agricultural pattern — each house had inbye land stretching back from the street. Moffat, Lochmaben and Thornhill are local examples.
Populating a game world
(You might want to read this essay in conjunction with my older essay, Settling a game world, which covers similar ground but which this hopefully advances on)
For an economy to work people have to be able to move between occupations to fill economic niches. In steady state, non player character (NPC) males become adult as 'vagrants', and then move through the state transitions described in this document. The pattern for females is different.
Basic occupations
Genetic buildings
Building selection based on location
The objective of this note is to create a landscape with varied and believable buildings, with the minimum possible data storage per instance.
Like plants, buildings will 'grow' from a seed which has northing and easting attributes. These locate a position on the map. Again, like trees, some aspects of the building type selector are location based. Aspects of the location which are relevant to building type are