Re: GHC and gcc 3.3.1

2003-10-21 Thread Jost Berthold
We have built GHC 6.2 for RedHat 9 in our department without problems (well... I checked out the sources approx. 2 weeks ago) using gcc-3.3.1 and a snapshot of ghc-6.1(20030829, rebuilt using binary ghc-6.1.20030803 and manually linking in a dummy __ctype_b). I only had problems because of the

Re: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
Well, i found the reason why it did work with haskell and not with C. It was simply that for haskell i provided an arch via -optc-march=pentium3 and did not the same with C++ (... i should have read the sse option documentation). Thanks for the hint about strictness on large data structures. Reg

Re: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
Yes, i got SSE to work with C++ with -march=pentium3 and -mfpmath=sse Well, don't make a difference for C++. It is still stuck at 140ms. But i must say that the speedup could be below the time resolution of my PC + Test. It is assumable that the improvement is similar to Haskell (about 4%) |---

Re: Faster, GHC, and floating point.

2003-10-21 Thread Michael Weber
* [EMAIL PROTECTED] [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael

RE: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
> > You put the blame on me for the bad performance of my code, > > I didn't mean to give that impression, sorry. Optimising Haskell code > is a delicate art which requires experience and sometimes a deep > knowledge of GHC's optimiser. This is a real problem, and we readily > accept that. I ju

RE: Faster, GHC, and floating point.

2003-10-21 Thread Simon Marlow
> > really performance-critical code. Also this will tell you > whether your > > performance problems are due to strictness/boxing or > something else. It > > should be possible to obtain the same performance as C++ > (or better). > > Are you shure about this? And why are you shure? One ca

RE: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
Hi Simon, > really performance-critical code. Also this will tell you whether your > performance problems are due to strictness/boxing or something else. It > should be possible to obtain the same performance as C++ (or better). Are you shure about this? And why are you shure? You put the blam

Re: Posible bug while optimizing? (Was: RULES for SPECIALIZ(E)ations)

2003-10-21 Thread Juanma Barranquero
> But I'm getting an error on recompilations that I don't understand. It > happens only with -O (or -On), AFAICS. On second (and less sleepy) thought, there's no mystery in it happening only with -O, as RULEs aren't used for non-optimizing compilations :) Still, it's weird to get an error on rec

Re: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
Can't tell you, SSE is disabled by cygwin when i try -mfpmath=sse i get the message c++ AIBD.cpp Main.cpp -O2 -mfpmath=sse -o AIBD.exe cc1plus: warning: SSE instruction set disabled, using 387 arithmetics and the program it takes obviously the same time. Oh, and btw, using MinGW yields the sam

RE: Faster, GHC, and floating point.

2003-10-21 Thread Simon Marlow
> I added some `seq` 's to the code. > I also used SSE (not p4, i don't have the p4 available by > now, but i'll > test it) > and indeed, it runs _a bit_ faster: ~640 now vs. 711 ms > before (Speedup > 1.11). > > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). > > But if i

RE: Faster, GHC, and floating point.

2003-10-21 Thread Andreas . Schroeder
Hi Simon, I added some `seq` 's to the code. I also used SSE (not p4, i don't have the p4 available by now, but i'll test it) and indeed, it runs _a bit_ faster: ~640 now vs. 711 ms before (Speedup 1.11). Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). But if i look in the in

Re: mips-sgi-irix bootstrapping

2003-10-21 Thread Donald Bruce Stewart
simonmar: > > [ARG_8??] MK_SMALL_BITMAP(3,6), > > [ARG_8?8] MK_SMALL_BITMAP(3,2), > Aha! It looks like toUpper isn't working properly. This is probably > because GHC.Unicode has been compiled for a 32-bit machine. This has solved that particular mips bug. And the port proceeds... --

Antwort: RE: Performance Tests in Haskell

2003-10-21 Thread Andreas . Schroeder
thanks a lot! (and sorry if this question was trivial) regards, Andreas Schroeder |-+---> | | "Simon Marlow" | | | <[EMAIL PROTECTED]| | | oft.com>| | | | | |

Posible bug while optimizing? (Was: RULES for SPECIALIZ(E)ations)

2003-10-21 Thread Juanma Barranquero
On Mon, 20 Oct 2003 12:01:59 +0100 "Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote: > Maybe you want a rule > > genericLength = length > > which will replace a call to (genericLength at type Int) by a call to > length? That gave me the idea of making a module to contain general purpose ru

Re: GHC Lexer

2003-10-21 Thread Steffen Mazanek
Hello, > LexCore is the lexer for "ExternalCore". > http://www.haskell.org/ghc/docs/papers/core.ps.gz > > For your purposes, you can ignore it. thank you for this information. I have checked out the latest cvs tree and thereby I have noticed, that Lex.lhs is now replaced by an alex file. GHC i