[Shootout-list] Re: Coding For Speed

[Robert Seeger]

See comments below:


On Sun, 27 Mar 2005 07:57:16 -0800 (PST), Isaac Gouy <igouy2@yahoo.com> wrote:
> --- Robert Seeger <rhseeger@gmail.com> wrote:
> > No, but it does claim to be a way to differentiate between the speed
> > and capabilities of different languages.
> 
> (The speed of vaguely comparable programs written in different
> languages.)
> 
> Let me know where the website claims to differentiate between the
> "capabilities" of different languages - I obviously need to remove
> that!

It was my assumption that, given that a number of the tests are
capability based (ackermann, object tests, network tests), that the
Shootout was showing what languages have what capabilities, as well as
how fast (and easy to use) those features are. Given your comments,
I'll assume I was incorrect on this. My apologies.


> > When looking at a test for which a given language performs poorly, I
> > think it would be useful to see answers to questions like:
> > * Is this just a failing of the language? or,
> > * What approach DOES work in this language for solving this type of
> > problem?
> 
> It would be useful to see answers to questions like:
> * Is this just a failing of the programmer?

If its a failing of the programmer, then one would hope another
programmer would come along and redo the code to overcome that
failing. Not always the case of course, but I tend to think it's the
ideal.


> Are you offering to provide analysis for all the programs on the
> Shootout?
> 
> There are a host of interesting/useful things that *could* be done. We
> don't even have the resources to complete and maintain the current
> very-limited Shootout.

Fair enough. If I can ask though, what is the point of the alternate
submission section of tests? I was under the impression it was for
"this doesn't follow the rules, but it might be how you implement
something like this in the real world".


> > Unicode is another example of this. I know there's not currently a
> > test for it, but... There are a lot of languages that currently just
> > can't do Unicode, or do it poorly or incorrectly. However, by using a
> > commonly available external library, they can work with it just fine.
> 
> So we have a Lua program using library U and a Tcl program using the
> same library U, what exactly would we be comparing - FFI? (That might
> be interesting for one benchmark.)

We're not comparing anything. I was referring to the alternate
submissions section. As I mentioned, I was thinking of that section as
a "this is how you might want to do it, for a given language, in the
real world, for various reasons (maintainability, speed, etc)". Using
Perl/CPAN as an example, its common practice (I think) to use C-level
APIs with a Perl wrapper to do things that require lots of speed. An
alternate submission in Perl that used such a CPAN package would show
that, although the valid shootout submission isn't a speed demon, it
is possible to easily get the speed needed when doing this type of
thing.

> Sebastien Loisel posted about the problems he saw in the numeric
> benchmarks on Shootout. And he posted his proposal for better numeric
> benchmarks. And he provided implementations in 3 quite different
> languages. He complained about a problem AND he provided a solution. A
> couple of days later The Sandbox has an alpha version of his proposal.
> 
> Things change when people provide solutions - not when they raise
> problems.

I didn't mean to propose there was a problem with anything. If I gave
that impression, you have my apologies. I was merely trying to put
forth a suggestion that might make the information on the Shootout
that much more useful to the visitors of the page. If that suggestion
would require too much work (and it would require more work, since
there would likely be more in the way of alternate submissions), then
I understand the reluctance.

Rob Seeger