VM Changes in D6

My curiosity seems to be not depleted yet. :-)

Will D6 VM include any new addition, modification or removal
compared with D5 VM?

Best regards.

Esteban,

> Will D6 VM include any new addition, modification or removal compared
> with D5 VM?

Offhand the major changes are:

1) Full block closures
2) Improved GC resulting in a 10-20% speed improvement.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> 1) Full block closures

Slick!


> 2) Improved GC resulting in a 10-20% speed improvement.

See, Smalltalkers just don't get it.  Everybody knows that software is
supposed to get slooooOOOOWWWer over time :)  Nice work!!!!

Returning to the serious, is there an impact from closures?  Which way,
and is the 10-20% a net on top of that?  IIRC, you were planning to have
various types of blocks to limit any performance penalty to the blocks
that needed it??  Or are they a good thing all around?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > 2) Improved GC resulting in a 10-20% speed improvement.

> Returning to the serious, is there an impact from closures?  Which
> way, and is the 10-20% a net on top of that?  IIRC, you were planning
> to have various types of blocks to limit any performance penalty to
> the blocks that needed it??  Or are they a good thing all around?

Well, of course, it depends on what you're doing. I've attached a
comparison of the STIC benchmarks between D51 and D6. Notice that
pretty much everything is better in D6 apart from the alloc test.

The improvements will be partly due to GC and partly due to the block
closures. So-called "clean" blocks will speed up block operations
considerably. The GC improvements are to do with the incremental
collection of garbage and result in the much improved message send
times (as illustrated by the Towers of Hanoi benchmark).

The slighly worse peformance of alloc (and the Floating Math which is
very dependent on alloc times) are a trade-off caused by the new GC
algorithm.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> The improvements will be partly due to GC and partly due to the block
> closures. So-called "clean" blocks will speed up block operations
> considerably. The GC improvements are to do with the incremental
> collection of garbage and result in the much improved message send
> times (as illustrated by the Towers of Hanoi benchmark).

I'm looking forward to this, but in the meantime -- on the off-chance that you
or Blair have the time -- I'd /love/ to know how GC improvements can interact
with message send time.

BTW, do the GC changes involve any memory layout changes that I should fold
back into the calculations in 'Space Breakdown' ?

    -- chris

Andy Bower escribió:
>>>2) Improved GC resulting in a 10-20% speed improvement.
>>Returning to the serious, is there an impact from closures?  Which
>>way, and is the 10-20% a net on top of that?  

> Well, of course, it depends on what you're doing. I've attached a
> comparison of the STIC benchmarks between D51 and D6. Notice that
> pretty much everything is better in D6 apart from the alloc test.

How to read that piece of data?

Best regards.

--
Esteban

I will take a look

"Andy Bower" <[hidden email]> escribió en el mensaje
news:[hidden email]...

Sorry, don't read

"Osvaldo Aufiero" <[hidden email]> escribió en el mensaje
news:[hidden email]...

> The slighly worse peformance of alloc (and the Floating Math which is
> very dependent on alloc times) are a trade-off caused by the new GC
> algorithm.

Most of my run-time bottlenecks are in these two areas.  Is this situation
likely to change in the near future?


Shaping

"Shaping" <[hidden email]> wrote in message
news:[hidden email]...
>> The slighly worse peformance of alloc (and the Floating Math which is
>> very dependent on alloc times) are a trade-off caused by the new GC
>> algorithm.
>
> Most of my run-time bottlenecks are in these two areas.  Is this situation
> likely to change in the near future?
>

In a word, no. The allocation of small objects such as Floats could not
really have been much faster than it was in D5, hence it slowing down
slightly in D6. On the whole though this allocation slowdown is only
measurable in micro-benchmarking, and it will be insignificant compared to
the gains in overall computation speed on a more macro scale. The issue is
really that FP arithmetic involves the allocation of an object to hold the
result. This has a number of implications - first there is the cost of that
allocation (and perhaps more importantly the cost associated with collecting
that memory later), and secondly it means that intermediate FP results are
being pulled off and pushed onto the FP stack. While this happens FP
performance is always going to be poor compared to languages that make
optimal use of the FPU. So poor FP performance in Smalltalk is to some
extent an outcome of the reinfication of Floats, and to some extent
(probably greater, though that's only an educated guess) the result of
treating arithmetic operations as message sends which always return a
further object. I believe a clever optimising translator could "cheat" away
at least some of the impact of the latter for common cases by appropriate
inlining, but this is not a short term goal in Dolphin. Another approach
might be to add pragmas to mark calculations as being statically
optimisable, and then having the compiler generate more optimal code at
compile time. This would be unclean, and somewhat at odds with the
philosophy of Smalltalk, but it could be a quick win. However, we have no
plans to do that either I'm afraid.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
So, Floats start-out boxed, and end-up boxed again, as proper objects.  Is
this correct?  Are the intermediate manipulations unboxed?

 I believe a clever optimising translator could "cheat" away
> at least some of the impact of the latter for common cases by appropriate
> inlining, but this is not a short term goal in Dolphin.

How does this optimisation relate to boxing of floats?

 Another approach
> might be to add pragmas to mark calculations as being statically
> optimisable, and then having the compiler generate more optimal code at
> compile time. This would be unclean, and somewhat at odds with the
> philosophy of Smalltalk, but it could be a quick win. However, we have no
> plans to do that either I'm afraid.

Clean is almost always better than a quick win.


Shaping