- Glasgow-haskell-users

Re: enormous executable
by Marcin 'Qrczak' Kowalczyk 02 Oct '01

02 Oct '01

Mon, 1 Oct 2001 09:55:11 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > We don't have support for shared libraries under Unix at the moment. It > has been investigated at various times in the past, and I believe the > story is that we couldn't do it without at least losing some performance > (more performance loss than you get from compiling C into a shared > library). There is also a big problem of binary incompatibility between different versions of ghc, and dependence on the exact version of modules our package depends on. Dynamic libraries work for C because C has a very stable ABI. Also it's easy to maintain binary compatibility in libraries. I'm afraid that cross-module optimizations of ghc make dynamic libraries nearly impractical. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

ghc-pkg
by Malcolm Wallace 02 Oct '01

02 Oct '01

I notice that the method for detecting the configuration of ghc (for building 'hmake') no longer works with 5.02. This must be the most unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, and now 5.02 as well! > ghc-pkg-5.00 --show-package std --field import_dirs /usr/malcolm/local/lib/ghc-5.00/imports/std > ghc-pkg-5.02 --show-package std --field import_dirs $libdir/imports/std There does not appear to be any way to persuade the new ghc-pkg to reveal what $libdir is set to. Can someone give me a clue how to discover this information? Regards, Malcolm

1 0

enormous binaries
by Willem Robert van Hage 02 Oct '01

02 Oct '01

Hello, I'm trying out GHC along with gtk+hs and iHaskell and I was surprised that a simple example with a list of selectable distribution names generated a binary of 2Mb. So I tried a simple hello world example exactly like the one I saw somewhere on the GHC pages that compiled to a binary of 6kb and I was surprised to see that even after stripping the binary it still takes up 140kb. Is there a good explanation for this? Am I doing something wrong or is it something else? ~/haskell/ghc-test % cat hello.hs module Main where main = putStrLn "hello, world!" ~/haskell/ghc-test % ghc -o hello hello.hs ~/haskell/ghc-test % ls -l total 212 -rwxr-xr-x 1 willem users 201453 Sep 29 09:55 hello -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o ~/haskell/ghc-test % strip hello ~/haskell/ghc-test % ls -l total 152 -rwxr-xr-x 1 willem users 141024 Sep 29 09:59 hello -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o ~/haskell/ghc-test % strings hello > strs I attached the file strs, maybe someone can deduce something from its contents... Willem van Hage -- wrvh(a)xs4all.nl | http://www.xs4all.nl/~wrvh wrvhage(a)science.uva.nl | http://quest.sourceforge.net

2 1

RE: More 5.02 downloads
by Simon Marlow 01 Oct '01

01 Oct '01

> Is there any chance of a MacOSX binary release? We're not planning to make one ourselves, but hopefully one of our friends with MacOS X expertise will help out: Atze, Sebastien - any plans? Cheers, Simon

2 1

FreeBSD/x86 package of 5.02 available
by Simon Marlow 01 Oct '01

01 Oct '01

There's a proper package of 5.02 for FreeBSD/x86 4.4-STABLE here: http://www.haskell.org/ghc/dist/5.02/ghc-5.02.tgz Please let me know whether it does/doesn't work for you. I've submitted the port to the FreeBSD folks, but it may be a while before they integrate it. Cheers, Simon

1 0

RE: enormous executable
by Simon Marlow 01 Oct '01

01 Oct '01

