[Philosophy] Do we need pool dictionaries?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Philosophy] Do we need pool dictionaries?

Casey Ransberger-2
This is something I've wondered about for awhile. I understand that pool dictionaries are convenient in uncommon cases. What I'm wondering, though, is whether or not we really need them.

Does using pools give us a performance gain? (I'm guessing it does.)

I can't think of an analogue to them in any other language I've used, though. I can't imagine that they're actually necessary unless there's something about Smalltalk that I don't understand (and I'm quite certain that there must be lots of things about Smalltalk that I don't understand yet!)

It seems like there could be some upside to ripping the entire concept out. OTOH if I had a pile of cash I'd hire some folks (you know who) to build out optimistic inlining in Cog and then rip out the concept of classes too, so of course I'm a bit of a radical. Call me an essentialist;)

I wonder what folks on the list would think if I undertook the probably huge task of eliminating them. I've been eyeing that prize. And of course it would be fabulous to know why it's a bad idea if it's a bad idea.

If its doable, I'd even go so far as to say that pools could be an external package for legacy code that needs them.  

Just what's on my mind this morning.

--C

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Frank Shearar-3
On 30 July 2013 11:49, Casey Ransberger <[hidden email]> wrote:
> This is something I've wondered about for awhile. I understand that pool dictionaries are convenient in uncommon cases. What I'm wondering, though, is whether or not we really need them.
>
> Does using pools give us a performance gain? (I'm guessing it does.)

If you threw out pool dictionaries, I guess you'd have to use message
sends to find out some value. Is that what you mean by a performance
gain?

> I can't think of an analogue to them in any other language I've used, though. I can't imagine that they're actually necessary unless there's something about Smalltalk that I don't understand (and I'm quite certain that there must be lots of things about Smalltalk that I don't understand yet!)

With the caveat that I've only just started looking at these guys
(because SharedPool lives in Squeak's System package, but several
Kernel classes use SharedPools), I'd say that they're something like a
limited mixin, in Ruby terminology. Or, if you prefer, if you needed a
pool dictionary in Ruby you'd use something like

  module MySharedPool
    ONE = 1
    TWO = 2
  end

  class MyClass
    include MySharedPool
  end

frank

> It seems like there could be some upside to ripping the entire concept out. OTOH if I had a pile of cash I'd hire some folks (you know who) to build out optimistic inlining in Cog and then rip out the concept of classes too, so of course I'm a bit of a radical. Call me an essentialist;)
>
> I wonder what folks on the list would think if I undertook the probably huge task of eliminating them. I've been eyeing that prize. And of course it would be fabulous to know why it's a bad idea if it's a bad idea.
>
> If its doable, I'd even go so far as to say that pools could be an external package for legacy code that needs them.
>
> Just what's on my mind this morning.
>
> --C

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Casey Ransberger-2
Aha! And now you've gotten to the nebulous question mark I've been wondering about since we first heard about Environments.

A Ruby module is nothing but a flexible namespace object, isn't it? I wrote some stuff about Environments in the original post, but deleted it before hitting send because I didn't want to conflate things or be windbaggish.

Also, yep, I was pretty sure that other solutions would involve either message sends or compiler/vm support to avoid message sends.

On Jul 30, 2013, at 3:59 AM, Frank Shearar <[hidden email]> wrote:

> On 30 July 2013 11:49, Casey Ransberger <[hidden email]> wrote:
>> This is something I've wondered about for awhile. I understand that pool dictionaries are convenient in uncommon cases. What I'm wondering, though, is whether or not we really need them.
>>
>> Does using pools give us a performance gain? (I'm guessing it does.)
>
> If you threw out pool dictionaries, I guess you'd have to use message
> sends to find out some value. Is that what you mean by a performance
> gain?
>
>> I can't think of an analogue to them in any other language I've used, though. I can't imagine that they're actually necessary unless there's something about Smalltalk that I don't understand (and I'm quite certain that there must be lots of things about Smalltalk that I don't understand yet!)
>
> With the caveat that I've only just started looking at these guys
> (because SharedPool lives in Squeak's System package, but several
> Kernel classes use SharedPools), I'd say that they're something like a
> limited mixin, in Ruby terminology. Or, if you prefer, if you needed a
> pool dictionary in Ruby you'd use something like
>
>  module MySharedPool
>    ONE = 1
>    TWO = 2
>  end
>
>  class MyClass
>    include MySharedPool
>  end
>
> frank
>
>> It seems like there could be some upside to ripping the entire concept out. OTOH if I had a pile of cash I'd hire some folks (you know who) to build out optimistic inlining in Cog and then rip out the concept of classes too, so of course I'm a bit of a radical. Call me an essentialist;)
>>
>> I wonder what folks on the list would think if I undertook the probably huge task of eliminating them. I've been eyeing that prize. And of course it would be fabulous to know why it's a bad idea if it's a bad idea.
>>
>> If its doable, I'd even go so far as to say that pools could be an external package for legacy code that needs them.
>>
>> Just what's on my mind this morning.
>>
>> --C
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Juan Vuletich-4
In reply to this post by Casey Ransberger-2
Hi Casey,

