> From: Gregg Lebovitz <glebov...@gmail.com> > Sent: Wednesday, May 16, 2012 12:02 PM
> I was looking at the debian coding contest benchmarks referenced by others in > this discussion. "debian coding contest" ? It's been called many things but, until now, not that. > All of the benchmarks algorithms, appear to be short > computationally intensive programs with a fairly low level of abstraction. Tiny tiny toy programs - more or less 100 lines - not quite small enough to be microbenchmarks. Why might that be? Well, not IO bound. Do people usually mean IO performance when they compare programming languages? (I guess you must have excluded meteor-contest from your consideration. It's a coding contest and so doesn't specify an algorithm.) > In almost all examples, the requirement says: you must implement the X > functions > as implemented in Java, or C#, or C++. binary-trees - No, it doesn't say that. thread-ring - No. chameneos-redux - No. pidigits - No. regex-dna - No. k-nucleotide - No. mandelbrot - No. reverse-complement - No. spectral-norm - "Each program must implement 4 separate functions / procedures / methods like the C# program." (The point being cross function calling so don't amalgamate 4 functions into a single function.) fasta-redux - No. fasta - No. meteor-contest - No. fannkuch-redux - "defined by programs in Performing Lisp Analysis of the FANNKUCH Benchmark" n-body - "Each program should model the orbits of Jovian planets, using the same simple symplectic-integrator - see the Java program." > The k-nucleotide even specifies a requirement to use an update a hash-table. Probably not too onerous a requirement for a test of hash table lookup :-) Some people like hash tables, go figure. http://gregorycollins.net/posts/2011/06/11/announcing-hashtables -snip- > Interesting that you would focus on this one comment in my post and not > comment > on one on countering the benchmarks with a new criteria for comparing > languages. 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 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? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
