New Cog VMs available

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

New Cog VMs available

Eliot Miranda-2
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Frank Shearar-3
On 14 November 2014 23:11, Eliot Miranda <[hidden email]> wrote:
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

... and updated in CI.

frank

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
Apologies but  at least the Spur VMs are broken.  They don't load images.  Consequently I've taken down the files.  Normal service will be resumed asap.

On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <[hidden email]> wrote:
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot



--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
Hi All,

    problems solved.  So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

CogVM binaries as per VMMaker.oscog-eem.935/r3137

These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.


On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <[hidden email]> wrote:
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot



--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

douglas mcpherson
… and ARMv6 and ARMv7 stack and stack/spur VMs updated accordingly.

Doug

On Nov 15, 2014, at 19:24, Eliot Miranda <[hidden email]> wrote:

Hi All,

    problems solved.  So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

CogVM binaries as per VMMaker.oscog-eem.935/r3137

These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.


On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <[hidden email]> wrote:
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot



--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

Herbert König
Hi,

I use the stack VM on a Pi, and the latest version  seems to work as well as the one before.
Which means it runs an Aida Webserver on a 4.3 derived image which I test with a Selenium testsuite for about five Minutes :-).

Didn't get around to try Spur.

Cheers,

Herbert

Am 16.11.2014 um 06:06 schrieb Douglas McPherson:
… and ARMv6 and ARMv7 stack and stack/spur VMs updated accordingly.

Doug

On Nov 15, 2014, at 19:24, Eliot Miranda <[hidden email]> wrote:

Hi All,

    problems solved.  So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

CogVM binaries as per VMMaker.oscog-eem.935/r3137

These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.


On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <[hidden email]> wrote:
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot



--
best,
Eliot




    



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

Herbert König
In reply to this post by douglas mcpherson
Hi,

Spur also works and in my case it seems that Spur is about 1.5 times as fast as Cog which seems a bit slower than the original VM that comes with the Pi.

Cheers,

Herbert
Am 16.11.2014 um 06:06 schrieb Douglas McPherson:
… and ARMv6 and ARMv7 stack and stack/spur VMs updated accordingly.

Doug

On Nov 15, 2014, at 19:24, Eliot Miranda <[hidden email]> wrote:

Hi All,

    problems solved.  So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

CogVM binaries as per VMMaker.oscog-eem.935/r3137

These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.


On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <[hidden email]> wrote:
... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/.

CogVM binaries as per VMMaker.oscog-eem.934/r3133
These VMs should be functionally identical to the 3126 VMs; the core VM differs
only in having been compiled from generated source that has been refactored to
enable convenient 32-bit to 64-bit Spur image bootstrap.  I'm building and
releasing them mostly to test that refactoring.  However, there is new DNS
support on Windows and SSL support on Unix.  See below.

Simulator/Slang:
Refactor to allow 32-bit and 64-bit Spur to coexist
in the simulator, thereby allowing a 64-bit bootstrap.

Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize
with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively.
Make sure these are still output as the manifest constants in the generated C.
Eliminate use of bytesPerSlot in favour of bytesPerOop.  The use of sends is
similar to those in trunk VMMaker, but I don't have time to merge.  Sorry :-(.

Work-around use of sends for bytesPerOop in e.g.  generateToByDo:on:indent: and
users of isConstantNode:valueInto:.

Do a better job at inlining via inlineCodeOrNilForStatement:in:.  Comment in
isNode:substitutableFor:inMethod:in: explains.

Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret.

Eliminate use of LargeContextSize in the stack and cog VMs.  Alas haven't yet
eliminated the frame offset constants such as FoxCallerSavedIP et al.  We only
need one of the two word sizes of interpreter to be executable in the bootstrap.

And remember to generate the GdbARMPlugin

Add accessorDepths for the exported browser plugin primitives for Spur.

Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix.

