I recently spent some time in the Lua section of the benchmarks game. It is a sad place for a few reasons:
- Lua programs cannot use shared memory concurrency or subprocesses with 2-way communication with the master process.
- Lua programs run on a very slow runtime compared to the fastest Lua runtime.
My impression after this is that for languages that aren't super fast and don't include all the primitives one could want, benchmarks like reverse-compliment are mainly measuring whether the language's standard library includes some C function that does the bulk of the work.
I would love it if Isaac included LuaJit and pypy in the benchmarks game, but ultimately I get it; it's just one guy's project, and he doesn't want to spend the time to maintain it across the entire incredible diversity of programming languages/implementations[1].
To a great extent any "language" benchmark (for languages that don't compile to efficient machine code) is certainly a benchmark of the language's standard library. I'm not sure there's a way around that reality. Are there external Lua libraries that allow shared-memory concurrency? If so, it's probably worth opening an issue asking whether those libraries could be allowed[2]; it might just be that nobody has submitted a program making use of Lua shared concurrency.
No, it does not mean that. I'll submit my multicore pfannkuchen-redux and reverse-compliment when I get around to it, and look at other problems after that.
The pfannkuchen-redux is just a bit hampered by uneven work sharing.
For reverse-compliment, it's a bit more trouble to work around the lack of 2-way communication. My implementation writes the entire input to stdout, then workers use fseek on stdout, which only works if you are piping the output of the command to a file. That is, it generates correct output if you run "lua blah.lua > out" but not if you run "lua blah.lua | cat > out" Additionally, since there's no pwrite and no way of getting a new open file description for stdout, I must cobble together a mutual exclusion mechanism to prevent workers from seeking while another worker tries to write.
A design objective of PUC-Rio Lua is to be pure ANSI C. I'm not certain, but my impression is that this imposes some unreasonable restrictions on the implementation. An additional design objective is to be small.
I think people don't usually write Lua programs intending to run them inside the binary you get when you build PUC-Rio Lua without any additional C libraries. Libraries like LPeg and lua-gumbo are Lua wrappers around C code. For C libraries that do not have Lua wrappers, people can more or less paste the preprocessed C header file into their Lua source file and use Luajit's FFI to use the library. This last approach is similar to how the Python regex program mentioned elsewhere in these comments works :). It's also common to use frameworks like Openresty or Love2d that provide the innards of some complex threaded program to user Lua code.
Outside of benchmark games and work, I'm working on some code that uses threads and channels, but the threads and channels are provided by liblove.
So I guess I can say, it has been addressed, but it won't be addressed in the standard library.
- Lua programs cannot use shared memory concurrency or subprocesses with 2-way communication with the master process.
- Lua programs run on a very slow runtime compared to the fastest Lua runtime.
My impression after this is that for languages that aren't super fast and don't include all the primitives one could want, benchmarks like reverse-compliment are mainly measuring whether the language's standard library includes some C function that does the bulk of the work.