huê con server của Amazon EC2 cấu hình 32 vCPU, 64 GB RAM, so với con Aquarium-PC của mình: 36 vCPU, 64 GB RAM, con của Amazon chạy nhanh hơn một chút, vì dù sao 2 con CPU Xeon của mình là đời cũ lắm rồi. Nhưng khi ép xung – overclock từ 2.3 lên 3.8 GHz thì con Aquarium-PC cho máy của Amazon “ngửi khói” lập tức! Nhưng ép xung cũng có nghĩa là tăng nhiệt, từ 60°C nhảy lên 75°C thường trực, và cũng phải tăng tốc độ quạt, tăng tiếng ồn. Đây là điều đành phải chấp nhận thôi, hoặc là phải có giải pháp tản nhiệt tốt hơn!

Giải pháp thì có, nhưng… kỳ công, phải học thêm nhiều kỹ năng nữa, nhất là cơ khí và CNC, mà tôi hiện tại chỉ có mấy kỹ năng làm mộc quèn mà thôi! Nói chung, xác nhận là tản nhiệt dầu vẫn có thể chạy tốt với máy ép xung được, nhưng thiết kế khâu tản nhiệt phải thật sự thông minh, thật sự hiệu quả! Viết một cái script nhỏ để bật / tắt việc ép xung cho Linux, chạy script là overclock + overvolt, tăng điện thế cấp cho các thành phần máy, chạy lần nữa là tắt tính năng này đi! Mới có mấy hôm mà kỹ năng viết shell-script của mình tăng lên thấy rõ!

rong post trước có nói về v-table, v-table là gì!? Với lập trình procedural truyền thống, gọi hàm thực chất là một lệnh hợp ngữ (Assembly), chỉ cần một lệnh JMP – Jump là nhảy ngay đến vùng nhớ chứa đoạn mã – hàm cần thực hiện! Nên gọi hàm trong ngôn ngữ C có tốc độ nhanh, nhanh đến mức không tưởng. Nhưng sự việc không đơn giản như vậy với các ngôn ngữ hướng đối tượng, như C++. Lấy ví dụ như: a->some_function(), trong trường hợp đơn giản nhất, ta cần nhảy 2 lần, lần đầu đến vùng nhớ chứa đối tượng (object) ‘a’, sau đó mới tìm trong vùng nhớ đó con trỏ đến hàm ‘some_function’ và nhảy thêm một lần nữa. Nhưng sự việc không đơn giản như vậy vì OOP có tính kế thừa, có nhiều phiên bản khác nhau của cùng một hàm ảo, những phiên bản này được chứa trong một cái bảng gọi là v-table, và việc gọi hàm lúc này bao gồm: 1. nhảy đến vùng nhớ bắt đầu đối tượng ‘a’, 2. tìm xem trong v-table của ‘a’ địa chỉ của hàm cần gọi, 3. nhảy đến vùng nhớ chính xác của hàm đó. Và cái bảng v-table này càng ngày càng lớn nếu kế thừa nhiều cấp, 20 ~ 30 cấp cũng là việc đã từng thấy! Sự việc bắt đầu trở nên phức tạp hơn nữa với những ngôn ngữ hỗ trợ đa kế thừa, đối tượng ‘a’ có thể kế thừa từ 1, 2 hay nhiều lớp khác nhau!

Lúc đó, compiler sẽ phải tạo ra nhiều v-table, và việc gọi hàm là một công cuộc tìm kiếm, tra bảng dài lê thê, thay vì chỉ một lệnh hợp ngữ JMP đơn giản! Thời gian tiêu tốn cho việc gọi hàm có thể giao động đâu đó trong khoảng 5 ~ 50% toàn bộ thời gian chạy chương trình. Đến tận ngày hôm nay, mấy chục năm sau khi các ngôn ngữ hướng đối tượng ra đời, bản chất của việc gọi hàm vẫn không đổi, và vẫn chưa có cải tiến nào mang tính cách mạng xảy ra! OOP đúng là một mô hình rõ ràng, dễ hiểu đối với lập trình viên, nhưng cực kỳ đau khổ cho những người làm compiler! OOP sinh ra, đầu tiên và trên hết là cho lập trình UI, mỗi cửa sổ, mỗi nút bấm trên UI là một đối tượng – object, nguyên thủy là vậy, về sau người ta mới mở rộng OOP từ UI sang những lĩnh vực khác! Nên những người làm ứng dụng lớn, cần tính lớp lang, cấu trúc rõ ràng, những người đó sẽ cảm thấy khó hiểu khi những coder ở mức thấp bên dưới chỉ thích procedural mà thôi! OOP đúng là rõ ràng và tiện lợi, nhưng không phải là cách tiếp cận duy nhất đối với các vấn đề lập trình, mọi việc có thể sẽ thay đổi! Và nhiều coder không hiểu vì sao một số người cố sống cố chết bám vào một số phong cách xưa cũ, vì… bản năng mách bảo rằng làm như thế mới là đúng! 🙂