- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] [NB] NativeBoost meets JIT

by Eliot Miranda

Hi Igor, great news! On Fri, Sep 21, 2012 at 7:59 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Hello there, > > so, we're entered a new area, where native code, generated from image > side can be run directly by JIT. > This feature was one of the first things which i wanted to try, once > Eliot released Cog :) > > The way how we do that, is when VM decides to JIT a specific method, > we copying the native code (from method trailer) > directly into the method's code. > All you need to do is to use special primitive for that 220 ( > #primitiveVoltage) > > So, a first question, which we wanted to be answered is how faster to > run native code by JIT, > comparing to running native code via NativeBoost primitive , which is > #primitiveNativeCall.. > > For here are methods, which just answer 42: > > This one using #primitiveNativeCall > > nbFoo2 > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > > ^ NBNativeCodeGen methodAssembly: [:gen :proxy :asm | > asm noStackFrame. > asm > mov: (42 << 1) + 1 to: asm EAX; > ret. > ] > > And this one uses JIT: > > nbFoo > <primitive: 220 error: errorCode> > > [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self > nbFoo ]. > > ^ NBNativeCodeGen jitMethodAssembly: [:gen :proxy :asm | > asm noStackFrame. > asm > mov: (42 << 1) + 1 to: asm EDX; > ret: 4 asUImm. > ] > > And this one is code which JIT can do: > > nbFoo42 > ^ 42 > > So, here the numbers: > > Time to run via #primitiveNativeCall : > > [100000000 timesRepeat: [ MyClass nbFoo2 ] ] timeToRun > 6995 > > Time to run via JIT: > > [100000000 timesRepeat: [ MyClass nbFoo ] ] timeToRun > 897 > > Time to run JITed method: > > [100000000 timesRepeat: [ MyClass nbFoo42 ] ] timeToRun > 899 > > so, as you can see, the JITed method and our custom generated code is > on par (which is logical ;). > > Time to run an empty loop: > > [100000000 timesRepeat: [ ] ] timeToRun 679 > > > So, here the result, if we extract the loop overhead, we can see the > difference in > calling our native code when it uses JIT vs using #primitiveNativeCall : > > (6995 - 679 ) / (897- 679) asFloat 28.972477064220183 > > 28 times faster!!!! > > So, with this new feature, we now can make our generated code to run > with unmatched speed, > without overhead related to #primitiveNativeCall. > This is especially useful for implementing primives which involving > heavy numeric crunching. > > I would release this code to public, but there's one little > discrepancy i need to deal with first: > > (one little problem, which i hope Eliot can help to solve) > > it looks like primitivePerform: never enters the JIT mode, but always > executing the method via interpreter. > I'll take a look. This is all very detailed so I'll need a little time. This is why you see this code: > [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self > nbFoo ]. > > because if i do it inside of NBNativeCodeGen>>jitMethodAssembly:, > which checks for same error and retries the send using perform > primitive, it never enters the JIT mode, > resulting in endless loop :( > > This is despite the fact that method is JITed, because we enforce the > JITing of that method during error handling: > > lastError = ErrRunningViaInterpreter ifTrue: [ > "a method contains native code, but executed by > interpreter " > method forceJIT ifFalse: [ self error: 'Failed to JIT the > compiled > method. Try reducing it''s size ' ]. > ^ self retrySend: aContext > ]. > > The #forceJit is the primitive which i implemented like following: > > primitiveForceJIT > > <export: true > > > | val result | > > val := self stackTop. > > (self isIntegerObject: val) ifTrue: [ ^ self primitiveFail ]. > (self isCompiledMethod: val) ifFalse: [ ^ self primitiveFail ]. > > (self methodHasCogMethod: val) ifFalse: [ > cogit cog: val selector: objectMemory nilObject ]. > > result := (self methodHasCogMethod: val ) ifTrue: [ objectMemory > trueObject ] ifFalse: [ objectMemory falseObject ]. > > ^ self pop: 1 thenPush: result. > > As you can see from its usage, if VM, for some reason will fail to jit > the method, the primitive will answer false, > and we will stop with an error.. Which apparently never happens. > Still, a #primitivePerform seems like ignoring that the method > contains machine code an always runs it interpreted :( > > I do not like the idea, that users will be forced to manually put such > loops in every method they will write.. > any ideas/suggestions how to overcome that? > Yes. The JIT should be told that methods that have NB code should be jitted. But right now I don't understand enough of how NB code is generated and methods marked that they have NB code etc to know exactly how to do this. I need to play around a bit. -- best, Eliot

Sept. 21, 2012

Re: [Pharo-project] headless CogVM on Windows

by Pavel Krivanek

This is the reason why I need the headless mode on Windows: http://youtu.be/L6P6VuqDmaM "This video shows a very simple Pharo application based on XULRunner. We firstly start XULRunner that displays a splashscreen. During the splash screen the XULRunner starts a new process with Pharo and starts Zinc server in it. As soon as the server is started, it starts to communicate to it using a WebSocket and opens the main window. When the window is closed, the Pharo image is closed immediately too." ...so this is the way we can create seamless applications with native GUI in Pharo without need of special VM extensions. Currently on Windows it works the same way however the Pharo window is displayed. I will test the Mac later. -- Pavel On Fri, Sep 21, 2012 at 5:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 September 2012 16:28, Torsten Bergmann <astares(a)gmx.de> wrote: >>>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) >> >> The regulary Squeak VM for Windows is able to do just that. >> It runs Smalltalk as an NT service by using the option "-service" >> See >> >> http://wiki.squeak.org/squeak/105 >> >> Dont know if this also works on Cog/Pharo standard VM. >> > > yeah.. but this is something different.. it registers itself as a > service in system. > Which is not the same as just running it headless. > >> Bye >> T. >> > > > > -- > Best regards, > Igor Stasenko. >

Sept. 21, 2012

Re: [Pharo-project] headless CogVM on Windows

by Igor Stasenko

On 21 September 2012 16:28, Torsten Bergmann <astares(a)gmx.de> wrote: >>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) > > The regulary Squeak VM for Windows is able to do just that. > It runs Smalltalk as an NT service by using the option "-service" > See > > http://wiki.squeak.org/squeak/105 > > Dont know if this also works on Cog/Pharo standard VM. > yeah.. but this is something different.. it registers itself as a service in system. Which is not the same as just running it headless. > Bye > T. > -- Best regards, Igor Stasenko.

Sept. 21, 2012

[Pharo-project] [NB] NativeBoost meets JIT

by Igor Stasenko

Hello there, so, we're entered a new area, where native code, generated from image side can be run directly by JIT. This feature was one of the first things which i wanted to try, once Eliot released Cog :) The way how we do that, is when VM decides to JIT a specific method, we copying the native code (from method trailer) directly into the method's code. All you need to do is to use special primitive for that 220 ( #primitiveVoltage) So, a first question, which we wanted to be answered is how faster to run native code by JIT, comparing to running native code via NativeBoost primitive , which is #primitiveNativeCall.. For here are methods, which just answer 42: This one using #primitiveNativeCall nbFoo2 <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ NBNativeCodeGen methodAssembly: [:gen :proxy :asm | asm noStackFrame. asm mov: (42 << 1) + 1 to: asm EAX; ret. ] And this one uses JIT: nbFoo <primitive: 220 error: errorCode> [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self nbFoo ]. ^ NBNativeCodeGen jitMethodAssembly: [:gen :proxy :asm | asm noStackFrame. asm mov: (42 << 1) + 1 to: asm EDX; ret: 4 asUImm. ] And this one is code which JIT can do: nbFoo42 ^ 42 So, here the numbers: Time to run via #primitiveNativeCall : [100000000 timesRepeat: [ MyClass nbFoo2 ] ] timeToRun 6995 Time to run via JIT: [100000000 timesRepeat: [ MyClass nbFoo ] ] timeToRun 897 Time to run JITed method: [100000000 timesRepeat: [ MyClass nbFoo42 ] ] timeToRun 899 so, as you can see, the JITed method and our custom generated code is on par (which is logical ;). Time to run an empty loop: [100000000 timesRepeat: [ ] ] timeToRun 679 So, here the result, if we extract the loop overhead, we can see the difference in calling our native code when it uses JIT vs using #primitiveNativeCall : (6995 - 679 ) / (897- 679) asFloat 28.972477064220183 28 times faster!!!! So, with this new feature, we now can make our generated code to run with unmatched speed, without overhead related to #primitiveNativeCall. This is especially useful for implementing primives which involving heavy numeric crunching. I would release this code to public, but there's one little discrepancy i need to deal with first: (one little problem, which i hope Eliot can help to solve) it looks like primitivePerform: never enters the JIT mode, but always executing the method via interpreter. This is why you see this code: [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self nbFoo ]. because if i do it inside of NBNativeCodeGen>>jitMethodAssembly:, which checks for same error and retries the send using perform primitive, it never enters the JIT mode, resulting in endless loop :( This is despite the fact that method is JITed, because we enforce the JITing of that method during error handling: lastError = ErrRunningViaInterpreter ifTrue: [ "a method contains native code, but executed by interpreter " method forceJIT ifFalse: [ self error: 'Failed to JIT the compiled method. Try reducing it''s size ' ]. ^ self retrySend: aContext ]. The #forceJit is the primitive which i implemented like following: primitiveForceJIT <export: true > | val result | val := self stackTop. (self isIntegerObject: val) ifTrue: [ ^ self primitiveFail ]. (self isCompiledMethod: val) ifFalse: [ ^ self primitiveFail ]. (self methodHasCogMethod: val) ifFalse: [ cogit cog: val selector: objectMemory nilObject ]. result := (self methodHasCogMethod: val ) ifTrue: [ objectMemory trueObject ] ifFalse: [ objectMemory falseObject ]. ^ self pop: 1 thenPush: result. As you can see from its usage, if VM, for some reason will fail to jit the method, the primitive will answer false, and we will stop with an error.. Which apparently never happens. Still, a #primitivePerform seems like ignoring that the method contains machine code an always runs it interpreted :( I do not like the idea, that users will be forced to manually put such loops in every method they will write.. any ideas/suggestions how to overcome that? -- Best regards, Igor Stasenko.

Sept. 21, 2012

Re: [Pharo-project] FS-Bug render Pharo 2.0 useless on Win (Issue 6531)

by Guillermo Polito

Today we were checking it with Ezequiel(he has a windowze machine). The problem seems to be in StandardFileStream>>open: fileName forWrite: writeMode ... fileID := StandardFileStream retryWithGC:[self primOpen: f writable: writeMode] until:[:id| id notNil] forFileNamed: fileName. ... that expression yields nil in Windows while in Mac/Unix it yields a file handle. Still looking at it. On Wed, Sep 19, 2012 at 10:29 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Anyone with deeper knowledge on FS code able to > have a look at issue 6531 - "Not possible to save one click > image on Windows" > > http://code.google.com/p/pharo/issues/detail?id=6531 > > I found the original cause - it crashes since the code > will open the changes file for a second time. > The reason is that FileStream(class)>>onHandle: > will not really work on an existing handle - and instead > opens the file again. It's easy to debug (see the bug entry > what to evaluate in a workspace). > > I'm not that familiar with the design and implementation > of the new file system. To me it looks like it is not > a bug but merely just unfinished in the transition from > new to old filesystem. > > Maybe someone with better knowledge of the intentions > of the new file system can help fixing it - and assure > it works on all platforms afterwards. Thanks in advance! > > Bye > T. > > > > > > >

Sept. 21, 2012

Re: [Pharo-project] FS-Bug render Pharo 2.0 useless on Win (Issue 6531)

by Camillo Bruni

On 2012-09-21, at 16:35, Torsten Bergmann <astares(a)gmx.de> wrote: >> Maybe someone with better knowledge of the intentions >> of the new file system can help fixing it > > <humor> > So many responses ... ?! Please - one after the other. > Please do not push ... and yes, it would be good if we > fix this before we overtake the world > </humor> The bug report did not get unnoticed, however - Windows Slave is down - Admins don't fix the Windows Slave - Nobody works regularly on Windows here to fix / test - We're moving our whole lab next monday - New servers are on the way so we will certainly do a pass here in the next time :) until then you might try to simply hack it together so it mostly works, then we can have a look at it and polish it :)

