vrr/BigMoeOnEdge
2
0
Fork 0
mirror of https://github.com/Helldez/BigMoeOnEdge.git synced 2026-10-19 07:23:46 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

docs: correct the macOS platform status after F_NOCACHE and the CI job

Browse source 
Three lines still described the state before #182 and #184.

- README said macOS is not exercised by CI. It is now compile-checked on every
  pull request and release tag, alongside Windows.
- benchmark-method told a Mac reader that o_direct is a no-op there, which would
  have them ignore the one field #182 made truthful.
- The platform-caveat paragraph still said macOS does not bypass the page cache.

limitations.md and community-benchmarks.md were already correct; these three were
missed in the same pass.
This commit is contained in:
Helldez 2026-08-29 19:11:31 +02:00
parent 40b7882493
commit 2b2f095c25
2 changed files with 9 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

9
README.md
View file

@ -398,12 +398,13 @@ The model must live on a real filesystem (on Android `/data/local/tmp/...`, not
`--moe-stream` for the plain mmap baseline. The byte-identity gates (streamed == resident) run with
`cd build && ctest --output-on-failure` (needs `python3` with the `gguf` package).
Platform status: Linux is exercised by CI (build + gates) and Windows is where the
Platform status: Linux is exercised by CI (build + gates), and Windows and macOS are
compile-checked there on every pull request and release tag. Windows is where the
[desktop numbers](#desktop) were measured. On Windows, build with CMake directly (Visual Studio
Build Tools); the script above is bash, and MSVC puts the binary in `build\cli\Release\bmoe-cli.exe`.
macOS builds from the same sources (the platform branches exist) but is not exercised by CI. It has
no O_DIRECT; a direct request is served with `F_NOCACHE` instead (uncached, but not alignment-constrained),
and `o_direct` in the telemetry reports what the open actually achieved.
macOS builds from the same sources and has no O_DIRECT; a direct request is served with `F_NOCACHE`
instead (uncached, but not alignment-constrained), and `o_direct` in the telemetry reports what the
open actually achieved.
### Android

7
docs/benchmark-method.md
View file

@ -22,7 +22,8 @@ bmoe-cli -m MODEL.gguf --moe-stream --cache-mb auto --io-threads 4 -t 4 -n 256 \
- **Check `o_direct=1` before trusting anything.** On Android the app's external files dir under
`/storage/emulated` is FUSE-backed: the `O_DIRECT` open succeeds but reads can return wrong data,
so the engine falls back to buffered and you are no longer measuring the path this page assumes.
`/data/local/tmp` and `/sdcard/Download` are real filesystems. On macOS the flag is a no-op today
`/data/local/tmp` and `/sdcard/Download` are real filesystems. On macOS `o_direct=1` means
`F_NOCACHE` was applied, which is uncached but carries no alignment or DMA contract
(see [limitations.md](limitations.md)).
- **Report** `s/token`, the `compute + flash I/O` split from the `moe-stream:` line, and the
`moe-cache:` hit rate.
@ -212,8 +213,8 @@ free-RAM-floor table alongside the throughput one.
dev host, identical output. Too large for CI.
The streamer works on Linux, macOS and Windows, but the throughput targets are stated for Android
and Linux on flash: Windows `VirtualAlloc` commit-per-slice is heavier, and macOS does not bypass
the page cache today ([limitations.md](limitations.md)).
and Linux on flash: Windows `VirtualAlloc` commit-per-slice is heavier, and macOS leaves the page
cache through `F_NOCACHE`, a caching hint rather than an I/O mode ([limitations.md](limitations.md)).
## Where the published numbers come from