2011/10/12 Levente Uzonyi <[email protected]> > On Thu, 13 Oct 2011, Igor Stasenko wrote: > > On 12 October 2011 23:22, Levente Uzonyi <[email protected]> wrote: >> >>> On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: >>> >>> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <[email protected]> wrote: >>>> >>>> On Wed, 12 Oct 2011, Clara Allende wrote: >>>>> >>>>> Hi guys, >>>>> >>>>>> >>>>>> I'm wondering, why? >>>>>> >>>>>> ProtoObject>> ~~ anObject >>>>>> "Answer whether the receiver and the argument are not the same object >>>>>> (do not have the same object pointer)." >>>>>> >>>>>> self == anObject >>>>>> ifTrue: [^ false] >>>>>> ifFalse: [^ true] >>>>>> >>>>>> >>>>>> Hi Carla. I can think about two things. The first one, is the one >>>> Levente >>>> said, performance. >>>> If you analyze the bycode of this method, you will see that it is >>>> extremely >>>> fast because: >>>> >>>> 1) #== has an special associated bytecode, that is, them VM maps such >>>> bytecode to an specific primitive and it is directly executed. It means >>>> that >>>> the method #== is really never sent. >>>> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, >>>> it >>>> method is never executed and instead the compiler replace a message send >>>> bytecode with jump ones. >>>> >>>> Another possible reason (it may not be the case, but in another places >>>> it >>>> is), is to prevent VM interruption for check other processes. In >>>> summary, >>>> the VM checks whether it should execute another process of the queue >>>> after >>>> a >>>> method execution. As you know, some parts of the scheduling process is >>>> done >>>> at the image side. And from there we lack a way to say to the VM, >>>> "please >>>> execute this method without checking others processes". Hence, in a few >>>> yet >>>> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used >>>> as >>>> a >>>> mean of executing something WITHOUT being interrupted. I can imagine >>>> that >>>> it >>>> may happen the same with #~~. So if you implement such method with a >>>> #not, >>>> you will indeed send a message, proving a possibilty to be interrupted. >>>> >>> >>> I don't see how this would be a reason. When you send #~~, then you >>> explicitly allow a suspension point, so not using #not won't avoid >>> suspension points. >>> >>> >> To my thinking, in a first place, i would ask: >> why instead of fixing the code which may be affected by having or not >> suspension points, >> we introducing new workarounds ?? >> > > Which code needs to be fixed? > > > >> I think it is bad excuse for introduction of new primitive. >> If we miss some atomicity for semaphores, lets add a primitive(s) >> which fixing the semaphore issue(s). >> > > Are there any issues with semaphores? > > > But introducing new primitive to avoid suspension?!?! i cannot follow >> this line of thinking. >> > > I guess you're not replying to my mail, but Eliot's. Btw there's no such > "line of thinking". He didn't add the primitive for #~~ to avoid a > suspension point, but to improve it's performance. >
+1. The primitive is nearly twice as fast as the old method in my measurements, which are these: | null | null := Time millisecondsToRun: [1 to: 1000000000 do: [:i| i - i]]. "- is an inlined" (Time millisecondsToRun: [1 to: 1000000000 do: [:i| i ~~ i]]) - null I got about 1200 ms before the primitive, about 660 afterwards, but there's noise to contend with. Anyway, significantly faster. > > Levente > > > >> >>>> Another reasons, similar to the previous one, is that sometimes #== is >>>> also >>>> used as a way to avoid executing method. So..there are some methods (I >>>> don't >>>> remember if #allInstancesDo: or #allObjectsDo:) will loop forever >>>> because >>>> >>> >>> #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: >>> uses a >>> custom marker object, so creating new objects won't cause infinite loop >>> (because gc doesn't change the order of any two objects). >>> >>> the loop condition would be creating objects (remember that method >>>> execution >>>> creates objects such as MethodContext). >>>> >>> >>> Contexts object are not created until requested and these loops don't >>> need >>> contexts. Some old methods interating through all/some objects use 0 as >>> the >>> marker object. These may have problems with objects created during their >>> loops. >>> >>> >>> Levente >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> -- best, Eliot
