<div dir="ltr">Hi Clément,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 9:02 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi Clément,<br></div><div><br>On Apr 12, 2018, at 8:29 AM, Clément Bera <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr">Hi all, <div><br><div>question inlined...<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Apr 12, 2018 at 4:05 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="auto"><div>Hi Bert,<br><br></div><div><br>On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.</div></div></div></blockquote><div><br></div>How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.<div><br></div><div>What /is/ trivial is detecting that an image's word size is unsupported on a platform and offering to convert it, a process that takes less than a minute for typical images.</div></div></blockquote><div> </div></span><div>Why does this process take a full minute ? Could we do that in 1 second ? Is it only because of SmallFloat ?</div></div></div></div></div></div></div></blockquote><div><br></div>The classes affected and the reasons are<div>- SmallInteger <-> LargePositiveInteger, <span style="background-color:rgba(255,255,255,0)">LargeNeg<wbr>ativeInteger, since in 32-bits SmallInteger minVal & SmallInteger minVal encompass a 31-bit 2's compliment range, and in 64-bits, a 61-bit range.</span></div><div><span style="background-color:rgba(255,255,255,0)">- SmallFloat64 <-> BoxedFloat64, since in 32-bits there are no immediate floats and in 64-bits floats whose exponent fits in 8 bits are represented by SmallFloat64</span></div><div><span style="background-color:rgba(255,255,255,0)">- Context & BlockClosure since pcs must be offset by 4 bytes per literal as the CompiledCode instance's literals will be twice or half as wide</span></div><div><span style="background-color:rgba(255,255,255,0)">- any and all bits collections (ByteSymbol, ByteArray, DoubleWordArray et al) whose formats change because the number of odd elements (the number of elements to subtract from the product of number of slots and slot size) is different in 32 and 64 bits</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">So the process in going from 32 to 64 bits is</span></div><div><span style="background-color:rgba(255,255,255,0)">- load the 32-bit image into a 32-bit simulator</span></div><div><span style="background-color:rgba(255,255,255,0)">- clone all the objects that are preserved in a 64-bit simulator, creating a map</span></div><div><span style="background-color:rgba(255,255,255,0)">- pass through the 32-bit objects, updating the corresponding slot in the 64-bit simulator with the object at the map</span></div><div><span style="background-color:rgba(255,255,255,0)">- save the 64-bit image</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">And the process in going in the reverse direction would be to</span></div><div><div><span style="background-color:rgba(255,255,255,0)">- load the 64-bit image into a 64-bit simulator</span></div><div><span style="background-color:rgba(255,255,255,0)">- clone all the objects in a 32-bit simulator, creating a map</span></div><div><div><span style="background-color:rgba(255,255,255,0)">- pass through the 64-bit objects, updating the corresponding slot in the 32-bit simulator with the object at the map, or otherwise allocating a boxed object for the 64-bit immediate that has no equivalent immediate in 32-bits</span></div><div><span style="background-color:rgba(255,255,255,0)">- save the 32-bit image</span></div></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">I just timed converting a 34 Mb 32-bit Squeak 5.1 image to 64-bits on my 2.3Ghz Core i7 Mac Mini in a 63-bit Spur image. It took 20.6 seconds to convert. One would probably have to add another 0.5 seconds for start up costs. And Pi is around 5x slower than Mac. So conversion times would be anywhere from 15 seconds to 1 1/2 minutes for standard images, scaling more or less linearly with larger images.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">I certainly don't see any way of doing this in orders of magnitude faster. But that's my limitation ;-)</span></div></div></div></blockquote><div><br></div><div>But this computation is ideal for Scorch/Sista right? It's a series of loops. It only ever does the same thing because input images are extremely similar. The image could be trained on a suitably general input set before being deployed. It would be very interesting to see how much faster Scorch/Sista manages to make image mapping.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>I mean I could dream of a world where 64-bits image under 2Gb are saved as 32 bits images to be more compact on disk. Then at start-up, the 32 bits image is converted into a 64 bits image if started on a 64 bits VM, or not if started on a 32 bits VM. We could also save image under 65k as 16 bits images, and convert them back as start-up :-). Obviously that would work only if the conversion is fast, but I think it could be with tricks to handle SmallFloats.</div></div></div></div></div></div></div></blockquote><div><br></div>I don't think two passes (allocation & mapping) can be avoided because pointer objects, compiled code, and bits objects all map differently, so there's no way to compute the position (and hence the oop) of the corresponding object independently of all other objects in the heap.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Note that the code optimized by Sista is currently dependent on word size though due to overflow computation, but I guess we'll solve this problem later.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>If we go this route we would include a headless 64-bit image that converts 32-bit images to 64-bits on 64-bit only systems, and <span style="background-color:rgba(255,255,255,0)">a headless 32-bit image that converts 64-bit images to 32-bits on 32-bit only systems.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">IIRC 64 to 32 bit conversion needs to be written, but I think it is trivial compared to building a 64-bit vm for 32-bit images.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Of course this applies only to Spur images. We don't have a way of automatically converting V3 images to Spur. Yo do that going forward we may have to depend on OS virtual machines, but somehow I can't see an ARMv8 Mac supporting x86 VMs like Parallels. This could be the end of an interoperability era.</span></div><div><br><blockquote type="cite"><div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Otherwise we won't have any way of opening regular 32 bit images on Macs.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">- Bert -</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 April 2018 at 14:47, Fabio Niephaus <span dir="ltr"><<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_7990019793995837189m_5190493073784700490m_3464897733717783518inboxEmptyGmelius"></div><div>Hi all,</div><div><br></div><div>According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.</div><div><br></div><div>It looks like it is time to make 64-bit the default, maybe with the next release? The Pharo community is already doing that for quite some time, so I'm wondering if there is any reason not to do the same?</div><div><br></div><div>Best,</div><div>Fabio</div><div><br></div>[1] <a href="https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/" target="_blank">https://techcrunch.com/2018/04<wbr>/11/apple-starting-to-alert-us<wbr>ers-that-it-will-end-32-bit-ap<wbr>p-support/</a></div></blockquote></div></div></div></blockquote></div></div></blockquote></span></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_7990019793995837189gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.<wbr>com/</a></div></div></div></div></div></div></font></span></div></div></div></div></div></blockquote></div></div></blockquote></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>