3 ms·

So..., What's a good alternative? One that's relatively straightforward to implement compared to the Python approach.

jerf 7y ago
In this very particular sense, almost anything else is better. Dynamic scripting languages that are intrinsically single threaded because they were single-threaded for the first 10-15 years of their lives, and it is virtually impossible to retrofit true threading all the way from their basic runtimes through all their libraries [1], are basically the pessimal case for this particular problem. This is not the whole story of the value of those languages. As the article even alludes to, at small loads or with lots of care this can be made to "work". But it is something that an engineer should know about them before picking them up and using a tool for something it isn't really good at. [1]: I add this caveat because I don't think there's anything about dynamic scripting languages that makes them intrinsically difficult to thread any moreso than any other category of language, it's just that by an accident of history, they all come to us from the 1990s personal computer world, and they all spent at least a decade cooking and setting and building libraries and communities and developer skillsets before a serious need for threading was even on the horizon.
- samatman 7y ago
  It's a good caveat, because Lua, in particular, has fully-reentrant functions. You can run a bunch of Lua_states cooperatively or on a threaded basis without problems. Everything the VM does, from the C side, receives a Lua_state as the first argument. It's intrinsically single-threaded, yes. But each instance is quite small and they stay out of each others way. Add coroutines and there's a lot you can safely do with Lua that's a real pain to accomplish with Python.
  - mhd 7y ago
    In the days of yore, I might've attempted to shoe-horn Tcl in such a situation. Decent event-loop for distributing tasks and (like Lua, but unlike Python/Ruby) more eager to escape to C for performance-sensitive tasks.
- oconnor663 7y ago
  > I don't think there's anything about dynamic scripting languages that makes them intrinsically difficult to thread any moreso than any other category of language I think there might be some intrinsic factors: 1. Languages like Python don't want to expose the program to undefined behavior. Defining some trivial class, and then manipulating it from two threads at the same time, is not supposed to crash the program or introduce horrible security issues. 2. Languages like Python have "property bag" objects. That means (someone who knows better should check me on this) that most writes in a typical program are hash table operations, rather than primitive stores of an int or whatever. Locking each table separately, or using a fully atomic implementation, can be a significant slowdown in single-threaded programs, compared to using a GIL.
  - jerf 7y ago
    I think if you wrote a new dynamic scripting language from scratch with the intention that it be threaded that you could probably come up with something. Python is blocked from it not because it is impossible, but because they've been unwilling to orphan all their C extensions. The problem is that while it may raise hackles when stated so bluntly, dynamic scripting languages are generally on their way out anyhow (although they have a ways to go before that is even generally recognized, and even longer before they're legacy; we're talking plural decades for the whole process here), and also, fighting really hard to get threading into a language that is also intrinsically slow is just not the sort of compelling end-point that would inspire an author to create it, and a community to back it up. Why would you want a "threaded scripting language" that literally takes a 32-core machine to catch up to what numerous languages would be capable of doing on a single core? (A new language will have a long ways to go before it can match a good JS VM. Look at Perl 6/Raku's performance history.) Especially since such a language would be racing things like Nim, Crystal, a D revitalization, and several other contenders who are getting 90% of the convenience of scripting languages while getting 90% (or more) of the performance of compiled ones.
pdonis 7y ago
> What's a good alternative? You don't necessarily need one; it depends on what kind of application you have and what its bottleneck is. If your application is network I/O bound, event-driven asynchronous I/O, which is what this article is describing, works fine, and a single process/thread even in a dynamic language like Python can handle a large volume of requests. The specific issue this article is describing is due to a particular poor implementation of event-driven asynchronous I/O, not a general problem with the entire concept. If your application is CPU bound, then yes, you need to use threads (or multiple processes), and you shouldn't be trying to mix event-driven asynchronous I/O with that.
jimbokun 7y ago
Anecdotally, seems like a lot of people are using Go, or maybe Elixir to keep the dynamic typed development experience but much more efficient hardware utilization.
j88439h84 7y ago
Async/await

