4 ms·
> copy-on-write also copies on reads for certain Perl structures This is perfectly okay! Your scalar variables are a pittance compared to your language's runti
by blasdel 17y ago
> copy-on-write also copies on reads for certain Perl structures
This is perfectly okay! Your scalar variables are a pittance compared to your language's runtime and all the bloaty libraries you've imported. Besides, in most of these instances, your memory footprint would grow (until GC) in single-process usage just the same.
> Maybe Python and Ruby are more clever here
Python is better about keeping things immutable. Matz's Ruby pisses all over itself, it's fundamentally incapable of sharing any objects copy-on-write: http://news.ycombinator.com/item?id=865364 http://news.ycombinator.com/item?id=865364
> do you really want one process for each of your 1 million users?
> No; you want a lightweight thread for each.
The hell you don't! Both of those options are the same shit in different costumes. Just because lightweight threads make keeping a stateful execution context for each client tractable on real-world OSes doesn't make it a good idea.
- jrockway 17y agoThis is perfectly okay! Your scalar variables are a pittance compared to your language's runtime and all the bloaty libraries you've imported. Besides, in most of these instances, your memory footprint would grow (until GC) in single-process usage just the same. Theoretically, this might be true, but it doesn't seem to work this way in the real world. Both of those options are the same shit in different costumes. Just because lightweight threads make keeping a stateful execution context for each client tractable on real-world OSes doesn't make it a good idea. I'm not sure what improvement you are offering. Lightweight threads have the space overhead of one structure, and almost no time overhead. (epoll is O(n) over active handles; so in most cases, constant time!)
- blasdel 17y agoI 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 agoWhile 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 agoHere's a nickel kid, go try out your ridiculous proposition. I'll wait while you pull the power plug and restart...
- btilly 17y agoYou 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 agoTry 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 agoI'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.