Ben Lippmeier wrote:
I guess this is true, but only if you are trying to find the optimal solution (or prooveably optimal
I thought the "lazy functional languages are great for implicit parallelism" thing died out some time ago - at least as far as running the programs on conventional hardware is concerned.
Designing an algorithm that breaks apart a "sequential" lazy program into parallel chunks of the appropriate size is **HARD** (with double asterixes). The time and space behavior of a lazy program is complex enough for the _programmer_ to reason about, let alone an automated analysis - which has no knowledge of what the program is actually trying to do.
solution)... There must me many ad-hoc solutions with reasonable performance. Perhaps a good first step would be a solution bounded in the worst case by the sequential execution time (IE the multi-CPU version would be no slower than the single CPU version, excluding the locking overhead). If something were to win on 2/4/8 cpu machines most of the time I think it would
be useful.
Keean.
_______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
