2 ms·

I think you massively underestimate the benefit of sharing libraries between processes -- It seems to be perfectly normal in the Rails world to have app process

by blasdel 17y ago

I think you massively underestimate the benefit of sharing libraries between processes -- It seems to be perfectly normal in the Rails world to have app processes start at several hundred MB, before a single request! I'm not sure how you think threads work. Of course Lightweight Threads have time overhead -- you still have to schedule them!

btilly 17y ago
While you've made a lot of good points, the time overhead is insignificant. By default modern versions of Linux use a O(log(N)) scheduler, so going from a few thousand to a few million threads of execution only doubles the scheduling time. Furthermore if you go to an older kernel you can get the O(1) scheduler, meaning that scheduling is constant time no matter how many threads you have. (But the scheduling had worse characteristics, which is why you're probably better off with the less scalable scheduler.)
- blasdel 17y ago
  Here's a nickel kid, go try out your ridiculous proposition. I'll wait while you pull the power plug and restart...
  - btilly 17y ago
    You have apparently misunderstood something here. Just because you are launching something that can scale to a million threads doesn't mean that it needs to spawn a million threads every time it spins up. But if it does spin up a million threads over time, the performance of your scheduler won't be your bottleneck. There will be lots of other big ones (memory, stack space, etc), but not scheduling overhead.
    - jrockway 17y ago
      Try Coro; the overhead per coroutine is very low. I have some numbers in a HN comment from a few weeks ago... let me dig that up. Edit: here we are: http://news.ycombinator.com/item?id=794535 http://news.ycombinator.com/item?id=794535 (Thanks, SearchYC. I found this post with a signle query!)
    - btilly 17y ago
      I'm replying to me because I don't have a reply button for jrockway's response. When you use the word "threads", most people are going to assume you mean OS threads because that is what most of the world means. Hence this subdiscussion with bladsel about having a lot of OS threads.
      - jrockway 17y ago
        I think he thinks you think the alternative to lightweight threads is a process-per-connection. (I think you think that too.) BTW, you can reply to posts without the reply button by clicking "link" and typing in the resulting box. Yeah.
        btilly 17y ago
        If you think that, then you think wrong. I am fully aware that there are plenty of alternatives to that model. I wouldn't choose to use them in Perl, but they exist. Which is why what I said earlier in http://news.ycombinator.com/item?id=866558 http://news.ycombinator.com/item?id=866558 (back when I thought that by "lightweight thread" you meant something like a thread in the JVM) boils down to, "Here is the standard way to do it in Perl. If you want to take this other type of approach using a similar class of scripting language, I would recommend one of these alternate implementations of Ruby or Python." Thanks for the tip on getting around the lack of a reply button.
jrockway 17y ago
I think you massively underestimate the benefit of sharing libraries Nope, I understand that this is incredibly efficient. The difference between C libraries and Perl libraries, though, is that Perl library data structures modify themselves as they are used. (The optree is immutable, that's about all.) UNIX/C shared objects are immutable, so it's easy to share them efficiently. It is common for people to complain of preforked mod_perl processes using all their memory -- not immediately after the fork, but after the app has been steady-state after a while. Things like memoized functions are obvious causes of this behavior, but even Perl's internal data structures change as they are used, and cause the sharing level to decrease over time. preforking works OK, but it is not perfect. (If you want one preforked process per core, that is fine. If you want one per client, and the process is reused for many clients, that's where I have seen problems.) Another thing I like about writing lightweight-thread-based apps (or simply async event-based; same thing basically) is convenience -- when I start up my development webserver, the same process can also handle mDNS requests. So I can just click a button in my browser to visit my app; no messing around with making sure that something else isn't binding port 3000, or whatever. Things like job queue runners, scheduled tasks (for cleaning up expired sessions), and so on can also run this way.

by blasdel 17y ago

btilly 17y ago

While you've made a lot of good points, the time overhead is insignificant. By default modern versions of Linux use a O(log(N)) scheduler, so going from a few thousand to a few million threads of execution only doubles the scheduling time. Furthermore if you go to an older kernel you can get the O(1) scheduler, meaning that scheduling is constant time no matter how many threads you have. (But the scheduling had worse characteristics, which is why you're probably better off with the less scalable scheduler.)

blasdel 17y ago
Here's a nickel kid, go try out your ridiculous proposition. I'll wait while you pull the power plug and restart...
- btilly 17y ago
  You have apparently misunderstood something here. Just because you are launching something that can scale to a million threads doesn't mean that it needs to spawn a million threads every time it spins up. But if it does spin up a million threads over time, the performance of your scheduler won't be your bottleneck. There will be lots of other big ones (memory, stack space, etc), but not scheduling overhead.
  - jrockway 17y ago
    Try Coro; the overhead per coroutine is very low. I have some numbers in a HN comment from a few weeks ago... let me dig that up. Edit: here we are: http://news.ycombinator.com/item?id=794535 http://news.ycombinator.com/item?id=794535 (Thanks, SearchYC. I found this post with a signle query!)
  - btilly 17y ago
    I'm replying to me because I don't have a reply button for jrockway's response. When you use the word "threads", most people are going to assume you mean OS threads because that is what most of the world means. Hence this subdiscussion with bladsel about having a lot of OS threads.
    - jrockway 17y ago
      I think he thinks you think the alternative to lightweight threads is a process-per-connection. (I think you think that too.) BTW, you can reply to posts without the reply button by clicking "link" and typing in the resulting box. Yeah.
      - btilly 17y ago
        If you think that, then you think wrong. I am fully aware that there are plenty of alternatives to that model. I wouldn't choose to use them in Perl, but they exist. Which is why what I said earlier in http://news.ycombinator.com/item?id=866558 http://news.ycombinator.com/item?id=866558 (back when I thought that by "lightweight thread" you meant something like a thread in the JVM) boils down to, "Here is the standard way to do it in Perl. If you want to take this other type of approach using a similar class of scripting language, I would recommend one of these alternate implementations of Ruby or Python." Thanks for the tip on getting around the lack of a reply button.

jrockway 17y ago

I think you massively underestimate the benefit of sharing libraries Nope, I understand that this is incredibly efficient. The difference between C libraries and Perl libraries, though, is that Perl library data structures modify themselves as they are used. (The optree is immutable, that's about all.) UNIX/C shared objects are immutable, so it's easy to share them efficiently. It is common for people to complain of preforked mod_perl processes using all their memory -- not immediately after the fork, but after the app has been steady-state after a while. Things like memoized functions are obvious causes of this behavior, but even Perl's internal data structures change as they are used, and cause the sharing level to decrease over time. preforking works OK, but it is not perfect. (If you want one preforked process per core, that is fine. If you want one per client, and the process is reused for many clients, that's where I have seen problems.) Another thing I like about writing lightweight-thread-based apps (or simply async event-based; same thing basically) is convenience -- when I start up my development webserver, the same process can also handle mDNS requests. So I can just click a button in my browser to visit my app; no messing around with making sure that something else isn't binding port 3000, or whatever. Things like job queue runners, scheduled tasks (for cleaning up expired sessions), and so on can also run this way.