a6d7835420
preparatory to producing a properly structured index
105 lines
5.2 KiB
Markdown
105 lines
5.2 KiB
Markdown
---
|
|
title: Scripting
|
|
...
|
|
|
|
Initially we intend to implement human to human secret messaging, with
|
|
money that can be transferred in the message, and the capability to make
|
|
messages public and provably linked with an identity
|
|
|
|
But obviously we are eventually going to need bot responses, and bot
|
|
scripts that can interact with the recipient within a sandbox. Not wanting
|
|
to repeat the mistakes of the internet, we will want the same bot language
|
|
generating responses, and interacting with the recipient.
|
|
|
|
There is a [list](https://github.com/dbohdan/embedded-scripting-languages){target="_blank"} of embeddable scripting languages.
|
|
|
|
Lua and python are readily embeddable, but [the language shootout](https://benchmarksgame-team.pages.debian.net/benchmarksgame/) tells us
|
|
they are terribly slow.
|
|
|
|
[Embedding LuaJIT in 30 minutes]:https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-minutes-or-so/
|
|
{target="_blank"}
|
|
|
|
|
|
Lua, however, has `LuaJIT`, which is about ten times faster than `Lua`, which
|
|
makes it only about four or five times slower than JavaScript under
|
|
`node.js`. It is highly portable, though I get the feeling that porting it to
|
|
windows is going to be a pain, but then it is never going to be expected to
|
|
call the windows file and gui operations.
|
|
|
|
Other people say it is faster than JavaScript, but avoid comparison
|
|
to Nodejs. But it is allegedly faster than any JavaScript I am likely to
|
|
be able to embed.
|
|
|
|
[Embedding LuaJIT in 30 minutes] gives as its example code a DNS
|
|
server written in embedded LUA. Note that it is very easy to embed
|
|
LUAJIT in such a way that the operations run amazingly slow.
|
|
|
|
Web application firewall that is used by Cloudfare was rewritten from
|
|
37000 lines of C to 2000 lines of lua. And it handles requests in
|
|
2ms. But it needed profiling and all that to find the slowdown
|
|
gotchas - everyone who uses LUA JIT winds up spending some time and
|
|
effort to avoid horrible pointless slow operations and they need
|
|
to know what they are doing.
|
|
|
|
He recommends embedded LUA JIT as easier to embed and
|
|
interface to C than straight LUA. Well, it would be easier for
|
|
someone who has an good understanding of what is happening
|
|
under the hood.
|
|
|
|
He also addresses sandboxing. Seems that LUA JIT sandboxes just
|
|
fine (unlike Javascript).
|
|
|
|
Checking his links, it seems that embedded LUA JIT is widely used in
|
|
many important applications that need to be fast and have a great
|
|
deal of money behind them.
|
|
|
|
LUA JIT is not available on the computer benchmarks shootout. The
|
|
JIT people say the shootout maintainer is being hostile and difficult,
|
|
the shootout maintainer is kind of apt to change the subject and
|
|
imply the JIT people are not getting off their asses, but I can see
|
|
they have done a decent amount of work to get their stuff included.
|
|
|
|
LUA JIT is a significantly different dialect to LUA, and tends to get
|
|
rather different idioms as a result of profiling driven optimization.
|
|
|
|
It looks like common LUA idioms are apt to bite in LUA JIT for
|
|
reasons that are not easy to intuit. Thus there is in effect some hand
|
|
precompiling for LUA JIT.
|
|
|
|
Anecdotal data on speed for LUA JIT:
|
|
|
|
* lua-JIT is faster than Java-with-JIT (the sun Java), lua-JIT is faster than V8 (Javascript-with-JIT), etc, ...
|
|
|
|
* As Justin Cormack notes in the comments to the answer below, it is crucial to remark that JITed calls to native C functions (rather than lua_CFunctions) are extremely fast (zero overhead) when using the LuaJIT ffi. That's a double win: you don't have to write bindings anymore, and you get on-the-metal performance. Using LJ to call into a C library can yield spooky-fast performance even when doing heavy work on the Lua side.
|
|
|
|
* I am personally surprised at luajit's performance. We use it in the network space, and its performance is outstanding. I had used it in the past is a different manner, and its performance was 'ok'. Implementation architecture really is important with this framework. You can get C perf, with minimal effort. There are limitations, but we have worked around all of them now. Highly recommended.
|
|
|
|
Lisp is sort of embeddable, startlingly fast, and is enormously capable, but
|
|
it is huge, and not all that portable.
|
|
|
|
ES (JavaScript) is impressively fast in its node.js implementation, which does
|
|
not necessarily imply the embeddable versions are fast.
|
|
|
|
Very few of the scripting languages make promises about sandbox
|
|
capability, and I know there is enormous grief over sandboxing JavaScript.
|
|
It can be done, but it is a big project.
|
|
|
|
Angelscript *does* make promises about sandbox capability, but I have
|
|
absolutely no information its capability and performance.
|
|
|
|
Tcl is event loop oriented.
|
|
|
|
But hell, I have an event loop. I want my events to put data in memory,
|
|
then launch a script for the event, the script does something with the data,
|
|
generates some new data, fires some events that will make use of the data, and
|
|
finishes.
|
|
|
|
Given that I want programs to be short and quickly terminate, maybe we
|
|
do not need dynamic memory management and garbage collection.
|
|
|
|
Lua is slowed by dynamic memory management. But with event
|
|
orientation, dynamic memory management is complete waste, since your
|
|
only memory management is allocating continuation objects to be fired on
|
|
the next event - which is to say, all memory management is explicit, when
|
|
an event handler detaches.
|