Sorry Bryan, there are a couple of comments I should make a final reply to -
I'll ignore the rest.
> From: Richard O'Keefe
> 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 increasingly as t
> From: wren ng thornton
> 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 Smalltalk.
I ha
> From: Richard O'Keefe
> 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 unicode?
-snip-
> 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.
&g
> From: Stephen Tetley
> 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 wrote:
>
>> I fail to see how the GUI part would suffer from lack of performance if the
>> rest of the system is fine. I would hate to b
> From: Richard O'Keefe
> 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
>>> rea
> From: wren ng thornton
> 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
> built-in
- Original Message -
> From: "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 the permu
- Original Message -
> From: Richard O'Keefe
> 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 DIFFERENCE BETWEEN
> From: Gregg Lebovitz
> 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 thank you for y
Too obvious to be interesting.
Interesting that you haven't said how you know 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
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?
__
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 somewhe
--- On Fri, 8/12/11, austin seipp wrote:
Thanks, I do like easy fixes :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
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=meteor&lang=ghc&id=5#log
- regex-dna #2 - Precedence parsing error
http://sho
--- On Wed, 6/9/10, Don Stewart 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 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 accessible to those languag
--- On Thu, 6/10/10, Don Stewart wrote:
> From: Don Stewart
> Subject: Re: [Haskell-cafe] Problems with threading?
> To: "Isaac Gouy"
> Cc: "Louis Wasserman" , "Haskell Café List"
>
> Date: Thursday, June 10, 2010, 12:54 PM
> igouy2:
&
--- On Thu, 6/10/10, Don Stewart wrote:
> From: Don Stewart
> Subject: Re: [Haskell-cafe] Problems with threading?
> To: "Louis Wasserman"
> Cc: igo...@yahoo.com, "Haskell Café List"
> Date: Thursday, June 10, 2010, 11:36 AM
> wasserman.louis:
> >
> > There are 4 sets of "rankings"
> so
--- On Thu, 6/10/10, Louis Wasserman 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=threadring&lang=ghc&id=3
> Yes, but Haskell used to be doing much better specifically on the u64q,
> which wa
--- On Thu, 6/10/10, Louis Wasserman 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 accessible to those langua
--- On Mon, 6/7/10, Don Stewart wrote:
> From: Don Stewart
> Subject: Re: [Haskell-cafe] Problems with threading?
> To: "Isaac Gouy"
> Cc: "Louis Wasserman" , "Haskell Café List"
>
> Date: Monday, June 7, 2010, 4:43 PM
> igouy2:
> > A
--- On Mon, 6/7/10, Don Stewart wrote:
> From: Don Stewart
> Subject: Re: [Haskell-cafe] Problems with threading?
> To: "Louis Wasserman"
> Cc: "Haskell Café List"
> Date: Monday, June 7, 2010, 2:50 PM
> wasserman.louis:
> > While working on the Shootout, I noticed the following
> benchmarks
On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach 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
> make
Ketil Malde 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 more idiomatic code?
On Mar 30, 1:26 am, Simon Marlow 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 exiting an intern
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
http://w
--- On Fri, 2/20/09, Bulat Ziganshin wrote:
> From: Bulat Ziganshin
> Subject: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
> To: "Isaac Gouy"
> Cc: haskell-cafe@haskell.org
> Date: Friday, February 20, 2009, 4:43 PM
> Hello Isaac,
>
> Saturday, Februa
--- On Fri, 2/20/09, Bulat Ziganshin 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 inside these tests, a
--- 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 say
--- 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, T
--- 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 re
--- 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 -
> 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 som
--- 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 benchmar
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.
--- 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 a
--- 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
--- 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
> > m
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
On Jul 15, 1:25 pm, "Hugh Perkins" <[EMAIL PROTECTED]> wrote:
> > or maybe 'pidigits', a lazy pi generator,
> This is I/O bound, which isnt interesting, unless you really want to
> benchmark I/O to console?
a) output is redirected to /dev/null - read the FAQ
b) the I/O is cheap
delete
PiDi
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 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 compact then
--- 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 co
--- 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 fr
--- 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).
http://shootout.alioth.debian.org/sandbox/f
--- 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
--- 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 machine
--- 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
--- 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.
__
> > 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'
--- 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 bes
> 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 w
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 a
--- 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 pr
--- 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 f
--- 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
--- 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).
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 perse
--- Isaac Gouy <[EMAIL PROTECTED]> wrote:
> We'll be happy to also show a Haskell program that
> uses Data.HashTable - first, someone needs to
> contribute that program.
Someone did: k-nucleotide Haskell GHC #2
http://shootout.alioth.debian.org/gp4/benchmark.php?test=
--- 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!
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 altern
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
http
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 othe
65 matches
Mail list logo
