New Batteries? (Was: Dead Batteries)

[Stefan <ste@...>]

Am 05.01.2020 um 23:00 schrieb Dibyendu Majumdar:
> Well Python is arguably a better general purpose language and has a
> very powerful set of libraries. Why does the world need another one?
>
> Regards

[Warning: wall of text - jump to "What about Lua?" or "Conclusion" for a 
shortcut]

Python's insufficient thread support is a *big* disadvantage.
The GIL (Global Interpreter Lock) basically combines the 
unpredictability of preemptive multithreading with the low performance 
of cooperative multithreading and is only useful for some I/O tasks[1].

Making Python and all of its libraries ready for "real" multithreading 
is a lot of work and the Python community hasn't done this yet.

But soon this will become very important!

Fast CPUs are a "solved problem" nowadays and we will probably only get 
more of them, more efficient and cheaper ones and specialized hardware 
but no longer faster cores[2].
This trend has already started - AMD produces mobile CPUs with 8 cores 
at 15W[3] and Intel will certainly not sit still.
Maybe 8 cores for laptops and 16 cores for PCs will be the default in 
less than five years...

OTOH data production/transport/storage technology is *still* improving 
at an unbelievable pace[4][5] (excerpt: new technology will help 500 
million Indians to join the internet).
With most users possessing only dual-core machines (today), not having 
actual multicore support wasn't that bad. But with 8/16/32/special 
cores? And a lot more data to process?

Even the CPU architects are concerned about this[6, page 35/36].

Unfortunately weak typing and multithreading doesn't mix well and 
multithreading in general has many pitfalls.
Jython/JRuby use the JVM to take advantage of its sophisticated runtime. 
But a threaded garbage collector and per-object locking seem to be 
anything but trivial and the JVM is a memory-hogging behemoth.
JavaScript doesn't allow shared context at all and WebWorkers basically 
provide processes with bolted-on message passing.
PHP seems to allow threading without actually being thread-safe... 
solves the problem by ignoring it ;)
About others I'm not sure.

What about Lua?

Making the language itself multithreaded is obviously not going to 
happen. But creating many independent Lua states that are executed by 
multiple threads is easy!

While starting hundreds or thousands of threads is not a good idea, 
having more independent program contexts than cores is very useful:
- map one network connection to one Lua state, i.e. application servers
- one state per user for multiuser applications
- one state per view for GUI programs
- process a directory recursively and have a state per directory
- for divide-and-conquer strategies in general
- partitioning of complex programs

Compared to various other scripting languanges Lua has by far the 
fastest startup time by at least an order of magnitude. Btw check out 
`strace ruby -e "puts 'hello world'" 2>&1 | wc -l`, Ruby 2.5 needs
1790 syscalls for "hello world" (yes I know this example is unfair :))

For Lua, one of my i5230M cores can create 100K states + load a 
precompiled script in *one second*. On x86_64 they use up ~700MB RAM 
afterwards.

Unfortunately the reason why this is so fast is that the lua_States are 
basically empty. Loading just the standard library slows it down by a 
factor of 10.

So, a theoretical future feature-rich standard library should support:
- lazy binding/loading so that adding more functions doesn't impede 
state creation
- thread safety or awareness of its functions (one C function could be 
called by multiple Lua states in parallel)
- communication/synchronization between states
- offloading of blocking calls into separate threads
- some kind of compatibility header/subset of the C API so that minor 
changes in the language don't break existing library sources

Conclusion:
- It's 2020, a useful standard library must support real threading
- And Lua states are handy since they provide separate contexts without 
giving up the user-friendly cooperative model

It has always bummed me out that there is no agreed-on bigger standard 
library for Lua that is not directly meant for embedding. I mean it is 
also the perfect glue language, why isn't there anything ready to glue 
together?

There are probably many "invisible" Lua users that are some kiddos that 
mod their favourite game and sooner or later want to create "real" 
applications outside of the host game.

But they aren't full-blown programmers with an elaborate toolchain and a 
stack of reference books on their desks (yet ^^).
So they download some things from the internet, fiddle around a bit and 
then give up on Lua...

Providing them with a powerful and extensible, pre-compiled library 
would go a long way!

I think due to its simple and divisible nature Lua *could* be a general 
purpose scripting language of the future!

Best regards and a happy new year :)

[1] "Inside the Python GIL"
https://www.dabeaz.com/python/GIL.pdf
[2] "Trends in Processor Architecture"
https://arxiv.org/ftp/arxiv/papers/1801/1801.05215.pdf
[3] "Ryzen 7 4700U: AMD's First Ever 8-Core APU"
https://www.tomshardware.com/news/ryzen-7-4700u-amds-first-ever-8-core-apu
[4] "Ericsson Mobility Report November 2019"
https://www.ericsson.com/4acd7e/assets/local/mobility-report/documents/2019/emr-november-2019.pdf
[5] "Cisco Visual Networking Index: Forecast and Trends, 2017–2022"
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white-paper-c11-741490.pdf
[6] "A New Golden Age for Computer Architecture"
https://californiaconsultants.org/wp-content/uploads/2018/04/CNSV-1806-Patterson.pdf