October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

2010/10/18 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Oct 18, 2010 at 9:21 AM, Bart Veenstra <bart.veenstra(a)gmail.com> > wrote: >> >> After MCMethodDefinition shutDown > > Does this have some kind of bad side effect or I can do it also? > it clears the MC cache. Absolutely safe. See http://code.google.com/p/pharo/issues/detail?id=3048.. and there are also a recent discussion about it on pharo-dev about removing MC cache from weak-dependents list, (but i'm too lazy to search and give a link to it :) ). > Cheers > > Mariano > >> >> it looks like it is reacting a bit >> faster to keyboard input. I often experience sluggishness in >> autocompletion method. When I type in a name of a class in a >> workspace, the autocomplete suggests 3 options. I want to choose the >> middle, so I press down and after 3 seconds (or sometimes nothging >> happens) it selects the class. The longer I have my image open, the >> longer this will take :S >> >> >> >> >> 2010/10/17 Igor Stasenko <siguctua(a)gmail.com>: >> > Bart, >> > can you try doing: >> > >> > MCMethodDefinition shutDown >> > >> > in your image? >> > >> > On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> wrote: >> >> Hi list, >> >> >> >> I have been working with Pharo for almost a month now, and I suspect >> >> that the performance is degrading fast. UI tasks takes several seconds >> >> to react to my keyboard. >> >> >> >> At work we use VAST and I have experience with VW as well and those >> >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> >> works very sluggish. >> >> >> >> My image is about 130MB because I have loaded all dutch postcode in >> >> memory, but that should not affect the performance of general >> >> operations like typing with the keyboard. I am not a fast typer, but >> >> sometimes it takes seconds to show my keyboard input. I can't use the >> >> down key to select the right method from suggestions, because it seems >> >> to lockup completely. >> >> >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> >> haven't got gemtools working on it... >> >> >> >> Will upgrading to 1.1.1 fix these issues? >> >> >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> >> >> Regards, >> >> >> >> Bart >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko AKA sig. >> > >> > _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by Igor Stasenko

