Add the missing YCSB entrypoint for SS2PL - #120
Merged
Conversation
`cc/ss2pl/CMakeLists.txt` registered only `bomb` and `tpcc`, so no `ycsb_ss2pl.exe` was ever built and SS2PL could not be measured on YCSB at all. `cmake --build <dir> --target ycsb_ss2pl.exe` fails with "No rule to make target". The pre-cmake YCSB main survived as `cc/ss2pl/ss2pl.cc`, but it is dead code: it is outside the build graph (the `ccbench_add_protocol` convention picks up `<workload>_<protocol>.cc`, which it does not match) and it calls the two-argument `TxExecutor` constructor that no longer exists. Nothing references it, so remove it rather than leave a file that cannot compile. - add `cc/ss2pl/ycsb_ss2pl.cc`, modelled on `cc/silo/ycsb_silo.cc` and `cc/ss2pl/bomb_ss2pl.cc`: the shared `ccbench::run<TxExecutor, TransactionStatus, YcsbWorkload>` runner with the current three-argument factory - add `ycsb` to the protocol's `WORKLOADS` - delete the dead `cc/ss2pl/ss2pl.cc` - mark SS2PL's YCSB column as supported in `README.md` and in both `docs/protocols_ja.md` and `docs/protocols_en.md` (each has a protocol table and a matrix snapshot; the snapshots were checked against a regenerated `build/PROTOCOL_MATRIX.md`, which is not committed) Not changed on purpose: - `cc/ss2pl/util.cc` is untouched. `chkArg()` validates the protocol-local legacy `FLAGS_rratio` rather than the `FLAGS_ycsb_rratio` the YCSB workload actually reads, but that mismatch is repo-wide (`cc/silo` disabled the same check) and fixing it only for this binary would make SS2PL's YCSB entrypoint behave differently from every other one. - With `ycsb_ss2pl.exe` in place, YCSB aborts are counted twice: once in `TxExecutor::abort()` and once in the workload loop in `include/ycsb.hh`. That is a pre-existing issue in the shared workload header, not specific to SS2PL, and is left for a separate change. - The per-protocol `README.md` and `script/*.sh` still refer to the old `ss2pl.exe` name and positional CLI. The same staleness exists under `cc/silo/`, so it is out of scope here. Verified on an Intel Xeon Platinum 8468 (48 physical cores): - `cmake --build` of every protocol with `-DCMAKE_BUILD_TYPE=Release`, `-Wall -Wextra -Werror`, under g++ 11.4 and g++ 12 - `ycsb_ss2pl.exe -ycsb_tuple_num=1000000 -ycsb_max_ope=10 -ycsb_rratio=50 -ycsb_zipf_skew=0 -thread_num=48 -extime=5` exits 0 at 7,800,905 tps (abort rate 0.0031) - `tpcc_ss2pl.exe` and `bomb_ss2pl.exe` are unaffected: their `.text` sections are byte-identical to a build of the parent commit - the `clang-format --dry-run --Werror` check from `.github/workflows/format.yml` passes with clang-format 14 GCC 13, which CI uses, was not available on the test machine, so the `-Werror` result there is unverified. This change was written with AI assistance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cc/ss2pl/CMakeLists.txtregistered onlybombandtpcc, so noycsb_ss2pl.exewas ever built and SS2PL could not be measured on YCSB at all.cmake --build <dir> --target ycsb_ss2pl.exefails with "No rule to make target".The pre-cmake YCSB main survived as
cc/ss2pl/ss2pl.cc, but it is dead code: it is outside the build graph (theccbench_add_protocolconvention picks up<workload>_<protocol>.cc, which it does not match) and it calls the two-argumentTxExecutorconstructor that no longer exists. Nothing references it, so remove it rather than leave a file that cannot compile.cc/ss2pl/ycsb_ss2pl.cc, modelled oncc/silo/ycsb_silo.ccandcc/ss2pl/bomb_ss2pl.cc: the sharedccbench::run<TxExecutor, TransactionStatus, YcsbWorkload>runner with the current three-argument factoryycsbto the protocol'sWORKLOADScc/ss2pl/ss2pl.ccREADME.mdand in bothdocs/protocols_ja.mdanddocs/protocols_en.md(each has a protocol table and a matrix snapshot; the snapshots were checked against a regeneratedbuild/PROTOCOL_MATRIX.md, which is not committed)Not changed on purpose:
cc/ss2pl/util.ccis untouched.chkArg()validates the protocol-local legacyFLAGS_rratiorather than theFLAGS_ycsb_rratiothe YCSB workload actually reads, but that mismatch is repo-wide (cc/silodisabled the same check) and fixing it only for this binary would make SS2PL's YCSB entrypoint behave differently from every other one.ycsb_ss2pl.exein place, YCSB aborts are counted twice: once inTxExecutor::abort()and once in the workload loop ininclude/ycsb.hh. That is a pre-existing issue in the shared workload header, not specific to SS2PL, and is left for a separate change.README.mdandscript/*.shstill refer to the oldss2pl.exename and positional CLI. The same staleness exists undercc/silo/, so it is out of scope here.Verified on an Intel Xeon Platinum 8468 (48 physical cores):
cmake --buildof every protocol with-DCMAKE_BUILD_TYPE=Release,-Wall -Wextra -Werror, under g++ 11.4 and g++ 12ycsb_ss2pl.exe -ycsb_tuple_num=1000000 -ycsb_max_ope=10 -ycsb_rratio=50 -ycsb_zipf_skew=0 -thread_num=48 -extime=5exits 0 at 7,800,905 tps (abort rate 0.0031)tpcc_ss2pl.exeandbomb_ss2pl.exeare unaffected: their.textsections are byte-identical to a build of the parent commitclang-format --dry-run --Werrorcheck from.github/workflows/format.ymlpasses with clang-format 14GCC 13, which CI uses, was not available on the test machine, so the
-Werrorresult there is unverified.This change was written with AI assistance.