Re: [Haskell-cafe] viewing HS files in Firefox
The Open in Browser Firefox extension -- quite possibly the handiest thing since hoogle as a custom search engine plugin (if not handier!) http://www.spasche.net/mozilla/ --S On Oct 27, 2007, at 8:16 PM, Thomas Schilling wrote: On Sat, 2007-10-27 at 18:48 -0400, Isaac Dupree wrote: When I try to go to one of the Module.hs files, e.g. on darcs.haskell.org, it now has type HS and Firefox refuses to display it (and only lets me download it). Does anyone know how to make Firefox treat certain file types as others (HS as plain text, in particular)? so that I can browse them with any convenience I believe those kinds of problem have to do with the MIME-encoding on the server side: The server uses text/x-haskell. For Firefox to display the document inline it probably has to be text/plain. Not sure what the proper fix is, though. / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: viewing HS files in Firefox
Thomas Schilling wrote: Isaac Dupree wrote: When I try to go to one of the Module.hs files, e.g. on darcs.haskell.org, it now has type HS and Firefox refuses to display it (and only lets me download it). Does anyone know how to make Firefox treat certain file types as others (HS as plain text, in particular)? so that I can browse them with any convenience I believe those kinds of problem have to do with the MIME-encoding on the server side: The server uses text/x-haskell. For Firefox to display the document inline it probably has to be text/plain. Not sure what the proper fix is, though. I think so, too. Isn't there a way to reassign MIME types to browser/plugins via some hidden preferences in Firefox/Camino? On MacOS 9, the old Netscape 4.5 allowed me to do that. I believe that Internet Explorer could do that as well via a standard system-wide preference. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] newbie optimization question
For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. I've tried using foldl', and doing explicit tail recursion with strict accumulators, but I can't get the running time below 3 seconds. Is it possible to come within striking distance of the other languages? Thanks. --PR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
On 10/28/07, Prabhakar Ragde [EMAIL PROTECTED] wrote: For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. You could try giving divisors type signature: divisors :: Int - [Int] I've tried using foldl', and doing explicit tail recursion with strict accumulators, but I can't get the running time below 3 seconds. Is it possible to come within striking distance of the other languages? Thanks. --PR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with PDF/PS backend in GTK2HS
I have a strange problem, which is so elementary that I think I must be missing something... In GTK2HS, when I draw text using using textPath, the text is located at different locations depending on which backend is used. I'm not talking about a difference of a couple of pixels , but in my case it's half a page off. The PNG and Win32 backend work fine, but the PDF/PS backends get it wrong. For example, I modified the Text.hs demo in the demos/Cairo subdirectory so it also outputs PDF. Here the text is also at different locations, so I guess it's not just my code. Code is pasted below. I'm using Windows, and GTK2HS version 0.9.12 from http://www.haskell.org/gtk2hs Maybe someone could give this a quick test on Linux? I guess this is most likely a Cairo problem, and has nothing to do with the Haskell wrapper? Still this is hard to believe, since these kinds of bugs would be quickly found. Thanks, Peter import Graphics.Rendering.Cairo import qualified Graphics.Rendering.Cairo.Matrix as M boxText :: String - Double - Double - Render () boxText text x y = do save lineWidth - getLineWidth (TextExtents xb yb w h _ _) - textExtents text rectangle (x + xb - lineWidth) (y + yb - lineWidth) (w + 2 * lineWidth) (h + 2 * lineWidth) stroke moveTo x y textPath text fillPreserve setSourceRGBA 0 0 1 0.5 setLineWidth 3.0 stroke restore transpSurface :: Double - Double - Render () transpSurface w h = do save rectangle 0 0 w h setSourceRGBA 0 0 0 0 setOperator OperatorSource fill restore width = 400 height = 300 main :: IO () main = withImageSurface FormatARGB32 width height $ \surface - do let render = do setSourceRGB 0.0 0.0 0.0 setLineWidth 2.0 transpSurface (fromIntegral width) (fromIntegral height) selectFontFace sans FontSlantNormal FontWeightNormal setFontSize 40 extents - fontExtents let fontHeight = fontExtentsHeight extents boxText Howdy, world! 10 fontHeight translate 0 fontHeight save translate 10 fontHeight rotate (10.0 * pi / 180.0) boxText Yay for Haskell! 0 0 restore translate 0 (3 * fontHeight) save setFontMatrix $ M.rotate ((-10.0) * pi / 180.0) $ M.scale 40.0 40.0 M.identity boxText ...and Cairo! 10 fontHeight restore renderWith surface render surfaceWriteToPNG surface Text.png withPDFSurface Text.pdf (realToFrac width) (realToFrac height) (flip renderWith $ render showPage) return () ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
Thomas Schilling wrote: On Sat, 2007-10-27 at 18:48 -0400, Isaac Dupree wrote: When I try to go to one of the Module.hs files, e.g. on darcs.haskell.org, it now has type HS and Firefox refuses to display it (and only lets me download it). Does anyone know how to make Firefox treat certain file types as others (HS as plain text, in particular)? so that I can browse them with any convenience I believe those kinds of problem have to do with the MIME-encoding on the server side: The server uses text/x-haskell. For Firefox to display the document inline it probably has to be text/plain. Not sure what the proper fix is, though. It should probably be fixed in one of the Apache config files. In the HTTP headers from darcs.haskell.org (viewed with the Live HTTP headers extension in FireFox) I'm getting Server: Apache/2.2.3 (Debian) Content-Type: text/x-haskell returned when I request the Map.hs file. For Apache 2.2 there seem to be various solutions. The web admin should probably be looking at these sorts of things http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addtype http://httpd.apache.org/docs/2.2/mod/core.html#forcetype http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype and maybe rummaging in file httpd.conf Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Jaak Randmets wrote: On 10/28/07, Prabhakar Ragde [EMAIL PROTECTED] wrote: For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. You could try giving divisors type signature: divisors :: Int - [Int] Thank you. That brings the time down to 0.5 seconds. I'm glad it was something as simple as that. --PR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tim Sweeney and multi-cores .... and Haskell
On 28/10/2007, Galchin Vasili [EMAIL PROTECTED] wrote: http://www.americanscientist.org/content/AMSCI/AMSCI/ArticleAltFormat/2007102151724_866.pdf Am I missing something? I didn't see anything about Haskell, nor Tim Sweeney for that matter, in that article. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Good news for Windows developers?
If I understand this blog correctly, F# leaves the research lab and becomes an official Visual Studio language? http://blogs.msdn.com/somasegar/archive/2007/10/17/f-a-functional-programming-language.aspx Okay it's not Haskell, but I think it's good news anyway... Cheers, Peter PS: Shouldn't the Super Simons do some more PR at Microsoft so this also happens to Haskell? ;-) ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Prabhakar Ragde writes: For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. I've tried using foldl', and doing explicit tail recursion with strict accumulators, but I can't get the running time below 3 seconds. Is it possible to come within striking distance of the other languages? Thanks. Just a trivial comment... 1. Don't speak about comparing *languages* when you compare *algorithms*, and in particular data structures. 2. Please, DO code the above in C, using linked lists. Compare then. 3. Check the influence of bare printing, separated from the computation. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Recipes for organizing HUnit tests
I'm new to Haskell and am trying to find a good way to organize my HUnit tests. Having used some of the other XUnit frameworks, I tended towards trying to organize them all in a parallel test folder structure, but this seems to be a bad fit for Haskell, since the test modules cannot see the source modules unless they are either in the same folder or a folder above it. That's without modifying the module search path when I run the tests, which I would like to avoid. So I tried looking for examples of HUnit-tested source code out there and found that the cryptographic library Crypto has some unit tests. However, Crypto seems to place all its test code at the top of the folder hierarchy for the reasons I mentioned above. This turns out to be fine for Crypto since there are few tests. But I can foresee the tests for my project multiplying to the point where it would become very unsightly to put them all in the top-level folder. My questions to you are: how do you organize your HUnit/QuickCheck tests? Is there a convention? Is there some library out there that embodies this convention? Mushfeq. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
On Sun, Oct 28, 2007 at 11:26:46AM -0400, Prabhakar Ragde wrote: Jerzy Karczmarczuk wrote: Just a trivial comment... 1. Don't speak about comparing *languages* when you compare *algorithms*, and in particular data structures. 2. Please, DO code the above in C, using linked lists. Compare then. 3. Check the influence of bare printing, separated from the computation. Isn't GHC clever enough to optimize away the entire computation if there is no I/O? Yes, but GHC is not clever enough to solve the perfect number classification problem. 'length' will suffice, and is prefered for most enumeration benchmarks. Note, however, that there are a grand total of 4 perfect numbers less than 10,000. Not exactly an IO problem. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recipes for organizing HUnit tests
Mushfeq Khan wrote: I'm new to Haskell and am trying to find a good way to organize my HUnit tests. Having used some of the other XUnit frameworks, I tended towards trying to organize them all in a parallel test folder structure, but this seems to be a bad fit for Haskell, since the test modules cannot see the source modules unless they are either in the same folder or a folder above it. That's without modifying the module search path when I run the tests, which I would like to avoid. Well, it's certainly possible to use parallel directory structures -- this is one way to do it: Xyzzy/Gizmo.hs: module Xyzzy.Gizmo where ... Test/Gizmo.hs: module Test.Gizmo where import Xyzzy.Gizmo main = ... ghc --make -main-is Test.Gizmo.main Test/Gizmo.hs Or without -main-is, Tests.hs: module Main where import Test.Gizmo import Test.Bar ... main = testGizmo, testBar ... ghc --make Tests Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with PDF/PS backend in GTK2HS
On Sun, 2007-10-28 at 15:07 +0100, Peter Verswyvelen wrote: I have a strange problem, which is so elementary that I think I must be missing something... In GTK2HS, when I draw text using using textPath, the text is located at different locations depending on which backend is used. I'm not talking about a difference of a couple of pixels , but in my case it's half a page off. The PNG and Win32 backend work fine, but the PDF/PS backends get it wrong. For example, I modified the Text.hs demo in the demos/Cairo subdirectory so it also outputs PDF. Here the text is also at different locations, so I guess it's not just my code. Code is pasted below. I'm using Windows, and GTK2HS version 0.9.12 from http://www.haskell.org/gtk2hs Maybe someone could give this a quick test on Linux? I guess this is most likely a Cairo problem, and has nothing to do with the Haskell wrapper? Still this is hard to believe, since these kinds of bugs would be quickly found. Yes, I get the same. It works fine on Linux and the text has the wrong position on Windows. I'm doing a new Gtk2Hs build soon for compatibility with ghc-6.8 and I can try with a more recent version of cairo then and see if the bug has been fixed. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Prabhakar Ragde wrote: You could try giving divisors type signature: divisors :: Int - [Int] Thank you. That brings the time down to 0.5 seconds. I'm glad it was something as simple as that. --PR I assume GHC was smart enough to do inlining and such in this case, so the difference is that it defaulted to Integer, whose operations are somewhat slower. Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with PDF/PS backend in GTK2HS
On 10/28/07, Duncan Coutts [EMAIL PROTECTED] wrote: Yes, I get the same. It works fine on Linux and the text has the wrong position on Windows. I'm doing a new Gtk2Hs build soon for compatibility with ghc-6.8 and I can try with a more recent version of cairo then and see if the bug has been fixed. I don't know if this is the same bug, bug I've ran into a similar one as well. It should be fixed on a new version ( http://lists.cairographics.org/archives/cairo/2007-August/011172.html ), but mine is a bit older than that so I can't confirm. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recipes for organizing HUnit tests
Isaac Dupree wrote: Mushfeq Khan wrote: I'm new to Haskell and am trying to find a good way to organize my HUnit tests. Having used some of the other XUnit frameworks, I tended towards trying to organize them all in a parallel test folder structure, but this seems to be a bad fit for Haskell, since the test modules cannot see the source modules unless they are either in the same folder or a folder above it. That's without modifying the module search path when I run the tests, which I would like to avoid. Well, it's certainly possible to use parallel directory structures -- this is one way to do it: Xyzzy/Gizmo.hs: module Xyzzy.Gizmo where ... Test/Gizmo.hs: module Test.Gizmo where import Xyzzy.Gizmo main = ... ghc --make -main-is Test.Gizmo.main Test/Gizmo.hs Or without -main-is, Tests.hs: module Main where import Test.Gizmo import Test.Bar ... main = testGizmo, testBar ... ghc --make Tests Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I asked the same question a while back. Yea, you want the parallel directory structure and you use the -iMyPack -iHUnit option when compiling you haskell code. You can kind of see what I did with this project. I have HUnit source in one module and Tests in a different module, different directory. http://octanemech.googlecode.com/svn/trunk/octanemech/src/ http://octanemech.googlecode.com/svn/trunk/octanemech/src/Makefile ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Stefan O'Rear adds to the dialogue: Prabhakar Ragde wrote: Jerzy Karczmarczuk wrote: Just a trivial comment... 1. Don't speak about comparing *languages* when you compare *algorithms*, and in particular data structures. 2. Please, DO code the above in C, using linked lists. Compare then. 3. Check the influence of bare printing, separated from the computation. Isn't GHC clever enough to optimize away the entire computation if there is no I/O? Yes, but GHC is not clever enough to solve the perfect number classification problem. 'length' will suffice, and is prefered for most enumeratioon benchmarks. My point didn't concern that point. Haskell compiler cannot change an algorithm using lists into something which deals with indexable arrays, usually faster. Indexing may be faster than the indirection, and the allocation of memory costs. And there is laziness... That's why I proposed to check what happens if one uses linked links in C. Well, the follow-ups seem to suggest that the main time eater was the overloading. I must say that I am really astonished. It is hard to believe that such a signature can make a factor of 8. Never seen that before. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
On Sun, 2007-10-28 at 10:23 -0400, Prabhakar Ragde wrote: Jaak Randmets wrote: On 10/28/07, Prabhakar Ragde [EMAIL PROTECTED] wrote: For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. You could try giving divisors type signature: divisors :: Int - [Int] Thank you. That brings the time down to 0.5 seconds. I'm glad it was something as simple as that. --PR I'm not sure if Jaak Randmets explained this, but the reason this makes a difference is that Haskell defaults to Integer, an arbitrary precision integer type, that is far more costly than an Int. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
jerzy.karczmarczuk: Stefan O'Rear adds to the dialogue: Prabhakar Ragde wrote: Jerzy Karczmarczuk wrote: Just a trivial comment... 1. Don't speak about comparing *languages* when you compare *algorithms*, and in particular data structures. 2. Please, DO code the above in C, using linked lists. Compare then. 3. Check the influence of bare printing, separated from the computation. Isn't GHC clever enough to optimize away the entire computation if there is no I/O? Yes, but GHC is not clever enough to solve the perfect number classification problem. 'length' will suffice, and is prefered for most enumeratioon benchmarks. My point didn't concern that point. Haskell compiler cannot change an algorithm using lists into something which deals with indexable arrays, usually faster. Indexing may be faster than the indirection, and the allocation of memory costs. And there is laziness... That's why I proposed to check what happens if one uses linked links in C. Well, the follow-ups seem to suggest that the main time eater was the overloading. I must say that I am really astonished. It is hard to believe that such a signature can make a factor of 8. Never seen that before. That fits with my experience writing low level numeric code -- Integer can be a killer. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
When I try to go to one of the Module.hs files, e.g. on darcs.haskell.org, it now has type HS and Firefox refuses to display it (and only lets me download it). Does anyone know how to make Firefox treat certain file types as others (HS as plain text, in particular)? so that I can browse them with any convenience In Windows what I do is save the file on the desktop when it asks you to save it. Then right-click the file and select open with and choose wordpad to open it with. Check the box open with this application every time. Now close it and go back to your browser and click on the file. It should now open up in wordpad each time. At least that is the behavior in IE. Thanks, Isaac Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
On Sun, 2007-10-28 at 12:01 -0700, Don Stewart wrote: jerzy.karczmarczuk: Stefan O'Rear adds to the dialogue: Prabhakar Ragde wrote: Jerzy Karczmarczuk wrote: Just a trivial comment... 1. Don't speak about comparing *languages* when you compare *algorithms*, and in particular data structures. 2. Please, DO code the above in C, using linked lists. Compare then. 3. Check the influence of bare printing, separated from the computation. Isn't GHC clever enough to optimize away the entire computation if there is no I/O? Yes, but GHC is not clever enough to solve the perfect number classification problem. 'length' will suffice, and is prefered for most enumeratioon benchmarks. My point didn't concern that point. Haskell compiler cannot change an algorithm using lists into something which deals with indexable arrays, usually faster. Indexing may be faster than the indirection, and the allocation of memory costs. And there is laziness... That's why I proposed to check what happens if one uses linked links in C. Well, the follow-ups seem to suggest that the main time eater was the overloading. I must say that I am really astonished. It is hard to believe that such a signature can make a factor of 8. Never seen that before. That fits with my experience writing low level numeric code -- Integer can be a killer. Inline machine operations v. out-of-line calls to an arbitrary precision integer C library: there shouldn't be any surprise here. I could make it even slower by making a Nat type and giving it the type Nat - [Nat]. Also, this is a well known issue. It is common for people to, for example, write naive fib and then say that Haskell is useless because it's orders of magnitude slower than naive fib in C or whatever. Then you tell them to add an Int - Int type signature and all of a sudden Haskell is beating C soundly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Am Sonntag, 28. Oktober 2007 20:09 schrieb Derek Elkins: snip That fits with my experience writing low level numeric code -- Integer can be a killer. Inline machine operations v. out-of-line calls to an arbitrary precision integer C library: there shouldn't be any surprise here. Obviously. However, what if 32 bit integers aren't sufficient? What perpetually puzzles me is that in C long long int has very good performance, *much* faster than gmp, in Haskell, on my computer, Int64 is hardly faster than Integer. So I stick to Integer mostly, it may be slow but it's correct. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
Hi,
Prabhakar Ragde wrote:
divisors i = [j | j-[1..i-1], i `mod` j == 0]
main = print [i | i-[1..1], i == sum (divisors i)]
Jerzy Karczmarczuk wrote:
My point didn't concern that point. Haskell compiler cannot change an
algorithm using lists into something which deals with indexable arrays,
usually faster. Indexing may be faster than the indirection, and the
allocation of memory costs. And there is laziness...
This may be true, but it isn't relevant in this case, since the obvious
c program doesn't need any arrays, only two loops:
for (int i = 1; i = 1; i++) {
int sum = 0;
for (int j = 1; j i; j++)
if (i % j == 0)
sum += i;
if (sum == i)
print(i);
}
Loops can be expressed with lazy lists in Haskell. Therefore, the
presented Haskell program is perfectly equivalent to the obvious c
program.
Tillmann Rendel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
Shachaf Ben-Kiki wrote: Richard Kelsall wrote: Thomas Schilling wrote: On Sat, 2007-10-27 at 18:48 -0400, Isaac Dupree wrote: When I try to go to one of the Module.hs files, e.g. on darcs.haskell.org, it now has type HS and Firefox refuses to display it (and only lets me download it). Does anyone know how to make Firefox treat certain file types as others (HS as plain text, in particular)? so that I can browse them with any convenience I believe those kinds of problem have to do with the MIME-encoding on the server side: The server uses text/x-haskell. For Firefox to display the document inline it probably has to be text/plain. Not sure what the proper fix is, though. It should probably be fixed in one of the Apache config files. In the HTTP headers from darcs.haskell.org (viewed with the Live HTTP headers extension in FireFox) I'm getting Fixed? It's already fixed. text/x-haskell is the right Content-Type to send; this is Haskell after all, not just plaintext. It's your browser's responsibility to display it any way it likes. People have had this discussion in #xmonad, and it seems that MIME edit (https://addons.mozilla.org/en-US/firefox/addon/4498) is a workable solution (I don't use it myself, though). Of course, Sterling Clover's suggestion (Open in Browser) would also work well. Hello Shachaf, I hope you intended this for the list, as I haven't seen it come through, if not my apologies for posting it. Ah, yes I see what you mean, text/x-haskell is the best media-type, however I think it ought to be possible to use 'content negotiation' http://httpd.apache.org/docs/2.2/content-negotiation.html with more than one representation to supply the same file as text/plain to non-Haskell-capable browsers. I haven't actually done this though so can't be certain of it or provide configuration details. If somebody really wanted to get clever with it it could also supply pretty coloured Haskell for a text/html representation. Sorry, I couldn't find the #xmonad discussion, is this published somewhere? Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
One thing I've noticed is that turning on optimizations significantly increases the speed of haskell code. Are you comparing code between languages with -O2 or without opts? On 10/28/07, Prabhakar Ragde [EMAIL PROTECTED] wrote: For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 1. divisors i = [j | j-[1..i-1], i `mod` j == 0] main = print [i | i-[1..1], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. I've tried using foldl', and doing explicit tail recursion with strict accumulators, but I can't get the running time below 3 seconds. Is it possible to come within striking distance of the other languages? Thanks. --PR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
rendel:
Prabhakar Ragde wrote:
divisors i = [j | j-[1..i-1], i `mod` j == 0]
main = print [i | i-[1..1], i == sum (divisors i)]
Jerzy Karczmarczuk wrote:
My point didn't concern that point. Haskell compiler cannot change an
algorithm using lists into something which deals with indexable arrays,
usually faster. Indexing may be faster than the indirection, and the
allocation of memory costs. And there is laziness...
This may be true, but it isn't relevant in this case, since the obvious
c program doesn't need any arrays, only two loops:
for (int i = 1; i = 1; i++) {
int sum = 0;
for (int j = 1; j i; j++)
if (i % j == 0)
sum += i;
if (sum == i)
print(i);
}
Loops can be expressed with lazy lists in Haskell. Therefore, the
presented Haskell program is perfectly equivalent to the obvious c
program.
So what we would hope is that GHC could transform a set of composed lazy list
functions
into a doubly nested strict loop in Int#...
Let's see if we can get that result from GHC, using a bit of fusion.
First, to explain what is happening, let's first replace the `mod` call with
`rem`, which is faster, and then desugar the list comprehension and
enumerations syntax, to expose the underlying program:
default(Int)
divisors i = filter (\j - i `rem`j == 0) (enumFromTo 1 (i-1))
main = print $ filter (\i - i == sum (divisors i)) (enumFromTo 1 1)
Looking at this we see some good chances for fusion to take place: the
enumFromTo should fuse twice with 'filter', using build/foldr fusion.
And with stream fusion, the left fold 'sum' should also fuse with pipeline that
results from divisors. So my prediction would be that this program would run
slightly faster with stream fusion. Let's see...
Compiling with -O2 and ghc 6.8 snapshot, with build/foldr fusion, we see
two fusion sites, as expected, and a spec-constr of 'sum:
$ ghc-6.9.20070916 A.hs -O2 -ddump-simpl-stats
RuleFired
1 SPEC Data.List.sum
2 fold/build
Good, running this:
$ time ./A-stream
[6,28,496,8128]
./A-stream 1.29s user 0.02s system 99% cpu 1.319 total
Now we can try with stream fusion, using the stream-fusible list library
here:
http://www.cse.unsw.edu.au/~dons/code/streams/list/
To use these list functions in preference to the default, we have to
import:
import Prelude hiding (filter,sum,enumFromTo)
import Data.List.Stream
and since the base library doesn't include stream fusible enumFromTo,
we'll have to write our own definition in terms of stream:
import Data.Stream (enumFromToInt,unstream)
enumFromTo i j = unstream (enumFromToInt i j)
Ok, that's easy. Compiling this, we hope to see 3 fusion sites, and all
heap-allocated Ints removed:
$ ghc-6.9.20070916 A.hs -O2 -ddump-simpl-stats -package list
RuleFired
2 filter - fusible
1 sumInt - fusible
1 sum spec Int
3 STREAM stream/unstream fusion
Terrific! The 'sum' was specialised to Int, then translated to a stream
version, the two filters also were translated, then 3 fusion sites were found
and fused. Our program should now run faster:
$ time ./A-stream
[6,28,496,8128]
./A-stream 1.23s user 0.01s system 99% cpu 1.251 total
And so it does, with no list allocated for the sum loop. In fact the entire
program reduces
to a strict unboxed nested loop:
unfold = Int# - [Int]
wloop_sum_sV5 :: Int# - Int# - Int#
So almost identical types to the C program (bar for the return [Int]).
Finally, we can manually translate the C code into a confusing set of nested
loops with interleaved IO,
main = loop 1
where
loop !i | i 1 = return ()
| otherwise = if i == go i 0 1 then print i loop (i+1)
else loop (i+1)
go !i !s !j | j = i-1 = if i `rem` j == 0 then go i (s+j) (j+1)
else go i s (j+1)
| otherwise = s
And we get *no speed benefit* at all!
time ./A-loop 1.24s user 0.00s system 98% cpu 1.256 total
So the lesson is: write in a high level style, and the compiler can do the work
for you. Or, GHC is pretty smart on high level code.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
On Sun, Oct 28, 2007 at 08:40:28PM +0100, Daniel Fischer wrote: Am Sonntag, 28. Oktober 2007 20:09 schrieb Derek Elkins: snip That fits with my experience writing low level numeric code -- Integer can be a killer. Inline machine operations v. out-of-line calls to an arbitrary precision integer C library: there shouldn't be any surprise here. Obviously. However, what if 32 bit integers aren't sufficient? What perpetually puzzles me is that in C long long int has very good performance, *much* faster than gmp, in Haskell, on my computer, Int64 is hardly faster than Integer. So I stick to Integer mostly, it may be slow but it's correct. Int64 in Glasgow Haskell is not implemented for speed - it uses the FFI to call a number of addition/subtraction/whatever primitives in the runtime. If this is a problem for you, file a feature request on the GHC bugtracker. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
On Sun, Oct 28, 2007 at 01:25:19PM -0700, Don Stewart wrote: Finally, we can manually translate the C code into a confusing set of nested loops with interleaved IO, main = loop 1 where loop !i | i 1 = return () | otherwise = if i == go i 0 1 then print i loop (i+1) else loop (i+1) go !i !s !j | j = i-1 = if i `rem` j == 0 then go i (s+j) (j+1) else go i s (j+1) | otherwise = s And we get *no speed benefit* at all! time ./A-loop 1.24s user 0.00s system 98% cpu 1.256 total So the lesson is: write in a high level style, and the compiler can do the work for you. Or, GHC is pretty smart on high level code. IO blocks unboxing in GHC. How fast is your mock-C code refactored to do IO outside of the loops only? Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
stefanor: On Sun, Oct 28, 2007 at 01:25:19PM -0700, Don Stewart wrote: Finally, we can manually translate the C code into a confusing set of nested loops with interleaved IO, main = loop 1 where loop !i | i 1 = return () | otherwise = if i == go i 0 1 then print i loop (i+1) else loop (i+1) go !i !s !j | j = i-1 = if i `rem` j == 0 then go i (s+j) (j+1) else go i s (j+1) | otherwise = s And we get *no speed benefit* at all! time ./A-loop 1.24s user 0.00s system 98% cpu 1.256 total So the lesson is: write in a high level style, and the compiler can do the work for you. Or, GHC is pretty smart on high level code. IO blocks unboxing in GHC. How fast is your mock-C code refactored to do IO outside of the loops only? It doesn't! The above code yields: Main.$wloop :: GHC.Prim.Int# - GHC.Prim.State# GHC.Prim.RealWorld - (# GHC.Prim.State# GHC.Prim.RealWorld, () #) $wgo_rMK :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# where $s$wgo_rMI :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
On Sun, Oct 28, 2007 at 01:43:07PM -0700, Don Stewart wrote: stefanor: IO blocks unboxing in GHC. How fast is your mock-C code refactored to do IO outside of the loops only? It doesn't! The above code yields: Main.$wloop :: GHC.Prim.Int# - GHC.Prim.State# GHC.Prim.RealWorld - (# GHC.Prim.State# GHC.Prim.RealWorld, () #) $wgo_rMK :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# where $s$wgo_rMI :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# Ah, interesting. I was reading something too general from http://hackage.haskell.org/trac/ghc/ticket/1592#comment:5. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
On 10/28/07, Stefan O'Rear [EMAIL PROTECTED] wrote: On Sun, Oct 28, 2007 at 01:43:07PM -0700, Don Stewart wrote: stefanor: IO blocks unboxing in GHC. How fast is your mock-C code refactored to do IO outside of the loops only? It doesn't! The above code yields: Main.$wloop :: GHC.Prim.Int# - GHC.Prim.State# GHC.Prim.RealWorld - (# GHC.Prim.State# GHC.Prim.RealWorld, () #) $wgo_rMK :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# where $s$wgo_rMI :: GHC.Prim.Int# - GHC.Prim.Int# - GHC.Prim.Int# Ah, interesting. I was reading something too general from http://hackage.haskell.org/trac/ghc/ticket/1592#comment:5. Right, unboxing is successful here because the arguments are marked as strict with (!) annotations. The IO hack described in that bug report would only be a problem if the arguments were not marked strict, and were used in code that has to be executed after an IO call. Although I don't think all of the strictness annotations are even necessary here. In any case, loop must evaluate i before the call to print; there would only be an issue if it called an IO function before doing anything that demands i. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt Accordingly, computer scientists commonly choose models which have bottoms, but prefer them topless. -- Davey Priestley, _Introduction to Lattices and Order_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
dons: stefanor: On Sun, Oct 28, 2007 at 01:25:19PM -0700, Don Stewart wrote: Finally, we can manually translate the C code into a confusing set of nested loops with interleaved IO, main = loop 1 where loop !i | i 1 = return () | otherwise = if i == go i 0 1 then print i loop (i+1) else loop (i+1) go !i !s !j | j = i-1 = if i `rem` j == 0 then go i (s+j) (j+1) else go i s (j+1) | otherwise = s And we get *no speed benefit* at all! time ./A-loop 1.24s user 0.00s system 98% cpu 1.256 total So the lesson is: write in a high level style, and the compiler can do the work for you. Or, GHC is pretty smart on high level code. Oh, and we can fuse with the print loop too, yielding an entire program of type Int# - IO (), and really no intermediate lists (even for the return list). Again, we need to use the fusible version of mapM_: import Prelude hiding (filter,sum,enumFromTo,mapM_,sequence_,map,foldr) import Data.List.Stream import Data.Stream (enumFromToInt,unstream) enumFromTo i j = unstream (enumFromToInt i j) mapM_ f as = sequence_ (map f as) sequence_ ms = foldr () (return ()) ms -- ^ fuse happily default(Int) main = mapM_ print $ filter (\i - i == sum (divisors i)) (enumFromTo 1 1) divisors i = filter (\j - i `rem`j == 0) (enumFromTo 1 (i-1)) And we see the map and foldr fuse in sequence, which in turn fuses with the filter (and rest of the program): 18 RuleFired 5 STREAM stream/unstream fusion 2 filter - fusible 1 foldr - fusible 1 map - fusible 1 sumInt - fusible The program flattens to a single nested loop, Main.$wloop_foldr :: GHC.Prim.Int# - GHC.Prim.State# GHC.Prim.RealWorld - (# GHC.Prim.State# GHC.Prim.RealWorld, () #) which really is equivalent in terms of control flow and intermediate structures to the C program. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Daniel Fischer wrote: What perpetually puzzles me is that in C long long int has very good performance, *much* faster than gmp, in Haskell, on my computer, Int64 is hardly faster than Integer. I tried the example with Int64 and Integer. The integer version was actually quicker ... which is the reason I decided to post the results. C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Interesting that Int64 is *slower* than Integer. On the other side the C version is not that much quicker. I guess the Haskell version is using generic versions of mod and sum (since they are from a library) which would mean indirect calls. The Haskell version probably also creates the list nodes ... even when they get almost immediately garbage collected. Thanks for pointing out Int64 sucks so much :) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: newbie optimization question
peter: Daniel Fischer wrote: What perpetually puzzles me is that in C long long int has very good performance, *much* faster than gmp, in Haskell, on my computer, Int64 is hardly faster than Integer. I tried the example with Int64 and Integer. The integer version was actually quicker ... which is the reason I decided to post the results. C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Interesting that Int64 is *slower* than Integer. On the other side the C version is not that much quicker. I guess the Haskell version is using generic versions of mod and sum (since they are from a library) which would mean indirect calls. The Haskell version probably also creates the list nodes ... even when they get almost immediately garbage collected. Thanks for pointing out Int64 sucks so much :) With -O2 ghc will only have a function call to 'sum', with -O2 and the list stream fusion library, there are no indirect calls and the entire program is specialised to a nested loop. Do you have your C++ program handy? I'd expect the fully fused version to be somewhere between 1 and 2x slower. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Peter Hercek wrote: C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Ooops, my results ware wrong (nonoptimizing ms cl compiler used and I used -O instead of -O2 in ghc). C++ version times: 1.109; 1.125; 1.125 Int32 cpu times: 1.359; 1.359; 1.375 Int64 cpu times: 11.688; 11.719; 11.766 Integer cpu times: 9.719; 9.703; 9.703 Great result from ghc. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: newbie optimization question
peter: Peter Hercek wrote: C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Ooops, my results ware wrong (nonoptimizing ms cl compiler used and I used -O instead of -O2 in ghc). C++ version times: 1.109; 1.125; 1.125 Int32 cpu times: 1.359; 1.359; 1.375 Int64 cpu times: 11.688; 11.719; 11.766 Integer cpu times: 9.719; 9.703; 9.703 Great result from ghc. What Haskell program were you using for this test? The original naive/high level implementation? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE / POST MORTEM: hswm, version ()
Hi everyone, HSWM was my attempt at a Haskell Window Manager, mostly written during the first half of 2006 as a personal research project, and out of frustration with some not to be named other window managers. Although I have been running it myself for almost two years, I never got around to polishing it into something releasable due to lack of time. [1] Since, as of today, its number of users is officially back to zero [2], this seems like a good moment to release version () of HSWM: The first and last version of my own window manager. Features are: - includes a lambda mouse cursor - multiple desktops - sticky windows - about 2300 lines, about half of which is X boilerplate and user configuration - somewhat based on evilwm - still regularly dies due to unhandled X errors, so a script to automatically restart in that case is included - my first Xlib program ever The basic idea is an event loop inside an X monad providing three services to plugins: - registering X Event handlers - registering X Error handlers - registering/requesting services, to be used by other plugins (a global registry of named Dynamics, basically) Compared to XMonad: - no tiling - much less stable - no extensions - needs no external libs So you might want to look at it, but even _I_ don't use it anymore. HSWM only was its working name, so if anybody ever feels like writing another window manager and calling it HSWM, I certainly won't mind. The BSD-licensed code: darcs get http://student.science.uva.nl/~rturk/hswm/ `make' compiles, and that's it. Greetings, Remi [1] Technical detail: The one feature I really wanted before releasing it, but never got around to implementing, is having the WM add a frame for each managed window and reparenting the window below that frame. This way, focusing windows can go right even when the WM dies, among others. [2] It once had 3 users: Me at home, me at the University of Amsterdam and me at Utrecht University. Utrecht now runs KDE and the rest xmonad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Don Stewart wrote:
C++ version times: 1.109; 1.125; 1.125
Int32 cpu times: 1.359; 1.359; 1.375
Int64 cpu times: 11.688; 11.719; 11.766
Integer cpu times: 9.719; 9.703; 9.703
Great result from ghc.
What Haskell program were you using for this test? The original
naive/high level implementation?
-- Don
Here it is (I played only with the types for divisors and perfect;
bottom is there from my previous tests, but it should not matter):
---cut---
module Main (bottom, divisors, perfect, main) where
import Data.Int
bottom = error _|_
divisors :: Int - [Int]
divisors i = [j | j-[1..i-1], i `mod` j == 0]
perfect :: [Int]
perfect = [i | i-[1..1], i == sum (divisors i)]
main = print perfect
---cut---
and here is the C++ version:
---cut---
#include iostream
using namespace std;
int main() {
for (int i = 1; i = 1; i++) {
int sum = 0;
for (int j = 1; j i; j++)
if (i % j == 0)
sum += j;
if (sum == i)
cout i ;
}
return 0;
}
---cut---
OS winxp 64 bit
ghc v. 6.6.1 (optins -O2)
MS cl.exe version 13.10.3077 (options /G7 /MD)
Peter.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Peter Hercek wrote: MS cl.exe version 13.10.3077 (options /G7 /MD) And I had cl options wrong too - I need to start to optimize not only to set the optimization target. /G7 /MD - 1.109; 1.125; 1.125 /Ox /G7 /MD - 0.922; 0.984; 0.984 Still it does not change the results too much. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: newbie optimization question
On Sun, 2007-10-28 at 23:34 +0100, Peter Hercek wrote: Don Stewart wrote: C++ version times: 1.109; 1.125; 1.125 Int32 cpu times: 1.359; 1.359; 1.375 Int64 cpu times: 11.688; 11.719; 11.766 Integer cpu times: 9.719; 9.703; 9.703 Great result from ghc. What Haskell program were you using for this test? The original naive/high level implementation? -- Don Here it is (I played only with the types for divisors and perfect; bottom is there from my previous tests, but it should not matter): ---cut--- module Main (bottom, divisors, perfect, main) where import Data.Int bottom = error _|_ divisors :: Int - [Int] divisors i = [j | j-[1..i-1], i `mod` j == 0] perfect :: [Int] perfect = [i | i-[1..1], i == sum (divisors i)] main = print perfect Try with rem instead of mod. (What the heck is with bottom?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie optimization question
G'day all. Quoting Don Stewart [EMAIL PROTECTED]: That fits with my experience writing low level numeric code -- Integer can be a killer. Mind you, if you're intending to work with large integers or rationals, Integer is great! The bottleneck is almost always show. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: newbie optimization question
peter: Don Stewart wrote: C++ version times: 1.109; 1.125; 1.125 Int32 cpu times: 1.359; 1.359; 1.375 Int64 cpu times: 11.688; 11.719; 11.766 Integer cpu times: 9.719; 9.703; 9.703 Great result from ghc. What Haskell program were you using for this test? The original naive/high level implementation? -- Don Here it is (I played only with the types for divisors and perfect; bottom is there from my previous tests, but it should not matter): ---cut--- module Main (bottom, divisors, perfect, main) where import Data.Int bottom = error _|_ divisors :: Int - [Int] divisors i = [j | j-[1..i-1], i `mod` j == 0] perfect :: [Int] perfect = [i | i-[1..1], i == sum (divisors i)] This should be a little faster , as sum will fuse, perfect :: [Int] perfect = [i | i-[1..1], i == sum' (divisors i)] where sum' = foldr (+) 0 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] newbie question about list performance
Hello, I've been following the list optimization thread with great interest, as it pertains to something I'm working on at the moment. I'm working with moderate-sized files (tens to hundreds of MBs) that have some ascii header data followed by a bunch of 32-bit ints. I can read the files into a lazy ByteString (and parse the header), but I'd like some advice as to the best data type to convert the ints into. Ideally, I'd have some functions like this: decode :: ByteString - (FileFormat, [Int32]) encode :: FileFormat - [Int32] - ByteString but I don't know if Int32 is actually the best choice. It seems to me that something like a lazy list of strict arrays (analogous to a lazy bytestring) would be better. Is there a library like this already? Or is this a case of premature optimization, and I should just try the list and see if it's good enough? Any suggestions would be appreciated. Also, I'd like to let the maintainers and implementors know that I really appreciate the work that's been done on optimizing Haskell. I haven't used Haskell much yet, but I've fallen in love with the language and it's great to see that performance even for heavy I/O tasks can be comparable to or exceed C. Thank you, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Newbie Question on Setting the GHC Search Path
Please pardon this intrusion for an elementary question on setting the GHC search path. I have installed GHC on my work Windows XP machine, and would like to be able to search for files in the following directory: D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC However, when I type the following command into the GHC interpreter: :cd D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC I get the following error message: *** Exception: D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC: setCurrentDirectory: invalid argument (Invalid argument) Yet, for testing purposes, when I type the following command: :cd cygwin I do not get any error message. There seems to be a problem with the spaces in the filename. However, I would like to be able to use the D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC directory for GHC programming practice, because I keep my practice work for my other programming languages in the same super-super-directory. Does anybody know a way to specify D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC as a directory in the search path for GHC? Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie question about list performance
jwlato: Hello, I've been following the list optimization thread with great interest, as it pertains to something I'm working on at the moment. I'm working with moderate-sized files (tens to hundreds of MBs) that have some ascii header data followed by a bunch of 32-bit ints. I can read the files into a lazy ByteString (and parse the header), but I'd like some advice as to the best data type to convert the ints into. Ideally, I'd have some functions like this: decode :: ByteString - (FileFormat, [Int32]) encode :: FileFormat - [Int32] - ByteString but I don't know if Int32 is actually the best choice. It seems to me that something like a lazy list of strict arrays (analogous to a lazy bytestring) would be better. Is there a library like this already? Or is this a case of premature optimization, and I should just try the list and see if it's good enough? Any suggestions would be appreciated. could you use Data.Binary.encode/decode (with custom put and get instances)? They read fomr lazy bytestrings into custom structures, such as arrays. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.4.1 Also, I'd like to let the maintainers and implementors know that I really appreciate the work that's been done on optimizing Haskell. I haven't used Haskell much yet, but I've fallen in love with the language and it's great to see that performance even for heavy I/O tasks can be comparable to or exceed C. Yay! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
