- Glasgow-haskell-users

RE: inside the GHC code generator
by Simon Peyton-Jones 12 Mar '06

12 Mar '06

| last days i studied GHC code generator, reading -ddumps of all sorts, | GHC sources, various papers and John's appeals :) | | what i carried from this investigation: | | GHC has great high-level optimization. moreover, GHC now allows to | program STG almost directly. when i look at STG code i don't see | anything that can be done better - at least for these simple loops i | tried to compile. i see just unboxed variables, primitive operations | and simple loops represented as tail recursion. fine. | | then STG compiled to the simplified C (called abstract C earlier and | quasi C-- now), what is next can be translated: | | * to real C and then compiled by gcc | * to assembler by build-in simple C-- compiler | * to assembler by some external C-- compiler (at least it is | theoretically possible) Good stuff Bulat. There's plenty of interesting stuff to be done here. However, let me strongly urge you *not* to focus attention primarily on the gcc route. Compiling via C has received a lot of attention over the years, and there are many papers describing cool hacks for doing so. GHC does not do as well as it could. But there are serious obstacles. That's not gcc's fault -- it wasn't designed for this. Accurate GC is one of them, tail calls is another, and there are plenty more smaller things that bite you only after you've invested a lot of time. This way lies madness. C-- was *designed* for this purpose. GHC uses C-- as its intermediate language (just before emitting C). So a good route is this: * Write C-- to C-- optimisations * Then, if you like, translate that code to C. Already you will be doing better than GHC does today, because the C-- to C-- optimiser will let you generate better C * But you can also emit C--, or native code; both of these paths will directly benefit from your C-- optimisations. The point is that none of this relies on Quick C--; you can always use an alternative back end. You can almost do this today. GHC uses C-- as an intermediate language. But alas, GHC's code generator does not take advantage of C--'s native calls or parameter passing. Instead, it pushes things on an auxiliary stack etc. (Those Sp memory operations you see.) This isn't necessary. We are planning to split GHC's code generator into two parts A) Generate C-- with native calls, with an implicit C-- stack B) Perform CPS conversion, to eliminate all calls in favour of jumps using an explicit stack The current code gen is A followed by B. But A is a much more suitable optimisation platform, and gives more flexibility. Chris Thompson, and undergrad at Cambridge, is doing (B) as his undergrad project, although it remains to be seen whether he'll have enough complete to be usable. Another shortcoming is that the native code generator in GHC isn't capable of dealing with backward jumps to labels (because GHC hasn't needed that so far). But if you did C-- optimisation, you'd probably generate such jumps. It'd be great to beef up the native code gen to handle that. Many of the optimisations you describe (perhaps all) are readily expressible in the C-- intermediate language, and by working at that level you will be independent of with the back end is gcc, a native code generator, or Quick C--, or some other C-- compiler. Much better. Simon

6 5

RE: Re[2]: How to find out the C type signature corresponding to a Haskell function type in FFI?
by Simon Marlow 10 Mar '06

10 Mar '06

On 09 March 2006 16:39, Bulat Ziganshin wrote: > Hello Simon, > > Thursday, March 9, 2006, 5:08:09 PM, you wrote: > >>>> for small "home" projects you can even use "Int" and "int" which >>>> would work in most of Haskell implementations > >> Yes, and to give a concrete example: HsInt and int are different >> types on x86_64 (and most other 64-bit C implementations). > > yes, it's better to use "Int" and "long" types :) I hope that smiley means you're joking... Cheers, Simon

1 0

RE: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
by Simon Marlow 10 Mar '06

10 Mar '06

