Squeak-dev March 2001

squeak-dev@lists.squeakfoundation.org

139 participants
508 discussions

Re: Squeak slowdowns (Unix 3.1)
by Bob Arning 04 Mar '01

04 Mar '01

Ned, A few questions: - When things are running well and you Sensor inspect what class is it and, if it is an EventSensor, what is its eventQueue? - When things are starting to go bad, same questions as above. - Between the times it is running well and running poorly, do any of the following happen (especially if they always happen): -- Do you get walbkacks in projects which are "isolated"? -- Do you switch between Morphic and MVC? -- Anything else notable happen? Cheers, Bob On Sat, 3 Mar 2001 18:33:39 -0800 Ned Konz <ned(a)bike-nomad.com> wrote: >On Tuesday 20 February 2001 21:15, Ned Konz wrote: >> I'm using the 3.0pre2 Unix VM under Linux 2.4.0, with a 3.1 image. >> What I'm finding is that: >> >> * normally things run pretty well; if I do a Message Tally I see about >> 80% of the time being spent in Delay>>wait. The CPU usage is below 5% for >> Squeak. >> >> * sometimes, though, Squeak uses about 100% of a CPU, and if I do a >> similar Message Tally, I see 75% of the time being spent in >> EventSensor>>nextEventFromQueue. >> >> It can go from the "good" state to the "bad" state just by being left alone >> with no interaction. >> >> Saving the image, quitting, and restarting fixes this problem. >> >> Any suggestions? > >OK, more details: I did about 10 seconds of MessageTally without moving the >mouse. > >Here's when it gets slow (system CPU at 95% for Squeak process): > - 558 tallies, 9715 msec. > >**Tree** >99.8% {9696ms} DisplayScreen>>doOneCycleMorphic > 99.8% {9696ms} PasteUpMorph>>doOneCycle > 99.8% {9696ms} WorldState>>doOneCycleFor: > 95.0% {9229ms} WorldState>>doOneCycleNowFor: > |89.4% {8685ms} HandMorph>>processEvents > | |89.2% {8666ms} EventSensor>>nextEvent > | | 89.2% {8666ms} EventSensor>>nextEventSynthesized > | | 46.8% {4547ms} EventSensor>>primKbdNext > | | 42.5% {4129ms} EventSensor>>primMousePt > |5.6% {544ms} PasteUpMorph>>runStepMethods > | 5.6% {544ms} WorldState>>runStepMethodsIn: > | 5.6% {544ms} WorldState>>runLocalStepMethodsIn: > | 2.7% {262ms} StepMessage(MorphicAlarm)>>value: > | 2.7% {262ms} NCLineEndConstraintMorph(Morph)>>stepAt: > 4.8% {466ms} WorldState>>interCyclePause: > 4.8% {466ms} Delay>>wait

2 1

Squeak slowdowns (Unix 3.1)
by Ned Konz 04 Mar '01

04 Mar '01

I'm using the 3.0pre2 Unix VM under Linux 2.4.0, with a 3.1 image. What I'm finding is that: * normally things run pretty well; if I do a Message Tally I see about 80% of the time being spent in Delay>>wait. The CPU usage is below 5% for Squeak. * sometimes, though, Squeak uses about 100% of a CPU, and if I do a similar Message Tally, I see 75% of the time being spent in EventSensor>>nextEventFromQueue. It can go from the "good" state to the "bad" state just by being left alone with no interaction. Saving the image, quitting, and restarting fixes this problem. Any suggestions? -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

2 3

Re: How to execute external programs across platforms?
by Jeff Szuhay 04 Mar '01

04 Mar '01

>Of course, for MacOSX, there will be other options, I'd imagine. No. Applescript will be fully supported on OS X. In fact, there was talk at last year's WWDC of being able to create full apps using Applescript as the main language (well, you can do that now) but from within IB/PB. So, we'll have to see. Anybody going to WWDC 2001? I am. Jeff 8-) -- ************************************************** Jeff Szuhay A randomly-directed www.szuhay.org chaotical wetware pattern jeff(a)szuhay.org recognizer/generator. Nothing of importance happened today. -- From George III's diary, July 4, 1776

1 0

Re: New Connectors Demo, Refrigerator Magnets on Bob's Super Swiki
by Ned Konz 04 Mar '01

04 Mar '01

On Saturday 03 March 2001 15:19, Karl Ramberg wrote: > > You might try deleting the classes in the config map and then reloading. > How do I do that ? By going to a browser, and removing the categories Morphic-NK-MagneticPoetry and Morphic-NK-Connectors. Then do a garbage collect, and try re-loading. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