On 7/30/2013 7:49 AM, Casey Ransberger wrote:

> This is something I've wondered about for awhile. I understand that pool dictionaries are convenient in uncommon cases. What I'm wondering, though, is whether or not we really need them.
>
> Does using pools give us a performance gain? (I'm guessing it does.)
>
> I can't think of an analogue to them in any other language I've used, though. I can't imagine that they're actually necessary unless there's something about Smalltalk that I don't understand (and I'm quite certain that there must be lots of things about Smalltalk that I don't understand yet!)
>
> It seems like there could be some upside to ripping the entire concept out. OTOH if I had a pile of cash I'd hire some folks (you know who) to build out optimistic inlining in Cog and then rip out the concept of classes too, so of course I'm a bit of a radical. Call me an essentialist;)
>
> I wonder what folks on the list would think if I undertook the probably huge task of eliminating them. I've been eyeing that prize. And of course it would be fabulous to know why it's a bad idea if it's a bad idea.
>
> If its doable, I'd even go so far as to say that pools could be an external package for legacy code that needs them.
>
> Just what's on my mind this morning.
>
> --C
>

Hi Casey,

I don't like pooldictionaries. They look like "hidden globals" to me,
and they are as bad as regular globals. Maybe there were good reasons
for them 30 years ago, but I don't see any today, except for compatibility.

Cuis base image doesn't include any pool dictionary. See 'Smalltalk
poolUsers' (unfortunately broken in Squeak). Squeak includes
ChronologyConstants, EventSensorConstants and the old style (non
SharedPool subclass) TextConstants. I cleaned all these in Cuis. Right
now there are a couple of them in the external Compression package. (I
had to tweak package saving to ensure saving pools prior to users for
it.) But we'd clean them as well. They can usually just be replaced with
class variables.

What I mean is that in Cuis we can already make SharedPool optional.
Feel free to make it happen, I'll integrate it.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Frank Shearar-3
On 30 July 2013 12:57, Juan Vuletich <[hidden email]> wrote:

> Hi Casey,
>
>
> On 7/30/2013 7:49 AM, Casey Ransberger wrote:
>>
>> This is something I've wondered about for awhile. I understand that pool
>> dictionaries are convenient in uncommon cases. What I'm wondering, though,
>> is whether or not we really need them.
>>
>> Does using pools give us a performance gain? (I'm guessing it does.)
>>
>> I can't think of an analogue to them in any other language I've used,
>> though. I can't imagine that they're actually necessary unless there's
>> something about Smalltalk that I don't understand (and I'm quite certain
>> that there must be lots of things about Smalltalk that I don't understand
>> yet!)
>>
>> It seems like there could be some upside to ripping the entire concept
>> out. OTOH if I had a pile of cash I'd hire some folks (you know who) to
>> build out optimistic inlining in Cog and then rip out the concept of classes
>> too, so of course I'm a bit of a radical. Call me an essentialist;)
>>
>> I wonder what folks on the list would think if I undertook the probably
>> huge task of eliminating them. I've been eyeing that prize. And of course it
>> would be fabulous to know why it's a bad idea if it's a bad idea.
>>
>> If its doable, I'd even go so far as to say that pools could be an
>> external package for legacy code that needs them.
>>
>> Just what's on my mind this morning.
>>
>> --C
>>
>
> Hi Casey,
>
> I don't like pooldictionaries. They look like "hidden globals" to me, and
> they are as bad as regular globals. Maybe there were good reasons for them
> 30 years ago, but I don't see any today, except for compatibility.
>
> Cuis base image doesn't include any pool dictionary. See 'Smalltalk
> poolUsers' (unfortunately broken in Squeak).

