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

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

5 % is cool in such scenario. Thanks levente. I believe in small speed ups and you show that. Stef On May 24, 2010, at 10:47 PM, Levente Uzonyi wrote: > On Mon, 24 May 2010, Lukas Renggli wrote: > >>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the >>> moment, so that should be preferred in core packages. >> >> It should not be preferred or changes unless you can prove a real >> performance benefit. I still haven't seen a single realistic benchmark >> with real code (from Pharo, Seaside, Pier, ...) where you can measure >> a real difference between these 4 variants. > > Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. > > For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: > > Original: > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next isNil ] whileFalse ] timeToRun ] ] > #(9928 9733 9753 9703 9711) > > Then I replaced the #isNil send to == nil: > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(9214 9301 9419 9273 9285) > > Not bad 4.8% faster. Then I replaced the line > character1 isNil ifTrue: [^ nil]. > with > character1 ifNil: [^ nil]. > in UTF8TextConverter >> #nextFromStream:. > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(8947 8779 8814 8845 8810). > 5% faster than the previous. > > Removing 2 #isNil sends from the tight loop gave ~10% speedup. > > > Levente > >> >> >>> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >>> object" directly to nil, otherwise #= will be asymmetric: >>> null = nil -> true >>> nil = null -> false >> >> That's not the problem. The problem is when you have proxy objects >> then all these inlined an shortcut variants fail miserably. >> >> Lukas >> >> -- >> Lukas Renggli >> 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

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

On Mon, 24 May 2010, Lukas Renggli wrote: >> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the >> moment, so that should be preferred in core packages. > > It should not be preferred or changes unless you can prove a real > performance benefit. I still haven't seen a single realistic benchmark > with real code (from Pharo, Seaside, Pier, ...) where you can measure > a real difference between these 4 variants. Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: Original: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next isNil ] whileFalse ] timeToRun ] ] #(9928 9733 9753 9703 9711) Then I replaced the #isNil send to == nil: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(9214 9301 9419 9273 9285) Not bad 4.8% faster. Then I replaced the line character1 isNil ifTrue: [^ nil]. with character1 ifNil: [^ nil]. in UTF8TextConverter >> #nextFromStream:. (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(8947 8779 8814 8845 8810). 5% faster than the previous. Removing 2 #isNil sends from the tight loop gave ~10% speedup. Levente > > >> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >> object" directly to nil, otherwise #= will be asymmetric: >> null = nil -> true >> nil = null -> false > > That's not the problem. The problem is when you have proxy objects > then all these inlined an shortcut variants fail miserably. > > Lukas > > -- > Lukas Renggli > 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 >

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by Adrian Lienhard

Hi Andrei, 1) is what most do (at least what we do at netstyle.ch for apps that can have higher loads). The following blog post is a nice writeup from Ramon Leon describing how to implement such a system: http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-pub… HTH, Adrian On May 24, 2010, at 20:47 , Mariano Martinez Peck wrote: > This is a good question. I don't have experience by myself but I can tell > you what I think it is usually done: > > 1) For one CPU: > > If the image don't need to be saved (no need of in image persistence) you > can take the same VM and load N number of images running at the same .image. > You can even not use .changes and .sources. Each image in different port. > Then, you have in front of them a web server (Apache or friends) and you do > load balance. The only thing you should take care with Seaside is to have > AFFINITY -> the same client should go always to the same image while a > conversation occurs. This is just a web-server setting. > > 2) For multiple core, I am thinking, maybe I am wrong, you may be able to > load different vms. For assigning each VM to a particular CPU. I don't know > windows, but in Linux (maybe I am wrong) I think you can specify where to > exclusively run a process. The, for each VM you do 1). > Do you know if this can work? > > Finally, there are different VM that aim not necessary multiple CPU but > similar: > > - COG VM > - Hydra > > I cc'ed may developers of them so that they can help you. > > Cheers > > Mariano > > > 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com> > >> I've been really impressed with what Seaside and Pier were capable of and >> really wanted to start my new web project with Pharo. >> I learned that Pharo (and most other open source ST implementations) only >> use green threads, having no ability to use a multi-core CPU systems. >> For those of you with experience building mid to heavy load web sites, how >> do you expect them to scale up on using just one core? >> Is Pharo a right tool for that? >> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my >> heart really sank when I learned about this issue... >> >> Thank you, >> Andrei >> >> _______________________________________________ >> 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

