June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] how slower is called a named primitive over a numbered primitive?

by David T. Lewis

On Mon, Jun 22, 2015 at 11:05:30AM -0700, Eliot Miranda wrote: > On Mon, Jun 22, 2015 at 9:35 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > That sounds right to me too. But it would be a worthwhile experiment to > > set up a test to confirm it. Maybe take one or more methods that call > > numbered primitives, and recode them to call the primitives by name. Then > > measure and see if anything got slower. > > > > Dave > > > > On Mon, Jun 22, 2015 at 10:40 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi Esteban, > > > > you can set up a test using the LargeInteger comparison primitives. > > They're both named and numberd. e.g. > > > > 23 primitiveLessThanLargeIntegers > > > > So you can write e.g. > > > > LargePositiveInteger>>#< anInteger > > "Primitive. Compare the receiver with the argument and answer true if > > the receiver is less than the argument. Otherwise answer false. Fail if the > > argument is not a SmallInteger or a LargePositiveInteger less than > > 2-to-the-30th (1073741824). > > Optional. See Object documentation whatIsAPrimitive." > > > > <primitive: 23> > > ^super < anInteger > > > > as > > > > numberedLessThan: anInteger > > "Primitive. Compare the receiver with the argument and answer true if > > the receiver is less than the argument. Otherwise answer false. Fail if the > > argument is not a SmallInteger or a LargePositiveInteger less than > > 2-to-the-30th (1073741824). > > Optional. See Object documentation whatIsAPrimitive." > > > > <primitive: 23> > > ^super < anInteger > > > > > > namedLessThan: anInteger > > "Primitive. Compare the receiver with the argument and answer true if > > the receiver is less than the argument. Otherwise answer false. Fail if the > > argument is not a SmallInteger or a LargePositiveInteger less than > > 2-to-the-30th (1073741824). > > Optional. See Object documentation whatIsAPrimitive." > > > > <primitive: 'primitiveLessThanLargeIntegers'> > > ^super < anInteger > > > > and test it with two suitable large integers. Will you report back? I'd > > like to know the answer. Named primitive invocation should be slightly > > slower. As Cl??ment says, a return different address is written to the > > stack, overwriting the primitive code, but that return path is essentially > > the same as for numbered primtiives. So I expect that there will be almost > > no measurable difference. > > > > Wow, it is indeed a significant difference. Substituting the return > address must invoke all sorts of cost in an x86 cpu. Here are 2 x 5 runs > > > | i | i := SmallInteger maxVal + 1. > (1 to: 6) collect: [:j| {[1 to: 10000000 do: [:k| i numberedLessThan: i]] > timeToRun. [1 to: 10000000 do: [:k| i namedLessThan: i]] timeToRun}] > > #(#(191 283) #(211 375) #(281 405) #(300 411) #(281 421) #(296 409)) > #(#(186 267) #(201 273) #(210 364) #(294 410) #(313 400) #(292 405)) > > So the overhead is of the order of (100ms / 10,000,000) per call. e.g. > around 10ns per named primitive call. Interesting :-) On an interpreter VM, the results are as Tim and I initially expected: | i | i := SmallInteger maxVal + 1. (1 to: 6) collect: [:j| {[1 to: 10000000 do: [:k| i numberedLessThan: i]] timeToRun. [1 to: 10000000 do: [:k| i namedLessThan: i]] timeToRun}] ==> #(#(791 789) #(793 794) #(793 790) #(791 791) #(790 794) #(795 789)) With a Cog VM, the numbered primitives are significantly faster: | i | i := SmallInteger maxVal + 1. (1 to: 6) collect: [:j| {[1 to: 10000000 do: [:k| i numberedLessThan: i]] timeToRun. [1 to: 10000000 do: [:k| i namedLessThan: i]] timeToRun}] ==> #(#(542 670) #(542 668) #(544 678) #(546 680) #(540 666) #(540 680)) On Mon, Jun 22, 2015 at 07:16:43PM +0200, Cl??ment Bera wrote: > > Well it also depends if the primitive is generated by the JIT. If you > rewrite SmallInteger>>#+ from primitive 1 to a named primitive the overhead > will be more important than just the searching/loading/linking because the > JIT won't compile it to n-code anymore. So maybe this is the reason for the difference. Note: this is with an old Cog VM, because I lost my primary PC and can't restore it right now. But I think the results are relevant WRT this discussion. /usr/local/lib/squeak/4.0-2776/squeak Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] Dave

June 23, 2015

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Nicolai Hess

