On Fri, Sep 10, 2010 at 3:06 PM, Isaac Gouy wrote:
> So what are we to do when there's a problem that has "no acceptable
> elegant Haskell form"?
Depending on the intend, for you benchmark program, write something
like what it is now.
For real life cases, call an exnternal library, use another la
On Sep 10, 2:22 pm, gary ng wrote:
-snip-
> My initial comment was all about 'it seems that Haskell submission is
> not the typical elegant form' and to me because of the specific you
> want to measure, there is no acceptable elegant Haskell form.
So what are we to do when there's a problem tha
On Fri, Sep 10, 2010 at 2:04 PM, Isaac Gouy wrote:
> It's starting to look like actually there was a point you wanted to
> make ;-)
You mean the 'no chice' part ? yes.
You mean the why not Data.Hashtable comment ? I don't think so.
>
> If you change the requirement to something else you'd simpl
On Sep 10, 11:54 am, gary ng wrote:
> On Fri, Sep 10, 2010 at 11:13 AM, Isaac Gouy wrote:
> > Clearly, they did choose "to write all that code" "in order to get a
> > much faster program" - I can't tell you if Andy had noticed the
> > benchmark was about "Hashtable update and k-nucleotide strin
On Fri, Sep 10, 2010 at 11:13 AM, Isaac Gouy wrote:
> Clearly, they did choose "to write all that code" "in order to get a
> much faster program" - I can't tell you if Andy had noticed the
> benchmark was about "Hashtable update and k-nucleotide strings" or
> whether he knew about Data.HashTable.
On Sep 10, 10:35 am, gary ng wrote:
> On Fri, Sep 10, 2010 at 8:49 AM, Isaac Gouy wrote:
> >> Huh ? point ? it was just a casual comment, no point was intended. And
> >> I have read some comments by Don that what is in the shoutout is way
> >> faster than Data.HashTable
>
> > If you knew there
On Fri, Sep 10, 2010 at 8:49 AM, Isaac Gouy wrote:
>> Huh ? point ? it was just a casual comment, no point was intended. And
>> I have read some comments by Don that what is in the shoutout is way
>> faster than Data.HashTable
>
>
> If you knew there was another option why write "I doubt there is
On Sep 9, 10:15 pm, gary ng wrote:
> On Thu, Sep 9, 2010 at 10:04 PM, Isaac Gouy wrote:
> > Is there any point speculating about this as outsiders?
>
> > It was available - Data.HashTable seems to be copyright 2003.
>
> >http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data
>
On Thu, Sep 9, 2010 at 10:04 PM, Isaac Gouy wrote:
> Is there any point speculating about this as outsiders?
>
> It was available - Data.HashTable seems to be copyright 2003.
>
> http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data.HashTable
Huh ? point ? it was just a casual comm
On Sep 9, 7:19 pm, gary ng wrote:
> On Thu, Sep 9, 2010 at 7:02 PM, Isaac Gouy wrote:
> > iirc the Haskell programs, and the Clean programs, and the Pascal
> > programs, and ... use translations of the simple hash table used by
> > the C programs.
>
> > If I ever knew, I don't recall why the Ha
On Thu, Sep 9, 2010 at 7:02 PM, Isaac Gouy wrote:
> iirc the Haskell programs, and the Clean programs, and the Pascal
> programs, and ... use translations of the simple hash table used by
> the C programs.
>
> If I ever knew, I don't recall why the Haskell program does not use
> Data.HashTable
>
C
On Sep 9, 6:06 pm, gary ng wrote:
> On Thu, Sep 2, 2010 at 6:07 PM, John Fingerhut
> wrote:
> > Some of the Haskell submissions are quite long for what they do. The
> > k-nucleotide one, for example, implements a mutable hash table using
> > features in Haskell that I had never seen before lo
On Thu, Sep 2, 2010 at 6:07 PM, John Fingerhut wrote:
> Some of the Haskell submissions are quite long for what they do. The
> k-nucleotide one, for example, implements a mutable hash table using
> features in Haskell that I had never seen before looking at that program.
> Did they need to write
On Sep 2, 4:51 pm, Isaac Gouy wrote:
> On Sep 1, 9:46 pm, John Fingerhut wrote:
>
> > Thanks to many people on this list in Aug 2009 who helped improve my code,
> > to Johannes Friestad for writing a nice fast Clojure program using deftype
> > for the n-body problem, to Isaac Gouy for setting u
I've got about 5 to 10 Clojure programs I've written for each of the 5
benchmark programs (many of which are only minor variations of each other,
looking for ways to make it faster). If you care to see any of the others,
they are on github here:
http://github.com/jafingerhut/clojure-benchmarks
T
On Sep 2, 5:28 pm, Sean Corfield wrote:
> On Wed, Sep 1, 2010 at 9:46 PM, John Fingerhut
> wrote:
> > You can see a brief summary of results comparing
> > run time, memory, and code size against "Java 6 -server" here:
> >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo...
>
>
On Wed, Sep 1, 2010 at 9:46 PM, John Fingerhut wrote:
> You can see a brief summary of results comparing
> run time, memory, and code size against "Java 6 -server" here:
> http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=clojure&lang2=java
Very interesting. Clojure is faster than
On Sep 1, 9:46 pm, John Fingerhut wrote:
> Thanks to many people on this list in Aug 2009 who helped improve my code,
> to Johannes Friestad for writing a nice fast Clojure program using deftype
> for the n-body problem, to Isaac Gouy for setting up the shootout web site
> to accept Clojure subm
Thanks to many people on this list in Aug 2009 who helped improve my code,
to Johannes Friestad for writing a nice fast Clojure program using deftype
for the n-body problem, to Isaac Gouy for setting up the shootout web site
to accept Clojure submissions, and to my having more time than good sense
On Aug 26, 8:37 am, John Fingerhut wrote:
> I have now submitted small modifications that permit AOT compilation. The
> compile time was small -- on the order of 1 to 2 sec of the total CPU time,
> which is often a small percentage of the long runs that are reported on the
> shootout web site.
I have now submitted small modifications that permit AOT compilation. The
compile time was small -- on the order of 1 to 2 sec of the total CPU time,
which is often a small percentage of the long runs that are reported on the
shootout web site.
But of course it is better if it is not included in
On Aug 26, 12:26 am, Meikel Brandmeyer wrote:
> Hi,
>
> On 26 Aug., 07:58, Isaac Gouy wrote:
>
> > Have you actually measured the time difference?
If you have measured the time difference with/without AOT compilation
then apparently you don't wish to share those measurements. Oh well.
Witho
Hi,
On 26 Aug., 07:58, Isaac Gouy wrote:
> Have you actually measured the time difference?
Compare the mandelbrot numbers for Haskell, Java and Scala. The ranges
are (0.07s 0.86s 13s), (0.19s 0.86s 12s), (0.22s 0.97s 15s). So Java
and Scala are not slower than Haskell, but the low iteration num
On Aug 25, 10:31 pm, Meikel Brandmeyer wrote:
> Hi,
>
> On 26 Aug., 05:37, Isaac Gouy wrote:
>
> > 1) The command line requested for these first programs doesn't AOT
> > compile so the measured time includes compiling the program.
>
> Which makes the comparison of languages with this benchmark
Hi,
On 26 Aug., 05:37, Isaac Gouy wrote:
> 1) The command line requested for these first programs doesn't AOT
> compile so the measured time includes compiling the program.
Which makes the comparison of languages with this benchmark even more
uninteresting.
> Perhaps AOT compilation is an usua
On Aug 25, 6:17 am, John Fingerhut wrote:
> I will try submitting one or a few of my benchmark programs created 1 year
> ago.
>
> For anyone that wants to look at some timing results and/or my source code
> used to achieve them before then, they are available on github here:
>
> http://github.co
You can probably boost n-body on 1.2 by replacing arrays with deftypes.
(definterface BodyIsh
(^double getMass [])
(setMass [^double x])
(^double getPosX [])
.)
(deftype Body [^double ^{:unsynchronized-mutable true} mass ^double
^{:unsynchronized-mutable true} posX .]
BodyIsh
I will try submitting one or a few of my benchmark programs created 1 year
ago.
For anyone that wants to look at some timing results and/or my source code
used to achieve them before then, they are available on github here:
http://github.com/jafingerhut/clojure-benchmarks
I just pushed a few cha
On Aug 24, 7:48 pm, ataggart wrote:
> Thanks for focusing solely on one example, and still not providing any
> useful, specific information.
You asked - "Do I really need to perform the itemCheck math ops in
the binary-tree test" - and if you can't see the answer from simply
looking at the ot
Thanks for focusing solely on one example, and still not providing any
useful, specific information.
There may be a number of possible implementations for a given design
criterion. The binary-tree "memory allocation/deallocation" test (for
example) includes not only that, but also math ops, in a p
On Aug 24, 9:50 am, ataggart wrote:
> It would have been more useful to answer the question (particularly
> with regards to a canonical implementation) than getting all passive-
> aggressive.
Did you find any programs that didn't perform itemCheck?
In Clojure does one integer addition and one
On Aug 24, 9:58 am, Nicolas Oury wrote:
> On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote:
>
> > Well when Clojure 1.3 is released...
>
> > The phrase "idiomatic code" often seems to be used to mean - code
> > written in a natural way for that language and as if performance
> > doesn't matter
On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote:
>
> Well when Clojure 1.3 is released...
>
> The phrase "idiomatic code" often seems to be used to mean - code
> written in a natural way for that language and as if performance
> doesn't matter - whereas I seem to have the strange notion that bot
>>> Clojure 1.3's performance improvements will significantly impact perf on
>>> some of the benchmarks. If you are trying these out, please try them on
>>> both 1.2 and 1.3.
>>
>>
>> Has Clojure 1.3 been released?
>>
>
> No, but since the num/prim/equiv work specifically targets performance, we
It would have been more useful to answer the question (particularly
with regards to a canonical implementation) than getting all passive-
aggressive.
On Aug 24, 5:55 am, Isaac Gouy wrote:
> On Aug 23, 7:07 pm, ataggart wrote:
>
> > It's never been clear to me exactly what the code is supposed
On Tue, Aug 24, 2010 at 12:33 PM, Isaac Gouy wrote:
> The phrase "idiomatic code" often seems to be used to mean - code
> written in a natural way for that language and as if performance
> doesn't matter - whereas I seem to have the strange notion that both
> code written as if performance matter
On Aug 24, 8:48 am, Stuart Halloway wrote:
> > On Aug 24, 6:44 am, Stuart Halloway wrote:
> >> Clojure 1.3's performance improvements will significantly impact perf on
> >> some of the benchmarks. If you are trying these out, please try them on
> >> both 1.2 and 1.3.
>
> > Has Clojure 1.3 bee
> On Aug 24, 6:44 am, Stuart Halloway wrote:
>> Clojure 1.3's performance improvements will significantly impact perf on
>> some of the benchmarks. If you are trying these out, please try them on both
>> 1.2 and 1.3.
>
>
> Has Clojure 1.3 been released?
>
No, but since the num/prim/equiv wor
On Tue, Aug 24, 2010 at 10:30 AM, Isaac Gouy wrote:
> Has Clojure 1.3 been released?
>
Nope.
> If you choose to throw idioms and readability out the window then
> don't be surprised at the comments that will be made about Clojure.
>
Clojure doesn't encourage mutable state. Most of the benchma
On Aug 24, 6:44 am, Stuart Halloway wrote:
> Clojure 1.3's performance improvements will significantly impact perf on some
> of the benchmarks. If you are trying these out, please try them on both 1.2
> and 1.3.
Has Clojure 1.3 been released?
> Also: the benchmarks are totally a numbers ga
Clojure 1.3's performance improvements will significantly impact perf on some
of the benchmarks. If you are trying these out, please try them on both 1.2 and
1.3.
Also: the benchmarks are totally a numbers game: throw idioms and readability
out the window. Clojure 1.3 should be able to match Ja
On Aug 23, 7:35 pm, Robert McIntyre wrote:
> I hear you --- I got excited about this too, and implemented the fannuchredux
> algorithm, only to be thwarted by an undocumented "checksum" each
> program is also
> supposed to calculate. This checksum depends heavily on the exact
> order in which
>
On Aug 23, 7:07 pm, ataggart wrote:
> It's never been clear to me exactly what the code is supposed to be
> do. For example, the "spec" for the binary-tree test is so wholly
> lacking in any details that I'm left to infer that one is supposed to
> copy an implementation used previously, though w
I hear you --- I got excited about this too, and implemented the fannuchredux
algorithm, only to be thwarted by an undocumented "checksum" each
program is also
supposed to calculate. This checksum depends heavily on the exact
order in which
a set of permutations are traversed. And of course, they
It's never been clear to me exactly what the code is supposed to be
do. For example, the "spec" for the binary-tree test is so wholly
lacking in any details that I'm left to infer that one is supposed to
copy an implementation used previously, though without any indication
as to which is the canoni
Now Clojure 1.2 has been released, Clojure programs will be included
in the Computer Language Benchmarks Game.
If you'd like to contribute Clojure programs, please follow the step-
by-step
http://shootout.alioth.debian.org/help.php#contribute
--
You received this message because you are subscri
46 matches
Mail list logo
