8 ms·

"All 101 threads run 99.9% of the time and we get an almost 100× speed-up" Yea I'm going to call shenanigans.

by banachtarski 10y ago

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.
the_duke 10y ago
This is a classic example for a completely IO bound workload. The program spends almost all time waiting for the web API responses and the the DB inserts, and the computations take a trivial amount of time. An almost linear speedup can be expected, since GHC has a pretty good microthread implementation. Up to a certain thread count of course, since at some point you either saturate the network / database with requests, or there are to many threads fighting for the CPU. It's very similar to what you could expect from goroutines in Go. The first answer here gives a very simplified overview of GHC s microthread model: http://stackoverflow.com/questions/5847642/haskell-lightweight-threads-overhead-and-use-on-multicores http://stackoverflow.com/questions/5847642/haskell-lightweig... And more in depth: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts
- banachtarski 10y ago
  What I'm missing is how an IO bound workload is really ever a good chance to showcase a language's threading and concurrency performance or featureset. When I think about a language's threading model, I think about memory sharing/message passing, synchronization and fences, signaling, context switching and scheduling, preemption etc. None of that is really important if the threads aren't doing any real work.
  - the_duke 10y ago
    Of course it is. In many languages that don't have microthreads baked in, this is not straightforward. You either have to use OS threads, which have a way higher overhead in memory and context switching costs and are not trivial to get right. Or you use some async IO framework with callbacks or the event based OS apis directly, which is also FAR from trivial to get right. Do you really want to think about memory fences and context switching when writing concurrent code? I don't. Of course you should be aware of how it works underneath though.
    - gvb 10y ago
      The problem with the article is Amdahl's law: he is speeding up the part of the code that takes a small fraction of the time and handwaving the bottleneck that takes most of the time. "Currently the bottleneck is writing to the file system..." (and then the rest of the paragraph makes no sense at all). "We cannot do writing to disk from several threads for the following reasons..." - so his threading speeds up everything except the bottleneck that takes all the time.

"All 101 threads run 99.9% of the time and we get an almost 100× speed-up" Yea I'm going to call shenanigans.

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.

the_duke 10y ago

This is a classic example for a completely IO bound workload. The program spends almost all time waiting for the web API responses and the the DB inserts, and the computations take a trivial amount of time. An almost linear speedup can be expected, since GHC has a pretty good microthread implementation. Up to a certain thread count of course, since at some point you either saturate the network / database with requests, or there are to many threads fighting for the CPU. It's very similar to what you could expect from goroutines in Go. The first answer here gives a very simplified overview of GHC s microthread model: http://stackoverflow.com/questions/5847642/haskell-lightweight-threads-overhead-and-use-on-multicores http://stackoverflow.com/questions/5847642/haskell-lightweig... And more in depth: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts

banachtarski 10y ago
What I'm missing is how an IO bound workload is really ever a good chance to showcase a language's threading and concurrency performance or featureset. When I think about a language's threading model, I think about memory sharing/message passing, synchronization and fences, signaling, context switching and scheduling, preemption etc. None of that is really important if the threads aren't doing any real work.
- the_duke 10y ago
  Of course it is. In many languages that don't have microthreads baked in, this is not straightforward. You either have to use OS threads, which have a way higher overhead in memory and context switching costs and are not trivial to get right. Or you use some async IO framework with callbacks or the event based OS apis directly, which is also FAR from trivial to get right. Do you really want to think about memory fences and context switching when writing concurrent code? I don't. Of course you should be aware of how it works underneath though.
  - gvb 10y ago
    The problem with the article is Amdahl's law: he is speeding up the part of the code that takes a small fraction of the time and handwaving the bottleneck that takes most of the time. "Currently the bottleneck is writing to the file system..." (and then the rest of the paragraph makes no sense at all). "We cannot do writing to disk from several threads for the following reasons..." - so his threading speeds up everything except the bottleneck that takes all the time.