Squeak-dev December 2002

squeak-dev@lists.squeakfoundation.org

173 participants
456 discussions

RE: Pocket PC Performance
by Andreas Raab 31 Dec '02

31 Dec '02

Hi Torge, If you're right with your assumption the difference should be measurable from within the VM with different images. I don't know if the devices we're talking about have something equivalent to the RDTSC instruction on i386 processors but if there's a _really_ cheap way of measuring sub-microsecond units (RDTSC, for example, measures clock cycles) then it might be really worthwhile to attribute a VM and see if you can find out a difference (e.g., time spent in critical areas such as "full" method lookup as a percentage of overall time spent). The problem I have with your measurements is that (I think) they are not really giving you any "good enough" evidence to make a case here. Even if it is true that faster images show smaller lookup lengths the differences could still be attributed to many other factors - lots of things have changed and chasing VM inefficiencies is typically very hard if you don't have any "hard numbers" to go along with. Personally, my feeling is "half and half" here. Yes, there could be a problem with the mcache size as well as the speed of the full method lookup. But then, it's _really_ hard to tell without hard numbers. Cheers, - Andreas > -----Original Message----- > From: squeak-dev-admin(a)lists.squeakfoundation.org > [mailto:squeak-dev-admin@lists.squeakfoundation.org] On > Behalf Of Torge.Husfeldt(a)gmx.de > Sent: Sunday, December 29, 2002 6:38 PM > To: squeak-dev(a)lists.squeakfoundation.org > Cc: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Pocket PC Performance > > > Hi All, > Can someone who encounters the performance problems mentioned in this > thread > please try out the following code snippets and report on the outcome?! > > First try in a workspace: > | lookupLengths | > lookupLengths _ SortedCollection new. > Behavior allSubInstancesDo:[:class | | md | > md _ class methodDict. > lookupLengths addAll:(md keys asSortedCollection collect:[:sel | > (((md scanFor: sel) - sel identityHash) > \\ md basicSize) -> (class -> > sel)]) > ]. > lookupLengths asBag sortedCounts inspect. > lookupLenghts last:100 inspect. > > This will give you two inspectors. > The first will show the sorted counts of a bag which entries should be > interpreted the following: > #occurences -> #lookupLength -> sampleClass -> sampleSelector > Please report on the differences between a slow image and an > acceptable > image (preferrably on the same system) > The second will give you the details of the 100 Methods with > the highest > lookupLenghts. > Please look swiftly over this list if you can detect any Morphic > specific selectors with > long lookup lenghts. > > The second thing i want you to try is to grow all your > MethodDictionaries that have > exessive lookupLenghts. The following code snippet will do > this for you. > > | lookupLengths | > Behavior allSubInstancesDo:[:class | | md | > md _ class methodDict. > md isEmpty ifFalse:[ > lookupLengths _ SortedCollection new. > lookupLengths addAll:(md keys > asSortedCollection collect:[:sel | > (((md scanFor: sel) - sel > identityHash) \\ md basicSize) -> (class > -> sel)]). > (lookupLengths last key > 9) ifTrue:[md grow]]] > > > Please report if your image "feels" any swifter after this operation. > Note#0: > Be sure not to have any PackagePaneBrowser (aka 5-pane browser) > open when you do your tests because these beasts will stop all morphic > updating (and maybe event dispatch) for up to one second every second > on a slow machine. This is due to a design bug which can very > easily be > avoided using a changeset i once posted to the list but don't have the > patience > to dig up right now. > Note#1: > These operations might take a _very_ long time (especially on a slow > system) > so be pationent) (on my 1700+ it was in the second range but since > you're > especially encountering problems on slow systems you will probably do > the > tests there, too -- so don't say i didn't warn you ). > Note#2: > LookupLenghts stand for the amount of probes the vm has to do in _a > single > method dictionary_ to find a method corresponding to a > selector. This is > just a > minimum measure because it doesn't count the number of probes spent > while > following the superclass chain. These numbers are typically small for > almost empty > method dictionaries but may become huge when all superclasses > have long > probe chains > and the selector is only implemented in ProtoObject > Note#3: > It is nowhere near guranteed that this will change anything because > lookup > lenghts aren't _supposed_ to make a difference. It is widely believed > that the > vm's lookup cache mechanism should deal with the performance hit that > would > result from long probe chains. > I have, whatsoever, two strong hints that lookupLenghts > _might_ be part > of the > problem you encounter. These are: > Hint#1: The problem has arisen rather gradually and noone has yet been > able to > find any particular change that made the difference > hint#2: The Lookup cache (as i understand it) seems to be rather small > for as big > a system as morphic (i only saw space for 512 entries last time i > looked) and gets > flushed on several accasions (such as gc's). > > Looking forward to your feedback, > Torge >

7 10

Array literals: ANSI vs. Blue Book
by Boris Gaertner 31 Dec '02

31 Dec '02

This note refers to Squeak3.4beta but I think it applies also to all earlier versions of Squeak. In the literal #('Hello' true false nil) the four elements are: 1. the string 'Hello' 2. the symbol #true (not the sole instance of class True) 3. the symbol #false (not the sole instance of class False) 4. the symbol #nil (not the sole instance of class UndefinedObject) This is traditional "Blue Book" Smalltalk. The Blue Book says (on page 21): "The literal representation of an array is a sequence of other literals - numbers, characters, strings, symbols, and arrays - delimited by parentheses and preceded by a pound sign. The other literals are separated by spaces. Embedded symbols and arrays are not preceded by pound signs." This traditional denotation was implemented in both Smalltalk-80 and Digitalk Smalltalk/V. But then there came a change with one of the releases of Smalltalk-80 (I think it was release 2.5, but I cannot find documentation that proves this). The literal expression #('Hello' true false nil) was now interpreted as the writing form of an array with these elements: 1. the string 'Hello' 2. the sole instance of class True (not a symbol) 3. the sole instance of class False (not a symbol) 4. the sole instance of class UndefinedObject (not a symbol) An array with symbols was now written as: #('Hello' #true #false #nil) The use of the pound symbol with embedded symbols was introduced to be able to distinguish between the symbol #true and the value true. All major Smalltalks changed to the interpretation that allows the use of the values true, false, nil in array literals. Squeak is, as far as I can see, the sole Smalltalk that follows the "Blue Book" interpretation. Here is what a draft of the ANSI specification from 1997 says: 5.4.6.6 Array Literals An array literal is a sequenced collection with numeric keys which may contain any number of other literals. <array literal> ::= '#(' <array element>* ')' <array element> ::= <literal> | identifier The value of an array literal is an object that implements the <sequencedReadableCollection> protocol. The elements of an array literal can consist of any combination of literal forms. If an identifier appears as an <array element> and it is one of the reserved identifiers nil, true or false the value of the corresponding element of the collection is the value of that reserved identifier. The meaning is undefined if any other identifier is used as an <array element>. If an <array literal> has no <array element>clauses the collection has no elements. My question to the community: Should we adopt the ANSI interpretation of array literals or should we keep the 'Blue Book' interpretation? Note that we can use curly brackets to create an array with logical values and with the value nil: {'Hello'. true. false. nil. #true. #false. #nil} The curly brackets are not part of the 'Blue Book' Smalltalk. They are, to the best of my understanding, also not part of the ANSI specification, but at times they are very useful. The attached change set is perhaps(!) sufficient to change to ANSI. It should be seen as an experimental change; please try it only with an image that does not contain work that you cannot restore after a fatal crash. Greetings and best wishes for a successful new year Boris

1 0

[Bug?] #aaaa printString -> 'aaaa'
by Stephane Ducasse 31 Dec '02

31 Dec '02

Hi Does anybody know why #aaaa printString -> 'aaaa' and not #aaaa printString -> '#aaaa' Because with the current behavior we cannot distinguish in list ;(((. in VisualWorks we get the expected behavior. Stef Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

3 2

Re: Duplicate Connector Flaps & Menu Items
by Ned Konz 31 Dec '02

31 Dec '02

I'd attempted to keep this from happening in the latest Connectors version by testing whether there were flaps with those particular names. I'll look into it (I just got back from a week-long trip to Texas). -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

1 0

[ANN] SmallInterfaces 2.0.0a in available on SqueakMap
by Masashi Umezawa 31 Dec '02

31 Dec '02

Hi all, I have just updated SmallInterfaces, which is now installable in Squeak 3.4. http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/smallInterfaces/Small Interfaces.sar Try a formal Smalltalk (sort of). The article - "Adding Dynamic Interfaces to Smalltalk" by Benny Sadeh and Stephane Ducasse can be read at JOT. http://www.jot.fm/issues/issue_2002_05/article1.pdf Cheers, --- [:masashi | ^umezawa]

1 0

[LINUX] activate jitter?
by Niko Schwarz 31 Dec '02

31 Dec '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello there, I can't figure how to get the jitter running, I'm doing this: igel@xi:~> squeak -version 3.2-5 #2 XShm Wed Oct 16 12:50:55 CEST 2002 gcc egcs-2.91.66 Squeak3.2gamma of 15 January 2002 [latest update: #4881] Linux pingu.inria.fr 2.2.19-6.2.7 #1 Thu Jun 14 07:51:10 EDT 2001 i686 default plugin location: /usr/lib/squeak/3.2-5/*.so igel@xi:~> uname -a Linux xi 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown igel@xi:~> squeak -jit could not find j_interpret igel@xi:~> What's going wrong? tia, nick - -- A well adjusted person is one who makes the same mistake twice without getting nervous. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+DG/z3P3nmXTVnC8RAoTsAKCWa0OhrsmGBDW8wMUM9Nfjv6LmPwCeOM3b IPR34tbgq/Ux8z+bdI1BzYE= =HNDl -----END PGP SIGNATURE-----

