- Glasgow-haskell-users

Re: Multi-parameter OOP
by Marcin 'Qrczak' Kowalczyk 19 Oct '01

19 Oct '01

Fri, 19 Oct 2001 17:02:54 +0200, George Russell <ger(a)tzi.de> pisze: > So is there any other way of doing this sort of dynamic lookup at > runtime, in a reasonably neat way? There is module Dynamic. I don't know if it helps or is reasonably neat. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Your Property Portfolio
by Smith Hawkshaw Properties 19 Oct '01

19 Oct '01

1 0

Why is (monad) elegance so costly?
by marku＠cs.waikato.ac.nz 19 Oct '01

19 Oct '01

I am about to rewrite my Z animation tool (JAZA) in a style that makes more intensive use of state monads. However, my experiments with a simplified lambda-calculus example shows that (with GHC 5.00) the state monad is dramatically less efficient than the simple identity monad: 4 TIMES SLOWER, and 7 TIMES MORE MEMORY! Is this normal? Acceptable? Am I doing something wrong? Can anyone suggest ways of reducing these overheads? (I am very keen to use state-monads if possible, because it allows my 'eval' code to be generic over the monad that is used, which allows me to reuse the code with other similar monads. In fact, I am using it to simulate the 'visitor' design pattern from OO langs.) Hugs gives slightly smaller differences (3 times more reductions and 3.5 times more cells), but I had hoped that GHC would be able to optimize most of the state monad overhead away (especially when the monad uses newtype)? My code and speed measurements are attached. Mark.

1 0

RE: Working character by character in Haskell
by Jan-Willem Maessen 19 Oct '01

19 Oct '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > To really match the C program, you need to use IOExts.hGetBuf and > IOExts.hPutBuf, and do the operations on raw characters in memory. > Using a UArray of Word8 would be better, but there aren't any > operations to do IO to/from a UArray yet (actually I've written > these, but they aren't in the tree yet). So why don't getContents / putStr / etc. deforest cleanly to calls to hGetBuf and hPutBuf? I'm genuinely curious; my own experience in this direction is "The engineering is challenging". These functions are so commonly used, though---and they're vastly easier to use, actually portable, etc. The effort would surely be repaid. Plus, I'm curious to hear about any challenges which may be involved in pulling this off. :-) If it's genuinely tricky, the tricks are likely to be generally useful for other stream-ish things. -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

1 0

RE: Working character by character in Haskell
by Simon Marlow 19 Oct '01

19 Oct '01

> Humn... I agree with both of you, Albert and Tom. I started > it from the > beginning, using map and don't using reverse anymore. But the > C program is > still 7x faster than the Haskell one. Here is the code of the Haskell > program: > > main :: IO () > main = do > bmFile <- openFileEx "in.txt" (BinaryMode ReadMode) > bmString <- hGetContents bmFile > writeFile "out.txt" (map inc bmString) > hClose bmFile > > inc :: Char -> Char > inc a = toEnum ((fromEnum a) + 1) Well, in Haskell each character of the string takes 20 bytes: 12 bytes for the list cell, and 8 bytes for the character itself - the memory used by the character will be recovered at GC time though, as long as the character is < chr 256. The map operation also allocates a further 28 bytes per character: list cell + thunk(8) + character, assuming the inc operation is suitably optimised not to do any extra allocation. That's a total of 48 bytes per character. The C code, by comparison, doesn't do any dynamic allocation at all. To really match the C program, you need to use IOExts.hGetBuf and IOExts.hPutBuf, and do the operations on raw characters in memory. Using a UArray of Word8 would be better, but there aren't any operations to do IO to/from a UArray yet (actually I've written these, but they aren't in the tree yet). You should find that the IO library in GHC 5.02 is slightly faster than the one in 5.00.2. Anyway, I hope all this helps to explain why the Haskell version is so slow. Cheers, Simon

2 1

Re: Working character by character in Haskell
by Albert Lai 19 Oct '01

19 Oct '01

