<div dir="ltr"><div>Hi Subbu,</div><div>Yes those raw bits are somehow like immediates, but not exactly...</div><div><br></div><div>Immediates are objects having their value encoded into the pointer slot (either in 4 or 8 bytes, according to 32bits or 64bits VM word size).</div><div>Currently, this covers only SmallInteger, Character and SmallFloat on 64bits.</div><div><br></div><div>Here we have values encoded into slots of 1, 2, 4 or 8 bytes, but not into an object oriented pointer slot.</div><div>Technically, #(1 2.0 $3) is an Array of immediates, while ((ColorArray with: Color black) first) is not an immediate...</div><div>So even if it is the same notion of encoded value, it's not an exact match...</div><div><br></div><div>Concerning the use cases, I effectively want to use such bit arrays for fast data transfer.</div><div>For example, it is useful for FFI I use exclusivily this kind of array for Smallapack...</div><div>But also when reading big files in Matlab, National Instrument TDMS or HDF5 format.</div><div>it really helps to have all the possible flavours for common elementary types of values.</div><div>Otherwise, I have to use an intermediate ByteArray, or pointers to external heap via FFI (like I did in Smallapack).</div><div><br></div><div>More than often, the data transfer can handle offset and stride via a BitBlt tricks (unless we have an odd layout).</div><div>This enables extracting a single "column" or bloc of data from a big file with a single copy.<br></div><div>I may need to extend BitBlt to cope with all the available bit-widths, not just 8 (byte) or 32 (word) though.</div><div><br></div><div>Also, those formats offer packed and contiguous memory layout which is an advantage too when dealing with large chunks of data.</div><div>Especially if we have vectorized primitives operating on the arrays.</div><div>
<div><br></div><div>Also, creating non-immediate objects on the fly thru #at: #at:put: is very efficient if VM has generation scavenger because those objects are generally short-lived.</div><div>While retaining all the pointers to a whole collection of non immediate objects is putting a lot of pressure on the garbage collector.</div>

</div><div><br></div><div>The advantage somehow diminish with the advent of 64bits VM: most values can be immediates, so we have quasi-contiguous data at a few exceptions, and not so much GC pressure.</div><div>But still, the primitives can operate on raw bits, without having to handle the immediate tag, nor exceptional (non immediate) values.</div><div><br></div><div>For the anecdote, in the 90s, I started to experiment some crashes in objectworks/visualworks when handling large Arrays of Float.</div><div>The console would only report: *out of memory*.<br></div><div>With increasing processor speed, the memory where exhausted before the low space monitoring process had a chance to handle the situation.</div><div>I then decided to handle all my Arrays of Float (Double) thru some UninterpretedBytes and ad-hoc primitives for at: at:put:</div><div>Since then, I never came back to pointer oriented arrays: if we want Smalltalk to scale, we need those basic objects  :)<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 3 mai 2020 à 06:50, K K Subbu <<a href="mailto:kksubbu.ml@gmail.com">kksubbu.ml@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/05/20 5:41 pm, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
> Nicolas Cellier uploaded a new version of Collections to project The Inbox:<br>
> <a href="http://source.squeak.org/inbox/Collections-nice.891.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/inbox/Collections-nice.891.mcz</a><br>
> <br>
> ==================== Summary ====================<br>
> <br>
> Name: Collections-nice.891<br>
> Author: nice<br>
> Time: 2 May 2020, 7:40:45.298967 pm<br>
> UUID: 08510be0-8293-6744-959d-c1d41bc13ae1<br>
> Ancestors: Collections-nice.890<br>
> <br>
> Experimental - For discussion<br>
> <br>
> Group some (most) non-pointers collections under an abstract FixedBitWifthArray.<br>
> I know, the name is hard to pronounce and thus ugly: it's opened to discussion.<br>
> <br>
> This enables factorization of some methods, for example the trick for atAllPut:<br>
> Also notice that most methods are shared between FloatArray and Float64Array.<br>
<br>
How about ImmediateWord/ImmediateObject and an ImmediateArray (an array <br>
consisting only of Immediate elements)? It would be consistent with <br>
isImmediateClass method.<br>
<br>
An object chunk could be checked at loading time to see if it needs to <br>
be converted from immediate to pointers or vice versa. In the typical <br>
case, this will be a nop. But if the image is moved to a different host <br>
type (say from 64b to 32b or from x86 to ARM), then some immediate <br>
numbers may be converted into pointers or vice versa. If this increases <br>
loading time for large images, then the image may be saved locally.<br>
<br>
This is just a strawman. I haven't really thought through all its <br>
implications.<br>
<br>
Regards .. Subbu<br>
<br>
</blockquote></div>