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 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 an
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
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
...
The UltraSPARC T1/T2 architecture supports very fast thread
synchronisation (by taking advantage of the fact that all threads
share the same L2 cache).
...
Ah, scratch that second part then - though this is perhaps less of an
issue when you have 4MB of L2 cache, vs the 256k cache for the m
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 continuat
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
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
> ove
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 Hask
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
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 an
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 c
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 o
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 Solari
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 ... don
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 ... do
16 matches
Mail list logo
