[Newcompiler] Closure with push and store bytecode

Marcus Denker denker at iam.unibe.ch
Sun Apr 29 08:22:33 UTC 2007


On 28.04.2007, at 23:38, <bryce at kampjes.demon.co.uk>  
<bryce at kampjes.demon.co.uk> wrote:

>
>
> I doubt that the current set would be acceptable for the mainstream
> VM. I'd like to see a suitable bytecode set developed but I'm not sure
> if now is the right time.

Yes... adding bytecodes will be tricky. And the urge will be high to
say "if, then for real", that is, make a new complete bytecode set
that e.g. does not have artificial upper bounds for everything (jumps,
number of ivars, number of lits, number of temps) and is more regular,
leading to better performance.

On the other hand, there is a tendency in Squeak to do nothing "because
there is a better way to do it". That is, we postpone it to be done with
all the other things that we did not do in 10 (!!!) years. "This will  
be done V4".
ROTFL.

It would be so funny if it would not be so sad, this whole Squeak thing.

The question is if this image-backward-compatibility religion really  
payed
so much back than it cost us. And I am very sceptical about that.

>
> Marcus: What performance goals does the closure compiler need to meet
> now? Or how fast does it need to be before other goals matter more?
> And generally how cheap is it to change the bytecode set 2)?  The only
> answer that really matters is, is performance a current major issue?
>

My personal performance goal is to have "real work macro" benchmarks
to be less then 10% slower. But that we have already, e.g. the 10- 
Browser-bench
is 6% slower on my machine on a full-block-image.

	Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3947 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/newcompiler/attachments/20070429/f2ed5e4b/smime-0001.bin


More information about the Newcompiler mailing list