- Glasgow-haskell-users

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 28 Oct '05

28 Oct '05

On 24 October 2005 17:23, John Goerzen wrote: > 9. Now run dist/build/gopherbot. > > You should see it start to download documents, and crash after a > few minutes. I have it running on my laptop, but I'm behind a firewall right now and I guess it doesn't understand the http_proxy environment variable (is there a way to tell it to use a proxy?). At least, it seems to be complaining about timeouts on its connections. I'll try later outside the firewall. Cheers, Simon

2 1

RE: Default name of target executable
by Simon Marlow 28 Oct '05

28 Oct '05

On 24 October 2005 21:45, Tomasz Zielonka wrote: > On 10/24/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: >> Here is the patch. > > Again, with a small bugfix in docs. Thanks; now committed. Cheers, Simon

1 0

[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
by SourceForge.net 28 Oct '05

28 Oct '05

Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Settings changed) made by jch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_…

1 0

[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
by SourceForge.net 28 Oct '05

28 Oct '05

Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_…

1 0

GHC-6.4.1 much slower than GHC-6.4
by Mirko Rahn 27 Oct '05

27 Oct '05

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 noticed such behavior? What could be the reason for that? Sorry, my example is a small monster, but at the moment there is neither time left to search for the reason for this behavior nor to break it down to some smaller pieces of code. I just noticed it... However, you can find the source tree in http://liinwww.ira.uka.de/~rahn/src/ The file http://liinwww.ira.uka.de/~rahn/src/prog.tar.gz contains the tree as well. For the output above: Extract, cd proj/prog and run rahn@i90pc18:~/local/proj/prog$ for version in 6.4 6.4.1; do find . -name '*.hi' | rm -f ; ghc-$version --make -Wall -cpp -D__POS__='__FILE__ ++ "[" ++ show(__LINE__::Int) ++ "]: " ++ ' -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -O Prog/Interesting.hs -o Prog/Interesting.$version.bin 2>/dev/null >/dev/null; echo -n "*** $version: " ; ./Prog/Interesting.$version.bin 2>&1 | grep time ; done Regards, Mirko P.S.: I run a debian-box with i686 GNU/Linux 2.6.11.11 and a dualcore P4 3.2 GHz. -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

2 1

RE: jhc vs ghc and the surprising result involving ghcgeneratedassembly.
by Simon Marlow 27 Oct '05

27 Oct '05

On 27 October 2005 12:12, John Meacham wrote: >> Note that GHC's back end is really aimed at producing good code when >> there are registers available for passing arguments - this isn't >> true on x86 or x86_64 at the moment, though. > > Hrm? why are registers not available on x86_64? I thought it had a > plethora. (compared to the i386) mutter mutter... a bunch of the registers are reserved for argument passing in the C calling convention, and when I tried to steal them I ran into trouble around foreign calls. It should/might be possible to work around this, I need to have another go. It works fine with the NCG, of course. > I was thinking something like the worker/wrapper split, ghc would > recognize when a function takes only unboxed arguments and returns an > unboxed result (these can probably be relaxed, no evals is the key > thing) > > so in the case of fac, it would create > > int fac(int n, int r) { > if (n == 1) return 1; > return fac (n - 1,n*r); > } > > and (something like) > > void fac_wrapper(void) { > continuation = pop() // I might be mixing up the order of these > n = pop() > r = pop() > > x = fac(n,r) > > push(x) > jump(continuation) > > } Well yes, but if the worker needs to return to the scheduler (i.e. if it does a heap check or stack check) then the C stack is all messed up and we need a setjmp/longjmp to get back to the scheduler. You can do it in the case where there are no heap/stack checks, but I think that's very rare. > 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) :-D > fortunatly, modern CPUs anticipate this conondrum and provide > 'write-combining' forms of their memory access functions, these will > write a value directly to RAM without touching the cache at all. This > will always be a win when updating thunks due to the reasons mentioned > above and is potentially a big benefit. selective write-combining is > in the top 3 performance enhancing things according to the cpu > optimization manuals. > > I think the easiest way to do this would be to have a MACRO defined to > an appropriate bit of assembly or a simple C assignment if the > write-combining mov's arn't available. very good idea, I must try that. Any more progress on why our x86_64 code is slow? Cheers, Simon

1 0

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 27 Oct '05

27 Oct '05

On 26 October 2005 19:58, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> 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 unregisterised .hc-bundle available on the net > for other users wanting to install ghc on freebsd-amd64. > Or is ist better to generate a new registerised .hc-bundle? A binary distribution would be best. You can build one as follows: - add BIN_DIST=1 to mk/build.mk - make clean; make - make binary-dist Project=Ghc - tar cvzf ghc-6.4.1-x86_64-unknown-freebsd.tar.gz ghc-* the unreg & reg hc-bundles are also useful. Cheers, Simon

1 0

RE: aha! I think.
by Simon Marlow 27 Oct '05

27 Oct '05

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. AFAIK we never misalign 8-byte things on x86_64. We align everything to 8 bytes. Cheers, Simon

1 0

RE: aha! I think.
by Simon Marlow 27 Oct '05

27 Oct '05

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 any processor, including a > whole chapter on how to write C code that optimizes well independent > of the CPU) > > "don't place code and data on the same cache line" I'd be surprised if this is an issue. GHC doesn't normally touch the info tables during execution (with one exception - getting the tag from a constructor in a datatype with >8 constructors). It touches the info tables during GC, but it doesn't touch the code during GC. So we might push some code out of the cache on a GC, but that shouldn't have a large effect. It could be an alignment issue, I suppose. Or passing arguments in registers (we don't, at the moment, on x86_64). If you have any handy test programs, can you try fiddling with the alignment of code blocks and see if you get a measurable difference? (I'm still digesting your other message, I'll reply in due course). Cheers, Simon

2 1

aha! I think.
by John Meacham 27 Oct '05

27 Oct '05

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/251… (which has a whole lot of good info for any processor, including a whole chapter on how to write C code that optimizes well independent of the CPU) "don't place code and data on the same cache line" it will cast out the code line from the cache on acces to the data and vice versa. so basically, ghc is running L1 cacheless on the x86-64 if I understand things properly. (maybe for other CPUs too, we might want to check the intel optimization manuals too) If it is too difficult to separate the code and data from each other (which it might be, since ghc goes through specific measures to put them next to each other) then making sure the transition from code to data occurs exactly on a 64 byte cache line boundry might solve this issue. it would mean that each function takes up a minimum of 128 bytes and we can't have more than one per cache line.. but perhaps that is an acceptable tradeoff, but we might want to inline more to get bigger functions so we don't have to pad so much. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0