- Haskell-Cafe - Haskell.org

OCaml list sees abysmal Language Shootout results
by Keith Wansbrough 08 Oct '04

08 Oct '04

I just saw this on the OCaml list (in a posting by "Rafael 'Dido' Sevilla" <dido(a)imperium.ph> in the "Observations on OCaml vs. Haskell" thread). 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? --KW 8-) http://caml.inria.fr/archives/200409/msg00485.html > > 2. Haskell strings are lists of characters > > > > It's annoying that strings aren't normally processed this way in OCaml, > > and even more annoying that (^) or (::) cannot be used in pattern > > matching over strings. I like Haskell's approach. The list > > concatenation operator is the same as the string concatenation operator > > in Haskell. > > > > This is something of an efficiency/elegance tradeoff. Making strings > act like lists means potentially boxing *every character in the string*. > In other words, it's potentially a very expensive way of doing business. > Paul Graham was mulling over this kind of tradeoff in his design of Arc, > as I recall. Another language that does this type of thing is Erlang, > and both languages seem to be significantly slower than OCaml in string > handling, at least as far as this site goes: > > http://shootout.alioth.debian.org/ > > For the word count benchmark OCaml scores 0.1850 seconds, while GHC is a > dismal last place at 105.2110 seconds! Even the bytecode ocaml is an > order of magnitude faster. The word frequency benchmark also shows this > kind of poor string handling performance for Haskell, with OCaml scoring > 0.5669 seconds, while GHC scores a truly dismal 6.4540, more than an > order of magnitude slower, and even the bytecode ocaml is faster at > 4.2644 seconds. > > All in all, it would appear that Haskell's approach has been expensive > in terms of performance, if the benchmarks are to be taken at face > value. Such are the tradeoffs language designers have to make.

18 43

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

Doubly linked lists do not work very well in functional languages.# when you have a list [1,2,3] and you prepend a value [9,1,2,3] the language relies on the fact that the list tail [1,2,3] is not chainged by this operation. This means the list can be "prepended-in-place". With a doubly linked list the [1] cell would be changes (the 'left' pointer is changed from null to point to the [9] cell)... The result of this is that with a doubly linked list the _whole_ list must be copied when prepending a single value. In other words in a functional language, a doubly linked list will make ':' as hard as '++' and not the other way round! Keean.

1 0

RE: [Haskell-cafe] Re: OCaml list sees abysmalLanguage Shootoutresults
by Simon Marlow 08 Oct '04

08 Oct '04

On 08 October 2004 13:36, Robert Dockins wrote: > BTW can you give some references to these known techniques? Hmm, well here's some folklorish ideas. I'm sure there are references for most of these, but I don't know them off hand. - Have another list constructor that has 2 (or more) elements. Prelude funnctions can take advantage of this, but the constructor can magically transform itself into ordinary cons cells when it is examined by an ordinary pattern match. - take this further and have list cells with 2 (or more) unboxed characters, or even a full buffer. - use space-saving techniques for storing list cells: eg. remove the tail pointer when cells appear next to each other in the heap, or have a memory page just for list cells and omit the info pointers. Or just improve cache behaviour by trying to store list cells adjacent in the heap. Cheers, Simon

1 0

A Typing Dilemma
by John Goerzen 08 Oct '04

08 Oct '04

