May 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Squeak and Pharo speed differences

by Shaping

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 eg loop, block invocation, arithmetic, overheads are either minimised wrt the code being benchmarked or subtracted from the code being benchmarked. Okay. 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. Right. I donât see how to guarantee some known starting state except to collect all garbage. Shaping

May 19, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Eliot Miranda

Hi Shaping, > On May 16, 2020, at 4:33 AM, Shaping <shaping(a)uurda.org> 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)

May 18, 2020

[ANN] Smalltalkhub Readonly Migration tuesday 8hs - server maintenance / migration

by Guillermo Polito

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

May 18, 2020

Re: [Pharo-dev] [Vm-dev] Squeak and Pharo speed differences

by Ben Coman

On Sun, 17 May 2020 at 15:06, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > By the release of Pharo 7 the idle time was increased to 50 ms in order to > reduce the CPU usage on the cloud and reduce costs. If I remember correctly > Ben Coman did a PR that changes the way the delays are scheduled in order > to select the most appropriate time for sleeping, but since the PR was to > close to a Pharo release, it was decided to not be included for safeness > reasons. We should resurrect that change soon because the default latency > is really bad. > hi Ronie, The PR that comes to mind essentially did two things: 1. Moved the native-sleep from the Idle-thread to the DelayScheduler-thread 2. Added an Idle-flag set in the Idle-thread and reset when the DelayScheduler-thread wakes a delayed-thread. It was based on the following logic... 1. When the existing Idle-thread is running, its knows that there are no other runable threads and so should native-sleep. However there are probably some delays that expire soon, but the Idle-thread doesn't know when, so it native-sleeps for a fixed period - possibly sleeping past a delay expiry. 2. If the Idle-thread were to send messages to discover how long until the next delay-expiry, that could race with an actual delay-expiry firing the timingSemaphore to premptively wake the DelayScheduler-thread, which subsequently wakes the delayed-thread - and I couldn't reason through the combination of multithreaded line-by-line sequences. 3. It simplified things to ensure there is only ONE sequence to reason about... where the only thing the Idle-thread does is set an Idle-flag then immediately fire the timingSemaphore to invoke the DelayScheduler-thread. When that sees the Idle-flag it native-sleeps the appropriate time until the next delay expiry. Upon waking from that it immediately schedules the delayed-thread and resets the Idle-flag. It shouldn't be too hard to recreate, but it may be redundant. I'd need direction from those working on the IdleVM cheers -ben

May 18, 2020

Re: [Pharo-dev] [Mm10s] 2020-05-18

by tesonep＠gmail.com

### 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 <estebanlm(a)netc.eu> 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. tesonep(a)gmail.com

May 18, 2020

Re: [Pharo-dev] would it make sense to have ZnCharacterReadStream and other readstream reply to readstream

by Sven Van Caekenberghe

https://github.com/svenvc/zinc/commit/7a4b4bda502092186d03b467dc6baf9d1a76b… > On 13 May 2020, at 17:49, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <stephane.ducasse(a)inria.fr> 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 >> >

May 18, 2020

[Mm10s] 2020-05-18

by Esteban Lorenzano

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

May 18, 2020

pharo-contributions/pharo-unicode

by Sven Van Caekenberghe

Hi, I am not 100% sure how things are organised, but I would like access to pharo-contributions/pharo-unicode, so that I can commit directly. I see that Alistair did the initial commits (copying from history), but I can't see how he could have done that. I access granted at the pharo-contributions level, or below ? Thx, Sven

May 17, 2020

Red Alarm!

by Janko Korelc

Red Alarm! 2 days ago had found databaseCriticsBrowser.zip and installed several packages from the catalog. NeuralNetworks installed successfully for the first time. Several image saves later, was dissatisfied with something, and as noticed option to revert changes, tried it. Look, everything got uninstalled! WTF? Thought, then at least let's install NN again. Only to discover I can not. Today, I believe it got deleted for a strange reason. Try to recover and those dangerous variants shall be removed from the public. For the curious look in group Compiler at my comment in topic: What should we do with programmers who introduce errors in code. -- gee, gravitino, graviton exchange

May 17, 2020

Re: [Pharo-dev] Squeak and Pharo why the fork

by Jimmie Houchin

On 5/16/20 3:56 AM, Shaping wrote: > > Hi Jimmie. > > On 5/15/20 5:26 AM, Shaping wrote: > > I donât understand the split.Â It looks silly.Â Maybe someone can > explain the split in terms of technical/architectural advantages, > if any exist. > > [snip] > > The Pink plane community wanted to begin to clean up Squeak. Break it > up into parts which could be reloaded. It wanted a much more modular > environment which allowed you to build the image you want for the > purpose you intend. > > The Blue plane community didn't see any problems with the way it was. > They liked it and still do. It fit what they wanted to do with > Squeak/Smalltalk. Frequently more research oriented and less business > oriented. > > Applied basic research is most of what I do. Â I still want a clean, > modular environment.Â I donât see how that interferes with creative > verve.Â It should help if only by limiting confusion and clarifying > configurational choices. > The Squeak and Pharo communities are not unlimited in size and resources. When you have differing priorities and limited resources, you have to make choices. Choices you might not rather make. But you make them anyway. This is what happened. One group had their priorities and the other theirs. They each split and their respective communities and resources when the way of their priorities. Most of us did not want a split. But if one group constrains the other, there becomes no other option. > Then in the midst of all this you have overlap in individuals who > understand both. You also had personality differences and > disagreements which developed over years. Eventually the Pink plane > community forked and created Pharo. The foundational community of > Squeak (Blue plane) did not want to make the changes the Pink plane > community wanted or required. > > What are the specific changes that Squeak folks donât want to make? > > Squeak/Pharo is a configurable environment.Â We can still have a > quasi-OS world if we want that.Â What specific aspects of the analytic > and creative experience break or degrade for Squeak users with these > specific changes, and also cannot be preserved by loading the right > Smalltalk packages? > This is all true. And most of us do enjoy the quasi-OS world. We want that. We just don't want to deploy that with our application. Especially server-side apps who want to run well in a limited environment or an environment that costs per amount of memory, cpu time, etc. > Pharo is now 12 years or so into its journey. It is not easy losing > weight and still keep working. But that is the goal of Pharo. Keep > reducing until the entire system can be built up from a base image. > And when it gets there. We don't have a problem with from that > foundation, being able to build it back up into a Squeak-like image. > > I have numerous projects which I am doing in Pharo. One is a trading > application. I personally want as little in my image as possible which > does not have to do with my trading application. It desires to be as > fast as possible, run without failure, and as memory and cpu efficient > as I can make it to be in Pharo. I could make and run this application > in Squeak. But it would include much that I don't need and don't want. > And that is the case in Pharo currently as well. > > This points to needing more modularity, not less.Â We want to unload > all that we donât want, in small or big pieces, easily and > confidently, without breaking anything.Â It sounds easy, but itâs not. > I think this should be one of the Consortiumâs main goals. > It is one of the Consortium's goals. However, it take time from highly skilled, dedicated people. Again, resources are limited. In people, money and time. So the priorities are directed. We will get there. But we are not there yet. > But Pharo has its philosophy and its direction that it is moving > towards. At some point in time my trading application will what I want > it to be with very little unused code in the image. That might not be > until Pharo 10+. I don't know. But there is a vision within Pharo for > people to build such applications. > > Image minimization is a useful feature. Â Â A Squeak user would want > this too, at least when deploying. > Yes, but it is not their priority. They prioritize differently and within their limited resources. > > I have not used Squeak in years. And nothing I write here is meant to > speak badly about Squeak. I like the Squeak community. They are full > of great people. And I do not know how accurate what I write is to the > current Squeak. My apologies for any inaccuracies or errors. > > Pharo in general is much more pro-business. It is an explicit goal of > Pharo. > https://pharo.org/about > https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf > > Both websites give you a feel for who the community is and the > orientation of their goals. > > As much as re-unification would be nice. > > Logical and utilitarian. > > I don't know that it will happen. At a minimum, not until the Squeak > community could build Squeak from a Pharo kernel image. Then it would > be possible. But I don't think likely. > > What are the specific problems? Anyone? > Resources and the prioritization of them. Personalities within each community. Branding of each project. As I said. When Pharo reaches its goal of a kernel image and everything is built from there. The Squeak community would be more than able to build the next Squeak x.y from that. Whether of not that happens. Only time will tell. There could be easily someone from the Pharo communities build the everything is in there image. It would seem to be a great way to test. Now had Squeak 15+ years ago had a portion of the funding that Java got. And had Sun, Google, et al. not chosen Smalltalkers to build HotSpot and V8 etc, but rather deployed those people and resources to Squeak. We could be much further down the road. Squeak is open source. They could have done that. Or if any big corp who spends significant resources on languages and tools would get a vision for what Smalltalk/Pharo is and could be. But alas it hasn't happened. So we are each making progress slowly within the goals and the priorities each have. Jimmie

May 17, 2020