5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

Tim Johnson-2
Hi,

I downloaded an ran the All-in-one and wanted to put it through its
paces on Windows 7 32-bit.  (I recognize 32-bit is a dying breed, but
nonetheless...)

Test steps:

* ran squeak.bat
* skipped configuration
* ran update (to #18160)
* ran Installer ensureRecentMetacello
* ran:

Metacello new
     baseline: 'Seaside3';
     repository: 'github://SeasideSt/Seaside:master/repository';
     load

Please note: my notes below are from my initial run and have not been
verified by duplicating my initial run.

results:

* initial fetches of BaselineOf* via Metacello all seem to initially
stall, then retry, then succeed.  My internet connection is pretty fast
(gigabit fiber).  In Transcript, each shows similar to:

...RETRY->BaselineOfSeaside3
...RETRY->BaselineOfGrease

* the VM opened a Debug Console.  Its text:

LoadLibrary(UUIDPlugin) (998: Invalid access to memory location.

)

LoadLibrary(UUIDPlugin.dll) (998: Invalid access to memory location.

)

UUIDPlugin was mentioned on the mailing list about two years ago, but I
don't know if this is related.

* Grease throws various Undeclared warnings in the transcript;  I wonder
if it will need some adjustments for Squeak 5.2, or what. Some examples:

BlockContext>>fixCallbackTemps (home is Undeclared)
BlockContext>>tempVarRefs(method is shadowed)
BlockContext>>tempVarRefs (home is Undeclared)
BlockContext>>tempVarRefs (startpc is Undeclared)


I decided to run some tests.  Results:

* Grease tests all pass, though one prompts for author initials.

* KernelTests:  1 error, 1 unexpected pass.

passed:   FloatTest>>#testTimesTwoPowerGradualUnderflow

failed:  AllocationTest>>#testOutOfMemorySignal

     (failed:  #vmParameterAt:put:   ... primitive 254) ?

* NetworkTests:  all green

* "Tests-*" -- excepting Tests-Bugs, Tests-Release, DecompilerTests*

I interrupted & restarted these tests partway thru in order to deselect
DecompilerTests.  Hopefully that didn't affect my results, but is worth
mentioning.

14 failures:

MCWorkingCopyTest>>#testDoubleRepeatedMerge
MCWorkingCopyTest>>#testRedundantMerge
MCWorkingCopyTest>>#testSnapshotAndLoad
PackageDependencyTest>>#testEtoys
PackageDependencyTest>>#testMorphic
PackageDependencyTest>>#testMorphicExtras
PackageDependencyTest>>#testNetwork
PackageDependencyTest>>#testSUnitGUI
PackageDependencyTest>>#testSound
PackageDependencyTest>>#testSystem
PackageDependencyTest>>#testTools
UserInterfaceThemeTest>>#test01ImplementationHooks
UserInterfaceThemeTest>>#test05ClearProperty
UserInterfaceThemeTest>>#test06SetAndClearUnkownProperty

2 errors:

MCWorkingCopyRenameTest>>#testRenamePrefix
MCWorkingCopyRenameTest>>#testRenameSuffix


* SqueakSSLTests -- all green!

* WebClientTests -- two failures:

WebClientServerTest>>#testLogging200
WebClientServerTest>>#testLogging404

* ChronologyTests -- one failure (maybe this is an expected failure)

DateAndTimeLeapTest>>#testAsSeconds


Thanks everybody,
Tim



Reply | Threaded
Open this post in threaded view
|

Re: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

Eliot Miranda-2
Hi Tim,

    thanks for this.  I don't want to respond to the tests per se, but I do want to address one parenthetical you make.

On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson <[hidden email]> wrote:
Hi,

I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit.  (I recognize 32-bit is a dying breed, but nonetheless...)

I don't think it is, at least not unless underlying OSs cease to support it.  Because Smalltalk has infinite precision arithmetic the 32-bit system works very well for anything that doesn't require a huge address space.  Because in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should be faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth.  I no longer use the 32-bit system with any regularity, but that's because the VM simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers.  But in this case the application is to a symbolic processing one, but a low level bit manipulation one.

So I, and others, hope that the 32-bit system will live for a long time.  The 64-bit version has its place, and in an increasing number of contexts it is required, but it can be overkill, and so there are string benefits to maintaining both.  Especially since in Smalltalk we have the infrastructure to freely exchange code between the two and are much less dependent on word size than programs written in many other programming languages.


Test steps:

* ran squeak.bat
* skipped configuration
* ran update (to #18160)
* ran Installer ensureRecentMetacello
* ran:

Metacello new
    baseline: 'Seaside3';
    repository: 'github://SeasideSt/Seaside:master/repository';
    load

Please note: my notes below are from my initial run and have not been verified by duplicating my initial run.

results:

* initial fetches of BaselineOf* via Metacello all seem to initially stall, then retry, then succeed.  My internet connection is pretty fast (gigabit fiber).  In Transcript, each shows similar to:

...RETRY->BaselineOfSeaside3
...RETRY->BaselineOfGrease

* the VM opened a Debug Console.  Its text:

LoadLibrary(UUIDPlugin) (998: Invalid access to memory location.

)

LoadLibrary(UUIDPlugin.dll) (998: Invalid access to memory location.

)

UUIDPlugin was mentioned on the mailing list about two years ago, but I don't know if this is related.

* Grease throws various Undeclared warnings in the transcript;  I wonder if it will need some adjustments for Squeak 5.2, or what. Some examples:

BlockContext>>fixCallbackTemps (home is Undeclared)
BlockContext>>tempVarRefs(method is shadowed)
BlockContext>>tempVarRefs (home is Undeclared)
BlockContext>>tempVarRefs (startpc is Undeclared)


I decided to run some tests.  Results:

* Grease tests all pass, though one prompts for author initials.

* KernelTests:  1 error, 1 unexpected pass.

passed:   FloatTest>>#testTimesTwoPowerGradualUnderflow

failed:  AllocationTest>>#testOutOfMemorySignal

    (failed:  #vmParameterAt:put:   ... primitive 254) ?

* NetworkTests:  all green

* "Tests-*" -- excepting Tests-Bugs, Tests-Release, DecompilerTests*

I interrupted & restarted these tests partway thru in order to deselect DecompilerTests.  Hopefully that didn't affect my results, but is worth mentioning.

14 failures:

MCWorkingCopyTest>>#testDoubleRepeatedMerge
MCWorkingCopyTest>>#testRedundantMerge
MCWorkingCopyTest>>#testSnapshotAndLoad
PackageDependencyTest>>#testEtoys
PackageDependencyTest>>#testMorphic
PackageDependencyTest>>#testMorphicExtras
PackageDependencyTest>>#testNetwork
PackageDependencyTest>>#testSUnitGUI
PackageDependencyTest>>#testSound
PackageDependencyTest>>#testSystem
PackageDependencyTest>>#testTools
UserInterfaceThemeTest>>#test01ImplementationHooks
UserInterfaceThemeTest>>#test05ClearProperty
UserInterfaceThemeTest>>#test06SetAndClearUnkownProperty

2 errors:

MCWorkingCopyRenameTest>>#testRenamePrefix
MCWorkingCopyRenameTest>>#testRenameSuffix


* SqueakSSLTests -- all green!

* WebClientTests -- two failures:

WebClientServerTest>>#testLogging200
WebClientServerTest>>#testLogging404

* ChronologyTests -- one failure (maybe this is an expected failure)

DateAndTimeLeapTest>>#testAsSeconds


Thanks everybody,
Tim






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

Ben Coman
On 29 July 2018 at 05:55, Eliot Miranda <[hidden email]> wrote:

> Hi Tim,
>
>     thanks for this.  I don't want to respond to the tests per se, but I do
> want to address one parenthetical you make.
>
> On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson <[hidden email]> wrote:
>>
>> Hi,
>>
>> I downloaded an ran the All-in-one and wanted to put it through its paces
>> on Windows 7 32-bit.  (I recognize 32-bit is a dying breed, but
>> nonetheless...)
>
>
> I don't think it is, at least not unless underlying OSs cease to support it.
> Because Smalltalk has infinite precision arithmetic the 32-bit system works
> very well for anything that doesn't require a huge address space.  Because
> in a symbolic processing application the 32-bit implementation will move
> half the data than the 64-bit implementation, the 32-bit version should be
> faster, and so if the application fits within the 32-bit heap there's no
> reason to go to 64-bits; one is simply wasting memory bandwidth.  I no
> longer use the 32-bit system with any regularity, but that's because the VM
> simulator is faster on 64-bits than on 32-bits because it spends a lot of
> time accessing the array (actually a Bitmap or DoubleWordArray) that
> contains the heap, and on 64-bits there's much less overflow into boxed
> integers.  But in this case the application is to a symbolic processing one,
> but a low level bit manipulation one.
>
> So I, and others, hope that the 32-bit system will live for a long time.
> The 64-bit version has its place, and in an increasing number of contexts it
> is required, but it can be overkill, and so there are string benefits to
> maintaining both.  Especially since in Smalltalk we have the infrastructure
> to freely exchange code between the two and are much less dependent on word
> size than programs written in many other programming languages.

A particular case where this applies is Internet Of Things size devices.

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

Eliot Miranda-2


On Sat, Jul 28, 2018 at 5:25 PM, Ben Coman <[hidden email]> wrote:
On 29 July 2018 at 05:55, Eliot Miranda <[hidden email]> wrote:
> Hi Tim,
>
>     thanks for this.  I don't want to respond to the tests per se, but I do
> want to address one parenthetical you make.
>
> On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson <[hidden email]> wrote:
>>
>> Hi,
>>
>> I downloaded an ran the All-in-one and wanted to put it through its paces
>> on Windows 7 32-bit.  (I recognize 32-bit is a dying breed, but
>> nonetheless...)
>
>
> I don't think it is, at least not unless underlying OSs cease to support it.
> Because Smalltalk has infinite precision arithmetic the 32-bit system works
> very well for anything that doesn't require a huge address space.  Because
> in a symbolic processing application the 32-bit implementation will move
> half the data than the 64-bit implementation, the 32-bit version should be
> faster, and so if the application fits within the 32-bit heap there's no
> reason to go to 64-bits; one is simply wasting memory bandwidth.  I no
> longer use the 32-bit system with any regularity, but that's because the VM
> simulator is faster on 64-bits than on 32-bits because it spends a lot of
> time accessing the array (actually a Bitmap or DoubleWordArray) that
> contains the heap, and on 64-bits there's much less overflow into boxed
> integers.  But in this case the application is to a symbolic processing one,
> but a low level bit manipulation one.
>
> So I, and others, hope that the 32-bit system will live for a long time.
> The 64-bit version has its place, and in an increasing number of contexts it
> is required, but it can be overkill, and so there are string benefits to
> maintaining both.  Especially since in Smalltalk we have the infrastructure
> to freely exchange code between the two and are much less dependent on word
> size than programs written in many other programming languages.

A particular case where this applies is Internet Of Things size devices.

A 16-bit version would be killer.  What 16-bit processors are doing well in the market these days, if any?

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit

timrowledge


> On 29-07-2018, at 1:50 PM, Eliot Miranda <[hidden email]> wrote:
>
>
> A particular case where this applies is Internet Of Things size devices.
>
> A 16-bit version would be killer.  What 16-bit processors are doing well in the market these days, if any?
>

I don't think there's any need for 16 bit; pretty much all IoT stuff is either ARM (with quite a lot of it using v8 cores because you might as well) or ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing a well trimmed image. The tiny ARM machines could potentially even run a Cog vm when memory allows.

The combination I think would have some value is 32bit oops for '64 bit' machines, ie using the better instruction sets. On ARM it would potentially make a big improvement to run AArch64 code but stay with 32 bit oops. You are of course somewhat at the mercy of your OS to be able to run within a 4Gb address space and not get silly.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Trying out for the javelin retrieval team.



Reply | Threaded
Open this post in threaded view
|

16 bit Squeak (was: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit)

Jecel Assumpcao Jr
Tim Rowledge wrote on Sun, 29 Jul 2018 14:20:11 -0700
> > On 29-07-2018, at 1:50 PM, Eliot Miranda wrote:
> > A particular case where this applies is Internet Of Things size devices.
> >
> > A 16-bit version would be killer.  What 16-bit processors are doing well
> > in the market these days, if any?

I think that the TI MSP430 is the most popular 16 bit processor.

https://en.wikipedia.org/wiki/TI_MSP430

> I don't think there's any need for 16 bit; pretty much all IoT stuff is either
> ARM (with quite a lot of it using v8 cores because you might as well) or
> ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing
> a well trimmed image. The tiny ARM machines could potentially even run a
> Cog vm when memory allows.

If you have a chip with 512KB of RAM, running a 16 bit image would get
you roughly the same results as a 32 bit image in 1MB (actually less
since Strings and Bitmaps would not change size).

It is not a good idea to use a 16 bit processor to run a 16 bit image
because 64KB (or 128KB with word addresses) is just not enough address
space for Smalltalk. At the very least you need to be able to have
multiple segments like in the 8086 or the Alto. But a 32 bit or even 64
bit processor can easily run a 16 bit Squeak as long as it can read and
write 16 bit values from/to memory without being awkward.

In Alan's 1972 proposal for the dynabook he put in very little memory
and expected to swap to tape in a virtual memory scheme (inspired by the
LINC). So if your microcontroller only has 512KB of RAM but does have
access to a serial Flash chip you could use that as a really fast tape
and swap objects between the Flash and RAM as needed.

> The combination I think would have some value is 32bit oops for '64 bit' machines,
> ie using the better instruction sets. On ARM it would potentially make a big
> improvement to run AArch64 code but stay with 32 bit oops. You are of course
> somewhat at the mercy of your OS to be able to run within a 4Gb address space
> and not get silly.

You could also use 32 bit oops and an object table to allow images
larger than 4GB. Or you could have 32 bit oops that are addresses
relative to some base and then the image would be less than 4GB but
could be placed anywhere in the address space.

In any case, I did some work on 16 bit images and a key issue was not
running out of oops. In my case I aliased SmallIntegers and Symbols and
also merged all the methods in a class into a single object.

I have also worked on 8 bit Smalltalks (with objects divided into groups
with at most 256 different oops in a group to local and remote objects)
but that was a case of diminishing returns.

-- Jecel

Reply | Threaded
Open this post in threaded view
|

Re: 16 bit Squeak (was: 5.2 alpha test results: VM 201807260206 & trunk image - Windows 7 32-bit)

Ben Coman
On 1 August 2018 at 07:05, Jecel Assumpcao Jr. <[hidden email]> wrote:

> Tim Rowledge wrote on Sun, 29 Jul 2018 14:20:11 -0700
>> > On 29-07-2018, at 1:50 PM, Eliot Miranda wrote:
>> > A particular case where this applies is Internet Of Things size devices.
>> >
>> > A 16-bit version would be killer.  What 16-bit processors are doing well
>> > in the market these days, if any?
>
> I think that the TI MSP430 is the most popular 16 bit processor.
>
> https://en.wikipedia.org/wiki/TI_MSP430

From that page, maximum RAM seems to be 10K and max speed 25MHz.
Although here shows an $18 chip with 32KB of RAM.
https://www.digikey.com.au/products/en/integrated-circuits-ics/embedded-microcontrollers/685?FV=23c0026%2C1f140000%2Cffe002ad&quantity=&ColumnSort=-1000011&page=1&k=MSP430&pageSize=25&pkeyword=MSP430


Coincidentally I recently researched some ESP32 devices...
https://www.mouser.com/Search/Refine.aspx?Keyword=esp32+rover
$4.20  240MHz ESP32 WROVER 8MB SRAM, 4MB Flash
$5.00  240MHz ESP32 WROVER 8MB SRAM, 16MB Flash (seems a new product,
lead time 8 weeks)

Now I guess that most of the cheaper third-party (non-Espressif)
boards use the WROOM that only have 512KB SRAM,
but the extra SRAM of the WROVER will require less trimming of the Image.
Background info on ESP32 Modules and Boards
https://dl.espressif.com/doc/esp-idf/latest/hw-reference/modules-and-boards.html
and further here
http://esp-idf.readthedocs.io/en/latest/hw-reference/modules-and-boards.html

The ESP-WROVER-KIT V3 seems a useful host system for VM porting work.
Useful features...
  1. JTAG debugging interface may help VM development
  2. MicroSD card slot for quickly switching between test systems and
expanded memory
  3. LCD screen might facilitate Morphic performance testing (although
the aim would be for a headless system).
Available approx US$50 at
https://www.aliexpress.com/item/ESP-WROVER-KIT-ESP32-V3-Development-Board-with-WiFi-Wireless-Bluetooth-with-3-2-inch-LCD/32834370473.html
and https://www.adafruit.com/product/3384


>> I don't think there's any need for 16 bit; pretty much all IoT stuff is either
>> ARM (with quite a lot of it using v8 cores because you might as well) or
>> ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing
>> a well trimmed image. The tiny ARM machines could potentially even run a
>> Cog vm when memory allows.

> If you have a chip with 512KB of RAM, running a 16 bit image would get
> you roughly the same results as a 32 bit image in 1MB (actually less
> since Strings and Bitmaps would not change size).

True, but memory keeps getting bigger and cheaper on all devices.

cheers -ben