Boost logo

Boost :

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:

http://howardhinnant.github.io/date_algorithms.html

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:

http://howardhinnant.github.io/coding_guidelines.html

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.

<shameless plug>
This is the philosophy I have followed for the software stack discussed in this Cppcon 2016 talk:

http://schd.ws/hosted_files/cppcon2016/0f/Welcome%20To%20The%20Time%20Zone%20-%20Howard%20Hinnant%20-%20CppCon%202016.pdf
</shameless plug>

Howard




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk