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
squeak-dev@lists.squeakfoundation.org