Spur with Immediate Floating Point Support implies a break
Locked
Spur with Immediate Floating Point Support implies a break
 
|
Re: Spur with Immediate Floating Point Support implies a break
|
|
On Mon, Dec 1, 2014 at 9:58 AM, Eliot Miranda <[hidden email]> wrote:
best,
Eliot |
MorphFloat.st (6K)
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
In reply to this post by Levente Uzonyi-2
> On 04.12.2014, at 04:18, Levente Uzonyi <[hidden email]> wrote: > > Hi Eliot, > > On Wed, 3 Dec 2014, Eliot Miranda wrote: > >> SmallFloat64 is an immediate tagged representation, like SmallInteger, so >> they fit within an object pointer and have no header. In 64-bit Spur there >> is a 3-bit tag, leaving 61 bits. SmallFoat64 steals 3 bits from the 11-bit >> exponent to donate to the tags, representing a full double precision >> floating-point value that is restricted to the ~ +/-10^+/-38 range. >> There's really no practical way to shoe-horn a usable range of 64-bit float >> into a 30-bit value. Its possible but so few values would fit that the >> effort would be counter-productive. DOes this make sense now? > > I didn't mean to use 30-bit values. I meant to use the same 61-bit representation as with the 64-bit Spur. > The object header is 64 bits long in both 32-bit and 64-bit Spur, right? > If yes, then why is it not possible to detect the tag of SmallFloat64 in a 32-bit VM, and treat the object as immediate? I explained this previously, but I'll paste again: > The Squeak VM (and Cog and Spur) traditionally use 32 bits to identify an object. When you store a reference to an object into some other object, the VM actually stores a 32 bit word to some place in main memory. > > When you use a Float in your code, the VM actually allocates 96 bits somewhere in memory (a 32-bit header for house keeping and 64 bits for the IEEE double) and gives you a 32-bit word back, which is a pointer to that object (we also call that an "oop"). This is called "boxing", it wraps the double inside an object. When you add two floats (say 3.0 + 4.0), the VM actually creates two objects and hands you back their oops (e.g. the two hexadecimal numbers @12345600 and @1ABCDE00). Then to add them, the VM reads 64 bits from the memory addresses 12345604 and 1ABCDE04 (skipping the object header), adds these two doubles, allocates another 96 bits in memory (say @56780000), and writes 64 bits of the result to the address 56780004. > > If this sounds expensive to you, that's because it is. It is even more expensive than that because we have just created 3*96 = 288 bits of garbage that needs to be cleaned up later, otherwise we would soon run out of memory if we keep allocating. Since everything in Smalltalk is an object, that is what the VM has to do. > > But there is a trick. The VM uses it to avoid all this allocating and memory fetching for the most common operations, namely working with smallish integers, which are used everywhere. > > That trick is to hide some data in the oop itself. In the 32 bits of object pointers, the lowest two bits are actually always 0, because objects are always allocated at addresses that are a multiple of 4 (32 bits = 4 bytes). If these are always 0, we don't actually need to store them. But since there is no good way to store just 30 bits, we can also use those two bits for something else. > > And we do. The VM currently just uses one bit, the least significant bit (LSB). If the LSB is 0, this is a regular pointer to an object in main memory. If the LSB is 1, then the VM uses the other 31 bits to store an integer. Inside the oop itself, not at some place in memory! It does not need to be allocated, or garbage-collected. It's just there, hidden inside the 32-bit oop. > > This makes operations on these "small integers" extremely efficient. To add e.g. 3 and 4, the VM gets the oops @00000007 and @00000009, shifts them 1 bit to get the actual integers (7 >> 1 = 3 and 9 >> 1 = 4), adds them, and shifts it back, sets the LSB, and answers @0000000F. All this happens in CPU registers, no memory access needed, which is why this is so fast. Access to main memory is orders of magnitude slower than register access. > > We call that an "immediate object". The Squeak VM currently uses only one kind of immediate objects, although there could be more, since we still have an unused bit. It would be great to speed up floating point operations, too. But there is no way to hide a 64-bit double in a 32 bit oop. > > Which brings us to the proposed 64-bit object format. Objects are allocated in chunks of 64 bits = 8 bytes, meaning addresses are multiples of 8, leaving the the 3 lowest bits for identifying immediate objects. > > But there still is no way to hide a 64-bit double inside a 64-bit oop, because the VM needs at least 1 bit to distinguish between regular object pointers and immediate objects. > > So Eliot is proposing a 61-bit immediate Float which (just like SmallIntegers) the VM can process using register operations only. This will be a major boost for most floating point operations (as long as your values are not larger than 10^38). > |
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break
|
|
In reply to this post by Bert Freudenberg
On 05.12.2014, at 00:50, Chris Cunnington <[hidden email]> wrote:
That is exactly right, you understood perfectly fine :)
Indeed, only one in four words is a valid address for an object. But this is actually optimal for a 32-bit processor. Its data bus is 32 bits wide. It cannot read a single byte from memory, it always reads 4 bytes, 32 bits. If you wanted to read 32 bits from the address @00000007 it would have to fetch the two 32 bit words from address @00000004 and @00000008, and combine 8 bits from one with 24 bits from the other. I think Intel CPUs actually do that, whereas others just say "nope, I won’t do that, it’s silly”. This is called “aligned” vs “unaligned” access. Unaligned access is slow, if it works at all. That is why we align all objects on addresses that are a multiple of 4 bytes. This is not a waste of memory since most objects are a multiple of 4 bytes long anyway. That’s because each reference to an object is 32 bits, so all pointer objects are multiple of 4 bytes long. Same for word objects. Only in byte objects we may waste 1 to 3 bytes. Wasting on average 2 bytes per string is a small price to pay for a huge gain in speed for the whole VM. - Bert - |
Immediate and heap objects
|
|
In reply to this post by Bert Freudenberg
I just thought of a unified explanation for immediate and non-immediate objects. It somewhat inverts the notion of "normal", but maybe this way it is easier to understand? -------------------------------------------------------------- In Squeak, everything is an "object". Each object has a reference to another object defining its behavior. This is called the object's "class". Many objects can reference the same class object, they are called the class's "instances". In addition to the class reference, an object may hold other data, the so-called "instance data". The interpretation of this data is defined by the class. Each object is stored in main memory using at least 1 machine word. Different variants of Squeak use either 32 or 64 bit words. For efficiency reasons, the storage format for an object is akin to a "Huffman code", using fewer bits and words for more common kinds of objects. How exactly the object's bits encode the class and instance data is not visible to the user. The Virtual Machine transparently handles the details and makes all objects appear alike. Some objects encode both the class reference and instance data in 1 word. These are called "immediate objects". Most objects do not fit in 1 word. These have a second part dynamically allocated on the heap. They are called "heap objects". The 1-word first part (the only word in immediates) is called an "oop". It is used to reference an object from another object's instance data. The oop has some "tag bits" and some data bits. The tag bits encode the class, and the data bits encode the instance data. One special combination of tag bits is reserved to denote heap objects. The other combinations of tag bits correspond to different classes of immediate objects. 32-bit oops have 2 tag bits. This allows four combinations of tag bits (00, 01, 10, 11). The tags 01 and 11 are used for immediate "SmallInteger" instances, which represents signed numbers between -1073741824 and 1073741823. The tag 10 will be used in Spur for immediate Characters. 64-bit oops have 3 tag bits in Spur. Only half of the 8 tags are assigned at the moment, for SmallIntegers, Characters, and SmallFloat64s. If all tag bits in an oop are zero, this denotes a heap object. In this case, the oop does not immediately encode the class and instance data, but instead it identifies a chunk of memory where that information is stored. Such an untagged oop is used as a direct pointer into the heap. The memory layout of heap objects is specified by the object's class. If you're interested in that layout or the actual assignment of tag bits, read Clement's excellent post: https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ -------------------------------------------------------------- Of course we normally call heap objects "regular objects", and as users we rarely have to care about the distinction anyway. But maybe when we do, explaining it the other way around is actually helpful ... - Bert - PS: Another idea would be to distinguish between "register objects" and "memory objects" and explaining it in terms of CPU operations, like I did in my previous attempt. Actually, that may not be such a bad idea? |
Re: [squeak-dev] Immediate and heap objects
|
|
Re: [squeak-dev] Immediate and heap objects
|
|
On 05.12.2014, at 06:44, Eliot Miranda <[hidden email]> wrote:
This is more precise, yes, but I think my wording is not wrong, just simpler. The tag bits are what the VM looks at to determine the class. It’s just that if the tag bits say that this is a heap object, then the VM needs to go to the heap to find the actual class. It’s a sort of Huffman code. And on the heap the class reference is again Huffman-coded, at least in regular 32-bit Squeak: There are 5 bits for “compact" classes, or 32 bits for all other classes. But spelling all this out at that point would obscure the argument, I think ... I agree that a word other than “encode” might be more appropriate. Would that help?
Oops. Sure. To me Spur is still in the future ;)
Well, I didn’t want to go into too many details, but still give an example, which is why I spelled out the tags for 32-bit oops. The exact assignment of tags is not important to understand the basic concept, and Clement’s post has all the details. - Bert - |
Re: [squeak-dev] Immediate and heap objects
|
|
Re: [squeak-dev] Immediate and heap objects
|
|
> I think the reference to Huffman coding is distracting. I may just call it "variable-length encoding". That's better than referring to Huffman, yes. - Bert - |
Re: [squeak-dev] Immediate and heap objects
|
|
[squeak-dev] Immediate and heap objects
|
|
Re: [squeak-dev] Immediate and heap objects
|
|
| Free forum by Nabble | Edit this page |