On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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. 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 the loop condition would be creating objects (remember that method execution creates objects such as MethodContext). So...again, I think it may happen the same with #~~. That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization. Cheers

Instead of:

...

ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

Levente

Thanks in advance!

...

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

On Wed, Oct 12, 2011 at 6:00 PM, Clara Allende <clari.allende@gmail.com>wrote:

Ok, now I get it :D Thanks a lot Mariano!

No problem :)

On 12 October 2011 12:49, Mariano Martinez Peck <marianopeck@gmail.com>wrote:

...

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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.

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 the loop condition would be creating objects (remember that method execution creates objects such as MethodContext). So...again, I think it may happen the same with #~~.

That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization.

Cheers

...

Instead of:

...

ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

Levente

Thanks in advance!

...

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

On Wed, Oct 12, 2011 at 6:02 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

Mariano please enhance the comments and publish them :)

I would like so.... but I would like that a real hacker tell me whether I am correct or not.

Stef

On Oct 12, 2011, at 5:49 PM, Mariano Martinez Peck wrote:

...

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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.

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 the loop condition would be creating objects (remember that method execution creates objects such as MethodContext). So...again, I think it may happen the same with #~~.

That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization.

Cheers

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

Levente

Thanks in advance! --

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

Excellent description. Just wondering: when the scheduling really happens? I thought that it is when you do a #yield or wait explicitely since scheduling is not preemptive. Cheers, Alexandre On 12 Oct 2011, at 12:49, Mariano Martinez Peck wrote:

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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.

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 the loop condition would be creating objects (remember that method execution creates objects such as MethodContext). So...again, I think it may happen the same with #~~.

That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization.

Cheers

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

Levente

Thanks in advance! --

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Ok, scheduling in Pharo may happen when sending a message. Thanks for the clarification. Cheers, Alexandre On 12 Oct 2011, at 13:40, Stéphane Ducasse wrote:

Alex

the vm should check condition from time to time and the place where it can check is at every message send. Since == is not a message send, when you write code with == or not even if it is semantically equivalent its execution may be different (it looks hackish).

Stef

On Oct 12, 2011, at 6:29 PM, Alexandre Bergel wrote:

...

Excellent description. Just wondering: when the scheduling really happens? I thought that it is when you do a #yield or wait explicitely since scheduling is not preemptive.

Cheers, Alexandre

On 12 Oct 2011, at 12:49, Mariano Martinez Peck wrote:

...

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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.

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 the loop condition would be creating objects (remember that method execution creates objects such as MethodContext). So...again, I think it may happen the same with #~~.

That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization.

Cheers

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

Levente

Thanks in advance! --

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- Mariano http://marianopeck.wordpress.com

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 12 October 2011 23:22, Levente Uzonyi <leves@elte.hu> wrote:

On Wed, 12 Oct 2011, Mariano Martinez Peck wrote:

...

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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 ?? 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). But introducing new primitive to avoid suspension?!?! i cannot follow this line of thinking.

...

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.

2011/10/12 Levente Uzonyi <leves@elte.hu>

On Thu, 13 Oct 2011, Igor Stasenko wrote:

On 12 October 2011 23:22, Levente Uzonyi <leves@elte.hu> wrote:

...

...

On Wed, 12 Oct 2011, Mariano Martinez Peck wrote:

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <leves@elte.hu> 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

Hi Do you mean you want to add this pragma "<primitive: 169>" in Object >> #~~ ? Or do you mean replacing #blockCopy: by #~~ in the special selectors to get it inlined by default like #== ? On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

Hi

It is been a while... So, do we want to replace ~~ with a primitive? :)

Cheers Alex

-- View this message in context: http://forum.world.st/About- and-tp3898409p4924391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Hi Clément, Hi All, On Thu, Nov 24, 2016 at 5:09 AM, Clément Bera <bera.clement@gmail.com> wrote:

Hi,

Support for primitive 169 for Object>>#~~ has been in the VM for a while. The default implementation in Squeak 5 uses this primitive for example.

I've just added today (VMMaker commit 2003) support for inlined #~~ like #== (including JIT support, branch pipelining, etc.). If one puts #~~ in the specialObjectsArray at the location of #blockCopy:, the bytecode compiler generates the special send bytecode for #~~ leading to improved performance and consistency between #== and #~~.

With today's update, the VM supports 3 inlined operations without any type checks: #==, #~~ and #class. It is possible to disable such optimisations in the bytecode compiler (In Pharo #class inlining is disabled there for example). Eliot would like to add support to disable these operations at VM level as a VM command line parameter too, and we may do it in the future.

Now this is for the VM support. It's up to the Pharo/Squeak/other community to decide what behavior they want in their runtime for these 3 selectors.

In my opinion, I believe that #~~ should be consistent with #==, hence they should be both inlined or both sends to primitives. I don't like the current situation in Pharo nor in Squeak.

