... 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 |
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 |
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:
best,
Eliot |
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:
best,
Eliot |
… and ARMv6 and ARMv7 stack and stack/spur VMs updated accordingly. Doug
|
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:
|
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:
|
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. |
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 |
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 > > > |
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 |
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 > > |
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: 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.
best,
Eliot |
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 |
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: Ah, cool. Yes, it's broken :-).
best,
Eliot |
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 |
Free forum by Nabble | Edit this page |