It's friday night. Finally back at the hotel without a meeting or party or a session to go to. What else is there to do but port benchmarks of debatable value to my favorite new non-Java language: Fan. Earlier in the I was directed to this blog post detailing some performance problems with groovy. Yes, I know the blog is old. That's not the point I want to make here. This week at Javaone, there was a presentation doing some more performance comparisons between languages on the JVM. This one caught my eye because it's the first one I've seen in the wild that included Fan. So this got me thinking about year old post and the ray tracing exercise. How would fan hold up? I decided to find out. Because there's no better way to spend a Friday night after long conference week, right? The Fan code isn't idiomatic (I'm not that bored tonight). It's just a quick and dirty port from the Java source to Fan. For reference, I reran the Java version and then the Fan version. This test is running on OS X and Java 1.6u13. Without further hand waving, here's the results:

time java -cp . ray 8 512

real	0m14.210s
user	0m12.443s
sys	0m1.313s

time fan tracer::RayTest 8 512

real	0m17.700s
user	0m15.832s
sys	0m0.672s

As you can see, the performance is really quite good. I'll probably play with the source over the next few days and see if I can't improve it a bit. The fan code is pretty rough so there's probably a fair bit to be done to speed that up a bit. I'll attach the source so if anyone else is interested the source will be available. I have to say, though, that's not too shabby at all.

I've been watching the Fan language for some time now after seeing it first mentioned on on Stephen Colebourne's blog. Or maybe it was Cedric's. Anyway, it caught my interest and i've been a voyeur ever since. I'd peek into the site every few weeks or and see what was up. Recently I decided to really give it a go. Since I had so many other side projects languishing, what's one more, right? Now, I'm not one to just sit down and start writing random code. I need a goal. A Project. I finally found one: porting mercurial from python to fan. Now, I know what you're probably asking. "Are you daft? Why would anyone want to do that?" Well, there are a few answers to that. Foremost, is that it gives me something concrete to write in Fan. Other, more ancillary, reasons include not really needing platform specific builds (get rid of the C code!) and seeing how Fan stacks up speed wise to the python version.

Now, that last reason is the tricky one. The first is easy enough to fulfill no matter how far down this road I go. I mean, I'll be learning fan regardless of how functional this port is. But to really compare speed, one has to have equally functional software. I *could* just write some benchmarks blahblahblah but those are relatively boring and my python chops are a bit rusty. Having me write python code for a benchmark wouldn't fair at all to python. And probably just a little embarrassing for me to have that code out in the wild.

So my question now is, how far do I take this? I like the fan language quite a bit. I'm far from having mastered it (especially as parts of it are still under heavy development and discussion). But so far, it's not too bad at all. It's like a cleaned up Java 2.0. I've found a number ways that *I* would "clean up" the current python code (I know "clean" is subjective and probably will start a flame war but that's not the point of all this). I'm almost to the point where I'm going to start getting into some heavy lifting of hg protocols and the like. I'm not sure have much further I really want to go down this path but so far I'm having fun.

If you're looking around for a new language to try or you've been thinking about fan, you should definitely give it a spin. It's probably a little too early to commit an enterprise to since there's still some evolution going on. And some IDE support would be nice. (I do have Komodo Edit set up to parse the build output but no syntax support yet...) It's definitely an interesting option if you have mixed deployment environments, though.

Some Post JavaOne Fun

I'm a big fan