Re: How do tagged data structures work in Strongtalk?

What about something like VW SmallDouble on a 64 bits machine?
(two tag bits taken from exponent i think)

Nicolas

David Griswold a écrit :
> 
> 
>> -----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
-~----------~----~----~----~------~----~------~--~---