- Pharo-users - lists.pharo.org

Re: [Pharo-users] New to Pharo and working on a small project

by Sean P. DeNigris

Pernet Alexis wrote > Hello everyone! Welcome! Keep us posted :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-to-Pharo-and-working-on-a-small-project-tp4772370… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 7, 2014

New to Pharo and working on a small project

by Pernet Alexis

Aug. 7, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by Thomas Bany

I forgot the copying of the data from the object heap to C heap: *MyClass*>>withNBCall externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray size. output := *NBExternalArrayOfDoubles *new: 4. 1 to: *self *internalArray size. do: [ :index | externalArray at: index (put: *self *internalArray at: index) ]. [*self *actualNBCallWith: externalArray adress storeResultIn: output adress] ensure: [externalArray free. output free]. *MyClass*>>withNBCallCommented externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray size. output := *NBExternalArrayOfDoubles *new: 4. 1 to: *self *internalArray size. do: [ :index | externalArray at: index (put: *self *internalArray at: index) ]. ["self actualNBCallWith: externalArray adress storeResultIn: output adress"] ensure: [externalArray free. output free]. Thomas. 2014-08-07 19:15 GMT+02:00 Thomas Bany <mun.sysdev(a)gmail.com>: > @ Alexandre: sure, no problem ! > > @ Luc: > > I'm not sure how much code I can provide without being to specific, but > here is how it goes : > > > - *Let's say I have the Smalltalk code bellow:* > > *MyClass*>>withNBCall > externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray > size. > output := *NBExternalArrayOfDoubles *new: 4. > [*self *actualNBCallWith: externalArray adress storeResultIn: output adress] > ensure: [externalArray free. output free]. > > *MyClass*>>withNBCallCommented > externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray > size. > output := *NBExternalArrayOfDoubles *new: 4. > ["self actualNBCallWith: externalArray adress storeResultIn: output > adress"] ensure: [externalArray free. output free]. > > *MyClass*>>actualNBCallWith: externalArray storeResultIn: output > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: > errorCode> > ^*self *nbCall: #(void callToC(double * externalArray, double * > output)) module: 'lib/myModule.dll' > > > - *And the C code bellow:* > > *void *callToC(*double ** externalArray, *double ** output) { > computationWith(externalArray, output); > } > > *void *specialCallToC(*double ** externalArray, *double ** output) { > * unsigned int* i; > *for *(i = 0; i < 24*3600; i++) > computationWith(externalArray, output); > } > > > - *Now I have the following code typed in Time Profiler tool :* > > object := (*MyClass *new) variousInitialization; yourself > 24*3600 timesRepeat: [object withNBCall] > >> Over 1 minute computation time of which over 99% are primitives. Also I > don't see the nbCall: in the tree. > > object := (*MyClass *new) variousInitialization; yourself > 24*3600 timesRepeat: [object withNBCallCommented] > >> Less than 1 second. > > object := (*MyClass *new) variousInitialization; yourself > object withNBCall > >> Less than 1 millisecond. > > object := (*MyClass *new) variousInitialization; yourself > object withNBSpecialCall "This time, I use the specialCallToC() function" > >> Arround 20 millisecond. > > > Allright, that's a pile of code but I hope it help :) > > On a side note: > > - Pharo 3, Win 7 32-bit > - I'm not at work anymore and don't have my code with me. So I will > double check tomorow that I didn't provided false informations but I think > it's accurate of what I do. > > > Again, thanks for the interest on my issue ! > > Thomas. > > > > 2014-08-07 18:39 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > I think that if you posted the code , preferably that contains only the >> problem would be easier to test , debug and investigate. >> >> >> >> On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany <mun.sysdev(a)gmail.com> wrote: >> >>> Hi everyone, >>> >>> I'm trying to reduce the computation time of the following pseudo-code: >>> >>> - memory allocation (~40 doubles) >>> - object heap to C heap copying >>> - NativeBoost call (nbCall:) >>> - memory freeing >>> >>> The time profiling results are bellow: >>> >>> - 24*3600 calls : > 1 minute >>> - 24*3600 calls with only memory allocation and copying : < 1 second >>> - 1 call with a 24*3600 loop inside de C code : < 1 second >>> >>> So it appears that the very coslty step is the transition from Pharo to >>> C. And I was wondering if it was possible to drasticly reduce this time by >>> doing something like, generate the the machine code once and call it >>> multiple time ? >>> >>> Thanks in advance ! >>> >>> Thomas. >>> >> >> >

Aug. 7, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by Thomas Bany

@ Alexandre: sure, no problem ! @ Luc: I'm not sure how much code I can provide without being to specific, but here is how it goes : - *Let's say I have the Smalltalk code bellow:* *MyClass*>>withNBCall externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray size. output := *NBExternalArrayOfDoubles *new: 4. [*self *actualNBCallWith: externalArray adress storeResultIn: output adress] ensure: [externalArray free. output free]. *MyClass*>>withNBCallCommented externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray size. output := *NBExternalArrayOfDoubles *new: 4. ["self actualNBCallWith: externalArray adress storeResultIn: output adress"] ensure: [externalArray free. output free]. *MyClass*>>actualNBCallWith: externalArray storeResultIn: output <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: errorCode> ^*self *nbCall: #(void callToC(double * externalArray, double * output)) module: 'lib/myModule.dll' - *And the C code bellow:* *void *callToC(*double ** externalArray, *double ** output) { computationWith(externalArray, output); } *void *specialCallToC(*double ** externalArray, *double ** output) { * unsigned int* i; *for *(i = 0; i < 24*3600; i++) computationWith(externalArray, output); } - *Now I have the following code typed in Time Profiler tool :* object := (*MyClass *new) variousInitialization; yourself 24*3600 timesRepeat: [object withNBCall] >> Over 1 minute computation time of which over 99% are primitives. Also I don't see the nbCall: in the tree. object := (*MyClass *new) variousInitialization; yourself 24*3600 timesRepeat: [object withNBCallCommented] >> Less than 1 second. object := (*MyClass *new) variousInitialization; yourself object withNBCall >> Less than 1 millisecond. object := (*MyClass *new) variousInitialization; yourself object withNBSpecialCall "This time, I use the specialCallToC() function" >> Arround 20 millisecond. Allright, that's a pile of code but I hope it help :) On a side note: - Pharo 3, Win 7 32-bit - I'm not at work anymore and don't have my code with me. So I will double check tomorow that I didn't provided false informations but I think it's accurate of what I do. Again, thanks for the interest on my issue ! Thomas. 2014-08-07 18:39 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > I think that if you posted the code , preferably that contains only the > problem would be easier to test , debug and investigate. > > > > On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany <mun.sysdev(a)gmail.com> wrote: > >> Hi everyone, >> >> I'm trying to reduce the computation time of the following pseudo-code: >> >> - memory allocation (~40 doubles) >> - object heap to C heap copying >> - NativeBoost call (nbCall:) >> - memory freeing >> >> The time profiling results are bellow: >> >> - 24*3600 calls : > 1 minute >> - 24*3600 calls with only memory allocation and copying : < 1 second >> - 1 call with a 24*3600 loop inside de C code : < 1 second >> >> So it appears that the very coslty step is the transition from Pharo to >> C. And I was wondering if it was possible to drasticly reduce this time by >> doing something like, generate the the machine code once and call it >> multiple time ? >> >> Thanks in advance ! >> >> Thomas. >> > >

Aug. 7, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by kilon alios

I think that if you posted the code , preferably that contains only the problem would be easier to test , debug and investigate. On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany <mun.sysdev(a)gmail.com> wrote: > Hi everyone, > > I'm trying to reduce the computation time of the following pseudo-code: > > - memory allocation (~40 doubles) > - object heap to C heap copying > - NativeBoost call (nbCall:) > - memory freeing > > The time profiling results are bellow: > > - 24*3600 calls : > 1 minute > - 24*3600 calls with only memory allocation and copying : < 1 second > - 1 call with a 24*3600 loop inside de C code : < 1 second > > So it appears that the very coslty step is the transition from Pharo to C. > And I was wondering if it was possible to drasticly reduce this time by > doing something like, generate the the machine code once and call it > multiple time ? > > Thanks in advance ! > > Thomas. >

Aug. 7, 2014

Re: [Pharo-users] Slice loading/merging differences question

by Mariano Martinez Peck

Hi Tim, Normally...a load simply loads that version you are telling to load. If you have local changes in any of the packages you will be loading, those changes will be LOST and overridden with the ones of the version you are loading. If you load via Monticello...if usually checks if you already have changes in the packages you are about to load and warns you or directly recommends you to merge (it depends which Pharo version you are working on). The merge...is for when you have local changes in that package you will load. Hence, the merge is the way so that you can merge your local changes and the changes coming from the new version you are about to load. It might have conflicts which need to be resolved. After you have merged, then you can commit your changes if you want. Also, note that you may also be trying to commit and there is a new version of the package from the one you started to change. Therefore, if you commit, you will override last version. Here, again, Monticello usually warns you. So what you would normally do here is a marge again, so that the changes from the last version gets merged with your local changes. After, you can commit without problems. Hope this is clear. Cheers, On Thu, Aug 7, 2014 at 1:15 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - I am still a bit confused about the difference between load vs. merge > with Monticello? > > Last month, when I tried to verify a bug fix, I did a load - and it caused > other things (dependencies?) to be loaded into my clean image and so I > ended up with something else in a broken state. So I had to do a Merge - > get just the specific fixes and I could prove everything worked. > > Yesterday however I wanted to test a fix Damien made for bug 13526. But > when I Merged it, I hit a DNU and then noticed he had put the following > comment (Slice .2 depends on 13787). > So I repeated the same merge step for 13787 and it then worked (apart from > another edge case I found and he has now fixed). > > But this has got me thinking, I donât really understand the difference > between merge/load. Can someone explain it to me in the above context? > Should I have âloadedâ 13526 so that it pulled in the dependency indicated? > (I notice in the slice description - it shows - Dependencies: > Tool-Base-DamienPollet.24). I thought Monticello managed dependencies - so > now Iâm confused why I need to do Merge anyway? > > Related to this, when the next âreleaseâ image gets built - how are these > slices assembled such that Tool-Base-DamienPollet.24 is correctly loaded > in release image? > > Thanks for any help. > > Tim > -- Mariano http://marianopeck.wordpress.com

Aug. 7, 2014

Slice loading/merging differences question

by Tim Mackinnon

Hi - I am still a bit confused about the difference between load vs. merge with Monticello? Last month, when I tried to verify a bug fix, I did a load - and it caused other things (dependencies?) to be loaded into my clean image and so I ended up with something else in a broken state. So I had to do a Merge - get just the specific fixes and I could prove everything worked. Yesterday however I wanted to test a fix Damien made for bug 13526. But when I Merged it, I hit a DNU and then noticed he had put the following comment (Slice .2 depends on 13787). So I repeated the same merge step for 13787 and it then worked (apart from another edge case I found and he has now fixed). But this has got me thinking, I donât really understand the difference between merge/load. Can someone explain it to me in the above context? Should I have âloadedâ 13526 so that it pulled in the dependency indicated? (I notice in the slice description - it shows - Dependencies: Tool-Base-DamienPollet.24). I thought Monticello managed dependencies - so now Iâm confused why I need to do Merge anyway? Related to this, when the next âreleaseâ image gets built - how are these slices assembled such that Tool-Base-DamienPollet.24 is correctly loaded in release image? Thanks for any help. Tim

Aug. 7, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by Alexandre Bergel

Hi Thomas, Please share with us how it goes. Your experience is important to us. Alexandre > Le 07-08-2014 Ã 11:25, Thomas Bany <mun.sysdev(a)gmail.com> a Ã©crit : > > Hi everyone, > > I'm trying to reduce the computation time of the following pseudo-code: > > - memory allocation (~40 doubles) > - object heap to C heap copying > - NativeBoost call (nbCall:) > - memory freeing > > The time profiling results are bellow: > > - 24*3600 calls : > 1 minute > - 24*3600 calls with only memory allocation and copying : < 1 second > - 1 call with a 24*3600 loop inside de C code : < 1 second > > So it appears that the very coslty step is the transition from Pharo to C. And I was wondering if it was possible to drasticly reduce this time by doing something like, generate the the machine code once and call it multiple time ? > > Thanks in advance ! > > Thomas.

Aug. 7, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by Luc Fabresse

Hi Thomas, 2014-08-07 17:25 GMT+02:00 Thomas Bany <mun.sysdev(a)gmail.com>: > Hi everyone, > > I'm trying to reduce the computation time of the following pseudo-code: > > - memory allocation (~40 doubles) > - object heap to C heap copying > - NativeBoost call (nbCall:) > - memory freeing > > The time profiling results are bellow: > > - 24*3600 calls : > 1 minute > - 24*3600 calls with only memory allocation and copying : < 1 second > - 1 call with a 24*3600 loop inside de C code : < 1 second > > So it appears that the very coslty step is the transition from Pharo to C. > And I was wondering if it was possible to drasticly reduce this time by > doing something like, generate the the machine code once and call it > multiple time ? > the machine code for the marshalling of the arguments is generated one time for all. so the penalty does not come from there. please send the code you wrote for these micro-benchs so I can better understand what happens. Luc > > Thanks in advance ! > > Thomas. >

Aug. 7, 2014

NativeBoost : optimisation of the machine code generation

by Thomas Bany

Hi everyone, I'm trying to reduce the computation time of the following pseudo-code: - memory allocation (~40 doubles) - object heap to C heap copying - NativeBoost call (nbCall:) - memory freeing The time profiling results are bellow: - 24*3600 calls : > 1 minute - 24*3600 calls with only memory allocation and copying : < 1 second - 1 call with a 24*3600 loop inside de C code : < 1 second So it appears that the very coslty step is the transition from Pharo to C. And I was wondering if it was possible to drasticly reduce this time by doing something like, generate the the machine code once and call it multiple time ? Thanks in advance ! Thomas.

Aug. 7, 2014