January 2001 - Glasgow-haskell-users

RE: Floating point performance
by Julian Seward (Intl Vendor) 29 Jan '01

29 Jan '01

I tried this, with ghc-4.08.1 -O both with and without profiling, on a Sparc box of I believe around 300 MHz, and I can't reproduce it at all. Without profiling, it allocates about 505 k of heap and runs in 0.02 seconds. Ummm ? J | -----Original Message----- | From: Jan Kort [mailto:kort@wins.uva.nl] | Sent: Friday, January 26, 2001 4:40 PM | To: glasgow-haskell-users(a)haskell.org | Subject: Floating point performance | | | Hi, | I noticed ghc (version 4.08.1) floating point performance is | really slow on my computer: a 270Mhz sun ultra5. The program | below does 1 milion floating point multiplications and takes | 2 seconds to run. I made a profile and it says most of the | time (93%) is spent in the function bar. Any idea what is | going on ? | | Regards, | Jan | | module Main where | | foo :: Double -> [Double] | foo 0 = [1] | foo n = bar n:foo (n-1) | | bar :: Double -> Double | bar n = n*1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | *1*1*1*1*1*1*1*1*1*1 | | foldl' :: (a -> b -> a) -> a -> [b] -> a | foldl' _ a [] = a | foldl' f a (x:xs) = (foldl' f $! f a x) xs | | main :: IO() | main = putStrLn (show (foldl' (+) 0 (foo 10000))) | | --------------------------- | Profile: | | total time = 2.60 secs (130 ticks @ 20 ms) | total alloc = 24,845,828 bytes (excludes profiling | overheads) | | COST CENTRE MODULE %time %alloc | | bar Main 93.1 96.1 | foo Main 3.1 2.4 | foldl' Main 3.1 1.4 | | | individual inherited | COST CENTRE MODULE entries %time %alloc | %time %alloc | | MAIN MAIN 0 0.0 0.0 | 100.0 100.0 | main Main 0 0.0 0.0 | 0.0 0.0 | CAF PrelShow 1 0.0 0.0 | 0.0 0.0 | CAF PrelFloat 3 0.0 0.0 | 0.0 0.0 | CAF PrelHandle 3 0.0 0.0 | 0.0 0.0 | CAF Main 9 0.0 0.0 | 100.0 100.0 | main Main 1 0.8 0.0 | 100.0 100.0 | foo Main 10001 3.1 2.4 | 96.2 98.5 | bar Main 10000 93.1 96.1 | 93.1 96.1 | foldl' Main 10002 3.1 1.4 | 3.1 1.4 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

3 2

Using GHC with Green Card under Win32
by Jeremy Shute 29 Jan '01

29 Jan '01

