- Pharo-dev - lists.pharo.org

[Pharo-project] Cleaning morphic?

by Guillermo Polito

I know morphic is one of the greatest issues Squeak and Pharo have. And I'm tired of the kilometric morph hierarchies with tons of methods that noone uses, and the impossible traceability of the morphic code... And I'm sure that a lot of people tried it before... And this isn't the highest priority. But I think morphic cleansing should be done. So, while i'm now in bed beacause of a flu, hehe, I want at least remove unused morph classes and unused methods... Or maybe we can separate some things from the core. Of course I will be "spamming" in the list asking for the changes I will do :P. what do you think? Do I open a ticket? Guille

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

ok we are in sync. Stef On Jul 13, 2010, at 4:21 PM, Marcus Denker wrote: > > On Jul 13, 2010, at 3:56 PM, StÃ©phane Ducasse wrote: > >> Strange this is not what gilad mentioned. >> A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. >> > > Yes. > > Gradual Typing is *not* about multiple type systems. It's just *one* Type System. Which has the > nice property of dealing nicely with code in the case of having no type annotations. > > One can implement Gradual Typing without any Pluggable Types. Then it's the only type-system the > language has. Type-check would in this case not be optional. It would be always done, but without > annotations leading to no static checking done. But it could actually influence the language semantics > (e.g. one could imagine a language that compiles in dynamic checks following the gradual type > checker in the case of no annotation. Instead of a runtime that has the checks build in like smalltalk). > > In turn, one could provide a Type-System based on Gradual Typing *on top* of a Pluggable Types > infrastrustructure.This then would be a type-system that is optional, not influencing language semantics. > > So both are orthogonal. But of course related. (how to type-check dynamic systems without making them static). > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Marcus Denker

On Jul 13, 2010, at 3:56 PM, StÃ©phane Ducasse wrote: > Strange this is not what gilad mentioned. > A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. > Yes. Gradual Typing is *not* about multiple type systems. It's just *one* Type System. Which has the nice property of dealing nicely with code in the case of having no type annotations. One can implement Gradual Typing without any Pluggable Types. Then it's the only type-system the language has. Type-check would in this case not be optional. It would be always done, but without annotations leading to no static checking done. But it could actually influence the language semantics (e.g. one could imagine a language that compiles in dynamic checks following the gradual type checker in the case of no annotation. Instead of a runtime that has the checks build in like smalltalk). In turn, one could provide a Type-System based on Gradual Typing *on top* of a Pluggable Types infrastrustructure.This then would be a type-system that is optional, not influencing language semantics. So both are orthogonal. But of course related. (how to type-check dynamic systems without making them static). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

Hilaire if you remove monticello you can get a lot of space (lukas checked and in 1.2 (we have 3.5 mb just for duration) On Jul 13, 2010, at 9:58 AM, Hilaire Fernandes wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : >> Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? > > > I want first to improve the user experience under this 12 years old CPU power technology (XO-1): make UI more responsive is the first and only issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to configuration, see my other post. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

Strange this is not what gilad mentioned. A pluggable type system: you can plug multiples one and the runtime is not influenced by type systems. Stef >> instead of gradual typing I prefer the term pluggable types because it is really clear what it means. >> > Pluggable types is differnt to "gradual typing". > > Pluggable types: Infrastucture to plug any type system (with infrastructure to allow to infer > or or ignore non-annotated code). > > Gradual Types: One (kind of) Type System where type annotations are optional: > > http://ecee.colorado.edu/~siek/gradualtyping.html > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Levente Uzonyi

On Mon, 12 Jul 2010, Hilaire Fernandes wrote: > Le 12/07/2010 18:08, Levente Uzonyi a Ã©crit : > >>> Which tweaking can be applied to the image for a better user experience? >> >> You can use MVC, it works well on much slower computers... oh wait... >> >> Sorry, I couldn't resist. :) > > Your joke remind me a funny event occurring one year ago. I was chatting with > an old friend working in the bank sector in Geneva. He asked me what's up > today, I told him my interest in Smalltalk, he joked I was interested in > computer archeology. It looked funny to me as well. :) > > >> Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont > > Yes, the sugar theme is flat black and white. > > >> without anti-aliasing. If you can build a custom vm, make sure that you >> optimize it for the platform and build all modules external, except for > > > Yes, beside -Ox option are there any additional one you know about to be > effective? Yes, if your target is the XO-1, you can optimize your vm for the Geode LX. With gcc 4.3+ I'd try this first: -march=geode -mmmx -m3dnow -O3 -fomit-frame-pointer then some other architectures (march), like i486, i586, i686 or k6-2. If you are using an older compiler, you can still use i486, i585, i686 and k6-2. Since only the user experience matters, you can rely on the browser benchmark and pick the config with the best results. If two results are close, you can check tinybenchmarks and base your decision on that. Of course you can run macrobenchmarks if you have the time. According to this: http://forum.world.st/iPhone-Cog-Stack-VM-performance-numbers-td2286605.htm… you should definitely build a stack vm. Building a small vm (all modules external which are not loaded at startup) is better, because the vm itself uses less memory. This also means that the chance for a cache miss is lower (tinyBenchmarks shows a 10% improvement with this on my pc). (I didn't look at the code, but the Cog vm could also be used if you can replace the sse2 instructions with 3dnow.) Levente > >> those which are loaded when the image starts. You can also try using the >> new StackVM. > > Will do later. > > Thanks for your tips. > > Hilaire > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Hi Julian, Thanks for your tips. Several people (Stef, Mariano, Marcus) already told me how good you did with Cuis to produce a small, coherent and effective Smalltalk, all these activities around Smalltalk are both exciting and a source of motivation to show out there how nice Smalltalk can be for developers and users. Right now, my hands are full with DrGeo refactoring, VM compilation to produce a VM for XO-1 (done now) and now configuring an image itself to be a nice host for the full, new bleeding DrGeo UI, polymorph based[1]. Serge also wants to have a lean Pharo on XO to port and to develop educational applications. We agree to share the workload: I am finishing the Sugar Polymorph theme (an important part to get a faster UI, on top of a coherent UI with the rest of the XO Sugar environment) and Serge will looks at the image configuration and optimization. Your help will be very welcome. Hilaire [1] http://blog.ofset.org/hilaire/index.php?post/2010/06/07/DrGeoII-new-user-in… Le 13/07/2010 12:28, Juan Vuletich a Ã©crit : > I suggest testing Cuis. In Cuis do 'Preferences veryBigFonts' and you > get a quite usable system on the XO. Then, use the profiler, to see > where Pharo spends time and Cuis doesn't. That's are the parts you need > to understand and optimize. And you can take code from Cuis to make it > faster (it is all MIT). BTW, anti aliased fonts are ok if StrikeFonts > (i.e. the Cuis DejaVu fonts), and most likely, using 16bpp Display > instead of 32 doesn't make much difference. > > Cheers, > Juan Vuletich

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Juan Vuletich

Hilaire Fernandes wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : >> Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? > > > I want first to improve the user experience under this 12 years old > CPU power technology (XO-1): make UI more responsive is the first and > only issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to > configuration, see my other post. > Hi Hilaire, I suggest testing Cuis. In Cuis do 'Preferences veryBigFonts' and you get a quite usable system on the XO. Then, use the profiler, to see where Pharo spends time and Cuis doesn't. That's are the parts you need to understand and optimize. And you can take code from Cuis to make it faster (it is all MIT). BTW, anti aliased fonts are ok if StrikeFonts (i.e. the Cuis DejaVu fonts), and most likely, using 16bpp Display instead of 32 doesn't make much difference. Cheers, Juan Vuletich

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Mariano Martinez Peck

On Tue, Jul 13, 2010 at 9:58 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : > > Hilarie: first question, do you want to make faster what? The >> development there or the deploy of a particular application? >> > > > I want first to improve the user experience under this 12 years old CPU > power technology (XO-1): make UI more responsive is the first and only > issue. > > I am compiling tips and suggestion on DrGeo Todo list: > http://community.ofset.org/index.php/DrGeo_Todo > > > Next of course the deployment is another aspect related to configuration, > see my other post. > > Ok ok ok. What I would to is to: - Start from PharoCore, of course. Not dev. Take a core and load what you need. To script such loads, you can use Gofer. If you want to use Metacello, you can take your conf and load it. It will bootstrap metacello, and then, once you have installed it, with ConfigurationOfMetacello >> unload you con can remove Metacello from the system. - Do some cleaning to the image. Check the stuff done in ScriptLoader >> cleanUpForProduction. There are a lot of interesting things there - Use standard fonts and as they said, without antialaising - For the VM you can also compile a minimal VM. I did that with MacOS where I compiled only the 4 or 5 plugins that were needed. I am not sure if you win something, thus. - Check and try this email: http://forum.world.st/Are-random-refactorings-welcome-td2283957.html#a22839… - Of course, try Cog. - I would use the SystemBrowser that comes with the Core. Not OB neither O2. - Enable fastDragWindowForMorphic - Don't use annotation panes. CHeck also issues 2403 - Use Pharo 1.1 that is much faster than 1.0 That's all that came to my mind. Not sure what could help. Good luck and let us know. Cheers Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Hilaire Fernandes

Le 13/07/2010 09:42, Mariano Martinez Peck a Ã©crit : > Hilarie: first question, do you want to make faster what? The > development there or the deploy of a particular application? I want first to improve the user experience under this 12 years old CPU power technology (XO-1): make UI more responsive is the first and only issue. I am compiling tips and suggestion on DrGeo Todo list: http://community.ofset.org/index.php/DrGeo_Todo Next of course the deployment is another aspect related to configuration, see my other post.

July 13, 2010