Re: [Pharo-dev] Squeak and Pharo speed differences
Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that. Given that both Pharo and Squeak useorphic and hence nothing have the same tender-in-step architecture isn’t the fact that they show the sane performance issue evidence that points to precisely this being the cause? Yes, but not architecture, by which I think you mean the pushing of events versus the fixed-frequency regular loop in Morphic. I would expect a big variation in the Morphic case, but I don’t know what the fixed frequency is; it could well under the noise floor. My first thought would be that getting the damage rects is the problem, but I’ve not seen the code. How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits? My understanding is that damage rectangles are retrieved, Right, but this is the potentially slow part—the retrieving or perhaps more specifically mapping a point to a rectangle containing a contiguous sequence of non-whitespace character (a word). combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles. You can read the gods for yourself. It’ll be a while. …. I just tried some new experiments. I should have thought of these earlier. Character insertion and cursoring in any direction by one character have the same latency. Collecting the damage rectangle at the cursor position and around the selected word are both taking about the same time as far as I can tell with my eye, and this time is longer than in VW or any Windows app. But VW doesn’t use the Windows message queue directly. All incoming Windows events are converted to Smalltalk equivalents and are queued on the Smalltalk side. And it works well. Why not mimic that pattern to get the extra speed? Does something in Squeak/Pharo architecture prevent us from doing that? How do we set a multi-process time profiler running so that we don’t need to eval blocks to get tallies. I just want to use the editor and watch method hit distribution. I see the Time profiler window; it seems to need a code snippet to work. How is the JIT code cache cleared? Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. Okay. Can’t remember how it’s done in VW. CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod flushCachedVMCode] Baseline state: the only thing that comes to mind here is Collect All Garbage. There’s also Smalltalk garbageCollectMost which just runs a scavenge. IIRC someInstance has a side effect of running a scavenge in VW. Okay. and then ensure, through the relevant introspection primitives, What are these? What state features am I introspecting after the test? Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm parameterAt: and senders. Okay. I see this list: parameterAt: parameterIndex "parameterIndex is a positive integer corresponding to one of the VM's internal parameter/metric registers. Answer with the current value of that register. Fail if parameterIndex has no corresponding register. VM parameters are numbered as follows: 1 end (v3)/size(Spur) of old-space (0-based, read-only) 2 end (v3)/size(Spur) of young/new-space (read-only) 3 end (v3)/size(Spur) of heap (read-only) 4 nil (was allocationCount (read-only)) 5 nil (was allocations between GCs (read-write) 6 survivor count tenuring threshold (read-write) 7 full GCs since startup (read-only) 8 total milliseconds in full GCs since startup (read-only) 9 incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 10 total milliseconds in incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 11 tenures of surving objects since startup (read-only) 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use 20 utc microseconds at VM start-up (actually at time initialization, which precedes image load). 21 root table size (read-only) 22 root table overflows since
Re: [Pharo-dev] Squeak and Pharo speed differences
Hi Shaping, > On May 18, 2020, at 6:52 PM, Shaping wrote: > > > 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms > latency (eye-balled, estimated) between end of double click (button up on > second click) and time of highlighting of selected text. It could be as low > as 60 ms, but I doubt it, and that’s still too long. I can’t track the > latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my > noise floor. Notepad latencies are even lower. The difference between VW > and Notepad is not enough to complain about. Neither is noticeable in > passing. The difference between VW and Pharo/Squeak latencies is a little > painful/distracting. It’s very much in your face, and you are keenly aware > that you are waiting for something to happen before you can resume your > thoughts about the code. > > 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies > between the step-click event and selection of the next evaluable is a solid > 100 ms (again estimated). Feels more like 150-175 ms much of the time. This > is actually hard to work with. > > Neither of these unequivocally demonstrates VM performance. > > I know. This comment is not about the VM. VM performance is another issue. > This comment is only about general usability as a function of the latencies, > whatever the cause. > > Both are more likely to derive from overall GUI architecture. > > Yup. > > In particular, VW’s display architecture is a direct stimulus-response i/o > model where input results in a transformation producing immediate rendering, > whereas Morphic is an animation architecture where input results in a new > state but no rendering. The Morphic GUI is rendered separately on every > “step” of the system. > > Okay. > > Hence graphics output necessarily lags input on Morphic. So these speed > differences have nothing to do with vm performance and everything to do with > GUI architecture. > > Both Squeak and Pharo show the same delay for text selection latency. The > architecture difference is not likely causing that. Given that both Pharo and Squeak useorphic and hence nothing have the same tender-in-step architecture isn’t the fact that they show the sane performance issue evidence that points to precisely this being the cause? > How do we index or look up the word rectangle to render? I’m think that is > more likely the cause. Is a map created at method compile time and updated > after text is moved during edits? My understanding is that damage rectangles are retrieved, combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles. You can read the gods for yourself. > Where is VisualWorks significantly faster than either Squeak or Pharo? > > VW 8.3.2 faster: > > 1. Text selection. > > 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). > Pharo’s repeat-key rate is the same or a little slower, there are more > pauses, and distribution of those pause-times is slightly wider for Pharo 9, > as if event flow isn’t as smooth as it could be (because text/cursor > rendering is a not efficient?). This is a minor issue, not a practical > problem. I did the test in a workspace in both cases. > > > Pharo 9 same or faster: > > Everything else in the GUI, like window openings/closings, menu > openings/closings work at nearly the same speed, or Pharo 9 is faster. > > Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. > If you scrutinize, you can see that Pharo system browser open times are often > about 2/3 to 4/5 of the VW times. This action is never faster in VW. > > Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. > Instant--delightful. > > > Specifically which VisualWorks VM or lower level facilities are much faster > than the Cog VM? Do you have benchmarks? > > No, I don’t, but I find the subject interesting, and would like to pursue it. > I’m trying to get some pressing work done in VW (as I contemplate jumping > ship to Pharo/Squeak). It’s not a good time for excursions, but here I am > playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. > > Do you have a specific procedure you like to use when benchmarking the VW VM? > > Any VM. Express the benchmark as a block. If the benchmark is not trying to > measure JIT and/or GC overhead then before the block is run make sure to put > the vm in some initialized state wrt hitting and/or GC, eg by voiding the JIT > code cache, > > How is the JIT code cache cleared? Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. Can’t remember how it’s done in VW. > and/or forcing a scavenge or a global GC. Then run the block twice, > reporting it’s second iteration, to ensure all code is JITted. > > Okay, so the above
Re: [Pharo-dev] Squeak and Pharo speed differences
1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and that’s still too long. I can’t track the latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. It’s very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Neither of these unequivocally demonstrates VM performance. I know. This comment is not about the VM. VM performance is another issue. This comment is only about general usability as a function of the latencies, whatever the cause. Both are more likely to derive from overall GUI architecture. Yup. In particular, VW’s display architecture is a direct stimulus-response i/o model where input results in a transformation producing immediate rendering, whereas Morphic is an animation architecture where input results in a new state but no rendering. The Morphic GUI is rendered separately on every “step” of the system. Okay. Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that. How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits? Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharo’s repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isn’t as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I don’t, but I find the subject interesting, and would like to pursue it. I’m trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). It’s not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Any VM. Express the benchmark as a block. If the benchmark is not trying to measure JIT and/or GC overhead then before the block is run make sure to put the vm in some initialized state wrt hitting and/or GC, eg by voiding the JIT code cache, How is the JIT code cache cleared? and/or forcing a scavenge or a global GC. Then run the block twice, reporting it’s second iteration, to ensure all code is JITted. Okay, so the above procedure tests execution-engine efficiency apart from JIT and GC efficiency. If attempting to measure JIT and/or GC overhead then do the same wet getting the vm to some baseline consistent initial state Baseline state: the only thing that comes to mind here is Collect All Garbage. and then ensure, through the relevant introspection primitives, What are these? What state features am I introspecting after the test? Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. that after the benchmark has run the events desired to be benchmarked have actually taken place. I’m thinking most checks on state will involve running more Smalltalk, not just primitives. If a micobenchmark then ensure that
Re: [Pharo-dev] Squeak and Pharo speed differences
Hi Shaping, > On May 16, 2020, at 4:33 AM, Shaping wrote: > > > Hi Eliot. > > > Generally, comparing VisualWorks to either Squeak or Pharo or both, what are > the most pressing speed problems? > > 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms > latency (eye-balled, estimated) between end of double click (button up on > second click) and time of highlighting of selected text. It could be as low > as 60 ms, but I doubt it, and that’s still too long. I can’t track the > latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my > noise floor. Notepad latencies are even lower. The difference between VW > and Notepad is not enough to complain about. Neither is noticeable in > passing. The difference between VW and Pharo/Squeak latencies is a little > painful/distracting. It’s very much in your face, and you are keenly aware > that you are waiting for something to happen before you can resume your > thoughts about the code. > > 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies > between the step-click event and selection of the next evaluable is a solid > 100 ms (again estimated). Feels more like 150-175 ms much of the time. This > is actually hard to work with. Neither of these unequivocally demonstrates VM performance. Both are more likely to derive from overall GUI architecture. N particular, VW’s display architecture is a direct stimulus-response i/o model where input results in a transformation producing immediate rendering, whereas Morphic is an animation architecture where input results in a new state but no rendering. The Morphic GUI is rendered separately on every “step” of the system. Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. > > Where is VisualWorks significantly faster than either Squeak or Pharo? > > VW 8.3.2 faster: > > 1. Text selection. > > 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). > Pharos repeat-key rate is the same or a little slower, there are more pauses, > and distribution of those pause-times is slightly wider for Pharo 9, as if > event flow isn’t as smooth as it could be (because text/cursor rendering is a > not efficient?). This is a minor issue, not a practical problem. I did the > test in a workspace in both cases. > > > Pharo 9 same or faster: > > Everything else in the GUI, like window openings/closings, menu > openings/closings work at nearly the same speed, or Pharo 9 is faster. > > Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. > If you scrutinize, you can see that Pharo system browser open times are often > about 2/3 to 4/5 of the VW times. This action is never faster in VW. > > Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. > Instant--delightful. > > > Specifically which VisualWorks VM or lower level facilities are much faster > than the Cog VM? Do you have benchmarks? > > No, I don’t, but I find subject interesting, and would like to pursue it. > I’m trying to get some pressing work done in VW (as I contemplate jumping > ship to Pharo/Squeak). It’s not a good time for excursions, but here I am > playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. > > Do you have a specific procedure you like to use when benchmarking the VW VM? Any VM. Express the benchmark as a block. If the benchmark is not trying to measure JIT and/or GC overhead then before the block is run make sure to put the vm in some initialized state wrt hitting and/or GC, eg by voiding the JIT code cache, and/or forcing a scavenge or a global GC. Then run the block twice, reporting it’s second iteration, to ensure all code is JITted. If attempting to measure JIT and/or GC overhead then do the same wet getting the vm to some baseline consistent initial state and then ensure, through the relevant introspection primitives, that after the benchmark has run the events desired to be benchmarked have actually taken place. If a micobenchmark then ensure that eg loop, block invocation, arithmetic, overheads are either minimised wrt the code being benchmarked or subtracted from the code being benchmarked. i.e. make sure the benchmark is repeatable (benchmark an initial used state). make sure the benchmark measures what is intended to be benchmarked and not some overhead. > > > Shaping Cheers, Eliot, _,,,^..^,,,_ (phone)
[Pharo-dev] [ANN] Smalltalkhub Readonly Migration tuesday 8hs - server maintenance / migration
Hi all, We wanted to announce that, as announced previously, Smalltalkhub is going read only from tomorrow, 8h central Europe time. This means the service could be down for a couple of hours until the sync of data is done. Keep tuned, Guille and Christophe in behalf of the RMoD team
Re: [Pharo-dev] [Mm10s] 2020-05-18
### Last week: - Large Images Updating Baseline - Pharo Sync Meeting - LiveTyping in Pharo: Recovering the build, fixing some problems - JIT Documentation / Test - Benchmarks with the Lowcode variant - Meeting with Esteban - Activate setting to run build in Sista w/FullBlockClosures - Implementing the Decompiler for FullBlockClosures - Fixing RecompileAll / recompile: with traits (it looks like it was never working), discovered thank to the tests - and activating FullBlockClosures - Working in PICs with Guille & Stef - Idle VM stabilization ### This week (starting 2020-05-18): - Missing parts in the Image to have Sista + FullBlockClosure - Running multiple testing images - Propagating changes in many images - [VM] Configuring Defaults from the build process. - Pharo Bootstrap in 64 bits - Large Images: Checking Remaining issues - Reviewing PR & Issues On Mon, May 18, 2020 at 10:00 AM Esteban Lorenzano wrote: > > Short list today ;) > > ### Last week: > >* [NewTools-Playground] polishing details and get it ready to test > internally (which now is the case :P) >* Documenting transmissions sub-framework. >* Spent a lot of time preparing integration of Spec2 0.6 into P9. > > ### This week (starting 2020-05-18): > > - Finish 0.6 merge. > - Start working with NewTools-Inspector > - verify some errors in UFFI > - Gtk backend: verify some problems with low-level events > -- Pablo Tesone. teso...@gmail.com
Re: [Pharo-dev] would it make sense to have ZnCharacterReadStream and other readstream reply to readstream
https://github.com/svenvc/zinc/commit/7a4b4bda502092186d03b467dc6baf9d1a76baed > On 13 May 2020, at 17:49, Sven Van Caekenberghe wrote: > > Yes, I know the pattern and yes it would make sense. I will study this a bit. > >> On 13 May 2020, at 17:21, Stéphane Ducasse wrote: >> >> Hi sven >> >> I like the pattern >> >> >> on: aStringOrStream >> >> | stream | >> stream := aStringOrStream readStream >> >> but I cannot apply with Zn because ZnCharacterReadStream and friends do not >> answer readstream >> >> What is your point of view on it. >> >> >> S. >> >> Stéphane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >
[Pharo-dev] [Mm10s] 2020-05-18
Short list today ;) ### Last week: * [NewTools-Playground] polishing details and get it ready to test internally (which now is the case :P) * Documenting transmissions sub-framework. * Spent a lot of time preparing integration of Spec2 0.6 into P9. ### This week (starting 2020-05-18): - Finish 0.6 merge. - Start working with NewTools-Inspector - verify some errors in UFFI - Gtk backend: verify some problems with low-level events
