On 30 December 2005 01:23, Jan-Willem Maessen wrote:
Probably. The minimum table chunk size was rather large. I have
been experimenting (tests are running even as I type) with alternate
implementations of Data.HashTable. So far the winning implementation
is one based on multiplicative
On Jan 4, 2006, at 5:30 AM, Simon Marlow wrote:
On 30 December 2005 01:23, Jan-Willem Maessen wrote:
Probably. The minimum table chunk size was rather large. I have
been experimenting (tests are running even as I type) with alternate
implementations of Data.HashTable. So far the winning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I recently stumbled across this thread, related to the Shootout
(which I run) and wanted to add a few comments.
First, I agree that I am a Haskell novice; however, I rely on
people like yourselves to show me where I am doing things wrong.
If
Hello Branimir,
Saturday, December 31, 2005, 4:55:51 AM, you wrote:
IOArrays is second-class citizens in GHC/Haskell. they are scanned on
_each_ GC, and this can substantially slow down program which uses
large IOArrays.
BM Hm, there is Hans Boehm GC for C and C++ and I have gcmalloc and
BM
Hello Albert,
Thursday, December 29, 2005, 11:56:12 PM, you wrote:
AL For almost a decade, most (I dare claim even all) Pascal and C
AL compilers were three-pass or two-pass.
1) Pascal was developed as one-pass compiled language.
highly-optimizing compilers used additional passes to generate
Hello Branimir,
Friday, December 30, 2005, 3:44:26 AM, you wrote:
BM myHashString = fromIntegral . ff''' . ff'' . ff' . foldr f 0
i use the following hash function in my program:
filenameHash = fromIntegral . foldl (\h c - h*37+(ord c)) 0
(it's written without explicit parameter in order to
From: Bulat Ziganshin [EMAIL PROTECTED]
Reply-To: Bulat Ziganshin [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], haskell-cafe@haskell.org
Subject: Re[2]: [Haskell-cafe] Re: Haskell Speed
Date: Fri, 30 Dec 2005 17:56:57 +0300
Hello Branimir,
Friday
Albert Lai writes:
For almost a decade, most (I dare claim even all) Pascal
and C compilers were three-pass or two-pass. It means
perhaps the compiler reads the input two or three times
[...], or perhaps the compiler reads the input once,
produces an intermediate form and saves it to
On Thu, 2005-12-29 at 15:56 -0500, Albert Lai wrote:
. . .
one-pass fast method, since for almost a decade no one did it. Most
of us had to wait until someone figured it out and then we had Turbo
Judging from comments by U. Ammann [1],[2], part of the original Pascal
implementation team at
From: Isaac Gouy [EMAIL PROTECTED]
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Re: Haskell Speed
Date: Thu, 29 Dec 2005 13:00:15 -0800 (PST)
--- Isaac Gouy [EMAIL PROTECTED] wrote:
We'll be happy to also show a Haskell program that
uses Data.HashTable - first, someone needs
On Dec 29, 2005, at 7:44 PM, Branimir Maksimovic wrote:
To comment some observation on this program.
Most of the pressure now is on Data.HashTable.
I've susspected such large memory usage on substring from array
conversions,
so mad version with data MyString = MakeMyStrinf { buf :: Ptr Char,
From: Isaac Gouy [EMAIL PROTECTED]
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Re: Haskell Speed
Date: Tue, 27 Dec 2005 20:12:01 -0800 (PST)
Branimir Maksimovic wrote:
Of course, first example uses [String] instead of
Data.HashTable
as other languages do. Imagine C program does
Simon Marlow wrote:
Also, I would like to draw your attention to the
fact that GHC
wipes the floor with nearly everyone in the
concurrency
benchmark
SmartEiffel is so much faster that I'm still trying to
figure out if it's doing something different :-)
Be interesting to see GHC on the other
Jared Updike wrote:
What that means is the results are completely
subject to
(1) how good the submission for that tests was
Contribute faster more-elegant programs
http://shootout.alioth.debian.org/gp4/faq.php#contribute
(2) the choice of tests in the first place
Suggest better tests
Branimir Maksimovic wrote:
Of course, first example uses [String] instead of
Data.HashTable
as other languages do. Imagine C program does not
use
hash,rather list, how it will perform:)
And the author comments his program
-- This is a purely functional solution to the
problem.
-- An
On 25 Dec 2005 12:24:38 +0100, Peter Simons [EMAIL PROTECTED] wrote:
Paul Moore writes:
It would be interesting to see standalone code for wcIOB
(where you're allowed to assume that any helpers you
need, like your block IO library, are available from the
standard library). This would
Back to where this came from, my view is that this is an education
issue - tutorials tend to focus on lazy, functional techniques, and
not on efficiency.
But the material is available, so people *can* learn. It just needs
some effort (but possibly more than it should...)
Can anyone suggest
Paul Moore wrote:
On 25 Dec 2005 12:24:38 +0100, Peter Simons [EMAIL PROTECTED] wrote:
Paul Moore writes:
It would be interesting to see standalone code for wcIOB
(where you're allowed to assume that any helpers you
need, like your block IO library, are available from the
standard
Paul Moore writes:
It would be interesting to see standalone code for wcIOB
(where you're allowed to assume that any helpers you
need, like your block IO library, are available from the
standard library). This would help in comparing the
obviousness of the two approaches.
A simple
On Sun, Dec 25, 2005 at 12:24:38PM +0100, Peter Simons wrote:
Paul Moore writes:
It would be interesting to see standalone code for wcIOB
(where you're allowed to assume that any helpers you
need, like your block IO library, are available from the
standard library). This would help
Tomasz Zielonka writes:
wc :: String - (Int, Int, Int)
wc file = ( length (lines file)
, length (words file)
, length file
)
I have a crazy idea: what if we computed all three length
applications concurrently, with the RTS preempting the
thread when
On 23 Dec 2005 22:29:02 +0100, Peter Simons [EMAIL PROTECTED] wrote:
Daniel Carrera writes:
when I have a simple algorithm and performance is an
issue [...] I'd use C.
You don't have to. You can write very fast programs in
Haskell.
I never really finished the article I wanted to write
On Dec 24, 2005, at 6:02 PM, Paul Moore wrote:
One of the interesting points that this illustrates (to me) is that
the obvious approach in Haskell can be seriously non-optimal in
terms of performance. Add to this the fact that tuning functional
programs is a non-trivial art, and it becomes
23 matches
Mail list logo
