>To:  	
>Reality speed check. etc.

Andreas Raab wrote:

>Geesh. This "benchmark" is as bogus as it gets.

I think you are out of line here.  First I’m more on
you side than not. A fifty percent performance
degradation is a pretty good argument for change.

Second I only claimed it to be a little test, which it
is. I never claimed it to be a  “benchmark”.

Third it is useful not bogus to do these tests. You
are not trying to convince me. I’ve yet to get my
major contributions into squeak. You need to convince
people like Diego who have the energy and the chops to
change “== nil” to “isNil” (in time critical inner
loop code). And add 500 “translate:” messages to the
image.


>Try it with 
>polymorphic receivers (say more than 3 different ones
to kill the cache 
>performance for a change).

Cool. Suggest the code for this. The try it yourself
tests are what will convince the others to go along
with your argument.

>Seriously, benchmarks should be defined by 
>people who understand what they are measuring.

Happy to see them do it. How do we convince them to
make the time?

Besides, my curiosity is not to teach myself to run
canned bench marks. My curiosity is why is squeak now
slower than it used to be and what needs to be changed
to speed it back up.

>My comparison was based on the fact that the
microbenchmarks

And these microbench marks are where? and runnable
how?

>show that 
>*on average* the difference between bytecodes and
sends is roughly 1:30. 
>On *average* mind you, not on a totally bogus, 
>send-the-same-message-to-the-same-object-with-guaranteed-cache-hit

>"benchmark".
>
>And besides, system performance has very little to do
with these 
>micro-benchmarks anyway

So, HOW do we find and address the critical
bottlenecks to good system performance?

>I don't buy *any* of those points made about 
>how horrible it is that we aren't aware about how
much time we "waste" 
>when sending a message instead of utilizing a
bytecode.

Whoa. Then what was your point about bytecodes vs.
sends being 1:30?
To improve (or accept) the speed of squeak (or tweak)
what should we focusing on?
How should we measure it?
>
>Let's stop this pointless discussion, shall we?

I don’t see how the discussion is pointless. Squeak to
be useful to as many as possible needs to run at an
acceptable speed on as many machines as possible. The
speed degradation as the versions progress has to be
tracked.

And the opportunity to work on squeak has to be
extended as widely as possible.

You Mr. Raab are a warhorse. Your knowledge of what
goes on in the internals of squeak may be unsurpassed.
You may have forgotten how much time you’ve dedicated
to getting that knowledge. You also have a warhorse’s
work load on your plate. It will take a good deal of
your future time and dedication to achieve what you’ve
set out to achieve with tweak. Some of the work on the
projects you’ve left behind will have to be left to
others. We can not be expected to have all of your
experience or acumen. Still we have our uses and our
efforts are needed if squeak is to be maintained and
improved.

Personally, I have read your code and I have found
your bugs. I have a good knowledge of the quality and
quantity of your work. I have been impressed by it and
I have seen its limitations. I respect your knowledge
and your fire and dedication for good code and a
useful squeak environment. I hope you will learn to
respect my ability to make useful contributions to the
projects you have cared about.



Take up your task of teaching and explaining
cheerfully. Be patient with those of us who don’t know
all that you know. You were once in this position
yourself. How did you learn? 

  
Cheers and joy, --Jerome Peace

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com