4 ms·

There’s various types of real-time systems: https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.m.wikipedia.org/wiki

There’s various types of real-time systems: https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria... You’re talking about hard real-time. Erlang, as it says on the official site, targets soft real-time.

sriram_malhar 9y ago
I know Erlang says that and I have always been a bit mystified by it. Definition of soft real time: "the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service". Well, duh. That's pretty useless. Any system in production is soft real-time by that definition. There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It is not as if admission and rate control are baked into BEAM. If you don't pay attention to your messaging architecture, head-of-line blocking will kill you. I know that they claim that their sharded-GC design helps with shorter pauses, but there's no real evidence to back the imputation that other GC designs have really held back the industry; consider the large number of sites that have been implemented in Java/Python/Ruby. I have put Java/Scala/Go/Erlang systems in production, and rarely have I have ever had to worry about GC tuning.
- qaq 9y ago
  There is something very special about Erlang VM fully preemptive scheduling
  - sriram_malhar 9y ago
    But is it really? I'm sure those who know Erlang well will correct me on this, but if it is doing IO of any sort, it is limited by the number of IO operations (posix/db calls) under the covers. There can be atmost as many as the number of kernel threads created by the VM, which is typically equal to the number of processors.
    - ramchip 9y ago
      Scheduler threads use async IO internally, they context switch to another process while the first one is blocked waiting for the IO to complete. When async is not possible, they dispatch operations to a thread pool.
- ramchip 9y ago
  > Any system in production is soft real-time by that definition. Most systems don't fit in that definition because they don't have deadlines in the first place. A site like Hacker News is not soft real-time; the faster it loads the better, but there's not a set number of seconds after which a user would give up. A video streaming service, or most API with response time guarantees, would be soft real-time systems. There is a deadline, but it doesn't need to be respected 100% of the time, as users can live with a few dropped frames or out-of-spec responses. > There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It's not about "pretty quick" but about predictable, reliable response times. The key feature is the preemptive scheduling. Processes can only block a given scheduler for a very short time; all functions in the language that can take a long time to execute are built to yield to the scheduler periodically. So you don't get a slow request because some other request decided to turn a huge map into a string, or run an expensive loop, or block waiting for I/O, or run a GC, etc. This is of course a tradeoff between throughput and latency, because all the yielding and checking comes at a cost. Go is a bit in the middle ground, it also uses lightweight processes, but does not yield as much so a hot loop can block for some time (but also runs faster as a result).
  - sriram_malhar 9y ago
    > A video streaming service, or most API with response time guarantees ... Preemption, the design of Erlang's GC etc. don't contribute to predictability or reliability any more than other frameworks. Consider a system written in Erlang, and another written using a very different architecture, say Python/C++ (YouTube). In both cases, Python and Erlang are basically used for orchestration; the action happens in the systems layer below. In both cases they use non-blocking I/O underneath, and some sort of adaptive bitrate streaming if not enough bytes are going through within the time bound. There is nothing that is particular to the Erlang system that monitors bitrate and does something about it. In both cases, the soft real time guarantee has to be accounted for explicitly; you don't get it in any shape or form from the Python or Erlang architecture. The only 'guarantee' you get is the promise of using the underlying API in the most sensible way possible, and to push out bytes with as little overhead as possible. What you get in both cases, is convenience. As a side note, here's BBC's Kamaelia framework (http://www.kamaelia.org/Home.html http://www.kamaelia.org/Home.html) written in Python. (I'm not sure if they still use it though).

sriram_malhar 9y ago

I know Erlang says that and I have always been a bit mystified by it. Definition of soft real time: "the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service". Well, duh. That's pretty useless. Any system in production is soft real-time by that definition. There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It is not as if admission and rate control are baked into BEAM. If you don't pay attention to your messaging architecture, head-of-line blocking will kill you. I know that they claim that their sharded-GC design helps with shorter pauses, but there's no real evidence to back the imputation that other GC designs have really held back the industry; consider the large number of sites that have been implemented in Java/Python/Ruby. I have put Java/Scala/Go/Erlang systems in production, and rarely have I have ever had to worry about GC tuning.

qaq 9y ago
There is something very special about Erlang VM fully preemptive scheduling
- sriram_malhar 9y ago
  But is it really? I'm sure those who know Erlang well will correct me on this, but if it is doing IO of any sort, it is limited by the number of IO operations (posix/db calls) under the covers. There can be atmost as many as the number of kernel threads created by the VM, which is typically equal to the number of processors.
  - ramchip 9y ago
    Scheduler threads use async IO internally, they context switch to another process while the first one is blocked waiting for the IO to complete. When async is not possible, they dispatch operations to a thread pool.
ramchip 9y ago
> Any system in production is soft real-time by that definition. Most systems don't fit in that definition because they don't have deadlines in the first place. A site like Hacker News is not soft real-time; the faster it loads the better, but there's not a set number of seconds after which a user would give up. A video streaming service, or most API with response time guarantees, would be soft real-time systems. There is a deadline, but it doesn't need to be respected 100% of the time, as users can live with a few dropped frames or out-of-spec responses. > There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It's not about "pretty quick" but about predictable, reliable response times. The key feature is the preemptive scheduling. Processes can only block a given scheduler for a very short time; all functions in the language that can take a long time to execute are built to yield to the scheduler periodically. So you don't get a slow request because some other request decided to turn a huge map into a string, or run an expensive loop, or block waiting for I/O, or run a GC, etc. This is of course a tradeoff between throughput and latency, because all the yielding and checking comes at a cost. Go is a bit in the middle ground, it also uses lightweight processes, but does not yield as much so a hot loop can block for some time (but also runs faster as a result).
- sriram_malhar 9y ago
  > A video streaming service, or most API with response time guarantees ... Preemption, the design of Erlang's GC etc. don't contribute to predictability or reliability any more than other frameworks. Consider a system written in Erlang, and another written using a very different architecture, say Python/C++ (YouTube). In both cases, Python and Erlang are basically used for orchestration; the action happens in the systems layer below. In both cases they use non-blocking I/O underneath, and some sort of adaptive bitrate streaming if not enough bytes are going through within the time bound. There is nothing that is particular to the Erlang system that monitors bitrate and does something about it. In both cases, the soft real time guarantee has to be accounted for explicitly; you don't get it in any shape or form from the Python or Erlang architecture. The only 'guarantee' you get is the promise of using the underlying API in the most sensible way possible, and to push out bytes with as little overhead as possible. What you get in both cases, is convenience. As a side note, here's BBC's Kamaelia framework (http://www.kamaelia.org/Home.html http://www.kamaelia.org/Home.html) written in Python. (I'm not sure if they still use it though).