[Philosophy] Do we need pool dictionaries?
Locked
[Philosophy] Do we need pool dictionaries?
 
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
Administrator
|
In reply to this post by Juan Vuletich-4
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
2014/1/22 Sean P. DeNigris <[hidden email]> Juan Vuletich-4 wrote 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 mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: [Philosophy] Do we need pool dictionaries?
|
Administrator
|
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 |
Re: [Philosophy] Do we need pool dictionaries?
|
|
2014/1/22 Sean P. DeNigris <[hidden email]> Nicolas Cellier wrote 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 ;)
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
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
|
Re: [Philosophy] Do we need pool dictionaries?
|
|
In reply to this post by Nicolas Cellier
On 22/01/2014 03:39 p.m., Nicolas Cellier wrote:
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 |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |