Squeak-dev June 2000

squeak-dev@lists.squeakfoundation.org

134 participants
686 discussions

Re: Cheap updates
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

=> 6/1/00 4:07:36 PM EDT, bparsia(a)email.unc.edu=> << Now, if only the updates were compressed..... >> and available in archival form (i.e., .zip, .tar.gz, .tgz, .sit, etc.) Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Re: Proposal3: Make $_ a valid identifier character
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

=> 6/1/00 3:29:40 PM EDT, sr(a)evolgo.de => << So I vote for including the $_ as valid char in selectors/vars, but with having the policy (by style guides?) to use it rarely. >> Hi Stephan, [BTW, I think your comments preceeding this statement are quite sober, and should be read by others who have strong opinions on this issue] Okay, and keep := for assignment. Does that mean that you'll tolerate elimination of the left arrow _? Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

RE: Large array slows down Squeak
by Parker, Mike 01 Jun '00

01 Jun '00

> At 08:51 31.05.00 -0500, you wrote: > > > > And there's another interesting observation. In Morphic, > the delay > > > because of tenuring is much larger than in MVC. This is probably > > > because Morphic creates much more short-lived object garbage. > > > >Umm, 'splain again why tenuring would make Morphic feel slow? > > My guess was that these objects aren't short-lived enough. > If they survive > one GC, they need to be copied - and this might take quite a few > milliseconds. I'd guess that Morphic creates too many Point > and Rectangle > objects just to draw one screen. And as there are most often > stepping > objects which require continuous screen updates, it will GC > quite often. > > So perhaps a "Smalltalk vmParameterAt: 5 put: 10000" will > reduce the > number of GCs. Could you please explain why increasing this > value has problems? I'm certainly not an expert on the Squeak collector, so one of the authors of the collector may want to step in and correct me, but here goes: The memory system reserves 4000 words at the end of eden to be used for storing relocation records. This is enough to relocate a minimum of 2000 objects. If there is additional spare free memory at the end of eden, it will also be available for relocation records. If I'm reading the code correctly, if it runs out of relocation records, it only compacts the last contiguous run of surviving objects up against the next-to-last contiguous run of survivors, then tries the compaction process again. If compacting that one survivor run freed up enough memory at the end of eden space that there is now enough room for all the relocation records, then this second compaction pass will complete normally. If not, then it again falls back to compacting the last two runs together. Needless to say, this can get really slow, and (I think, I need to refresh my memory when I get back home) contains the possibility that a minor compaction may fail to terminate (if the last contiguous run contains more objects than there are relocation records). At any rate, the combined affect of the 4000 object gc threshold and the 2000 object tenuring threshold is that these pathological cases don't happen very often, at the cost of (imho) excessively frequent minor collections, as well as reduced flexibility in the scavenging and tenuring policies. > >Creating lots of temporary objects will trigger lots more minor > >GC's which could make it run slower. > > Yes, that was my argument. To prove it, I created a simple test for > morphic. Without any interaction and just a workspace (and of > course my > InfoStringMorph) open, I get about 2 incremental GCs per second. > > Selecting text in the workspace raises the GCs/sec to 25! > > If I increment the object count to 10000, I get only 9 GCs/sec when > selecting text in that same workspace. About what I would have expected. OTOH, each minor GC will take a bit longer, but as long as your code matches the generational hypothesis the GC time doesn't increase linearly. > I think, this proves that objects live too long. Not really. It just proves that forcing a minor GC every 10000 allocations will trigger fewer GC's than triggering one every 4000 allocations. 9/25 is roughly equal to 4/10 (2.7 vs 2.5) > My system spends about 10 milliseconds or 1% of all time in GCs > per second. (0.3% if count = 10000) One of the goals of Squeak's allocator (and of scavenging collectors in general) is to reduce GC-induced latency to <10ms, short enough that you shouldn't notice it if it happens while you're tracking the mouse. If your numbers are right, and you're only spending about 1% of your time in the collector when you're in Morphic, then GC overhead wouldn't appear to be the cause of Morphic's slowness relative to MVC. > If I allocate a one-million-elements array, spends about 230 > milliseconds or 23% of all time in GC per second (12% if count > = 10000)! This means, the incremental GC doesn't scale well > at all. Yep, this isn't a good thing, but Squeak isn't the first system to dislike large pointer-containing objects. They violate some of the fundamental assumptions underlying generational scavenging technology. Still, 23% GC overhead in this case isn't too bad if you think about it. Under normal circumstances Squeak tries to keep < 2000 objects in edenspace. Assuming 25-30 bytes/object that's only about 60k on average. Suddenly you inject about six thousand times that much data into eden but the collection time only increases by a factor of 23! Actually, 23% overhead isn't bad anyway in the grand scheme of things. I'm pretty sure it was Benjamin Zorn who profiled a bunch of allocation schemes (mark & sweep, mark & sweep & compact, mark & sweep & compact with a separate mark bit array, stop & copy, generational scavenging, as well as a variety of malloc/free implementations), and discovered several real-world C programs that had memory management overheads greater than 40%, while most commonly used garbage collectors managed much lower overhead under much higher allocation loads. Prematurely tenuring large objects isn't really a good answer either, because object size is a poor predictor of object lifetime, so when the references to this object disappears it'll become a huge chunk of nothing clogging up your oldspace, and partly because writes into tenured objects are much more expensive than writes into untenured objects. This may not be so noticeable in a system like Squeak, where the interpreter overhead can mask the 20-40 instruction overhead, but it's much more noticeable in a compiled, optimized system like SML or Self. Another problem is that unless all the objects in this array are also tenured, the collector will still have to scan the array every minor GC looking for pointers to objects in eden. Unfortunately, there is no universal solution. Industrial- strength collectors tend to have whatzit-knobs and tommybars all over them to allow them to be tuned to the particular application, but to my knowledge no collection scheme deals gracefully with anything but an idealized "general case". I don't know how interested you are in persuing this, but I'd be interested to know what the GC overhead was in the case where you did the major GC just before allocating the large array (so that it was created at the front of edenspace and therefore wouldn't need to be moved during compaction).

1 0

Re: [BUG] vmTable:at:
by Bob Arning 01 Jun '00

01 Jun '00

On Thu, 01 Jun 2000 14:41:48 +0200 Stefan Matthias Aust <sma(a)3plus4.de> wrote: >Can be remove vmTable:at:, yes? It's identical to vmParameterAt: and has >no sender. I just ask because perhaps somebody relays on this method. Stefan, While the comment may seem similar to that in #vmParameterAt:, it's just plain wrong. Primitive 254 does different things depending on the number of arguments, so #vmTable:at: actually provides functionality identical to #vmParameterAt:put:. Cheers, Bob

1 0

Re: BCPL in the new millenium (was: Proposal3: Make $_ a valid id entifier ch...
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

=> 6/1/00 2:55:45 PM EDT, mparker(a)CaseServices.com => << Oh well, back to the C++ salt mines. >> We're coming, we're coming, please just leave a trail of bread-crumbs. Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Re: [ENH] More Faster Senders
by Andres Valloud 01 Jun '00

01 Jun '00

Hi Stefan. > I really appreciate your refactorings to speed up Squeak (and I'm sure > other do, too) but I'd like to ask you to please use attachements to submit > your code. This will speed up adding your enhancement to the base image ;-) Hey! I never meant NOT to use attachments!!! This Netscape shows me my own attachments attached... sorry about that!!! I just sent you a mail to check if my attachments are working properly now. Thanks for letting me know. I would never have noticed something was going wrong. Andres.

1 0

RE: Large array slows down Squeak
by Parker, Mike 01 Jun '00

01 Jun '00

> And there's another interesting observation. In Morphic, the delay > because of tenuring is much larger than in MVC. This is probably > because Morphic creates much more short-lived object garbage. Umm, 'splain again why tenuring would make Morphic feel slow? If Morphic creates lots of short-lived objects, then much (most?) of those objects won't survive long enough to get tenured; besides, isn't tenuring only done every now and then, when incremental GC's get too long (too many survivors) or the root table gets full? > Thinking about this, could this be the reason, why Morphic > always feels a little bit slower than MVC? If yes, then the best > approach to speed up Morphic would be to reduce the number of > temporary objects... Creating lots of temporary objects will trigger lots more minor GC's which could make it run slower. However, there are several improvements to the collector that could improve this. Dynamically adjusting the allocation threshold (currently fixed at 4000) and tenuring policy could reduce the frequency of minor GC's, giving those short-lived objects more time to die while keeping minor GC duration below the 10ms threshold. Looking at the collector, though, it looks like the reason for the 4000 object allocation threshold is because the relocation phase doesn't deal very well with the case where more than 2000 objects need to be relocated in a single minor collection, although this could be tweaked.

3 2

Re: Cheap updates
by Bijan Parsia 01 Jun '00

01 Jun '00

--On Thursday, June 01, 2000, 2:54 PM +0200 "Bert Freudenberg" <bert(a)isgnw.CS.Uni-Magdeburg.De> wrote: > Hi all per-minute online time paying Squeakers, > > I just discovered a nice method to fetch updates without updating the > system which sometimes takes a while for recompiling. Just put the > following statement into the "do..." menu: > > Utilities readServerUpdatesSaveLocally: true updateImage: false Now, if only the updates were compressed..... Cheers, Bijan Parsia.

1 0

RE: BCPL Needs => Free C and ASM
by Parker, Mike 01 Jun '00

01 Jun '00

GNU C++ works well on the PC side. You'll need Cygwin if you're running NT or 95. I've got a hacked version that generates native executables (unoptimized, but still faster than the interpreter) using the Cygwin tools. > -----Original Message----- > From: JArchibald(a)aol.com [mailto:JArchibald@aol.com] > Sent: Thursday, June 01, 2000 4:31 AM > To: squeak(a)cs.uiuc.edu > Subject: BCPL Needs => Free C and ASM > > > All-- > > Can anyone recommend free C and Asm resources for either Mac > or Windows > platforms. I downloaded the BCPL material, and it looks like > it will require > some grunge work to get it going [one of those times when I > wish I had a > Linux system up -- next week -- LOL ]. > > It was a delight to see a site (www.cl.cam.ac.uk/users/mr/) > well laid out, > which is what I would expect from Martin. He was on a > sabbatical at IBM > Research in the early '70s, and I succeeded him in being the > 'keeper of the > keys' for his port of BCPL to VM/CMS. He had left everything > in perfect order > for me to take over. I continued to use this BCPL until I > left IBM in 1993 > (20 years, pretty good record for durability). > > I build a theorem prover (for Effigy [symbolic execution] > headed by Jim King) > in a personally modified BCPL. BCPL was written in BCPL, > still a somewhat > novel concept at the time [though the Fortran H was the > originator (I had > worked on that {I/O packages in S/360 assembler language} in > 1965)]. It did > have a primitive package (jeez, I wonder where that came from > ... ) written > in assembler, which is what Martin had ported. > > Any pointers will be appreciated. > > Cheers, > Jerry. > ____________________________ > > Jerry L. Archibald > systemObjectivesIncorporated > ____________________________ > > "I can't think of the author." Anon. >

1 0

BCPL Needs => Free C and ASM
by JArchibald＠aol.com 01 Jun '00

01 Jun '00

All-- Can anyone recommend free C and Asm resources for either Mac or Windows platforms. I downloaded the BCPL material, and it looks like it will require some grunge work to get it going [one of those times when I wish I had a Linux system up -- next week -- LOL ]. It was a delight to see a site (www.cl.cam.ac.uk/users/mr/) well laid out, which is what I would expect from Martin. He was on a sabbatical at IBM Research in the early '70s, and I succeeded him in being the 'keeper of the keys' for his port of BCPL to VM/CMS. He had left everything in perfect order for me to take over. I continued to use this BCPL until I left IBM in 1993 (20 years, pretty good record for durability). I build a theorem prover (for Effigy [symbolic execution] headed by Jim King) in a personally modified BCPL. BCPL was written in BCPL, still a somewhat novel concept at the time [though the Fortran H was the originator (I had worked on that {I/O packages in S/360 assembler language} in 1965)]. It did have a primitive package (jeez, I wonder where that came from ... ) written in assembler, which is what Martin had ported. Any pointers will be appreciated. Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ "I can't think of the author." Anon.

2 1

Jump to page: