October 2005 - Glasgow-haskell-users

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

27 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 26 Oct '05

26 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

vectors
by John Meacham 26 Oct '05

26 Oct '05

as an interesting tidbit, gcc now supports using vector (SIMD) types directly as if they were normal C types in a portable way.. I wonder how hard it would be to expose these types to the user in ghc? http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Vector-Extensions.html things like matricies and complex numbers might be greatly sped up. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: GHC and Windows (DLL/FFI) woes
by Simon Marlow 26 Oct '05

26 Oct '05

On 23 October 2005 19:00, Esa Ilari Vuokko wrote: > I have been trying to build some Windows DLLs with > GHC, and I have run into some misfeatures or maybe > I have misunderstood how to use GHC. Any help or > advice would be appreciated. :) > > First of all, I can't get ghc to generate stubs from > foreign export in anywhere else than next to original > source, which is sort of annoying. I would like all > the generated files to go quite a bit diffrent place than > source directory. We don't have a flag for that; perhaps we should. Or perhaps there should be a flag that says "put all generated files here", that subsumes -odir, -hidir, -hcdir and also coveres _stub.{c,h} files. > Next, --make and --mk-dll don't seem to work together. > Ok, what I do, is I just --make -no-link and then --mk-dll > all the object files I find :) That's true. This is closer to working in 6.5, we should make it work (if anyone's interested, this just means hooking up DriverPipeline.link with DriverPipeline.doMkDLL in the right way). > It seems that -i flag and compiling those _stub.c have > following problem: if path given in -i flag contains any > /- or \-characters, i.e. any real subpaths, it seems to > stop with something like: > \source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d: : > createDirectory: invalid argument (Invalid argument) > It seems a bit random what is the supposed "filename" > part of the path, typically it contains drive letter and few > colons, it doesn't seem totally random data. Could you give me a detailed description of the problem: the exact command line, and the error message that is produced. Thanks. Cheers, Simon

2 1

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

25 Oct '05

On 24 October 2005 19:04, Wilhelm B. Kloke wrote: > Wilhelm B. Kloke <wb(a)arb-phys.uni-dortmund.de> schrieb: >> Simon Marlow <simonmar(a)microsoft.com> schrieb: >>> >>> Are you building GHC in a fresh tree now? I'd recommend doing that. >> >> Now I am using a *really* fresh tree. Formerly the compilation of >> Apply.cmm did not render an instructive error message, just >> failed for some sort of memory access exception. Now I have: >> > I have enabled freebsd in the mangler now. After installing with > make install stage=1 > the compiler compiles an .o and .hi file, but it does not find the > libraries to link with for test.hs. Is it that it does not find the libraries, or does it find the libraries but still gets a bunch of undefined references? If the latter, then there could be an issue with the mangler. Try an 'nm' on libHSbase.a to see if the missing symbols are actually defined. Cheers, Simon

2 1