Subject: Re: [boost] [beast] Request for Discussion
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2016-09-23 16:04:47
On Sep 23, 2016, at 11:50 AM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> As I was saying to David Sankel and Roland Bock yesterday when we
> were discussing HTTP and BEAST, I really wouldn't care if you stuck
> O(N^N) complexity loops into your implementation and throw in a
> pointless sleep(500ms) for good measure in an initial implementation.
> *I don't care about the quality of the implementation*. I only care,
> for now, about the solid design of the top level API. Once we have a
> working implementation of that which has passed Boost peer review,
> everything else will follow naturally.
Fwiw, I have observed many examples of this purely âtop-downâ design over the decades. I have even seen some of them result in reasonably functional software. All too often, not even that. The result nearly always works, but often the top-level API dictates an inefficient implementation, and the top-level API gets locked-in by issues such as backwards compatibility and/or resource constraints.
These are not hypothetical concerns. When a 2GHz 4-core dedicated computer canât keep up with my wifeâs typing speed, something has gone horribly wrong in many places up and down the software stack.
I am not alone in recognizing these shortcomings and many people have gravitated towards a âbottom-upâ approach: Build a solid low-level foundation first which emphasizes performance. Higher-level software layers can add functionality. I have personally participated in several low-level projects with this âbottom-upâ view: unique_ptr, mutex, condition_variable, thread, and more recently low-level date algorithms:
Iâve had considerable success with this approach, but it is not perfect. As I add the higher-level API I sometimes find a missing brick in the foundation. There is nothing like real-world testing of low-level foundation software to find missing or poorly specified functionality, and building that higher-level API upon the lower-level *is* that real-world testing.
If that higher-level testing can be done prior to setting the lower-level API in stone, one can achieve a valuable feedback loop where the lower-level level API can be improved while the high-level API is under development.
I have also found that a high-performance low-level API usually guides the higher-level design. It encourages the high-level API to not do things that are gratuitously inefficient, as long as the low-level API stands its ground on delegating expensive fancy features to the higher-level.
In the end, the very most important thing for software to be is correct. However, the next most important thing is run time performance:
Correctness can be achieved with top-down or bottom-up. But bottom-up combined with early feedback from the top-down lends itself towards a software stack that is both fully functional and high performance.
This is the philosophy I have followed for the software stack discussed in this Cppcon 2016 talk:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk