November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

by Eliot Miranda

Hi Thierry, > On Nov 14, 2016, at 7:04 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Has anybody seen performance differences between the 32bits and the 64bits versions of Pharo 6 ? > > I'm seeing a speedup greater than 2 on some intensive numerical code. > > Note that, on that code, Pharo 64bits is slower than R, by around 30%. The code overall is memory bound. Can you post (a pointer to?) the R & Pharo code you're comparing? TIA > > Thierry > >

Nov. 14, 2016

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

by Thierry Goubier

2016-11-14 16:24 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi Thierry, > > On the speed center you can compare 32 bits and 64 bits linux VMs: > http://squeak.org/codespeed/ > > Interesting to see the rsqueak results on that type of benchs. Mandelbrot would be the closest. > > Normally Pharo 64 should be overall slightly slower than Pharo 32 because > 70% of the memory is used for pointers, implying twice more data to process > by the processor for pointer operations. Specific things, for example > SmallFloat arithmetic, should however be faster on 64 bits. > Yes, then it is a lot faster. > > For numerical code, benchs can be faster for two main reasons: > - the bench uses SmallFloat instead of BoxedFloat for most floats it uses > in 64 bits > - the bench overflows the 31bits signed integer range for SmallIntegers, > leading to the usage of LargeInteger in 32 bits, while it does not overflow > the 61 bits signed integer range in 64 bits. This is typically the case for > int32 benchs. > > Other numerical benchs may be faster on 32 bits. > > > On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Has anybody seen performance differences between the 32bits and the >> 64bits versions of Pharo 6 ? >> >> I'm seeing a speedup greater than 2 on some intensive numerical code. >> >> Note that, on that code, Pharo 64bits is slower than R, by around 30%. >> The code overall is memory bound. >> >> Thierry >> >> >> > Thierry

Nov. 14, 2016

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

by ClÃ©ment Bera

Hi Thierry, On the speed center you can compare 32 bits and 64 bits linux VMs: http://squeak.org/codespeed/ Normally Pharo 64 should be overall slightly slower than Pharo 32 because 70% of the memory is used for pointers, implying twice more data to process by the processor for pointer operations. Specific things, for example SmallFloat arithmetic, should however be faster on 64 bits. For numerical code, benchs can be faster for two main reasons: - the bench uses SmallFloat instead of BoxedFloat for most floats it uses in 64 bits - the bench overflows the 31bits signed integer range for SmallIntegers, leading to the usage of LargeInteger in 32 bits, while it does not overflow the 61 bits signed integer range in 64 bits. This is typically the case for int32 benchs. Other numerical benchs may be faster on 32 bits. On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Has anybody seen performance differences between the 32bits and the 64bits > versions of Pharo 6 ? > > I'm seeing a speedup greater than 2 on some intensive numerical code. > > Note that, on that code, Pharo 64bits is slower than R, by around 30%. The > code overall is memory bound. > > Thierry > > >

Nov. 14, 2016

Performance difference between Pharo 32bits and 64bits

by Thierry Goubier

Has anybody seen performance differences between the 32bits and the 64bits versions of Pharo 6 ? I'm seeing a speedup greater than 2 on some intensive numerical code. Note that, on that code, Pharo 64bits is slower than R, by around 30%. The code overall is memory bound. Thierry

Nov. 14, 2016

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

by Brad

I vote for the NumberFormatter. It adds another layer, which can be a pain, but gives you much more flexibility. Plus it decouples the formatting from all of the number classes. VA Smalltalk has something like this. Brad Selfridge 913-269-2385 > On Nov 14, 2016, at 8:38 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am voting against because both methods are very similar while we are trying to clean. > > Also, if I would have to present a number I would personally always prefer the .00 for uniformity. > > But I understand what you want. I think a NumberFormatter object would be better -- what about thousands separators, negative and/or positive sign, different scientific notations, ... ? > > Anyway, just my opinion. > >> On 14 Nov 2016, at 14:56, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> >> Hi! >> >> I have a problem in an application, I need to print some numbers with 2 >> decimals max. The numbers can be an Integer, Float or Fraction. I >> checked and found Number>>#printShowingDecimalPlaces:. This is cool but >> this is not what I want because when I get "10", I want to print "10" >> and not "10.00". >> >> So I created a method Number>>#printShowingMaxDecimalPlaces: to do so. >> At first I made a mistake and I was not the only one. To avoid this kind >> of mistakes I think this method should be in Pharo by default. This is >> really useful when building a GUI. >> >> This method already exists in Squeak. >> >> I want to ask to the list, do you think this method should make it in >> the image? I think this is important but I also know that people do not >> want to have too much things in the kernel. >> >> So, do you think this is important enough or not? >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> > >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Esteban A. Maringolo

