- Pharo-dev - lists.pharo.org

[Pharo-project] Clamato vs Amber (was Re: PetitParser + Amber)

by Noury Bouraqadi

I saw it few years ago as a news in a mailing list (squeak-dev). I don't remeber any presentation at a Smalltatalk conference. I don't know what is the status, though I imagine it is discontinued. @Nicolas, I wonder what is the difference with Amber. Noury On 14 sept. 2011, at 13:39, Alexandre Bergel wrote: > First time I hear about http://clamato.net/ > > Alexandre > > > On 14 Sep 2011, at 06:44, Lukas Renggli wrote: > >> Hi Frank, >> >> Likely this has nothing to do with PetitParser. >> >> From my understanding: In Clamato the parser was running at the >> language level (Smalltalk). JTalk introduced a dead-slow method lookup >> and as a consequence they optimize the parser by moving it to the >> implementation level (a JavaScript primitive). >> >> Lukas >> >> On 14 September 2011 09:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> Hi GÃ¶ran, >>> >>> Quick question: during your work on Amber, did you find any >>> particularly slow parts of PetitParser? >>> >>> Or, rephrased: while a hand-written parser is pretty much guaranteed >>> to run faster than PetitParser (or any general parser generator, I >>> reckon), are there any parts of PetitParser that leap out as being >>> ripe for optimisation? >>> >>> Thanks, >>> >>> frank >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury http://twitter.com/#!/NouryBouraqadi -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

Sept. 14, 2011

Re: [Pharo-project] PetitParser + Amber

by Nicolas Petton

On Wed, 2011-09-14 at 11:44 +0200, Lukas Renggli wrote: > Hi Frank, > > Likely this has nothing to do with PetitParser. > > From my understanding: In Clamato the parser was running at the > language level (Smalltalk). JTalk introduced a dead-slow method lookup > and as a consequence they optimize the parser by moving it to the > implementation level (a JavaScript primitive). As GÃ¶ran explained, the lookup wasn't really the issue. Compiling a method using PetitParser was (and would still be) fast enough to not notice the difference, and that's what you do most of the time using the class browser. But then doing a full "make" has always been awefully slow. The new parser fixes that. The lookup slowed down Amber by 30-40% but at the same time we introduced compiler optimizations doing inlinings. Here's tinyBenchmarks results from before the lookup: '2253521.1267605633 bytecodes/sec; 129005.9582919563 sends/sec' And now with Amber 0.9: '4173187.271778821 bytecodes/sec; 90916.66666666667 sends/sec' Cheers, Nico > > Lukas > > On 14 September 2011 09:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > Hi GÃ¶ran, > > > > Quick question: during your work on Amber, did you find any > > particularly slow parts of PetitParser? > > > > Or, rephrased: while a hand-written parser is pretty much guaranteed > > to run faster than PetitParser (or any general parser generator, I > > reckon), are there any parts of PetitParser that leap out as being > > ripe for optimisation? > > > > Thanks, > > > > frank > > > > > > > -- Nicolas Petton http://www.nicolas-petton.fr

Sept. 14, 2011

Re: [Pharo-project] PetitParser + Amber

by GÃ¶ran Krampe

On 09/14/2011 01:42 PM, GÃ¶ran Krampe wrote: > We first tried to figure out what was happening, but we didn't succeed > and spent a lot of time on it. Then Nicolas decided to go "native" on > the problem. I rewrote ChunkParser - because it was also in PP and was > also going into endless chewing. Nicolas used PEGjs to produce a new > parser. > > Note that the AST and code emitting etc is still in Amber. And oh, I only rewrote the ChunkParser in Amber - not in raw js. And in fact, it came out simpler I would say - but chunk format is not that complicated (although a bit messy to get right). Btw, Nicolas just checked out an old Jtalk to see how much difference the "changed lookup" made - and for tinyBench it only took a ... 20% hit or something. Not a magnitude thing. (this is referring to what Lukas wrote in another post) We might need to investigate why the endless chewing came about though - because it indicates some kind of bug somewhere I think, probably in Amber itself, or in the PP port. regards, GÃ¶ran

Sept. 14, 2011

[Pharo-project] PetitParser + Amber

by Torsten Bergmann

GÃ¶ran wrote: >Amber is pretty slow compared to raw js Let's see what Dart provides compared to js ... and if its Smalltalk/Amber like (see [1] and [2]) Bye T. [1] http://astares.blogspot.com/2011/09/one-month-until-dart-is-released.html [2] http://astares.blogspot.com/2011/09/more-rumors-on-dart-and-smalltalk.html -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Sept. 14, 2011

Re: [Pharo-project] PetitParser + Amber

by GÃ¶ran Krampe

On 09/14/2011 09:30 AM, Frank Shearar wrote: > Hi GÃ¶ran, > > Quick question: during your work on Amber, did you find any > particularly slow parts of PetitParser? I really didn't dissect it to know, but see below. > Or, rephrased: while a hand-written parser is pretty much guaranteed > to run faster than PetitParser (or any general parser generator, I > reckon), are there any parts of PetitParser that leap out as being > ripe for optimisation? Amber is pretty slow compared to raw js. Now, the parsing stage of compilation is ... well, it seems to be at least 90% of the time. So, even before we added DNU support a full recompilation of whole Amber took about 1 hour. On a corei7. :) We started contemplating rewriting it in js (again - the first parser was also in js according to Nicolas), but it was actually later when we experienced really odd behavior - PP endlessly chewing and never finishing - we caved. We first tried to figure out what was happening, but we didn't succeed and spent a lot of time on it. Then Nicolas decided to go "native" on the problem. I rewrote ChunkParser - because it was also in PP and was also going into endless chewing. Nicolas used PEGjs to produce a new parser. Note that the AST and code emitting etc is still in Amber. Now, exactly why this happened is hard to know. But the primary problem here is that Jtalk is still a magnitude slower than raw js (not a problem most of the time) and this hurts the user experience. It didn't hurt that much when we were only parsing one method at a time. Then we created amberc (jtalkc) and the problem became clear. Now, the changelog says "100x" faster. That is actually not just a game with words - it is an estimation. We went from approximately 1 hour to 25 seconds. So 100 is actually on the low side :) Also, note that the problem was there from the beginning - it was not created by modified lookup - although the "endless chewing" might have been. regards, GÃ¶ran

Sept. 14, 2011

Re: [Pharo-project] PetitParser + Amber

by Alexandre Bergel

First time I hear about http://clamato.net/ Alexandre On 14 Sep 2011, at 06:44, Lukas Renggli wrote: > Hi Frank, > > Likely this has nothing to do with PetitParser. > > From my understanding: In Clamato the parser was running at the > language level (Smalltalk). JTalk introduced a dead-slow method lookup > and as a consequence they optimize the parser by moving it to the > implementation level (a JavaScript primitive). > > Lukas > > On 14 September 2011 09:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> Hi GÃ¶ran, >> >> Quick question: during your work on Amber, did you find any >> particularly slow parts of PetitParser? >> >> Or, rephrased: while a hand-written parser is pretty much guaranteed >> to run faster than PetitParser (or any general parser generator, I >> reckon), are there any parts of PetitParser that leap out as being >> ripe for optimisation? >> >> Thanks, >> >> frank >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Alexandre Bergel

http://code.google.com/p/pharo/issues/detail?id=4798 A slice is in the inbox Alexandre On 14 Sep 2011, at 08:20, Igor Stasenko wrote: > On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Apparently, the following method is abstract: >> >> ArrayedCollection>>add: newObject >> self shouldNotImplement >> >> If I evaluate: >> (ArrayedCollection>>#add:) isAbstract => true >> >> This is not quite right. A method that is cancelled is not abstract. >> >> I propose to change >> CompiledMethod>>abstractMarkers >> ^ #(subclassResponsibility shouldNotImplement) >> >> into >> CompiledMethod>>abstractMarker >> ^ #shouldNotImplement >> >> Does it make sense? >> > > yes > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 14, 2011

Re: [Pharo-project] What is an abstract method?

by Igor Stasenko

On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Apparently, the following method is abstract: > > ArrayedCollection>>add: newObject > Â Â Â Â self shouldNotImplement > > If I evaluate: > (ArrayedCollection>>#add:) isAbstract => true > > This is not quite right. A method that is cancelled is not abstract. > > I propose to change > CompiledMethod>>abstractMarkers > Â Â Â Â ^ #(subclassResponsibility shouldNotImplement) > > into > CompiledMethod>>abstractMarker > Â Â Â Â ^ #shouldNotImplement > > Does it make sense? > yes > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Best regards, Igor Stasenko.

Sept. 14, 2011

Re: [Pharo-project] PetitParser + Amber

by Lukas Renggli

Hi Frank, Likely this has nothing to do with PetitParser. >From my understanding: In Clamato the parser was running at the language level (Smalltalk). JTalk introduced a dead-slow method lookup and as a consequence they optimize the parser by moving it to the implementation level (a JavaScript primitive). Lukas On 14 September 2011 09:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Hi GÃ¶ran, > > Quick question: during your work on Amber, did you find any > particularly slow parts of PetitParser? > > Or, rephrased: while a hand-written parser is pretty much guaranteed > to run faster than PetitParser (or any general parser generator, I > reckon), are there any parts of PetitParser that leap out as being > ripe for optimisation? > > Thanks, > > frank > > -- Lukas Renggli www.lukas-renggli.ch

Sept. 14, 2011

[Pharo-project] [update 1.4] #14140

by Marcus Denker

14140 ----- Issue 4796: Fix ClassSearch http://code.google.com/p/pharo/issues/detail?id=4796 Issue 4794: New method in AbstractTool http://code.google.com/p/pharo/issues/detail?id=4794 Issue 4789: Improve the way morphs communicate with model http://code.google.com/p/pharo/issues/detail?id=4789 -- Marcus Denker -- http://marcusdenker.de

Sept. 14, 2011