On 23/09/2020 14:21, Peter Dimov via Boost wrote:
Niall Douglas wrote:
For the record, I've had offlist email discussions about proposed Boost.JSON with a number of people where the general feeling was that there was no point in submitting a review, as negative review feedback would be ignored, possibly with personal retribution thereafter, and the library was always going to be accepted in any case.
Personal retribution, really?
Some have interpreted it as such yes. I have a raft of private email that just arrived there after my post here recounting their stories about being on the receiving end of Vinnie's behaviour, and/or thanking me for writing that post. Richard, I appreciate your "they're being snowflakes" response and standing up for your friend, that was good of you. You should be aware that I've known Vinnie longer than you, possibly as long as anyone here. I think you'll find you're in the "get it done" philosophical camp (at least that's my judgement of you from studying the code you write), so Vinnie's fine with you. I have noticed, from watching him on the internet, he tends to find most issue with those in the "aim for perfection" philosophical camp. Vinnie particularly dislikes other people's visions of abstract perfection if it makes no sense to him, if it's abtuse, or he doesn't understand it. If you're in that camp, then you might have a very different experience than what you've had. Nevertheless, I believe Vinnie's opinion is important as representative of a significant minority of C++ users, and I think it ought to continue to be heard. I might add that the said "snowflakes" that I've spoken to have all to date agreed with that opinion, we're perfectly capable of withstanding severe technical criticism, indeed some of us serve on WG21 where every meeting is usually a battering of oneself. Anyway, I have no wish to discuss this further, all I want to say has been said.
Consider this: a Hana Dusíková type all-constexpr JSON parser could let you specify to the compiler at compile time "this is the exact structure of the JSON that shall be parsed". The compiler then bangs out optimum parse code for that specific JSON structure input. At runtime, the parser tries the pregenerated canned parsers first, if none match, then it falls back to runtime parsing.
To go on your tangent, I, personally, think that compile-time parsing is overrated because it's cool. Yes, CTRE is a remarkable accomplishment, and yes, Tim Shen, the author of libstdc++'s <regex> also thinks that compile-time regex parsing is the cure for <regex>'s ills. But I don't think so. In my unsubstantiated opinion, runtime parsing can match CTRE's performance, and the only reason current engines don't is because they are severely underoptimized.
Hana's runtime benchmarks showed her regex implementation far outpacing any of those in the standard libraries. Like, an order of magnitude in absolute terms, linear scaling to load instead of exponential for common regex patterns. A whole new world of performance. Part of why her approach is so fast is because she didn't implement all of regex. But another part is because she encodes the parse into relationships between literal types which the compiler can far more aggressively optimise than complex types. So basically the codegen is way better, because the compiler can eliminate a lot more code.
Similarly, I doubt that a constexpr JSON parser will even match simdjson, let alone beat it.
simdjson doesn't have class leading performance anymore. There are faster alternatives depending on your use case. Niall