On 18 October 2010 07:00, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 17 Oct 2010, Levente Uzonyi wrote: > > snip > >> SharedQueue's code for "growing" (#makeRoomAtEnd) is crap IMHO. Because of >> that it takes O(n) time to add or remove and element to or from the queue. >> SharedQueue2 is a lot better approach, because it doesn't try to >> reimplement a dynamic array, but uses OrderedCollection instead. > > I uploaded a new version of that method to the Trunk. I don't think it's > really useful, because I'm pretty sure we will get rid of both SharedQueue > and SharedQueue2 in the near future. > Anyway I did some benchmarks using Cog, and SharedQueue became surprisingly > good, though it's still not even close to Igor's new FIFOQueue or > AtomicSharedQueue. > > Benchmark #1: Make a large queue > > { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ > :queueClass | > Â Â Â Â | queue | > Â Â Â Â queue := queueClass new. > Â Â Â Â queueClass -> ( > Â Â Â Â Â Â Â Â (1 to: 5) collect: [ :run | > Â Â Â Â Â Â Â Â Â Â Â Â Smalltalk garbageCollect. > Â Â Â Â Â Â Â Â Â Â Â Â { > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ 1 to: 1000000 do: [ :each | queue nextPut: > each ] ] timeToRun. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ 1 to: 1000000 do: [ :each | queue next ] ] > timeToRun } ]) ]. > > SharedQueue->#(#(1028 1615) #(945 1557) #(976 2322) #(492 459) #(489 476)). > SharedQueue2->#(#(1976 2284) #(1318 8298) #(982 692) #(1005 675) #(1002 > 665)). > FIFOQueue->#(#(180 67) #(184 67) #(182 69) #(181 66) #(177 67)). > AtomicSharedQueue->#(#(208 66) #(207 67) #(209 66) #(213 68) #(209 65)). > > This benchmark is similar to what Igor used, but it doesn't create a new > queue between runs. It simply adds 1,000,000 elements then removes them > which is a pretty unrealistic scenario for a shared queue. The effect of GC > is pretty high on this benchmark, probably that's responsible for the high > spikes. > > Benchmark #2: Sequential throughput test > > { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ > :queueClass | > Â Â Â Â | queue | > Â Â Â Â queue := queueClass new. > Â Â Â Â queueClass -> ( > Â Â Â Â Â Â Â Â (1 to: 5) collect: [ :run | > Â Â Â Â Â Â Â Â Â Â Â Â | results | > Â Â Â Â Â Â Â Â Â Â Â Â Smalltalk garbageCollect. > Â Â Â Â Â Â Â Â Â Â Â Â results := #(0 0). > Â Â Â Â Â Â Â Â Â Â Â Â 1 to: 1000 do: [ :round | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â results := results + { > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ 1 to: 1000 do: [ :each | queue > nextPut: each ] ] timeToRun. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ 1 to: 1000 do: [ :each | queue next > ] ] timeToRun } ]. > Â Â Â Â Â Â Â Â Â Â Â Â results ]) ]. > > SharedQueue->#(#(464 452) #(472 436) #(466 437) #(463 449) #(462 452)). > SharedQueue2->#(#(949 692) #(980 663) #(984 670) #(992 670) #(958 677)). > FIFOQueue->#(#(125 67) #(263 62) #(250 76) #(262 63) #(247 81)). > AtomicSharedQueue->#(#(154 70) #(264 77) #(273 62) #(275 63) #(265 71)). > > This is similar to benchmark #1, but instead of adding and removing > 1,000,000 at once it's chunked up to 1,000 equal parts. It's more realistic > than benchmark #1. It's interesting that both FIFOQueue and > AtomicSharedQueue performed better in the previous benchmark, unlike the > other two queues, which are better here. > > Benchmark #3: Concurrent throughput test > > { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ > :queueClass | > Â Â Â Â | queue semaphore | > Â Â Â Â queue := queueClass new. > Â Â Â Â semaphore := Semaphore new. > Â Â Â Â queueClass -> ( > Â Â Â Â Â Â Â Â (1 to: 5) collect: [ :run | > Â Â Â Â Â Â Â Â Â Â Â Â | producers consumers | > Â Â Â Â Â Â Â Â Â Â Â Â Smalltalk garbageCollect. > Â Â Â Â Â Â Â Â Â Â Â Â producers := (1 to: 100) collect: [ :each | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ 1 to: 10000 do: [ :index | queue nextPut: > each ] ] newProcess ]. > Â Â Â Â Â Â Â Â Â Â Â Â consumers := (1 to: 100) collect: [ :each | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1 to: 10000 do: [ :index | queue next > ]. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â semaphore signal ] newProcess ]. > Â Â Â Â Â Â Â Â Â Â Â Â [ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â consumers do: [ :each | each priority: 39; > resume ]. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â producers do: [ :each | each priority: 39; > resume ]. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 100 timesRepeat: [ semaphore wait ] ] > timeToRun ]) ]. > > SharedQueue->#(3143 2977 3034 2949 3021). > SharedQueue2->#(4280 4384 4179 4160 4181). > FIFOQueue->#(245 311 252 254 255). > AtomicSharedQueue->#(277 274 277 280 274) > > This benchmark is the real concurrent stress test. 100 processes are adding > 10,000 elements to the queue while another 100 are reading from it. It > clearly shows that Igor's queues are an order of magnitude faster. Also 200 > concurrent processes cause much less slowdown compared to the sequential > tests for them. > > So, even though SharedQueue is now faster than SharedQueue2, both will have > to go IMHO. :) > Thanks, Levente for giving a feedback. Please, feel free to shape my classes in more complete from (such as proper naming), to make them ready for inclusion in both Squeak's and Pharo cores. I propose the following names: AtomicQueue (base class) -> AtomicCollection FIFOQueue -> AtomicQueue LIFOQueue -> AtomicStack If you, or anyone else having better suggestions, speak now :) In any case, i'm am open to discuss further details and possible caveats of using new classes to anyone interested in using them. P.S. As a side note, i now can explain (to myself at first place), why i intuitively choosed to used atomic swap instead of CAS. Because it fits better fits with smalltalk language semantics: A swap operation in smalltalk implemented as two assignments: x := y. y := z. An assignments is basic operation, which have nothing to do with late-bound nature of language. Unless we going to introduce a meta-object protocol(s), which could turn a simple assignment into some message sends under the hood, it will remain a basic, early-bound operation. And even if we do, it is highly unlikely, that even then we will throw away the old, simple assignment, which identifies an assignment source & target at compile time. In contrast, a CAS operation , if written in smalltalk looks like: (a == b ) ifTrue: [ a := c ] so, it having two message sends (#== , #ifTrue:), and from strict, pure language perspective, this using a late-bound semantics (a message sends), and as any message send, the message result and behavior cannot be predicted at compile time and therefore its wrong to assume that such statement could be an atomic operation. Unless, of course, we introduce a new language syntax which will denote a CAS operation explicitly. > > Levente > > > snip > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Fwd: pharo sprint / moose dojo - october 23-24, bern

by Laval Jannik

Hi, I created an entry at: http://code.google.com/p/pharo/wiki/PharoSprints We will join you by internet :) Cheers, Jannik On Oct 18, 2010, at 11:01 , Tudor Girba wrote: > Hi, > > This is just a reminder that the next Pharo sprint will take place during October 23-24 in Bern (see below). If you want to attend, please let me know. > > Cheers, > Doru > > > Begin forwarded message: > >> We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). >> >> Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): >> http://www.moosetechnology.org/events/2010-10-22-dojo >> >> For planning purposes, please let me know if you will attend. ESUG will kindly offer support for food and drinks. >> >> Cheers, >> Doru >> >> p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) >> http://choose.s-i.ch/events/forum2010 > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project --- Jannik Laval

Oct. 18, 2010

[Pharo-project] Fwd: pharo sprint / moose dojo - october 23-24, bern

by Tudor Girba

Hi, This is just a reminder that the next Pharo sprint will take place during October 23-24 in Bern (see below). If you want to attend, please let me know. Cheers, Doru Begin forwarded message: > We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). > > Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): > http://www.moosetechnology.org/events/2010-10-22-dojo > > For planning purposes, please let me know if you will attend. ESUG will kindly offer support for food and drinks. > > Cheers, > Doru > > p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) > http://choose.s-i.ch/events/forum2010 -- www.tudorgirba.com "Obvious things are difficult to teach."

Oct. 18, 2010

[Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails

by nullPointer

Hi I do implementing a easy Timer class. The purpose of timer is launch events for UI thread and the process thread too when a interval of time is elapsed. My problem is throwned when I call the message #newProcessWith: from BlockClosure. I pass an array with a parameter, the instance of CLTimer class, which is used in the Closure process for launc the events. A error of not is valid the number of arguments is launched: 'This block accepts 1 argument, but was called with 0 arguments.' I donÂ´t understand very good the problem. I have pass an array with one element, and the Closure receives one parameter too... Basically the code: pvtGetNewProcessBlock ^[:timer || intervalDelay | [timer enabled] whileTrue:[ (Delay forMilliseconds: timer interval) wait. timer enabled ifTrue:[ timer raiseOnElapsedTimeForProcessThread: (timer getProcess). WorldState addDeferredUIMessage:[ timer raiseOnElapsedTimeForUIThread: (timer getProcess) ]. ] ]. ]. pvtStartProcess | processBlock | processBlock := self pvtGetNewProcessBlock. internalProcess := processBlock newProcessWith:{self}. internalProcess resume. PD. Exists some complete doc with the way for work with threads in Pharo/Squeak? I did see time ago a doc of Smalltalk processes, in french language, but I donÂ´t see in Google :( http://forum.world.st/file/n2999831/CLTimer.st CLTimer.st -- View this message in context: http://forum.world.st/Implementing-a-Timer-newProcessWith-anArray-fails-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Mariano Martinez Peck

On Mon, Oct 18, 2010 at 9:21 AM, Bart Veenstra <bart.veenstra(a)gmail.com>wrote: > After MCMethodDefinition shutDown Does this have some kind of bad side effect or I can do it also? Cheers Mariano > it looks like it is reacting a bit > faster to keyboard input. I often experience sluggishness in > autocompletion method. When I type in a name of a class in a > workspace, the autocomplete suggests 3 options. I want to choose the > middle, so I press down and after 3 seconds (or sometimes nothging > happens) it selects the class. The longer I have my image open, the > longer this will take :S > > > > > 2010/10/17 Igor Stasenko <siguctua(a)gmail.com>: > > Bart, > > can you try doing: > > > > MCMethodDefinition shutDown > > > > in your image? > > > > On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> wrote: > >> Hi list, > >> > >> I have been working with Pharo for almost a month now, and I suspect > >> that the performance is degrading fast. UI tasks takes several seconds > >> to react to my keyboard. > >> > >> At work we use VAST and I have experience with VW as well and those > >> smalltaks react to my keyboard and mouse actions instantly. But Pharo > >> works very sluggish. > >> > >> My image is about 130MB because I have loaded all dutch postcode in > >> memory, but that should not affect the performance of general > >> operations like typing with the keyboard. I am not a fast typer, but > >> sometimes it takes seconds to show my keyboard input. I can't use the > >> down key to select the right method from suggestions, because it seems > >> to lockup completely. > >> > >> Are there ways to speedup Pharo? I would love to use cogVM but I > >> haven't got gemtools working on it... > >> > >> Will upgrading to 1.1.1 fix these issues? > >> > >> Is my OS (Windows 7-64bit) causing these issues? > >> > >> Regards, > >> > >> Bart > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > _______________________________________________ > > 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 >

Oct. 18, 2010

Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1

by Bart Veenstra

I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part. Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much. Regards, Bart 2010/10/18 Sven Van Caekenberghe <sven(a)beta9.be>: > > On 18 Oct 2010, at 09:21, Bart Veenstra wrote: > >> After MCMethodDefinition shutDown it looks like it is reacting a bit >> faster to keyboard input. I often experience sluggishness in >> autocompletion method. When I type in a name of a class in a >> workspace, the autocomplete suggests 3 options. I want to choose the >> middle, so I press down and after 3 seconds (or sometimes nothging >> happens) it selects the class. The longer I have my image open, the >> longer this will take :S > > That is what I had before, see my earlier answer... > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] A Lazy Inspector?

