31–40 of 153 posts
If you want to learn how to understand the performance of the whole system I can recommend Brendan Gregg's Systems Performance: Enterprise and the Cloud ( https://www.brendangregg.com/blog/2020-07-15/systems-perform... ). It is a good book that teaches a lot of basics and techniques and gives a good understanding of the impact different system components can have on performance.
Performance optimization covers a lot of topics, it depends on what you are trying to optimize. 1. Latency vs throughput. Oftentimes they are the same, i.e. reduce the time it takes to do something. However, when you passed a certain threshold, techniques that can optimize throughput will hurt latency, so it is important to know what you are looking for. There are also low level details if you have rather extreme lat…
Latency and thruput are never the same, they don't even have the same units so they can't be the same.
Advice to OP. Learn how to make measurements, and you'll never make mistakes like these.
Performance optimization covers a lot of topics, it depends on what you are trying to optimize. 1. Latency vs throughput. Oftentimes they are the same, i.e. reduce the time it takes to do something. However, when you passed a certain threshold, techniques that can optimize throughput will hurt latency, so it is important to know what you are looking for. There are also low level details if you have rather extreme lat…
> Latency vs throughput. Oftentimes they are the same Latency and thruput are never the same, they don't even have the same units so they can't be the same. Advice to OP. Learn how to make measurements, and you'll never make mistakes like these.
Performance optimization covers a lot of topics, it depends on what you are trying to optimize. 1. Latency vs throughput. Oftentimes they are the same, i.e. reduce the time it takes to do something. However, when you passed a certain threshold, techniques that can optimize throughput will hurt latency, so it is important to know what you are looking for. There are also low level details if you have rather extreme lat…
> Latency vs throughput. Oftentimes they are the same Latency and thruput are never the same, they don't even have the same units so they can't be the same. Advice to OP. Learn how to make measurements, and you'll never make mistakes like these.
OP is right that you can often improve both at the same time, it's just worded poorly.
My playbook for optimizing in the real world is something like this: 1. Understand what you're actually trying to compute end-to-end. The bigger the chunk you're trying to optimize, the greater the potential for performance.
2. Sketch out what an optimal process would look like. What data do you need to fetch, what computation do you need to do on this, how often does this need to happen. Don't try to be clever and micro-optimize or cache computations. Just focus on only doing the things you need to do in a simple way. Use arrays a lot.
3. Understand what the current code is actually doing. How close to the sketch above are you? Are you doing a lot of I/O in the middle of the computation? Do you keep coming back to the same data?
If you want to understand the limits of how fast computers are, and what optimal performance looks like I'd recommend two talks that come with a very different perspective from what you usually hear:
1. Mike Acton's talk at cppcon 2014 https://www.youtube.com/watch?v=rX0ItVEVjHc
2. Casey Muratori's talk about optimizing a grass planting algorithm https://www.youtube.com/watch?v=Ge3aKEmZcqY
Performance optimization covers a lot of topics, it depends on what you are trying to optimize. 1. Latency vs throughput. Oftentimes they are the same, i.e. reduce the time it takes to do something. However, when you passed a certain threshold, techniques that can optimize throughput will hurt latency, so it is important to know what you are looking for. There are also low level details if you have rather extreme lat…
The idea to classify cycles into front-end bound, backend bound, bad speculation or memory bound is brilliant. Once you know which one your program suffers from, it's easy to know what can be done to improve things.
Out of curiosty, what are you optimising exactly?
I guess there are some common parts like profiling and statistics, but thats about it.
Most software in the industry is slow because it's doing a lot of stuff that it shouldn't. Often times additional "optimization" layers adds caching, but makes getting to the root of the issue harder. The biggest win is primarily getting rid of things you don't need and secondarily operating on things in batch. My playbook for optimizing in the real world is something like this: 1. Understand what you're actually try…