New Connectors Demo, Refrigerator Magnets on Bob's Super Swiki
by Ned Konz 04 Mar '01

04 Mar '01

I've just posted new versions of my NewConnectorsDemo and the RefrigeratorMagnets on Bob's Super Swiki. These fix performance problems and potential walkbacks in the ConstraintMorphs. You may get walkbacks if you switch to older versions of these projects (or try to use older versions). To avoid this, after loading one of these newer projects (and without changing projects!), execute the following in a Workspace window: NCConstraintMorph allSubInstancesDo: [ :ea | ea stepTime: 100 ]. I couldn't figure out how to attach this to the Project for execution (though it may have worked to put it in as a postscript on the change set, I don't know). -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

2 3

[ENH] PPMReadWriter-nk
by Ned Konz 03 Mar '01

03 Mar '01

from preamble: "Change Set: PPMReadWriter-nk Date: 27 August 2000 Author: Ned Konz This is my second cut at a PPM reader/writer. It will write a 256x256x32 Form out to a file in less than 3 seconds on my machine. It may be somewhat slower on 16 and 8 bit color depths. An off-by-one bug was fixed in the prior version. Currently, it only reads rawbits (P6) images. I'm putting it out so that it can be used in the ICFP Programming Contest."!

1 0

MacVM 3.0MT8
by Bruce ONeel 03 Mar '01

03 Mar '01