2016-11-14 11:50 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >> Breaking Metacello in any version = Not good. >> >> Metacello is very backward compatible but breaking pragma semantics >> would require a rewrite of many configurations that work okay today > Why? ConfigurationOf~ not collect any pragmas by themselves. They only > declare versions by pragmas. You're right. > And we only need to fix Pharo version of Metacello which is already fork. Which is not there yet. Quoting myself: "... and would require a new version of Metacello that contemplates the new selectors based on some criteria." Criteria being pharo version, or anything else that identifies the new pragma semantics. Regards!

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Denis Kudriashov

2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Breaking Metacello in any version = Not good. > > Metacello is very backward compatible but breaking pragma semantics > would require a rewrite of many configurations that work okay today > Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.

Nov. 14, 2016

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

by Sven Van Caekenberghe

I am voting against because both methods are very similar while we are trying to clean. Also, if I would have to present a number I would personally always prefer the .00 for uniformity. But I understand what you want. I think a NumberFormatter object would be better -- what about thousands separators, negative and/or positive sign, different scientific notations, ... ? Anyway, just my opinion. > On 14 Nov 2016, at 14:56, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi! > > I have a problem in an application, I need to print some numbers with 2 > decimals max. The numbers can be an Integer, Float or Fraction. I > checked and found Number>>#printShowingDecimalPlaces:. This is cool but > this is not what I want because when I get "10", I want to print "10" > and not "10.00". > > So I created a method Number>>#printShowingMaxDecimalPlaces: to do so. > At first I made a mistake and I was not the only one. To avoid this kind > of mistakes I think this method should be in Pharo by default. This is > really useful when building a GUI. > > This method already exists in Squeak. > > I want to ask to the list, do you think this method should make it in > the image? I think this is important but I also know that people do not > want to have too much things in the kernel. > > So, do you think this is important enough or not? > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Esteban A. Maringolo

2016-11-14 11:27 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Breaking Metacello in Pharo 6: Not good. Revert: +1 Breaking Metacello in any version = Not good. Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today and would require a new version of Metacello that contemplates the new selectors based on some criteria. Regards! Esteban A. Maringolo

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by phil＠highoctane.be

Breaking Metacello in Pharo 6: Not good. Revert: +1 On Mon, Nov 14, 2016 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > we need to revert. > this is a huge mess in a very inappropriate moment :) > > Esteban > > > On 14 Nov 2016, at 13:56, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > Indeed, I forgot that #selector is doing something else. This is a bit > of a mess. Either we revert it today, or we leave it. Otherwise, more > projects will adopt the new API only to break again afterwards. > > > > Doru > > > >> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> > >> On 14/11/2016 13:44, Tudor Girba wrote: > >>> Hi, > >>> > >>> Please do not revert the API. Just comment out the deprecation. The > code in Moose was already updated to the new API and I presume other > projects might be in the same situation. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Be rather willing to give than demanding to get." > >>> > >>> > >>> > >> > >> Changing the API without a deprecation phase is bad. This kind of > >> breaking change without warning is something companies can fear. This is > >> even more important when there is such a dangerous change. #selector is > >> still here but do something differentâ¦ This is bad to just change it in > >> one go. > >> > >> Maybe some projects updated but most companies do not follow the > >> development version of Pharo. > >> > >> -- > >> Cyril Ferlicot > >> > >> http://www.synectique.eu > >> > >> 2 rue Jacques PrÃ©vert 01, > >> 59650 Villeneuve d'ascq France > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "It's not how it is, it is how we see it." > > > > > > >

Nov. 14, 2016