Have the Unix & Mac VMs print the process id and working directory when blocking
on error or assert fail.  Add scripts for the ARM VM archives.
--
best,
Eliot



--
best,
Eliot




    



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

timrowledge
In reply to this post by Herbert König

On 16-11-2014, at 1:28 AM, Herbert König <[hidden email]> wrote:

> Didn't get around to try Spur.

I’ve played with the Spur vm on my Pi and it works well enough that I’ll soon be making time to see how well nuScratch does on it. If all is well I’ll push that out as the standard for the Pi. 1.5 million (plus) customers should concentrate the mind wonderfully….

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The Static Typing Philosophy: Make it fast. Make it right. Make it run.



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

timrowledge
In reply to this post by Herbert König

On 16-11-2014, at 6:14 AM, Herbert König <[hidden email]> wrote:

> Spur also works and in my case it seems that Spur is about 1.5 times as fast as Cog which seems a bit slower than the original VM that comes with the Pi.

Now that’s an interesting claim; what tests lead you to that conclusion?

For me the Stack vm (no actual Cog yet…) runs very slightly  faster (under tinyBenchmarks, as a simple example) for bytecodes and 50% or so better for sends. Spur seems similar for bytecodes (surprise!) and maybe 40% better than stackvm for sends. Cog is coming soon…

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RWD: Rewind Disk



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] New Cog VMs available

Herbert König
Hi,

as I wrote I run an AidaWeb server. Main reason is, that that is running
lots of processes, fiddles with the call stack and I have an automated
test which keeps it busy for several minutes.

Blease (too nice to correct :-) note that I said it seems, because this
is a really shaky kind of benchmark. I only measured the reply times in
Firebug after having made sure that all static content is in the browser
cache. And one should not compare 4.3 image based results with 4.6 image
based results. And Cog was the wrong term,
stklinuxhtARMv6-14.45.3126.tgz was what I used. I assumed it was Cog.....

Basically I was surprised how good the standard VM was performing. For
the whole test (which loads the Pi with about 50% CPU) I got the reverse
result of what I expected. Standard VM fastest, Spur slowest. Just tried
again, same result. No idea why. Standard VM and StackVM ran the same
image. The important result was that a complex application (Webserver +
application model, mostly Ajax updates) ran stable with all VMs.

In the next days I'll run simultaneous users on the Webserver and some
other applications which ran for days or hours on the standard VM
without any crash.

Cheers,

Herbert

Am 16.11.2014 um 20:20 schrieb tim Rowledge:

> On 16-11-2014, at 6:14 AM, Herbert König <[hidden email]> wrote:
>
>> Spur also works and in my case it seems that Spur is about 1.5 times as fast as Cog which seems a bit slower than the original VM that comes with the Pi.
> Now that’s an interesting claim; what tests lead you to that conclusion?
>
> For me the Stack vm (no actual Cog yet…) runs very slightly  faster (under tinyBenchmarks, as a simple example) for bytecodes and 50% or so better for sends. Spur seems similar for bytecodes (surprise!) and maybe 40% better than stackvm for sends. Cog is coming soon…
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: RWD: Rewind Disk
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Frank Shearar-3
In reply to this post by Eliot Miranda-2
On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
> Hi All,
>
>     problems solved.  So new VMs available at
> http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

