October 2001 - Glasgow-haskell-users

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

Does GHS has FFI for Mac OS X?
by Shivkumar Chandrasekaran 17 Oct '01

17 Oct '01

Hi, Can someone tell me if GHC has a working FFI on Mac OS X? And also if someone has succeeded in installing GHC on Mac OS X? Thanks, --shiv--

1 0

RE: IO concurrency
by Simon Marlow 17 Oct '01

17 Oct '01

> I didn't try ghc-5.02 since I haven't installed it yet. Could you do that? The IO library in 5.00.2 had a bug in fdToHandle which meant that it didn't put the file descriptor into non-blocking mode, and I suspect this is the cause of your problem. Cheers, Simon

2 1

Re: qforeign-0.65: Bzip2: problems with [Word8]
by Ashley Yakeley 17 Oct '01

17 Oct '01

At 2001-10-16 11:12, Michael Marte wrote: >But I need String -> String! >(Reading from a file, decompressing, and feeding it to the XML parser.) >How can I do this? The "reading from a file" part is arguably a misdesign in the standard libraries. There ought to be Word8-based file IO functions for reading/writing the bytes of a file. I'm not sure, but I think the Char-based functions may even do newline conversion. >I found out that fromIntegral does the conversion from Word8 to Char >but I do not know how to convert from Char to Word8. I think fromIntegral will work for that too. -- Ashley Yakeley, Seattle WA

2 1

ANNOUNCE: popenhs-0.00 released
by Jens-Ulrik Petersen 17 Oct '01

17 Oct '01

I am happy to announce the first release of popenhs, version 0.00. popenhs is a very small Haskell library, based on runProcess in hslibs' posix library. It provides lazy output from subprocesses through two functions popen2 and popen3. The source and rpm files are available from: http://www.01.246.ne.jp/~juhp/haskell/popenhs/ I welcome comments and feedback. Jens

1 0