Now when we look for solutions, we see that one of #== and #~~ needs to be a primitive (it's essential), hence it makes sense to have both Object>>#== and Object>>#~~ as primitives (with the primitive pragma in the method body). The inlining of #== and #~~ is arguable and I let the community decide what they believe is best for their runtime, though I would rather have the same behavior for both selectors.

In addition, for proxies, it makes sense to allow the system to not inline the primitives. Let me explain. The primitives for #== and #~~, just like any other primitives, are found by message sends. However, a set of 32 "special" selectors, which comprise some arithmetic selectors (#+, #- etc) and comparison selectors (#< #<= etc) and some frequent selectors #(at: #next #value #== etc) are subject to inlining with no sends (see Smalltalk specialSelectoers for the full set). The first sixteen are arithmetic and comparison, and the interpreter gains performance by implementing these byte codes to test for SmallIntegers and Floats, and performing the arithmetic directly without a send, and for the comparisons, performing the comparison and any immediately following conditional branch. The JIT performs these optimisations too. But these short-cuts (static type prediction in the official terminology) are safe because they apply only to SmallInteger and Float. Of the next sixteen most are there only to save space in a method's literal frame. Since the byte code encodes the selector directly there is no need to store the selector in the method's literals. The implementation of all but two (three if we add #~~ to replace #blockCopy: as mentioned above) of these bytecodes is to fetch the selector from the specialSelectors array and do a normal send. #== and #class are handled specially. These are inlined without doing a send. The current Opal compiler in Pharo avoids the inlining of #class by not generating the #class special selector bytecode. Squeak's compiler still issues the special selector bytecode. Both generate #== by issuing the #== special selector bytecode, and so #== is never sent. This is not what's desired for applications that use proxies. It is fine for simple applications that prefer speed. One simple thing one can do is prevent inlining for anything other than the arithmetic and comparison operators. A simple command-line switch, or perhaps better, a flag in the image header, can control whether the VM inlines #class, #== & #~~. This then allows the compilers to generate the more compact special selector byte codes for these sends, but causes the VM to treat them like the other 13 non-arithmetic special selectors. Hence they become true sends. I did this for VisualWorks several years ago and it works well, expect for needing a command-line switch. The flag in the image header is much more reliable; whether an image should be run with inlining or not is a property of the image, not of a particular VM invocation. So I suggest that a) I implement the switch as an image header flag, allowing the inlining of #class, #== and #~~ to be turned off (but keeping inlining on by default) b) Pharo changes Opal to start issuing the #class special selector send byte code again and turns off inlining of #class, #== and #~~ c) applications that use proxies (in Cuis, Pharo or Squeak) experiment with the setting and see if logic is improved and report back; Squeak and other dialects can then decide what they want as the default, and indeed certain packages could try and set the flag or at least check that the flag is in the desired state

Cheers

On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

...

Hi

It is been a while... So, do we want to replace ~~ with a primitive? :)

Cheers Alex

-- View this message in context: http://forum.world.st/About-an d-tp3898409p4924391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- _,,,^..^,,,_ best, Eliot

On 25 Nov 2016, at 19:31, Peter Uhnak <i.uhnak@gmail.com> wrote:

Out of interest... is the single extra dispatch really that expensive?

And speaking of object inequality... I would like to propose "<>" instead of "~=", because I never remember on which side ~ should be..

Let’s replace it with ~=~ then :P Y

Peter

On Wed, Nov 23, 2016 at 05:39:03AM -0800, Aliaksei Syrel wrote:

...

Hi

It is been a while... So, do we want to replace ~~ with a primitive? :)

Cheers Alex

-- View this message in context: http://forum.world.st/About-and-tp3898409p4924391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi <leves@elte.hu> 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]

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?

Levente

Thanks in advance!

...

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- best, Eliot

On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:

...

On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi <leves@elte.hu> 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]

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?

with or without special bytecode associated?

Initially without. Dynamic frequency is low, and primitive adds significant performance over the non-primitive version. One could use the blockCopy: special bytecode but I'd wait until doing a complete bytecode set redesign.

...

...

Levente

Thanks in advance!

...

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- best, Eliot

-- Mariano http://marianopeck.wordpress.com

-- best, Eliot

OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into the main branch? On Wed, Oct 12, 2011 at 10:47 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

On Wed, Oct 12, 2011 at 7:29 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:

...

On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

...

On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:

...

On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi <leves@elte.hu> 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]

Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."

^(self == anObject) not

And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^self = anObject == false

Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."

^(self = anObject) not.

Is there any particular reason for this that I'm missing?

Performance.

But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?

with or without special bytecode associated?

Initially without.

+1

...

Dynamic frequency is low, and primitive adds significant performance over the non-primitive version. One could use the blockCopy: special bytecode but I'd wait until doing a complete bytecode set redesign.

...

...

...

Levente

Thanks in advance!

...

--

"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"

Linus Torvalds

-- best, Eliot

-- Mariano http://marianopeck.wordpress.com

-- best, Eliot

-- Mariano http://marianopeck.wordpress.com

-- best, Eliot