5 ms·

They're overwhelmingly argument by assertion. I'm not sure that counts as "well argued"? Like the stuff at the end about STM and M:N scheduling. There are sy

They're overwhelmingly argument by assertion. I'm not sure that counts as "well argued"? Like the stuff at the end about STM and M:N scheduling. There are systems that use both to tremendous effect. Erlang only offers an M:N scheduling model, and it works extremely well for building the kinds of systems Erlang was built for.

nickpsecurity 11y ago
Yeah, both examples plus him not backing up his performance assertion showed he was full of crap. Haskell did nearly bulletproof STM that I hear. I've seen other examples. Your Erlang example is good on M:N. Microkernel with work in AI planning still using it successfully with ever more efficient algorithms. JeOS performance characteristics of the past suggest unikernels might improve performance over monoliths or plain virtualization. Need real-world data rather than assertions. He seems to be all talk. He's also more critical of unikernel level security and robustness over well-known issues like POLA while ignoring that his own platform violates both POLA and other rules we've learned about INFOSEC over time. The only proven approaches were separation kernels a la Nizza architecture, capability model at OS or component level, and language-based protection w/ extra care on HW interfaces. He doesn't mention those because they oppose UNIX approach, which he ideologically supports, plus show his product is likely not trustworthy. This article isn't objective or reliable.
- dmpk2k 11y ago
  I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems. Circa 2000, Solaris, Linux, and some (all?) BSDs had M:N threading, and all of them threw it away because there are numerous performance artifacts caused by two schedulers (OS and the M:N) conflicting with each other. Mr. Cantrill was there when this all happened, and even wrote a paper on it: ftp://ftp.cs.brown.edu/pub/techreports/96/cs96-19.pdf This doesn't affect Erlang as much simply because Erlang is really slow. I think of it as a waterline -- the lower the overhead of the language, the more likely you will run into the serious problems that M:N typically inflicts. E.g. priority inversion, and long and unpredictable latencies when the OS swaps out a thread that M:N wanted running. As for Haskell and STM, all I know on the topic is that some pretty damn smart engineers at IBM spent a good while trying to make STM work well, and gave up. See this ACM article: https://queue.acm.org/detail.cfm?id=1454466 https://queue.acm.org/detail.cfm?id=1454466. Perhaps Haskell managed to pull it off through the language restrictions it allows, but I’d like to see some compelling articles on that by engineers who know a thing or two; just because a language has STM doesn’t mean it does it well. Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's. While you might disagree with him, there’s sufficient literature to give his stance some legitimacy. Sweepingly calling his stance "full of crap" says a thing or two.
  - nickpsecurity 11y ago
    "I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems." "Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's." Probably was. Idk who he is or what he does. I'm aware there were fads to claim the two could solve every problem under the Sun in their category. I'm one of those few that ignore fads to focus on any lessons we can learn from certain tech or research. He made a blanket assertion against at least three technologies in one article with no context. Anyone reading might think the techs don't work well in any context. So, I briefly called that. As evidence, I gave an example of STM that worked. In OS's, it had mixed results unless hardware accelerated and one typically had to protect I/O stuff with locks due to irreversibility. Far as M:N, only found OS use for it in security kernels (eg GEMSOS) to help supress covert, timing channels. Didn't expect him to know that use-case, though, since the cloud products are usually full of covert channels. And then there's MirageOS on unikernel end using type- and memory-safety for robust, network applications already showing fewer 0-days than alternatives did. So, all three already have real-world, beneficial use. Quite the opposite of his claim that leads one to believe that never happens. "Sweepingly calling his stance "full of crap" says a thing or two." In other comments, I did present data and specific examples to reject his claims about UNIX being a usable foundation for this sort of thing among others. His approach to such things was to ignore all counter evidence and/or leave the discussion. Eventually, a new article shows him making an adverti... err, a bunch of claims, some backed up and some assertions, about all kinds of tech in an anti-unikernel rant. Strange that you're fine with him ignoring his critic's counterpoints... with references... to his major claims but have trouble with how I handle minor, tangential ones. Says a thing or two indeed.
    - dmpk2k 11y ago
      I comment on the things I know about. Strange indeed.
      - chris_wot 11y ago
        I don't often see you commenting.
mcguire 11y ago
I personally, as a Rust guy, was disappointed by the loss of M:N threading; without that, you cannot effectively use threads as a design tool rather than simply ("simply" :-)) a parallelization/performance tool. Erlang has a lot of neat ideas.
- masklinn 11y ago
  m:n does not an erlang make though (witness Go), and Rust was not headed in that direction.
  - mcguire 11y ago
    I know, I know. And Rust is a better systems language for it. Still, I can dream.
    - im_down_w_otp 11y ago
      Take a look at pony-lang. It's sorta like what Rust was once going to be. It's sort of implicitly going for a bare-metal Erlang-shaped thing. There's a lot missing, not the least of which is a set of abstractions over the rich primitives which provide simple programming interfaces that don't force a lot of the language's complexity on you, but if what you want is something that might one day be a really fast Erlangish it's probably the front-runner at the moment. I still have high hopes for BEAMJIT existing as a production-grade thing someday. That way I don't have to drop into C in my Erlang applications as often. Sure BEAMJIT will probably never be as fast, but if it can be good-enough while also not forcing me across the safety boundary to get to that good-enough state... that's a huge win.
- zokier 11y ago
  I thought the idea in Rust was to provide solid primitives so that libraries can then provide m:n/green threading if wanted. And sure enough we have stuff like coio and mioco which provide coroutines. Is there something missing in those that you'd want from m:n threading?
hinkley 11y ago
Solaris used to have an M:N scheduling model and they've mostly abandoned it, didn't they? I wonder what Erlang got right that Solaris got wrong.
- deleted 11y ago
  [deleted]
- tormeh 11y ago
  Erlang is a low-throughput, low-latency language. It makes no apologies for the former and it even says so on the tin. That allows it to do stuff other languages/runtimes can't.
the_why_of_y 11y ago
I'd say he's half-right on the M:N scheduling. For implementing POSIX threads, M:N threading has a lot of extra complexity and few advantages, and worse performance. But if you don't have POSIX threads, but something higher-level that's managed by a runtime anyway, you don't need to worry about things like ensuring enough VM space and at least one allocated page for each thread stack. Erlang's and GHC's threads start out needing much less space than a single page, so you can start 10x more threads in the same amount of RAM.

nickpsecurity 11y ago

Yeah, both examples plus him not backing up his performance assertion showed he was full of crap. Haskell did nearly bulletproof STM that I hear. I've seen other examples. Your Erlang example is good on M:N. Microkernel with work in AI planning still using it successfully with ever more efficient algorithms. JeOS performance characteristics of the past suggest unikernels might improve performance over monoliths or plain virtualization. Need real-world data rather than assertions. He seems to be all talk. He's also more critical of unikernel level security and robustness over well-known issues like POLA while ignoring that his own platform violates both POLA and other rules we've learned about INFOSEC over time. The only proven approaches were separation kernels a la Nizza architecture, capability model at OS or component level, and language-based protection w/ extra care on HW interfaces. He doesn't mention those because they oppose UNIX approach, which he ideologically supports, plus show his product is likely not trustworthy. This article isn't objective or reliable.

dmpk2k 11y ago
I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems. Circa 2000, Solaris, Linux, and some (all?) BSDs had M:N threading, and all of them threw it away because there are numerous performance artifacts caused by two schedulers (OS and the M:N) conflicting with each other. Mr. Cantrill was there when this all happened, and even wrote a paper on it: ftp://ftp.cs.brown.edu/pub/techreports/96/cs96-19.pdf This doesn't affect Erlang as much simply because Erlang is really slow. I think of it as a waterline -- the lower the overhead of the language, the more likely you will run into the serious problems that M:N typically inflicts. E.g. priority inversion, and long and unpredictable latencies when the OS swaps out a thread that M:N wanted running. As for Haskell and STM, all I know on the topic is that some pretty damn smart engineers at IBM spent a good while trying to make STM work well, and gave up. See this ACM article: https://queue.acm.org/detail.cfm?id=1454466 https://queue.acm.org/detail.cfm?id=1454466. Perhaps Haskell managed to pull it off through the language restrictions it allows, but I’d like to see some compelling articles on that by engineers who know a thing or two; just because a language has STM doesn’t mean it does it well. Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's. While you might disagree with him, there’s sufficient literature to give his stance some legitimacy. Sweepingly calling his stance "full of crap" says a thing or two.
- nickpsecurity 11y ago
  "I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems." "Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's." Probably was. Idk who he is or what he does. I'm aware there were fads to claim the two could solve every problem under the Sun in their category. I'm one of those few that ignore fads to focus on any lessons we can learn from certain tech or research. He made a blanket assertion against at least three technologies in one article with no context. Anyone reading might think the techs don't work well in any context. So, I briefly called that. As evidence, I gave an example of STM that worked. In OS's, it had mixed results unless hardware accelerated and one typically had to protect I/O stuff with locks due to irreversibility. Far as M:N, only found OS use for it in security kernels (eg GEMSOS) to help supress covert, timing channels. Didn't expect him to know that use-case, though, since the cloud products are usually full of covert channels. And then there's MirageOS on unikernel end using type- and memory-safety for robust, network applications already showing fewer 0-days than alternatives did. So, all three already have real-world, beneficial use. Quite the opposite of his claim that leads one to believe that never happens. "Sweepingly calling his stance "full of crap" says a thing or two." In other comments, I did present data and specific examples to reject his claims about UNIX being a usable foundation for this sort of thing among others. His approach to such things was to ignore all counter evidence and/or leave the discussion. Eventually, a new article shows him making an adverti... err, a bunch of claims, some backed up and some assertions, about all kinds of tech in an anti-unikernel rant. Strange that you're fine with him ignoring his critic's counterpoints... with references... to his major claims but have trouble with how I handle minor, tangential ones. Says a thing or two indeed.
  - dmpk2k 11y ago
    I comment on the things I know about. Strange indeed.
    - chris_wot 11y ago
      I don't often see you commenting.

mcguire 11y ago

I personally, as a Rust guy, was disappointed by the loss of M:N threading; without that, you cannot effectively use threads as a design tool rather than simply ("simply" :-)) a parallelization/performance tool. Erlang has a lot of neat ideas.

masklinn 11y ago
m:n does not an erlang make though (witness Go), and Rust was not headed in that direction.
- mcguire 11y ago
  I know, I know. And Rust is a better systems language for it. Still, I can dream.
  - im_down_w_otp 11y ago
    Take a look at pony-lang. It's sorta like what Rust was once going to be. It's sort of implicitly going for a bare-metal Erlang-shaped thing. There's a lot missing, not the least of which is a set of abstractions over the rich primitives which provide simple programming interfaces that don't force a lot of the language's complexity on you, but if what you want is something that might one day be a really fast Erlangish it's probably the front-runner at the moment. I still have high hopes for BEAMJIT existing as a production-grade thing someday. That way I don't have to drop into C in my Erlang applications as often. Sure BEAMJIT will probably never be as fast, but if it can be good-enough while also not forcing me across the safety boundary to get to that good-enough state... that's a huge win.
zokier 11y ago
I thought the idea in Rust was to provide solid primitives so that libraries can then provide m:n/green threading if wanted. And sure enough we have stuff like coio and mioco which provide coroutines. Is there something missing in those that you'd want from m:n threading?

hinkley 11y ago

Solaris used to have an M:N scheduling model and they've mostly abandoned it, didn't they? I wonder what Erlang got right that Solaris got wrong.

deleted 11y ago
[deleted]
tormeh 11y ago
Erlang is a low-throughput, low-latency language. It makes no apologies for the former and it even says so on the tin. That allows it to do stuff other languages/runtimes can't.

the_why_of_y 11y ago

I'd say he's half-right on the M:N scheduling. For implementing POSIX threads, M:N threading has a lot of extra complexity and few advantages, and worse performance. But if you don't have POSIX threads, but something higher-level that's managed by a runtime anyway, you don't need to worry about things like ensuring enough VM space and at least one allocated page for each thread stack. Erlang's and GHC's threads start out needing much less space than a single page, so you can start 10x more threads in the same amount of RAM.