Optimize Pharo for slow horse
Locked
12
12
 
|
CONTENTS DELETED
The author has deleted this message.
|
Re: Optimize Pharo for slow horse
|
In reply to this post by hilaire
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? 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.html#a2286605 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Optimize Pharo for slow horse
|
|
In reply to this post by Marcus Denker-4
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Optimize Pharo for slow horse
|
|
In reply to this post by hilaire
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Optimize Pharo for slow horse
|
|
In reply to this post by Stéphane Ducasse
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Optimize Pharo for slow horse
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
As far as I can see, he is in the formalizing (a subset of) Smalltalk phase. We must be patient, such formal stuff cannot be hurried ;-) On 12 Jul 2010, at 16:45, Stéphane Ducasse wrote: > I would love to hear more about oscar. I would love to know where the libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if there are some results. > > Stef > >> >> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >> >> So, we are working on it ;-) > -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Sorry, I did not invent the terminology, we'll just have to do with this ... On 12 Jul 2010, at 16:45, Stéphane Ducasse wrote: > instead of gradual typing I prefer the term pluggable types because it is really clear what it means. > > On Jul 12, 2010, at 10:03 PM, Johan Fabry wrote: > >> >> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >> >> So, we are working on it ;-) > -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Optimize Pharo for slow horse
|
|
yes what I imply is that we do not want to have the runtime semantics changed because of a type system.
Stef On Jul 13, 2010, at 5:05 PM, Johan Fabry wrote: > > Sorry, I did not invent the terminology, we'll just have to do with this ... > > On 12 Jul 2010, at 16:45, Stéphane Ducasse wrote: > >> instead of gradual typing I prefer the term pluggable types because it is really clear what it means. >> >> On Jul 12, 2010, at 10:03 PM, Johan Fabry wrote: >> >>> >>> Gradual typing could help there, doing optimisations where possible. Eric has a PhD student (Oscar) working on gradual typing, with Pharo as the test bed. Next semester there should start a second one with me (Esteban) that is going to look at the vm side of things: if type info is available, use it to optimise ... >>> >>> So, we are working on it ;-) >> > > -- > Johan Fabry > [hidden email] - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
CONTENTS DELETED
The author has deleted this message.
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |