It's Friday night, and I have just finished my first week of my second year at the Australian National University. This is the reason I haven't written anything here for the last week, and my blog rate will probably remain low for the next 10 weeks... but I'll do my best! This semester I'm doing some rather interesting courses (and some not so much...) COMP2300 - Introduction to Computer Systems Which is about.. well computer systems. It covers topics like binary representations of numbers, C, computer architecture, etc. The thing I am however most looking forward to the most will...
February 2009 Archives
So what's new? Well, i split it up a bit, into three modules: Data.AVar, the classic interface, Data.AVar.Unsafe, the same as Data.AVar, but it throws any exceptions encountered by the variable, instead of passing them back to the user, and Data.AVar.Internal, which contains the code for the actual for AVars, and the datatypes used by them...
The other day, I put my AVar package on hackage. Doing so taught me more than i expected it would, mainly that i need to do more testing of cabal packages before submitting them, and also to make sure you've exported all the functions you need to actually use the package (I forgot to put putAVar in the module exports -_-). So i'm up to release 0.0.3, without much work being done at all (although, I can't think of much more to do really). With the current release, i think that all exceptions that may occur from functions passed by...
Today, I've been talking with some people in #haskell about this ASTM thing, and I've had some great input, mainly from Stefan Ljungstrand (ski on #haskell), along with quicksilver and Simon Marlow, and I thought I'd share the changes I've put in with their help. I'm still not sure how useful this stuff is, but it's fun and I'm learning. If you're wondering what i'm on about, see this post. So, the new features I've added are mainly to do with exception handling, so that variables don't 'die' if you call tail on [], they report the error, and don't...
...an idea for the emulation of mutable variables, using functions as a way of storing the values in an accumulating parameter of sorts. They could safely be shared between threads, and could (and sort of do) support atomic actions...
So, I'm putting a call out to see if anyone else can either think of a better way to get the answer than the current entry, or any tips about reducing memory usage. If you come up with anything, I'd love to hear from you.
I've been talking to Stephen Blackheath on the #haskell-in-depth channel, and he's just submitted another new program to the shootout. This entry is for the regex-dna problem. For this benchmark, each language is limited by the speed of the regex library it's using. Right... let me see. Here's what I did; I am not certain, but it seems that forcing the evaluation of s1, s2 and s3 (the blobs of input data) before parallelizing the processing gave better CPU utilisation. I also changed the part at the end where it does large numbers of pattern substitutions, so that it updated...
So I've been taking full advantage of the new #haskell-in-depth channel, and with the thanks of blackh and others, I've made a few more changes, and I've shaved another whole 30 seconds of my already not too shabby 1m17s. I'm now down to 47.215s, making a saving of 30s, or a saving of 39%. If you're wondering what I'm on about, take a look at this post for the story of my n-bodies program so far, and this port for what my code looked like before. So how did I do it this time? Well, I decided STRefs weren't necessary,...
For the last week or so, ozy` has been working on improving the haskell bundle in TextMate. He's done a lot of work, and it really makes a difference. The changes should be in SVN sometime soon I hope...
The reason I got interested in this problem was because I decided to take a look at the current haskell submission. I was a little horrified when I say it as all pointer nonsense and back magic. Full of stuff haskell can do fine (And possibly better and more safely that other languages), but should really be avoided where possible. I wanted to see if you could write a fast version, using more accessible techniques.
So I've been playing with this n-bodies thing again, and while I haven't managed to get all that much closer to the likes of C, C++, or even the current Haskell entry. BUT! I did manage to make my program almost exactly twice as fast as it was. I used a few simple tricks from the performance part of the haskell wiki, mainly the use of unsafeRead and unsafeWrite from the Arrays page, and the use of -fexcess-precision to speed up the Double computation. For those interested in my progress (no one), here's my current code: {-# OPTIONS -O2 -funbox-strict-fields...
