On 1/6/06, Udo Stenzel [EMAIL PROTECTED] wrote:
Sebastian Sylvan wrote:
On 1/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
There is no need to beat a dead horse, though. This benchmark sets out
to test fgets / atoi, and that is all. There are better benchmarks to
spend time on.
Relative speed comparison below
Udo Stenzel wrote:
Sebastian Sylvan wrote:
On 1/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
There is no need to beat a dead horse, though. This benchmark sets out
to test fgets / atoi, and that is all. There are better benchmarks to
spend time on.
I
Brent Fulgham wrote:
--- Chris Kuklewicz [EMAIL PROTECTED]
wrote:
Also about sum-file: They do not reveal what the
actual 8k test file contains. So there is no way
to reproduce the benchmark locally for testing.
(One can learn it totals 40, but since
negative numbers are allowed, this
On 1/4/06, Brent Fulgham [EMAIL PROTECTED] wrote:
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
Some of the problems seem to be heavily geared
towards an imperative *implementation*, meaning that
a Haskell
version is hardly idiomatic Haskell (and as such I ,
and I
suspect otehrs,
Also about sum-file: They do not reveal what the actual 8k test file
contains. So there is no way to reproduce the benchmark locally for
testing. (One can learn it totals 40, but since negative numbers
are allowed, this does not help much).
The problem can even be solved in one line with
On 1/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
Also about sum-file: They do not reveal what the actual 8k test file
contains. So there is no way to reproduce the benchmark locally for
testing. (One can learn it totals 40, but since negative numbers
are allowed, this does not help
I did manage to tweak SumFile to use unboxed Int# and go 10% faster.
http://haskell.org/hawiki/SumFile
Sebastian Sylvan wrote:
On 1/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
Also about sum-file: They do not reveal what the actual 8k test file
contains. So there is no way to reproduce
This uses getLine instead of getContents and is 3.8 times slower.
{-# OPTIONS -fglasgow-exts -O2 #-}
--
-- The Computer Language Shootout
-- http://shootout.alioth.debian.org/
--
-- compile with : ghc -O2 -o SumF SumF.hs
-- To get better performance set default heap size to 10MB
-- i.e. invoke
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
Some of the problems seem to be heavily geared
towards an imperative *implementation*, meaning that
a Haskell
version is hardly idiomatic Haskell (and as such I ,
and I
suspect otehrs, really have no inclination to work
on it).
I agree that
On 1/4/06, Brent Fulgham [EMAIL PROTECTED] wrote:
But I think Haskell may face real-world cases where
data must
be produced in some known order. For Haskell to be a
contender
in real world use, it sometimes has to confront ugly
requirements.
I must respectfully note that you contradict
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
My point here was that even though you _can_
generate this data in Haskell, there's no point in
requiring
(because the order doesn't matter for the benchmark
itself).
We do need to agree on which 30 permutations should be
used
in the validation
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
Some of the problems seem to be heavily geared towards an
imperative *implementation*, meaning that a Haskell version
is hardly idiomatic Haskell (and as such I , and I suspect
otehrs, really have no inclination to work on it).
This may be
12 matches
Mail list logo