> "Julian Seward (Intl Vendor)" <v-julsew(a)microsoft.com> writes: > > > On Linux and probably most Unixes, the text and data segments > > of the executable are loaded page-by-page into memory on > > demand. So having a lot of unused junk in the executable doesn't > > necessarily increase the memory used, either real memory or > > swap space. > > (Surely not swap, since code is just paged from the > executable image :-) Not if the executable comes from an NFS server - it might be quicker to back it with swap space. I believe this is what some OSs do (though not Linux, I think). > Surely the executable itself is only linked with the functions > that are actually used by the program? Sure, except that this is done at the level of granularity of a module, which when we're talking about Haskell code tends to be quite large. This is where GHC's -split-objs comes in: it splits modules into smaller units, which reduces the chances that you end up linking with something you don't need. Actually static linking is better for locality in the binary, because the memory paged into the running executable is more likely to be densely packed with useful functions. Shared libraries only really come into their own when there are multiple running programs using the same library - otherwise they are a loss for both performance and memory use. > Or are you talking about working set? I'd expect a GUI library to > have considerable initialization etc. code, which is used relatively > rarely. In that case, the waste is mostly disk space, which is > abundant these days. > > My thought was, however, that the GUI toolkit is probably used by > multiple other (non-haskell) programs, and could be usefully shared. The C code in GTK lives in shared libraries, which are still dynamically linked against the executable when you use GTK+HS. It's just the Haskell code which is statically linked. Cheers, Simon

1 0

RE: enormous executable
by Julian Seward (Intl Vendor) 01 Oct '01

01 Oct '01

| Surely the executable itself is only linked with the | functions that are actually used by the program? AFAIUI the GNU linker is not clever enough to remove junk on a per-function basis, only on a per-object basis. This is why we do object-splitting -- by breaking libraries up into thousands of .o files before rolling them into a .a, the effectiveness of what GNU ld can do is enhanced. Perhaps more recent GNU ld's do better on some platforms? I have a vague recollection of some -gc-sections flag. J

1 0

RE: enormous executable
by Julian Seward (Intl Vendor) 01 Oct '01

01 Oct '01

| OTOH when you start using and reusing larger libraries, like | Gtk+, the waste accumulates, and it's possibly you don't need | to run too many GTK+HS programs before you see performance decrease | due to memory exhaustion. On Linux and probably most Unixes, the text and data segments of the executable are loaded page-by-page into memory on demand. So having a lot of unused junk in the executable doesn't necessarily increase the memory used, either real memory or swap space. I think it's basically harmless providing you're only running one instance of the program on the machine. J

2 1

RE: enormous executable
by Simon Marlow 01 Oct '01

01 Oct '01

> > > -rwxr-xr-x 1 willem users 201453 Sep 29 09:55 hello > > > -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs > > > -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o > > > > Probably, the executable hello is 1000 times larger than object > > one because some piece of library (including binary code for > > outputting a string) is linked to it. > > In small user programs the library code is usually the larger > > part. In large user programs, it will be the smaller part. > > > > Serge Mechveliani > > I think so too, but what I'm surprised about is that GHC apparently > can't use printing functions and all those other things I saw in > `strings hello`, for example things about sockets, forks and file IO, > from a library instead of compiling it into the 'hello' binary. We don't have support for shared libraries under Unix at the moment. It has been investigated at various times in the past, and I believe the story is that we couldn't do it without at least losing some performance (more performance loss than you get from compiling C into a shared library). So what you're seeing is static linking in action. We do have some hacks in our library building to "split" objects into small chunks so that static linking doesn't result in *huge* binaries (see the -split-objs flag), but this isn't being used in GTK+HS, hence the 2Mb binaries. Cheers, Simon

2 1

memory management
by S.D.Mechveliani 01 Oct '01

01 Oct '01

Simon Peyton-Jones <simonpj(a)microsoft.com> writes on my recent bug reports > Simon is going to look into the storage management bug. > I believe that it does not show up if you do not use the > (new) compacting garbage collector, correct? > > We'll produce 5.02.1 when we know what the cause is; > meanwhile, can you just switch off compacting GC? > (Admittedly, that would be easier to do if you could > specify some run-time flags at link time, which is something > we've been thinking about.) See my new smallest report of today to ..bugs@.. And I tried to switch out the new garbage collector by +RTS -c100 -RTS, and this does not help. On the other hand, this looks like a trouble with memory management: -M100k - all right, -M300k - Heap exhausted. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0