Adding loop primitives/optimizations
denker at iam.unibe.ch
Fri Dec 3 08:50:51 UTC 2004
>> guess that my System today is faster then the Jit based one of 2001.
> These are tested on the same system?
No. 2001 it was a 450PowerMacG4, Today: PowerBook1.5Ghz.
> I'm not sure I can agree with anyone
> hinting that any beneficial change is not worth it. If there was a 0.1%
> speedup for the entire system achievable with 20 hours of Smalltalk
> I would still do it. (Though, at that small amount, you are optimising
> wrong thing! Or, there is nothing else left to optimise =)
But you need to keep complexity Vs. benefit in a good relation. If we
in the end only 2times speedup with J3, but J3 turns out not to be not
maintainable by the community, we have a problem.
And it turned out that this happened: J3 was there, but it was not
up by the community. It's not a trvial piece of software. From my part,
was more like "hundreds of hours of C coding" then 20 hours of
Debugging dynamically generated machine code is an interesting
though. Especially on MacOS9.
Am 03.12.2004 um 02:41 schrieb Lyndon Tremblay:
>>> This is because Squeak was carefully optimized to run primitives most
>>> of the time.
>>> And then, as Tim pointed out, even if the Jit can optimize the code
>>> run in zero
>>> seconds, you will only see the perfomance doubled when the system
>>> spends 50%
>>> of the time in the primitives.
> Ahh, I understand. Are most of these Interpreter primitives? I'll be
> and think from the historical documents that ObjectMemory,
> Interpreter, and
> BitBlt are the main 'primitive objects' for the VM itself.
Lots of other stuff: There are primitives for LargeInts, Sound,
>>> Speaking about runtime compilers for Squeak, there are two other
>>> projects: Exupery by Bruce Kampjes, a
>>> runtime translator that is written in Squeak, not C++. This is on
>>> SqueakMap. Bruce has reported
>>> some good speedup already.
> Unfortunately for Win32 builders, it does require 'struct foo' for
> it's VM
> changes. I can again look into the VM here when I get a decent custom
> worth comparing with the official - I will probably actually use
> Exupery for
> my project.
I may be mistaken, but I don't think that Exupery is in a state that
using it for a project would make sense.
Have you thought about analysing your application for hot-spots and
as a plugin?
> Oh, what does this mean? No projects or application where its benefits
> changes prove completely useful? I am still highly interested in the
> optimisation of Squeak.
That it never got to a point were it actually did run the image, or did
It's an experiment, and not yet (likely never) finished. Nobody is
working on it right now, I think.
More information about the Squeak-dev