[Pharo-project] PetitParser + Amber
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
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@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
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@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@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)
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@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
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
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
participants (6)
-
Alexandre Bergel -
Frank Shearar -
Göran Krampe -
Lukas Renggli -
Nicolas Petton -
Noury Bouraqadi