jerf 7y ago

In this very particular sense, almost anything else is better. Dynamic scripting languages that are intrinsically single threaded because they were single-threaded for the first 10-15 years of their lives, and it is virtually impossible to retrofit true threading all the way from their basic runtimes through all their libraries [1], are basically the pessimal case for this particular problem. This is not the whole story of the value of those languages. As the article even alludes to, at small loads or with lots of care this can be made to "work". But it is something that an engineer should know about them before picking them up and using a tool for something it isn't really good at. [1]: I add this caveat because I don't think there's anything about dynamic scripting languages that makes them intrinsically difficult to thread any moreso than any other category of language, it's just that by an accident of history, they all come to us from the 1990s personal computer world, and they all spent at least a decade cooking and setting and building libraries and communities and developer skillsets before a serious need for threading was even on the horizon.

samatman 7y ago
It's a good caveat, because Lua, in particular, has fully-reentrant functions. You can run a bunch of Lua_states cooperatively or on a threaded basis without problems. Everything the VM does, from the C side, receives a Lua_state as the first argument. It's intrinsically single-threaded, yes. But each instance is quite small and they stay out of each others way. Add coroutines and there's a lot you can safely do with Lua that's a real pain to accomplish with Python.
- mhd 7y ago
  In the days of yore, I might've attempted to shoe-horn Tcl in such a situation. Decent event-loop for distributing tasks and (like Lua, but unlike Python/Ruby) more eager to escape to C for performance-sensitive tasks.
oconnor663 7y ago
> I don't think there's anything about dynamic scripting languages that makes them intrinsically difficult to thread any moreso than any other category of language I think there might be some intrinsic factors: 1. Languages like Python don't want to expose the program to undefined behavior. Defining some trivial class, and then manipulating it from two threads at the same time, is not supposed to crash the program or introduce horrible security issues. 2. Languages like Python have "property bag" objects. That means (someone who knows better should check me on this) that most writes in a typical program are hash table operations, rather than primitive stores of an int or whatever. Locking each table separately, or using a fully atomic implementation, can be a significant slowdown in single-threaded programs, compared to using a GIL.
- jerf 7y ago
  I think if you wrote a new dynamic scripting language from scratch with the intention that it be threaded that you could probably come up with something. Python is blocked from it not because it is impossible, but because they've been unwilling to orphan all their C extensions. The problem is that while it may raise hackles when stated so bluntly, dynamic scripting languages are generally on their way out anyhow (although they have a ways to go before that is even generally recognized, and even longer before they're legacy; we're talking plural decades for the whole process here), and also, fighting really hard to get threading into a language that is also intrinsically slow is just not the sort of compelling end-point that would inspire an author to create it, and a community to back it up. Why would you want a "threaded scripting language" that literally takes a 32-core machine to catch up to what numerous languages would be capable of doing on a single core? (A new language will have a long ways to go before it can match a good JS VM. Look at Perl 6/Raku's performance history.) Especially since such a language would be racing things like Nim, Crystal, a D revitalization, and several other contenders who are getting 90% of the convenience of scripting languages while getting 90% (or more) of the performance of compiled ones.

pdonis 7y ago

> What's a good alternative? You don't necessarily need one; it depends on what kind of application you have and what its bottleneck is. If your application is network I/O bound, event-driven asynchronous I/O, which is what this article is describing, works fine, and a single process/thread even in a dynamic language like Python can handle a large volume of requests. The specific issue this article is describing is due to a particular poor implementation of event-driven asynchronous I/O, not a general problem with the entire concept. If your application is CPU bound, then yes, you need to use threads (or multiple processes), and you shouldn't be trying to mix event-driven asynchronous I/O with that.

jimbokun 7y ago

Anecdotally, seems like a lot of people are using Go, or maybe Elixir to keep the dynamic typed development experience but much more efficient hardware utilization.

j88439h84 7y ago

Async/await