Repository navigation
fix(native): Auto runs 4 threads on Pixel 6 and 7 - #77
Conversation
CpuTopology.bigCores keeps only the fastest frequency group unless it has a single core. On Tensor G1/G2 (2 X1 + 2 mid + 4 little) that's 2 cores, so Auto ran 2 threads there, where llama.rn used 4. Auto now uses autoCores: the fastest groups, adding the next one until there are 4 cores, but never the slowest group once there are 2 (little cores hold every thread back; 6 and 8 threads halved generation on the X6). Tensor G1/G2 get their 2 + 2 fast cores; every other layout tested (Dimensity 8300, Snapdragon 870, Tensor G3, 2 big + 6 little, one cluster) gets the same cores as before. bigCores is unchanged for the bench.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Approve. autoCores is right on every layout in the test, and bigCores keeping its meaning |
|
@coderabbitai review |
|
2 participants
Auto runs 4 threads on Pixel 6 and 7
Builds on #76 (the CI job), so this PR's CI runs the engine tests; the last commit is this PR's.
CpuTopology.bigCoreskeeps only the fastest frequency group unless that group has a single core. On Tensor G1 and G2 (Pixel 6, 6a, 6 Pro, 7, 7a, 7 Pro: 2 X1 + 2 mid + 4 little cores) that leaves 2 cores, so Auto ran 2 threads there; llama.rn used 4. The X6 Pro and POCO F3 have one prime core, so they got 4 and couldn't show it. GrapheneOS runs only on Pixels.Auto now uses a new
CpuTopology.autoCores: the fastest frequency groups, adding the next group until there are 4 cores, but never the slowest group once there are 2. The slowest group is left out because every thread waits for the slowest one; on the X6, 6 and 8 threads halved generation.bigCoresis unchanged, so the bench's "Big cores" option means what it did.EngineTweaksTest, "Auto threads - 4 on the fast cores of every layout, never the little ones", with the per-core maximum frequencies of each chip.Not measured. I haven't measured 2 vs 4 threads on a Tensor phone. Prompt reading should be faster with 4, as llama.rn ran it, but that needs a run on a Pixel 6 or 7. I haven't built this locally (no Android toolchain here); the CI job from #76 runs the tests. No CodeRabbit CLI review was run before pushing (
crisn't installed here).