Lane's Blog

I spent some time yesterday profiling roguestar. I do this every few months just to see where things stand, and there are always two culprits at the top of roguestar-gl.prof, every single time:

* typeclass dictionary lookups in inner loops
* Rational

In the first case, I think the simplest solution is to INLINE the puppy. Can the ghc inliner be a little bit more aggressive when it sees dictionary lookups? Inliners are tricky business. I’m not sure I see a simple heuristic. Vaguely: leaf functions that require dictionary lookups need to be specialized.

Rational can sneak into an unsuspecting program through realToFrac, and absolutely *kills* performance.

I sit down thinking to myself, “Ok, today I’m going to streamline my Super Mumbo Jumbo Widget and get 15% faster performance,” or some such goal I set for myself. And I run the profiler and 75% of my time is being spent in fromRational . toRational.

Here we see our hero fighting a recreant with a kinetic sabre. The material spheres front and left can be used to repair yourself, while a phase rifle is to the right. In unskilled hands, such powerful weapons can more dangerous to the user than enemy.

As I’ve found myself repeatedly writing a bit of code that looked vaguely like this:

get :: SomeArrow String (Maybe Thing)

foo :: [Thing] -> FooThing

. . .

getAToZ :: SomeArrow () (Maybe FooThing)
getAToZ = proc () ->
    do m_a <- get -< "a"
       m_b <- get -< "b"
       . . .
       m_z <- get -< "z"
       returnA -<
           do a <- m_a
              b <- m_b
              . . .
              z <- m_z
              return $ foo [a,b . . . z]

It seemed that there would have to be a way to automate this. So I wrote this MaybeArrow (careful, I'm still using 6.8.2 so it's the old arrows with 'pure'.). I know that there is already an ErrorArrow. But ErrorArrow as far as I can see requires ArrowChoice, and I'm not doing that. In the MaybeArrow, if an earlier computation throws a Nothing, then later computations are still allowed to perform side effects, although their outputs are snuffed, which is the behavior I want.

I would appreciate any constructive feedback.

If you're wondering the use case has to do with waiting on several separate pieces of information to arrive from a server and combining them into one output message.

This is what I imagine a very cold (~2000K) red star might look like at sunrise. I’m not sure if it matters whether it is a red giant or red dwarf — the system tries to size the star semi-realistically according to the temperature of the star and the climate of the local planet, so it should have about the same apparent size either way. A blue star would always look very small, even though these stars are always giants, because if you were ever close enough that it looked big, it would just sterilize you.

The mysterious green object in the upper right corner is a cyborg planet killer. It’s really big and powerful, so don’t **** it off.

In other news, for my United Statesian readers, it’s election day! All you have to do is show up, wait in line a little while, and draw a little line to the right arrowhead, or pull a lever or however it’s done in your state. Try not to **** it up. Unless you have electronic voting machines, in which case the cyborgs will take care of it, so don’t bother.

If you have astrophysics brains and don’t mind feeding them to my zombie code monkey, maybe I can make more realistic stars?

Here’s something I’ve been spending waaaay too much time on, but I wasn’t happy with the results the first try, or the second try, or the third try and . . . I can be very stubborn.

This is actually very low resolution. It uses a simple media ray tracer that can handle some common atmosphere models. The tracer runs in a background thread and the result is just pasted onto a sky sphere.

More shots as I refine the lighting.