2 3

Re: Newbie question: ConstantShapeMorph?
by Bob Arning 31 Dec '02

31 Dec '02

On Mon, 30 Dec 2002 12:15:13 -0800 Bill Spight <bspight(a)pacbell.net> wrote: >How do you make a Morph that keeps its shape upon resizing? I would have >thought that that would be a common thing to do, but I have not found >anything in the documentation about how to do that. Bill, You could override the #extent: method to do something like: extent: aPoint x _ aPoint x. y _ aPoint y. (y * aspectRatio) > x ifTrue: [ x _ y * aspectRatio ] ifFalse: [ y _ x / aspectRatio ]. ^super extent: (x@y) rounded Where aspectRatio is an instance variable set to the desired x/y ratio. Cheers, Bob

2 1

Apparent bug in Squeak's exception handling - false alarm..
by Chris Muller 30 Dec '02

30 Dec '02

Please disregard my note below.. I confused myself by signaling concrete Notifications in my code, not remembering that other subclasses of Notification would be getting caught in my handler. Oops! Probably better to subclass with my own and use that.. Sorry. - Chris PS - that is an clever way to access a preference and still have an apparently thread-safe way to change it dynamically, using a resumable exception! --- Chris Muller <afunkyobject(a)yahoo.com> wrote: > Date: Sun, 29 Dec 2002 20:54:40 -0800 (PST) > From: Chris Muller <afunkyobject(a)yahoo.com> > Subject: Apparent bug in Squeak's exception handling > To: Squeak List <squeak-dev(a)lists.squeakfoundation.org> > > > In a stock 3.4 image, print this in a workspace: > > [ InMidstOfFileinNotification signal ] > on: Notification > do: [ :noti | noti resume ] > > This expression should return false, but it returns nil. > InMidstOfFileinNotification is an Exception included with Squeak that has a > defaultAction to return false. > > But when wrapped in a Notification handler, as above, it seems to not return > the correct value. > > Is this a bug? Any assistance would be appreciated. > > - Chris > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

3 2

Gaming on the Grid -- with Croquet ?
by HNBeck＠t-online.de 30 Dec '02

30 Dec '02

Hi, on IEEE computer society web page I found this: http://dsonline.computer.org/0211/d/brief2.htm may be interessting for the croquet players (or already known ;-)) (It's about a so-called gaming grid named Butterfly grid which looks like IBM's grid effort for scientifc computung) Greetings Hans

1 0

RE: Pocket PC Performance
by Torge.Husfeldt＠gmx.de 30 Dec '02

30 Dec '02

