RE: How do tagged data structures work in Strongtalk?

> -----Original Message-----
> From:  prunedtree
> > On May 27, 12:54 am, Richard <[email protected]> wrote:
> > I'm wondering how tagged data structures work in strongtalk. Are
> > objects always 4 byte aligned allowing the low two order bytes to be
> > used for tagging.

The tag is two bits, not two bytes, which is probably what you meant :-).

> > If this is the case how to floats and doubles work?
> > How do you gracefully move from an unboxed double to a boxed double?
> > Or are doubles always boxed? What about floats?
>
> The only unboxed values in strongtalk are smis (smallintegers). All
> others are full heap-allocated objects. There are no single precision
> floating point values in strongtalk, only 64-bit fp (C "double").
> doubleOops take 128 bit: 4 byte GC header, 4 byte class oop, 8 byte
> data.

Actually there are experimental unboxed doubles, however they can only be
used within a method, not passed, and are not unified with the type system.
See the Mandelbrot application for an example.  They work, and are very
fast, but not very complete.

>
> > Is there a primitive array type that allows one to have an array of
> > doubles?
>
> At the VM level, yes. But it's not implemented in the system. All
> arrays working on raw data (even external data) will probably be
> unified.

Yes, prunedtree is right, I believe there are the necessary VM types and
primitives, but no class in Smalltalk using them right now.  But it would be
incredibly simple to implement; probably only a few small methods, although
the VM functionality probably hasn't been tested.

> > Is there a way to have such an array interact gracefully with
> > an Object array? e.g. if you put an object in your double array can it
> > turn into an Object array with boxed doubles?
>
> Of course. If you have basic encapsulation, #at: will always return
> objects, to access doubles the VM will box them.

I don't think that's quite what he was asking; you couldn't store a
non-double into a double array and have the double array turn into an object
array, without using a become: operator, which isn't there right now, unless
you designed a special hybrid array class that held a secondary array
internally that it could replace as necessary.  But that would cause
reallocation of the entire array when it happens, and wouldn't be
reversible.

> > Is this type of
> > situation helped by having a static type system in strongtalk?
>
> No. The static type system is irrevelant to the implementation and
> performance of the VM.
>
> >
> > I presume the recent brenchmarking example discussed in relation to
> > memory allocation was designed to test the precision of strongtalk
> > arithmetic as well as its performance.
>
> What benchmark do you have in mind exactly ?
>
> >
> > Is there accepted wisdom of the merits of boxed and unboxed primitive
> > types in smalltalk/strongtalk?
>
> First, there's only one type in smalltalk/strongtalk: objects.
> Regarding implementation, smis have indeed different semantics from
> most objects: they are not heap-allocated (you can't only pass them by
> copy, never by reference). This is common in smalltalks. Everything
> else is boxed objects.

There are a couple of reasons why there are no double arrays in the system
might now.  First of all, it just hadn't been needed yet.  But more
importantly, I have an objection to them.  The problem with a double array
is that it must allocate a double every time you access an array element.
In general, reads are much more frequent than writes, and so in the common
case you can cause *vast* amounts of allocation without realizing it.  In
such a situation, it is actually better to allocate an object array, with
individually allocated doubles; you will usually do far less total
allocation that way, and accessing individual elements will be actually be
faster; the main downside is a bit more than twice the space is required
(two more words for each double header, and another word for the reference
to it in the array, vs. two words).

That is the basic problem with unboxed doubles in general: every time an
unboxed double passes across into boxed-object land, it has to be
reallocated, and this sort of invisible allocation can easily cause massive
amounts of accidental alllocation.  So in general, I'm only an advocate of
unboxed doubles in situations where they are provably immediate results that
can be held in registers or on the stack and discarded immediately.

-Dave


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---