- Glasgow-haskell-users

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

Re: Default name of target executable
by Tomasz Zielonka 24 Oct '05

24 Oct '05

On 10/14/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: > On 10/14/05, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > HEAD definitely. We don't change the specification of STABLE, only fix > > bugs. > > Great, I have the initial implementation, but I'll try to make it > prettier. Here is the patch. Some notes: - I am not sure if it's OK to modify Session in this place. Perhaps my code should be called from DriverPipeline.staticLink, but it has no access to module graph, and I didn't want to make such a big change - I wanted to add .exe suffix on Windows, but if I think that GHC relies on mingw32 tools to add it when necessary. - There is some documentatin in separate_compilation.xml. I wrote about the ability to put Main in file other than Main.hs, but I couldn't find documentation for this feature. Tell me if there are other places where this feature should be mentioned. - I didn't check that docs are properly generated after my changes. Besides, the language can be incorrect. Best regards Tomasz

1 1

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

24 Oct '05

On 18 October 2005 20:26, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> At this point you can either do 'make install stage=1', or you can >> just use the compiler you built to build a clean GHC in another >> tree, i.e. with ./configure >> --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. > > Now I am getting the following really strange error message: > > ==fptools== gmake all -wr; > in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler > ------------------------------------------------------------------------ > /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler/ghc-inplace > -H16m -O -istage1/utils -istage1/basicTypes -istage1/types > -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck > -istage1/deSugar -istage1/coreSyn -istage1/specialise > -istage1/simplCore -istage1/stranal -istage1/stgSyn > -istage1/simplStg -istage1/codeGen -istage1/main > -istage1/profiling -istage1/parser -istage1/cprAnalysis > -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm > -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package > template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts > -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser > -package unix -ignore-package lang -recomp -Rghc-timing -H16M > '-#include "hschooks.h"' -i../lib/compat -ignore-package Cabal -H80m > -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi > stage1/prelude/PrimOp.hi > > prelude/PrimOp.lhs:104:0: parse error (possibly incorrect indentation) > <<ghc: 30809992 bytes, 2 GCs, 129776/129776 avg/max bytes residency > (1 samples), 60M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.10 > elapsed), 0.01 GC (0.02 elapsed) :ghc>> > gmake[2]: *** [stage1/prelude/PrimOp.o] Fehler 1 > gmake[1]: *** [install] Fehler 1 > gmake[1]: Leaving directory > `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc' > gmake: *** [install] Fehler 1 > > I checked that PrimOp.lhs is identical with the versions in > -i386amd64 and -amd64, so the error message text is certainly > misleading. PrimOp.lhs includes a bunch of files that are auto-generated from primops.txt. In ghc/compiler you should have a bunch of files called primop-*-incl, which are generated by the genprimopcode program in ghc/utils/genprimopcode. If these files are empty or corrupt, just remove them and re-build. Are you building GHC in a fresh tree now? I'd recommend doing that. Cheers, Simon

2 2