4 ms·

Based on what?

by thinkpad20 10y ago

Based on what?

dllthomas 10y ago
Are there >100 cores involved?
- Filligree 10y ago
  No, it's an I/O heavy workload.
  - banachtarski 10y ago
    What's the point of the article then. Is there any language that can't fire off a billion syscalls that enter a wait assuming it's purely IO bound?
    - wyager 10y ago
      Have fun programming that in most languages, especially if you're doing some non-trivial combination of IO activities. Haskell's runtime allows you to program in a convenient and clear threaded style and automagically takes care of efficient polling and dispatch and such. If you want to write a web application in around some giant epoll loop, more power to you. Have fun with fairness guarantees, buffering, ensuring that connections don't time out because you're favoring certain connections...
      - banachtarski 10y ago
        I'm actually pretty fluent in Haskell but you're overselling it in my opinion. Haskell also has issues with fairness guarantees and as for buffering and timeouts and stuff, I have less control than I would in a language like C. Also, epoll really isn't that hard.
        willtim 10y ago
        C is the right choice for some performance critical domains, but productivity will be a long way from what a Haskell developer can achieve, especially when concurrency is thrown into the mix. IMHO, I think you are overselling C.
        deleted 10y ago
        [deleted]
  - gvb 10y ago
    If it is an I/O heavy workload (and it is), then his statement "All 101 threads run 99.9% of the time and we get an almost 100× speed-up." cannot be true. The processing portion probably runs n times faster, where n = the number of CPU cores, but his I/O thread is still single-threaded ("[w]e cannot do writing to disk from several threads for the following reasons...") and obviously cannot be running 100x faster.
    - dllthomas 10y ago
      Well, it's possible that the IO is dispatched from a single thread but can be handled in parallel by the OS. If the single thread doesn't need to block, it needn't be the bottleneck. Still, even if they are somehow seeing 100x speedup, it won't be because 100 threads are near constantly busy - without that many cores (after hyperthreading, maybe, with caveats) it is simply not going to be the case that all threads are constantly busy.

Based on what?

dllthomas 10y ago

Are there >100 cores involved?

Filligree 10y ago
No, it's an I/O heavy workload.
- banachtarski 10y ago
  What's the point of the article then. Is there any language that can't fire off a billion syscalls that enter a wait assuming it's purely IO bound?
  - wyager 10y ago
    Have fun programming that in most languages, especially if you're doing some non-trivial combination of IO activities. Haskell's runtime allows you to program in a convenient and clear threaded style and automagically takes care of efficient polling and dispatch and such. If you want to write a web application in around some giant epoll loop, more power to you. Have fun with fairness guarantees, buffering, ensuring that connections don't time out because you're favoring certain connections...
    - banachtarski 10y ago
      I'm actually pretty fluent in Haskell but you're overselling it in my opinion. Haskell also has issues with fairness guarantees and as for buffering and timeouts and stuff, I have less control than I would in a language like C. Also, epoll really isn't that hard.
      - willtim 10y ago
        C is the right choice for some performance critical domains, but productivity will be a long way from what a Haskell developer can achieve, especially when concurrency is thrown into the mix. IMHO, I think you are overselling C.
      - deleted 10y ago
        [deleted]
- gvb 10y ago
  If it is an I/O heavy workload (and it is), then his statement "All 101 threads run 99.9% of the time and we get an almost 100× speed-up." cannot be true. The processing portion probably runs n times faster, where n = the number of CPU cores, but his I/O thread is still single-threaded ("[w]e cannot do writing to disk from several threads for the following reasons...") and obviously cannot be running 100x faster.
  - dllthomas 10y ago
    Well, it's possible that the IO is dispatched from a single thread but can be handled in parallel by the OS. If the single thread doesn't need to block, it needn't be the bottleneck. Still, even if they are somehow seeing 100x speedup, it won't be because 100 threads are near constantly busy - without that many cores (after hyperthreading, maybe, with caveats) it is simply not going to be the case that all threads are constantly busy.