Hi all, What is the status of Rob Ennals' optimistic evaluation work? I'm told that it has been removed from GHC. This is extremely depressing to me. Without such a feature available, it becomes very difficult to write programs that process large amounts of data in Haskell. In many such applications, strictness annotations become not just important for performance, but necessary to get a program to function at all. With optimistic evaluation, GHC and Haskell would have been at least potential candidates for my programming work in machine learning; without it I fear that this is no longer the case. Will optimistic evaluation ever be present in GHC again? What is its priority, compared to other features which are being implemented? What was the last (if any) version of GHC with optimistic evaluation present? Thanks, Frederik
On Tue, Feb 07, 2006 at 08:28:51PM +0000, Frederik Eaton wrote:
What is the status of Rob Ennals' optimistic evaluation work? I'm told that it has been removed from GHC. This is extremely depressing to me. Without such a feature available, it becomes very difficult to write programs that process large amounts of data in Haskell. In many such applications, strictness annotations become not just important for performance, but necessary to get a program to function at all.
With optimistic evaluation, GHC and Haskell would have been at least potential candidates for my programming work in machine learning; without it I fear that this is no longer the case.
Will optimistic evaluation ever be present in GHC again? What is its priority, compared to other features which are being implemented? What was the last (if any) version of GHC with optimistic evaluation present?
I am not sure this is similar to optimistic evaluation, but I was wondering if it would be possible to find space-leaks at runtime and try to reduce them. There's also a related idea to decrease the priority of garbage producing threads (and/or increase for garbage reducing threads). This way it would be possible to make the idiomatic Haskell 'wc' (word count) implementation space efficient with some simple 'par' annotations: main = do cs <- getContents let nChars = length cs nWords = length (words cs) nLines = length (lines cs) (nChars `par` nWords `par` nLines) `seq` return () print (nChars, nWords, nLines) (I am not sure I used "par" correctly, but I hope you know what I mean). Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote:
There's also a related idea to decrease the priority of garbage producing threads (and/or increase for garbage reducing threads). This way it would be possible to make the idiomatic Haskell 'wc' (word count) implementation space efficient with some simple 'par' annotations:
main = do cs <- getContents let nChars = length cs nWords = length (words cs) nLines = length (lines cs) (nChars `par` nWords `par` nLines) `seq` return () print (nChars, nWords, nLines)
(I am not sure I used "par" correctly, but I hope you know what I mean).
Intuitively, the three threads computing nChars, nWords and nLines would chase each other on the cs list. The thread that is causing bigger memory residency would get his priority lowered. At last it would be stopped and other threads would have a chance to consume what was produced. Thus longer and longer prefixes of cs could be reclaimed. But I am not sure it's possible to implement. One question is how to measure thread's impact on memory use. Counting allocations seems to be not enough. In our example, the "nWords" threads consuming what was produced by the "nChars" thread, would probably allocate at the same speed as "nChars" thread (it creates the word list), but it should get a higher priority. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote:
... I was wondering if it would be possible ...
There's also a related idea ...
I've heard that the implementation of optimistic evaluation was rather complex, which was the main reason not to include it in GHC (yet). That's why I wonder if there is some other low hanging fruit. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland
participants (2)
-
Frederik Eaton -
Tomasz Zielonka