- Glasgow-haskell-users

Re: simple program crash (GHC 5.02, Hugs)
by matthew_bentham＠yahoo.com 21 Dec '01

21 Dec '01

Oleg Galbert wrote: > I'm a newbie in Haskell. > I tryed to compare performance of GHC compiled code and Ocaml compiled > code > on a small example: > > test n cosx > | n==0 = cosx > | otherwise = test (n-1) (cosx+cos(cosx)) > > main = print ( test 10000000 0.0 ) > > I compiled it on Win NT : > > ghc -o test_haskell.exe test_haskell.hs > <snip> > Does a stack usage depends on number of recursive calls? Is there a tail > recursion optimization? <snip> Yes and yes. To turn on the optimiser, add -O or -O2 to the compiler command line: [mjb67@mjb67 mjb67]$ ghc -o test_haskell test_haskell.hs [mjb67@mjb67 mjb67]$ ./test_haskell Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. [mjb67@mjb67 mjb67]$ ghc -O2 -o test_haskell test_haskell.hs [mjb67@mjb67 mjb67]$ ./test_haskell 1.5707963267948966 [mjb67@mjb67 mjb67]$ Hope this helps, Matthew (fellow Haskell newbie :-) )

1 0

Re: ghc image size
by Mike Gunter 21 Dec '01

21 Dec '01

You may not like this argument but its kind are essential to the strategic part of engineering. Since you bring it up, let's consider whether it's worthwhile to optimize code for time. I'm less familiar with the costs of labour but around here (Silicon Valley) labor costs are well in excess of a cent per second. When last I checked, good generalist engineering consultants were charging more than $150/hour (specialists cost more.) (And remember that, like for disk space, their costs are higher than their price.) The rates may have come down somewhat lately but I'm quite sure costs are still well in excess of one cent per second. Moreover, lots of programs take many, many seconds to run and get run many times. So, optimization for time can save you a lot of expensive people time over the long haul. It's worth putting some effort there. One can make a case for reducing executable size in certain contexts. For instance, it's not unreasonable to work to make code loaded by web browsers smaller -- those executables have to be repeatedly moved over slow links while people are waiting. In my environment, though, I don't see much benefit in smaller GHC executables. Are there contexts where it matters more? GHC's resources (the implementation team, the constructive criticism of users, etc.) are limited. I'd hate to see them spent on unimportant things. mike > Mike Gunter <m(a)ryangunter.com> writes: > > > Why is executable size a barrier? 1.64 megabytes (that's the size of > > the executable I built with GHC most recently) of disk space costs less > > than half a cent. > > I don't like this argument. Can I go to a computer store, pay a cent, > and get a hard disk with space 1.64 megabytes or more? Until then, I > can't believe that 1.64 megabytes of disk space costs less than half a > cent. > > When a compiler does not perform as good as other compilers (e.g., in > terms of generated code size), it is important to ask: Why does it > happen? Is there anything we can do to improve it? Being critical is > the first step towards progress. (Of course these questions should be > asked in a constructive rather than whining way.) Why would anyone > optimize code for time --- a second of electricity and labour cost > less than a cent... > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Setting up ghc for GPH and GranSim
by matthew_bentham＠yahoo.com 21 Dec '01

21 Dec '01

Hi all, I'm new to both this list and Haskell, so apologies if these questions have been answered before or seem obvious. I've trawled the website and my suspicion is that I'm using a 'too new' version of the compiler that doesn't support GranSim. Anyway: I'm trying to set up a ghc. I want to compile GPH programs and run them on GranSim. With my current setup (details at the bottom of the mail) I get the following error when I try to compile a GPH program: [mjb67@mjb67 mjb67]$ ghc -gransim -fvia-c -fglasgow-exts --make parfib.hs ghc-5.02.1: can't find module `Prelude' Does anyone have any idea what I might be doing wrong? The error is reported even when the program is normal Haskell, whenever I use the -gransim or -parallel options to the compiler. I presume this is some sort of library issue? My compiler was set up in the following way: I installed the binary RPMs: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.i386.rpm http://www.haskell.org/happy/dist/1.11/happy-1.11-1.i386.rpm I downloaded the source RPM from: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.src.rpm I unpacked the source. I then typed (in the source root directory) ./configure --enable-gransim make make install Thanks in advance, Matthew

1 0

RE: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
by Simon Marlow 21 Dec '01

21 Dec '01

> This example raises a general problem (which, as it turns > out, is relevant > to my current work). How can one mix multithreading with > multiprocessing? In particular, how can a threaded process > safely create > another process to run a program? Put another way, how can the > combination of `forkProcess` and `executeFile` be done > "atomically enough" > so that existing threads in the forking process don't "get in > the way". > > I read something on this topic (involving some sort of > pervasive locking > strategy) recently, but can't recall where. Anybody remember? I can't think of a good way to do this at the Haskell level, because you'd need to halt all the running threads except for the one doing the fork. But one hack which will work is to call out to a C function which does the fork/exec, since foreign calls will be atomic from the point of view of the Haskell RTS. However, one caveat which might be relevant in the future is that if the Haskell program is running in a multi-threaded environment (i.e. OS threads, not Haskell threads), then the C function must be marked 'unsafe' for it to be treated as atomic by the Haskell RTS. The OS thread support in the RTS isn't fully implemented yet, though. Cheers, Simon

1 0

Concurrent and Posix libraries...
by Marcus Shawcroft 20 Dec '01

20 Dec '01

Hi, I want to use a thread in concurrent haskell to manage a posix fork/exec/wait. I expected the test code attached below to output "recovering result" once, instead I get "recovering result" twice. Can anyone shed some light on whats going wrong? (ghci 5.02.1 x86 linux) Thanks /Marcus > module Test where > import Concurrent > import Posix > main = do > mv <- newEmptyMVar > forkIO $ do x <- forkProcess > case x of > Nothing -> do > executeFile "sleep" True ["2"] Nothing > error "oops" > Just pid -> > getProcessStatus True False pid > putMVar mv () > print "recovering result" > takeMVar mv

2 1

GHC-3.02 (maybe OFF-time)
by Rafael Martínez Torres 20 Dec '01

20 Dec '01

Hi all: I'm hacking with ghc-3.02.src.tar.gz on several platforms, namely i386 and sparc ... Both platforms run with gcc-2.7.2.3 ( higher versions may be a risk , 2.95 was bad...) In sparc I have no problems, but in i386 I do obtain the next results (File : fptools/ghc/lib/posix/PosixProcPrim.hc) "../../../ghc/driver/ghc -i../misc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O '-#include"cbits/libposix.h"' -c PosixProcPrim.hc -o PosixProcPrim.o -osuf o PosixProcPrim.hc:2244: fixed or forbidden register was spilled. This may be due to a compiler bug or to impossible asm statements or clauses." I think cc1 is reducing uncorrectly to asm code. Reading documents on gcc, I got this... ( File: /usr/docs/gcc/PROBLEMS ) May be has nothing to do... "3. When find_reloads is used to count number of spills needed it does not take into account the fact that a reload may turn out to be a dummy." May be this is rather a question for gcc , but... Does any body know where to add any flag to help gcc to reduce OK ? I tried no -O flag , -O2 ,-O1, but no sucess... Regards... Martinez-Torres.

1 0

RE: GHC-3.02 (maybe OFF-time)
by Simon Marlow 20 Dec '01

20 Dec '01

> I'm hacking with ghc-3.02.src.tar.gz on several platforms, namely i386 > and sparc ... > > Both platforms run with gcc-2.7.2.3 ( higher versions may be a risk , > 2.95 was bad...) > > In sparc I have no problems, but in i386 I do obtain the next results > (File : fptools/ghc/lib/posix/PosixProcPrim.hc) > > "../../../ghc/driver/ghc -i../misc -recomp -cpp -fglasgow-exts -fvia-C > -Rghc-timing -O '-#include"cbits/libposix.h"' -c > PosixProcPrim.hc -o > PosixProcPrim.o -osuf o > PosixProcPrim.hc:2244: fixed or forbidden register was spilled. > This may be due to a compiler bug or to impossible asm > statements or clauses." You need to give GHC the -monly-3-regs (or possibly -monly-2-regs) option. Cheers, Simon

1 0

RE: unexpected space leak
by Julian Seward (Intl Vendor) 20 Dec '01

20 Dec '01

It's a hack we put in, because fixing the bytecode generator properly for this relatively obscure case was a lot of effort and other calls on our time (we were stabilising for the 5.02 release at the time) were more pressing. It is (nearly) harmless. What usually causes it is having strict polymorphic fields on constructors: data T a = T !a The warning is intended to mean that the strictness annotation will be ignored in interpreted code. This shouldn't have any effect on the overall outcome of your program, unless it depends on evaluation order changes induced by the !, for some gruesome reason. However, the space behaviour may well be different from what it would be if ! was observed. If you do experience problems as a result of this, I'd be interested to hear of them. J | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: Wednesday, December 19, 2001 11:22 PM | To: GHC Users Mailing List | Subject: unexpected space leak | | | what does it mean when ghci says: | | WARNING: ignoring polymorphic case in interpreted mode. | Possibly due to strict polymorphic/functional constructor args. | Your program may leak space unexpectedly. | | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

(no subject)
by mailer.daemon＠server1.home4.com 20 Dec '01

20 Dec '01

1 0

unexpected space leak
by Hal Daume III 19 Dec '01

19 Dec '01

what does it mean when ghci says: WARNING: ignoring polymorphic case in interpreted mode. Possibly due to strict polymorphic/functional constructor args. Your program may leak space unexpectedly. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0