RE: aha! I think.

2005-10-27 Thread Simon Marlow
On 27 October 2005 01:33, John Meacham wrote: I think I might have found why (or partially why) ghc is so slow on x86-64.. section 5.10 of the optimization manual http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ 25112.PDF (which has a whole lot of good info for

RE: aha! I think.

2005-10-27 Thread Simon Marlow
On 27 October 2005 09:05, John Meacham wrote: but an alignment issue sounds more likely, if we are stradling 4 byte boundries with our 8 byte pointers and ints, that could affect things very much. it is the number one cause of performance problems according to the AMD optimization manual.

RE: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-10-27 Thread Simon Marlow
John, this is great stuff. There's clearly a lot we can do to improve GHC's code, at least for fac :-) (I'd be really interested in any numbers you have for larger programs too, eg. the nofib suite). and now the generated assembly. Main_zdwfac_info: .text .align 8 .text

RE: GHC-6.4.1 on FreeBSD-amd64 port progress

2005-10-27 Thread Simon Marlow
On 26 October 2005 19:58, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: On 25 October 2005 10:01, Wilhelm B. Kloke wrote: Try with splitting off: set SplitObjs=NO in your mk/build.mk. Done with success. I just used the compiler to install darcs. I am able to make the

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-10-27 Thread John Meacham
On Thu, Oct 27, 2005 at 10:38:20AM +0100, Simon Marlow wrote: gcc started generating this rubbish around version 3.4, if I recall correctly. I've tried disabling various optimisations, but can't seem to convince gcc not to generate the extra jump. You don't get this from the native code

Re[2]: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-10-27 Thread Bulat Ziganshin
Hello Simon, Thursday, October 27, 2005, 12:40:27 PM, you wrote: SPJ That is, a C-- == C-- optimiser would be a nice independent project. SPJ My reason for mentioning all this now, when it's still partly SPJ vapourware, is to see if anyone else is interested. In particular, SPJ perhaps a C--

GHC-6.4.1 much slower than GHC-6.4

2005-10-27 Thread Mirko Rahn
Hello, I was surprised about really big differences in running times between 6.4 and 6.4.1, whereby 6.4.1 is *much* slower: *** 6.4: cpu-time interesting (3,3): 00:01:38.08 *** 6.4.1: cpu-time interesting (3,3): 00:05:58.91 Here we have a factor of about 3.6!! Are there others that have

Re: GHC-6.4.1 much slower than GHC-6.4

2005-10-27 Thread Christian Maeder
Mirko Rahn wrote: I was surprised about really big differences in running times between 6.4 and 6.4.1, whereby 6.4.1 is *much* slower: *** 6.4: cpu-time interesting (3,3): 00:01:38.08 *** 6.4.1: cpu-time interesting (3,3): 00:05:58.91 indeed, I had similar results. You may try to find out

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-10-27 Thread Benjamin Franksen
On Thursday 27 October 2005 13:11, John Meacham wrote: I am not sure how much sense this makes though. I am no expert on the spineless tagless G machine (which would make an excellent name for a band BTW) :-) Ben ___ Glasgow-haskell-users

C minus minus? No, C monad monad.

2005-10-27 Thread John Meacham
I have this new thing where I try to write down my ideas before I lose them. so far I think it is going well. this is also available at http://repetae.net/john/repos/jhc/docs/c-minus-monad.txt Sorry if this is a bit raw or wrong, it is an idea congealing as it is being written