- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo

by ClÃ©ment Bera

Hi, This is a lovely post. Thanks for posting about Smalltalk / Pharo / Squeak. 1. Why *exactly* does the override work (in 32bit images)? 2. What changed so that things are different in Squeak 5.1 64bit image (overrides partially work)? If I am correct your questions are exclusively for bitOr: and bitAnd:. I don't know what you are aware of and what you're not aware of, hence I am going to give you some details on how bitAnd: is executed (bitOr: is done exactly the same way), and hopefully there will be something you don't know yet that should help you understand what's going on. *Execution of bitAnd:* bitAnd: a special selector. If you run Smalltalk specialSelectors you get this array: #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) which includes bitAnd: . Special selectors are encoded in the bytecode differently to save memory, so they can be executed differently without inducing overhead. In Cog, bitAnd: is executed differently using type-prediction. In the Stack Interpreter, the execution of bitAnd: is done as follows: If both operands are SmallIntegers, push the bitAnd: value of the 2 SmallIntegers else Try the primitive BitAnd for SmallIntegers (14) on success push the result on failure perform the send. In the JIT, bitAnd: sends are compiled differently that normal send, the compilation logic is as follows: If both operands are SmallInteger literals compute the result during compilation and use this value else If one of the 2 operands is a SmallInteger literal generate 2 paths, a quick inlined path testing at runtime that the other operand is a SmallInteger, and if so, Ands the operands and use that result, else use the slow path performing a send else generate a normal send *Primitives* primitive 14 -> Works for SmallIntegers and LargePositiveInteger fitting in an unsigned machine word. (Slower than direct SmallInteger bitAnd performed by the special selector) primitive 34 -> Works for SmallIntegers and LargePositiveInteger fitting in an unsigned int64. (Slower than primitive 14 in 32 bits but covering more cases, equivalent in 64 bits) primDigitBitAnd (in Integer) -> Works for any integer. (Slower than the primitive 14 and 34) *SmallInteger encoding* In 32 bits, SmallIntegers are signed 31bits integer. In 64 bits, SmallIntegers are signed 61 bits integer. *Discussion* Let's make some assertions based on previous information: 1) If you have the exact same bitAnd: implementation for #bitAnd: and #bitAnd2:, #bitAnd2: is slower because it is not a special selector. 2) Still with the exact same bitAnd: implementation, using the JIT, things like that: 16r1 bitAnd: 1. "1 bits" 16r2 bitAnd: 2. "2 bit" 16r4 bitAnd: 4. "3 bit" 16r8 bitAnd: 3. "4 bit" Are bitAnd: operations between SmallInteger constants and the result is unused. Hence this whole portion of code does not generate any native instructions. On the other hand, things like that: 16r1 bitAnd2: 1. "1 bits" 16r2 bitAnd2: 2. "2 bit" 16r4 bitAnd2: 4. "3 bit" 16r8 bitAnd2: 3. "4 bit" Are sends, generating multiple native instructions including calls. 3) Because of the SmallInteger encoding, 16r200000000000000 bitAnd: 98490667780264321. "58 bit" is compiled by the JIT to nothing in 64 bits but to a send in 32 bits (the JIT can't solve LargeInteger arithmetic at compilation time). 4) primitive 34 provides some speed-up over primitive 14 in 32 bits, covering bitAnd: operations from unsigned 33 bits integer to unsigned 64 bits integer, but makes no difference in 64 bits. In 64bits all the cases covered by primitive 34 are covered by primitive 14, so it should even slow down things. *So...* Does this answer your questions ? Don't hesitate to ask further questions. If you want more details, I wrote something about special selectors a while ago: https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special… . Best, Clement PS1: If I'm correct, you referenced my blog a couple times, thank you for doing this, I really appreciate that. PS2: I enjoy chess myself, so if you have an open-source/MIT working algorithm at some point please send it to me, I will play against the AI and look at the code. On Fri, Feb 10, 2017 at 8:18 AM, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org>, "pharo-dev(a)lists.pharo.org" < > pharo-dev(a)lists.pharo.org> > Cc: > Date: Fri, 10 Feb 2017 07:18:02 +0000 (UTC) > Subject: Integer arithmetic and bit counting performance in Squeak and > Pharo > For those interested in performance of bit operations and integer > arithmetic in Squeak and Pharo : > > Bit operations in general : https://endormitoire.wordpress > .com/2017/02/10/bits-and-pieces/ > > Bit counting algorithms : https://endormitoire.wordpress > .com/2017/02/10/1001001-sos/ > > Some questions, some results, some answers... > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

Feb. 10, 2017

Re: [Pharo-dev] Slack, fragmentation and design information

by Esteban Lorenzano

Hi Stephan, > On 10 Feb 2017, at 10:27, Stephan Eggermont <stephan(a)stack.nl> wrote: > > The past year we have started using Slack to communicate in real-time about Pharo. It has nice (mobile) clients and makes it easy to share pictures and snippets. As a result a large part of the communication about design and how to do things has moved from the mailing lists to Slack. As we're using the free version, and cannot afford to use the commercial version, we have no long-time storage of the design discussions. This contrasts with our mailing lists, that have a long-term archive. There was some discussion about this, and I'm not aware of that resulting in an accessible, easy to access archive. Also, we have not succeeded in summarizing design discussions from slack to the mailing lists. The resulting gap in design information forms an enormous long-term risk for our community. Without the design discussions it is much more difficult to later understand why decisions were taken. We cannot afford to let this short-term ease-of-use destroy Pharo's community history, and thereby Pharo. Let us fix this. I share many of what you sayâ¦ but in the other point of view, Slack as really worked and there is a lot more happening now in Slack + mailing list than what was before just in mailing list. But most of that is lost because of Slack policies (also Slack pricing model is impossible for a community as ours), and we need to find a solution for that. Last days we were experimenting with @kilon again on use discord as a substitute and I find that for now it works really well and with a bit of work we can have all what you want: discord incorporated a search function (and they do not have the 10k limit) and we could do a bot that logs everything that happens there and stores that into gists (or whatever, but gists seems like a good idea). With this we would have enhanced the availability of those discussions (it remains the fact that immediate communication is worst organised than mails, but wellâ¦ we need to try) Esteban > > Stephan > >

Feb. 10, 2017

Slack, fragmentation and design information

by Stephan Eggermont

The past year we have started using Slack to communicate in real-time about Pharo. It has nice (mobile) clients and makes it easy to share pictures and snippets. As a result a large part of the communication about design and how to do things has moved from the mailing lists to Slack. As we're using the free version, and cannot afford to use the commercial version, we have no long-time storage of the design discussions. This contrasts with our mailing lists, that have a long-term archive. There was some discussion about this, and I'm not aware of that resulting in an accessible, easy to access archive. Also, we have not succeeded in summarizing design discussions from slack to the mailing lists. The resulting gap in design information forms an enormous long-term risk for our community. Without the design discussions it is much more difficult to later understand why decisions were taken. We cannot afford to let this short-term ease-of-use destroy Pharo's community history, and thereby Pharo. Let us fix this. Stephan

Feb. 10, 2017

[ANN] Prototype Fund for Free Software developers

by Hilaire

Hi, This support fund targets civil society oriented free software for Germany based developers. https://prototypefund.de/en/ Hilaire -- Dr. Geo http://drgeo.eu

Feb. 10, 2017

Integer arithmetic and bit counting performance in Squeak and Pharo

by Benoit St-Jean

For those interested in performance of bit operations and integer arithmetic in Squeak and Pharo : Bit operations in general : https://endormitoire.wordpress.com/2017/02/10/bits-and-pieces/ Bit counting algorithms : https://endormitoire.wordpress.com/2017/02/10/1001001-sos/ Some questions, some results, some answers...Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Feb. 10, 2017

