Code Feedback

[Drew Haven]

I wrote some code up for a quick experiment and I was wondering if
anyone would like to give some feedback. I'm curious if anyone sees
any good ways to improve it, mistakes I made, etc.

After reading http://qbonnard.github.com/2011/10/25/The_answer_is_2011_the_question_can_be_brute_force.html
I thought, "damn, that's a lot of code. I bet I could do this in
Haskell much simpler." So I got to work, and after a few iterations,
here is what I came up with:

https://github.com/periodic/AnswerIs2011

Note that if you want to take advantage of the parallel stuff, you'll
need to compile with -threaded and probably -rtsopts, then pass +RTS -
N# on the command line after the target number.

Run it by running "./Main 2011" for example, but that won't have many
results. Run it with a target of 1 for lots of output.

[David Terei]

I just had a quick glance over it. Looks very nice! I don't think
there is much to improve about it.

Only suggestion would be to investigate using a different mechanism
for parallelism. Your program looks like it could use safer forms of
parallelism such as 'par' and 'pseq', parallel strategies I think this
form of parallelism is called in the Haskell community. If wanting to
use explicit threads, using STM or Channels might be a safer choice in
replace of some of the MVar's to avoid any chance of deadlock.

http://community.haskell.org/~simonmar/par-tutorial.pdf

Final thing, be careful of the fact that MVar's aren't strict:

http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#concurrent.useful.nonstrict

Haven't run your code so can't say but on the surface it looks like
this may be a problem for your current code.

Cheers,
David

[Drew Haven]

Well, it worked and seem to run fairly fast, so no huge deadlocks or anything.  I was relying on some semantics of the program in the parallelism, like that the producer is assumed to be finished and the thread terminated if all the consumers have found no more input and thus terminated.

I'll take a look at the strategies.  They look... intimidating.

Thanks for taking a look.

Drew Haven
drew....@gmail.com

[David Terei]

On 2 November 2011 11:20, Drew Haven <drew....@gmail.com> wrote:
> Well, it worked and seem to run fairly fast, so no huge deadlocks or
> anything.  I was relying on some semantics of the program in the
> parallelism, like that the producer is assumed to be finished and the thread
> terminated if all the consumers have found no more input and thus
> terminated.

Sure. The danger is as always with threaded programming that extending
/ maintenance is harder. I had to think carefully when reading your
code about the order of various takes and puts. There isn't anything
'wrong' with the method you chose but given you're writing this for
fun / experience I think other forms of parallelism in Haskell are
more 'beautiful'.

> I'll take a look at the strategies.  They look... intimidating.

Yeah they are a little but I think the tutorial Simon Marlow wrote
recently and also recent changes in the design with a lot more
infrastructure around now to help in using the spark parallel facility
should go a long way to changing this.