Skip to content

Yoakke parser rewrite - #565

Closed
WhiteBlackGoose wants to merge 18 commits into
masterfrom
yoakke-parser-rewrite
Closed

Yoakke parser rewrite#565
WhiteBlackGoose wants to merge 18 commits into
masterfrom
yoakke-parser-rewrite

Conversation

@WhiteBlackGoose

Copy link
Copy Markdown
Member

No description provided.

@WhiteBlackGoose

Copy link
Copy Markdown
Member Author

186/251 parsing tests pass so far

@WhiteBlackGoose

Copy link
Copy Markdown
Member Author

222/239

@WhiteBlackGoose

Copy link
Copy Markdown
Member Author

232/239

@WhiteBlackGoose

Copy link
Copy Markdown
Member Author

Full report (first line - now, second one - how it was)

Method                Mean                              
ParseEasy             6,815,103 ns           
ParseEasy                38,910 ns              
                                        
ParseHard             88,204,656 ns          
ParseHard              4,391,397 ns           
                                        
SimplifyEasy          180,776 ns             
SimplifyEasy           70,517 ns              
                                        
SimplifyHard          4,622,871,968 ns       
SimplifyHard          4,880,437,739 ns       
                                        
Derivate              107,337 ns             
Derivate               48,712 ns              
                                        
SolveEasy             34,736,589 ns          
SolveEasy             34,993,516 ns          
                                        
SolveEasyMedium       212,730 ns             
SolveEasyMedium        83,940 ns              
                                        
SolveMedium           7,643,240 ns           
SolveMedium           2,560,370 ns           
                                        
SolveMediumHard       370,657,437 ns         
SolveMediumHard       378,002,345 ns         
                                        
SolveHard             3,267,480,539 ns       
SolveHard             3,408,514,454 ns       
                                        
EvalEasy              775 ns                 
EvalEasy                9 ns                   
                                        
CompileEasy           521,392 ns             
CompileEasy           384,260 ns             
                                        
CompileHard           1,189,803 ns           
CompileHard             966,155 ns             
                                        
RunEasy               38 ns                  
RunEasy               33 ns                  
                                        
RunMedium             338 ns                 
RunMedium             299 ns                 
                                        
RunHard               4,059 ns          
RunHard                 641 ns          

(huge performance regression 😢 )

@WhiteBlackGoose

Copy link
Copy Markdown
Member Author

We need to make Yoakke orders of magnitude more performant. Work happens here: LanguageDev/Yoakke#149.

Also I might need to optimize the transformers themselves.

@Rafael-SOWNet

Copy link
Copy Markdown
Collaborator

Closing the branch and keeping the proposal: the question is now #898, with the costs of ANTLR that motivated this written down and the objections against replacing it written down beside them.

Why the branch cannot be the vehicle, four years on:

  • It is against a directory layout that no longer exists. Every path in it is
    Sources/AngouriMath/AngouriMath/…; f0db3eef moved the library up a folder in January.
  • −7185 lines of it is the generated ANTLR output, which has been regenerated since against a newer
    ANTLR than the 4.8 jar this deletes; the repository is on antlr-4.13.1-complete.jar now.
  • The acceptance it needs did not exist when it was written. StringizeRoundTripTest now holds
    printing to being parsing's inverse across every node type, and 2.0 fixed several shapes that did not
    round-trip. Any replacement parser has to pass that, which is a much sharper target than the branch
    was aiming at — and a good thing for whoever picks it up.

So this is closed as needs-design rather than declined. #898 says what would make it decidable: whether
the round trip survives, whether the error messages actually improve, what it costs on the FromString
hot path, and whether Syntax.md can be generated from the new parser rather than maintained beside
it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants