Sorry Bryan, there are a couple of comments I should make a final reply to -
I'll ignore the rest.
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Wednesday, May 23, 2012 10:52 PM
-snip-
Says who? Is that on your own authority or some other source you can point
us to?
It looks
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Tuesday, May 22, 2012 7:59 PM
But string processing and text I/O using the java.io.* classes aren't
brilliant.
Wait just a moment - Are you comparing text I/O for C programs that process
bytes against Java programs that process double-byte
From: wren ng thornton w...@freegeek.org
Sent: Tuesday, May 22, 2012 9:30 PM
-snip-
FWIW, that matches my expectations pretty well. Naive/standard Java
performing
slower than Smalltalk; highly tweaked Java using non-standard data types
performing on-par with or somewhat faster than
From: Richard O'Keefe
Sent: Monday, May 21, 2012 6:54 PM
On 22/05/2012, at 4:15 AM, Isaac Gouy wrote:
Actually, I/O bound is *good*.
Why would that be good or bad?
The context here is a UNIX-style topological sorting program.
Being I/O bound means that the program is limited by how
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Sunday, May 20, 2012 3:41 PM
On 19/05/2012, at 5:51 AM, Isaac Gouy wrote:
In the 'tsort' case, it turns out that the Java and Smalltalk
versions are I/O bound with over 90% of the time spent just
reading the data.
My guess is that they could
From: Stephen Tetley stephen.tet...@gmail.com
Sent: Monday, May 21, 2012 10:08 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
On 21 May 2012 17:27, Yves Parès yves.pa...@gmail.com wrote:
I fail to see how the GUI part would suffer from lack of performance if the
rest of
From: wren ng thornton w...@freegeek.org
Sent: Saturday, May 19, 2012 12:49 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
Fair in what sense? That is, what _exactly_ are you hoping to
compare?
If the goal is to benchmark the implementation of the runtime, VM, or
- Original Message -
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Thursday, May 17, 2012 8:30 PM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
The claim was and remains solely that
THE TIME DIFFERENCE BETWEEN *ALGORITHMS*
can be bigger than
THE TIME
- Original Message -
From: o...@cs.otago.ac.nz o...@cs.otago.ac.nz
Sent: Friday, May 18, 2012 9:38 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
and if we want
to compare *languages*, we should use identical algorithms to make the
comparison fair.
In
From: Gregg Lebovitz glebov...@gmail.com
Sent: Thursday, May 17, 2012 5:50 AMI look forward to
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac,
I see your point. Probably I shouldn't have made that assertion given my
limited understanding of the benchmarks. I want to
Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote:
2) ... I think the problem with current comparisons,
is that they are designed to favor imperative languages.
Please be specific:
- Which current comparisons?
- How do you know what they are designed to favor?
imperative languages ;-)
On 5/16/2012 12:59 PM, Isaac Gouy wrote:
Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote:
2) ... I think the problem with current comparisons,
is that they are designed to favor imperative languages.
Please be specific:
- Which current comparisons
2012/5/8 Silvio Frischknecht
Also I challenge anyone to improve one of the haskell programs there. It'd be
cool if we could make haskell get a higher rank. I recently managed to
improve the Fasta algorithm, but not by much. Also I think the benchmarks
don't use llvm flag. It says somewhere
1) Some of the GHC programs contributed to the benchmarks game have problems
with recent GHC releases
- meteor-contest #5 - Ambiguous occurrence `permutations'
http://shootout.alioth.debian.org/u64q/program.php?test=meteorlang=ghcid=5#log
- regex-dna #2 - Precedence parsing error
--- On Fri, 8/12/11, austin seipp a...@hacks.yi.org wrote:
Thanks, I do like easy fixes :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote:
Date: Thursday, June 10, 2010, 1:32 AM
Yeah, Control.Parallel would be nice to have. Heck, ideally I could get
the whole Haskell Platform, which would be a reasonable comparison to
the huge Java and C++ libraries
--- On Wed, 6/9/10, Don Stewart d...@galois.com wrote:
-snip-
Now how do we get those regex-dna and binary-trees
programs to compile?
http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc
binary-trees:
Could not find module
`Control.Parallel.Strategies':
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote:
Date: Thursday, June 10, 2010, 1:32 AM
Yeah, Control.Parallel would be nice to have. Heck, ideally I could get
the whole Haskell Platform, which would be a reasonable comparison to
the huge Java and C++ libraries
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote:
Date: Thursday, June 10, 2010, 11:25 AM
There are 4 sets of rankings so -
http://shootout.alioth.debian.org/u64/program.php?test=threadringlang=ghcid=3
Yes, but Haskell used to be doing much better specifically on the
--- On Thu, 6/10/10, Don Stewart d...@galois.com wrote:
From: Don Stewart d...@galois.com
Subject: Re: [Haskell-cafe] Problems with threading?
To: Louis Wasserman wasserman.lo...@gmail.com
Cc: igo...@yahoo.com, Haskell Café List haskell-cafe@haskell.org
Date: Thursday, June 10, 2010, 11:36
--- On Thu, 6/10/10, Don Stewart d...@galois.com wrote:
From: Don Stewart d...@galois.com
Subject: Re: [Haskell-cafe] Problems with threading?
To: Isaac Gouy igo...@yahoo.com
Cc: Louis Wasserman wasserman.lo...@gmail.com, Haskell Café List
haskell-cafe@haskell.org
Date: Thursday, June 10
--- On Mon, 6/7/10, Don Stewart d...@galois.com wrote:
From: Don Stewart d...@galois.com
Subject: Re: [Haskell-cafe] Problems with threading?
To: Isaac Gouy igo...@yahoo.com
Cc: Louis Wasserman wasserman.lo...@gmail.com, Haskell Café List
haskell-cafe@haskell.org
Date: Monday, June 7, 2010
--- On Mon, 6/7/10, Don Stewart d...@galois.com wrote:
From: Don Stewart d...@galois.com
Subject: Re: [Haskell-cafe] Problems with threading?
To: Louis Wasserman wasserman.lo...@gmail.com
Cc: Haskell Café List haskell-cafe@haskell.org
Date: Monday, June 7, 2010, 2:50 PM
wasserman.louis:
On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach leimy2k at gmail.com wrote:
I'm still trying to figure out what the point of the shootout really is.
From one point of view - http://shootout.alioth.debian.org/help.php#why
If there's no dedicated folks working with a language there, trying to
Ketil Malde ketil at malde.org writes:
As for code size, the programs are heavily tuned for speed.
iirc there was a community effort 2 or 3 years ago, but now ghc has changed
enough that the compiler and runtime parameters seem to need re-tuning.
Is it an idea to go back a few steps to
On Mar 30, 1:26 am, Simon Marlow marlo...@gmail.com wrote:
The shootout (sorry, Computer Language Benchmarks Game) ...
In a different time, in a different place, the shootout meant a football once
again flying over the cross bar or harmlessly into the arms of the keeper and
England once more
On Mon May 25 16:18:29 EDT 2009, Arnaud Payement wrote:
... I thought it is better to show Haskell as one would naturally write it.
One would naturally first write it in C ? :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote:
-snip-
You need look no further than the debian language
shootout that things
really aren't as bad as you're making out √
Haskell comes in in
general less than 3x slower than gcc compiled C.
you should look
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote:
From: Bulat Ziganshin bulat.zigans...@gmail.com
Subject: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Isaac Gouy igo...@yahoo.com
Cc: haskell-cafe@haskell.org
Date: Friday, February 20, 2009, 4:43 PM
Hello Isaac
--- Simon Brenner [EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
[EMAIL PROTECTED] wrote:
this overall test is uselles for speed comparison. afair, there are
only 2-3 programs whose speed isn't heavily depend on libraries. in
DNA test, for example, Tcl (or
--- Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Graham,
i don't think that these 3 libs allows to write high-level
high-performance code in *most* cases. just for example, try to
write wc
without using words.
To a newbie, that's a cryptic statement. Are you saying that these
--- Don Stewart [EMAIL PROTECTED] wrote:
-snip
How should the benchmarks game approach multicore?
Well, there's a famous paper,
Algorithm + Strategy = Parallelism
I'd imagine we use the benchmark game's algorithms, but let
submitters determine the strategy. Then the results
dons:
(Where I note GHC is currently in second place, though we've not
submitted any parallel programs yet).
We might call that the thread-ring effect :-)
Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout
open for business? Should we rally the troops?
iirc there was some
--- Don Stewart [EMAIL PROTECTED] wrote:
-snip-
So still consolidating the system.
Pretty much.
Do I understand though, that if we submit, say, a quad-core version
of
binary-trees, for example, using `par` and -N4, it'll go live on the
benchmark page?
That's an open question - should
--- Don Stewart [EMAIL PROTECTED] wrote:
igouy2:
Duncan Coutts wrote
Note that ghc-6.8.2 is in gentoo now and has been for a few
weeks.
There's no reason not to use it.
Cool! It shall be done!
Great. Do let us know when its available. A couple of benchmarks
will need to be
Duncan Coutts wrote
Note that ghc-6.8.2 is in gentoo now and has been for a few weeks.
There's no reason not to use it.
Cool! It shall be done!
Mea culpa - when I was considering building ghc from source I seem to
have unmerged ghc, so ghc-6.8.2 didn't show up in the portage updates.
Ketil Malde wrote:
[LOC vs gz as a program complexity metric]
Do either of those make sense as a program /complexity/ metric?
Seems to me that's reading a lot more into those measurements than we
should.
It's slightly interesting that, while we're happily opining about LOCs
and gz, no one
--- Jon Harrop [EMAIL PROTECTED] wrote:
On Friday 02 November 2007 19:03, Isaac Gouy wrote:
It's slightly interesting that, while we're happily opining about
LOCs
and gz, no one has even tried to show that switching from LOCs to
gz
made a big difference in those program bulk rankings
--- Sebastian Sylvan [EMAIL PROTECTED] wrote:
-snip-
It still tells you how much content you can see on a given amount of
vertical space.
And why would we care about that? :-)
I think the point, however, is that while LOC is not perfect, gzip is
worse.
How do you know?
Best case
--- Greg Fitzgerald [EMAIL PROTECTED] wrote:
while LOC is not perfect, gzip is worse.
the gzip change didn't significantly alter the rankings
Currently the gzip ratio of C++ to Python is 2.0, which at a glance,
wouldn't sell me on a less code argument.
a) you're looking at an average,
Donald Bruce Stewart wrote:
-snip-
I agree. Breaking the rules was mainly the reason for the drop.
Entries
like chameneos and fasta. Also, the other language teams kept
improving
things.
Yes, I missed that opportunity for listing things in threes ;-)
Over the year improved programs were
On 11/10/06, Henk-Jan van Tuyl hjgtuyl at chello.nl wrote:
Haskell suddenly dropped several places in the overall socre, when
the
size measurement changed from line-count to number-of-bytes after
gzipping. Maybe it's worth it, to study why this is; Haskell
programs
are
often much more
--- Ketil Malde [EMAIL PROTECTED] wrote:
Isaac Gouy [EMAIL PROTECTED] writes:
Programmer skill and effort really does matter ;-)
Yes, more so, than any inherent language
disadvantage, perhaps, which
happens to be the general lesson from the ICFP
contests as well. Any
idea if other
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
It seems to be number 2 at the moment.
It looks like it, all of a sudden, has one missing
benchmark. Did
something break?
Previously the GHC program was shown incorrectly as
completing regex-dna within the timeout - now it's
shown correctly.
--- Chris Kuklewicz [EMAIL PROTECTED]
wrote:
-snip,snip-
It is 3rd fastest.
Looking at Just Memory Use, Haskell is 8th
Looking at Just Lines Of Code, Haskell is 1st
Lookat at the 1:1:1 even balance Haskell is 1st
Programmer skill and effort really does matter ;-)
Congratulations.
--- Brent Fulgham [EMAIL PROTECTED] wrote:
As expected, GHC makes quite a good showing, moving
to 4th position behind ...
Rather than look at rank position look at the relative
performance (and remember that Bigloo tops ackermann
on The Sandbox).
Shootout favouring C
On 1/16/06, Daniel Fischer wrote:
Is it only my machime, or can you confirm that for
the Ackermann benchmark, it's very good for C that
they chose
9 and not a larger value?
Sebastian Sylvan [EMAIL PROTECTED] wrote:
This is interesting. Hopefully it's not
--- Brent Fulgham [EMAIL PROTECTED] wrote:
it's not such a big deal to extend the timeout (as
we have done
for spectralnorm and others), and I think it would
be
good to do so for the Ackermann test.
For ackermann, the constraint is stack-space not
run-time.
--- Daniel Fischer [EMAIL PROTECTED] wrote:
the Ackermann benchmark, it's very good for C that
they
chose 9 and not a larger value? For 10, we are
significantly faster and for 11,12,13, we can run
rings around the C-programme
homepage: understand that the faster program may
become the slower
--- Benjamin Franksen [EMAIL PROTECTED]
wrote:
What is the reason the debian/amd page lists
different program versions
than gentoo/intel page? On the former, ghc fails two
tests (downgrading
it to rank 4), whereas on the latter, it does not
and thus has rank 2.
1) Both test machines take
--- Daniel Fischer [EMAIL PROTECTED] wrote:
motive
Jealousy?
I've never used C or C++ so I probably don't mix with
enough of those guys to say, but the impression I got
was of, shall we say, 'assertive confidence'.
-snip-
and I dare say Java does suffer from that even more
than GHC
Haskell now ranked 2nd overall, only a point or so
behind C:
It was always obvious that the Write the program
as-if lines of code were not being measured clause
relied too heavily on contributors willingness to
co-operate.
http://shootout.alioth.debian.org/gp4/faq.php#implementlist
Maybe we
--- Donald Bruce Stewart [EMAIL PROTECTED] wrote:
-snip-
Ah! Just as I thought, SML really was trying very
hard ;)
Quite possibly so, but no reason to follow down that
slippery slope ;)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best
Programmers who use languages without static type
checking sometimes claim that static type checking
gives folk the false impression that once the program
passes type checking the program is correct.
That always seemed silly to me, but I'm starting to
wonder ;-)
Of course, the shootout programs
--- Aaron Denney [EMAIL PROTECTED] wrote:
Are we off-topic for this mailing-list?
I'd just like to respond to this:
Anyways, your shootout, your hard work, your rules,
but having rulings on what's acceptable be easier to
find would be nice.
People here have made the effort to develop
--- Aaron Denney [EMAIL PROTECTED] wrote:
On 2006-01-11, Chris Kuklewicz
[EMAIL PROTECTED] wrote:
Aaron Denney wrote:
The old version with the meeting place thread has
been disqualified
(along with Erlang submissions).
Is this reasoning explained and clarified anywhere,
or did they
--- Aaron Denney [EMAIL PROTECTED] wrote:
The forums there seem to be useless because...?
Because I can't find anything relevant (and I did
look). I can't even
tell where such an announcement would have been
made.
Ah! Useful for finding an announcement - maybe not.
otoh the forums do
--- Chris Kuklewicz [EMAIL PROTECTED]
wrote:
I have two strong suggestions:
* whoever does submit them should diff the output
with a previously accepted version.
-snip-
Simply diff program output with the example output
file (there's now an output file link in each problem
description).
Of
I sent a private email and the response to it has
appeared on this mailing-list, so let me just correct
some of the interpretations that have been made.
You can say that again!
Ah..sarcasm, I know that one.
No, it was emphatic agreement (the ordinary usage of
that phrase).
Is a
--- Chris Kuklewicz [EMAIL PROTECTED]
wrote:
-snip-
which is the wrong kind of CPU anyway -- they
test on an AMD system
What machine are you running the programs on?
http://shootout.alioth.debian.org/gp4/faq.php#machine
__
Yahoo! for
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
63 matches
Mail list logo
