Giải thuật 03/09/2026 8 phút

Cùng một hàm constexpr: một chỗ chạy 0,227 ns, chỗ kia 45625 ns — khác nhau ở đâu?

Đánh dấu constexpr là chắc chắn tính sẵn lúc biên dịch, 0 chi phí? Tôi đo và phát hiện chữ đó hứa ít hơn tưởng. Đặt kết quả vào biến constexpr thì nó thành literal đọc 0,227 ns; gọi đúng hàm ấy với đầu vào động thì nó chạy nguyên vòng lặp lúc chạy, 45625 ns. Ngữ cảnh mới quyết định, không phải từ khóa.

Giải thuật 03/09/2026 8 phút

fork chỉ tốn 74µs dù cha giữ gì — nhưng cấp 256MB trước rồi fork lại chậm 1,86 lần

Tưởng fork đắt vì phải sao chép cả bộ nhớ? Tôi đo: Copy-on-Write nên fork KHÔNG chép dữ liệu — chỉ 74µs, 1,6 lần một luồng. Nhưng CoW không làm fork miễn phí theo kích thước: fork sau khi cấp 256MB chậm 1,86 lần vì vẫn phải nhân đôi bảng trang. CoW cắt chép dữ liệu, không cắt chép bảng trang.

Giải thuật 03/09/2026 8 phút

Bỏ if cho nhanh: mẹo hay hay giáo điều?

Code không nhánh (branchless) luôn nhanh hơn if? Đo trên host ARM: khi nhánh khó đoán (dữ liệu ngẫu nhiên), branchless nhanh gấp 3 lần vì né được dự đoán sai. Nhưng khi nhánh dễ đoán và thân điều kiện rất đắt (8 phép chia, hiếm khi chạy), bản có if lại thắng vì bỏ qua được việc đắt. Và nhiều khi trình biên dịch đã tự bỏ nhánh giúp bạn rồi mà không hay.

Giải thuật 03/09/2026 9 phút

Hàng đợi xử lý ~0 việc vẫn chỉ 6,8 triệu op/s — và gom lô đẩy nó lên 7,4 lần

Tưởng throughput hàng đợi chỉ phụ thuộc tốc độ xử lý, hoặc hàng đợi càng lớn càng nhanh? Tôi đo: đẩy/lấy từng phần tử chỉ 6,8 triệu op/s vì chi phí đồng bộ mỗi lần bàn giao, gom lô lên 50,6 (7,4 lần), và kích thước hàng đợi chỉ giúp tới điểm bão hòa. Kẻ giết throughput là đồng bộ per-item, không phải xử lý.

Giải thuật 03/09/2026 9 phút

20.000 việc nhỏ: tạo luồng mỗi việc mất gần 1 giây, thread pool xong trong 8 mili giây

Tưởng tạo luồng mỗi việc là ổn cho việc nhỏ, hoặc thread pool là kỹ thuật rườm rà thừa? Tôi đo: 20.000 việc nhỏ kiểu thread-per-task mất 989ms vì chi phí tạo luồng ~47µs lấn át việc thật, còn thread pool nhanh 125 lần với số worker quanh số lõi — quá nhiều worker lại chậm đi. Một chi phí nhỏ nhân số lần lớn thành nút thắt khổng lồ.

Giải thuật 03/09/2026 9 phút

malloc 48GB trên máy 8GB vẫn thành công — vì sao kiểm malloc==NULL gần như vô dụng

Tưởng malloc trả non-NULL nghĩa là bạn thật sự có bộ nhớ đó? Tôi đo: malloc 48GB trên máy 8GB vẫn thành công (RSS chỉ ~1MB), RAM thật chỉ tốn lúc chạm — và chạm quá giới hạn thì OOM killer bắn chết tiến trình bằng SIGKILL (exit 137), không hề trả NULL cho bạn bắt.