[Haskell-cafe] Seeking reference(s) relating to FP performance
I've taken it as an article of faith that performance of FP language implementations has been improving quite steadily over the past few years. I'd like to assert this, but I can't find any clear evidence to support such an assertion. I note that the about Haskell page makes a similar assertion, but it doesn't offer any hint of supporting evidence: [[ Aren't functional programs very slow? They used to be, but the compilers have now caught up. Haskell programs run fast enough for all but the most performance-demanding applications. ]] -- http://www.haskell.org/aboutHaskell.html I'm looking for a reference -- informal will be enough -- that can give an perspective of progress in functional language implementation performance. I'm not looking for a single benchmark that shows a case of blindingly-fast functional code, but a pointer to trends of improving performance. It would also serve my purpose to have indications based on languages other than Haskell (e.g. ML and friends). Any ideas, please? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
At 10:55 28/09/04 +0100, Malcolm Wallace wrote: Keith Wansbrough [EMAIL PROTECTED] writes: I can't believe that a simple wc implementation should be 570 times slower in Haskell than OCaml - could someone investigate and fix the test? With code like this, I'm not surprised! main = do file - getContents putStrLn $ show (length $ lines file) ++ ++ show (length $ words file) ++ ++ show (length file) Space-leak or what? Er, please excuse a dumb question, but I'm struggling to see the problem here. I can see that this requires the original file to be kept for 3-time scanning, so enough memory for the entire file will be required. Is that *the* problem to which you allude? I can't see any other problem here. And why would this put Haskell at a disadvantage? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about function on data type
There's the following alternative. mike data TermOp = TermAnd | TermOr deriving (Show, Eq) data Term = Not Term | Op Term TermOp Term | Literal Char deriving Show assoc (Op (Op t1 op1_2 t2) op12_3 t3) | op1_2 == op12_3 = Op t1 op1_2 (Op t2 op1_2 t3) assoc t = t () = (`Op` TermAnd) (|||) = (`Op` TermOr) tlA = Literal 'A' tlB = Literal 'B' tlC = Literal 'B' tt1 = Not tlA tlB -- Should not assoc. tt2 = tt1 tlC -- Should assoc. tt3 = tt1 ||| tlC -- Should not assoc. tests = putStr $ unlines $ map (show . (\t - (t, assoc t))) [tt1, tt2, tt3] Hello! My question concerns a general term datatype: data Term = Not Term | Term :: Term | Term :||: Term | Literal Char Is it somehow possible to write a generic function that applies the associativity rules on a Term (by using pattern matching) and works with both data constructors or is it necessary to write one for :: and :||: ? Something like: assoc :: Term - Term assoc ((t1 `op` t2) `op` t3) = -- this doesn't work ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
On Wed, Sep 29, 2004 at 01:41:03PM +0100, Graham Klyne wrote: With code like this, I'm not surprised! main = do file - getContents putStrLn $ show (length $ lines file) ++ ++ show (length $ words file) ++ ++ show (length file) Space-leak or what? Er, please excuse a dumb question, but I'm struggling to see the problem here. I can see that this requires the original file to be kept for 3-time scanning, so enough memory for the entire file will be required. It would be nice if these scans were performed concurrently in a way that would make memory usage constant, wouldn't it? ;) Hmmm... maybe some simple tracking of garbage collection results would suffice... Reschedule if the current thread doesn't help in collecting garbage... But I am dreaming now... :) Is that *the* problem to which you allude? I can't see any other problem here. And why would this put Haskell at a disadvantage? The only problem is that some people may draw incorrect conclusions. Should we care? I already submitted two improvements for shootout in the last two days (not included yet), but I don't know if it's worth the effort. I remember SPJ's motto: ,,Avoid success at all cost''. Is this motto still valid? http://research.microsoft.com/Users/simonpj/papers/haskell-retrospective/HaskellRetrospective-2.pdf Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
On 2004-09-29, Tomasz Zielonka [EMAIL PROTECTED] wrote: I remember SPJ's motto: ,,Avoid success at all cost''. Is this motto still valid? Maybe. The existing user-base is being used as an argument for not doing the right thing with regards to binary-IO, strings, localization and text IO. -- Aaron Denney -- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
Graham Klyne [EMAIL PROTECTED] writes: main = do file - getContents putStrLn $ show (length $ lines file) ++ ++ show (length $ words file) ++ ++ show (length file) Space-leak or what? I can see that this requires the original file to be kept for 3-time scanning, so enough memory for the entire file will be required. Is that *the* problem to which you allude? I can't see any other problem here. Yes, it is the main problem. Don't forget, the shootout benchmark runs this example over a very large input (15Mb). Since the character-list stored in memory for this file takes approximately 12 bytes per character, that blows up to about 180Mb to store temporarily. The shootout performance figures reckon that ghc actually uses 223Mb in total. And why would this put Haskell at a disadvantage? Large live heap space means a large time spent in GC, trying to find the needle that is actual garbage in the haystack of live pointers. It also increases the likelihood of cache misses and all kinds of other bad memory effects. In other words, wasting space is wasting time. There is a good literature on heap profiling in Haskell which demonstrates the benefits of keeping space usage small to improve time performance. In any case, for the shootout, this is patently a different algorithm to the one every other solution uses. All the other languages do a simple one-pass traversal of the file, in constant memory space. Why artificially handicap Haskell by insisting it do the job naively? Regards, Malcolm ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Seeking reference(s) relating to FP performance
On 2004-09-29, Graham Klyne [EMAIL PROTECTED] wrote: I've taken it as an article of faith that performance of FP language implementations has been improving quite steadily over the past few years. I'd like to assert this, but I can't find any clear evidence to One place to start is the Language Shootout at http://shootout.alioth.debian.org/. While it is a benchmark, and therefore subject to all sorts of standard disclaimers about rigged benchmarks, some interesting conclusions can be seen: 1. OCaml often performs better than g++ 2. OCaml sometimes even beats gcc. 3. ghc doesn't seem to do very well in terms of performance, though it does at least beat out Java in many cases. 4. ghc has some of the most concise programs out there There's not a lot of information there on historical trends, but the fact that a mostly-functional language like OCaml can beat out c++ is fairly impressive. -- John I'm looking for a reference -- informal will be enough -- that can give an perspective of progress in functional language implementation performance. I'm not looking for a single benchmark that shows a case of blindingly-fast functional code, but a pointer to trends of improving performance. It would also serve my purpose to have indications based on languages other than Haskell (e.g. ML and friends). Any ideas, please? #g Graham Klyne For email: http://www.ninebynine.org/#Contact -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rethinking OO idioms
I've worked with languages with object-oriented features for awhile now. Python and OCaml, the two with which I work the most, both have OO. One of my first projects in Haskell would be to write a Haskell version of Python's ConfigParser[1] class. I wrote[2],[3] a version of this for OCaml that works very well. In a nutshell, ConfigParser is a utility for working with sectioned configuration files in a style similar to the familiar .ini files from Windows. It has methods to read a configuration file, get/set the items that are being configured, and write a new file back out. This, then, is a fairly typical metaphor for OO programs: an instance of a class has some state that can be accessed or modified, and possibly stored and retrieved. So I am thinking about a ConfigParser for Haskell. The first thing that occured to me is that Haskell has no OO features, so I'm not sure what is the best way to handle the class and its various methods. The next thing that occured to me is that, unlike OCaml and Python classes, Haskell has no mutable variables. A call like config.setOption(main, initpath, /usr) in Python -- which alters the state of the config object and returns nothing -- would be impossible in Haskell (unless perhaps the FiniteMaps are mutable somehow?) I guess I'm having trouble translating this common OO language paradigm into the Haskell world. Thanks for any insight. -- John BTW, if I get a working ConfigParser for Haskell, I will publish it under the GPL like all the rest of my code. [1] http://www.python.org/doc/current/lib/RawConfigParser-objects.html [2] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.html [3] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.rawConfigParser.html ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rethinking OO idioms
You can use state monad to mimic mutation. Also, take a look at the recursive decent monadic parsec library. It may have done what you are trying to do. Regards, Ben. John Goerzen [EMAIL PROTECTED]To: [EMAIL PROTECTED] g cc: Sent by: Subject: [Haskell-cafe] Rethinking OO idioms haskell-cafe-bounces@ haskell.org 09/29/2004 03:29 PM I've worked with languages with object-oriented features for awhile now. Python and OCaml, the two with which I work the most, both have OO. One of my first projects in Haskell would be to write a Haskell version of Python's ConfigParser[1] class. I wrote[2],[3] a version of this for OCaml that works very well. In a nutshell, ConfigParser is a utility for working with sectioned configuration files in a style similar to the familiar .ini files from Windows. It has methods to read a configuration file, get/set the items that are being configured, and write a new file back out. This, then, is a fairly typical metaphor for OO programs: an instance of a class has some state that can be accessed or modified, and possibly stored and retrieved. So I am thinking about a ConfigParser for Haskell. The first thing that occured to me is that Haskell has no OO features, so I'm not sure what is the best way to handle the class and its various methods. The next thing that occured to me is that, unlike OCaml and Python classes, Haskell has no mutable variables. A call like config.setOption(main, initpath, /usr) in Python -- which alters the state of the config object and returns nothing -- would be impossible in Haskell (unless perhaps the FiniteMaps are mutable somehow?) I guess I'm having trouble translating this common OO language paradigm into the Haskell world. Thanks for any insight. -- John BTW, if I get a working ConfigParser for Haskell, I will publish it under the GPL like all the rest of my code. [1] http://www.python.org/doc/current/lib/RawConfigParser-objects.html [2] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.html [3] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.rawConfigParser.html ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise the IT Security department at [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
Greg Buchholz wrote: The algorithm isn't correct (it counts spaces instead of words), but anyone have advice for improving its performance? You probably want some strictness annotations in there. . . When I tried the same thing, I came up with something like: import Char; cclass c | isSpace c = (c == '\n', False) | otherwise = (False, True) data Cdata = Cdata !Bool !Int !Int !Int deriving Show combine (Cdata last l w c) (nl, iw) = Cdata iw l' w' (c + 1) where l' = if nl then l + 1 else l w' = if not last iw then w + 1 else w wc = foldl combine (Cdata False 0 0 0) . map cclass main = getContents = putStrLn . show . wc It seems to work in constant stack space, and gives the same answers (albeit not very beautifully) as my GNU copy of wc. Is the problem caused by the laziness of the Int's inside the tuple? I'm pretty sure that's what's causing it. I had quite a search around when my version was running out of memory and everything seemed to suggest that, basically, the algorithm is building a massive list of +1s that only actually get executed when the you try and print the totals at the end. Any comments from more authoritative sources? Here is the report from ghc with the '-ddump-simpl' option. If anyone has any hints about how to read this output, I'd be grateful. It makes a bit of sense, but I don't really know what it means. I.e. it's obviously the simplified parse tree and I can see how it relates back to the source (loosely), but attempting to figure out if something's going to be as leaky as a sieve or not is beyond me. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rethinking OO idioms
On 2004-09-29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You can use state monad to mimic mutation. Is that really what I want? In other words, is there a completely different, more Haskellish, way to look at this? Also, take a look at the recursive decent monadic parsec library. It may have done what you are trying to do. Thanks for the pointer. I'll take a look. -- John ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling GHC for AIX5.1L
jgoerzen: Hello, Following the directions at http://www.haskell.org/ghc/docs/6.2.1/html/building/sec-porting-ghc.html#UNREGISTERISED-PORTING... I have a Debian unstable system on i386 as the host machine and an IBM PowerPC system as the target. I have configured the files as specified in the docs. I am to the make boot make phase in the ghc directory on the (Linux) host. All goes well until: You're now in the rts/ on the host machine? If so: Don't worry if the build falls over in the RTS, we don't need the RTS yet. You can use make -k to keep going, I seem to remember, or use -pgmltrue, to have ghc skip the linking phase. This was a common trick when we went through a porting frenzy last year. Check the mailing list archives for lots of hints. http://www.haskell.org/pipermail/glasgow-haskell-users/2003-September/thread.html Adding something like: AR=/usr/bin/true LD=/usr/bin/true SRC_HC_OPTS+= -pgmc /usr/bin/true -pgma /usr/bin/true -pgml /usr/bin/true to build.mk might help. Good luck! :) -- Don ==fptools== make all -r; in /home/jgoerzen/no-backup/programs/ghc-6.2.1/ghc/rts ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -c Adjustor.c -o Adjustor.o /tmp/ghc10917.s: Assembler messages: /tmp/ghc10917.s:54: Error: no such instruction: `dcbf 0,%eax' /tmp/ghc10917.s:55: Error: no such instruction: `sync' /tmp/ghc10917.s:56: Error: no such instruction: `icbi 0,%eax' /tmp/ghc10917.s:63: Error: no such instruction: `sync' /tmp/ghc10917.s:64: Error: no such instruction: `isync' make[1]: *** [Adjustor.o] Error 1 make: *** [all] Error 1 Why it's trying to use PowerPC assembler on an x86 host I don't know. (I assume that's what's going on here; but I don't really know.) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Seeking reference(s) relating to FP performance
On 29.09 19:00, John Goerzen wrote: 3. ghc doesn't seem to do very well in terms of performance, though it does at least beat out Java in many cases. Please note that many of the GHC programs are not posed for performance, but rather elegance. E.g. the nestedloop got seven times faster with minor corrections (not reflected on the website yet). - Einar Karttunen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
