In other videos Casey argues against the profile–fix–repeat workflow (I’m not saying that you necessarily meant this by measuring), instead arguing for estimating the theoretical maximum, then trying to get close enough to it. His argument is that the former might push you towards a local minimum without realising that you could do much better

▲

tialaramex a day ago | parent | next [-]

When "Estimating the theoretical maximum" you're going to bring your assumptions to that estimate and so you're equally likely to get stuck in some local optimal point because you didn't see what else was possible, so that doesn't persuade me much. Worse, now it's a local optimal which might be entirely in your head.

There is some space for this "Estimate the theoretical maximum" as a high level insight, if the software needs to do a thing which your estimate says is impossible that's important to address up front but I think for practical software engineering you're much more likely to need profile-fix-repeat

Actually measuring is crucial and an estimate is not a measurement. I think one of the reasons many in the Handmade Community don't like measuring is that it too often ruins their "estimate" of how the crap they've written is achieving a "theoretical maximum" in favour of a boring fact that it's much worse than alternatives.

	▲	zipy124 5 hours ago \| parent [-]
		Usually the ideas it that the theoretical maximum is not a local optima though, but some ideal global optima which you know you realistically cannot reach. That is you know the data is some size, and memory throughput is some rate, and clock cycles is some rate etc... You are entirely correct about the line of thinking if your assumptions are down a different line of thinking such as algorithmic estimates though, where you might miss some better way of doing things.

▲

zipy124 5 hours ago | parent | prev [-]

I've always used this method of working and can stand by it. For instance let's say you are working on a high-speed real-time image processing system. If you know that each image is 1080p for instance, that's 2 million pixels, and we will have 3 bytes per pixel for colour, then that's like 6MB per image (without compression). If you have 25 GB/s of RAM bandwidth, then there is a hard limit of ~4 thousand frames per second if you aren't even doing any processing. Therefore if you strip out your processing and are only getting say 400 frames per second, you know something is going wrong.

This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.

Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.