May 24, 2010

[Pharo-project] [update 1.1] #11371

by StÃ©phane Ducasse

11371 ----- - Issue 1281: Button in TestRunner to fileout the test results. Thanks Laurent. - Issue 2468: Better method trailer method creation. Part One. Thanks Igor. - Issue 2406: MovieMorph should be removed from the core. Thanks Alain. - Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks Laurent - Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks Guillermo. Stef

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Lukas Renggli

> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the > moment, so that should be preferred in core packages. It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants. > 1 just looks bad, I can't imagine an OODB that doesn't map it's "null > object" directly to nil, otherwise #= will be asymmetric: > null = nil -> true > nil = null -> false That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

On Mon, 24 May 2010, Lukas Renggli wrote: >> For now the list of levente and a slow machine >> >> Â Â Â Â "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." >> is the one to use > > Please read my comments on the issue tracker. > > For *any practical* example it doesn't matter what to use speed wise: That's not true. Most of the time it doesn't matter, but when these checks/conditional statements are in tight loops they can make a huge difference. Core packages have some good code examples and those have to be fast, but not cross-dialect. I'm sure other smalltalks are implemented this way. > > 1 = nil ifTrue: [ ] > 2 == nil ifTrue: [ ] > 3 isNil ifTrue: [ ] > 4 ifNil: [ ] IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages. 2 is cross-dialect and it's probably the fastest in all dialects, so if I were writing cross-dialect code then I'd probably use that. 3 looks nice and #isNil is inlined in some dialects (AFAIK), but it's "slow" in Squeak/Pharo. 1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false Btw I hope we will have an inlining JIT soon which can decrease/eliminate these performance differences. Levente > > Personally I find 3 the most readable. 1 and 3 are the only practical > ones if you use OODBs, because they are not shortcut by the compiler. > > I only use 4 for lazy initializers, it makes a good pattern. The use > of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable > if you don't care about compatibility with other Smalltalk dialects. > > Lukas > > -- > Lukas Renggli > 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 >

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by Igor Stasenko