OK, so in CI this manifests (in
http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
"Segmentation fault".

Currently the build conflates several tests: it tests the latest
released CogSpur while trying to update the image. That means that
"segmentation fault" could actually arise because of a broken VM, or
from something during the update. I _think_ that we can distinguish
between the two cases, because during update we should see more
output, like a stack trace or similar. For instance
http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
the VM (3126) did indeed load the image, and something went wrong
during an update.

frank

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Levente Uzonyi-2
On Mon, 17 Nov 2014, Frank Shearar wrote:

> On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
>> Hi All,
>>
>>     problems solved.  So new VMs available at
>> http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.
>
> OK, so in CI this manifests (in
> http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
> "Segmentation fault".
>
> Currently the build conflates several tests: it tests the latest
> released CogSpur while trying to update the image. That means that
> "segmentation fault" could actually arise because of a broken VM, or
> from something during the update. I _think_ that we can distinguish
> between the two cases, because during update we should see more
> output, like a stack trace or similar. For instance
> http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
> the VM (3126) did indeed load the image, and something went wrong
> during an update.

There's nothing in crash.dmp about this crash, but there are runaway
images again from ExternalPackages.

Levente

>
> frank
>
>

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Eliot Miranda-2
In reply to this post by Frank Shearar-3
Hi Frank,

On Mon, Nov 17, 2014 at 12:44 AM, Frank Shearar <[hidden email]> wrote:
On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
> Hi All,
>
>     problems solved.  So new VMs available at
> http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.

OK, so in CI this manifests (in
http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
"Segmentation fault".

I htink I'm in the clear.  I see this from lines immediately preceeding the launch:

curl -sSo cogspurlinux.tgz http://www.mirandabanda.org/files/Cog/VM/VM.r3133/cogspurlinuxht-14.45.3133.tgz

So I don't think you're testing 3137.  Fingers crossed.

perhaps putting a cogspurlinux/squeak -version  in the script to print the version before doing the proper launch would be a good idea.


Currently the build conflates several tests: it tests the latest
released CogSpur while trying to update the image. That means that
"segmentation fault" could actually arise because of a broken VM, or
from something during the update. I _think_ that we can distinguish
between the two cases, because during update we should see more
output, like a stack trace or similar. For instance
http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
the VM (3126) did indeed load the image, and something went wrong
during an update.

frank




--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Frank Shearar-3
On 17 November 2014 21:20, Eliot Miranda <[hidden email]> wrote:

> Hi Frank,
>
> On Mon, Nov 17, 2014 at 12:44 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi All,
>> >
>> >     problems solved.  So new VMs available at
>> > http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.
>>
>> OK, so in CI this manifests (in
>> http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
>> "Segmentation fault".
>
>
> I htink I'm in the clear.  I see this from lines immediately preceeding the
> launch:
>
> curl -sSo cogspurlinux.tgz
> http://www.mirandabanda.org/files/Cog/VM/VM.r3133/cogspurlinuxht-14.45.3133.tgz
>
>
> So I don't think you're testing 3137.  Fingers crossed.

Oh, no, I thought it'd be clear I was _agreeing_ with you that 3133 was broken!

> perhaps putting a cogspurlinux/squeak -version  in the script to print the
> version before doing the proper launch would be a good idea.

The scripts delete "stale" Cogs and download the version in
lib/squeak-ci/version.rb, which - if necessary - says that it's
installing a new version ("Installing new cogspur r.3137 (spur)" in
http://build.squeak.org/job/SqueakTrunkOnSpur/102/console)

3137's working its way through CI now. I don't know why it didn't kick
off earlier today, when I pushed the version change.

frank

>> Currently the build conflates several tests: it tests the latest
>> released CogSpur while trying to update the image. That means that
>> "segmentation fault" could actually arise because of a broken VM, or
>> from something during the update. I _think_ that we can distinguish
>> between the two cases, because during update we should see more
>> output, like a stack trace or similar. For instance
>> http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
>> the VM (3126) did indeed load the image, and something went wrong
>> during an update.
>>
>> frank
>>
>
>
>
> --
> best,
> Eliot

Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Eliot Miranda-2


On Mon, Nov 17, 2014 at 1:49 PM, Frank Shearar <[hidden email]> wrote:
On 17 November 2014 21:20, Eliot Miranda <[hidden email]> wrote:
> Hi Frank,
>
> On Mon, Nov 17, 2014 at 12:44 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi All,
>> >
>> >     problems solved.  So new VMs available at
>> > http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.
>>
>> OK, so in CI this manifests (in
>> http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
>> "Segmentation fault".
>
>
> I htink I'm in the clear.  I see this from lines immediately preceeding the
> launch:
>
> curl -sSo cogspurlinux.tgz
> http://www.mirandabanda.org/files/Cog/VM/VM.r3133/cogspurlinuxht-14.45.3133.tgz
>
>
> So I don't think you're testing 3137.  Fingers crossed.

Oh, no, I thought it'd be clear I was _agreeing_ with you that 3133 was broken!

Ah, cool.  Yes, it's broken :-).
 

> perhaps putting a cogspurlinux/squeak -version  in the script to print the
> version before doing the proper launch would be a good idea.

The scripts delete "stale" Cogs and download the version in
lib/squeak-ci/version.rb, which - if necessary - says that it's
installing a new version ("Installing new cogspur r.3137 (spur)" in
http://build.squeak.org/job/SqueakTrunkOnSpur/102/console)

3137's working its way through CI now. I don't know why it didn't kick
off earlier today, when I pushed the version change.

frank

>> Currently the build conflates several tests: it tests the latest
>> released CogSpur while trying to update the image. That means that
>> "segmentation fault" could actually arise because of a broken VM, or
>> from something during the update. I _think_ that we can distinguish
>> between the two cases, because during update we should see more
>> output, like a stack trace or similar. For instance
>> http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
>> the VM (3126) did indeed load the image, and something went wrong
>> during an update.
>>
>> frank
>>
>
>
>
> --
> best,
> Eliot




--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available

Frank Shearar-3
In reply to this post by Frank Shearar-3
On 17 November 2014 21:49, Frank Shearar <[hidden email]> wrote:

> On 17 November 2014 21:20, Eliot Miranda <[hidden email]> wrote:
>> Hi Frank,
>>
>> On Mon, Nov 17, 2014 at 12:44 AM, Frank Shearar <[hidden email]>
>> wrote:
>>>
>>> On 16 November 2014 03:24, Eliot Miranda <[hidden email]> wrote:
>>> > Hi All,
>>> >
>>> >     problems solved.  So new VMs available at
>>> > http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.
>>>
>>> OK, so in CI this manifests (in
>>> http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
>>> "Segmentation fault".
>>
>>
>> I htink I'm in the clear.  I see this from lines immediately preceeding the
>> launch:
>>
>> curl -sSo cogspurlinux.tgz
>> http://www.mirandabanda.org/files/Cog/VM/VM.r3133/cogspurlinuxht-14.45.3133.tgz
>>
>>
>> So I don't think you're testing 3137.  Fingers crossed.
>
> Oh, no, I thought it'd be clear I was _agreeing_ with you that 3133 was broken!
>
>> perhaps putting a cogspurlinux/squeak -version  in the script to print the
>> version before doing the proper launch would be a good idea.
>
> The scripts delete "stale" Cogs and download the version in
> lib/squeak-ci/version.rb, which - if necessary - says that it's
> installing a new version ("Installing new cogspur r.3137 (spur)" in
> http://build.squeak.org/job/SqueakTrunkOnSpur/102/console)
>
> 3137's working its way through CI now. I don't know why it didn't kick
> off earlier today, when I pushed the version change.

OK, so the good news is that 3137 happily loaded the image. The bad
news is that, like some earlier builds, there's a recursive DNU in
ImageSegment >> #restoreEndianness, kicked off by BitmapStreamTests >>
#testMatrixTransform2x3WithImageSegment

I've not tried reproducing it locally.

frank

> frank
>
>>> Currently the build conflates several tests: it tests the latest
>>> released CogSpur while trying to update the image. That means that
>>> "segmentation fault" could actually arise because of a broken VM, or
>>> from something during the update. I _think_ that we can distinguish
>>> between the two cases, because during update we should see more
>>> output, like a stack trace or similar. For instance
>>> http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
>>> the VM (3126) did indeed load the image, and something went wrong
>>> during an update.
>>>
>>> frank
>>>
>>
>>
>>
>> --
>> best,
>> Eliot