The Trunk: Collections-eem.792.mcz

On a serious note, libary methods, like that method, ought to be fast,

Every method in the image is a library method, so what do you mean by

Really? Explain me how Browser >> #defaultBrowserTitle, a method I chose randomly, is a library method?

because you can't know in what situation they will be used. Saying that it's
not even used is therefore not a valid reason.

That's only true for the very lowest-level methods.  Generally, it's
better to design and code for what's known, and NOT try to code for
the future / unknown.  IF and when that future comes, it'd be easy
enough for you to deal with any performance issues at THAT time.  In
the meantime, we "ought"  :) to keep as much beautiful minimal
elegance as we can.

So, if I decided to write a mail transfer agent, and I found that optimizing #isAsciiString would bump the throughput by, let's say, 10%, then and only then would I be allowed to change the implementation in Squeak? Or should I keep my optimized version in my image, because it's not considered generally useful?

Hi Tobias, Hi All,


> On May 3, 2018, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Thu, 3 May 2018, Tobias Pape wrote:
>>
>>
>>> On 03.05.2018, at 22:48, Nicolas Cellier <[hidden email]> wrote:
>>> But WideString requires another hack...
>>
>> Like
>>
>>    ^false
>>
>> ? :D
>
> Not really: ((WideString new: 2) first: 1) isAsciiString
>
> Levente

