<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi, Simon.<br><br>I ported the array benchmark to a slower machine, in order to detect smaller variations in speed. Clean compiler does not show huge differences in speed when one switches from boxed to unboxed arrays, or from lazy to strict arrays. As you can see below, adding unboxed annotation, or strictness annotation does not change performance noticeably. This is a feature that I like in Clean, and I would like to see in Haskell. Correct programs are almost equally fast. Therefore, the programmer does not need to worry about boxed, unboxed, strict or lazy applications. What I miss in Clean is an interpreter, like GHCi. I am writing a somewhat large genetic programming system to diagnostic electric installations, and electronic circuits. I mean, I am working for people who are writing the programs and designing the circuits. The programs are
working in Lisp and Scheme (SBCL and Gambit). The Clean version is almost functional. I am struggling with the Haskell version. I will write a private letter to you explaining how the Clean program works. I wonder whether you could give me some hints on how to port it to Haskell. Since Haskell has an interpreter, I think that it could be used to test the generated applications, and calculate the fitness function.<br><br>/* BOXED LAZY<br>D:\Clean 2.2\geneticprog\bench>boxedlazy<br>280000000<br>Execution: 0.04 Garbage collection: 0.17 Total: 0.21<br><br>D:\Clean 2.2\geneticprog\bench>boxedlazy<br>280000000<br>Execution: 0.06 Garbage collection: 0.17 Total: 0.23<br><br>D:\Clean 2.2\geneticprog\bench>boxedlazy<br>280000000<br>Execution: 0.04 Garbage collection: 0.17 Total: 0.21<br>*/<br>module boxedlazy<br>import StdEnv<br><br>fn i a acc | i<1 = acc<br>fn i a=:{[i]=b} acc<br> # a= {a&[i]=
b+3.0}<br> # (c, a)= a![i]<br> = fn (i-1) a (c+acc)<br><br>Start= fn 2000000 vt 0.0<br> where<br> vt:: .{Real}<br> vt = createArray 2000001 137.0 <br> <br><br>module arrays<br>import StdEnv<br><br>fn i a acc | i<1 = acc<br>fn i a=:{[i]=b} acc<br> # a= {a&[i]= b+3.0}<br> # (c, a)= a![i]<br> = fn (i-1) a (c+acc)<br><br>Start= fn 2000000 vt 0.0<br> where<br> vt:: .{#Real}<br> vt = createArray 2000001 137.0<br><br>/* unboxedlazy<br>D:\Clean 2.2\geneticprog\bench>unboxedlazy.exe<br>280000000<br>Execution: 0.03 Garbage collection: 0.00 Total: 0.03<br><br>D:\Clean 2.2\geneticprog\bench>unboxedlazy.exe<br>280000000<br>Execution: 0.04 Garbage collection: 0.00 Total: 0.04<br><br>D:\Clean 2.2\geneticprog\bench>unboxedlazy.exe<br>280000000<br>Execution: 0.03
Garbage collection: 0.00 Total: 0.03<br>*/<br>module unboxedlazy<br>import StdEnv<br><br>fn i a acc | i<1 = acc<br>fn i a=:{[i]=b} acc<br> # a= {a&[i]= b+3.0}<br> # (c, a)= a![i]<br> = fn (i-1) a (c+acc)<br><br>Start= fn 2000000 vt 0.0<br> where<br> vt:: .{#Real}<br> vt = createArray 2000001 137.0<br><br>/* unboxedstrict<br>D:\Clean 2.2\geneticprog\bench>unboxedstrict.exe<br>280000000<br>Execution: 0.03 Garbage collection: 0.00 Total: 0.03<br><br>D:\Clean 2.2\geneticprog\bench>unboxedstrict.exe<br>280000000<br>Execution: 0.04 Garbage collection: 0.00 Total: 0.04<br><br>D:\Clean 2.2\geneticprog\bench>unboxedstrict.exe<br>280000000<br>Execution: 0.04 Garbage collection: 0.00 Total: 0.04<br><br>*/<br>module unboxedstrict<br>import StdEnv<br><br>fn i a acc | i<1 = acc<br>fn i a=:{[i]=b} acc<br> # a=
{a&[i]= b+3.0}<br> # (c, a)= a![i]<br> = fn (i-1) a (c+acc)<br><br>Start= fn 2000000 vt 0.0<br> where<br> vt:: !.{#!Real}<br> vt = createArray 2000001 137.0<br><br><br><br>--- On <b>Thu, 10/15/09, Simon Peyton-Jones <i><simonpj@microsoft.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Simon Peyton-Jones <simonpj@microsoft.com><br>Subject: RE: [Fwd: Re: [clean-list] Clean versus Haskell]<br>To: "Adrian Hey" <ahey@iee.org>, "clean-list@science.ru.nl" <clean-list@science.ru.nl><br>Received: Thursday, October 15, 2009, 1:22 AM<br><br><div class="plainMail">I submitted Philippos as a performance bug to GHC's trac, here:<br> <a href="http://hackage.haskell.org/trac/ghc/ticket/3586" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/3586</a><br><br>If you follow
the link you'll see lots of commentary, including a version that generates code twice as fast as Clean's, and is purely functional.<br><br>That said, I think it's v bad that a straightforward program runs so slowly, and it's certainly true that this is an area we could pay more attention to. (Trouble is, there are so many such areas!)<br><br>Meanwhile, I'm curious: are the arrays in Philippos's program strict? Or lazy? If strict, that's a pretty big difference. (The "STU" arrays mentioned in the above link are strict and unboxed; that's what the "U" means.)<br><br>Simon<br><br>| -----Original Message-----<br>| From: <a ymailto="mailto:clean-list-bounces@science.ru.nl" href="/mc/compose?to=clean-list-bounces@science.ru.nl">clean-list-bounces@science.ru.nl</a> [mailto:<a ymailto="mailto:clean-list-bounces@science.ru.nl" href="/mc/compose?to=clean-list-bounces@science.ru.nl">clean-list-bounces@science.ru.nl</a>] On<br>| Behalf Of
Adrian Hey<br>| Sent: 15 October 2009 07:33<br>| To: <a ymailto="mailto:clean-list@science.ru.nl" href="/mc/compose?to=clean-list@science.ru.nl">clean-list@science.ru.nl</a><br>| Subject: [Fwd: Re: [clean-list] Clean versus Haskell]<br>| <br>| <br>| -------- Original Message --------<br>| Subject: Re: [clean-list] Clean versus Haskell<br>| Date: Thu, 15 Oct 2009 06:41:20 +0100<br>| From: Adrian Hey <<a ymailto="mailto:ahey@iee.org" href="/mc/compose?to=ahey@iee.org">ahey@iee.org</a>><br>| To: Philippos Apolinarius <<a ymailto="mailto:phi500ac@yahoo.ca" href="/mc/compose?to=phi500ac@yahoo.ca">phi500ac@yahoo.ca</a>><br>| References: <<a ymailto="mailto:8400.82204.qm@web58803.mail.re1.yahoo.com" href="/mc/compose?to=8400.82204.qm@web58803.mail.re1.yahoo.com">8400.82204.qm@web58803.mail.re1.yahoo.com</a>><br>| <br>| Hello Philippos,<br>| <br>| GHC has a long standing performance bug for garbage collection and<br>| mutable arrays:<br>|
<br>| <a href="http://hackage.haskell.org/trac/ghc/ticket/650" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/650</a><br>| <br>| For some reason they haven't (can't?) fixed it. I guess the<br>| authors of Haskell/ghc shootout entries are aware of this so don't<br>| use native mutable arrays in their entries (at least not those that<br>| show haskell/ghc to be "fast" :-)<br>| <br>| Regards<br>| --<br>| Adrian Hey<br>| <br>| Philippos Apolinarius wrote:<br>| > I wrote a very simple program to check whether Haskell improved its array<br>| processing libraries or not. Here is how to compile and run the program arr.hs in<br>| Haskell (I have used the GHC compiler):<br>| ><br>| >> ghc -O arr.hs -o arr.exe<br>| ><br>| > $ time arr.exe +RTS -K32000000<br>| > 2.8e8<br>| ><br>| > real 0m3.938s<br>| > user 0m0.031s<br>| > sys 0m0.000s<br>| ><br>| > The same program
in Clean:<br>| > C:\Clean 2.2\exemplos\console>arraytest.exe<br>| > 280000000<br>| > Execution: 0.01 Garbage collection: 0.01 Total: 0.03<br>| ><br>| > C:\Clean 2.2\exemplos\console>arraytest.exe<br>| > 280000000<br>| > Execution: 0.01 Garbage collection: 0.01 Total: 0.03<br>| ><br>| > This means that Clean is 390 times faster than Haskell in this particular problem.<br>| These results makes me worder whether Haskell is safer than Clean. It turns out that<br>| Haskell checks index out of range at runtime, exactly like Clean. Larger problems<br>| make the difference between Clean and Haskell even worse. For instance, neural<br>| networks like the one described in Schmidtt et al. run 400 times faster in Clean.<br>| ><br>| > Haskell seems to be slow, and not safe. For instance, GHC compiler does not at a<br>| program trying to write into a closed handle.<br>| ><br>| > module Main
where<br>| > import System( getArgs )<br>| > import IO<br>| ><br>| > main = do<br>| > args <- getArgs<br>| > if (length args /= 2)<br>| > then putStr "Usage: f1a f2a <n>"<br>| > else (do<br>| > fromHandle <- openFile (head args) ReadMode<br>| > contents <- hGetContents fromHandle<br>| > toHandle <- openFile (head (tail args)) WriteMode<br>| > hClose toHandle -- Comment this line<br>| >
hPutStr toHandle contents<br>| > hClose toHandle<br>| > putStr "Done.")<br>| ><br>| > The Clean equivalent program is somewhat smaller. In my opinion it is easier to<br>| understand. What is more important, Clean compiler balks at closed handles.<br>| ><br>| > module cleancopy<br>| > import StdEnv, ArgEnv<br>| ><br>| > Start w<br>| > # argv= getCommandLine<br>| > | size argv < 3 = abort "Usage, etc."<br>| > # (ok, f, w)= fopen argv.[1] FReadText w<br>| > (contents, f)= freads f 64000<br>| > (ok, f, w)= fopen argv.[2] FWriteText w<br>| > f= fwrites contents f<br>| > = fclose f w<br>| ><br>| > Below you will
find the array examples. You can check that Clean is really much<br>| faster than Haskell. I wonder why the Benchmarks Game site does not report such a<br>| large difference between Haskell and Clean performances. I believe that people who<br>| wrote Haskell benchmarks for the Benchmarks Game site cheated in using foreign<br>| pointers to access arrays.<br>| ><br>| > -- arr.hs<br>| > import Control.Monad.ST<br>| > import Data.Array.ST<br>| > main = print $ runST<br>| > (do arr <- newArray (1,2000000)<br>| > 137.0 :: ST s<br>| > (STArray s<br>| >
Int Double)<br>| > a <- readArray arr 1<br>| > b <- readArray arr 1<br>| > fn 2000000 arr 0.0 )<br>| ><br>| ><br>| > fn i a acc | i < 1 = do (return acc)<br>| > fn i a acc= do<br>| > b <- readArray a i<br>| > writeArray a i (b+3.0)<br>| > c <- readArray a i<br>| > fn (i-1) a (acc+c)<br>| ><br>| > //Clean version<br>| > module arraytest<br>| > import StdEnv<br>| > fn i a acc | i<1 = acc<br>| > fn i a=:{[i]=b} acc<br>| > # a= {a&[i]= b+3.0}<br>| > # (c, a)=
a![i]<br>| > = fn (i-1) a (c+acc)<br>| ><br>| > Start= fn 2000000 vt 0.0<br>| > where<br>| > vt:: .{#Real}<br>| > vt = createArray 2000001 137.0<br><br>_______________________________________________<br>clean-list mailing list<br><a ymailto="mailto:clean-list@science.ru.nl" href="/mc/compose?to=clean-list@science.ru.nl">clean-list@science.ru.nl</a><br><a href="http://mailman.science.ru.nl/mailman/listinfo/clean-list" target="_blank">http://mailman.science.ru.nl/mailman/listinfo/clean-list</a><br></div></blockquote></td></tr></table><br>
<hr size=1>Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the <a href="http://ca.promos.yahoo.com/newmail/overview2/"><b>All-new Yahoo! Mail </b></a>