new Cog VMs
Locked
 
|
Hi All,
I've released a new version of Cog that has a substantially improved code generator along the lines of Peter Deutsch's HPS (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple tecnique to identify constant references in bytecode and to support a register-based calling convention. While this does produce faster code it tends to accelerate low-level code much more than high-level code as you can see by the following benchmarks:
SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 192 - 691 / 6.91 -72% SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec' StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec' 931756141 - 753495217 / 7534952.17 -24%
128157989 - 64769127 / 647691.27 -98% SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript)
43406 - 47013 / 470.13 -7.67234594686576 The status of this code is essentially beta. The test suite runs the same on the new code generator as on the old, but I think there are still bugs because I get the occasional transient error. I am therefore very interested in any reproducible errors you can find.
The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few other important changes: - a bug fix to bytecode<->native pc mappng that produced incorrect results for methods containing blocks with ^-returns in them. One symptom is incorrect highlighting of the pc in the debugger, althoguh symptoms could be much serious.
- jitting interpreted methods on backward branches. Currently any interpreted method that performs more than 20 backward branches will be considered for JIT compilation and if it is suitable (default, <= 60 literals) will be compiled to native code.
- new callback support. I need to commit some changes to the Alien package to provide access to this but essentially the VM's callback support is now able to be ported to architectures with register-based calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, and to back-port the changes to the standard VM before the end of the holiday.
One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. Apologies. I'll try and get a fix for this before the end of the holidays too, but time might be too tight. There are other priorities such as harmonising the standard and Cog VMs for the 4.2 release.
best Eliot |
|
|
Wow fantastic!
I will try tomorrow on my usual development work. Thanks by share! German. 2010/12/30, Eliot Miranda <[hidden email]>: > Hi All, > > I've released a new version of Cog that has a substantially improved > code generator along the lines of Peter Deutsch's HPS (VisualWorks) and > various of Ian Piumarta's VMs. These all use a simple tecnique to identify > constant references in bytecode and to support a register-based calling > convention. While this does produce faster code it tends to accelerate > low-level code much more than high-level code as you can see by the > following benchmarks: > > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > 192 - 691 / 6.91 -72% > > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 > sends/sec' > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; > 128157989 sends/sec' > 931756141 - 753495217 / 7534952.17 -24% > 128157989 - 64769127 / 647691.27 -98% > > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no > transcript > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no > transcript) > 43406 - 47013 / 470.13 -7.67234594686576 > > The status of this code is essentially beta. The test suite runs the same > on the new code generator as on the old, but I think there are still bugs > because I get the occasional transient error. I am therefore very > interested in any reproducible errors you can find. > > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few > other important changes: > > - a bug fix to bytecode<->native pc mappng that produced incorrect results > for methods containing blocks with ^-returns in them. One symptom is > incorrect highlighting of the pc in the debugger, althoguh symptoms could be > much serious. > > - jitting interpreted methods on backward branches. Currently any > interpreted method that performs more than 20 backward branches will be > considered for JIT compilation and if it is suitable (default, <= 60 > literals) will be compiled to native code. > > - new callback support. I need to commit some changes to the Alien package > to provide access to this but essentially the VM's callback support is now > able to be ported to architectures with register-based calling conventions > (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, > and to back-port the changes to the standard VM before the end of the > holiday. > > One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. > Apologies. I'll try and get a fix for this before the end of the holidays > too, but time might be too tight. There are other priorities such as > harmonising the standard and Cog VMs for the 4.2 release. > > best > Eliot > -- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com ================================================= |
|
|
Thanks Eliot!
Francisco
On Fri, Dec 31, 2010 at 12:37 AM, Germán Arduino <[hidden email]> wrote: Wow fantastic! |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
Thanks for the new version! And here's the first bug report, reproducible :) http://dl.dropbox.com/u/17707726/image.tar.xz Using this image (pharo 1.1.1 from Lukas' hudson with omnibrowser & friends & seaside loaded, pharov10.sources) - opening the settings from the world menu crashes the VM. The output is named 'out1' in the same archive. Regards, Stanislav Paskalev On Fri, Dec 31, 2010 at 4:02 AM, Eliot Miranda <[hidden email]> wrote: > > Hi All, > I've released a new version of Cog that has a substantially improved code generator along the lines of Peter Deutsch's HPS (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple tecnique to identify constant references in bytecode and to support a register-based calling convention. While this does produce faster code it tends to accelerate low-level code much more than high-level code as you can see by the following benchmarks: > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > 192 - 691 / 6.91 -72% > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec' > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec' > 931756141 - 753495217 / 7534952.17 -24% > 128157989 - 64769127 / 647691.27 -98% > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript) > 43406 - 47013 / 470.13 -7.67234594686576 > The status of this code is essentially beta. The test suite runs the same on the new code generator as on the old, but I think there are still bugs because I get the occasional transient error. I am therefore very interested in any reproducible errors you can find. > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few other important changes: > - a bug fix to bytecode<->native pc mappng that produced incorrect results for methods containing blocks with ^-returns in them. One symptom is incorrect highlighting of the pc in the debugger, althoguh symptoms could be much serious. > - jitting interpreted methods on backward branches. Currently any interpreted method that performs more than 20 backward branches will be considered for JIT compilation and if it is suitable (default, <= 60 literals) will be compiled to native code. > - new callback support. I need to commit some changes to the Alien package to provide access to this but essentially the VM's callback support is now able to be ported to architectures with register-based calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, and to back-port the changes to the standard VM before the end of the holiday. > One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. Apologies. I'll try and get a fix for this before the end of the holidays too, but time might be too tight. There are other priorities such as harmonising the standard and Cog VMs for the 4.2 release. > best > Eliot > > |
|
|
In reply to this post by garduino
Thanks for your great work Eliot.
On Thu, Dec 30, 2010 at 8:37 PM, Germán Arduino <[hidden email]> wrote: > Wow fantastic! > I will try tomorrow on my usual development work. > Thanks by share! > German. > > 2010/12/30, Eliot Miranda <[hidden email]>: >> Hi All, >> >> I've released a new version of Cog that has a substantially improved >> code generator along the lines of Peter Deutsch's HPS (VisualWorks) and >> various of Ian Piumarta's VMs. These all use a simple tecnique to identify >> constant references in bytecode and to support a register-based calling >> convention. While this does produce faster code it tends to accelerate >> low-level code much more than high-level code as you can see by the >> following benchmarks: >> >> SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 >> StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 >> 192 - 691 / 6.91 -72% >> >> SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 >> sends/sec' >> StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; >> 128157989 sends/sec' >> 931756141 - 753495217 / 7534952.17 -24% >> 128157989 - 64769127 / 647691.27 -98% >> >> SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no >> transcript >> StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no >> transcript) >> 43406 - 47013 / 470.13 -7.67234594686576 >> >> The status of this code is essentially beta. The test suite runs the same >> on the new code generator as on the old, but I think there are still bugs >> because I get the occasional transient error. I am therefore very >> interested in any reproducible errors you can find. >> >> The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few >> other important changes: >> >> - a bug fix to bytecode<->native pc mappng that produced incorrect results >> for methods containing blocks with ^-returns in them. One symptom is >> incorrect highlighting of the pc in the debugger, althoguh symptoms could be >> much serious. >> >> - jitting interpreted methods on backward branches. Currently any >> interpreted method that performs more than 20 backward branches will be >> considered for JIT compilation and if it is suitable (default, <= 60 >> literals) will be compiled to native code. >> >> - new callback support. I need to commit some changes to the Alien package >> to provide access to this but essentially the VM's callback support is now >> able to be ported to architectures with register-based calling conventions >> (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, >> and to back-port the changes to the standard VM before the end of the >> holiday. >> >> One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. >> Apologies. I'll try and get a fix for this before the end of the holidays >> too, but time might be too tight. There are other priorities such as >> harmonising the standard and Cog VMs for the 4.2 release. >> >> best >> Eliot >> > > > -- > ================================================= > Germán S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > |
|
|
In reply to this post by Eliot Miranda-2
On Thu, Dec 30, 2010 at 06:02:36PM -0800, Eliot Miranda wrote:
> > Hi All, > > I've released a new version of Cog that has a substantially improved > code generator along the lines of Peter Deutsch's HPS (VisualWorks) and > various of Ian Piumarta's VMs. This is very impressive - thank you! Dave |
|
|
In reply to this post by Eliot Miranda-2
Hi All,
thanks to everyone finding bug cases. Please keep it up. I'm anxious to find a reproducible case for a crash in (what I thought was fixed) bytecode to machine code pc mapping with the r2333 VMs which has a stack trace like the following:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.teleplace.Teleplace 0x000b8ca6 mapForbcpcperformUntilarg + 166 (cogit.c:10929) 1 com.teleplace.Teleplace 0x000b8f3c mcPCForstartBcpcin + 44 (cogit.c:11480)
I get it only intermittently (ironically when pushing out a new version of the VM sources) and would love to find a reproducible case. So if anyone sees this I'd be indebted if you could spend some time trying to make it easily reproducible.
TIA Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
|
|
On Fri, Dec 31, 2010 at 2:25 PM, Eliot Miranda <[hidden email]> wrote:
> Hi All, > thanks to everyone finding bug cases. Please keep it up. I'm anxious > to find a reproducible case for a crash in (what I thought was fixed) Hi Eliot, I was able to launch the Squeak4.2-10779-alpha.image with the new VM, but when I tried to open a file list it crashed with the following information in the console: Case not found and no otherwise clause Smalltalk stack dump: 0xbfb87c0c I Color>slightlyDarker 2026011364: a(n) Color 0xbfb87c30 I Color>atMostAsLuminentAs: 2025218908: a(n) Color 0xbfb87c64 I PluggableTreeMorph(SimpleHierarchicalListMorph)>lineColor 2024731300: a(n) PluggableTreeMorph 0xbfb87c88 I PluggableTreeMorph(SimpleHierarchicalListMorph)>drawLinesOn: 2024731300: a(n) PluggableTreeMorph 0xbfb87cac I PluggableTreeMorph(SimpleHierarchicalListMorph)>drawOn: 2024731300: a(n) PluggableTreeMorph 0xbfb87cc8 M FormCanvas>? 2025370248: a(n) FormCanvas 0xbfb87ce4 M FormCanvas>? 2025370248: a(n) FormCanvas Segmentation fault Most recent primitives primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primRenderScanline:with: primFinishedProcessing primGetTimes: primGetCounts: primGetBezierStats: wait at:put: signal @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew basicNew new: @ basicNew at:put: @ basicNew at:put: @ @ basicNew at:put: @ @ basicNew at:put: copyBits copyBits copyBits copyBits @ @ basicNew copyBits copyBits basicNew basicNew at:put: digitCompare: new: at:put: at:put: at:put: at:put: @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew basicNew new: @ basicNew at:put: @ basicNew at:put: @ @ basicNew at:put: @ @ basicNew at:put: copyBits copyBits copyBits copyBits @ @ basicNew copyBits copyBits @ @ basicNew @ @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits * * * * * * perform:with: * / perform:with: / perform:with: * perform:with: / basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated perform:with: * perform:with: / [1]+ Aborted (core dumped) squeak Squeak4.2-10779-alpha.image On Fri, Dec 31, 2010 at 2:25 PM, Eliot Miranda <[hidden email]> wrote: > Hi All, > thanks to everyone finding bug cases. Please keep it up. I'm anxious > to find a reproducible case for a crash in (what I thought was fixed) > bytecode to machine code pc mapping with the r2333 VMs which has a stack > trace like the following: > Thread 0 Crashed: Dispatch queue: com.apple.main-thread > 0 com.teleplace.Teleplace 0x000b8ca6 mapForbcpcperformUntilarg + > 166 (cogit.c:10929) > 1 com.teleplace.Teleplace 0x000b8f3c mcPCForstartBcpcin + 44 > (cogit.c:11480) > I get it only intermittently (ironically when pushing out a new version of > the VM sources) and would love to find a reproducible case. So if anyone > sees this I'd be indebted if you could spend some time trying to make it > easily reproducible. > TIA > Eliot > On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> > wrote: >> >> Hi All, >> I've released a new version of Cog that has a substantially improved >> code generator along the lines of Peter Deutsch's HPS (VisualWorks) and >> various of Ian Piumarta's VMs. These all use a simple tecnique to identify >> constant references in bytecode and to support a register-based calling >> convention. While this does produce faster code it tends to accelerate >> low-level code much more than high-level code as you can see by the >> following benchmarks: >> SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 >> StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 >> 192 - 691 / 6.91 -72% >> SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 >> sends/sec' >> StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; >> 128157989 sends/sec' >> 931756141 - 753495217 / 7534952.17 -24% >> 128157989 - 64769127 / 647691.27 -98% >> SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no >> transcript >> StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no >> transcript) >> 43406 - 47013 / 470.13 -7.67234594686576 >> The status of this code is essentially beta. The test suite runs the same >> on the new code generator as on the old, but I think there are still bugs >> because I get the occasional transient error. I am therefore very >> interested in any reproducible errors you can find. >> The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few >> other important changes: >> - a bug fix to bytecode<->native pc mappng that produced incorrect results >> for methods containing blocks with ^-returns in them. One symptom is >> incorrect highlighting of the pc in the debugger, althoguh symptoms could be >> much serious. >> - jitting interpreted methods on backward branches. Currently any >> interpreted method that performs more than 20 backward branches will be >> considered for JIT compilation and if it is suitable (default, <= 60 >> literals) will be compiled to native code. >> - new callback support. I need to commit some changes to the Alien >> package to provide access to this but essentially the VM's callback support >> is now able to be ported to architectures with register-based calling >> conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code >> released soon, and to back-port the changes to the standard VM before the >> end of the holiday. >> One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. >> Apologies. I'll try and get a fix for this before the end of the holidays >> too, but time might be too tight. There are other priorities such as >> harmonising the standard and Cog VMs for the 4.2 release. >> best >> Eliot > > > > > |
|
|
In reply to this post by Eliot Miranda-2
ignore this one. I have the patient on the table...
On Fri, Dec 31, 2010 at 12:25 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
|
|
In reply to this post by Eliot Miranda-2
Hi All,
there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2337/ & VM.r2338/ respectively. These contain fixes for another bad pc mapping bug that could cause hard crashes when jitting on a backward branch in a looping interpreted method. If you're trying to reproduce Cog crashes please upgrade to one of tthese two VMs.
TIA and happy new 2011, P.S. according to an FBF RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11 consecutive prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211
Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
|
|
In reply to this post by Eliot Miranda-2
Hi All,
there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2339/ & VM.r2340/ respectively. These contain fixes for rounding bug causing underestimate of openPICSize and resultant hard crashes, seen e.g. by trying to recover lost changes in a Pharo 1.2 image installed on c:\pharo. If you're trying to reproduce Cog crashes please upgrade to one of tthese two VMs.
TIA EliotOn Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
|
|
In reply to this post by Eliot Miranda-2
Hi All,
find new VMs in VM.r2344/ (SimpleStackBasedCogit) and VM.r2345/ (StackToRegisterMappingCogit) and VMMaker-oscog-45. These fix a bug that could cause crashes when converting an interpreted method to a machine-code method on backward branch (i.e. when the Vm detects an interpreted method is looping).
I hope there are no new issues with VM.r2344/ (SimpleStackBasedCogit). However, Matthew Fulmer has found that on linux the VM.r2343/ VM.r2345/ (StackToRegisterMappingCogit) VMs crash immediately loading Squeak4.2-10856-beta.image. I can reproduce this but haven't had time to investigate. The StackToRegisterMappingCogit VMs do start up this image on Mac and Windows.
Agan thanks for pounding on these. I may not be able to attend to the linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next weekend. Apologies. best
Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
|
|
In reply to this post by Eliot Miranda-2
Hi All,
I've uploaded new VMs to VM.r2348/ (SimpleStackBasedCogit) and VM.r2349/ (StackToRegisterMappingCogit). The former are simply to be up-to-date with svn & Monticello. The latter also fix a bad bug with the StackToRegisterMappingCogit where e.g. 16r10 bitOr: 16r20 would evaluate to 1. I've smoke-tested the 2349 VMs on the Squeak4.2 beta test suite and things look good.
best Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |