Ma trận kề ngốn 1.527 MB ở V=40.000 và OOM quanh V~90.000, còn danh sách kề chỉ 2,6 MB. Bảng DP đầy đủ dùng 382 MB, bản cuộn hai biến dùng 1 MB cùng thời gian. Merge sort tốn gấp đôi RAM nhưng nhanh hơn heapsort 3,7 lần. Không gian là bức tường cứng, không phải tài nguyên miễn phí — tôi đọc VmHWM để đo.
Ai cũng được dạy lưu biểu thức chung vào biến tạm cho khỏi tính lại. Tôi đo và thấy compiler tự làm: bản viết lặp và bản lưu tạm sinh mã giống hệt. Nhưng một phép ghi qua con trỏ có thể trùng lại chặn đứng nó, buộc tính lại — và restrict khôi phục, nhanh 1,34 lần ở phép chia. Aliasing mới là thứ quyết định.
Nhân học sinh O(n²) đáng ra phải thua Karatsuba O(n^1,585) — nhưng đo ra nó thắng tới tận ~1024 hạn (~9.800 chữ số). Ở 64 hạn Karatsuba còn chậm hơn 2,8 lần vì hằng số ẩn của đệ quy. Và mọi phép số lớn chậm hơn nhân 64-bit gốc hàng trăm nghìn lần. Bậc tốt hơn không tự động nhanh hơn. Tôi đo.
Mọi sắp xếp dựa trên so sánh bị chặn ở O(n log n). Nhưng radix và counting sort chạy O(n): radix thắng introsort 5–11 lần trên số 32-bit ở mọi cỡ, counting sort nhanh 15,6 lần với khóa nhỏ. Giới hạn thật không ở n nhỏ mà ở bề rộng khóa (32-bit 4 lượt, 64-bit 8 lượt) và scatter phá cache. Tôi đo.
Cùng một code C, -O0 chậm 4,6 lần -O2 — không phải vì làm nhiều phép tính hơn, mà vì giữ mọi biến trên ngăn xếp (72 lệnh load/store so với 26 khi lên -O1). Cú nhảy tốc độ lớn nhất nằm ở -O0 → -O1; còn -O2 và -O3 cho mã gần như y hệt. Số cao hơn không đảm bảo nhanh hơn.
Chia việc cho 10 lõi tưởng nhanh gấp 10, nhưng đo ra: việc song song thuần nhất chỉ đạt 7,38x, thêm 10% việc tuần tự tụt còn 4,53x (khớp luật Amdahl), và việc nghẽn băng thông bộ nhớ chỉ 3,28x vì mọi lõi tranh một bus. Phần tuần tự nhỏ bé mới là thứ đặt trần. Tôi đo.