'Too many open files' (EMFILE, mỗi tiến trình) và '...in system' (ENFILE, toàn hệ thống) chỉ khác ba chữ, nhưng cần hai cách chữa khác hẳn. Tôi chạm cái thứ hai, phản xạ vá cái thứ nhất, gõ ulimit cả buổi không xong. Đo thật hai giới hạn fd và bài học đọc kỹ lỗi.
Tưởng chuyển ngữ cảnh gần như tức thì, và chuyển giữa tiến trình đắt hơn hẳn giữa luồng vì phải xả TLB? Tôi đo bằng ping-pong qua pipe: mỗi lần chuyển ~8,5µs (hàng nghìn chu kỳ, không tức thì), và tiến trình bằng luồng (~1,0x) nhờ TLB gắn nhãn ASID. Một 'sự thật' sách giáo khoa đã lỗi thời vì phần cứng tiến hóa.
BST tra cứu O(log n)? Chỉ khi cây cân bằng. Tôi đo thử: chèn dữ liệu ĐÃ sắp xếp vào một BST thường làm cây lệch thành chuỗi cao đúng bằng N (50.000), tra cứu chậm hơn std::map 461 lần và xây cây chậm 594 lần. Dữ liệu sắp xếp — thứ trông đẹp nhất — hóa ra là worst case, không phải best.
Nhân với chia đều là một phép toán nên tốn như nhau? Đo trên host ARM: chuỗi phép nhân số thực chạy 3,3 chu kỳ mỗi phép, nhưng chia số thực tốn 10,7 chu kỳ — gấp hơn ba lần, và gấp mười lần một phép cộng. Số nguyên udiv 8 chu kỳ so với mul 3,2. Nhưng chia cho hằng số thì trình biên dịch biến thành nhân, và lấy dư cho lũy thừa 2 thành phép AND — gần như miễn phí.
Chạy một lần bấm giờ là biết cấu trúc nào nhanh hơn? Đo ra bốn cái bẫy: lần chạy đầu chậm 1,5 lần (cache lạnh, page fault); nếu quên volatile SINK thì -O2 xóa sạch vòng lặp và đo ra 0 ns (số bịa); đo một thao tác đơn cho 84 ns rác (toàn overhead đồng hồ) so với 0,23 ns thật; và nhiễu OS chỉ làm chậm nên phải lấy min, không lấy trung bình.
Tưởng khóa nhiều mutex thì thứ tự nào chẳng được, chạy thử thấy chạy là ổn? Tôi tái hiện deadlock thật: hai luồng khóa ngược thứ tự treo cứng — nhưng chạy đúng hàng nghìn vòng, treo ở thời điểm khác nhau mỗi lần. Thuốc là áp một thứ tự khóa toàn cục, hoặc trylock+backoff.