Thanks so much for all the help many of you have provided. I have one (heh) more question: I have this code: defaultHandler :: LogHandler b => IO (a -> IORef b) defaultHandler = do h <- (streamHandler stdout WARNING) r <- newIORef h return (\x -> r) The idea is to create a new IORef to something in the LogHandler class and return a function that returns it. The thing returned by that call to streamHandler is in the LogHandler class. Specifically, its declaration looks like this: instance LogHandler (GenericHandler a) where ... and streamHandler returns a "GenericHandler Handle" object. Now, when compiling that defaultHandler code, the compiler complains: Cannot unify the type-signature variable `b' with the type `MissingH.Logging.Handler.Simple.GenericHandler Handle' Expected type: IORef b Inferred type: IORef (MissingH.Logging.Handler.Simple.GenericHandler Handle) In a lambda abstraction: \ x -> r In the first argument of `return', namely `(\ x -> r)' I'm stumped. Can anyone shed some light on that for me? Thanks, -- John

2 1

RE: [Haskell-cafe] Being Compatible
by Simon Peyton-Jones 08 Oct '04

08 Oct '04

John Yes, I think your best route is cpp-ery, horrible though it is. I suggest you use ghc6.2.1 (or 6.2.2 when it comes out, which will be Monday-ish), rather than some ghc5.x version. Otherwise you risk investing work in making a library incompatible with the current story. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of John | Goerzen | Sent: 07 October 2004 15:35 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Being Compatible | | Hi, | | I have appreciated some of the comments here about what exactly is | standardized. My next question is how to work at the greatest number of | places. | | I am working on a library of Haskell-related utilities. There is some | code in there that works with binary I/O, and some code that works with | rawSystem(), etc. | | Some of these are not supported on Hugs, nhc98, or ghc5 to varying | degrees. | | My initial thought was to use the cpp-style ifdefs I've seen elsewhere | to mask those unsupported features on those particular systems. But | Hugs at least doesn't support that, and I've found it extremely | difficult to find a list of predefined macros for the other systems | anyway. | | What is the suggested way to work around these problems? | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Re: IPv6?
by Simon Marlow 08 Oct '04

08 Oct '04

On 08 October 2004 15:11, John Goerzen wrote: > I probably could figure out how to do that based on the existing IPv4 > code. Some small parts of IPv6 support are already there. > > However, I'd have two questions: > > 1. Wouldn't there need to be some sort of discussion first to ensure > that all the compiler/interpreter implementors do it the same way? We all share libraries, so anything you do to Network.Socket will appear in all the compilers, provided it is portable enough. If there are issues about how the interface to IPv6 should be exposed to the programmer, then the best place to discuss it is libraries(a)haskell.org. I suspect that it'll be pretty straightforward, though - Network.Socket is a low level interface that just tries to re-expose the OS primitives as a Haskell library. > 2. I don't know anything about the autotools stuff save that it does > not get along very well with me. If I submit a patch that assumes > that IPv6 support is available, would somebody be able to add the > appropriate tests and ifdefs around it to ensure that it really is? Probably... we have one or two autoconf-compliant hackers amongst the GHC regulars. Cheers, Simon

1 0

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
by Peter Achten 08 Oct '04

08 Oct '04

At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote: >Andrew Butterfield <Andrew.Butterfield(a)cs.tcd.ie> writes: > > >>I though clean was always strict, and that was the major difference > >>between clean and haskell (that and the fact clean is a proprietry > >>language) > > > > No - Clean is pure and lazy like Haskell, > >But it uses explicit strictness annotations a lot, and provides strict >and/or unboxed versions of various fundamental types (e.g. tuples), >with some implicit coercions. It is of course not the language that uses strictness annotations. Clean programs without strictness annotations are perfectly lazy. Clean has a powerful strictness analysis that includes only safe strictness to function arguments. Programmers *can* include strictness annotations, exactly for the reasons that were mentioned in this thread, namely to influence the evaluation strategy in such a way that heap consumption and/or run time decrease. In addition, this can be done light-weight because annotations are added only to function argument types and data types, instead of modifying the code by inserting strict evaluator functions. Regards, Peter Achten N.B. My new email address is : P.Achten(a)cs.ru.nl. The University of Nijmegen has changed its name to Radboud University Nijmegen

1 0

RE: [Haskell-cafe] IPv6?
by Simon Marlow 08 Oct '04

08 Oct '04

On 07 October 2004 21:43, John Goerzen wrote: > Network.Socket in GHC6 seems to be restricted to IPv4, despite the > prsence of AF_INET6. How do I support IPv6 in Haskell? You write some code to handle IPv6 and send it to us for inclusion in Network.Socket ;-) Cheers, Simon

2 1

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

>lists doubly-linked and circular. Erm, this just increases overhead, and file access is linear anyway. Singly linked is good enough. What would make a difference is if each 'node' in the listwas allowed to be larger that '1' item. For example reading a file with 4k buffers, would work much better if the list were represented by 4k chunks in a liked list. Keean.

1 0

RE: [Haskell-cafe] more shootout madness -- hashes in GHC
by Simon Marlow 08 Oct '04

08 Oct '04

On 07 October 2004 20:53, Robert wrote: > I've been playing around with the "Hashes, Part II" code from the > shootout. I wanted to try to implement this test using Data.HashTable > instead of Data.FiniteMap to see if that would buy us anything. In > fact, the HashTable implementation is consistantly faster than > FiniteMap, but not by a lot (thus making the transition to the IO > monad not worthwhile IMO). The interesting thing, however, is that > at a certain number of iterations (106 in my case), the Hashtable code > segfaults. GDB shows that it is blowing the top off the program stack > and dying when it tries to write to kernel space. (can't write to > 0xbfffffff). Thanks, that's a good bug to catch just before the 6.2.2 release. There is a performance bug in the 6.2.2 HashTable implementation which we already found, but I forgot to merge into the 6.2 branch. The performance bug caused the table to overflow, leading to the segfault (not checking for overflow is another bug). Upshot: this will be fixed in 6.2.2. Furthermore, performance will be better. Cheers, Simon

1 0