Hi, In general, when working in the IO monad, it guarentees that the order of operations is the same as how it's specified. For instance: main = do putStrLn "hi" putStrLn "bye" could not possibly output "bye" before "hi". What if I don't care about this? Is there any way to tell the compiler that it is free to reorder these? 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. The only thing I can think of would be to define a new nonsequential IO monad that basically used unsafePerformIO to do the computations. So it would basically transform the above from to: main = unsafePerformIO (putStrLn "hi") `seq` unsafePerformIO (putStrLn "bye") and then order wouldn't be guarentee, right? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
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
participants (2)
-
D. Tweed -
Hal Daume III