Re: [Pharo-dev] Final rush for submitting GSOC proposal - Need your help

by Alexandre Bergel

Anyway, this is not the final list of projects. There will be a call on some point. We are at the stage to have Pharo accepted as a sponsored organization. The major difference between this proposal and what we have done in the past, is to have Pharo and not ESUG as the organization. We also highlighted the recent effort with the Mooc and the lectures in Africa and Bolivia. Letâs hope for the best! Alexandre > On Feb 9, 2017, at 2:06 PM, phil(a)highoctane.be wrote: > > I think that I send a couple topics before. > > On Thu, Feb 9, 2017 at 5:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Hi all, > > we are currently working with Alexandre to submit the gsoc proposal to Google. > I was a little bit busy with my lectures and I didn't check the > current proposals available here: > > http://gsoc.pharo.org/ > > but all the projects are coming from RMOD team, but having all the > projects proposal coming from the same place might be perceived > negatively from Google. Can we add more projects from previous gsoc > form other people also ? > > We have only one hour to polish the list. > Thank you for your help. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 9, 2017

Re: [Pharo-dev] Final rush for submitting GSOC proposal - Need your help

by serge.stinckwich＠gmail.com

Ok can you send me again your projects. I will integrate them. Try to put maximum 10-15 lines for description. EnvoyÃ© de mon iPhone > Le 9 fÃ©vr. 2017 Ã 18:06, "phil(a)highoctane.be" <phil(a)highoctane.be> a Ã©crit : > > I think that I send a couple topics before. > >> On Thu, Feb 9, 2017 at 5:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> Hi all, >> >> we are currently working with Alexandre to submit the gsoc proposal to Google. >> I was a little bit busy with my lectures and I didn't check the >> current proposals available here: >> >> http://gsoc.pharo.org/ >> >> but all the projects are coming from RMOD team, but having all the >> projects proposal coming from the same place might be perceived >> negatively from Google. Can we add more projects from previous gsoc >> form other people also ? >> >> We have only one hour to polish the list. >> Thank you for your help. >> >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> >

Feb. 9, 2017

Re: [Pharo-dev] Final rush for submitting GSOC proposal - Need your help

by phil＠highoctane.be

I think that I send a couple topics before. On Thu, Feb 9, 2017 at 5:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com > wrote: > Hi all, > > we are currently working with Alexandre to submit the gsoc proposal to > Google. > I was a little bit busy with my lectures and I didn't check the > current proposals available here: > > http://gsoc.pharo.org/ > > but all the projects are coming from RMOD team, but having all the > projects proposal coming from the same place might be perceived > negatively from Google. Can we add more projects from previous gsoc > form other people also ? > > We have only one hour to polish the list. > Thank you for your help. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Feb. 9, 2017

Re: [Pharo-dev] [Pharo-users] Final rush for submitting GSOC proposal - Need your help

by Serge Stinckwich

Yes, thank you Stephan. I just add them ;-) I think we can change the list of projects until tomorrow. Regards, On Thu, Feb 9, 2017 at 5:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 09/02/17 17:05, Serge Stinckwich wrote: >> >> but all the projects are coming from RMOD team, but having all the >> projects proposal coming from the same place might be perceived >> negatively from Google. Can we add more projects from previous gsoc >> from other people also ? > > > My two earlier proposals are fine, and already on the site. > > Stephan > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 9, 2017

Final rush for submitting GSOC proposal - Need your help

by Serge Stinckwich

Hi all, we are currently working with Alexandre to submit the gsoc proposal to Google. I was a little bit busy with my lectures and I didn't check the current proposals available here: http://gsoc.pharo.org/ but all the projects are coming from RMOD team, but having all the projects proposal coming from the same place might be perceived negatively from Google. Can we add more projects from previous gsoc form other people also ? We have only one hour to polish the list. Thank you for your help. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 9, 2017