On 09 March 2006 18:19, Michael Marte wrote: > Simon Marlow wrote: > >> Michael Marte wrote: >> >>> Lennart Augustsson wrote: >>> >>>> I'm not implying anything, except that I've plugged the space >>>> leak of 256M every time a DLL is loaded&unloaded. >>>> >>>> -- Lennart >>>> >>>> Michael Marte wrote: >>>> >>>>> Lennart, >>>>> >>>>> do you imply that you have fixed the problem causing the crashes? >>>>> May I safely assume that DLLs produced by ghc 6.4.2 will not crash >>>>> upon being freed? >>>> >>>> >>>> >>> I wanted to test the fix for ticket #711 but I am stuck because >>> there is no current snapshot of ghc 6.5 for mingw. (The last one is >>> dated end of February, the patch was commited on March, 2nd.) >> >> >> The patch hasn't been committed at all, AFAIK. > > Ok, it am new to Darcs, so this patch is only a proposal contained in > the ticket? > >> >>> I saw that the patch is scheduled for milestone 6.4.2 but has been >>> commited only for 6.5. When will it be available for 6.4.2? >>> >>> I started learning to compile ghc and I have succeeded with the >>> current head of the 6.4 branch on Debian Linux/testing. Next step is >>> to compile the head on this system. My current problem is a missing >>> symbol when linking stage1/ghc-6.5, namely u_gencat referenced by >>> stage1/parser/Lexer.o. Am I missing some library? >>> (I think my sources are up to date, I pulled only half an hour ago.) >> >> >> When compiling with 6.4.1 or later, u_gencat should come from >> libHSbase_cbits.a in your 6.4.1 installation. Is it there? >> >> > No, I am compiling with plain 6.4 (a newer Debain package is not > available) and it does not have u_gencat in this library. > However I can compile the head of the 6.4 branch which in turn should > be able to compile the head, shouldn't it? Yes, I think a plain 6.4 can't compile the HEAD right now. We'll try to fix this, but for now you should use a 6.4.1 or later. Cheers, Simon

1 0

Memory leak in Fudgets
by Dimitry Golubovsky 09 Mar '06

09 Mar '06