Hi Andreas, You're right, my tests don't deal with hard numbers. I just made a guess as to what may cause the bad _image_ performance in later squeak versions. And given that this performance hit came rather gradually and nobody has yet been able to tie it to a particular change, i thought, let's give it a try and ask people how performance 'feels' with reduced lookup lengths (btw in my 3.4b image i encountered lookup lengths up to 46 and i think this is quite a lot). Once we have two or three votes of people who say that it helped (or didn't help) we can decide whether to go on chasing for hard numbers. But then again, since you are such an expert on i386 VMs you can go chasing hard numbers right away ;) My proposition of images to compare (with the same vm since the problems reported are independent of VMs): #(2.6 2.8 3.0) do:[:imageVersion | #(mvc morphic) do:[:guiMode | #(true false) do:[:withLookupLenghtsReduced | imageVersion startUp. project := twm open... <guiMode> Project. project enter. withLookupLenghtsReduced ifTrue:[applyTorgeSPatch] "Do some testing"]]] ... is my pseudo-smalltalk program that describes the test cases. This could give us some good hints on what the change in this particular area is and then we may discuss what benefits we can get from which change. Note that i'm talking about a performance hit that occured on all CPUs with all (applicable)VMs between the image versions. I'd be glad to give you the numbers on my not so up to date K6-2/350 (I think i can make it run as slow as 233 if this helps) but i have to make it run first. Best Regards, Torge "Andreas Raab" <andreas.raab(a)gmx.de> wrote: > Hi Torge, > > If you're right with your assumption the difference should be measurable > from within the VM with different images. I don't know if the devices > we're talking about have something equivalent to the RDTSC instruction > on i386 processors but if there's a _really_ cheap way of measuring > sub-microsecond units (RDTSC, for example, measures clock cycles) then > it might be really worthwhile to attribute a VM and see if you can find > out a difference (e.g., time spent in critical areas such as "full" > method lookup as a percentage of overall time spent). > > The problem I have with your measurements is that (I think) they are not > really giving you any "good enough" evidence to make a case here. Even > if it is true that faster images show smaller lookup lengths the > differences could still be attributed to many other factors - lots of > things have changed and chasing VM inefficiencies is typically very hard > if you don't have any "hard numbers" to go along with. > > Personally, my feeling is "half and half" here. Yes, there could be a > problem with the mcache size as well as the speed of the full method > lookup. But then, it's _really_ hard to tell without hard numbers. > > Cheers, > - Andreas > > > -----Original Message----- > > From: squeak-dev-admin(a)lists.squeakfoundation.org > > [mailto:squeak-dev-admin@lists.squeakfoundation.org] On > > Behalf Of Torge.Husfeldt(a)gmx.de > > Sent: Sunday, December 29, 2002 6:38 PM > > To: squeak-dev(a)lists.squeakfoundation.org > > Cc: squeak-dev(a)lists.squeakfoundation.org > > Subject: Re: Pocket PC Performance > > > > > > Hi All, > > Can someone who encounters the performance problems mentioned in this > > thread > > please try out the following code snippets and report on the outcome?! > > > > First try in a workspace: > > | lookupLengths | > > lookupLengths _ SortedCollection new. > > Behavior allSubInstancesDo:[:class | | md | > > md _ class methodDict. > > lookupLengths addAll:(md keys asSortedCollection collect:[:sel | > > (((md scanFor: sel) - sel identityHash) > > \\ md basicSize) -> (class -> > > sel)]) > > ]. > > lookupLengths asBag sortedCounts inspect. > > lookupLenghts last:100 inspect. > > > > This will give you two inspectors. > > The first will show the sorted counts of a bag which entries should be > > interpreted the following: > > #occurences -> #lookupLength -> sampleClass -> sampleSelector > > Please report on the differences between a slow image and an > > acceptable > > image (preferrably on the same system) > > The second will give you the details of the 100 Methods with > > the highest > > lookupLenghts. > > Please look swiftly over this list if you can detect any Morphic > > specific selectors with > > long lookup lenghts. > > > > The second thing i want you to try is to grow all your > > MethodDictionaries that have > > exessive lookupLenghts. The following code snippet will do > > this for you. > > > > | lookupLengths | > > Behavior allSubInstancesDo:[:class | | md | > > md _ class methodDict. > > md isEmpty ifFalse:[ > > lookupLengths _ SortedCollection new. > > lookupLengths addAll:(md keys > > asSortedCollection collect:[:sel | > > (((md scanFor: sel) - sel > > identityHash) \\ md basicSize) -> (class > > -> sel)]). > > (lookupLengths last key > 9) ifTrue:[md grow]]] > > > > > > Please report if your image "feels" any swifter after this operation. > > Note#0: > > Be sure not to have any PackagePaneBrowser (aka 5-pane browser) > > open when you do your tests because these beasts will stop all morphic > > updating (and maybe event dispatch) for up to one second every second > > on a slow machine. This is due to a design bug which can very > > easily be > > avoided using a changeset i once posted to the list but don't have the > > patience > > to dig up right now. > > Note#1: > > These operations might take a _very_ long time (especially on a slow > > system) > > so be pationent) (on my 1700+ it was in the second range but since > > you're > > especially encountering problems on slow systems you will probably do > > the > > tests there, too -- so don't say i didn't warn you ). > > Note#2: > > LookupLenghts stand for the amount of probes the vm has to do in _a > > single > > method dictionary_ to find a method corresponding to a > > selector. This is > > just a > > minimum measure because it doesn't count the number of probes spent > > while > > following the superclass chain. These numbers are typically small for > > almost empty > > method dictionaries but may become huge when all superclasses > > have long > > probe chains > > and the selector is only implemented in ProtoObject > > Note#3: > > It is nowhere near guranteed that this will change anything because > > lookup > > lenghts aren't _supposed_ to make a difference. It is widely believed > > that the > > vm's lookup cache mechanism should deal with the performance hit that > > would > > result from long probe chains. > > I have, whatsoever, two strong hints that lookupLenghts > > _might_ be part > > of the > > problem you encounter. These are: > > Hint#1: The problem has arisen rather gradually and noone has yet been > > able to > > find any particular change that made the difference > > hint#2: The Lookup cache (as i understand it) seems to be rather small > > for as big > > a system as morphic (i only saw space for 512 entries last time i > > looked) and gets > > flushed on several accasions (such as gc's). > > > > Looking forward to your feedback, > > Torge > >

1 0

← Newer
1
2
3
4
5
6
7
...
46
Older →

Jump to page: