John Goerzen [EMAIL PROTECTED] writes:
Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems
to be a verbatim copy of the darcs repo at York.
Ahh. You are correct.
Re-converting now, since you've presumably committed patches to the
darcs side, is probably not going to be
Hi List,
I'm running GHC and GCC head-to-head on the task of adding a bunch of
long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook
and gets a runtime for the GHC-compiled binary that's about 10x as long
as for GCC. Simon M. tells me this should be much better. Here are the
Sven Moritz Hallberg [EMAIL PROTECTED] writes:
I'm running GHC and GCC head-to-head on the task of adding a bunch of
long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook
and gets a runtime for the GHC-compiled binary that's about 10x as long
as for GCC.
Is it possible that
Hello Sven,
Wednesday, January 18, 2006, 3:33:40 PM, you wrote:
SMH and gets a runtime for the GHC-compiled binary that's about 10x as long
SMH as for GCC. Simon M. tells me this should be much better. Here are the
attached version is only 5 times slower :) please note that
1)
Bulat Ziganshin wrote:
Wednesday, January 18, 2006, 3:33:40 PM, you wrote:
SMH and gets a runtime for the GHC-compiled binary that's about 10x as long
SMH as for GCC. Simon M. tells me this should be much better. Here are the
attached version is only 5 times slower :) please note that
1)
Hello Malcolm,
Wednesday, January 18, 2006, 4:22:23 PM, you wrote:
I'm running GHC and GCC head-to-head on the task of adding a bunch of
long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook
and gets a runtime for the GHC-compiled binary that's about 10x as long
as for GCC.
Simon Peyton-Jones wrote:
I'm very interested to know whether you like it or hate it.
In the latter case, I'd also like to know whether you also
have programs that will be broken by the change.
I don't use GADTs yet and I assume this change will not (seriously)
break our code, but let me/us
Hello Simon,
Wednesday, January 18, 2006, 5:31:25 PM, you wrote:
2) generating random values takes about 1.5-2 seconds by itself.
Haskell's RNG is very different from C's one
SM I squeezed a bit more out (see attached).
x `seq` v `seq` return ()
it's new trick for me :) now the
I'm trying to run the following sequence on ghc 6.4: ghc -fglasgow-exts --make Main ghc -o exec Main.o Exemplo1.oBut I always get this error message after the second command:/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main':: undefined reference to
Hello Bulat,
Wednesday, January 18, 2006, 8:34:54 PM, you wrote:
BZ the only cause that this code is only 3 times slower is that C version
BZ is really limited by memory speed. when tested on 1000-element
BZ arrays, it is 20 times slower. i'm not yet tried SSE optimization for
BZ gcc ;)
sorry,
On 1/18/06, Tays Soares [EMAIL PROTECTED] wrote:
I'm trying to run the following sequence on ghc 6.4:
ghc -fglasgow-exts --make Main
ghc -o exec Main.o Exemplo1.o
But I always get this error message after the second command:
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function
On Wed, Jan 18, 2006 at 06:18:29PM +0300, Bulat Ziganshin wrote:
:) even C version performs only 20 millions of additions in one second
because this program is most limited by memory throughput - it access
to 24 memory bytes per each addition. GHC just can't produce simple
loops even for
On Wed, Jan 18, 2006 at 08:54:43PM +0300, Bulat Ziganshin wrote:
sorry, with the gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops
the C version is 50 times faster than best Haskell one... it's the
loop from C version:
I believe something similar to what I noted here is the culprit:
13 matches
Mail list logo
