>> I'd
>> 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 
> coding,
> I would still do it. (Though, at that small amount, you are optimising 
> the
> wrong thing! Or, there is nothing else left to optimise =)

But you need to keep complexity Vs. benefit in a good relation. If we 
get
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 
picked
up by the community. It's not a trvial piece of software. From my part, 
it
was more like "hundreds of hours of C coding" then 20 hours of 
Smalltalk...

Debugging dynamically generated machine code is an interesting 
experience,
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 
>>> to
>>> 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 
> naive
> 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, 
FloatArrays...lots
of stuff.

>>> 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 
> build
> 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 
would make
using it for a project would make sense.

Have you thought about analysing your application for hot-spots and 
code those
as a plugin?

[AOStA]
> Oh, what does this mean? No projects or application where its benefits 
> and
> 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 
real optimizations...
It's an experiment, and not yet (likely never) finished. Nobody is 
working on it right now, I think.

       Marcus