You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kvrocks.apache.org by GitBox <gi...@apache.org> on 2022/10/10 08:56:25 UTC
[GitHub] [incubator-kvrocks] PragmaTwice created a discussion: Update the C++ standard used by kvrocks to a newer version
GitHub user PragmaTwice created a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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 and 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.
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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 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 the compiler. 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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
I think the standard can hardly affect the real performance without code changes, but the compiler and its version matters.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3838606
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Yes, agree to upgrade to C++17 first, so that we can follow up RocksDB 7.x new features.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3849438
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 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 the compiler. 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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 a decade old antique compiler (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
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
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 )
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3849402
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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 and 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.
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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 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 the compiler. 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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3866162
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 the compiler. 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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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.
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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 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 the compiler. 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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 old (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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
clang: 5 or above
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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] torwig added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user torwig added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
In my opinion, if we don't have anything that can stop us from using the C++17 standard (e.g. `kvrocks` **must** support some old OS that has a compiler that doesn't aware of C++17 or some **dependency doesn't support C++17** or something else), `kvrocks` definitely can use C++17.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3897495
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 a decade old antique compiler (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. We do place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Cool, good news!
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3838086
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] tanruixiang added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user tanruixiang added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Hi. I noticed that you have a pr about redis-benchmark. Have you tested the performance data of the two C++ versions?
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3838469
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
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.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3866162
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
In our private fork, all current code of kvrocks building ok without any changes in C++17
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3838010
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] tanruixiang added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user tanruixiang added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
> I think the standard can hardly affect the real performance without code changes, but the compiler and its version matters.
I think this at least provides a proof that the upgrade was successful.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839128
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
> I think this at least provides a proof that the upgrade was successful.
That's a good point.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839159
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
It is fine, I will fix these errors if we need to compile in c++20 : )
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839115
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
It is fine, I will fix these error if we need to compile in c++20.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839115
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
At this time we have not a clear test, but this is cool idea. Need to test it
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3838501
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
So, I have a dirty benchmark of two version of kvrocks, cpp11 (a current head, commit [f91aad6](https://github.com/apache/incubator-kvrocks/commit/f91aad6246290c7ecd307606e8922dfd04a2fcf6)) and cpp17:
**cpp11**:
> PING_INLINE: 56980.06 requests per second, p50=0.415 msec
> PING_MBULK: 60679.61 requests per second, p50=0.399 msec
> SET: 34340.66 requests per second, p50=0.711 msec
> GET: 43535.05 requests per second, p50=0.575 msec
> INCR: 29463.76 requests per second, p50=0.775 msec
> LPUSH: 25555.84 requests per second, p50=0.759 msec
> RPUSH: 25947.07 requests per second, p50=0.815 msec
> LPOP: 22276.68 requests per second, p50=0.791 msec
> RPOP: 22537.75 requests per second, p50=0.591 msec
> SADD: 31230.48 requests per second, p50=0.775 msec
> HSET: 20529.67 requests per second, p50=0.751 msec
> SPOP: 53163.21 requests per second, p50=0.455 msec
> ZADD: 26525.20 requests per second, p50=0.895 msec
> ZPOPMIN: 47846.89 requests per second, p50=0.543 msec
> LPUSH (needed to benchmark LRANGE): 24348.67 requests per second, p50=0.783 msec
> LRANGE_100 (first 100 elements): 15206.81 requests per second, p50=1.727 msec
> LRANGE_300 (first 300 elements): 6825.01 requests per second, p50=3.815 msec
> LRANGE_500 (first 500 elements): 3684.46 requests per second, p50=7.087 msec
> LRANGE_600 (first 600 elements): 3201.84 requests per second, p50=8.127 msec
> MSET (10 keys): 8602.15 requests per second, p50=1.007 msec
**cpp17**:
> PING_INLINE: 63734.86 requests per second, p50=0.383 msec
> PING_MBULK: 65573.77 requests per second, p50=0.383 msec
> SET: 34638.03 requests per second, p50=0.727 msec
> GET: 53304.90 requests per second, p50=0.407 msec
> INCR: 28843.38 requests per second, p50=0.823 msec
> LPUSH: 25425.88 requests per second, p50=0.847 msec
> RPUSH: 25680.53 requests per second, p50=0.871 msec
> LPOP: 22737.61 requests per second, p50=0.759 msec
> RPOP: 23299.16 requests per second, p50=0.639 msec
> SADD: 32092.43 requests per second, p50=0.783 msec
> HSET: 21399.53 requests per second, p50=0.639 msec
> SPOP: 50709.94 requests per second, p50=0.479 msec
> ZADD: 28530.67 requests per second, p50=0.799 msec
> ZPOPMIN: 59844.41 requests per second, p50=0.391 msec
> LPUSH (needed to benchmark LRANGE): 23435.67 requests per second, p50=0.719 msec
> LRANGE_100 (first 100 elements): 16401.51 requests per second, p50=1.671 msec
> LRANGE_300 (first 300 elements): 6204.63 requests per second, p50=4.207 msec
> LRANGE_500 (first 500 elements): 4082.63 requests per second, p50=6.591 msec
> LRANGE_600 (first 600 elements): 3363.95 requests per second, p50=7.927 msec
> MSET (10 keys): 8397.72 requests per second, p50=1.079 msec
All benchmarks running in same machine (Debian 12 x64).
Run own benchmark: run ./kvrocks without options and then redis-benchmark -p 6666 -q
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839156
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a comment on the discussion: Update the C++ standard used by kvrocks to a newer version
It is fine, I will fix these errors if we need to compile in c++20.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839115
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a discussion: Update the C++ standard used by kvrocks to a newer version
C++ is an evolving language led by WG21 ([ISO/IEC JTC1/SC22/WG21](https://www.open-std.org/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):
- clickhouse: c++20
- bitcoin: c++20
- mongodb: c++17 or c++20
- godot: c++17
- llvm: c++17
- taichi: c++17
- mysql: c++17
- rocksdb: c++17
- grpc: c++14
- tensorflow: c++14
- pytorch: c++14
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 a decade old antique compiler (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. We will place restrictions on the compiler versions that users can use, and these restrictions are as follows:
gcc: 7 or above
clang: 5 or above
I'm 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Current code compiled at c++17, but have a lot of errors in c++20
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3839071
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Posted by GitBox <gi...@apache.org>.
GitHub user aleksraiden added a comment to the discussion: Update the C++ standard used by kvrocks to a newer version
Some performance test after c++17 ([42517c5](https://github.com/apache/incubator-kvrocks/commit/42517c576f94067b826df732ae1f55c5a390e40f)
PING_INLINE: 46970.41 requests per second, p50=0.519 msec
PING_MBULK: 56242.97 requests per second, p50=0.431 msec
SET: 34188.04 requests per second, p50=0.743 msec
GET: 48828.12 requests per second, p50=0.503 msec
INCR: 30257.19 requests per second, p50=0.807 msec
LPUSH: 24479.80 requests per second, p50=0.871 msec
RPUSH: 24576.06 requests per second, p50=0.687 msec
LPOP: 22306.49 requests per second, p50=0.807 msec
RPOP: 22426.55 requests per second, p50=0.687 msec
SADD: 29770.77 requests per second, p50=0.767 msec
HSET: 22099.45 requests per second, p50=0.511 msec
SPOP: 50581.69 requests per second, p50=0.503 msec
ZADD: 28587.77 requests per second, p50=0.807 msec
ZPOPMIN: 57175.53 requests per second, p50=0.399 msec
LPUSH (needed to benchmark LRANGE): 23546.03 requests per second, p50=0.799 msec
LRANGE_100 (first 100 elements): 16846.36 requests per second, p50=1.583 msec
LRANGE_300 (first 300 elements): 7399.19 requests per second, p50=3.471 msec
LRANGE_500 (first 500 elements): 5024.62 requests per second, p50=5.327 msec
LRANGE_600 (first 600 elements): 4029.33 requests per second, p50=6.607 msec
MSET (10 keys): 8901.55 requests per second, p50=1.039 msec
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/970#discussioncomment-3904645
----
This is an automatically sent email for dev@kvrocks.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@kvrocks.apache.org