Dean,
Interesting side note: This is about 30% faster than my 450 MHz Pentium II at work.
Check out how much L2 cache you have in the machines - it could make a huge difference.
Now on to the Win32 VM stuff. Running on the P133 machine (aSharp Widenote), mouse clicks were definitely getting lost when running in Morphic, and I also experienced long periods of un- responsiveness - not as bad as on the Casio E-105, but several seconds anyway. This behavior was not apparent under the standard UI.
Lost mouse clicks are definitely not a Win32 issue - it happens on all machines that are slow enough. The events are received by the VM but Morphic just does not poll often enough to get the mouse clicks (e.g., when the mouse gets down and up inbetween two poll cycles you have a lost mouse click).
I'm not sure about the long pauses but I suspect that this is no Win32 issue either. I'd recommend looking at the image side and try to figure out if the problem might be GC related (wild guess: having a big image and not enough memory might cause the system to swap like hell on full GCs).
Andreas -- +===== Andreas Raab ========= (andreasr@wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
At 11:03 AM 8/20/1999 -0700, you wrote:
Dean,
Interesting side note: This is about 30% faster than my 450 MHz Pentium II at work.Check out how much L2 cache you have in the machines - it could make a huge difference.
The difference could also be attributable to the longer branch misprediction penalties of the Pentium II compared to the newer PowerPC chips. The x86 instruction set is harder to decode and takes more cycles to do so, so a mispredicted branch takes more cycles. Meanwhile, the PowerPC processors have about the lowest branch misprediction penalty of any chip I am familiar with. The bytecode branch, at least, will likely be mispredicted.
Now on to the Win32 VM stuff. Running on the P133 machine (aSharp Widenote), mouse clicks were definitely getting lost when running in Morphic, and I also experienced long periods of un- responsiveness - not as bad as on the Casio E-105, but several seconds anyway. This behavior was not apparent under the standard UI.
Lost mouse clicks are definitely not a Win32 issue - it happens on all machines that are slow enough. The events are received by the VM but Morphic just does not poll often enough to get the mouse clicks (e.g., when the mouse gets down and up inbetween two poll cycles you have a lost mouse click).
I'm not sure about the long pauses but I suspect that this is no Win32 issue either. I'd recommend looking at the image side and try to figure out if the problem might be GC related (wild guess: having a big image and not enough memory might cause the system to swap like hell on full GCs).
Andreas
+===== Andreas Raab ========= (andreasr@wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
Greg Gritton (greg@gritton.org)
Lost mouse clicks are definitely not a Win32 issue - it happens on all machines that are slow enough. The events are received by the VM but Morphic just does not poll often enough to get the mouse clicks (e.g., when the mouse gets down and up inbetween two poll cycles you have a lost mouse click).
Can someone explain to me why mouse clicks can't have a sticky bit so that only the second click is lost, not the first?
A second mystery to me is why Filein operations are irreversable. What's the problem? I know how to write the reversing instructions when I do the damage in other systems. Why do people put up with being unable to retreat?
Dick
A second mystery to me is why Filein operations are irreversable. What's the problem? I know how to write the reversing instructions when I do the damage in other systems. Why do people put up with being unable to retreat?
Why do you add this holier-than-thou spin to an otherwise reasonable question?
First, although, as Dwight points out, a fileIn can have any kind of executable code in it, most are pretty well behaved (add/remove methods, instVars, classVars, classes), and most of these changes could be reversed without a huge amount of bookkeeping. It might be worth doing.
Second, there is the nascent capability to isolate projects with regards to many such changes. So one could open a new project, try out the fileIn in it, and then assert the changes throughout or remove the project depending on whether the results were favorable. This mechanism cannot currently isolate all possible changes.
Now to answer your rhetorical question. The reason people put up with things the way they are is that Squeak's save/restore at the image level is usually simpler, faster and more effective than any of the alternative undo schemes we have considered. It's quite possible, though, that it should be packaged and presented better so that you don't feel so bereft of even the most basic support.
- Dan
Another alternative is to consider implementing a (non trivial) persistence/transaction system.
GS Smalltalk has this, and it becomes quite indispensable; something screws up, you do an abort, everything is the way it was.
It changes the way you do change tracking & stuff like that, however. If your image crashes, for example, all the changes you have committed are safe. So your change set, instead of hanging on to the context to reproduce the change, can hang on to the context to undo the change.
There is open source transaction code in the Postgres distribution.
Although this may sound like overkill, it's more elegant than Dwight's suggestion of backing up the image before every file-in.
Of course the transaction stuff could possibly be useful for more than just file-ins :-)
Steve (be kind, it's early :-)
-----Original Message----- From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] Sent: September 1, 1999 12:07 AM To: Dick Karpinski Cc: squeak@cs.uiuc.edu Subject: RE: More Benchmark Results + Problems with Win32/WinCE VMs
A second mystery to me is why Filein operations are irreversable. What's the problem? I know how to write the reversing instructions
when I do the
damage in other systems. Why do people put up with being unable
to retreat?
Why do you add this holier-than-thou spin to an otherwise reasonable question?
First, although, as Dwight points out, a fileIn can have any kind of executable code in it, most are pretty well behaved (add/remove methods, instVars, classVars, classes), and most of these changes could be reversed without a huge amount of bookkeeping. It might be worth doing.
Second, there is the nascent capability to isolate projects with regards to many such changes. So one could open a new project, try out the fileIn in it, and then assert the changes throughout or remove the project depending on whether the results were favorable. This mechanism cannot currently isolate all possible changes.
Now to answer your rhetorical question. The reason people put up with things the way they are is that Squeak's save/restore at the image level is usually simpler, faster and more effective than any of the alternative undo schemes we have considered. It's quite possible, though, that it should be packaged and presented better so that you don't feel so bereft of even the most basic support.
- Dan
Steve Wart wrote:
Another alternative is to consider implementing a (non trivial) persistence/transaction system.
GS Smalltalk has this, and it becomes quite indispensable; something screws up, you do an abort, everything is the way it was.
It changes the way you do change tracking & stuff like that, however. If your image crashes, for example, all the changes you have committed are safe. So your change set, instead of hanging on to the context to reproduce the change, can hang on to the context to undo the change.
There is open source transaction code in the Postgres distribution.
Although this may sound like overkill, it's more elegant than Dwight's suggestion of backing up the image before every file-in.
Well, I was just illustrating a point -- backing up image and changes files before every filein is (normally) way overkill. But in the absence of any other mechanism I actually do this from time to time. I also keep a clean set of fully updated image and changes files tucked away, so I can just copy them to another directory, then filein and modify the working copy as much as I wish without worrying about it screwing up - I'm only about 10 seconds from restoring the image back to it's "original" state.
-- Dwight
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
Dick Karpinski -
Dwight Hughes -
Greg & Cindy Gritton -
Raab, Andreas -
Steve Wart