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 ...
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
15 matches
Mail list logo