No more! Environments-fbs.22 fixes it so you can say `Smalltalk
globals poolUsers`, which says, in the "base" 4.5,

 a Dictionary(#BalloonEngineConstants->an
OrderedCollection(#BalloonEngine an OrderedCollection())
#ChronologyConstants->an OrderedCollection(#Date #Week #DateAndTime
#Time #Duration #Month #TimeZone an OrderedCollection())
#CustomEventsRegistry->an OrderedCollection(an OrderedCollection())
#EventSensorConstants->an OrderedCollection(#KeyboardInputInterpreter
#DisplayHostWindow #MorphicUnknownEvent #EventSensor #UserInputEvent
#TextConverter #HandMorph an OrderedCollection()) #GZipConstants->an
OrderedCollection(#GZipWriteStream #GZipReadStream an
OrderedCollection()) #ImageImports->an OrderedCollection(an
OrderedCollection()) #MCMockAPoolDictionary->an
OrderedCollection(#MCMockClassB an OrderedCollection())
#References->an OrderedCollection(#Player an OrderedCollection())
#SharedPool->an OrderedCollection(an OrderedCollection())
#TextConstants->an OrderedCollection(#DisplayText
#LimitingLineStreamWrapper #MultiTextComposer #MultiNewParagraph
#TextLine #CharacterBlock #TextAlignment #SegmentScanner #HostFont
#StrikeFont #TextLineInterval #CompositionScanner
#PostscriptCharacterScanner #Text #MultiCharacterScanner #TextStyle
#CharacterScanner an OrderedCollection()) #Undeclared->an
OrderedCollection(an OrderedCollection()) #ZipConstants->an
OrderedCollection(#ZipWriteStream #ZipEncoder #DeflateStream an
OrderedCollection()) #ZipFileConstants->an
OrderedCollection(#ZipArchive #ZipArchiveMember an
OrderedCollection()) )

frank

> Squeak includes
> ChronologyConstants, EventSensorConstants and the old style (non SharedPool
> subclass) TextConstants. I cleaned all these in Cuis. Right now there are a
> couple of them in the external Compression package. (I had to tweak package
> saving to ensure saving pools prior to users for it.) But we'd clean them as
> well. They can usually just be replaced with class variables.
>
> What I mean is that in Cuis we can already make SharedPool optional. Feel
> free to make it happen, I'll integrate it.
>
> Cheers,
> Juan Vuletich
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Sean P. DeNigris
Administrator
In reply to this post by Juan Vuletich-4
Juan Vuletich-4 wrote
I don't like pooldictionaries. They look like "hidden globals" to me,
and they are as bad as regular globals. Maybe there were good reasons
for them 30 years ago, but I don't see any today, except for compatibility.
I agree that they should be avoided if possible, but they seem useful e.g. for NativeBoost in Pharo. There are many C constants, and you'd like to refer to them directly so you can copy/paste from documentation, and so that you don't have to context switch as much when writing C calls. With shared pools, you can import them into the namespace of all classes that directly access the library.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Nicolas Cellier

2014/1/22 Sean P. DeNigris <[hidden email]>
Juan Vuletich-4 wrote
> I don't like pooldictionaries. They look like "hidden globals" to me,
> and they are as bad as regular globals. Maybe there were good reasons
> for them 30 years ago, but I don't see any today, except for
> compatibility.

I agree that they should be avoided if possible, but they seem useful e.g.
for NativeBoost in Pharo. There are many C constants, and you'd like to
refer to them directly so you can copy/paste from documentation, and so that
you don't have to context switch as much when writing C calls. With shared
pools, you can import them into the namespace of all classes that directly
access the library.


But then, what difference with class variables?
class vars also are  global, just with a bit more restrictive visibility (subclasses)...

Usage of such globals for well known constants (like a C macro) is not that problematic.
Of course, it's possible to replace such shared pool by message send:
Character cr rather than CR.
But note that you replace a global (CR) by another global (Character).
OK reducing the number of globals is already something...
Also, motherness is not always that trivial, is it Text centered or TextAttribute centered?

Sure, some small optimization difference still exist:
- is a new instance created or a constant shared?
- is a message sent or not (note that Squeak 4.5 now send a message to access the #value of a global)
That indeed might have influenced decisions in the 70s.

Usage as a shared mutable state is more problematic
It's hardly possible to avoid such states (like a registry of opened files for example)
in this case, yes, it's better to restrict access (encapsulate) with a class var.
But I think Pharo already cleaned out the ugliest examples in TextConstants, no?




-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Philosophy-Do-we-need-pool-dictionaries-tp4701469p4738435.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Sean P. DeNigris
Administrator
Nicolas Cellier wrote
But then, what difference with class variables?
It's just like class variables but more flexible because:
- you import a specific group or groups instead of individual names
- you don't "waste" committing to a superclass. Without multiple inheritance, this is important. For example, in NativeBoost, there are objects representing external entities, which will use C constant names, and must inherit from a particular NativeBoost class. Then, if you make a facade for the library functions themselves, which also need the constants defined, but will not be subclassed from the same object.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Nicolas Cellier

2014/1/22 Sean P. DeNigris <[hidden email]>
Nicolas Cellier wrote
> But then, what difference with class variables?

It's just like class variables but more flexible because:
- you import a specific group or groups instead of individual names
- you don't "waste" committing to a superclass. Without multiple
inheritance, this is important. For example, in NativeBoost, there are
objects representing external entities, which will use C constant names, and
must inherit from a particular NativeBoost class. Then, if you make a facade
for the library functions themselves, which also need the constants defined,
but will not be subclassed from the same object.



The first thing that I was trying to say, is that pool dictionaries are much like class variables.
So saying that we want to eliminate pool dictionaries because they are globals is like saying that we want to eliminate class variables...

Eliminating pool dictionaries because we do not need two different implementations for these variables is another matter...
It seems that my remarks did apply more to this second POV maybe?.
I wanted to put alternatives in balance, but I was not suggesting to remove shared pools, and I agree they can be convenient...
Anyway, we can observe that modern shared pools are implemented by way off class vars, so we cannot say these are two different implementations ;)
 

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Philosophy-Do-we-need-pool-dictionaries-tp4701469p4738491.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

KenDickey
In reply to this post by Sean P. DeNigris
On Wed, 22 Jan 2014 05:38:34 -0800 (PST)
"Sean P. DeNigris" <[hidden email]> wrote:

> Juan Vuletich-4 wrote
> > I don't like pooldictionaries. They look like "hidden globals" to me,
> > and they are as bad as regular globals. Maybe there were good reasons
> > for them 30 years ago, but I don't see any today, except for
> > compatibility.
>
> I agree that they should be avoided if possible, but they seem useful e.g.
> for NativeBoost in Pharo. There are many C constants, and you'd like to
> refer to them directly so you can copy/paste from documentation, and so that
> you don't have to context switch as much when writing C calls. With shared
> pools, you can import them into the namespace of all classes that directly
> access the library.

I also don't see the need for pools.

A better idea is first class environments [selector + which environment/dictionary to use].  This was used in SmalltalkAgents and PLT Scheme to allow one, e.g. to debug a new debugger using the old one.

A bit of work, but quite handy.

$0.02,
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: [Philosophy] Do we need pool dictionaries?

Juan Vuletich-4
In reply to this post by Nicolas Cellier
On 22/01/2014 03:39 p.m., Nicolas Cellier wrote:

2014/1/22 Sean P. DeNigris <[hidden email]>
Juan Vuletich-4 wrote
> I don't like pooldictionaries. They look like "hidden globals" to me,
> and they are as bad as regular globals. Maybe there were good reasons
> for them 30 years ago, but I don't see any today, except for
> compatibility.

I agree that they should be avoided if possible, but they seem useful e.g.
for NativeBoost in Pharo. There are many C constants, and you'd like to
refer to them directly so you can copy/paste from documentation, and so that
you don't have to context switch as much when writing C calls. With shared
pools, you can import them into the namespace of all classes that directly
access the library.


But then, what difference with class variables?
class vars also are  global, just with a bit more restrictive visibility (subclasses)...

Usage of such globals for well known constants (like a C macro) is not that problematic.
Of course, it's possible to replace such shared pool by message send:
Character cr rather than CR.
But note that you replace a global (CR) by another global (Character).
OK reducing the number of globals is already something...
Also, motherness is not always that trivial, is it Text centered or TextAttribute centered?

Sure, some small optimization difference still exist:
- is a new instance created or a constant shared?
- is a message sent or not (note that Squeak 4.5 now send a message to access the #value of a global)
That indeed might have influenced decisions in the 70s.

Usage as a shared mutable state is more problematic
It's hardly possible to avoid such states (like a registry of opened files for example)
in this case, yes, it's better to restrict access (encapsulate) with a class var.
But I think Pharo already cleaned out the ugliest examples in TextConstants, no?

Cuis (this is what this list is about) makes no use of pool dictionaries. But they are there in case someone needs or wants them. Cuis is a Smalltalk-80 system. Removing support for pool dictionaries would mean turning Cuis into a "Smalltalk inspired" kind of system.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org