[Shootout-list] Directions of various benchmarks

John Skaller skaller@users.sourceforge.net
Fri, 20 May 2005 01:52:46 +1000


On Thu, 2005-05-19 at 12:20 +0200, Bengt Kleberg wrote:

> concurrency is often a result of designing with async interaction in 
> mind. this is rarely possible to have in a small benchmark test of the 
> kind used in the shootout. since i still want to see how other languages 
> handle concurrency i think it is a worthwhile addition to the shootout.

Yes, but someone will need at minimum a dual core CPU. AMD64 will have
one later this year. Known in advance Ocaml is going to suffer badly,
it can't handle concurrent threading.

> 
> ...deleted interesting info about felix
> 
> > Example. Suppose you want to say 'sort this file using
> > a bubble sort'. Do it 'the same way' at the algorithmic level.
> > 
> > Well you CANNOT sanely require that. So, what you require instead
> > is 'sort this array with less than 5 lines of code without allocating
> > more than a constant amount of memory'.
> 
> i am not saying that you are wrong here. but i am not able to understand 
> why bubble sort is not a sane requirement.

Because it is an algorithm specified in terms of loops and
arrays and variables .. that is, one where you might judge
a procedural program implements it, but a functional language
without variables and arrays, or, worse, a logic programming 
language like Mercury or Prolog .. algorithms are nonsense
in a declarative language.

This is an 'extreme' view, to be taken with a grain of salt,
BUT, in more complex tests or more difficult to specify
features, such as 'regular expression' or 'thread' or
'concurrent' or 'exception handling' or ... it becomes highly
problematic whether code is acceptable or not.

>From my point of view this is extremely serious because I really
don't know if a particular encoding I might submit is fair
or not. 


-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net