LED Lighting

We just replaced our entire hallway lighting with LEDs, in total, that’s 8 halogen bulbs gone. I have to say, I’m fairly impressed for a first generation technology, it’s not perfect, but it does work well.

The good, the bad and the ugly

The new bulbs aren’t as bright as the old halogens, having said that, we bought some of the cheapest LED lights there are, little 1W babies, it’s possible to get ones that are much brighter.

The new bulbs also give off a slightly cooler light than the old, but not as cold as I expected, they’re entirely acceptable in the hallway.

Some maths

The new bulbs cost €5 each, and have a life time of 50,000 hours, as I said, they’re 1W bulbs, so they’re gonna use about 50kWh in their life.

The old bulbs also cost about €5 each, and have a lifetime of 750 hours, they were 25W bulbs. Over the life time of the LED lights, I would have to replace them 67 times, and the would use 1,250kWh.

Electricity costs about €0.15 per kWh at the moment, and I can only imagine that will go up. Lets make a conservative estimate that over the next 50 years, the average price will be €0.20 per kWh.

That puts the price of an LED light over the next 50 years at €15 – €5 for the bulb, and €10 for the electricity. The halogen bulbs meanwhile cost €585 – €335 for the bulbs and €250 for electricity.

I knew that LEDs cost less over time, but honestly, I had no idea it was that much that you saved.


Collecting Non-Memory Resources

A Problem

Let us consider a small problem. We would like to manage resources using a Haskell program, that are not just memory. For the sake of argument we will consider GPU resources. This can be reasonably straight forwardly done by using the IO monad to essentially write an imperative program that manages the resources. But doesn’t this defeat the point of functional programming? We’re losing so many benefits that we normally get, we no longer get to describe only the result of our program, instead we have to describe how to get to it too. Not only that, but we’ve lost our wonderful garbage collection system that allows us to easily avoid all of those nasty segfaults we see in non-managed languages. So, the problem today is, how do we extend the Haskell garbage collector (preferably without playing with the runtime or compiler) to be able to manage all these resources.

An attempt

Let’s consider only one small subset of GPU resources – a shader. What we would like in our Haskell program is a pure value that represents the shader, which we can call on at a later date. We’d like a function that takes our shader code, and produces this pure value, and we’d like the resources on the GPU to be collected when the value is no longer in scope.

compile :: String -> String -> Shader
compile vertexShdrSrc fragShdrSrc = s
    s = doCompile s vertexShdrSrc fragShdrSrc

{-# NOINLINE doCompile #-}
doCompile :: Shader -> String -> String -> Shader
doCompile  s vertexShdrSrc fragShdrSrc =
  unsafePerformIO $ do
    {- Set up our fancy pants shader stuff here -}
    addFinalizer s {- Remove resources from the GPU here -}

What we hope will happen is that we return our shader – s, with a finalizer attached to it. When the garbage collector collects s, it will also collect the resources off the GPU. This all looks rather good, so lets try using it:

myShader :: Shader
myShader =
  compile "some vertex shader source"
          "some fragment shader source"

The result of evaluating myShader is a constant use of s, the definition of this constant is looked up, and replaces it, so myShader is now defined as the right hand side of s. Unfortunately, there’s now nothing that points at s itself, so it’s garbage collected, and all our resources removed from the graphics card.


We’ve tried to find a way of getting automated collection of non-memory resources, but ultimately, not quite got there. I don’t see a way forward from this point, and would love to hear other people’s input on how this sort of management can be done