Update the C++ standard used by kvrocks to a newer version #970
Replies: 5 comments 10 replies
-
|
In our private fork, all current code of kvrocks building ok without any changes in C++17 |
Beta Was this translation helpful? Give feedback.
-
|
I think the standard can hardly affect the real performance without code changes, but the compiler and its version matters. |
Beta Was this translation helpful? Give feedback.
-
|
Current code compiled at c++17, but have a lot of errors in c++20 |
Beta Was this translation helpful? Give feedback.
-
|
It is fine, I will fix these errors if we need to compile in c++20 : ) |
Beta Was this translation helpful? Give feedback.
-
I think this at least provides a proof that the upgrade was successful. |
Beta Was this translation helpful? Give feedback.
-
That's a good point. |
Beta Was this translation helpful? Give feedback.
-
|
So, I have a dirty benchmark of two version of kvrocks, cpp11 (a current head, commit f91aad6) and cpp17: cpp11:
cpp17:
All benchmarks running in same machine (Debian 12 x64). Run own benchmark: run ./kvrocks without options and then redis-benchmark -p 6666 -q |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, at stage 1 we could switch codebase into cpp17, and then, after some time of stabilizations, prepare PR to fix all issues in cpp20. C++20 close our problem for next ~5 years ) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, agree to upgrade to C++17 first, so that we can follow up RocksDB 7.x new features. |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, please do not hesitate to speak up and give your opinion! If there is no objection, I will prepare a standard updating PR in a few days. cc @apache/kvrocks-committers |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion, if we don't have anything that can stop us from using the C++17 standard (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Some performance test after c++17 (42517c5 PING_INLINE: 46970.41 requests per second, p50=0.519 msec |
Beta Was this translation helpful? Give feedback.
-
C++ is an evolving language led by WG21 (ISO/IEC JTC1/SC22/WG21), which has been significantly modified over the years to improve ease of use and expressiveness while maintaining the zero-overhead principle.
The latest experimental standard for C++ is C++23 (also known as C++2b), and the latest stable standard is C++20. After C++11, WG21 has made a number of sweeping improvements to make modern C++ even more exciting. Among them, C++14 [1] can be regarded as a series of small patches to C++11, which complemented the unsatisfactory parts of C++11, such as lifting some of the restrictions on constexpr functions, supporting variable templates and polymorphic lambdas; while C++17 [2] is a relatively big change, it supports constexpr if, guarantees more copy elision to improve efficiency, specifies a more explicit execution order to eliminate undefined behaviors, and brings several new library components such as filesystem, basic_string_view, any, optional, variant, and other class templates.
The industry has gradually become more comfortable with the new C++ standard, and here are some notable open source projects and the C++ standard they are using (in the main branch):
I want kvrocks to use a newer C++ standard to apply rich new features to improve code quality and maintainability and have the ability to use the current version of rocksdb rather than stucking into an old version, and in particular, I want to update the standard to at least C++17. It is important to note that the new C++ standard will have significant breaking changes in only a few cases, but we can sort out later whether these changes will affect kvrocks. Also, all developers' experience with c++11 can continue to be used in the new standard.
C++17 requires a newer version of compilers like gcc or clang. In fact, this can be a compiler version from a few years ago (e.g., gcc7, 2017), but not an antique compiler from a decade ago (e.g., gcc 4.8, 2013). As with the very new version of go 1.18 that we are currently using, I see no harm in encouraging users to use as newer versions of the compiler as possible, as long as they are not unstable versions. To use C++17, we will place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above (current latest release: 12)
clang: 5 or above (current latest release: 15)
I am not quite sure what expectations, concerns and questions people have about updating the standards at this point, and I look forward to everyone expressing their views on this issue!
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html
[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0636r2.html
Beta Was this translation helpful? Give feedback.
All reactions