[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5707":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},5707,"napkin-math","sirupsen\u002Fnapkin-math","sirupsen","Techniques and numbers for estimating system's performance from first-principles","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=IxkSlnrRFqc",null,"Rust",5239,215,96,4,0,11,60,8,38,"MIT License",false,"master",true,[],"2026-06-12 02:01:14","# Napkin Math\n\nThe goal of this project is to collect software, numbers, and techniques to\nquickly estimate the expected performance of systems from first-principles. For\nexample, how quickly can you read 1 GB of memory? By composing these resources\nyou should be able to answer interesting questions like: how much storage cost\nshould you expect to pay for logging for an application with 100,000 RPS?\n\nThe best introduction to this skill is [through my talk at\nSRECON](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=IxkSlnrRFqc).\n\nThe best way to practise napkin math in the grand domain of computers is to work\non your own problems. The second-best is to **subscribe to [this\nnewsletter](http:\u002F\u002Fsirupsen.com\u002Fnapkin) where you'll get a problem every few\nweeks to practise on**. It should only take you a few minutes to solve each one as your\nfacility with these techniques improve.\n\nThe archive of problems to practise with are\n[here](https:\u002F\u002Fsirupsen.com\u002Fnapkin\u002F). The solution will be in the following\nnewsletter.\n\n## Numbers\n\nBelow are numbers rounded for memorization, not faux precision.\nThe rows this repo can currently refresh on a single host were re-measured and\nrevalidated on fresh GCP `c4-standard-48-lssd` instances on March 8, 2026\n(Intel Xeon 6985P-C, 48 vCPU \u002F 24 physical cores, 180 GB RAM, Ubuntu 22.04.5\nLTS).\n\n[9]: https:\u002F\u002Fgist.github.com\u002Fsirupsen\u002F766f266eebf6bdf2525bdbb309e17a41\n\n**Note 1:** Some throughput and latency numbers don't line up, this is\nintentional for ease of calculations.\n\n**Note 2:** Take the numbers with a grain of salt. E.g. for I\u002FO, [`fio`][fio] is\nthe state-of-the-art. I am continuously updating these numbers as I learn more\nto improve accuracy and as hardware improves.\n\n| Operation                           | Latency     | Throughput | 1 MiB  | 1 GiB  |\n| ----------------------------------- | -------     | ---------- | ------ | ------ |\n| Sequential Memory R\u002FW (64 bytes)    | 0.5 ns      |            |        |        |\n| ├ Single Thread                     |             | 20 GiB\u002Fs   | 50 μs  | 50 ms  |\n| ├ Threaded                          |             | 200 GiB\u002Fs  | 5 μs   | 5 ms   |\n| Network Same-Zone                   |             | 10 GiB\u002Fs   | 100 μs | 100 ms |\n| ├ Inside VPC                        |             | 10 GiB\u002Fs   | 100 μs | 100 ms |\n| ├ Outside VPC                       |             | 3 GiB\u002Fs    | 300 μs | 300 ms |\n| Hashing, not crypto-safe (64 bytes) | 10 ns       | 5 GiB\u002Fs    | 200 μs | 200 ms |\n| Random Memory R\u002FW (64 bytes)        | 20 ns       | 3 GiB\u002Fs    | 300 μs | 300 ms |\n| Fast Serialization `[8]` `[9]` †    | N\u002FA         | 1 GiB\u002Fs    | 1 ms   | 1s     |\n| Fast Deserialization `[8]` `[9]` †  | N\u002FA         | 1 GiB\u002Fs    | 1 ms   | 1s     |\n| System Call                         | 300 ns      | N\u002FA        | N\u002FA    | N\u002FA    |\n| Hashing, crypto-safe (64 bytes)     | 100 ns      | 1 GiB\u002Fs    | 1 ms   | 1s     |\n| Sequential SSD read (8 KiB)         | 1 μs        | 8 GiB\u002Fs    | 100 μs | 100 ms |\n| Context Switch `[1] [2]`            | 10 μs       | N\u002FA        | N\u002FA    | N\u002FA    |\n| Sequential SSD write, -fsync (8KiB) | 2 μs        | 3 GiB\u002Fs    | 300 μs | 300 ms |\n| TCP Echo Server (32 KiB)            | 50 μs       | 500 MiB\u002Fs  | 2 ms   | 2s     |\n| Random SSD Read (8 KiB)             | 100 μs      | 70 MiB\u002Fs   | 15 ms  | 15s    |\n| Decompression `[11]`                | N\u002FA         | 1 GiB\u002Fs    | 1 ms   | 1s     |\n| Compression `[11]`                  | N\u002FA         | 500 MiB\u002Fs  | 2 ms   | 2s     |\n| Sorting (64-bit integers)           | N\u002FA         | 500 MiB\u002Fs  | 2 ms   | 2s     |\n| Proxy: Envoy\u002FProxySQL\u002FNginx\u002FHAProxy | 50 μs       | ?          | ?      | ?      |\n| Network within same region          | 250 μs      | 2 GiB\u002Fs    | 500 μs | 500 ms |\n| Premium network within zone\u002FVPC     | 250 μs      | 25 GiB\u002Fs   | 50 μs  | 40 ms  |\n| Sequential SSD write, +fsync (8KiB) | 300 μs      | 30 MiB\u002Fs   | 30 ms  | 30s    |\n| {MySQL, Memcached, Redis, ..} Query | 500 μs      | ?          | ?      | ?      |\n| Serialization `[8]` `[9]` †         | N\u002FA         | 100 MiB\u002Fs  | 10 ms  | 10s    |\n| Deserialization `[8]` `[9]` †       | N\u002FA         | 100 MiB\u002Fs  | 10 ms  | 10s    |\n| Sequential HDD Read (8 KiB)         | 10 ms       | 250 MiB\u002Fs  | 2 ms   | 2s     |\n| Random HDD Read (8 KiB)             | 10 ms       | 0.7 MiB\u002Fs  | 2 s    | 30m    |\n| Blob Storage GET, if-not-match 304  | 30 ms       |            |        |        |\n| Blob Storage GET, 1 conn (128KiB)   | 80 ms       | 100 MiB\u002Fs  | 10 ms  | 10s    |\n| Blob Storage GET, n conn (offsets)  | 80 ms       | NW limit   |        |        |\n| Blob Storage LIST                   | 100 ms      |            |        |        |\n| Blob Storage PUT, 1 conn (128KiB)   | 200 ms      | 100 MiB\u002Fs  | 10 ms  | 10s    |\n| Blob Storage PUT, n conn (multipart)| 200 ms      | NW limit   | 10 ms  | 10s    |\n| Network between regions `[6]`       | [Varies][i] | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network NA Central \u003C-> East         | 25 ms       | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network NA Central \u003C-> West         | 40 ms       | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network NA East \u003C-> West            | 60 ms       | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network EU West \u003C-> NA East         | 80 ms       | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network EU West \u003C-> NA Central      | 100 ms      | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network NA West \u003C-> Singapore       | 180 ms      | 25 MiB\u002Fs   | 40 ms  | 40s    |\n| Network EU West \u003C-> Singapore       | 160 ms      | 25 MiB\u002Fs   | 40 ms  | 40s    |\n\n[i]: https:\u002F\u002Fwww.cloudping.co\u002F \n\n**†:** \"Fast serialization\u002Fdeserialization\" is typically a simple wire-protocol\nthat just dumps bytes, or a very efficient environment. Typically standard\nserialization such as e.g. JSON will be of the slower kind. We include both here\nas serialization\u002Fdeserialization is a very, very broad topic with extremely\ndifferent performance characteristics depending on data and implementation.\n\nFor the active Criterion suite, run `.\u002Frun --bench napkin_math` to get the\nright optimization levels and Linux tuning. You won't get the right numbers\nwhen you're compiling in debug mode. The wrapper already uses `sudo`\ninternally. On locked-down cloud images, run\n`sudo sysctl -w kernel.perf_event_paranoid=-1` once before invoking it. You\ncan help this project by adding new suites and filling out the blanks.\n\n**Note:** The active benchmark path today is Criterion.rs in `benches\u002F`.\n`src\u002Fmain.rs` is still the older ad hoc harness and remains the source of truth\nfor the benches that have not been fully migrated and revalidated yet. The\ncurrent Criterion suite now includes `blob_storage`, `memory_read`,\n`memory_random`, `hash`, `syscall`, `sort`, `serialization`, `compression`,\nand `compressed_memory_read`. The current SSD rows were refreshed from the older\nharness with `NAPKIN_BENCH_FILE` pointed at a RAID0 local-SSD mount.\nThe `compressed_memory_read` Criterion bench is a BitPacker integer-unpack\nmicrobenchmark; it should not be used to rewrite the generic `[11]`\ncompression\u002Fdecompression rows above. The new `serialization` and\n`compression` Criterion groups are workload-specific and are not yet wired into\nthe generic README rows above.\nThe new `blob_storage` Criterion group is opt-in and credentialed: set\n`NAPKIN_GCS_BUCKET` and\u002For `NAPKIN_S3_BUCKET`. Both the GCS and S3 paths now\nuse the AWS S3 SDK. The GCS side talks to the GCS XML interoperability endpoint\nand requires `NAPKIN_GCS_ACCESS_KEY` plus `NAPKIN_GCS_SECRET_KEY`. The S3 side\nuses the local AWS profile in `NAPKIN_S3_PROFILE` (default `tpuf-test`) plus\n`NAPKIN_S3_REGION` (default `us-west-2`).\nThe concurrent `get_offsets` and `put_multipart` paths explicitly fan out onto\na multi-thread Tokio runtime, so they can get close to the host NIC limit when\nthe range count \u002F object count is high enough. On March 9, 2026, same-region\n`1 GiB` single-stream GETs landed at about `95 MiB\u002Fs` on S3 (`m6id.12xlarge`\nin `us-west-2a`) and about `190-200 MiB\u002Fs` on GCS XML\n(`c4-standard-48-lssd` in `us-central1-c`). On the same machines, explicit\nconcurrent range GETs reached about `2.0 GiB\u002Fs` on S3 and about `4.9 GiB\u002Fs` on\nGCS, while multipart PUTs reached about `1.8-1.9 GiB\u002Fs` on S3 and about\n`3.3 GiB\u002Fs` on GCS. AWS's own S3 guidance suggests budgeting about\n`85-90 MB\u002Fs` per concurrent request when saturating a `10 Gbps` instance, which\nmatched the measured S3 single-stream result closely. The old `500 MiB\u002Fs`\nsingle-stream blob GET row above did not reproduce on either provider, so it\nhas been revised down to a conservative generic `100 MiB\u002Fs`. The current\nblob-storage work has revalidated throughput much more than first-byte latency;\nthe `50 ms` \u002F `150 ms` latency cells above should still be read as rough\nheuristics until a dedicated small-object \u002F time-to-first-byte probe is added.\nThere is now a dedicated small-object latency probe in `src\u002Fbin\u002Fs3_latency.rs`.\nRun `.\u002Fscript\u002Fblob-latency s3` or `.\u002Fscript\u002Fblob-latency gcs` to sweep\n`get`, `put`, `if_none_match`, and `put_if_match` across the default\n`8 KiB .. 8 MiB` size ladder, except `if_none_match`, which now defaults to a\nsingle `128 KiB` row because its latency was effectively flat across the small\nsize sweep. Override `NAPKIN_BLOB_LATENCY_OPS`,\n`NAPKIN_BLOB_LATENCY_SIZES`, and\n`NAPKIN_BLOB_LATENCY_IF_NONE_MATCH_SIZES` when you want a smaller or\nprovider-specific run. The latency probe now defaults to a per-row wall-clock\nbudget of `300` seconds, collecting as many samples as fit in that time.\nTune that with `NAPKIN_BLOB_LATENCY_ROW_SECONDS`; optionally cap it with\n`NAPKIN_BLOB_LATENCY_SAMPLE_CAP` (or the older `NAPKIN_BLOB_LATENCY_SAMPLES`\nalias) when you want shorter count-limited experiments instead.\nThe `list` op now seeds a larger namespace by default (`100k` keys) and\nmeasures one randomized `1000`-key page per sample via `start_after`, rather\nthan repeatedly scanning the same small fixed prefix. Tune that shape with\n`NAPKIN_BLOB_LATENCY_LIST_NAMESPACE_KEYS`,\n`NAPKIN_BLOB_LATENCY_LIST_KEYS`, and\n`NAPKIN_BLOB_LATENCY_LIST_SEED_CONCURRENCY`. If you also want the old\nwhole-namespace walk, add `list_full_scan` to `NAPKIN_BLOB_LATENCY_OPS`.\nFor aligned range-read latency, `.\u002Fscript\u002Fblob-random-range-latency` measures\nthe `128 KiB`-aligned shape and `.\u002Fscript\u002Fblob-random-range-latency-8m`\nmeasures the `8 MiB`-aligned shape over the same `128 x 1 GiB` object pool.\n`.\u002Fscript\u002Fblob-random-range-latency-8m-multipart` seeds those `1 GiB` source\nobjects via multipart upload with `8 MiB` parts, then measures `8 MiB`-aligned\nreads against those multipart boundaries.\n`memory_read` now emits explicit `No SIMD` and `SIMD` variants in Criterion,\nbut the README intentionally collapses them to one single-thread row and one\nthreaded row for memorability.\n\nI am aware of some inefficiencies in this suite. I intend to improve my skills\nin this area, in order to ensure the numbers are the upper-bound of performance\nyou may be able to squeeze out in production. I find it highly unlikely any of\nthem will be more than 2-3x off, which shouldn't be a problem for most users.\n\n## Cost Numbers\n\nApproximate numbers that should be consistent between Cloud providers.\n\n| What                | Amount | \\$ \u002F Month | 1y commit \\$ \u002Fmonth | Spot \\$ \u002Fmonth | Hourly Spot \\$ |\n| --------------------| ------ | ---------  | ------------------ | ------------- | ------------- |\n| CPU                 | 1      | \\$15       | \\$10                | \\$2            |  \\$0.005       |\n| GPU                 | 1      | \\$5000     | \\$3000              | \\$1500         |  \\$2           |\n| Memory              | 1 GB   | \\$2        | \\$1                 | \\$0.2          |  \\$0.0005      |\n| Storage             |        |            |                    |               |               |\n| ├ Warehouse Storage | 1 GB   | \\$0.02     |                    |               |               |\n| ├ Blob (S3, GCS)    | 1 GB   | \\$0.02     |                    |               |               |\n| ├ Zonal HDD         | 1 GB   | \\$0.05     |                    |               |               |\n| ├ Ephemeral SSD     | 1 GB   | \\$0.08     | \\$0.05             | \\$0.05        |  \\$0.07        |\n| ├ Regional HDD      | 1 GB   | \\$0.1      |                    |               |               |\n| ├ Zonal SSD         | 1 GB   | \\$0.2      |                    |               |               |\n| ├ Regional SSD      | 1 GB   | \\$0.35     |                    |               |               |\n| Networking          |        |            |                    |               |               |\n| ├ Same Zone         | 1 GB   | \\$0        |                    |               |               |\n| ├ Blob              | 1 GB   | \\$0        |                    |               |               |\n| ├ Ingress           | 1 GB   | \\$0        |                    |               |               |\n| ├ L4 LB             | 1 GB   | \\$0.008    |                    |               |               |\n| ├ Inter-Zone        | 1 GB   | \\$0.01     |                    |               |               |\n| ├ Inter-Region      | 1 GB   | \\$0.02     |                    |               |               |\n| ├ Internet Egress † | 1 GB   | \\$0.1      |                    |               |               |\n| CDN Egress          | 1 GB   | \\$0.05     |                    |               |               |\n| CDN Fill ‡          | 1 GB   | \\$0.01     |                    |               |               |\n| Warehouse Query     | 1 GB   | \\$0.005    |                    |               |               |\n| Logs\u002FTraces    ♣    | 1 GB   | \\$0.5      |                    |               |               |\n| Metrics             | 1000   | \\$20       |                    |               |               |\n| EKM Keys            | 1      | \\$1        |                    |               |               |\n\n† This refers to network leaving your cloud provider, e.g. sending data to S3\nfrom GCP or egress network for sending HTML from AWS to a client.\n\n‡ An additional per cache-fill fee is incurred that costs close to blob storage\nwrite costs (see just below).\n\n7 This is standard pricing among a few logging providers, but e.g. [Datadog\npricing](https:\u002F\u002Fwww.datadoghq.com\u002Fpricing\u002F?product=log-management#products) is\ndifferent and charges \\$0.1 per ingested logs with \\$1.5 per 1m on top for 7d\nretention.\n\nFurthermore, for blob storage (S3\u002FGCS\u002FR2\u002F...), you're charged per read\u002Fwrite\noperation (fewer, large files is cheaper):\n\n |                | 1M      | 1000     |\n |----------------|---------|----------|\n | Reads          | \\$0.4   | \\$0.0004 |\n | Writes         | \\$5     | \\$0.005  |\n | EKM Encryption | \\$3     | \\$0.003  |\n\n## Compression Ratios\n\nThis is sourced from a few sources. `[3]` `[4]` `[5]` Note that compression speeds (but\ngenerally not ratios) vary by an order of magnitude depending on the algorithm\nand the level of compression (which trades speed for compression).\n\nI typically ballpark that another _x in compression ratio decreases performance\nby 10x_. E.g. we can [get a 2x ratio on English\nWikipedia](https:\u002F\u002Fquixdb.github.io\u002Fsquash-benchmark\u002F#results-table) at ~200\nMiB\u002Fs, and 3x at ~20MiB\u002Fs, and 4x at 1MB\u002Fs.\n\n| What        | Compression Ratio |\n| ----------- | ----------------- |\n| HTML        | 2-3x              |\n| English     | 2-4x              |\n| Source Code | 2-4x              |\n| Executables | 2-3x              |\n| RPC         | 5-10x             |\n| SSL         | -2% `[10]`        |\n\n## Techniques\n\n* **Don't overcomplicate.** If you are basing your calculation on more than 6\n    assumptions, you're likely making it harder than it should be.\n* **Keep the units.** They're good checksumming.\n    [Wolframalpha](https:\u002F\u002Fwolframalpha.com) has terrific support if you need a\n    hand in converting e.g. KiB to TiB.\n* **Calculate with exponents.** A lot of back-of-the-envelope calculations are\n    done with just coefficients and exponents, e.g. `c * 10^e`. Your goal is to\n    get within an order of magnitude right--that's just `e`. `c` matters a lot\n    less. Only worrying about single-digit coefficients and exponents makes it\n    much easier on a napkin (not to speak of all the zeros you avoid writing).\n* **Perform Fermi decomposition.** Write down things you can guess at until you\n    can start to hint at an answer. When you want to know the cost of storage\n    for logging, you're going to want to know how big a log line is, how many of\n    those you have per second, what that costs, and so on.\n\n## Resources\n\n* `[1]`: https:\u002F\u002Feli.thegreenplace.net\u002F2018\u002Fmeasuring-context-switching-and-memory-overheads-for-linux-threads\u002F\n* `[2]`: https:\u002F\u002Fblog.tsunanet.net\u002F2010\u002F11\u002Fhow-long-does-it-take-to-make-context.html\n* `[3]`: https:\u002F\u002Fcran.r-project.org\u002Fweb\u002Fpackages\u002Fbrotli\u002Fvignettes\u002Fbrotli-2015-09-22.pdf\n* `[4]`: https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsnappy\n* `[5]`: https:\u002F\u002Fquixdb.github.io\u002Fsquash-benchmark\u002F\n* `[6]`: https:\u002F\u002Fdl.acm.org\u002Fdoi\u002F10.1145\u002F1879141.1879143\n* `[7]`: https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FHard_disk_drive_performance_characteristics#Seek_times_&_characteristics\n* `[8]`: https:\u002F\u002Fgithub.com\u002Fsimdjson\u002Fsimdjson#performance-results\n* `[9]`: https:\u002F\u002Fgithub.com\u002Fprotocolbuffers\u002Fprotobuf\u002Fblob\u002Fd20e9a92\u002Fdocs\u002Fperformance.md\n* `[10]`: https:\u002F\u002Fwww.imperialviolet.org\u002F2010\u002F06\u002F25\u002Foverclocking-ssl.html\n* `[11]`: https:\u002F\u002Fgithub.com\u002Finikep\u002Flzbench\n* [\"How to get consistent results when benchmarking on\n  Linux?\"](https:\u002F\u002Feasyperf.net\u002Fblog\u002F2019\u002F08\u002F02\u002FPerf-measurement-environment-on-Linux#2-disable-hyper-threading).\n  Great compilation of various Kernel and CPU features to toggle for reliable\n  bench-marking, e.g. CPU affinity, disabling turbo boost, etc. It also has\n  resources on proper statistical methods for benchmarking.\n* [LLVM benchmarking tips](https:\u002F\u002Fwww.llvm.org\u002Fdocs\u002FBenchmarking.html). Similar\n  to the above in terms of dedicating CPUs, disabling address space\n  randomization, etc.\n* [Top-Down performance analysis\n  methodology](https:\u002F\u002Feasyperf.net\u002Fblog\u002F2019\u002F02\u002F09\u002FTop-Down-performance-analysis-methodology).\n  Useful post about using `toplev` to find the bottlenecks. This is particularly\n  useful for the benchmarking suite we have here, to ensure the programs are\n  correctly written (I have not taken them through this yet, but plan to).\n* [Godbolt's compiler explorer](https:\u002F\u002Fgcc.godbolt.org\u002F#). Fantastic resource\n  for comparing assembly between Rust and e.g. C with Clang\u002FGCC.\n* [cargo-show-asm](https:\u002F\u002Fgithub.com\u002Fpacak\u002Fcargo-show-asm). Cargo extension to allow\n  disassembling functions. Unfortunately the support for closure is a bit\n  lacking, which requires some refactoring.\n* [Agner's Assembly\n  Guide](https:\u002F\u002Fwww.agner.org\u002Foptimize\u002Foptimizing_assembly.pdf). An excellent\n  resource on writing optimum assembly, which will be useful to inspect the\n  various functions for inefficiencies in our suite.\n* [Agner's Instruction\n  Tables](https:\u002F\u002Fwww.agner.org\u002Foptimize\u002Finstruction_tables.pdf). Thorough\n  resource on the expected throughput for various instructions which is helpful\n  to inspect the assembly.\n* [halobates.de](http:\u002F\u002Fhalobates.de\u002F). Useful resource for low-level\n  performance by the author of `toplev`.\n* [Systems Performance (book)](https:\u002F\u002Fwww.amazon.com\u002FSystems-Performance-Enterprise-Brendan-Gregg\u002Fdp\u002F0133390098\u002Fref=sr_1_1?keywords=systems+performance&qid=1580733419&sr=8-1). Fantastic book about analyzing system performance, finding bottlenecks, and understanding operating systems.\n* [io_uring](https:\u002F\u002Flwn.net\u002FArticles\u002F776703\u002F). Best summary, it links to many\n  resources.\n* [How Long Does It Takes To Make a Context Switch](https:\u002F\u002Fblog.tsunanet.net\u002F2010\u002F11\u002Fhow-long-does-it-take-to-make-context.html)\n* [Integer Compression Comparisons](https:\u002F\u002Fgithub.com\u002Fpowturbo\u002FTurboPFor-Integer-Compression)\n* [Files are hard](https:\u002F\u002Fdanluu.com\u002Ffile-consistency\u002F)\n\n[fio]: https:\u002F\u002Fgithub.com\u002Faxboe\u002Ffio\n","Napkin Math 是一个旨在收集软件、数据和技术以快速从第一原理估计系统性能的项目。其核心功能包括提供一系列基准数值和计算方法，帮助用户估算诸如内存读写速度、网络传输速率等关键性能指标。该项目采用Rust语言编写，具有高精度和易用性特点。适用于需要对计算机系统性能进行初步评估的各种场景，如成本预估、资源规划等。通过订阅项目提供的通讯，可以定期练习相关技能，从而提高解决问题的能力。",2,"2026-06-11 03:04:49","top_language"]