February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14357

by Marcus Denker

14357 ----- Issue 5383: Merge all Compiler tests into CompilerTests package http://code.google.com/p/pharo/issues/detail?id=5383 Issue 5375: Clean dead code in CharacterScanner a bit http://code.google.com/p/pharo/issues/detail?id=5375 Issue 5318: DNU On PluggableListMorph http://code.google.com/p/pharo/issues/detail?id=5318 Issue 5374: Remove old DOS font support http://code.google.com/p/pharo/issues/detail?id=5374 Issue 5373: remove unused (undocumented) R2L code in MultiCharacterScanner and Fonts. http://code.google.com/p/pharo/issues/detail?id=5373 -- Marcus Denker -- http://marcusdenker.de

Feb. 25, 2012

Re: [Pharo-project] So I broke 8k req/s today

by Sven Van Caekenberghe

Philippe , That is incredibly fast, I just tried and I can't even get plain apache2 serve the static.html that fast over the local network ! When I have more time, I really have to try to repeat your results with your code ( as well as study the code ;-) Can you please provide the main pointers again ? I remember you once explained how to setup AJP somewhere... Sven On 25 Feb 2012, at 17:31, Philippe Marschall wrote: > On 25.02.2012 16:02, Sven Van Caekenberghe wrote: >> Philippe, >> >> On 25 Feb 2012, at 14:35, Philippe Marschall wrote: >> >>> Hi >>> >>> I heighten everybody's mood I'll post some positive news. >>> >>> After some optimizations in both Seaside and AJP I managed to break 8000 requests / sec with a single Pharo 1.3 image. Thanks to SystemProfiler I knew where to look. >>> >>> This is with a single request handler that just returns a two byte response. It doesn't involve any rendering, sessions, continuations or whatsoever but it kicks on the full Seaside request handling machinery with a request context and everything. >>> >>> I'm using WASmallRequestHandler from the Seaside-Benchmark package. >>> >>> WASmallRequestHandler>> #handleFiltered: aRequestContext >>> aRequestContext respond: [ :response | >>> response >>> binary; >>> contentType: WAMimeType textHtml; >>> nextPutAll: 'OK' asByteArray ] >>> >>> Apache 2.2.21 mpm_worker mod_proxy_ajp >>> CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz >>> SmalltalkImage current vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.138]' >>> >>> Attached you'll find the output of ApacheBench. >>> >>> Cheers >>> Philippe >>> <8k.txt> >> >> Very nice, indeed. >> >> What would you get with your setup when you increase the work a bit from the your lower limit 2 byte response to something like this page ? >> >> http://zn.stfx.eu/dw-bench (dynamically generated by Zn) >> http://caretaker.wolf359.be:8080/DW-Bench (dynamically generated by Seaside) >> http://stfx.eu/static.html (static reference by Apache) > > Drops to about 6.5 k but throughput goes up to about 50 Mbytes/sec. That's with a statically allocated byte array, no rendering. > > It's still doing too much copying so there is space left to go. > > Cheers > Philippe > > <dw-bench.txt>

Feb. 25, 2012

[Pharo-project] Do we have the new primitive?? [WAS] Re: IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

> All I can say is that I am impressed by the numbers it is really much >> faster. >> I still don't understand why I send this email with a subject say >> IdentitySet because what I really need is a fast/large IdentityDictionary >> :( Anyway, there's a place where we can use this LargeIdentitySet in Fuel >> I think). >> >> So Levente, you say this is not possible to adapt this for dictionary? >> can >> we contact Eliot to provide such a primitive? >> > > As promised, I uploaded my LargeIdentityDictionary implementation to > http://leves.web.elte.hu/**squeak/**LargeIdentityDictionary.st<http://leves.web.elte.hu/squeak/LargeIdentityDictionary.st>. > The numbers will be a bit worse compared to LargeIdentitySet, because of > the lack of the primitive, but it's still 2-3x faster than other solutions > (IdentityDictionary, PluggableIdentityDictionary, subclassing, etc). I'm > about to propose this primitive with other improvements on the vm-dev list. > > Hi Eliot/Levente. What is the status of this? Do we have already the new primitive? If true, how can we adapt LargeIdentitySet to use such new primitive? Thanks! > > Levente > > >> thanks >> >> On Fri, Dec 16, 2011 at 3:28 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote: >>> >>> On 16.12.2011 03:26, Levente Uzonyi wrote: >>> >>>> >>>> >>>>> How about my numbers? :) >>>>> >>>>> "Preallocate objects, so we won't count gc time." >>>>> n := 1000000. >>>>> objects := Array new: n streamContents: [ :stream | >>>>> n timesRepeat: [ stream nextPut: Object new ] ]. >>>>> >>>>> set := IdentitySet new: n. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "4949" >>>>> >>>>> set := LargeIdentitySet new. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "331" >>>>> >>>>> set := (PluggableSet new: n) >>>>> hashBlock: [ :object | object identityHash * 4096 + object class >>>>> identityHash * 64 ]; "Change this to #basicIdentityHash in Pharo" >>>>> equalBlock: [ :a :b | a == b ]; >>>>> yourself. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "5511" >>>>> >>>>> >>>>> I also have a LargeIdentityDictionary, which is relatively fast, but >>>>> not >>>>> as fast as LargeIdentitySet, because (for some unknown reason) we don't >>>>> have a primitive that could support it. If we had a primitive like >>>>> primitive 132 which would return the index of the element if found or >>>>> 0 if >>>>> not, then we could have a really fast LargeIdentityDictionary. >>>>> >>>>> >>>>> Levente >>>>> >>>>> Hehe yes, if writing a version fully exploiting the limited range, >>>> that's >>>> probably the approach I would go for as well. >>>> (IAssuming it's the version at http://leves.web.elte.hu/** >>>> squeak/LargeIdentitySet.st<htt**p://leves.web.elte.hu/squeak/** >>>> LargeIdentitySet.st<http://leves.web.elte.hu/squeak/LargeIdentitySet.st> >>>> > >>>> ) >>>> >>>> Mariano commented in the version at http://www.squeaksource.com/** >>>> FuelExperiments <http://www.squeaksource.com/**FuelExperiments<http://www.squeaksource.com/FuelExperiments>> >>>> that it's >>>> >>>> slow for them, which I guess is due to not adopting #identityHash calls >>>> to >>>> #basicIdentityHash calls for Pharo: >>>> ((0 to: 4095) collect: [:each | each << 22 \\ 4096 ]) asSet size -> 1 >>>> So it basically uses 1 bucket instead of 4096... Whoops. :) >>>> >>>> Uploaded a new version to the MC repository which is adapted for Pharo, >>>> on the same machine my numbers were taken from, it does the same test >>>> as I >>>> used above in 871 ms. (181 with preallocation). >>>> >>>> >>> Cool. One more thing: in Squeak the method using primitive 132 directly >>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If >>> this was also added to Pharo, then the #pointsTo: sends should be changed >>> to #instVarsInclude:, otherwise Array can be reported as included even if >>> it wasn't added. >>> I'll upload my LargeIdentityDictionary implementation to the same place >>> this evening, since it's still 2-3 factor faster than other solutionts >>> and >>> there seem to be demand for it. >>> >>> >>> Levente >>> >>> >>> Cheers, >>>> Henry >>>> >>>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

Feb. 25, 2012

Re: [Pharo-project] Thanks Marcus for all these updates...

by Sven Van Caekenberghe

On 25 Feb 2012, at 17:11, StÃ©phane Ducasse wrote: > Thank thanks thanks and thanks because I love to see all these updates. > I got back and dead and now recoveringâ¦ +100 as well. The integrator's job is very important and much appreciated. Thx to the both of you, Sven

Feb. 25, 2012

Re: [Pharo-project] Thanks Marcus for all these updates...

by Tudor Girba

+100 Doru On 25 Feb 2012, at 17:11, StÃ©phane Ducasse wrote: > HI marcus > > Thank thanks thanks and thanks because I love to see all these updates. > I got back and dead and now recoveringâ¦ > > Stef -- www.tudorgirba.com "It's not how it is, it is how we see it."

Feb. 25, 2012

Re: [Pharo-project] So I broke 8k req/s today

by Philippe Marschall

On 25.02.2012 16:02, Sven Van Caekenberghe wrote: > Philippe, > > On 25 Feb 2012, at 14:35, Philippe Marschall wrote: > >> Hi >> >> I heighten everybody's mood I'll post some positive news. >> >> After some optimizations in both Seaside and AJP I managed to break 8000 requests / sec with a single Pharo 1.3 image. Thanks to SystemProfiler I knew where to look. >> >> This is with a single request handler that just returns a two byte response. It doesn't involve any rendering, sessions, continuations or whatsoever but it kicks on the full Seaside request handling machinery with a request context and everything. >> >> I'm using WASmallRequestHandler from the Seaside-Benchmark package. >> >> WASmallRequestHandler>> #handleFiltered: aRequestContext >> aRequestContext respond: [ :response | >> response >> binary; >> contentType: WAMimeType textHtml; >> nextPutAll: 'OK' asByteArray ] >> >> Apache 2.2.21 mpm_worker mod_proxy_ajp >> CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz >> SmalltalkImage current vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.138]' >> >> Attached you'll find the output of ApacheBench. >> >> Cheers >> Philippe >> <8k.txt> > > Very nice, indeed. > > What would you get with your setup when you increase the work a bit from the your lower limit 2 byte response to something like this page ? > > http://zn.stfx.eu/dw-bench (dynamically generated by Zn) > http://caretaker.wolf359.be:8080/DW-Bench (dynamically generated by Seaside) > http://stfx.eu/static.html (static reference by Apache) Drops to about 6.5 k but throughput goes up to about 50 Mbytes/sec. That's with a statically allocated byte array, no rendering. It's still doing too much copying so there is space left to go. Cheers Philippe

Feb. 25, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by StÃ©phane Ducasse

can you send the code that we play with it because I would like to learn how you do that. Stef On Feb 24, 2012, at 7:02 PM, S Krish wrote: > I love Pharo's ability to mould/ twist in spare time something that is > imminently usable.. > > Just playing around over an hour plus, I find this tree view grouping > more convinient than current browsers in giving a coherent view that > easily extends: > > All editable code text morphs, spreading over to mutliple worlds one > can traverse too if needed. or appears on tab anyways for each group. > > a) Package, Class, Category , Hierarchy levels. > > b) Senders, implementors .. > > c) Arbitrary groups of methods if one desires to.. > > Can also include some class definition info bubble/ reduce noise > through some more optimization to make it optimized > > ... we can have a little customizations too to get a good grip of the > whole as well as the part. > > But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo > fragmented view it will still represented. May be each will have > little twist of his predilictions and cannot be highly generalized. > > > On 2/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia(a)gmail.com> >> wrote: >>> On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;) >>> >>> Ooops... Time to get a new identity :) >>> >>> >>> On 23 February 2012 19:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> Sure we know. >>>> And we also know that it requires effort and lot of people are talking. >>> >>> I know there's a loooong way to see what CodeBubbles can do, and that >>> requires to do a big effort, but imagined that some kind of >>> alternative - I'm not sure that CB is **exactly** what I want (sure >>> Java-ers want to see **something more** than just a file pimped with >>> colours, but Smalltalk **allready has** much more than a text file - >>> have real code) - could be very less effort-consuming. Making the >>> current browser (Nautilus? - newbie here :) ) pop a new >>> Â¿window?Â¿morph? showing a method instead of updating a single pane >>> (the current one showing method's source) don't seems to be so "far" >>> away to me. >>> >>> Of course that's my point of view, based on what I imagine that could >>> be. I should spend some time to see how it is implemented, and to see >>> if it really is that simple, but anyway trust you if you say is a huge >>> effort... >>> >> >> Well, popping out a new morph every time you clicking around is easy part. >> The hard part is to make this stuff really consistent and easy to use >> for navigation and development. >> It requires far more serious work than just spending 2 hours >> implementing "bubbling" behavior. >> >>> >>> Cheers :) >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > <Pharo_CodeBrowser01.JPG>

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14355

by Marcus Denker

On Feb 25, 2012, at 5:20 PM, StÃ©phane Ducasse wrote: > Excellent! > Pavel > We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that. > because this is really great. > It already is configured to be build after every update: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ tests, too: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/ Now we need to take action when it breaks... -- Marcus Denker -- http://marcusdenker.de

Feb. 25, 2012

Re: [Pharo-project] So I broke 8k req/s today

by StÃ©phane Ducasse

On Feb 25, 2012, at 2:35 PM, Philippe Marschall wrote: > Hi > > I heighten everybody's mood I'll post some positive news. Ok now I understand what the earth stopped to spin today :) Thanks for the mail Stef > > After some optimizations in both Seaside and AJP I managed to break 8000 requests / sec with a single Pharo 1.3 image. Thanks to SystemProfiler I knew where to look. > > This is with a single request handler that just returns a two byte response. It doesn't involve any rendering, sessions, continuations or whatsoever but it kicks on the full Seaside request handling machinery with a request context and everything. > > I'm using WASmallRequestHandler from the Seaside-Benchmark package. > > WASmallRequestHandler >> #handleFiltered: aRequestContext > aRequestContext respond: [ :response | > response > binary; > contentType: WAMimeType textHtml; > nextPutAll: 'OK' asByteArray ] > > Apache 2.2.21 mpm_worker mod_proxy_ajp > CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz > SmalltalkImage current vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.138]' > > Attached you'll find the output of ApacheBench. > > Cheers > Philippe > <8k.txt>

Feb. 25, 2012

[Pharo-project] MorphTreeMorph is faster

by Tudor Girba

Hi Alain, Thanks for making MorphTreeMorph faster :). Here are some tiny benchmarks: Time millisecondsToRun: [GLMFinder new show: [:a | a list display: [:x | 1 to: x]]; openOn: 10000 ] Old MorphTreeMorph in 1.3: 10000 items ==> 7654 ms 100000 items ==> 96739 ms New MorphTreeMorph in 1.4: 10000 items ==> 3872 ms 100000 items ==> 68746 ms Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Feb. 25, 2012