- Glasgow-haskell-users

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

RE: 5.04 ?
by Simon Peyton-Jones 01 Oct '01

01 Oct '01

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.) Simon | -----Original Message----- | From: S.D.Mechveliani [mailto:mechvel@math.botik.ru] | Sent: 29 September 2001 13:46 | To: glasgow-haskell-users(a)haskell.org | Cc: Simon Marlow | Subject: 5.04 ? | | | Dear GHC, | | I have tested ghc-5.02 | on various examples of computer algebra, with -O too. | | All tests are all right, | | except it shows a bug in memory management (Simon Marlow | wrote of), visible in subtly chosen cases. | | The impression is that 5.02 saves much memory and gains performance | in situations involving garbage collections (most practicable case). | | But due to the above bug, would 5.04 appear soon as a stable | release? | For I need to mention some newest stable GHC release in DoCon | program documentation. | | Regards, | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

5.04 ?
by S.D.Mechveliani 29 Sep '01

29 Sep '01

Dear GHC, I have tested ghc-5.02 on various examples of computer algebra, with -O too. All tests are all right, except it shows a bug in memory management (Simon Marlow wrote of), visible in subtly chosen cases. The impression is that 5.02 saves much memory and gains performance in situations involving garbage collections (most practicable case). But due to the above bug, would 5.04 appear soon as a stable release? For I need to mention some newest stable GHC release in DoCon program documentation. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: enormous executable
by S.D.Mechveliani 29 Sep '01

29 Sep '01

Willem Robert van Hage <wrvh(a)xs4all.nl> writes > [..] > 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. > > -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 It shows that source program takes 51 bytes, compiled object program - 1468 bytes. This is not mauch. 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. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

compiling hmake
by Colin Paul Adams 29 Sep '01

29 Sep '01

Can anyone tell me what options to pass to configure when trying to compile hmake with ghc 5.02? -- Colin Paul Adams Preston Lancashire

1 0