Sigbjorn: Yes, this works perfectly now. Thanks! I've taken the liberty of mailing this to the GHC mailing list so hopefully it can percolate to the archives and be of use to others (I know I usually check there first). I hope this won't be considered misuse of the list... Thanks again! Jeremy Shute > -----Original Message----- > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com] > Sent: Monday, January 29, 2001 1:21 PM > To: Jeremy Shute > Subject: Re: Troubles running ScriptReg > > > Yes, you don't want to link against the Hugs DLL when > you're working with ghc compiled code. Try adding > -package greencard to the final link line. > > --sigbjorn > > ----- Original Message ----- > From: "Jeremy Shute" <shutej(a)rpi.edu> > To: "Sigbjorn Finne" <sigbjorn_finne(a)hotmail.com> > Sent: Monday, January 29, 2001 18:53 > Subject: RE: Troubles running ScriptReg > > > > Yes, now things work wonderfully. I've written a little shell script to > > automate the process, the .o builds fine! Now I'm trying to make use of > the > > library: > > > > > > > > $ ghc -static Main.hs Gimme.o -fglasgow-exts -fvia-C \ > > > > > '-iF:\\usr\\share\\ghc\\lib\\imports\\greencard;F:\\usr\\share\\gh > c\\lib\\im > > ports\\greencard' > > Compilation IS NOT required > > Output file not specified, defaulting to "main.exe" > > Gimme.o(.text+0x38):ghc1140.c: undefined reference to `__init_StdDIS' > > Gimme.o(.text+0x144):ghc1140.c: undefined reference to > > `StdDIS_unmarshallzustringzu_closure' > > Gimme.o(.text+0x250):ghc1140.c: undefined reference to > > `StdDIS_unmarshallzustringzu_closure' > > collect2: ld returned 1 exit status > > > > > > > > I've crawled the drive and found that the only C code-ish file > for StdDIS > > are StdDIS.dll, and that's in greencard\lib\hugs... I don't > think linking > > against that would be appropriate. When I omit that trailing > '-iF:\\...', > > the same errors are output. Sooo close! > > > > Perhaps I should post all this to the mailing list, just so people can > find > > it while crawling the archives? I would think these are fairly useful > > nuggets of info. :-) > > > > Jeremy > > > > > > > > > -----Original Message----- > > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com] > > > Sent: Friday, January 26, 2001 12:30 PM > > > To: Jeremy Shute > > > Subject: Re: Troubles running ScriptReg > > > > > > > > > > > > Good to hear that you're up and running, at least on the HaskellScript > > > side. You're close on the GC side too - to properly process the input > > > you need to use the -i option to inform GC where it can slurp in > > > StdDIS.gc from (Although the docs says so, the binary doesn't > > > automatically > > > figure this out..) So, if you invoke it as follows > > > > > > green-card -tghc Gimme.gc -iF:\\usr\\share\\greencard\\lib\\ghc > > > > > > the warning should go away. To compile Gimme.hs with ghc-4.08, > > > use the following command-line: > > > > > > ghc -static -c Gimme.hs -fglasgow-exts -fvia-C \ > > > > > > '-iF:\\usr\\share\\greencard\\lib\\ghc;F:\\usr\\share\\greencard\\ > > > lib\\ghc' > > > > > > i.e., you need to kludge around a bit to get DOS-style paths to work > > > OK & redundantly give it twice, using ';' as separator. > > > > > > To generate Hugs-compatible output on a Win32 box, Section 12.2 of > > > the manual contains accurate info. > > > > > > hth, > > > --sigbjorn > > > > > > ----- Original Message ----- > > > From: "Jeremy Shute" <shutej(a)rpi.edu> > > > To: "Sigbjorn Finne" <sigbjorn_finne(a)hotmail.com> > > > Sent: Friday, January 26, 2001 02:56 > > > Subject: RE: Troubles running ScriptReg > > > > > > > > > > Howdy, Sigbjorn. > > > > > > > > Confirming again that Hugs now works great with > HaskellScript (or what > > > I've > > > > tested of it, at least, ;-) )... > > > > > > > > Now here I am, staring at Green Card, realizing that you're > one of the > > > > authors. You sure do get around in the Haskell world! > > > > > > > > I'm running GHC-4.08.1 and Green Card 2 (presumably 2.01, I > installed > it > > > > right before Christmas break). I've looked at the example > > > online of GDBM, > > > > and am trying this code: > > > > > > > > ---------------------------------------- > > > > %#include "hello.h" > > > > {- > > > > Testing... This is Gimme.gc! > > > > -} > > > > > > > > module Gimme( gimme ) > > > > > > > > where > > > > > > > > import StdDIS > > > > import Foreign( ForeignObj, > > > > makeForeignObj ) > > > > > > > > %fun gimme :: IO String > > > > %code > > > > %result (string {hello()}) > > > > > > > > ---------------------------------------- > > > > /* > > > > Testing... This is hello.h! > > > > */ > > > > > > > > char* hello( ) { > > > > return "Howdy!\n"; > > > > } > > > > > > > > ---------------------------------------- > > > > > > > > I run: > > > > > > > > green-card.exe -tghc Gimme.gc > > > > > > > > It says: > > > > > > > > Warning: unable to find StdDIS in: > > > > > > > > Notice how it says nothing after the "in"... I've scoured > the manual > > > > looking for ways to set the library path of green card, and > either I'm > > > > missing something or it's not there... Reguardless, I suppose > > > I'm not too > > > > TERRIBLY concerned at this stage, as I still have a > Gimme.hs that it's > > > > produced. The contents of which are (the comment is no longer > correct, > > > but > > > > I left it reguardless): > > > > > > > > ---------------------------------------- > > > > {-# OPTIONS -#include "hello.h" #-} > > > > {- > > > > Testing... This is Gimme.gc! > > > > -} > > > > > > > > module Gimme( gimme ) > > > > > > > > where > > > > > > > > import StdDIS > > > > import Foreign( ForeignObj, > > > > makeForeignObj ) > > > > > > > > gimme :: IO String > > > > gimme = > > > > _casm_ ``do {do {} while(0);} while(0);'' > > > > (unmarshall_string hello()) >>= \ gc_res1 -> > > > > > > > > ---------------------------------------- > > > > > > > > That last line may wrap in your email... gimme= should be > followed by > 2 > > > > lines. The file's contents look OK, so I look up where StdDIS.hs is > > > located > > > > under my Green Card directory, stuff that onto GHC's command > > > line, and try > > > > to whip out an executable of some sort (using the static flag > > > because it's > > > > necessary under this version of GHC for Win32). Okay, so here comes > the > > > > part where I blame it on GHC instead of Green Card: > > > > > > > > I run: > > > > > > > > ghc -static -iF:\\usr\\share\\greencard\\lib\\ghc\\ Gimme.hs > > > > > > > > It says: > > > > > > > > Gimme.hs:15: parse error on input ``' > > > > > > > > I have reinstalled Green Card several times, moved things > around, been > > > > pretty thorough... Tried various other code, and it always > > > lands me with > > > > this message. I can only presume that I'm being foolish, yet again, > and > > > > that perhaps this newer version of GHC is mutually exclusive with > Green > > > > Card? Please advise. > > > > > > > > :-) So far, my experience with the language has been nothing but > > > positive. > > > > I tried out Erlang, too, and Haskell just feels cleaner. > > > However, getting > > > > the implementations set up is quite daunting... > > > > > > > > > > > > > > > > Jeremy Shute > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com] > > > > > Sent: Wednesday, January 17, 2001 7:00 AM > > > > > To: Jeremy Shute > > > > > Cc: daan(a)cs.uu.nl; erik(a)cs.uu.nl > > > > > Subject: Re: Troubles running ScriptReg > > > > > > > > > > > > > > > Hi Jeremy, > > > > > > > > > > I don't know if anyone else has been trying to help you out, > > > > > but the HaskellScript binary you're using is not quite > > > > > up-to-date with the available Hugs98 binaries and libraries, > > > > > i.e., Addr.addrToInt is a recent addition to the Addr lib. > > > > > > > > > > My initial suggestion would be to simply comment-out > > > > > the 'primitive' declaration for addrToInt and try again -- > > > > > addrToInt isn't used all that much, anyway. > > > > > > > > > > --sigbjorn > > > > > > > > > > ----- Original Message ----- > > > > > From: "Jeremy Shute" <shutej(a)rpi.edu> > > > > > To: <daan(a)cs.uu.nl>; <erik(a)cs.uu.nl> > > > > > Cc: <sof(a)dcs.gla.ac.uk> > > > > > Sent: Sunday, January 14, 2001 19:17 > > > > > Subject: Troubles running ScriptReg > > > > > > > > > > > > > > > > I'm having some difficulty with HaskellScript under Windows 2000 > > > > > > Professional. My progress so far: > > > > > > > > > > > > * Downloaded and installed Hugs 98: November 1999 > version. Chose > > > > > "typical" > > > > > > install. Hugs resides in "C:\Hugs98". > > > > > > > > > > > > * Downloaded and installed HaskellScript (build 11). > HaskellScript > > > > > resides > > > > > > in "C:\HScript98". > > > > > > > > > > > > * Started reading through the documentation and figured I'd try > > > > > ScriptReg > > > > > > (in the demos directory) on the included Calculator > > > example, as noted > > > at > > > > > the > > > > > > bottom of > > > http://haskell.cs.yale.edu/haskellscript/osexamples.html. A > > > > > popup > > > > > > window informed me that Prelude.hs was not found. I > > > investigated the > > > > > > contents of my registry and determined that > HaskellScript doesn't > > > assume > > > > > or > > > > > > ask for any information about Hugs' install directory, so I came > up > > > with > > > > > the > > > > > > quick fix I've attached. Maybe you can make it useful to > others... > > > > > > > > > > > > * ScriptReg now fails with a MsgBox. The title of the box is > > > > > "HugsScript" > > > > > > and the error message follows: > > > > > > > > > > > > error: ERROR "C:\Hugs98\lib\exts\Addr.hs" (line 23): > > > Unknown primitive > > > > > > reference "addrToInt" > > > > > > > > > > > > When the "OK" button is pressed, another message box pops > > > up, this one > > > > > > titled "ScriptReg", which states: > > > > > > > > > > > > Run-time error '440': > > > > > > > > > > > > Automation error > > > > > > > > > > > > * Checked out the contents of Addr.hs... Everything looks in > > > > > order. Line > > > > > > 14 in this file reads: > > > > > > > > > > > > -- data Addr -- in Prelude > > > > > > > > > > > > So I looked in Prelude.hs. Line 1605 of Prelude.hs reads: > > > > > > > > > > > > data Addr -- builtin datatype of C pointers > > > > > > > > > > > > Prelude.hs also contains the appropriate Standard Integral > > > types. I'm > > > > > left > > > > > > wondering if Prelude.hs isn't processed before Addr.hs??? > > > This is the > > > > > only > > > > > > suspicion I have, maybe I've missed something? > > > > > > > > > > > > I would appreciate any insight you could give me: Two weeks > > > > > from now I'm > > > > > > starting on a web spider that's going to have to have bayesian > > > > > classifiers > > > > > > and neural networking components. I want to encapsulate these > parts > > > in > > > > > > Haskell, but that would be a much easier case to make to my > > > boss if my > > > > > > coworkers could access my code from COM! > > > > > > > > > > > > Thanks so much! > > > > > > > > > > > > Jeremy > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

RE: Floating point performance
by Simon Marlow 29 Jan '01

29 Jan '01

> Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort <kort(a)wins.uva.nl> pisze: > > > I made a profile and it says most of the time (93%) is spent in > > the function bar. > > Did you compile with optimization turned on (option -O)? > I see similar results without -O but quite different with -O. Without optimisation, you get the native code generator which produces particularly brain-dead code for floating point on x86 (mainly due to Intel's brain-dead design of the x86 floating point unit). With optimisation, you get gcc. Cheers, Simon

1 0

RE: 4.08.2
by Simon Peyton-Jones 29 Jan '01

29 Jan '01

George I'm sorry we've been silent. MS has some kind of huge email backlog. But the real reason is that POPL and a workshop have intervened so we've been out of action for a fortnight. The plan is to release 4.08.2 in a matter of days, not weeks. If you build the head of the ghc-4-07-branch you'll get the current 4.08.2, and we expect only tiny changes before the release (e.g. making sure it all works on Sparc). 4.08 remains our "stable branch". Simon | -----Original Message----- | From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de] | Sent: 23 January 2001 22:23 | To: George Russell | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: 4.08.2 | | | George Russell wrote: | > Since the absence of any reply presumably means "not for a | while yet", | | I'm not so sure about this, there has been quite some | bug-fixing and it's | not clear to me what's missing for a release. Simon^2? | | > could someone let me have a compiled hsc for the ghc-4.08 head | > on something reasonably close to SunOS/sparc Ultra-1? | | The current branch-o-mania is a little confusing, but the CVS branch | called "ghc-4-07-branch" (yes, "7", not "8") should contain what you | are looking for. At least I think so... :-} Any | bootstrapping problems? | | Cheers, | Sven | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

Floating point performance
by Jan Kort 26 Jan '01

26 Jan '01

Hi, I noticed ghc (version 4.08.1) floating point performance is really slow on my computer: a 270Mhz sun ultra5. The program below does 1 milion floating point multiplications and takes 2 seconds to run. I made a profile and it says most of the time (93%) is spent in the function bar. Any idea what is going on ? Regards, Jan module Main where foo :: Double -> [Double] foo 0 = [1] foo n = bar n:foo (n-1) bar :: Double -> Double bar n = n*1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 *1*1*1*1*1*1*1*1*1*1 foldl' :: (a -> b -> a) -> a -> [b] -> a foldl' _ a [] = a foldl' f a (x:xs) = (foldl' f $! f a x) xs main :: IO() main = putStrLn (show (foldl' (+) 0 (foo 10000))) --------------------------- Profile: total time = 2.60 secs (130 ticks @ 20 ms) total alloc = 24,845,828 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc bar Main 93.1 96.1 foo Main 3.1 2.4 foldl' Main 3.1 1.4 individual inherited COST CENTRE MODULE entries %time %alloc %time %alloc MAIN MAIN 0 0.0 0.0 100.0 100.0 main Main 0 0.0 0.0 0.0 0.0 CAF PrelShow 1 0.0 0.0 0.0 0.0 CAF PrelFloat 3 0.0 0.0 0.0 0.0 CAF PrelHandle 3 0.0 0.0 0.0 0.0 CAF Main 9 0.0 0.0 100.0 100.0 main Main 1 0.8 0.0 100.0 100.0 foo Main 10001 3.1 2.4 96.2 98.5 bar Main 10000 93.1 96.1 93.1 96.1 foldl' Main 10002 3.1 1.4 3.1 1.4

2 1

RE: limited suspending on readChan possible?
by Simon Marlow 26 Jan '01

26 Jan '01

> Hello everyone, I thought I?d return to more earthly issue > than discovering > bugs in signal handlers etc. :) > > I?ve been looking for a way to suspend on an empty channel for only a > limited time. So I came up with a solution which involves > dupChan (which > is currently broken as stated in Meurig?s bug-report) and unGetChan: How about timeout N . readChan where timeout is defined according to our Asynchronous Exceptions paper (see http://www.haskell.org/~simonmar/papers/async.ps.gz) Cheers, Simon

1 0

RE: _scc_
by Simon Marlow 26 Jan '01

26 Jan '01

> Why > _scc_ "foo" > and not > {-# SCC "foo" #-} > ? > > IMHO a pragma would be better: does not make the scc-annotated program > non-standard. > > (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary > places.) Good suggestion. I'm not sure why it was done the current way; perhaps it was before the advent of pragmas. Anyway, on my ToDo list it goes... Cheers, Simon

1 0

_scc_
by qrczak＠knm.org.pl 25 Jan '01

25 Jan '01

Why _scc_ "foo" and not {-# SCC "foo" #-} ? IMHO a pragma would be better: does not make the scc-annotated program non-standard. (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary places.) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: using the GHC parser and renamer
by Simon Peyton-Jones 25 Jan '01

25 Jan '01

Kate I'm sorry not to have replied to your earlier message; I've been away at POPL etc. Incidentally, for implementation-related things, better to use glasgow-haskell-bugs (albeit it's not actually a bug) rather than glasgow-haskell-users. GHC 4.08 (which is the place from which you got your code, I think) uses a "driver" written in perl to coordinate its operations. The driver runs cpp, then GHC itself (a binary called 'hsc'), then gcc, then as, then ld. Run ghc-4.08 with "-v" to see what it does. My bet is that you are running your bits-of-ghc-plus-bits-of-your-own binary directly. So it's not getting all the command-line flags it expects. (nor are they documented, because it's an internal interface). | Main.hs:1: | Could not find interface file for 'Prelude' | in the directories ./*.hi It's not looking in the right directories because it hasn't been told to do so by the command-line flags. If you run ghc-4.08 -v you'll see how the driver communicates which directctories to look in. | Main.hs:3: | Bad interface file:: ./ParseAndRenameFile.hi | ./ParseAndRenameFile.hi:1 Interface file | version error; Expected 0 | found version 408 The version number it expects to find is again communicated by a command line flag. For your purposes you may not care, so one option is to just remove the test. Or ghc-4.08 -v will show you what the driver is saying to hsc. Incidentally, Tim Sheard at OGI is building a modular front end for Haskell, in the spirit of Mark Jones's Typing Haskell in Haskell paper. It might be worth asking him whether it's in a borrow-able state, becuase it's probably less of a monster than GHC. Simon

1 0

limited suspending on readChan possible?
by Volker Stolz 25 Jan '01

25 Jan '01

Hello everyone, I thought I´d return to more earthly issue than discovering bugs in signal handlers etc. :) I´ve been looking for a way to suspend on an empty channel for only a limited time. So I came up with a solution which involves dupChan (which is currently broken as stated in Meurig´s bug-report) and unGetChan: > timedReadChan ch t = do > dup <- dupChan ch > mv <- newEmptyMVar > forkIO (do > msg <- readChan dup > putMVar mv True > ) > forkIO (do > threadDelay t > putMVar mv False > ) > res <- takeMVar mv > if res > then do > -- we discard dup and re-read from ch: > msg <- readChan ch > return (Just msg) > else (return Nothing) However, shouldn´t the dupChan be a space-leak par excellence? We end up having no readers and keep adding new meesages to dup... -- \usepackage[latin1]{inputenc}! Volker Stolz * stolz(a)i2.informatik.rwth-aachen.de * PGP + S/MIME

1 0