fix(mrcProfiler): keep MINISIM's hash tables small, and require a thread count

MINISIM builds one cache per profile point and holds them all at once, so
every point pays for its own hash table. Sizing those tables the way cachesim
does -- hashpower 24, 128MiB apiece -- costs 12.8GiB at the default
--size=0.01,1,100 and was OOM-killed on one run here; hashpower 20 peaks at
0.8GiB and finishes 27x faster.

The larger table bought exactness for a single policy. Measured at 100MB on
cloudPhysicsIO.oracleGeneral, five runs each, only randomTwo moves: 0.8215
against cachesim's 0.8220. lru, fifo, arc, s3fifo, sieve, twoq, lfu, clock,
gdsf, hyperbolic and randomLRU already agree to four decimals, and random and
lecar seed from the clock and vary between runs on both sides, so no table
size makes those two match. One policy's 0.0005 is not worth 15x the memory;
the comment records what closing that gap properly would take.

Separately, MINISIM's thread_num is only assigned when a third parameter is
present, so --profiler-params=FIX_RATE,1 left it at 0, skipped the validation
that guards it, and aborted inside the thread pool with "cannot push data
into thread_pool in get_miss_ratio" -- saying nothing about the parameter
that was actually missing. Reject that form where the other parameter errors
are raised. SHARDS is unaffected: its optional third field is a salt, and 0
is a valid salt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YUq1vM4g82TkaX2jvLmuQc

Author: claude

libCacheSim/mrcProfiler/mrcProfiler.cpp

@@ -25,14 +25,6 @@ static constexpr double kHashSpaceSize = 18446744073709551616.0;
  * caches are small, so a smaller table than cachesim's is appropriate. */
 static constexpr int kMiniSimHashPower = 20;
 
-/* what cachesim uses, mirroring DEFAULT_HASHPOWER in bin/cachesim/cache_init.h.
- * Above sample rate 0.5 MINISIM replays the whole trace, and that run is meant
- * to be exact rather than approximate, so it has to size the table the way
- * cachesim would: Random, RandomTwo, RandomLRU and Hyperbolic draw eviction
- * candidates through the hash mask, so a different table gives a different
- * curve. */
-static constexpr int kCacheSimHashPower = 24;
-
 /* whether a reader fills in req->next_access_vtime, which the Belady policies
  * need; every other reader leaves it at -2.
  *
@@ -380,14 +372,35 @@ void mrcProfiler::MRCProfilerMINISIM::run() {
 
   /* BeladySize picks its victim by drawing samples from the hash table, so an
    * oversized table costs memory and leaves the sampler probing empty buckets.
-   * cachesim shrinks it by 8 before constructing the cache; do the same here,
-   * since the miniature caches are built straight from the registry and would
-   * otherwise get a 1M-slot table each. Hyperbolic gets it for a different
-   * reason: Hyperbolic_init shrinks its own table as well, so cachesim ends up
-   * two reductions down, and matching that is what makes an unsampled run
-   * reproduce cachesim rather than land 0.0001 away. */
-  int minisim_hashpower =
-      (sampler == nullptr) ? kCacheSimHashPower : kMiniSimHashPower;
+   * cachesim shrinks it by 8 before constructing the cache, landing on 16;
+   * the miniature caches are built straight from the registry and would
+   * otherwise keep a 1M-slot table each, so the floor below puts them on 16
+   * too. Hyperbolic gets the same treatment for a different reason:
+   * Hyperbolic_init shrinks its own table as well, so cachesim ends up two
+   * reductions down, and starting from the same 16 is what makes an unsampled
+   * hyperbolic run reproduce cachesim to four decimals rather than land beside
+   * it. */
+  /* The table stays small even when sampling is off and MINISIM replays the
+   * whole trace, rather than growing to the hashpower cachesim would use.
+   * MINISIM builds one cache per profile point and holds them all at once, so
+   * the table is paid for once per point: at the default --size=0.01,1,100
+   * that is 100 of them, and cachesim's 24 would be 128MiB each. Measured on
+   * cloudPhysicsIO, that peaks at 12.8GiB and was OOM-killed on one run;
+   * hashpower 20 peaks at 0.8GiB and finishes 27x faster. --size accepts up to
+   * MAX_MRC_PROFILE_POINTS points, so the ceiling is higher still.
+   *
+   * What the smaller table costs: policies that draw eviction candidates
+   * through the hash mask can land slightly off a cachesim run at the same
+   * size. Measured at 100MB on cloudPhysicsIO.oracleGeneral, five runs each,
+   * the only reproducible gap is randomTwo -- 0.8215 here against cachesim's
+   * 0.8220. lru, fifo, arc, s3fifo, sieve, twoq, lfu, clock, gdsf, hyperbolic
+   * and randomLRU agree to four decimals. random and lecar disagree by a
+   * comparable amount, but they seed from the clock and move between runs on
+   * both sides, so no table size makes those two match. Closing randomTwo's
+   * gap would need simulate_with_multi_caches to build each cache when a
+   * thread picks it up instead of all of them up front -- a change to the
+   * simulator, not to this profiler. */
+  int minisim_hashpower = kMiniSimHashPower;
   if (strcasecmp(params_.cache_algorithm_str, "hyperbolic") == 0) {
     minisim_hashpower = MAX(minisim_hashpower - 8, 16);
   }

libCacheSim/mrcProfiler/mrcProfiler.h

@@ -178,6 +178,17 @@ typedef struct profiler_params {
           start = end + 1;
         }
       }
+
+      /* thread_num is only assigned when a third field is present, so
+       * --profiler-params=FIX_RATE,1 leaves it at 0 and skips the check just
+       * above. simulate_with_multi_caches then fails to queue any work and
+       * aborts with "cannot push data into thread_pool in get_miss_ratio",
+       * which says nothing about the parameter that was actually missing. */
+      if (current_param_idx < 3) {
+        ERROR("minisim params need FIX_RATE,<sample_rate>,<thread_num>: %s\n",
+              str);
+        exit(1);
+      }
     }
   } minisim_params;