4 ms·

That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it, and only then s

by YZF 8y ago

That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it, and only then start optimizing. That's not engineering, that's trial and error. You can absolutely aim for both correctness and performance in your design. In fact performance is (can be) part of correctness, if it doesn't perform to spec then it's most likely not useful. If you don't care about performance, fine, don't design for it and don't optimize. Your starting point for optimization has to be a solid design with specific performance goals in mind. If you have a solid design maybe you won't need to do any optimization, if you do it's going to be optimizing on top of the design.

not_kurt_godel 8y ago
> That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it, and only then start optimizing. That's not engineering, that's trial and error. Sorry, but that's a terrible analogy. "Performance", by definition of the context of this general discussion, is outside of spec. A ball of steel with an engine strapped on that doesn't fly isn't within spec. A more appropriate analogy for a fighter jet would be cost optimization (and yes, I realize that's not perfect, but bear with me). The first priority is getting the jet doing what it needs to do. If you design the thing to be made of 90% gold and platinum, then yes, optimizing cost is going to be impossible. But if you keep things semi-reasonable materials-wise, you can (presumably) optimize the manufacturing process post-facto to be more economically friendly.
- YZF 8y ago
  Performance can't be outside spec. Performance is part of the spec. Maybe it says "don't care" but it's gotta be in the spec and if it says "don't care" it better be you really don't care. If you have performance targets you have to design towards them - don't meet all the other goals and only then start thinking about performance.
stcredzero 8y ago
That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it Very bad analogy. We have 80 years of past knowledge around designing fighter jets. The advice is to use actual data and knowledge, not suppositions. There is actual data around building certain kinds of servers. What I'm advocating is using actual data and experience. What you are advocating is to "melt a ball of steel into some shape, put an engine on it, and try to fly it." There's a wealth of aerodynamic engineering knowledge. Why not apply that and make a better shape, based on past art designing aircraft of the kind you want to build? However, you shouldn't try to flight test and speed optimize that airplane if it can't yet fly properly, like if it's a vaguely shaped ball of steel with an engine on it. That would be counterproductive, if not dangerous. That is what I'm advising against in my comment and with the Kent Beck anecdote. Are you advocating to flight test and speed optimize that airplane if it can't yet fly properly? (EDIT: Note that, even with this built up knowledge, there is still a lot of testing done, because often what engineers think they've built is not what they've actually built. Isn't what you're advocating more like just assuming you've built what you think you've built?)
- snovv_crash 8y ago
  We also have a wealth of knowledge about computer architecture and what software design decisions will result in performance problems or benefits. At a high level, trying to design, eg, a computer vision application that has to upload gigabytes of data to the cloud, will result in poor performance. At the low level, iterating over linked lists is slower than memory contiguous arrays, especially if your data is too big to fit in cache. The low-level knowledge that inlined methods let the compiler eliminate branches and vectorize code more effectively, informs the mid level architects that if everything is done by inheritance you lose this advantage since everything has to go through the vtable. For too long we've been able to make poor performance decisions and be rescued by Moore's law; no more. We will find in the upcoming years that performance is an architectural decision that can come back to bite us if we don't design for it up-front.
- YZF 8y ago
  I'm advocating for coming up with a software design that we think can support all the requirements including performance. Not writing random code in the hope that it can be optimized to meet the performance requirements once the other requirements have been met. The fighter jet design is upfront about all its requirements. Does the design require some tweaks one you start flight tests, you bet, but if it's on the completely wrong path the project is doomed. Just like software projects.

by YZF 8y ago

not_kurt_godel 8y ago

> That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it, and only then start optimizing. That's not engineering, that's trial and error. Sorry, but that's a terrible analogy. "Performance", by definition of the context of this general discussion, is outside of spec. A ball of steel with an engine strapped on that doesn't fly isn't within spec. A more appropriate analogy for a fighter jet would be cost optimization (and yes, I realize that's not perfect, but bear with me). The first priority is getting the jet doing what it needs to do. If you design the thing to be made of 90% gold and platinum, then yes, optimizing cost is going to be impossible. But if you keep things semi-reasonable materials-wise, you can (presumably) optimize the manufacturing process post-facto to be more economically friendly.

YZF 8y ago
Performance can't be outside spec. Performance is part of the spec. Maybe it says "don't care" but it's gotta be in the spec and if it says "don't care" it better be you really don't care. If you have performance targets you have to design towards them - don't meet all the other goals and only then start thinking about performance.

stcredzero 8y ago

That's like saying we can't design a fighter jet so we're going to melt a ball of steel into some shape, put an engine on it, and try to fly it Very bad analogy. We have 80 years of past knowledge around designing fighter jets. The advice is to use actual data and knowledge, not suppositions. There is actual data around building certain kinds of servers. What I'm advocating is using actual data and experience. What you are advocating is to "melt a ball of steel into some shape, put an engine on it, and try to fly it." There's a wealth of aerodynamic engineering knowledge. Why not apply that and make a better shape, based on past art designing aircraft of the kind you want to build? However, you shouldn't try to flight test and speed optimize that airplane if it can't yet fly properly, like if it's a vaguely shaped ball of steel with an engine on it. That would be counterproductive, if not dangerous. That is what I'm advising against in my comment and with the Kent Beck anecdote. Are you advocating to flight test and speed optimize that airplane if it can't yet fly properly? (EDIT: Note that, even with this built up knowledge, there is still a lot of testing done, because often what engineers think they've built is not what they've actually built. Isn't what you're advocating more like just assuming you've built what you think you've built?)

snovv_crash 8y ago
We also have a wealth of knowledge about computer architecture and what software design decisions will result in performance problems or benefits. At a high level, trying to design, eg, a computer vision application that has to upload gigabytes of data to the cloud, will result in poor performance. At the low level, iterating over linked lists is slower than memory contiguous arrays, especially if your data is too big to fit in cache. The low-level knowledge that inlined methods let the compiler eliminate branches and vectorize code more effectively, informs the mid level architects that if everything is done by inheritance you lose this advantage since everything has to go through the vtable. For too long we've been able to make poor performance decisions and be rescued by Moore's law; no more. We will find in the upcoming years that performance is an architectural decision that can come back to bite us if we don't design for it up-front.
YZF 8y ago
I'm advocating for coming up with a software design that we think can support all the requirements including performance. Not writing random code in the hope that it can be optimized to meet the performance requirements once the other requirements have been met. The fighter jet design is upfront about all its requirements. Does the design require some tweaks one you start flight tests, you bet, but if it's on the completely wrong path the project is doomed. Just like software projects.