- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Making some progress, and a few observations

by Mariano Martinez Peck

I think it has no sense to test with several images. Look adrian comment "This basically measures how many bytecodes and messages the VM can execute per second." So, I guess it is a benchmark for VM + hardware. I don't think the image can influence much here. Am I correct? best, Mariano On Thu, Jul 16, 2009 at 1:38 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Here are my numbers. > Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) > OS: Windows XP SP3 > > Seaside 2.8.3 One Click Image: > '157248157 bytecodes/sec; 4708854 sends/sec' > > Seaside 2.8.4 One Click Image: > '158907510 bytecodes/sec; 4592283 sends/sec' > > pharo0.1-10373web09.07.2: > '156479217 bytecodes/sec; 4413998 sends/sec' > > > Regards, > > Esteban A. Maringolo > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Esteban A. Maringolo

Here are my numbers. Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) OS: Windows XP SP3 Seaside 2.8.3 One Click Image: '157248157 bytecodes/sec; 4708854 sends/sec' Seaside 2.8.4 One Click Image: '158907510 bytecodes/sec; 4592283 sends/sec' pharo0.1-10373web09.07.2: '156479217 bytecodes/sec; 4413998 sends/sec' Regards, Esteban A. Maringolo

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Schwab,Wilhelm K

It would be one good idea among many in a very well engineered system. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Thursday, July 16, 2009 9:07 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? Indeed, that sounds like a good solution. 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > My recollection is that most of Dolphin's startup is forced to happen lazily as part of startup, allowing an image to both continue and start from the saved state. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Lukas Renggli > Sent: Thursday, July 16, 2009 8:27 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > >>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. > > It is correct that these scripts are run after a snapshot, because when the image is saved it has to be shutdown so that it can come up correctly again. I guess Dolphin works exactly the same. The problem in Pharo/Squeak is that some of shutdown and startup scripts might not really be necessary to run in the case of a save without quit, so feel free to submit optimizations in this area. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:44 PM, Esteban Lorenzano wrote: > I use them a lot... just because "select:thenCollect:" looks clearer > to > me than "(select:)collect:", and I can indent the code in a more > fashion way to me. > Of course, if you choose remove it, I can change my code without any > problem (it is not so hard, after all :) ), but I just wanted to point > that optimization is not always the reason because a protocol can be > added... some times, is gramatics too. indeed but then it would be good to have it efficient also > > Cheers, > Esteban > > On 2009-07-16 07:02:56 -0300, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> said: > >> I'd favor removing such methods. The allocation optimization can be >> >> implemented better whenever it's needed, and IME it doesn't happen >> that >> >> often. >> >> StÃ©phane Ducasse wrote: >>> so in that case I would be in favor to remove them because this >>> does not help and just bloat the image. >>> >>> >>> >>> On Jul 16, 2009, at 8:21 AM, Lukas Renggli wrote: >>> >>> >> >>>>> select: selectBlock thenCollect: collectBlock >>>>> >>>>> | newCollection | >>>>> newCollection := self species new. >>>>> self do: [:each | (selectBlock value: each) ifTrue: >> >>>>> [newCollection add: >>>>> (collectBlock value: each)]]. >>>>> ^newCollection >>>>> >> >>>> That code would also break Dictionary and Array. >>>> >>>> I think the methods #select:thenCollect: and #collect:thenSelect: >>>> should be removed: >>>> >>>> - This is a low level optimization that the compiler (or JIT) >>>> should >>>> optimize, not the developer. >>>> - 'a select: b thenCollect: c' is longer to write than '(a >>>> select: b) >>>> collect: c'. Furthermore it is not that obvious what it does. I >>>> have >>>> seen several people being confused about it. >>>> - This is just #select:thenCollect:, what about >>>> #reject:thenCollect:select:thenInjectInto:? What about all >>>> subclasses >>>> that require a new implementation (Array, Dictionary, ...) of such >>>> methods. >>>> >>>> If people really want to be able to combine enumerator methods for >>>> higher efficiently the Collection hierarchy should be fixed. Having >>>> external iterator objects like in C++ and Java is not that bad >>>> after >>>> all: >>>> >>>> result := aCollection iterator >>>> select: [ :e | ... ]; >>>> collect: [ :e | ... ]; >>>> contents >>>> >>>> The accessors #select:, #reject:, #collect: ... on the iterator >>>> object >>>> would just iteratively create a new iteration block that is lazily >>>> executed when the result is accessed with #contents, #size or #do:. >>>> >>>> Cheers, >>>> Lukas >>>> >>>> -- >> >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> . > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:16 PM, Paolo Bonzini wrote: > On 07/16/2009 11:38 AM, StÃ©phane Ducasse wrote: >> Paolo >> >> why Iterable as a superclass of stream and collection? >> Why not a trait? >> Then I'm wondering why this would be faster. > > Maybe for just "(a select: ...) collect: b" it would not be faster. > > However, the important thing is to provide: > > 1) a new abstraction. Providing more polymorphism between Collections > and Streams can only do good, especially when the semantics are 100% > identical as for #detect: or #fold: (based on #do:). In GNU > Smalltalk I > did a bit more by providing also #readStream and #nextPutAllOn:, but > that's not necessary so I kept my pharo proposal minimal. > > 2) a new bag of tools. Lazy filtering has been proposed in many > different ways, so it *is* useful. Adding Iterable is in my opinion > the > best way to provide this tool in a way that fits the simplicity of the > standard Smalltalk class library (this is a way to say that > #doesNotUnderstand: tricks have their place, but other ways should be > explored as well). sure but for me my point was collect:thenSelect: looks badly implemented. Now you can that composed Stream. Damien has that in Nile since two years too. > > Paolo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:09 PM, Paolo Bonzini wrote: > On 07/16/2009 12:04 PM, Lukas Renggli wrote: >> I believe, that in >> this case*not* using traits forces you to do the right thing: >> delegate to another object that knows how to iterate over your >> object. > > Agreed. Adding a #do: method to a class can often be the right thing, > but I still have to see one case when a non-Collection, non-Stream > class > would have advantages from a public #inject:into: or #fold: or > #detect: > method. A sidenote -- things that do not count: In the moose environemnt we have group and they cannot inherit from Iterable. > 1) #select:/#reject:/#collect:, because those would be abstract in > Iterable anyway. > > 2) using the above methods from within the class itself, because > 99.99% > of the cases you will have an underlying collection or stream and you > can access that underlying object without violating information > hiding. yes so what? How this stream based iomplementation goes faster that the default collection one? > >>>>>> Is this going >>>>>> to be ANSI? >>>> >>>> DNU? why ANSI has to be in the story? >> >> Paolo is in the ANSI committee, I though. Maybe that will be added? > > There is no ANSI committee, that required to pay money and was not > considered viable. > > There is a mailing list (run by Bruce Badger) and a protocol (hosted > at > the GNU Smalltalk site, see the "STEPs" link in the home page) to > submit > proposals for extensions to Smalltalk, hopefully so that they can be > implemented cross vendor. But it has been dormient for too long. :-( > > Paolo > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 12:04 PM, Lukas Renggli wrote: >>> Having an iterator class also avoids having to implement all these >>> iteration methods over and over again, e.g. in visitors. >> >> lukas do you have an example because I do not see why >> Also with traits you just have to implement do: and you get all the >> other one for free. > > The class and metaclass system of Smalltalk is already at the limit of > complexity that I can handle. Traits make this existing model even > more complicated. Even with support from a trait aware browser I find > traits extermely hard to use. To me the most important thing is that > at all points in time I know exactly what changes when I compile a > method. This is absolutely not clear when using traits. I find your statements a bit rude. > > So far I haven't seen a single example where traits would really help. Really! I'm writing a trait to get magritte-aware xml output without having to always inherit from a top class or to copy and paste all the time the same code in my classes. > As Paolo suggested the problem can be simply solved by introducing an > Iterable superclass to Collection and Stream. I do not see how his solution will offer a faster implementation > Now you might say that this only works if I am not inheriting from > some other important class. True, an Iterable-trait would avoid that > problem. However, adding such a trait to an existing hierarchy looks > extremely scary to me. It potentially pollutes an existing protocol > with existing code that is most likely unrelated (or maybe it already > contains some iterator code for something else). like what collect: select: do: reject: inject:into: ? I think that you should also have a look at what other people are doing. > I believe, that in > this case *not* using traits forces you to do the right thing: > delegate to another object that knows how to iterate over your object. > >>> Is this going >>> to be ANSI? >> >> DNU? why ANSI has to be in the story? > > Paolo is in the ANSI committee, I though. Maybe that will be added? ANSI is dead. It was a bunch of specification pushed apart because smalltalk was hot and vendors wanted or not a feature in.

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Lukas Renggli

Indeed, that sounds like a good solution. 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > My recollection is that most of Dolphin's startup is forced to happen lazily as part of startup, allowing an image to both continue and start from the saved state. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli > Sent: Thursday, July 16, 2009 8:27 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > >>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. > > It is correct that these scripts are run after a snapshot, because when the image is saved it has to be shutdown so that it can come up correctly again. I guess Dolphin works exactly the same. The problem in Pharo/Squeak is that some of shutdown and startup scripts might not really be necessary to run in the case of a save without quit, so feel free to submit optimizations in this area. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Mariano Martinez Peck

Pentium 4 2.26 GZ, windows XP SP3, 2GB RAM 168199737 bytecodes/sec; 3670275 sends/sec 2009/7/16 Benoit St-Jean <bstjean(a)yahoo.com> > If that helps... > > 0 tinyBenchmarks > > Windows XP, 2002, SP3 > Pentium 4, dual core, 3Ghz, 2 Gb RAM > > All tests were run 5 times and here are the averages : > > Some comparisons: > > Squeak 3.9 latest update: #7067 > 76297334 bytecodes/sec; 3397437 sends/sec > > Squeak 3.10.2 latest update: #7179 > 74839234 bytecodes/sec; 3443964 sends/sec > > Pharo 0.1 latest update: #10377 > 75877223 bytecodes/sec; 3134820 sends/sec > > > > > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > Blog: lamneth.wordpress.com > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ------------------------------ > *From:* Gary Chambers <gazzaguru2(a)btinternet.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Thursday, July 16, 2009 6:51:59 AM > > *Subject:* Re: [Pharo-project] Making some progress, and a few > observations > > In the Windows camp, Watery2 theme... > > Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), > Pharo0.1Core-10371. > > 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 373 > > Older laptop, XP, 1GB, Pentium M (1.73 GHz)... > > 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 677 > > Still feels quite responsive even on that! > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> > Sent: Thursday, July 16, 2009 2:07 AM > Subject: Re: [Pharo-project] Making some progress, and a few observations > > > On my crusty old Linux box: > > 155339805 bytecodes/sec; 3931964 sends/sec > > However, I always like to test on less than my customers will have, so by > some arguments, this machine is just about right. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain Plantec > [alain.plantec(a)free.fr] > Sent: Wednesday, July 15, 2009 6:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Making some progress, and a few observations > > Adrian Lienhard a Ã©crit : > > Bill, > > > > Could you post the results of the following benchmark? > > > > 0 tinyBenchmarks > > > > > On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: > > > > '543236074 bytecodes/sec; 12101592 sends/sec' > > > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit > pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' > pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' > > not so bad with linux :) > > Cheers > Alain > > > Cheers, > > Adrian > > > > On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: > > > > > >> Stef, > >> > >> No browser should be that slow. I suspect the Linux vm is not a > >> speed demon, the xp machines I use are heavily burdened by anit- > >> virus software and other performance drains, etc. My linux box at > >> home might be further hindered by the fact that I bought a wide > >> screen monitor for it, and use LOTS of screen real estate. Still, > >> when I compare Pharo with other software (including Dolphin) under > >> similarly abusive conditions, Pharo is not quick. > >> > >> This particular image is small; it is based on the most recent web > >> image, and is 22 MB. It has some of my Seaside code in it, but has > >> not yet executed same. I have a couple of Seaside cleanup > >> expressions that help when images bloat up, but looking at the > >> current size makes me think I'm missing an opportunity. All that > >> aside, on my linux box, I find that after the saving cursor > >> disappears, it can take a few seconds for the image to again become > >> responsive. On xp in my office, there is at least a second of down > >> time after the cursor reverts to normal. > >> > >> In doing some SIF imports, I noted that it was hard to tell when the > >> image was still busy. I have no idea how long it should take to do > >> the work it was doing, but it took long enough that some gentle > >> prodding becomes irresistable: "is it done yet?" I remember lots of > >> debate about Cursor class>>showWhile: on Dolphin; it might be one of > >> those things that is tricky to get right. > >> > >> A little bit nicer news: I have it running on my office machine > >> (xp), with FreeType in use, and it's ok with the standard tools and > >> the w2k theme. > >> > >> Bill > >> > >> > >> > >> -----Original Message----- > >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >> ] On Behalf Of StÃ©phane Ducasse > >> Sent: Wednesday, July 15, 2009 2:31 PM > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] Making some progress, and a few > >> observations > >> > >> > >>> Stef, > >>> > >>> In terms of response times, even with a lot of things turned off, I > >>> was still surprised at how long it takes to change from even one > >>> method to another. > >>> > >> which browser are you using. > >> Because the old browser should not be that slow. > >> > >> > >> > >>> Anything past 0.2 sec (or whatever that threshold is) starts to add > >>> up; Pharo sometimes takes up to a second, which is _really_ shows up. > >>> > >>> Saving an image is not necessarily quick either, I _think_ > >>> particuarly > >>> on Linux?? > >>> > >> What is the size of your image: here jannik generated an image of > >> 800 mb. > >> > >> > >>> Also, I get the sense the wait cursors are displayed, on Linux, for a > >>> smaller fraction of the down time than on Windows. > >>> > >>> Bill > >>> > >>> > >>> -----Original Message----- > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >>> ] On Behalf Of StÃ©phane Ducasse > >>> Sent: Wednesday, July 15, 2009 12:58 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-project] Making some progress, and a few > >>> observations > >>> > >>> > >>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: > >>> > >>> > >>>> Hello all, > >>>> > >>>> I managed to create an install script; as I suspected would be case, > >>>> it was very anticlimactic. I tried creating a password-protected > >>>> directory under my personal web site, but that did not go well. The > >>>> authentication is weird, so it was probably asking a lot. A > >>>> directory repository worked. > >>>> > >>> Good to know > >>> > >>>> Does Monticello/PackageInfo see a change in method category (aka > >>>> package) as a change to the package? > >>>> > >>> normally it should. > >>> > >>> > >>>> It appears not, and it worries me a little in that it seems to make > >>>> it easy to lose work by forgetting to save it. Do any of you script > >>>> saving your packages? > >>>> > >>> you can check in ScriptLoader to see how we compute the packages that > >>> changed (not only dirty but also new packages) > >>> > >>> > >>>> The results are untested at present, but I used SIF to transfer a > >>>> fair amount of code into Pharo. To cope with the naming of the ODBC > >>>> classes, I ended up doing things like Smalltalk at:#DBConnection > >>>> put:ODBCConnection, and that worked out nicely, at least AFAICT at > >>>> this stage. SIF finally ended up complaining about running out of > >>>> items when processing the last file. I reserve the right to later > >>>> report that it was a miserable failure, but it looks like I most of > >>>> the code imported. > >>>> > >>>> Using the standard tools, the w2k theme, disabling faded backgrounds > >>>> and enabling fast drag, performance on an older Linux system is ok > >>>> (more or less). There are still things that take too long, > >>>> > >>> like what? > >>> > >>> > >>>> and Pharo's responses are no better (sometimes worse) than even > >>>> software running over a remote desktop connection. We need a speed > >>>> boost, but judicious settings help a little. > >>>> > >>>> Is there a way to disable the anti-aliased fonts? In fairness, I > >>>> should try turning that off to see if any speed boost is worth the > >>>> price. > >>>> > >>>> Bill > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ------------------------------ > Make your browsing faster, safer, and easier with the new Internet > ExplorerÂ® 8. Optimized for Yahoo! *Get it Now for Free! *<http://downloads.yahoo.com/ca/internetexplorer/> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Benoit St-Jean

