Re: How do tagged data structures work in Strongtalk?

On May 27, 10:38 pm, nicolas cellier <[email protected]> wrote:
> What about something like VW SmallDouble on a 64 bits machine?
> (two tag bits taken from exponent i think)

Tagged doubles have the same advantage than unboxed doubles: They
bypass allocation. Their advantage is that they don't break the object
model. But strongtalk works only for x86-32 and will stay like that
for quite some time.

Btw, I think we should get rid of the unboxed doubles in smalltalk
code. Sure, they currently show us the cost of allocation for 64bit fp
computation, and they are useful for that, but the strongtalk compiler
is made to overcome this in the long term. For instance, with some
escape analysis it would be easy to enable object recycling in
compiled code, and thus remove most of the allocated doubles in
computations. Life analysis can easily infer that for many doubles we
allocate, old ones die, and thus you can reuse them (eg: z_im := two *
z_re * z_im + c_im). Conceputally, it's like changing +/-/* operators
into +=/-=/*=. It doesn't change semantics because the objects we
recycle are garanteed to be garbage.

It makes little sense to keep unboxed doubles in a smalltalk system
like strongtalk, whose emphasis is achieving good performance on
idiomatic smalltalk code. You will find under the "computation"
category of the Mandelbrot class several exemples of the kind of code
I would like to avoid.





On May 27, 11:33 pm, Richard <[email protected]> wrote:
> Thanks for your answers, much appreciated.
>
> The recent performance example I was wondering about was:http://groups.google.com/group/strongtalk-general/browse_thread/threa...
>
> Now that I understand that doubles are boxed in strongtalk, I see that
> the example is only about time and space performance, not precision.

Well, I hope you don't take this as a reference benchmark, because i'm
afraid it won't tell much :)

Benchmarking real code might be more interressing. In my opinion, the
true strength of the strongtalk compiler is that it lets you write
many short methods and use lots of blocks with very high runtime
effiency. The compiler is not optimised much for low level number
crunching yet.

>
> regards,
>
> Richard.



On May 27, 10:38 pm, nicolas cellier <[email protected]> wrote:
> What about something like VW SmallDouble on a 64 bits machine?
> (two tag bits taken from exponent i think)

Tagged doubles have the main feature of unboxed doubles: They bypass
allocation. Their advantage is that they don't break the object model.
I should add that strongtalk works only for x86-32 and will stay like
that for quite some time.

Unboxed doubles are not very interressing in the strongtalk system.
Sure, they currently show us the cost of allocation for 64bit fp
computation, and they are useful for that, but the strongtalk compiler
can overcome this in the long term. For instance, with some escape
analysis it would be easy to enable object recycling in compiled code,
and thus remove most of the allocated doubles in computations. Life
analysis can easily infer that for many doubles we allocate, old ones
die, and thus you can reuse them (eg: z_im := two * z_re * z_im +
c_im). Conceputally, it's like changing +/-/* operators into +=/-=/*=.
It doesn't change semantics because the objects we recycle are
garanteed to be garbage. And it would speed up tredemously all
temporary object allocations (which should ideally have close to no
cost) by totally bypassing GC (the main cost of these allocations is
the garbage : it increases the number of scavenges, and thus the GC
time).

It doesn't make much sense to keep unboxed doubles in a smalltalk
system like strongtalk, that puts emphasis on achieving good
performance on idiomatic smalltalk code.

regards,
prunedtree


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---