4 ms·

Who is this surprising to? Timesharing, timeslicing, multiprocess, multitenancy,-- whatever you call the same underlying concept -- was one of the pivotal advan

Who is this surprising to? Timesharing, timeslicing, multiprocess, multitenancy,-- whatever you call the same underlying concept -- was one of the pivotal advances in computer systems. Surely no serious person is surprised it is effective.

mjb 4y ago
Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. What's surprising here isn't that time slicing works, it's that the same mechanism drives both the economics of large systems, and their ability to economically support bursty workloads. I can understand that may not be a surprise to you. What's surprising to me is that you took the time to come say you aren't surprised, instead of going on with your day. Clearly, I shouldn't have claimed this casual blog post was original research that had never been seen in any form before. Silly me!
- throwawaylinux 4y ago
  > Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. I mean its implementation in computer systems. > What's surprising here isn't that time slicing works, it's that the same mechanism drives both the economics of large systems, and their ability to economically support bursty workloads. That's not surprising. > Clearly, I shouldn't have claimed this casual blog post was original research that had never been seen in any form before. Silly me! That's not the issue though is it, that's your snarky strawman to deflect from it. Which is that its a lazy cliche title and it purports to be much more grandiose than it is.
  - preseinger 4y ago
    thank you, good samaritan, for doing the tough but necessary work of disparaging this blog post, and the person who posted it, because you find the conclusions obvious i'm sure that marc brooker, the author, and one of the most accomplished computer scientists currently living, will think twice before posting such pablum again
    - throwawaylinux 4y ago
      Somebody was surprised by the scalability of multitenancy :)
jmillikin 4y ago
At my previous employer, there was at least one person with a "staff software engineer" job title who believed that running more than one Ruby server process per AWS virtual machine would lead to unacceptable contention at the hardware level. I was never able to convince them that Linux handles tens of thousands of processes just fine, or that even if you do one per VM there's nothing stopping AWS from scheduling those VMs onto the same machine. I guess whether you consider someone like that to be a "serious person" or a "charlatan" depends on your own point of reference. In that case, their arguments were more persuasive to management than mine were. I found the experience baffling.
- djbusby 4y ago
  The lesson for you was in communication not engineering. No hate. Was (is) a frustrating experience for me too.
  - jmillikin 4y ago
    Having had some back-channel status updates after I got pushed aside, the lesson is that some people accept or discard ideas based on employment background. On the team I was on, newly-hired managers from Amazon accepted the ideas of ICs who had previously worked at Amazon, and rejected ideas from people who had not. I didn't realize this was a pattern until I already had one foot out the door, but even if I had realized it earlier it wouldn't have helped. I was ex-Google, so the ex-Amazon folks tagged every document with the bozo bit before they'd even opened it. My takeaway was to be cautious of companies where the culture is imported through mass hiring from single companies. I joined in the middle of the "Google wave", which was relatively peaceful (per Google's culture at the time). When the "Amazon wave" arrived it was quite a shock; their culture was much more adversarial and authoritarian than anywhere I'd worked before. By the time I left, there were signs the Amazon folks were starting to get sidelined by an emerging "Oracle wave".
- ec109685 4y ago
  Doesn’t it depend on how many cpu cores to some extent and how much the ruby process is idle on io? Amazon doesn’t over commit cpu for normal VM instance types.
kqr 4y ago
I agree. It's not even about efficiently utilising resources. If we process things in timeslices that immediately kills any bad effects variability has on the workload. Small jobs go fast even if a big job happened to arrive in front of it. (Of course, it's still a tradeoff between context switching overhead and the magnitude of the variability, but fundamentally even a tiny level of timeslicing can be a huge improvement.)

mjb 4y ago

Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. What's surprising here isn't that time slicing works, it's that the same mechanism drives both the economics of large systems, and their ability to economically support bursty workloads. I can understand that may not be a surprise to you. What's surprising to me is that you took the time to come say you aren't surprised, instead of going on with your day. Clearly, I shouldn't have claimed this casual blog post was original research that had never been seen in any form before. Silly me!

throwawaylinux 4y ago
> Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. I mean its implementation in computer systems. > What's surprising here isn't that time slicing works, it's that the same mechanism drives both the economics of large systems, and their ability to economically support bursty workloads. That's not surprising. > Clearly, I shouldn't have claimed this casual blog post was original research that had never been seen in any form before. Silly me! That's not the issue though is it, that's your snarky strawman to deflect from it. Which is that its a lazy cliche title and it purports to be much more grandiose than it is.
- preseinger 4y ago
  thank you, good samaritan, for doing the tough but necessary work of disparaging this blog post, and the person who posted it, because you find the conclusions obvious i'm sure that marc brooker, the author, and one of the most accomplished computer scientists currently living, will think twice before posting such pablum again
  - throwawaylinux 4y ago
    Somebody was surprised by the scalability of multitenancy :)

jmillikin 4y ago

At my previous employer, there was at least one person with a "staff software engineer" job title who believed that running more than one Ruby server process per AWS virtual machine would lead to unacceptable contention at the hardware level. I was never able to convince them that Linux handles tens of thousands of processes just fine, or that even if you do one per VM there's nothing stopping AWS from scheduling those VMs onto the same machine. I guess whether you consider someone like that to be a "serious person" or a "charlatan" depends on your own point of reference. In that case, their arguments were more persuasive to management than mine were. I found the experience baffling.

djbusby 4y ago
The lesson for you was in communication not engineering. No hate. Was (is) a frustrating experience for me too.
- jmillikin 4y ago
  Having had some back-channel status updates after I got pushed aside, the lesson is that some people accept or discard ideas based on employment background. On the team I was on, newly-hired managers from Amazon accepted the ideas of ICs who had previously worked at Amazon, and rejected ideas from people who had not. I didn't realize this was a pattern until I already had one foot out the door, but even if I had realized it earlier it wouldn't have helped. I was ex-Google, so the ex-Amazon folks tagged every document with the bozo bit before they'd even opened it. My takeaway was to be cautious of companies where the culture is imported through mass hiring from single companies. I joined in the middle of the "Google wave", which was relatively peaceful (per Google's culture at the time). When the "Amazon wave" arrived it was quite a shock; their culture was much more adversarial and authoritarian than anywhere I'd worked before. By the time I left, there were signs the Amazon folks were starting to get sidelined by an emerging "Oracle wave".
ec109685 4y ago
Doesn’t it depend on how many cpu cores to some extent and how much the ruby process is idle on io? Amazon doesn’t over commit cpu for normal VM instance types.

kqr 4y ago

I agree. It's not even about efficiently utilising resources. If we process things in timeslices that immediately kills any bad effects variability has on the workload. Small jobs go fast even if a big job happened to arrive in front of it. (Of course, it's still a tradeoff between context switching overhead and the magnitude of the variability, but fundamentally even a tiny level of timeslicing can be a huge improvement.)