by Mariano Martinez Peck

On Mon, Oct 18, 2010 at 4:40 AM, Oscar E A Callau <oalvarez(a)dcc.uchile.cl>wrote: > Hello all, > > I was wondering what actually the inspector does in the following case: > > When you explore (or inspect) the expression: Class environment > you get all classes in the system dictionary. If you navigate inside a > class, for example AColorSelectorMorph, you can see all its properties and > one of them is environment, if you go inside it, you get again all classes > in the system dictionary. So, you can repeat this infinitely (or until you > get run out of memory, I guess) > > Is it the behavior of a lazy inspector? If true, why I cannot inspect a > mutually-recursive class definition, like this: > > Object subclass: #Foo > instanceVariableNames: 'bar' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Foo>>initialize > bar:= Bar new > > Object subclass: #Bar > instanceVariableNames: 'foo' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Foo>>initialize > bar:= Foo new > > Thanks in advance. > > That's a good question. I have no idea how it is hanlder. > P.S.: How can I stop my execution in the pharo image when it is in a > infinite loop? I can't remember what the shortcut was. > > http://book.pharo-project.org/book/TipsAndTricks/InterruptKey/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1

by Sven Van Caekenberghe

On 18 Oct 2010, at 09:21, Bart Veenstra wrote: > After MCMethodDefinition shutDown it looks like it is reacting a bit > faster to keyboard input. I often experience sluggishness in > autocompletion method. When I type in a name of a class in a > workspace, the autocomplete suggests 3 options. I want to choose the > middle, so I press down and after 3 seconds (or sometimes nothging > happens) it selects the class. The longer I have my image open, the > longer this will take :S That is what I had before, see my earlier answer... Sven

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

VM Statistics: uptime 45h21m14s memory 125,787,076 bytes old 122,936,884 bytes (97.7%) young 288,944 bytes (0.2%) used 123,225,828 bytes (98.0%) free 2,561,248 bytes (2.0%) GCs 211,214 (773ms between GCs) full 26 totalling 9,392ms (0.0% uptime), avg 361.2ms incr 211188 totalling 6,751ms (0.0% uptime), avg 0.0ms tenures 176 (avg 1199 GCs/tenure) Since last view 198,425 (0ms between GCs) uptime -29.4s full 5 totalling 6,910ms (-23.5% uptime), avg 1382.0ms incr 198420 totalling 4,258ms (-14.5% uptime), avg 0.0ms tenures 100 (avg 1984 GCs/tenure) 2010/10/18 Bart Veenstra <bart.veenstra(a)gmail.com>: > After MCMethodDefinition shutDown it looks like it is reacting a bit > faster to keyboard input. I often experience sluggishness in > autocompletion method. When I type in a name of a class in a > workspace, the autocomplete suggests 3 options. I want to choose the > middle, so I press down and after 3 seconds (or sometimes nothging > happens) it selects the class. The longer I have my image open, the > longer this will take :S > > > > > 2010/10/17 Igor Stasenko <siguctua(a)gmail.com>: >> Bart, >> can you try doing: >> >> MCMethodDefinition shutDown >> >> in your image? >> >> On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> wrote: >>> Hi list, >>> >>> I have been working with Pharo for almost a month now, and I suspect >>> that the performance is degrading fast. UI tasks takes several seconds >>> to react to my keyboard. >>> >>> At work we use VAST and I have experience with VW as well and those >>> smalltaks react to my keyboard and mouse actions instantly. But Pharo >>> works very sluggish. >>> >>> My image is about 130MB because I have loaded all dutch postcode in >>> memory, but that should not affect the performance of general >>> operations like typing with the keyboard. I am not a fast typer, but >>> sometimes it takes seconds to show my keyboard input. I can't use the >>> down key to select the right method from suggestions, because it seems >>> to lockup completely. >>> >>> Are there ways to speedup Pharo? I would love to use cogVM but I >>> haven't got gemtools working on it... >>> >>> Will upgrading to 1.1.1 fix these issues? >>> >>> Is my OS (Windows 7-64bit) causing these issues? >>> >>> Regards, >>> >>> Bart >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 18, 2010