Sept. 21, 2012

[Pharo-project] FS-Bug render Pharo 2.0 useless on Win (Issue 6531)

by Torsten Bergmann

>Maybe someone with better knowledge of the intentions >of the new file system can help fixing it <humor> So many responses ... ?! Please - one after the other. Please do not push ... and yes, it would be good if we fix this before we overtake the world </humor> Thx T.

Sept. 21, 2012

[Pharo-project] headless CogVM on Windows

by Torsten Bergmann

>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) The regulary Squeak VM for Windows is able to do just that. It runs Smalltalk as an NT service by using the option "-service" See http://wiki.squeak.org/squeak/105 Dont know if this also works on Cog/Pharo standard VM. Bye T.

Sept. 21, 2012

Re: [Pharo-project] headless CogVM on Windows

by Esteban Lorenzano

yeah... we need a real headless mode (no systry, nothing... just a deamon running) On Sep 21, 2012, at 2:52 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > hmm :-( at least older Windows VM versions started directly to systray. > > -- Pavel > > On Fri, Sep 21, 2012 at 2:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> that was always like that... headless mode is not actually headless in any of the platforms. >> >> Esteban >> >> On Sep 21, 2012, at 2:27 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> Hi, >>> >>> it seems that the headless mode in CogVM on Windows is not working >>> well. It always opens a window and the only difference from the normal >>> start is that it uses minimalization to systray. As far as I know the >>> older windows VMs always used systray (bad) but without the initial >>> window opening. >>> >>> -- Pavel >>> >> >> >

Sept. 21, 2012

Re: [Pharo-project] headless CogVM on Windows

by Pavel Krivanek

hmm :-( at least older Windows VM versions started directly to systray. -- Pavel On Fri, Sep 21, 2012 at 2:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that was always like that... headless mode is not actually headless in any of the platforms. > > Esteban > > On Sep 21, 2012, at 2:27 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> it seems that the headless mode in CogVM on Windows is not working >> well. It always opens a window and the only difference from the normal >> start is that it uses minimalization to systray. As far as I know the >> older windows VMs always used systray (bad) but without the initial >> window opening. >> >> -- Pavel >> > >

Sept. 21, 2012