A friend asked on his blog why gpg —gen-random warns the user: "PLEASE, don’t use this command unless you know what you are doing; it may remove precious entropy from the system!". Below is my essay-like response. It has been edited and posted here as it may help others understand how random number generation and entropy work in a computer system.

I have not written for a while, mainly because I have been trying to convert from a Masters degree to a Ph.D. degree, which is the topic of this article. This might sound strange but that is the normal way of entering a Computer Science Ph.D. course at Melbourne Uni if you do not already have a Masters.

I begun this process in mid May but have been working (or at least looking) towards it since February. So far, as of the 12th of July it is still not complete, even though I thought it was and told Twitter and Facebook that it was. What follows is a blow-by-blow summary of this process.

Today there was a lot of wind that I didn't notice because I was in my office without windows in my comfy office building.  At this time a tree decided it had had enough and attempted to attack our house.  It very nearly took out the power.  As of this writing I'm waiting at home for the SES to come and remove it.  Photos are below.

Just for fun, here are some photos of some things around the csse.unimelb.edu.au offices.

Since the last 'Left vs Right Recursion' article work stealing has been implemented in the Mercury runtime. In this new implementation the --max-contexts-per-thread runtime option is no longer obeyed (bug #144), therefore deeply right-recursive parallel code will run out of memory.

We've implemented a simple transformation in the runtime: All recursive conjuncts in a independent parallel conjunction are ordered as early is possible. This turns right recursion in parallel conjunctions into left recursion wherever possible. Then we noticed the following results for parallelising the ray-tracer.

Livejournal syndication is back!

The video of my presentation, Automatic Parallelism in Mercury, Multicore Miniconf, Linuxconf Australia 2010, Wellington NZ. is now available here. The slides are here

Please do not filter the internet. As many others have pointed out this is a very bad idea.

Previously we described a potential transformation that we believe will increase the amount of parallelism available at runtime, and use a constant number of stacks rather than a linear number of stacks with respect to the number of parallel conjunctions in a singly-recursive predicate. Read more to see the underwhelming results and conclusion.

We are already aware from previous tests that Mercury's current runtime parallelism system is not ideal. So the outcome if this test is not very useful and it should be re-evaluated later once the runtime system has been improved. That said the test is still interesting and the outcome was not what I was expecting.

This is part one, in a (probably) three part series. In this post I introduce the problem, the background information and the hypothesis