Re: [Help-smalltalk] Language Shootout - are we doing something wrong?

[MSA or SJF]

--- Isaac Gouy <address@hidden> wrote:

> Hello again
> 
> > This is somthing of a digression, but these
> benchmarks
> > really interest me in terms of how you have to
> write
> > non-Smalltalk-style code in order to acheive
> higher
> > performance.
> 
> Caveat - I've been writing these tests in so many
> different languages
> that my programming style has turned to mush!

Well, nobody expects optimized code to look nice.

> Having said that...
>  
> > To take an example, I wrote a (deliberately) naive
> > implementation of the wc test.
> 
> See the implementations Paolo posted, his wc.gst is
> similar but avoids
> creating the subStrings.

Yes. If I remember from my own experiments, the
creation of the line strings doesn't carry anything
like the same cost as creating the word strings, which
is educational in itself. Ditto the use of
isSeparator, rather than using explicit comparisons.

Have you compared the speed of Paolo's implementation
against yours? I think it is slightly slower.

> > The core of it went something like:
> > 
> > [ | line | (line := FileStream stdin nextLine)
> notNil
> > ]
> >   whileTrue:
> >     [ lineCount := lineCount + 1.
> >     wordCount := wordCount + line subStrings size.
> >     charCount := charCount + line size. ].
> >     
> > Now, there are some issues with this, but it seems
> to
> > me that it is the most direct solution to the
> problem
> > (I would be interested to see more direct
> solutions in
> > any language).
> 
> Let's ask if this is indeed "the most direct
> solution to the problem".
> The problem does not require the creation of lines
> or words, just their
> identification and tally. 

> I can see that making objects and counting them
> might seem more
> "direct" in that we have created individuals and
> directly counted those
> individuals. However, this is just like taking
> scissors and cutting out
> lines of type from a page, and then snipping those
> lines into words,
> and then counting the resulting scraps of paper.

> The "most direct solution" to counting lines and
> words is to scan the
> text without creating the individual scraps of
> paper. 

But can you see that your analogy is based around the
understanding that creating the Strings has a cost?
What if the comparison was between reading the words
and counting them? There isn't a lot of difference in
the speed you can do that.

(in fact, I would say that it is quicker to read them,
but having read them, you can't easily say how many
there were, so my analogy breaks down, but you take my
point, I hope)

> The direct-manipulation solution to counting lines
> and words is to
> create objects for lines and words, and then count
> them.
> 
> > What it is not is fast (my shot in the dark is
> that it
> > has to instantiate a LOT of Strings, some of which
> are
> > not even used).
> 
> Well, none of them are used. They are created to be
> counted and we can
> count them without creating them :-)

Just to be pedantic about it, in my solution, the
Strings for the lines are used. Same in Paolo's
solution.

But, more to the point, if #subStrings created a
Collection that lazily instantiates the Strings it
contains, then it too could answer #size without
instantiating Strings.

> > The approach that you posted which
> > scans character by character is significantly
> faster,
> > but in style it's much more procedural, and it
> seems
> > to me that the more procedural it gets, the less
> point
> > there is in it being Smalltalk. 
> 
> The problem *is* a procedural micro-benchmark. 
> 
> How much point is there in
> SortedCollection>>quickSort:to: being
> Smalltalk?

> > Now, the OO rhetoric would say that, as
> developers, we
> > should not need to be aware of the underlying
> > implementations, but if we are interested in
> speed,
> > then we clearly need to be. So my question is, how
> > could we stay at a high level, and still keep the
> > speed?
> 
> So much for the OO rhetoric! Algorithms matter!

Certainly they do, but who is going to decide which
algorithm to use?

Did you come across the idea that JIT compilers can
be, in theory and in practice, faster than
hand-optimised code, because they can take advantage
of the actual data structures, rather than having to
make an assumption in advance?

If you've coded your algorithms explicitly, then
you've precluded the possibility of making such
optimisations at the next level up.

> Provide a high level interface to efficient
> algorithms, for example:   
> 
>    SequenceableCollectionSorter on: aCollection

Regards, 

Mike






                
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail