On Sat, 16 Feb 2002, Hal Daume III wrote:
The reason I ask is that I'm generating a FSM description file and it doesn't matter which order I list the transitions in. I'm curious whether I could get the program to run any faster if I don't care about order.
I'm a bit confused here: assuming that by faster you mean decreased _total_ run-time (and not becasuse, e.g., you're piping the input to another program and want an description lines to be produced at regular intervals), why is the IO monad ordering going to be the big factor in what determines this? I wouldn't imagine that in a non-concurrent Haskell program there's any `locking' of IO resources so there can't be contention for that. I can imagine that you could dramatically decrease run-time on machines with low memories by re-ordering some computations so that the heap size is always small (and so you get less swapping) rather than generating lots of heap items long before they are used, this would presumably be going on in the standard functional parts of your program. And here you only ever get (ignoring the results of strictness analysis) Haskell's standard evaluation order. (I.e., you could write a monadic wrapper which processes a list of lazily produced transition lines, outputting each new line as it becomes available, but I can't think of any way to write the functional part of the computation so that it constructs the list of transitions in such a way that each line is constructed as early as possible.) ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel