2 ms·

> How much of the standard Lua test suit can your implementation pass? I haven't tried it yet, but I don't believe it would get very far since I haven't yet ex

> How much of the standard Lua test suit can your implementation pass? I haven't tried it yet, but I don't believe it would get very far since I haven't yet exposed ways to load Lua code from Lua modules (`dofile`, `load`, `require`, etc.). I've been building up my own test suite[1] while working through the reference manual[2]. I had never really used Lua before this, so it's been pretty interesting learning the language while implementing it. > Do you have some benchmarks to compare the speed? I've been using programs from the benchmarks game[3] and comparing them against regular Lua on my machine. On these programs, the overhead is usually somewhere around 2-3x. I believe that's mostly because these programs tend to be very mutation heavy. It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in. If you're curious, you can get it to print the code it generates for any given module by setting the `RACKET_LUA_DEBUG` env var to `x` before running some code. Eg: $ echo -e '#lang lua\nprint(1)' > test.lua $ env RACKET_LUA_DEBUG=x racket test.lua <<test.lua>> '((#%provide #%chunk) (#%define _ENV (#%global)) (#%load-stdlib! _ENV) (#%define (#%lua-module . #%rest) (#%begin (#%begin (print 1)) (#%values))) (#%define #%chunk (#%adjust (#%lua-module)))) 1 > What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases. Yup. I just haven't gotten around to it. My goal this week has been to get it to a usable spot for embedding in my app and then iterate from there. [1]: https://github.com/Bogdanp/racket-lua/tree/master/lua-test/lua/examples https://github.com/Bogdanp/racket-lua/tree/master/lua-test/l... [2]: https://www.lua.org/manual/5.4/manual.html https://www.lua.org/manual/5.4/manual.html [3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/

gus_massa 4y ago
> On these programs, the overhead is usually somewhere around 2-3x. Nice! > It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in. Part of the secret of the reimplementation Racket on top of Chez Scheme is that there are many macros pretending to be functions. The optimization pass inlines some of the functions, but sometimes the heuristic is not good enough, and you must cheat using a macro. (And sometimes the "obvious" improvements are wrong, and using a macro to force the expansion of the code has a worse result.) For example in https://github.com/Bogdanp/racket-lua/blob/master/lua-lib/private/arithmetic.rkt#L103-L111 https://github.com/Bogdanp/racket-lua/blob/master/lua-lib/pr... I'd try using a macro to inline the fast case where both numbers are exact integers, and then call a real function for the slow cases. (Is it common that someone wants to use 7.0 to do bit operations? Perhaps it's better to inline more. That's the tricky part, understanding which is the best split. I'm not sure. Probably only Matthew knows.)

gus_massa 4y ago

> On these programs, the overhead is usually somewhere around 2-3x. Nice! > It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in. Part of the secret of the reimplementation Racket on top of Chez Scheme is that there are many macros pretending to be functions. The optimization pass inlines some of the functions, but sometimes the heuristic is not good enough, and you must cheat using a macro. (And sometimes the "obvious" improvements are wrong, and using a macro to force the expansion of the code has a worse result.) For example in https://github.com/Bogdanp/racket-lua/blob/master/lua-lib/private/arithmetic.rkt#L103-L111 https://github.com/Bogdanp/racket-lua/blob/master/lua-lib/pr... I'd try using a macro to inline the fast case where both numbers are exact integers, and then call a real function for the slow cases. (Is it common that someone wants to use 7.0 to do bit operations? Perhaps it's better to inline more. That's the tricky part, understanding which is the best split. I'm not sure. Probably only Matthew knows.)