[Pharo-project] Optimize Pharo for slow horse
Hello, I am testing Pharo on XO OLPC computer. It is slow, yes, the machine are slow. But I am looking at place to make it more usable: - larger font size (at least 12pt) - screen depth to 16 bpp - no background, does it help? - browser, can we improve something? - polymorph theme, I have this unfinished sugar theme I would like to optimize for faster rendering Which tweaking can be applied to the image for a better user experience? Thanks to share any thought, even random ones. Hilaire
Le 12/07/2010 16:22, Hilaire Fernandes a écrit :
Hello,
I am testing Pharo on XO OLPC computer.
It is slow, yes, the machine are slow. But I am looking at place to make it more usable:
- larger font size (at least 12pt) you can load the full DejaVu strikefont package from squeaksource (CUIS fonts). It includes dejaVu of size 6,7,8,9,10,11,12,14,17 and 22.
http://www.squeaksource.com/DejaVu Alain
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Le 12/07/2010 16:55, Alain Plantec a écrit :
- larger font size (at least 12pt) you can load the full DejaVu strikefont package from squeaksource (CUIS fonts). It includes dejaVu of size 6,7,8,9,10,11,12,14,17 and 22.
Thanks for the tip. Can the freetype plugin be removed from the VM then? And then the freetype package from the image aswell ? I think pharo already use strike font for a few sizes, right? Hilaire
thanks for trying. did you try cuis to see a difference? I know that juan optimize scrollbars and others.
Hello,
I am testing Pharo on XO OLPC computer.
It is slow, yes, the machine are slow. But I am looking at place to make it more usable:
- larger font size (at least 12pt) - screen depth to 16 bpp - no background, does it help? - browser, can we improve something? - polymorph theme, I have this unfinished sugar theme I would like to optimize for faster rendering
Which tweaking can be applied to the image for a better user experience?
Thanks to share any thought, even random ones.
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 12 Jul 2010, Hilaire Fernandes wrote:
Hello,
I am testing Pharo on XO OLPC computer.
It is slow, yes, the machine are slow. But I am looking at place to make it more usable:
- larger font size (at least 12pt) - screen depth to 16 bpp - no background, does it help? - browser, can we improve something? - polymorph theme, I have this unfinished sugar theme I would like to optimize for faster rendering
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. :) Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont 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 those which are loaded when the image starts. You can also try using the new StackVM. And you can also run the following version of the browser test to see where can you improve the performance: | savedMorphs | savedMorphs := World submorphs. World removeAllMorphs."heh, heh" [ [ 10 timesRepeat: [ Browser fullOnClass: Object selector: #yourself ]. World submorphs do: [ :m | m delete. self currentWorld doOneCycle] ] ensure: [ World addAllMorphs: savedMorphs ] ] timeProfile. Levente
Thanks to share any thought, even random ones.
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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?
those which are loaded when the image starts. You can also try using the new StackVM.
Will do later. Thanks for your tips. Hilaire
2010/7/12 Hilaire Fernandes <hilaire.fernandes@gmail.com>
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.
Your friend is right: we still use IT of the 70s... But maybe he's still using those of the late 60s himself (you know,{}, no boolean, source files, include files, preprocessor directives, compiler flags,...) That's something I usually answer. Nicolas
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?
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Your friend is right: we still use IT of the 70s... But maybe he's still using those of the late 60s himself (you know,{}, no boolean, source files, include files, preprocessor directives, compiler flags,...) That's something I usually answer.
Nicolas
:) Even if it would be good to invent the next generation - secure - extremely modular/malleable (bootstrap and coevolution of the vm would be really cool) - high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining - customizable memory management - better mop 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 ;-) On 12 Jul 2010, at 15:53, Stéphane Ducasse wrote:
- high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 ;-)
On 12 Jul 2010, at 15:53, Stéphane Ducasse wrote:
- high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/12 Stéphane Ducasse <stephane.ducasse@inria.fr>
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
Oh, you mean following the steps of Strongtalk... Nicolas
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 ;-)
On 12 Jul 2010, at 15:53, Stéphane Ducasse wrote:
- high optimized (I would be curious to know if we could "seal"
some packages and in this case use a lot of inlining
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 12, 2010, at 11:16 PM, Nicolas Cellier wrote:
2010/7/12 Stéphane Ducasse <stephane.ducasse@inria.fr> 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
Oh, you mean following the steps of Strongtalk...
Yes getting advantage of strong typing without the inconvenient. You could have checkers that help us and still have a pure dynamically typed language. Some years ago a student did an experiment at bern on that. Stef
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 ;-)
On 12 Jul 2010, at 15:53, Stéphane Ducasse wrote:
- high optimized (I would be curious to know if we could "seal" some packages and in this case use a lot of inlining
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 12, 2010, at 10:45 PM, Stéphane Ducasse wrote:
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.
Hilarie: first question, do you want to make faster what? The development there or the deploy of a particular application? On Tue, Jul 13, 2010 at 9:15 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Jul 12, 2010, at 10:45 PM, Stéphane Ducasse wrote:
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:
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
On Tue, Jul 13, 2010 at 9:58 AM, Hilaire Fernandes < hilaire.fernandes@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#a228395... - 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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-int... 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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.html... 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You can use MVC, it works well on much slower computers... oh wait...
:) Levente it was a good one. :)
Sorry, I couldn't resist. :)
:) I know the feeling. Now we removed MVC from pharo not because we did not value it but because we want a clean infrastructure (where several UI system could be loaded) and this was not with a isMorphic code everywhere that we could move. So sometimes you have to take decision so that you can get again agile so that you can reconsider your own decision.
Try getting rid of gradients, dropshadows, etc. Use a plain old strikefont 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 those which are loaded when the image starts. You can also try using the new StackVM. And you can also run the following version of the browser test to see where can you improve the performance:
| savedMorphs | savedMorphs := World submorphs. World removeAllMorphs."heh, heh" [ [ 10 timesRepeat: [ Browser fullOnClass: Object selector: #yourself ]. World submorphs do: [ :m | m delete. self currentWorld doOneCycle] ] ensure: [ World addAllMorphs: savedMorphs ] ] timeProfile.
Levente
Thanks to share any thought, even random ones.
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Alain Plantec -
Hilaire Fernandes -
Johan Fabry -
Juan Vuletich -
Levente Uzonyi -
Marcus Denker -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse