Nathan Braswell e95feb9309 tiny perceus fix, but mostly wrote match+rb-tree f-expr/macro for newLisp and benchmarked it. kraken 5-15x faster than newlisp-rbtree-macro, 137x faster than newlisp-rbtree-fexpr. I was suprised at first that the macro and fexpr versions were so close at 8.7x (while interpreted kraken rbtree is 50,000x slower), but after thinking about it it makes sense - the Kraken version has slowdown exponential in the multiple levels of f-exprs ('match' is an fexpr, but then so is 'let' and 'and' and 'lambda'), whereas the newLisp f-expr runtime expands to fast builtins ('let', 'and', etc). And all that exponential f-expr slowdown gets compiled away in Kraken!

2022-07-06 02:34:48 -04:00

..

CMakeLists.txt

tiny perceus fix, but mostly wrote match+rb-tree f-expr/macro for newLisp and benchmarked it. kraken 5-15x faster than newlisp-rbtree-macro, 137x faster than newlisp-rbtree-fexpr. I was suprised at first that the macro and fexpr versions were so close at 8.7x (while interpreted kraken rbtree is 50,000x slower), but after thinking about it it makes sense - the Kraken version has slowdown exponential in the multiple levels of f-exprs ('match' is an fexpr, but then so is 'let' and 'and' and 'lambda'), whereas the newLisp f-expr runtime expands to fast builtins ('let', 'and', etc). And all that exponential f-expr slowdown gets compiled away in Kraken!

2022-07-06 02:34:48 -04:00

newlisp-builtin-rbtree.nl

tiny perceus fix, but mostly wrote match+rb-tree f-expr/macro for newLisp and benchmarked it. kraken 5-15x faster than newlisp-rbtree-macro, 137x faster than newlisp-rbtree-fexpr. I was suprised at first that the macro and fexpr versions were so close at 8.7x (while interpreted kraken rbtree is 50,000x slower), but after thinking about it it makes sense - the Kraken version has slowdown exponential in the multiple levels of f-exprs ('match' is an fexpr, but then so is 'let' and 'and' and 'lambda'), whereas the newLisp f-expr runtime expands to fast builtins ('let', 'and', etc). And all that exponential f-expr slowdown gets compiled away in Kraken!

2022-07-06 02:34:48 -04:00

newlisp-fib-let.nl

Add newLisp, our second interpreted lisp implementation that supports f-exprs today, (not in NixOS, but pretty easy to build, so inlined deriviation right in flake.nix). Implemented simple fib/fib-let test.

2022-07-03 00:50:00 -04:00

newlisp-fib.nl

Add newLisp, our second interpreted lisp implementation that supports f-exprs today, (not in NixOS, but pretty easy to build, so inlined deriviation right in flake.nix). Implemented simple fib/fib-let test.

2022-07-03 00:50:00 -04:00

newlisp-macro-rbtree.nl

tiny perceus fix, but mostly wrote match+rb-tree f-expr/macro for newLisp and benchmarked it. kraken 5-15x faster than newlisp-rbtree-macro, 137x faster than newlisp-rbtree-fexpr. I was suprised at first that the macro and fexpr versions were so close at 8.7x (while interpreted kraken rbtree is 50,000x slower), but after thinking about it it makes sense - the Kraken version has slowdown exponential in the multiple levels of f-exprs ('match' is an fexpr, but then so is 'let' and 'and' and 'lambda'), whereas the newLisp f-expr runtime expands to fast builtins ('let', 'and', etc). And all that exponential f-expr slowdown gets compiled away in Kraken!

2022-07-06 02:34:48 -04:00

newlisp-slow-fexpr-rbtree.nl

tiny perceus fix, but mostly wrote match+rb-tree f-expr/macro for newLisp and benchmarked it. kraken 5-15x faster than newlisp-rbtree-macro, 137x faster than newlisp-rbtree-fexpr. I was suprised at first that the macro and fexpr versions were so close at 8.7x (while interpreted kraken rbtree is 50,000x slower), but after thinking about it it makes sense - the Kraken version has slowdown exponential in the multiple levels of f-exprs ('match' is an fexpr, but then so is 'let' and 'and' and 'lambda'), whereas the newLisp f-expr runtime expands to fast builtins ('let', 'and', etc). And all that exponential f-expr slowdown gets compiled away in Kraken!

2022-07-06 02:34:48 -04:00