On 24 May 2010 21:47, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > This is a good question. I don't have experience by myself but I can tell > you what I think it is usually done: > > 1) For one CPU: > > If the image don't need to be saved (no need of in image persistence) you > can take the same VM and load N number of images running at the same .image. > You can even not use .changes and .sources. Each image in different port. > Then, you have in front of them a web server (Apache or friends) and you do > load balance. The only thing you should take care with Seaside is to have > AFFINITY -> the same client should go always to the same image while a > conversation occurs. This is just a web-server setting. > > 2) For multiple core, I am thinking, maybe I am wrong, you may be able to > load different vms. For assigning each VM to a particular CPU. I don't know > windows, but in Linux (maybe I am wrong) I think you can specify where to > exclusively run a process. The, for each VM you do 1). > Do you know if this can work? > 3) write a good code, so it could handle things well without need of so much horsepower :) > Finally, there are different VM that aim not necessary multiple CPU but > similar: > > - COG VM > - Hydra > > I cc'ed may developers of them so that they can help you. > > Cheers > > Mariano > > > 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com> >> >> I've been really impressed with what Seaside and Pier were capable of and >> really wanted to start my new web project with Pharo. >> I learned that Pharo (and most other open source ST implementations) only >> use green threads, having no ability to use a multi-core CPU systems. >> For those of you with experience building mid to heavy load web sites, how >> do you expect them to scale up on using just one core? >> Is Pharo a right tool for that? >> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my >> heart really sank when I learned about this issue... >> Thank you, >> Andrei >> _______________________________________________ >> 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.

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 22:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Ok. Let me start. > > Excellent I want to learn. > And I will ask cyrille to read all that. > The first things is that we should get Rome working then we fix the api. > > >> Rome/Athens adds variouls extension methods to classes which are >> involved with graphics. >> Here is one of them: >> >> GradientFillStyle>>installOnRomePluginCanvas: aCanvas >> Â Â Â | colorStops i | >> Â Â Â colorStops := WordArray new: colorRamp size * 3. >> Â Â Â i := 0. >> Â Â Â colorRamp do: [:stop | >> Â Â Â Â Â Â Â colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. >> Â Â Â Â Â Â Â colorStops at: (i:=i+1) put: stop value privateRGB. >> Â Â Â Â Â Â Â colorStops at: (i:=i+1) put: stop value privateAlpha]. >> Â Â Â radial == true >> Â Â Â Â Â Â Â ifTrue: [ >> Â Â Â Â Â Â Â Â Â Â Â aCanvas primFillRadialGradientOriginX: origin x asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â y: origin y asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â directionX: direction x asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â y: direction y asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â normalX: self normal x asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â y: self normal y asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â colorStops: colorStops] >> Â Â Â Â Â Â Â ifFalse: [ >> Â Â Â Â Â Â Â Â Â Â Â aCanvas primFillLinearGradientOriginX: origin x asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â y: origin y asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â directionX: direction x asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â y: direction y asFloat >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â colorStops: colorStops] >> >> Good: >> - a conversion method is context sensitive (it takes a canvas as an argument) >> Bad: >> - this conversion method will work only for Rome plugin and nothing else. > > how to you see that? > Well, consider this: colorRamp do: [:stop | colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. colorStops at: (i:=i+1) put: stop value privateRGB. colorStops at: (i:=i+1) put: stop value privateAlpha]. most likely, this will be inappropriate for anything else than RomePlugin. While, of course each kind of canvas could implement own #primFillLinearGradientOriginX: y:directionX: y: colorStops: except that it should not be a prim, and then it will waste time converting color stops again - into a form, which fits best for its own needs. So, why using 2 conversions, where 1 is enough? :) In same way, #asFloat may be not necessary, because canvas could accept integers as well as floats, so converting everything to floats is just a waste of time. > >> This means, that if i'd want to use different canvas, i will need to >> add another method >> which will perform a conversion. > > you lost me there. But I ;m sure that you will explain it to me :) > I meant that i would need to add the GradientFillStyle>>installOnRomeGLCanvas: aCanvas instead of reusing the code. > >> But this can be avoided, if we provide a generic canvas method to >> create a gradient fills. >> Then this method could be renamed to #installOnRomeCanvas: >> and implementation will consist of messages, sent to canvas to build a >> gradient fill. > > do you have a sketch that I follow the example 100% > GradientFillStyle>>installOnRomeCanvas: aCanvas ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas gradientFill: #linear origin: ... colors: ... ] and generally, a persistent resources (or ones which may change, but rarely) could use a following pattern: Something>>installOnRomeCanvas: aCanvas self isChanged ifTrue: [ aCanvas invalidateCache: self ]. ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas createSomething: ... ] Then, after heating-up, it will run at maximum efficiency by using a cached (and already converted resources) instead of performing conversions each time. >> Another example: >> >> asRomeFill , asRomeFont >> >> - this is bad. >> Its not a context-sensitive. And therefore , an implementation of >> these methods assumes that it will provide >> the most suitable conversion of fill or font for Rome backend. >> But depending on backend, it may not be the case! >> So, all methods like this, should always use a canvas as argument and >> talk back to canvas >> to perform a conversion. > > I see we need a factory and the canvas will play this role. > Yes. > Stef >> >>> Stef >>> >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] cant remove accept: method

by Sean Allen

Sorry. I see that just plain old 'remove method' works, just not from refactoring menu. On Mon, May 24, 2010 at 3:27 PM, Sean Allen <sean(a)monkeysnatchbanana.com> wrote: > Pharo 1.0 > > I have a class that has a method accept: that is no longer used. > > When I go to remove it, I get the message: > > Possible call to accept: in XXXX Browse? > > If you do no, it doesn't remove the method. > If you do yes, you can only browse, not remove. > > How can I remove the method short of filing out the class, removing the method > and filing the class back in? >

May 24, 2010

[Pharo-project] I need another pair of eyes to look at: super look in debugger

by stephane ducasse

http://code.google.com/p/pharo/issues/detail?id=2446 Stef

May 24, 2010