Hi, It's in the 3.0 directory. Readme below. cheers bruce The macintosh 3.0Alpha8 VM, Feb 28th 2001 This VM was built with the base 3.x image at change set #3740. What has been fixed/changed. V3.0.8 1) The caps lock no longer maps to the shift attribute. So if the caps lock is down mouse clicks will behave normally. 2) Numerous fixes for the BitBltPlugin plugin 3) Memory allocation grow/shrink logic for Carbon was added. 4) Spurious mouse clicks for the browser plugin has been fixed. (This took awhile to fix, I'm sure it's a bug with the Swedish version of Netscape) 5) The browser plugin will attempt first to allocate memory from the browser heap, then the system heap. Most people when faced with a memory issue usually increase memory for the browser first. However memory for the plugin is controlled by an attribute in the EMBED HTML statement. V3.0.7 1) A bug exists in pre OS 8.x that causes a crash in activate window if the standard get file dialog comes up before the Squeak Window. I remove the InvalWindow call found in that routine since it is actually redundant. 2) The standard get file dialog on system 7.x would not terminate if you did a cancel. 3) The InterfaceLib had to be weak linked to prevent CFM startup issues. V3.0.6 1) Alias resolving is less aggressive. 2) We no longer cache image reads or writes. This was done because OS 9.1 allows you to have very large disk caches, and it's pointless to cache the image read or write. 3) The file flush primitive now actually flushes the file via an OS call. This was a bug in the CodeWarrior 5.3 source code. 4) The 68K version was being built with the 68881 math library. This fails on 68040LC chips. We now use the non-68881 math library. Thanks to Bruce ONeel for find this. 5) A bug was found in the path resolving logic that was added for 3.x. This bug apparently only affects 68K machines, never was identified as a PowerPC issue. 6) The Netscape plugin needs a properly allocated clip region, this code seemed to work ok on new systems, but fails on system 7.6.1 7) The security interface will create a Documents folder on the root volume if the default Document folder has been deleted. This is needed for security purposes. 8) Jitter needs 1MB of free memory to run. 9) 68K machines require another 32K of stack 10) Threads now work on 68K machines, but turned off because of possible performance issues. (I think more study is needed). 11) The 68K version was compiled with better optimization, expect a 15% improvement. 12) fix for BitBltPlugin ascii = byteAt((sourcePtr + charIndex) - 1); 13) The interpreter object validation checking code was alter to work correctly. V3.0.5 1) sqConfig.h changed due to BE OS header changes 2) sqMacDirectory.c. Added support for Navigation services or Standard File Get to find the image at startup time when the Squeak.image is not found by the VM. This replaces the DOS like console message that comes up saying that Squeak can't find a image. 3) A fix to drag and drop for the browser plugin. 4) We now use Apple's cooperative multithreading package to run the UI in one thread, the VM in the other. This solves some issues with the browser and makes the UI versus VM logic and execution responsibilities easier to understand. 5) Changed the sqMacNSPlugin.c code to support a 3.0VM using multithreading support. This should give Squeak in a browser better performance. Also changed the full screen support to correctly work with multiple monitors. 6) BitBltPlugin.c gets one more op code 7) Added the security interface 8) Added the file flush primitive 9) Rewrote the macintosh readme file 10) Revisited the zoomWindow code and found a bug with multiple monitor support, then I fixed the code to make Full Screen mode work on screen that Squeak window is mostly on, versus the menubar screen. Also if you switch from full screen back it resizes the window back to the orginal size and location before you invoked the full screen. V3.0.2 Plugins Recompiled the internal BitBltPlugin plugin to encorporate: Change Set: 258AlphaBlendOpt-dsm Author: Duane Maxwell, Paul Phillips/exobox a) Short circuits full opaque and full transparent pixels when alpha blending. Recompiled the internal LargeIntegerPlugin 3298LargeIntegersV1-2-sr -- Stephan Rudlof -- 29 November 2000 3299LargeIntV1-2For29-sr -- Stephan Rudlof -- 29 November 2000 VM Software (b) PowerManagement for macintosh is now supported. You can disable the power manager to give you better performance on some powerbooks at the expense of battery life. See the Preferences Panel for details, category 'Performance' - changed sq.h - changed sqMacWindow.c to add support for power mgr disabling (c) Drag and Drop support for the macintosh, dragging files from the Finder to the Squeak window is now supported. - sqMacDragDrop.c added - sqMacWindow.c changed (d) Added primitive for get macintosh creator and file type. - sqMacDirectory.c changed (e) Carbon support. Thanks to Karl Goiser karl(a)wattle.net for work he did on sound and other Carbonization hotspots. - sqMacAsyncFilePrims.c changed - sqMacFFIPPC.c changed (not supported for Carbon) - sqMacNetwork.c changed per Apple tech note 1173 Carbon asset tracking -sqMacSerialAndMIDIPort.c chnaged (Not supported for Carbon) - sqMacSound.c changed per Apple tech note 1198 Carbon double sound buffer playing - sqMacWindow.c changed (various changes for Carbon) (f) Poll at least 60 times a second for the mouse if required. Previous 2.9.x VM did it 30 times but this is too slow and 2.8.x VM do it 60 times a second. (g) Reworked path support Thanks to Karl Goiser karl(a)wattle.net for starting this. - sqmacDirectory.c changed reworked lookupPath - sqMacWindow.c changed, added GetApplicationDirectory to get application directory (h) I rewrote the sqMacDirectory.c logic to enable proper understanding of Apple's Alias logic. This means for example you can alias the "SqueakV3.sources" file and then only have one copy and have all your images point to it. (i) Added Zoom Window support. (j) Change the Squeak change file icon to better match Apple's visual guidelines, Thanks to Doug Way for the suggestion and the new icons. (k) The sound plugins have changed... (j) Dropped FFI out of the base Squeak because of security concerns (k) Compiled for 750(G3) processor versus 603 (l) Added screenDepth primitive The 3.0.x VM contains most of the optional plugins, you might want to check this by inspecting "Smalltalk listBuiltinModules" to see where your plugins are coming from. In some case people have been accidentally overriding the new builtin plugins with older plugins. The file "Squeak 3.0Alpha7.asc" contains the PGP signature for the Squeak 3.0Alpha7 VM The file "NS-Squeak VM 3.0.asc" contains the PGP signature for the NS-Squeak VM 3.0.asc browser plugin John M McIntosh johnmci(a)smalltalkconsulting.com

5 5

Tailored Major Shrinks -- was: re: [NEWBIE - BUG ?] Fileout
by JArchibald＠aol.com 03 Mar '01

03 Mar '01