2014-12-18 22:32 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Iâm ready to help with this issue, but as far as I can tell, itâs not hard > to implement the mentors. Here we should decide on the meaning of the > phrases. What are "all behaviorsâ and so on. The reason of the refactoring > that Iâve done was that there were two methods with similar names that were > doing different things. > > Uko > > On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi, > > some time ago Yuriy cleaned up the RBBrowserEnvironment methods for > allClassesAndTraits(Do), classesDo, .... > > The fix was good and necessary (I think). But they had an impact > on some SmallLint-rules (they arent applied on the class side) and the > behavior > for the different Environments changed (compared with Pharo3 > (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some > RBBrowserEnvironments don't work well with Metaclasses)) > > As some SmallLint-rules need to iterate over the metaclasses as well and > I don't want to revert Yuriys change, I 'll add another method that > collect classes and metaclasses. > > So, I need some help, how to name this methods: > > all classes (Object, Integer, ....) -> allClasses, ok > all classes and metaclasses (Object, Object class, Integer class ) -> ? > allBehaviors? > all classes and traits -> allClassesAndTraits, ok > all classes and meta classes and traits and class traits -> ? no idea! > all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't > know if we need this > > One problem with "allBehaviors" is, SystemNavigation uses allBehaviors to > iterate > over classes, metaclasses, traits and class traits, > allthough a Trait is not a Behavior. (TClass isBehavior -> false) > > feedback is welcome > > > nicolai > > > > Pharo 3.0: SystemNavigation default allClasses size. 4024 Smalltalk allClasses size. 4024. RBBrowserEnvironment default allClasses size. 4024 RBBrowserEnvironment default classes size. 8048 Pharo 4.0: SystemNavigation default allClasses size. 5012 Smalltalk allClasses size. 5012 RBBrowserEnvironment default allClasses size. 5012 RBBrowserEnvironment default classes size. 5012 -> I "define" the Pharo 4.0 behavior as the correct one. RBEnvironment>>#classes should not contain meta classes. Some other RBEnvironments and/or RBRules rely on the "classes = classes and metaclasses" (-> see issue 14621 <https://pharo.fogbugz.com/default.asp?14621> Some RBBrowserEnvironments don't work well with Metaclasses 14230 <https://pharo.fogbugz.com/default.asp?14230> Some rules aren't applied on the classside anymore 15302 <https://pharo.fogbugz.com/default.asp?15302> a RBEnvironment from #referencesTo: does not list meta classes I will change them, and if appropiate, add a new classesAndMetaclasses resp. classesAndMetaclassesDo: I don't know about classesAndMetaclassesTraits. And I skip "behaviors" for now. #allBehaviors is suspicious to me, I still don't know what they are: Smalltalk globals allBehaviors includes:TBehavior. -> true (1) TBehavior isBehavior. -> false (!)

June 22, 2015

Re: [Pharo-dev] [Vm-dev] how slower is called a named primitive over a numbered primitive?

by Eliot Miranda

On Mon, Jun 22, 2015 at 9:35 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > That sounds right to me too. But it would be a worthwhile experiment to > set up a test to confirm it. Maybe take one or more methods that call > numbered primitives, and recode them to call the primitives by name. Then > measure and see if anything got slower. > > Dave > On Mon, Jun 22, 2015 at 10:40 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Esteban, > > you can set up a test using the LargeInteger comparison primitives. > They're both named and numberd. e.g. > > 23 primitiveLessThanLargeIntegers > > So you can write e.g. > > LargePositiveInteger>>#< anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > as > > numberedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > > namedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 'primitiveLessThanLargeIntegers'> > ^super < anInteger > > and test it with two suitable large integers. Will you report back? I'd > like to know the answer. Named primitive invocation should be slightly > slower. As ClÃ©ment says, a return different address is written to the > stack, overwriting the primitive code, but that return path is essentially > the same as for numbered primtiives. So I expect that there will be almost > no measurable difference. > Wow, it is indeed a significant difference. Substituting the return address must invoke all sorts of cost in an x86 cpu. Here are 2 x 5 runs | i | i := SmallInteger maxVal + 1. (1 to: 6) collect: [:j| {[1 to: 10000000 do: [:k| i numberedLessThan: i]] timeToRun. [1 to: 10000000 do: [:k| i namedLessThan: i]] timeToRun}] #(#(191 283) #(211 375) #(281 405) #(300 411) #(281 421) #(296 409)) #(#(186 267) #(201 273) #(210 364) #(294 410) #(313 400) #(292 405)) So the overhead is of the order of (100ms / 10,000,000) per call. e.g. around 10ns per named primitive call. Interesting :-) > > This is all to do with callbacks. Numbered primitives are assumed never > to callback (so far that's a valid assumption). But named primitives (such > as an FFI call) may indeed callback and hence, by the time the primitive > finally returns the code zone may have been compacted and the original > method containing the callout may have moved. So the VM can't simply > return to a primitive that may have called back, and then have that > primitive's code return form the primitive, because that codee may have > moved. The solution is to provide a piece of code at a fixed address that > returns from a named primitive call, and have the return sequence run that > code. > > On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> Hi, >> >> Any idea how slower is? I mean, any measure/estimation/something around? >> >> cheers, >> Esteban >> >> > > > -- > best, > Eliot > -- best, Eliot

June 22, 2015

Re: [Pharo-dev] [Vm-dev] how slower is called a named primitive over a numbered primitive?

by Esteban Lorenzano

> On 22 Jun 2015, at 19:47, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Jun 22, 2015 at 10:40 AM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > Hi Esteban, > > you can set up a test using the LargeInteger comparison primitives. They're both named and numberd. e.g. > > 23 primitiveLessThanLargeIntegers > > So you can write e.g. > > LargePositiveInteger>>#< anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > as > > numberedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > > namedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 'primitiveLessThanLargeIntegers'> > ^super < anInteger > > and test it with two suitable large integers. Will you report back? I'd like to know the answer. Named primitive invocation should be slightly slower. As ClÃ©ment says, a return different address is written to the stack, overwriting the primitive code, but that return path is essentially the same as for numbered primtiives. So I expect that there will be almost no measurable difference. > > This is all to do with callbacks. Numbered primitives are assumed never to callback (so far that's a valid assumption). But named primitives (such as an FFI call) may indeed callback and hence, by the time the primitive finally returns the code zone may have been compacted and the original method containing the callout may have moved. So the VM can't simply return to a primitive that may have called back, and then have that primitive's code return form the primitive, because that codee may have moved. The solution is to provide a piece of code at a fixed address that returns from a named primitive call, and have the return sequence run that code. > > I should have said that numbered primitives other than 117 (primitiveExternalCall) & 120 (primitiveCalloutToFFI) are assumed never to call-back. In fact, the VM code in primitivePropertyFlagsForSpur: & primitivePropertyFlagsForV3: won't set the required flags to tell the Cogit to substitute the return address if you use primitiveCalloutWithArgs as a named primitive instead of 120 as a numbered primitive. So please use 120. Anyway, the test should demonstrate that there's no difference. > > If you /do/ want to use primitiveCalloutWithArgs instead of 120 then primitivePropertyFlagsForSpur: & primitivePropertyFlagsForV3: are going to get more complicated. The system is currently setup for the FFP plugin to be unloaded and hence the system made secure by not shipping the FFI plugin. But including a reference to primitiveCalloutWithArgs in the main VM needs to be done carefully to avoid having to link the FFI plugin into the VM. So this should be done with e.g. a > self cppIf: PharoVM ifTrue: ... > idiom. I will not change anything until I actually find a reason to do itâ¦ and if I find a reason, I will discuss it here, so do not worry about. Right now Iâm just wondering, because Iâm writing the NB to FFI backend and Iâm thinking on better ways to do itâ¦ and since this is all while we wait for the new FFI implementation, most probably everything can waitâ¦ but, it would be nice to actually know the numbers, instead just guessingâ¦ :) Esteban > > > On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > Hi, > > Any idea how slower is? I mean, any measure/estimation/something around? > > cheers, > Esteban > > > > > -- > best, > Eliot > > > > -- > best, > Eliot

June 22, 2015

Re: [Pharo-dev] [Vm-dev] how slower is called a named primitive over a numbered primitive?

by Eliot Miranda

On Mon, Jun 22, 2015 at 10:40 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Esteban, > > you can set up a test using the LargeInteger comparison primitives. > They're both named and numberd. e.g. > > 23 primitiveLessThanLargeIntegers > > So you can write e.g. > > LargePositiveInteger>>#< anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > as > > numberedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 23> > ^super < anInteger > > > namedLessThan: anInteger > "Primitive. Compare the receiver with the argument and answer true if > the receiver is less than the argument. Otherwise answer false. Fail if the > argument is not a SmallInteger or a LargePositiveInteger less than > 2-to-the-30th (1073741824). > Optional. See Object documentation whatIsAPrimitive." > > <primitive: 'primitiveLessThanLargeIntegers'> > ^super < anInteger > > and test it with two suitable large integers. Will you report back? I'd > like to know the answer. Named primitive invocation should be slightly > slower. As ClÃ©ment says, a return different address is written to the > stack, overwriting the primitive code, but that return path is essentially > the same as for numbered primtiives. So I expect that there will be almost > no measurable difference. > > This is all to do with callbacks. Numbered primitives are assumed never > to callback (so far that's a valid assumption). But named primitives (such > as an FFI call) may indeed callback and hence, by the time the primitive > finally returns the code zone may have been compacted and the original > method containing the callout may have moved. So the VM can't simply > return to a primitive that may have called back, and then have that > primitive's code return form the primitive, because that codee may have > moved. The solution is to provide a piece of code at a fixed address that > returns from a named primitive call, and have the return sequence run that > code. > I should have said that numbered primitives other than 117 (primitiveExternalCall) & 120 (primitiveCalloutToFFI) are assumed never to call-back. In fact, the VM code in primitivePropertyFlagsForSpur: & primitivePropertyFlagsForV3: won't set the required flags to tell the Cogit to substitute the return address if you use primitiveCalloutWithArgs as a named primitive instead of 120 as a numbered primitive. So please use 120. Anyway, the test should demonstrate that there's no difference. If you /do/ want to use primitiveCalloutWithArgs instead of 120 then primitivePropertyFlagsForSpur: & primitivePropertyFlagsForV3: are going to get more complicated. The system is currently setup for the FFP plugin to be unloaded and hence the system made secure by not shipping the FFI plugin. But including a reference to primitiveCalloutWithArgs in the main VM needs to be done carefully to avoid having to link the FFI plugin into the VM. So this should be done with e.g. a self cppIf: PharoVM ifTrue: ... idiom. > On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> Hi, >> >> Any idea how slower is? I mean, any measure/estimation/something around? >> >> cheers, >> Esteban >> >> > > > -- > best, > Eliot > -- best, Eliot

June 22, 2015

Re: [Pharo-dev] [Vm-dev] how slower is called a named primitive over a numbered primitive?

by Eliot Miranda

Hi Esteban, you can set up a test using the LargeInteger comparison primitives. They're both named and numberd. e.g. 23 primitiveLessThanLargeIntegers So you can write e.g. LargePositiveInteger>>#< anInteger "Primitive. Compare the receiver with the argument and answer true if the receiver is less than the argument. Otherwise answer false. Fail if the argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). Optional. See Object documentation whatIsAPrimitive." <primitive: 23> ^super < anInteger as numberedLessThan: anInteger "Primitive. Compare the receiver with the argument and answer true if the receiver is less than the argument. Otherwise answer false. Fail if the argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). Optional. See Object documentation whatIsAPrimitive." <primitive: 23> ^super < anInteger namedLessThan: anInteger "Primitive. Compare the receiver with the argument and answer true if the receiver is less than the argument. Otherwise answer false. Fail if the argument is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). Optional. See Object documentation whatIsAPrimitive." <primitive: 'primitiveLessThanLargeIntegers'> ^super < anInteger and test it with two suitable large integers. Will you report back? I'd like to know the answer. Named primitive invocation should be slightly slower. As ClÃ©ment says, a return different address is written to the stack, overwriting the primitive code, but that return path is essentially the same as for numbered primtiives. So I expect that there will be almost no measurable difference. This is all to do with callbacks. Numbered primitives are assumed never to callback (so far that's a valid assumption). But named primitives (such as an FFI call) may indeed callback and hence, by the time the primitive finally returns the code zone may have been compacted and the original method containing the callout may have moved. So the VM can't simply return to a primitive that may have called back, and then have that primitive's code return form the primitive, because that codee may have moved. The solution is to provide a piece of code at a fixed address that returns from a named primitive call, and have the return sequence run that code. On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Any idea how slower is? I mean, any measure/estimation/something around? > > cheers, > Esteban > > -- best, Eliot

June 22, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50128 Home: https://github.com/pharo-project/pharo-core

June 22, 2015

[pharo-project/pharo-core] 4be78a: 50128

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4be78ab29757a890f66a76a5260f06dd5481dee1 https://github.com/pharo-project/pharo-core/commit/4be78ab29757a890f66a76a5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-22 (Mon, 22 Jun 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50127.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50128.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50127.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50128.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Sources.package/SourceFileArray.class/definition.st A System-Sources.package/SourceFileArray.class/instance/to remove/at_ifAbsent_.st M System-Sources.package/SourceFileArray.class/instance/to remove/collect_.st Log Message: ----------- 50128 15818 Clean up discouraged uses of SourceFiles and friends (7) https://pharo.fogbugz.com/f/cases/15818 http://files.pharo.org/image/50/50128.zip

June 22, 2015

Re: [Pharo-dev] Pay attention recent changes in the source manager can lead to loss of code

by Martin Dias

Hi, it's possible that this error while filing-in in 50109 was my fault when touching the source files management. I'm sorry for this mistake... fixed it some days after integration. MartÃn On Fri, Jun 19, 2015 at 9:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And possibly worse, in my image, #50109, recovering lost changes is broken > (fails to file in chunks) - maybe that is already fixed. > > > On 19 Jun 2015, at 21:43, stepharo <stepharo(a)free.fr> wrote: > > > > I experienced that and lost my changes. > > > > Stef > > > > >

June 22, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50127 Home: https://github.com/pharo-project/pharo-core

June 22, 2015