I wrote a very simple Fudgets program (just copies stdin to stdout, no graphics involved) -------- leaktest.hs ------------------ module Main where import Graphics.UI.Fudgets.Fudgets main = fudlogue (stdoutF >==< stdinF) and ran it like this: yes | leaktest I found out that the program grows in memory. Its "traditional" analog: -------- leaktest2.hs ----------------- module Main where import System.IO main = do hGetLine stdin >>= hPutStrLn stdout main works in constant space. I tried to observe the GC realtime stats with +RTS -Sstderr -M600K It turns out, garbage is collected, number of allocated and collected bytes are mostly constant, and number of live bytes fluctuates, but averagely stays the same: Alloc Collect Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 316720 262144 9528 0.00 0.00 0.02 0.02 144 499 (Gen: 0) 262128 262144 22188 0.01 0.01 0.03 0.04 0 3 (Gen: 0) 262128 262144 8276 0.00 0.00 0.04 0.05 0 0 (Gen: 0) 262128 262144 24612 0.01 0.01 0.05 0.06 0 0 (Gen: 0) 262128 262144 10680 0.00 0.00 0.06 0.07 0 0 (Gen: 0) 262128 262144 23376 0.00 0.00 0.06 0.08 0 0 (Gen: 0) 262128 262144 9444 0.00 0.00 0.07 0.09 0 0 (Gen: 0) 262012 262144 25492 0.00 0.00 0.07 0.10 0 0 (Gen: 0) ... program grows to 10M ......... 262128 262144 1684 0.01 0.01 42.33 66.10 0 0 (Gen: 0) 262128 262144 13396 0.01 0.01 42.34 66.11 0 0 (Gen: 0) 262124 262144 25540 0.01 0.01 42.35 66.12 0 0 (Gen: 0) 262128 262144 11988 0.00 0.00 42.35 66.13 0 0 (Gen: 0) 262128 262144 1760 0.00 0.00 42.36 66.14 0 0 (Gen: 0) 262128 262144 14464 0.00 0.00 42.37 66.15 0 0 (Gen: 0) 262128 262144 1656 0.00 0.00 42.37 66.16 0 0 (Gen: 0) .... and was interrupted ........... 1,614,769,480 bytes allocated in the heap 78,801,952 bytes copied during GC 25,624 bytes maximum residency (6160 sample(s)) 6160 collections in generation 0 ( 10.35s) 1 Mb total memory in use INIT time 0.01s ( 0.00s elapsed) MUT time 32.01s ( 55.38s elapsed) GC time 10.35s ( 10.78s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 42.37s ( 66.16s elapsed) %GC time 24.4% (16.3% elapsed) Alloc rate 50,430,027 bytes per MUT second Productivity 75.5% of total user, 48.4% of total elapsed So, what could be the reason of such memory leak? What else may grow if the heap remains constant? How can it be observed? Any ideas are welcome. -- Dimitry Golubovsky Anywhere on the Web

3 2

Allocating aligned memory?
by Li, Peng 09 Mar '06

09 Mar '06

In GHC, how can I allocate a chunk of memory aligned to some block size (say, 512 or 1024 bytes)? I tried to specify it in the "alignment" method in the Storable typeclass, but that does not seem to work. Is Storable.alignment really used in GHC? If so, is there a code example that allocates aligned memory in this way? For the moment I am using the C function memalign() like this: foreign import ccall "static stdlib.h" memalign :: CInt -> CInt -> IO (Ptr CChar) .... do ptr <- memalign alignment size fptr <- newForeignPtr finalizerFree ptr Is it safe to do so? Thanks, Peng

4 3

How to find out the C type signature corresponding to a Haskell function type in FFI?
by Brian Hulley 09 Mar '06

09 Mar '06

Hi - I've got a Haskell module with the following ffi import: foreign import ccall duma_init :: Int -> IO Int However my problem is that I've got no idea what the type signature for the corresponding C function should be, and when I compile the above module with ghc -fglasgow-exts -fffi --make it doesn't create any stubs either. I've tried looking at the wiki but that only seems to give specific examples. I'm trying to find what the mapping is between Haskell function signatures and C signatures is in general. Any ideas? Also, I really wanted to be able to use () -> IO () but () doesn't seem to be allowed in FFI... A third point is, how would I pass an arbitrary monad instead of just using IO? Thanks, Brian.

7 11

Using GHC with SMP and FFI?
by Li, Peng 09 Mar '06

09 Mar '06

[1] Extending the Haskell Foreign Function Interface with Concurrency [2] Haskell on a Shared-Memory Multiprocessor I read the above two papers [1,2] and I have been trying to write an application that uses both FFI and SMP. The first paper [1] shows how FFI is implemented on uniprocessor concurrent Haskell; the second paper [2] shows how SMP Concurrent Haskell is implemented. However, I found little documentation on using FFI with the latest SMP extension. In addition to [1], what has been changed and what should a programmer know if he wants to use FFI in a multithreaded program running on SMP machines? Best, Peng

2 1

--make keep going?
by John Meacham 09 Mar '06

09 Mar '06

is there an option to get ghc to keep going if it encounters an error building a file with --make? as in, I'd like it to continue compiling as much as it can only skipping what actually depends on the file that failed rather than completly aborting everything. John -- John Meacham - ⑆repetae.net⑆john⑈

4 4

Getting GHC to print "Done" when it's finished linking?
by Brian Hulley 07 Mar '06

07 Mar '06

Hi - I've set up my Visual Studio environment so that ghc is an external tool, where the output from ghc appears on the VS output pane. However when I use this to compile and link a Haskell program (I'm just using the plain text editor that comes with VC++ not the Haskell plugin because of its unfortunate MS-restricted-use licence...) the last thing ghc prints is: Linking ... but when it's finished nothing else is printed out, with the net result that I sit and wait forever! :-) Is there any flag to get ghc or the ghc linker to print "Done" or something when it's finished? Thanks, Brian.

3 5

Re: ghc on on macbook pro (fwd)
by Wolfgang Thaller 05 Mar '06

05 Mar '06

On 4-Mar-06, at 3:33 PM, Geoffrey Alan Washburn wrote: > I don't have MacOS X Intel handy to verify, but I was under the > impression that Rosetta was only automagically invoked by the > operating system on application bundles. However, there is a > dearth of information regarding this point on the web, so I could > be wrong. Fortunately, you are :-). It's automagically invoked by the kernel's executable loader whenever any Mach-O binary is loaded that only has ppc code. You're right about the lack of (easily available) information though. A friend of mine was at the conference when they announced the switch, so I just asked him to try it out; I have found no place on the web that spells it out. Cheers, Wolfgang

1 0