[Haskell-cafe] ghc socket weirdness
FreeBSD/7.0 amd64: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :module +Network Prelude Network listenOn $ PortNumber 8765 Loading package parsec-2.1.0.0 ... linking ... done. Loading package network-2.1.0.0 ... linking ... done. *** Exception: getAddrInfo: does not exist (servname not supported for ai_socktype) (same error when compiled). Anyone seen this before? I have multiple NICs, could that be confusing listenOn (does it not just bind on 0.0.0.0?) Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc socket weirdness
Tim Newsham [EMAIL PROTECTED] writes: FreeBSD/7.0 amd64: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :module +Network Prelude Network listenOn $ PortNumber 8765 Loading package parsec-2.1.0.0 ... linking ... done. Loading package network-2.1.0.0 ... linking ... done. *** Exception: getAddrInfo: does not exist (servname not supported for ai_socktype) (same error when compiled). Anyone seen this before? I have multiple NICs, could that be confusing listenOn (does it not just bind on 0.0.0.0?) ghc 6.8.2 has the same problem on NetBSD/i386, it fixed with ghc 6.8.3: http://hackage.haskell.org/trac/ghc/ticket/2103 -- jungle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On Thu, 2008-07-24 at 16:43 +1200, Richard A. O'Keefe wrote: On 24 Jul 2008, at 3:52 am, Duncan Coutts wrote: [Sun have donated a T5120 server + USD10k to develop support for Haskell on the SPARC.] This is wonderful news. I have a 500MHz UltraSPARC II on my desktop running Solaris 2.10. I have 500MHz UltraSPARC II on my desktop running Gentoo Linux. :-) Some time ago I tried to install GHC 6.6.1 on it, but ended up with something that compiles to C ok, but then invokes some C compiler with option -fwrapv, which no compiler on that machine accepts, certainly none that was present when I installed it. I've got ghc 6.8.2 working, but only -fvia-C and only unregisterised. -fwrapv is an option to some version of gcc, but I couldn't tell you which. I would really love to be able to use GHC on that machine. Me too :-), or in my case use it a bit quicker. Unregisterised ghc builds are pretty slow. I also have an account on a T1 server, but the research group who Sun gave it to chose to run Linux on it, of all things. Our tentative plan is to partition our T2 server using logical domains and run both Solaris and Linux. We'd like to set up ghc build bots on both OSs. So binary distributions for SPARC/Solaris and SPARC/Linux would be very very nice things for this new project to deliver early. I guess this is something that anyone with an account on the box could do. So once we get to the stage where we're handing out accounts then hopefully this would follow. The project isn't aiming to get the registerised C backend working nicely, we're aiming to get a decent native backend. That should also be much less fragile by not depending on the version of gcc so closely. (Or some kind of source distribution that doesn't need a working GHC to start with.) That's a tad harder. Needs lot of build system hacking. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Profiling nested case
Done. http://hackage.haskell.org/trac/ghc/ticket/2465 -- ryan On 7/23/08, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | I had similar experiences as you when attempting to write high | performance Haskell; the language makes you want to use high-level | abstracted functions but the optimizer (while amazing, to be honest) | seems to miss a few cases that it seems like it should hit. Ryan, if you find any of these, do please submit them to GHC's Trac bug-tracker. There's a special category for performance bugs. Small programs of the form GHC should hit this, but doesn't are incredibly useful. Thanks Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
Neat stuff. I used to work at Sun in the solaris kernel group, the SPARC architecture is quite elegant. I wonder if we can find an interesting use for the register windows in a haskell compiler. Many compilers for non c-like languages (such as boquist's one that jhc is based on (in spirit, if not code)) just ignore the windows and treat the architecture as having a flat 32 register file. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ansi2html - one program, several issues
On Sun, Jul 20, 2008 at 09:55:15AM -0400, Isaac Dupree wrote: It doesn't stop it from parsing the entire file strictly. However, what it does do is prevent the parser from backtracking out of arbitrary amounts of lookahead. So, unless you use try (which allows for lookahead), when any token is consumed by the parser, it can be garbage collected (assuming the parser is the only thing pointing to the token stream). So, it consumes its input strictly, but with limited overhead (ideally using try only for some small bounded lookahead where it's needed). So with Parsec, you can keep the *input* from filling up memory, but if you do, the *result* will still take up space (e.g. Right (value)). For a simple transformation where the output is a similar string to the input, it will be just as large, so not much space is actually saved (maybe a factor of 2 -- just keeping the output, not also the input), it seems. Yeah, this is my understanding. frisby combats this via 'irrefutable' parser combinators. An irrefutable combinator is one that always succeeds, a prime example is the 'many' combinator. Since 'many' consumes only as many of its arguments as it can and is perfectly fine consuming nothing, it inherently always succeeds so the parser can immediately begin returning results (before consuming all of the input). Ironically, this means frisby often uses less space than other parsers, despite being based on PEGs which generally are known for taking a lot of space. It is not too hard to ensure your optimizer is irrefutable, for instance, the parser for a simple language might be many statement eof however, the 'eof' makes the parser non-irrefutabel. however it is easy to gain back by doing many statement (eof // pure (error unexpected data)) frisbys static analysis realizes that (irrefutable // ... ) and ( ... // irrefutable) are irrefutable. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On Thu, 2008-07-24 at 14:38 -0700, John Meacham wrote: Neat stuff. I used to work at Sun in the solaris kernel group, the SPARC architecture is quite elegant. I wonder if we can find an interesting use for the register windows in a haskell compiler. Many compilers for non c-like languages (such as boquist's one that jhc is based on (in spirit, if not code)) just ignore the windows and treat the architecture as having a flat 32 register file. Right. GHC on SPARC has also always disabled the register window when running Haskell code (at least for registerised builds) and only uses it when using the C stack and calling C functions. We should discuss this with our project adviser from the SPARC compiler group. The problem of course is recursion and deeply nested call stacks which don't make good use of register windows because they keep having to interrupt to spill them to the save area. I vaguely wondered if they might be useful for leaf calls or more generally where we can see statically that the call depth is small (and we can see all callers of said function, since it'd change the calling convention). But now you mention it, I wonder if there is anything even more cunning we could do, perhaps with lightweight threads or something. Or perhaps an area to quickly save registers at GC safe points. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: blas bindings, why are they so much slower the C?
Last month Anatoly Yakovenko published some disturbing numbers about the Haskell BLAS bindings I wrote being significantly slower than using plain C. I wanted to let everyone know that I've closed the performance gap, and now for doing ten million dot products, the overhead for using Haskell instead of C is about 0.6 seconds on my machine, regardless of the size of the vectors. The next version will incorporate the changes. If you can't wait for a formal release, the darcs repository is at http://www-stat.stanford.edu/~patperry/code/blas/ Anyone interested in more details can check out my blog: http://quantile95.com/2008/07/24/addressing-haskell-blas-performance-issues/ Thanks everyone for the input on this (especially Anatoly). If any else finds any performance discrepancies, please let me know and I will do whatever I can to fix them. Patrick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: blas bindings, why are they so much slower the C?
patperry: Last month Anatoly Yakovenko published some disturbing numbers about the Haskell BLAS bindings I wrote being significantly slower than using plain C. I wanted to let everyone know that I've closed the performance gap, and now for doing ten million dot products, the overhead for using Haskell instead of C is about 0.6 seconds on my machine, regardless of the size of the vectors. The next version will incorporate the changes. If you can't wait for a formal release, the darcs repository is at http://www-stat.stanford.edu/~patperry/code/blas/ Anyone interested in more details can check out my blog: http://quantile95.com/2008/07/24/addressing-haskell-blas-performance-issues/ Thanks everyone for the input on this (especially Anatoly). If any else finds any performance discrepancies, please let me know and I will do whatever I can to fix them. Great work, Patrick! So if I read correctly, the main change was to flatten the representation (and thus in loops the vector's structure will be unpacked and kept in registers, which isn't possible for sum types). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: blas bindings, why are they so much slower the C?
Yeah, I think that's where most of the performance gains came from. I also added a re-write rule for unsafeGet dot (since it doesn't matter if the arguments are conjugated or not if the vectors are real) that shaved off about a tenth of a second. Patrick On Jul 24, 2008, at 4:26 PM, Don Stewart wrote: patperry: Last month Anatoly Yakovenko published some disturbing numbers about the Haskell BLAS bindings I wrote being significantly slower than using plain C. I wanted to let everyone know that I've closed the performance gap, and now for doing ten million dot products, the overhead for using Haskell instead of C is about 0.6 seconds on my machine, regardless of the size of the vectors. The next version will incorporate the changes. If you can't wait for a formal release, the darcs repository is at http://www-stat.stanford.edu/~patperry/code/blas/ Anyone interested in more details can check out my blog: http://quantile95.com/2008/07/24/addressing-haskell-blas-performance-issues/ Thanks everyone for the input on this (especially Anatoly). If any else finds any performance discrepancies, please let me know and I will do whatever I can to fix them. Great work, Patrick! So if I read correctly, the main change was to flatten the representation (and thus in loops the vector's structure will be unpacked and kept in registers, which isn't possible for sum types). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On 25/07/2008, at 8:55 AM, Duncan Coutts wrote: Right. GHC on SPARC has also always disabled the register window when running Haskell code (at least for registerised builds) and only uses it when using the C stack and calling C functions. I'm not sure whether register windows and continuation based back-ends are ever going to be very good matches - I don't remember the last time I saw a 'ret' instruction in the generated code :). If there's a killer application for register windows in GHC it'd be something tricky. I'd be more interested in the 8 x hardware threads per core, [1] suggests that (single threaded) GHC code spends over half its time stalled due to L2 data cache miss. 64 threads per machine is a good incentive for trying out a few `par` calls.. Ben. [1] http://www.cl.cam.ac.uk/~am21/papers/msp02.ps.gz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On Fri, 2008-07-25 at 10:38 +1000, Ben Lippmeier wrote: I'd be more interested in the 8 x hardware threads per core, [1] suggests that (single threaded) GHC code spends over half its time stalled due to L2 data cache miss. Right, that's what I think is most interesting and why I wanted to get this project going in the first place. If we spend so long blocked on memory reads that we're only utilising 50% of a core's time then there's lots of room for improvements if we can fill in that wasted time by running another thread. So that's the supposed advantage of multiplexing several threads per core. If Haskell is suffering more than other languages with the memory latency and low utilisation then we've also got most to gain with this multiplexing approach. 64 threads per machine is a good incentive for trying out a few `par` calls.. Of course then it means we need to have enough work to do. Indeed we need quite a bit just to break even because each core is relatively stripped down without all the out-of-order execution etc. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Off-topic] Loss of humour
On Wed, 23 Jul 2008 22:09:08 +0100, Andrew Coppin [EMAIL PROTECTED] wrote: Jeremy Shaw wrote: At Wed, 23 Jul 2008 19:45:56 +0100, Andrew Coppin wrote: A while back I found a page somewhere containing some rather amusing IRC quotes. Unfortunately it seems to have vanished. I can't remember where on earth I found it, but I've scoured the Internet trying to track it down. (In particular, it contained a quote of somebody impersonating a typical Haskell newbie - lots of enthusiasm and no attention span! Well it amused *me* anyway...) Anybody have any ideas where this has gone? http://web.archive.org/web/20070609061216/http://www.haskell.org/hawiki/QuotesPage LOL! Thanks, that's the one... You're referring to this one from that page, right? Ninja Jones does a not-too-far-off parody of a certain flavor of visitor to #haskell *** highlyInterested (~ijones) has joined channel #haskell highlyInterested hi! I'm highly interested, but have no attention span!!! highlyInterested Can anyone help me?!?!? * highlyInterested runs around!! *** highlyInterested (~ijones) has quit: Client Quit -- Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On 25 Jul 2008, at 10:55 am, Duncan Coutts wrote: The problem of course is recursion and deeply nested call stacks which don't make good use of register windows because they keep having to interrupt to spill them to the save area. A fair bit of thought was put into SPARC V9 to making saving and restoring register windows a lot cheaper than it used to be. (And the Sun C compiler learned how to do TRO.) It's nice to have 3 windows: C worldstartup Haskell world normal Haskell code millicode special support code so that normal code doesn't have to leave registers spare for millicode routines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
On 25/07/2008, at 12:42 PM, Duncan Coutts wrote: Of course then it means we need to have enough work to do. Indeed we need quite a bit just to break even because each core is relatively stripped down without all the out-of-order execution etc. I don't think that will hurt too much. The code that GHC emits is very regular and the basic blocks tend to be small. A good proportion of it is just for copying data between the stack and the heap. On the upside, it's all very clean and amenable to some simple peephole optimization / compile time reordering. I remember someone telling me that one of the outcomes of the Itanium project was that they didn't get the (low level) compile-time optimizations to perform as well as they had hoped. The reasoning was that a highly speculative/out-of-order processor with all the trimmings had a lot more dynamic information about the state of the program, and could make decisions on the fly which were better than what you could ever get statically at compile time. -- does anyone have a reference for this? Anyway, this problem is moot with GHC code. There's barely any instruction level parallelism to exploit anyway, but adding an extra hardware thread is just a `par` away. To quote a talk from that paper earlier: GHC programs turn an Athlon into a 486 with a high clock speed! Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