Greetings to you, PhiHo-- => 3/2/01 10:39:53 PM EST, phiho.hoang(a)home.com => << Greetings, I am trying to add FFI functionality to the majorShrinked Squeak3.0.image (latest update #3552), VM 3.0 (release build 2). >> What's the real objective here? Why are you adding to majorShrinked image? I presume you need this for some "small" application destination. And what is needed is a "shunken" image + some facilities (restored from the original unshrunken image). If it is not something like this, do whatever you are up to in the full system. Save majorShrink activities for solving delivery problems (space, delivery band-width, etc.), as it is somewhat a trial to get what you need working. In general, what you might find the quickest way to get what you need is to: (1) Figure out what are the primary facilities you want in the new shrunken image (the "some" facilities restored). (2) Iteratively figure out what is needed (dependencies) to make these work. (3) Remove the appropriate "delete" statements from the "majorShrink" code. (4) Perform #majorShrink (leave out #abandonSources and #lastRemoval) (5) Test (6) Go back (iterate) and re-evaluate #1 and #2 above. << When 'FFI-Kernel.st' (this was filed out from the full Squeak3.0.image) was filed in, I got a walkback 'MessageNotUnderstood: allSubInstancesDo:'. (The file 'Filein_FFI-Kernel.log' is attached) >> The relevant thing here is the missing #allSubInstancesDo:. This is because it is not called in the shrunken image. I can't tell exactly what's going on from your walk-back, but my guess is that it may be similar to one of the "clever" things that Morphic facilities do -- often out-guessing the compiler to get some specialized (non-standard) Smalltalk behavior. Something in your needed classes is calling routines that mess with the instance variables (look up the walk-back to see this). << Is this because of the order of the classes in a fileout, must they be sorted according to the hierarchy ? > That is an important consideration, but not really relevant here. majorShrink removes anything not used. If you deliberately remove something and then restore it by fileIn, you will need to file it back in in appropriate hierarchical order (top down). This is exactly the way I create Mini Swiki systems; I file out relevant classes, shrink, and then file relevant classes back in. Normally this is not needed, but Swiki is special (see below). << During the process of transfering the FFI functionality to the majorShrinked image, I had to look at the hierarchy browser and manually file out and in, in a proper order. Followings are the files and order that were filed in: >> Again this may be necessary, but the above suggested scenario would have you figure out how to remove these classes from the "shrink" process so you don't have to add them back in. (Also removing them before enables majorShrink to shrink those additional facilities (classes) also, removing unneeded methods from their signatures.) Of course, there are many sub-systems (components) which have a lot of "blind" methods (a good example is PWS), which are needed by the facility, but are not called by methods contained in the facility. Much of the PWS functionality is driven by method references which are contained in the "pages" on the server, and typically all called ONLY from there. Start by adjusting "shrink" code (#majorShink and methods called from it) to leave these in where they are removed. As an example, Behavior, ClassDescription and Metaclass are not going to be removed, but methods within them are being "shrunk" out of the image when other classes are removed. So change SystemDictionary>>#majorShrink to remove the line sending Smalltalk discardFFI. "33k" (BTW, the space saved figures are quite old, and can only be depended on for relative estimates.). Then attempt to Shrink as see how close you get. Iterate. << VMConstruction.Plugins.InterpreterPlugin OK VMConstruction.Plugins.FFIPlugin OK Kernel.Classes.Behavior OK Kernel.Classes.ClassDescription OK Kernel.Classes.Metaclass OK FFI-Kernel-> MessageNotUnderstood: allSubInstancesDo: (ExternalType, ExternalStructure, ExternalData not filed in) FFI.Kernel.ExternalType OK FFI.Kernel.ExternalStructure OK FFI.Kernel.ExternalData OK FFI-Plugin OK FFI-Examples-MacOS OK FFI-Examples-Win32 OK FFI-Examples-X11 OK >> << Is there an easier way to do this ?>> Unfortunately not. At least, not yet. I have been working on some componentizing tools, but they are not ready for prime time yeT. <<Thanks for your help, PhiHo >> You are welcome. Hope this helps, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Re: [ENH][plugin] hashSpeedup-sr
by Stephan Rudlof 03 Mar '01

03 Mar '01

Mark, Mark van Gulik wrote: > > on 2/28/01 5:18 PM, Stephan Rudlof at sr(a)evolgo.de wrote: > ... > > History: > > First I have tried just to make a primitive for SmallInteger>>hashMultiply, > > but this hasn't speeded up things! Reason: no message send occurs inside > > this method in real... > > Thanks, that's the intention. I glanced at the generated C code and it's > horrible. Which one? I haven't posted any plugin code for >>hashMultiply and the posted one from String>>primStringHashFor: string startHash: startHash results in EXPORT(int) primStringHashForStartHash(void) which has in its core loop (looping over the string) at the C side: --- for (ix = 1; ix <= lastIx; ix += 1) { hash += asciiValue(string[ix]); low = hash & 16383; hash = ((9741 * low) + ((((9741 * (((unsigned) hash >> 14))) + (101 * low)) & 16383) * 16384)) & 268435455; } --- I think this C code isn't so bad. And there are advantages: - the Smalltalk method from which it is generated is executable - as it is - if the plugin is missing! This makes it clear that the semantics are the same; - if there should be a change at the ST side, you'd just have to regenerate the plugin/VM and the semantics are in sync (in spite of this you have to be careful here...); - last but not least: I was able to realize it in reasonable time without thinking about numerics, I'm not an expert here. > I'm not really "up" on the latest Squeak stuff, but isn't there a > way of specifying C translations directly for some methods? Do you mean the TestInterpreterPlugin mechanism? First I have made a version with it, but for this case I've thought the older variant fits better. > If so, there is > a method (or maybe it's already been manually inlined) whose sole purpose is > to multiply by 1664525, modulo 2^24. It was coded in a roundabout way, to > avoid large integer math. In C this is not necessary. Instaed just "*" the > receiver by 1664525 and "&" it with 0x0FFFFFFF. Actually, we only need to > mask the *final* result of the hash, as upper bits don't affect lower bits. This probably would be an improvement (assumed the compiler isn't very intelligent), but also had the drawback to keep two ST methods in sync (the C specific plugin method and the ST method working if the plugin is missing, the latter beeing there then to avoid LargeIntegers arithmetics!). But feel free to post your version! > > You may want to avoid the invocation of String>>at: which is just a C array accesss, > and > Character>>asciiValue which is #define asciiValue(c) c (effectively a noop) in the plugin. > in your primitive, and make sure you're using C > integers throughout. There are only C integers in the core loop, isn't it? > I'd guess this should drop the time by *at least* a > factor of two. Ask your C compiler to generate assembly code to get a feel > for what it's really doing down deep. > > In addition, because it's just a polynomial evaluation with a known constant > for the "variable", we can allow better processor parallelism by > accumulating all the even terms while in parallel accumulating all the odd > terms. You'll need to multiply by the square of 1664525 mod 2^24 between > successive even terms (and between successive odd terms). The multiplier > squared mod 2^24 is 121134249. When you're done, just multiply the even > accumulation by 1664525 and add the odd accumulation. You might even want > to do four simultaneous streams instead of two to really keep the CPU > humming. If Squeak guarantees that the "pad" bytes of a > non-multiple-of-four-byte String are all zero, you can simply overrun the > actual String characters, merge the streams, and then fix up for 0-3 zero > bytes that aren't part of the String proper. Hint: The inverse of 1664525 > mod 2^24 is 249583813, as can be shown by the identity "(1664525 * 249583813 > bitAnd: 16r0FFFFFFF) = 1". A table of this inverse raised to 0, 1, 2, and 3 > should make this pretty quick. It may be that there are further improvements possible, but I don't think that this core loop is a bottleneck. And: There is an about factor 10 improvement for long strings *now*! Again: Feel free to post an improved version, but I don't expect dramatical speedups seen from the ST side. Greetings, Stephan > > > " > > > > For me it is (Linux (without jitter)): > > > > Time millisecondsToRun: [100000 timesRepeat: [#n hash]]. > > 1611 1603 1607 "filed in without plugin" > > 1061 1060 1067 "filed in with plugin" > > 1453 1465 1449 "before" > > Time millisecondsToRun: [100000 timesRepeat: [#namenamenamenamenamename > > hash]]. > > 8928 8888 8901 "filed in without plugin" > > 1273 1290 1281 "filed in with plugin" "!" > > 10685 10684 10687 "before" > > > > To compile evaluate > > MiscPrimitivePlugin translateDoInlining: true > > . > > > > Greetings, > > > > Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 1

Re: growing and shrinking ObjectMemory
by Lex Spoon 03 Mar '01

03 Mar '01

Bert Freudenberg <bert(a)isg.cs.uni-magdeburg.de> wrote: > On Fri, 2 Mar 2001, Lex Spoon wrote: > > > Anyway, after a little thought, I came up with the below code which can > > release memory that's no longer used. The trick used is to munmap() > > unusued portions and then to mmap() them back again in order that the > > region of memory stays contiguous. > > Looks better already :) > > Still, you're mmapping the entire MEMORY_TO_USE while I think it would > suffice to just mmap what was asked for. > Actually, I think such a big chunk needs to be allocated, in order to assure that the ObjectMemory can grow when requested. If only the minimal amount is allocated, then two problems can come up: 1. The region could be mapped at the *end* of the usable address space, so there won't be any room to grow. 2. Some other code in the VM, eg the malloc() library, could call mmap() and take over the address space just following our own. I don't know a good solution to these problems other than to allocate a big chunk up front. Well... it would be neat if the Squeak allocator could deal with non-contiguous chunks of memory. But that's complicated.... -Lex

1 0

← Newer
1
...
44
45
46
47
48
49
50
51
Older →

Jump to page: