3 ms·

We are actually talking about orthogonal aspects. You are right that being able to run the system on a smaller number of nodes reduces inefficiencies and reduce

We are actually talking about orthogonal aspects. You are right that being able to run the system on a smaller number of nodes reduces inefficiencies and reduces the "hit" of diminishing returns stemming from Amdahl's law. However, to do that, you need to speed up your code and I argue that unless you speed up the non-parallelizable part together with the parallelizable part, you won't be able to achieve that system speedup that allows you to remove a number of servers from your cluster in the first place. However, I think you are right that on small number of servers speeding up parallel part can have a more immediate effect. I did a small calculation just to check the numbers. Assume you have a server that can do 100 RPS. You can either speed up the parallel code 2x (let's be realistic here and stop this 100x nonsense) and bring the RPS almost to 200 or you can take that serial code that is just a fraction and reduce it by half, so that f=0.995 and not 0.99 (and adding a marginal RPS increase to 102 RPS). Here is the plot: https://imgur.com/a/7w1hms9 https://imgur.com/a/7w1hms9 Edit: read http://www.frankmcsherry.org/assets/COST.pdf http://www.frankmcsherry.org/assets/COST.pdf as recommended in the upvoted comment above!

CyberDildonics 6y ago
I think you are building on misunderstanding with assumptions that aren't backed up by anything. > non-parallelizable part Which part is that? Synchronization does not have to be expensive. The original paper had a theoretical 'serial' part of a program, but synchronization is different in that it can be very fast and doesn't tie up other resources. For a web server the synchronization is in IO, which is being handled by queues. It doesn't stall cores, processes or threads can put their data in a queue and another core can handle it. > You can either speed up the parallel code 2x (let's be realistic here and stop this 100x nonsense) Far from it. If python is translated to C++ directly you would already have a massive speedup (I would guess at least 20x, maybe more). If memory allocations are minimized you get another huge (7x) speedup on top of that. If larger chunks are dealt with at one time you get another huge speedup. I think 100x would be common. Amdahl's Law is really about diminishing returns when there are significant places that need to be serial. Any emulator can be a good example. There aren't nearly as many scenarios that have to be serial as most people think.

CyberDildonics 6y ago

I think you are building on misunderstanding with assumptions that aren't backed up by anything. > non-parallelizable part Which part is that? Synchronization does not have to be expensive. The original paper had a theoretical 'serial' part of a program, but synchronization is different in that it can be very fast and doesn't tie up other resources. For a web server the synchronization is in IO, which is being handled by queues. It doesn't stall cores, processes or threads can put their data in a queue and another core can handle it. > You can either speed up the parallel code 2x (let's be realistic here and stop this 100x nonsense) Far from it. If python is translated to C++ directly you would already have a massive speedup (I would guess at least 20x, maybe more). If memory allocations are minimized you get another huge (7x) speedup on top of that. If larger chunks are dealt with at one time you get another huge speedup. I think 100x would be common. Amdahl's Law is really about diminishing returns when there are significant places that need to be serial. Any emulator can be a good example. There aren't nearly as many scenarios that have to be serial as most people think.