"Andre W B Furtado" <awfurtado(a)uol.com.br> writes: [...] > For example, suppose function doSomeStuffWith returns its own parameter. > Using a 1.5MB file in this case, the Haskell program ends in almost 5 > seconds, while the C program ends in less than 0.5 seconds... Is my Haskell > program too bad implemented? (I'm using GHC 4.08-1 under a Windows 98 > platform.) I indeed think that your Haskell program is inefficient and is not a translation of your C program. It reverses a huge string, which takes not only execution time but also garbage collection time and memory, which entails even more time for OS overhead and swapping out other things in the physical memory. (Many programmers complain "my linear-time algorithm takes just 1 second on a 100M list, so why is it taking 5 seconds on a 200M list?" They forget that because of issues such as cache locality and virtual memory, their computers do not scale.) I am wondering that if doSomeStuffWith is pure-functional, why are you writing and using copyFile instead of just using map? I mean: main :: IO () main = do bmFile <- openFileEx "in.txt" (BinaryMode ReadMode) bmString <- hGetContents bmFile writeFile "out.txt" (map doSomestuffWith bmString) hClose bmFile Because both hGetContents and map are lazy and use O(1) memory, this program behaves exactly as your C program plus occasional garbage collections that don't hurt too much. In partcular, the OS will see no difference (although the cache does).

2 1

createAdjustor on Darwin
by Ashley Yakeley 19 Oct '01

19 Oct '01

The Darwin (Mac OS X) port of GHC 5.00.2 appears to be missing createAdjustor. As I understand it createAdjustor does some kind of architecture-specific thing with the stack, or something. Is anyone working on porting GHC 5.02 to Darwin? Will createAdjustor be included? I need it because I do dynamic exporting of callback functions through the FFI... -- Ashley Yakeley, Seattle WA

1 0

Working character by character in Haskell
by Andre W B Furtado 18 Oct '01

18 Oct '01

I'm trying to create a fast program in Haskell that reads the content of a file, do some stuff with its characters (one by one) an then save the final result (the modified characters) in another file. The fastest program I've developed so far is: main :: IO () main = do bmFile <- openFileEx "in.txt" (BinaryMode ReadMode) bmString <- hGetContents bmFile str <- copyFile bmString [] writeFile "out.txt" str hClose bmFile copyFile :: String -> String -> IO String copyFile [] s = return (reverse s) copyFile (a:as) s = copyFile as ( (doSomeStuffWith a):s) What I can't understand is why a similar program, written in C, is much faster than the Haskell program. Here you have the C program: void main() { FILE *in, *out; char ch; in = fopen("in.txt","rb"); out = fopen("out.txt","wb"); while ( (ch=getc(in)) != EOF) putc(doSomeStuffWith(ch),out); fclose(out); fclose(in); } For example, suppose function doSomeStuffWith returns its own parameter. Using a 1.5MB file in this case, the Haskell program ends in almost 5 seconds, while the C program ends in less than 0.5 seconds... Is my Haskell program too bad implemented? (I'm using GHC 4.08-1 under a Windows 98 platform.) Thanks, -- Andre

1 0

New GHC 5.02 InstallShield
by Reuben Thomas 18 Oct '01

18 Oct '01

I've finally managed to produce a new InstallShield that fixes all the known problems with the old one (note that doesn't include non-InstallShield-specific problems). In particular, the win32 library is now fully present, the util package comes with the profiling headers, and GHC installs itself once more under \ghc\ghc-5.02 to avoid problems when you're using it with tools that don't like spaces in paths (e.g. autoconf). The bug in ghci that prevented it working with long command lines (well, actually anything other than very short command lines) is also fixed. Also, for all you Windows hackers out there, it installs a couple of registry keys (in HKEY_LOCAL_MACHINE\Software\GHC) telling you what version is installed and where. -- http://sc3d.org/rrt/ | violence, n. bravery for cowards

1 0

ANNOUNCE: linkchk-0.01 released
by Jens-Ulrik Petersen 18 Oct '01

18 Oct '01

Two months after the first release, linkchk version 0.01 is released! New in this version: * displays ping time instead of ok status * IPv6 support * command option to set delay between pings * uses netstat instead of /proc/net/route * uses popenhs * uses automake and autoconf The source and rpm files are available from: http://www.01.246.ne.jp/~juhp/haskell/linkchk/ Feedback, comments and code contributions appreciated, Jens

1 0