Note that this is a common issue in Smalltalk, where we can have different implementations (classes) with the same interface.  Take LargeInteger and SmallInteger.  The arithmetic system and the VM are both implemented to almost never represent something in the SmallInteger range as a LargeInteger (there are rare circumstances but it's safe to assume that the invariant is always maintained, and the invariant is depended upon).  This allows the VM to only ever check for SmallIntegers for things like indices, never having to waste code bloat or cycles checking for denormalised LargeIntegers.

Why can we do this with SmallInteger & LargeInteger, but not with ByteString and WideString?  Because ByteString and WideString are mutable (and because of the FFI).  Were the system to maintain the invariant that strings containing characters in the range 0 to 255 were always represented by ByteString, then, Tobias, your WideString>>isAsciiString ^false would work.  But the cost of maintaining that invariant would be scanning the ret of the string every time at:put: deposited a byte character, to see if we had just replaced the last wide character by a byte one and hence needed to do a become:.  We'd also potentially spend a lot of time doing becomes, and we'd also have to allow for denormalisation when passing an ascii string through the FFI to code requiring a wide string.  And even worse we'd have to avoid WideString new: n like the plague since new strings are always ascii, being full of nuls.  So only WideString with:... forms would make sense.

So this kind of multiple implementation approach only works well with certain types and access patterns.  Interesting, no?

2018-05-04 0:50 GMT+02:00 Eliot Miranda <[hidden email]>:

Hi Tobias, Hi All,


> On May 3, 2018, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Thu, 3 May 2018, Tobias Pape wrote:
>>
>>
>>> On 03.05.2018, at 22:48, Nicolas Cellier <[hidden email]> wrote:
>>> But WideString requires another hack...
>>
>> Like
>>
>>    ^false
>>
>> ? :D
>
> Not really: ((WideString new: 2) first: 1) isAsciiString
>
> Levente

Note that this is a common issue in Smalltalk, where we can have different implementations (classes) with the same interface.  Take LargeInteger and SmallInteger.  The arithmetic system and the VM are both implemented to almost never represent something in the SmallInteger range as a LargeInteger (there are rare circumstances but it's safe to assume that the invariant is always maintained, and the invariant is depended upon).  This allows the VM to only ever check for SmallIntegers for things like indices, never having to waste code bloat or cycles checking for denormalised LargeIntegers.

Why can we do this with SmallInteger & LargeInteger, but not with ByteString and WideString?  Because ByteString and WideString are mutable (and because of the FFI).  Were the system to maintain the invariant that strings containing characters in the range 0 to 255 were always represented by ByteString, then, Tobias, your WideString>>isAsciiString ^false would work.  But the cost of maintaining that invariant would be scanning the ret of the string every time at:put: deposited a byte character, to see if we had just replaced the last wide character by a byte one and hence needed to do a become:.  We'd also potentially spend a lot of time doing becomes, and we'd also have to allow for denormalisation when passing an ascii string through the FFI to code requiring a wide string.  And even worse we'd have to avoid WideString new: n like the plague since new strings are always ascii, being full of nuls.  So only WideString with:... forms would make sense.

In such case we would maintain a count of non-byte characters and avoid scanning...

So this kind of multiple implementation approach only works well with certain types and access patterns.  Interesting, no?

On Fri, May 4, 2018 at 12:44 PM, Nicolas Cellier <[hidden email]> wrote:

2018-05-04 0:50 GMT+02:00 Eliot Miranda <[hidden email]>:

Hi Tobias, Hi All,


> On May 3, 2018, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Thu, 3 May 2018, Tobias Pape wrote:
>>
>>
>>> On 03.05.2018, at 22:48, Nicolas Cellier <[hidden email]> wrote:
>>> But WideString requires another hack...
>>
>> Like
>>
>>    ^false
>>
>> ? :D
>
> Not really: ((WideString new: 2) first: 1) isAsciiString
>
> Levente

Note that this is a common issue in Smalltalk, where we can have different implementations (classes) with the same interface.  Take LargeInteger and SmallInteger.  The arithmetic system and the VM are both implemented to almost never represent something in the SmallInteger range as a LargeInteger (there are rare circumstances but it's safe to assume that the invariant is always maintained, and the invariant is depended upon).  This allows the VM to only ever check for SmallIntegers for things like indices, never having to waste code bloat or cycles checking for denormalised LargeIntegers.

Why can we do this with SmallInteger & LargeInteger, but not with ByteString and WideString?  Because ByteString and WideString are mutable (and because of the FFI).  Were the system to maintain the invariant that strings containing characters in the range 0 to 255 were always represented by ByteString, then, Tobias, your WideString>>isAsciiString ^false would work.  But the cost of maintaining that invariant would be scanning the ret of the string every time at:put: deposited a byte character, to see if we had just replaced the last wide character by a byte one and hence needed to do a become:.  We'd also potentially spend a lot of time doing becomes, and we'd also have to allow for denormalisation when passing an ascii string through the FFI to code requiring a wide string.  And even worse we'd have to avoid WideString new: n like the plague since new strings are always ascii, being full of nuls.  So only WideString with:... forms would make sense.

In such case we would maintain a count of non-byte characters and avoid scanning...

Only possible if the representation makes room for a count, which could easily require more than 24 bits.  It is non-trivialto implement, and of course slows down access.

So this kind of multiple implementation approach only works well with certain types and access patterns.  Interesting, no?

_,,,^..^,,,_

best, Eliot

Hi Levente,

 

meant.  My own criteria is "methods which are called thousands of times per minute" _today_.  

 

A rule of thumb could be that if a core method (e.g. anything in Kernel/Collections) is part of an API and it's not there to support a very specific task (e.g. Dictionary >> #associationDeclareAt:), then its performance should be taken into account.

That sounds like it only exempts utility methods ("specific tasks").  Technically, this should leave me afraid that you might want to inline Dictionary>>#at:, but I'm relatively sure you don't.  #at: is the most basic featured accessing method for understanding and using a Dictionary, so I hope you agree that's one that should retain its exemplar status.

OTOH, #associationDeclareAt: and #isOctetString, by their nature, are only of interest to developers.  Users would never use those methods, so optimizing them would be fine I suppose.  Methods which take block arguments also tend to be not as usable by users, since passing a block requres writing some code.  So it seems we have _some_ concrete criteria starting to form simply by having looked at a few examples:

   - methods which run hundreds of times per minute

   - methods which take block as arguments

   - methods which are concerned with internals instead of externals

#isAsciiString seems like it could go either way, so I'm fine if you and Eliot prefer it to be optimized.  For me this discussion itself to get a slightly better understanding of each others' positions with the request to keep Dynabook users in mind when evaluating future such optimizations, is more important.

Regards,

  Chris

On Fri, May 4, 2018 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:

On Thu, 3 May 2018, Chris Muller wrote:

                  On a serious note, libary methods, like that method, ought to be fast,


            Every method in the image is a library method, so what do you mean by


      Really? Explain me how Browser >> #defaultBrowserTitle, a method I chose randomly, is a library method?


Well, I was actually asking for clarification from _you_  for the meaning of "library method", since you were the one assigning an "ought" to them  :).  So I started out with it meaning, "every method in the base image", as a means to open up the question of what you
meant.  My own criteria is "methods which are called thousands of times per minute" _today_.  But as the guy whose done more of these sorts of method optimizations than anyone (most of which I love), I am actually *truly curious* about YOUR criteria on this.  What
methods in the image would Levente prefer to be more readable than performant, and why?

I can't give you an exact definition of a "library method", but I'm sure that String >> #isAsciiString is one, while Browser >> #defaultBrowserTitle is not.
A rule of thumb could be that if a core method (e.g. anything in Kernel/Collections) is part of an API and it's not there to support a very specific task (e.g. Dictionary >> #associationDeclareAt:), then its performance should be taken into account.

Btw, please have a look at String >> #isOctetString.

Levente

> ....
 


                  because you can't know in what situation they will be used. Saying that it's
                  not even used is therefore not a valid reason.


            That's only true for the very lowest-level methods.  Generally, it's
            better to design and code for what's known, and NOT try to code for
            the future / unknown.  IF and when that future comes, it'd be easy
            enough for you to deal with any performance issues at THAT time.  In
            the meantime, we "ought"  :) to keep as much beautiful minimal
            elegance as we can.


      So, if I decided to write a mail transfer agent, and I found that optimizing #isAsciiString would bump the throughput by, let's say, 10%, then and only then would I be allowed to change the implementation in Squeak? Or should I keep my optimized version in
      my image, because it's not considered generally useful?


Yes.  That's when you'll have the concrete context necessary to enable you to make the best implementation choice.  Until then, degrading code readability in exchange for no real-world performance benefit just... well, degrades the code...