If that helps... 0 tinyBenchmarks Windows XP, 2002, SP3 Pentium 4, dual core, 3Ghz, 2 Gb RAM All tests were run 5 times and here are the averages : Some comparisons: Squeak 3.9 latest update: #7067 76297334 bytecodes/sec; 3397437 sends/sec Squeak 3.10.2 latest update: #7179 74839234 bytecodes/sec; 3443964 sends/sec Pharo 0.1 latest update: #10377 75877223 bytecodes/sec; 3134820 sends/sec ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Gary Chambers <gazzaguru2(a)btinternet.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, July 16, 2009 6:51:59 AM Subject: Re: [Pharo-project] Making some progress, and a few observations In the Windows camp, Watery2 theme... Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371. 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373 Older laptop, XP, 1GB, Pentium M (1.73 GHz)... 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677 Still feels quite responsive even on that! Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations On my crusty old Linux box: 155339805 bytecodes/sec; 3931964 sends/sec However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec(a)free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a Ã©crit : > Bill, > > Could you post the results of the following benchmark? > > 0 tinyBenchmarks > > On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: > > '543236074 bytecodes/sec; 12101592 sends/sec' > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain > Cheers, > Adrian > > On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: > > >> Stef, >> >> No browser should be that slow. I suspect the Linux vm is not a >> speed demon, the xp machines I use are heavily burdened by anit- >> virus software and other performance drains, etc. My linux box at >> home might be further hindered by the fact that I bought a wide >> screen monitor for it, and use LOTS of screen real estate. Still, >> when I compare Pharo with other software (including Dolphin) under >> similarly abusive conditions, Pharo is not quick. >> >> This particular image is small; it is based on the most recent web >> image, and is 22 MB. It has some of my Seaside code in it, but has >> not yet executed same. I have a couple of Seaside cleanup >> expressions that help when images bloat up, but looking at the >> current size makes me think I'm missing an opportunity. All that >> aside, on my linux box, I find that after the saving cursor >> disappears, it can take a few seconds for the image to again become >> responsive. On xp in my office, there is at least a second of down >> time after the cursor reverts to normal. >> >> In doing some SIF imports, I noted that it was hard to tell when the >> image was still busy. I have no idea how long it should take to do >> the work it was doing, but it took long enough that some gentle >> prodding becomes irresistable: "is it done yet?" I remember lots of >> debate about Cursor class>>showWhile: on Dolphin; it might be one of >> those things that is tricky to get right. >> >> A little bit nicer news: I have it running on my office machine >> (xp), with FreeType in use, and it's ok with the standard tools and >> the w2k theme. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Wednesday, July 15, 2009 2:31 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Making some progress, and a few >> observations >> >> >>> Stef, >>> >>> In terms of response times, even with a lot of things turned off, I >>> was still surprised at how long it takes to change from even one >>> method to another. >>> >> which browser are you using. >> Because the old browser should not be that slow. >> >> >> >>> Anything past 0.2 sec (or whatever that threshold is) starts to add >>> up; Pharo sometimes takes up to a second, which is _really_ shows up. >>> >>> Saving an image is not necessarily quick either, I _think_ >>> particuarly >>> on Linux?? >>> >> What is the size of your image: here jannik generated an image of >> 800 mb. >> >> >>> Also, I get the sense the wait cursors are displayed, on Linux, for a >>> smaller fraction of the down time than on Windows. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of StÃ©phane Ducasse >>> Sent: Wednesday, July 15, 2009 12:58 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Making some progress, and a few >>> observations >>> >>> >>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: >>> >>> >>>> Hello all, >>>> >>>> I managed to create an install script; as I suspected would be case, >>>> it was very anticlimactic. I tried creating a password-protected >>>> directory under my personal web site, but that did not go well. The >>>> authentication is weird, so it was probably asking a lot. A >>>> directory repository worked. >>>> >>> Good to know >>> >>>> Does Monticello/PackageInfo see a change in method category (aka >>>> package) as a change to the package? >>>> >>> normally it should. >>> >>> >>>> It appears not, and it worries me a little in that it seems to make >>>> it easy to lose work by forgetting to save it. Do any of you script >>>> saving your packages? >>>> >>> you can check in ScriptLoader to see how we compute the packages that >>> changed (not only dirty but also new packages) >>> >>> >>>> The results are untested at present, but I used SIF to transfer a >>>> fair amount of code into Pharo. To cope with the naming of the ODBC >>>> classes, I ended up doing things like Smalltalk at:#DBConnection >>>> put:ODBCConnection, and that worked out nicely, at least AFAICT at >>>> this stage. SIF finally ended up complaining about running out of >>>> items when processing the last file. I reserve the right to later >>>> report that it was a miserable failure, but it looks like I most of >>>> the code imported. >>>> >>>> Using the standard tools, the w2k theme, disabling faded backgrounds >>>> and enabling fast drag, performance on an older Linux system is ok >>>> (more or less). There are still things that take too long, >>>> >>> like what? >>> >>> >>>> and Pharo's responses are no better (sometimes worse) than even >>>> software running over a remote desktop connection. We need a speed >>>> boost, but judicious settings help a little. >>>> >>>> Is there a way to disable the anti-aliased fonts? In fairness, I >>>> should try turning that off to see if any speed boost is worth the >>>> price. >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

July 16, 2009