telecentric

Mỗi ngày biết thêm một tí, trong video là một loại ống kính rất đặc biệt – telecentric lens, vật thể nằm trong trường nhìn của nó có kích thước giống nhau dù ở xa hay gần! Tức nó không tạo ra một phép chiếu phối cảnh (perspective projection) mà kỳ lạ thay, có thể tạo ra một phép chiếu đẳng cấu (isometric projection)! Điều này có vẻ khá là khó tin nhưng phép chiếu đẳng cấu thực ra không xa lạ như mọi người nghĩ! Thậm chí tôi còn cho rằng, bản năng đầu tiên của chúng ta khi diễn họa cấu trúc một vật thể là đẳng cấu chứ không phải phối cảnh. Xem thêm về một bức tranh vẽ trong không gian đẳng cấu ở đây!

Nhưng cụ thể, ống kính này được dùng để làm gì? Nó được dùng trong các ứng dụng đo lường, kiểm định, các ứng dụng computer vision, pattern recognition, etc.. sẽ tránh được nhiều lỗi sai về kích thước, vì dù có chụp gần hay chụp xa thì kích thước vẫn y như thế, xem như đã chuẩn hóa đầu vào! Một ví dụ khác là in vi mạch bằng phương pháp quang khắc đều dùng loại ống kính này để tránh sai số! Một chút suy luận là sẽ thấy ngay, ống kính không thể nhìn thấy được vật thể to hơn nó (lớn hơn đường kính ống), nên quên chuyện dùng để chụp phong cảnh đi, chỉ dùng để chụp những vật thể nhỏ và macro mà thôi!

bilge pump

Mới cách đây độ 5 ~ 7 năm, cần mua một cái bơm chìm (bilge pump) để bơm nước cho chiếc xuồng, đây là loại tương đối đơn giản, chạy điện AC 12V và không cần phải có chất lượng quá cao ngoại trừ việc có thể đặt chìm trong nước! Nhưng tìm khắp Sài Gòn không có, phải lên Amazon đặt hàng, mà Amazon lúc đó thì không ship thẳng về VN! Và thế là quy trình để có được cái bơm như sau, lòng vòng nhiều bước: trước hết là đặt hàng trên Amazon, hàng bắt đầu được gởi đi từ… TQ sang Mỹ, đến một cái địa chỉ ở Mỹ! Tất cả những bước này, Amazon nó thể hiện ra chi tiết quá trình vận chuyển hàng cho mình biết! Địa chỉ này thực chất là một công ty logistics nhỏ, do một số người bạn tôi làm trong ngành logistics hùn hạp với nhau mở ra, xem như việc kinh doanh phụ thêm cho công việc chính! Công ty này sẽ gom nhiều đơn hàng và chuyển về VN một lần cho giảm chi phí! Về VN rồi vẫn chưa hết chuyện, còn phải ra Hải quan nhận hàng! Là cái công ty logistics kia có đường dây làm việc với Hải quan luôn, hàng giao nếu không có gì đặc biệt thì sẽ tính phí theo trọng lượng!

Còn nếu là dạng hàng hóa gì đặc biệt, lạ mắt, mà Hải quan nó để ý, thì sẽ còn phiền phức nữa! Và thế là lòng vòng mất hơn 2tr VND cho một cái bơm nhỏ xíu mà giờ đây lên Shoppee mua mất 200K kể cả tiền ship! Mà mới có mấy năm thôi, cái xứ gì mà thủ tục nhiêu khê, tác phong lề mề, làm gì cũng thấy bụi bay mù trời chứ chẳng thấy tiến triển! Thấy cái gì mới lạ thì phản ứng đầu tiên là sợ: ah, “nước ngoài” họ làm được chứ “ta” làm không được đâu, lúc nào cũng chỉ chực cơ hội “gian” và “ăn”, tự bản thân không muốn vận động, còn hễ mà thấy ai làm được cái gì là ghét và tìm cách phá! Thế nhưng ai phỉnh nịnh một vài câu chữ rẻ tiền đánh vào “cái tôi” là lấy làm sướng, có bao giờ tự nhìn cho rõ mình đâu!? Kỳ rồi đặt mua 2 miếng nhựa giá tổng cộng 20K, đặt xong mới để ý công ty nó ở Thượng Hải, ấy thế mà 7 ngày sau nó ship về tới nơi, không chê cả cái đơn 10 xu (cents), người ta làm ăn như thế thì mình chỉ có nước đi bán muối! Về thành ngữ “đi bán muối”… ở các thành phố ven biển miền Trung, muối là thứ gì đó rất rẻ, phổ biến, thừa thãi, nên làm cái công việc đi bán muối dạo, tính từ góc độ hiệu quả làm ăn là hết sức kém, vô cùng kém!

overclock

Thuê 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õ!

vtables

Trong 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ể dao độ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 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! 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!

thôi thủ

Facebook nhắc lại ngày này năm trước… Không phải là lười xuống nước, nhưng đúng là gần một năm qua cảm thấy thiếu ý tưởng và thiếu cả động lực, cảm thấy không tìm ra được ý tưởng gì mới. Mùa mưa coi như là đã về đi, chuẩn bị khởi động lại chương trình ra sông tập luyện! Một trong những điều cốt yếu của brace và roll là sự tự nhiên, mềm dẻo…

Cơ thể mà căng cứng, lo sợ là sẽ không làm được! Nói theo một nghĩa nào đó thì như bạn đang “thôi thủ – 推手 – pushing hands” với nước vậy, mà nước thì vô cùng mềm dẻo! Không biết “thôi thủ” là gì thì tìm xem một vài phim tài liệu về Thái cực quyền, các cao thủ chỉ cần chạm nhẹ cánh tay vào nhau là đã biết đối phương cao thấp thế nào!

rust

Những cái thuộc về ngôn ngữ, 10 năm là ít, 30 năm chưa phải là nhiều, thời gian để cho một ngôn ngữ trưởng thành, trở nên chính chắn, cẩn trọng từng câu, từng lời, bảo đảm mọi điều nói ra phải có nghĩa chính xác. Nhiều người bảo, chỉ là một tập cú pháp – syntax thôi mà, nói sao không được!? Không phải vậy, đã từng có vô số cú pháp “nhảm” bị đào thải sau vài năm, đơn cử như là C#, C# đã từng có vô số cú pháp nhảm, nhảm đến mức thiểu năng, ngu xuẩn! Và cũng đã có một số cú pháp kiểu “chữa lành – chảnh lừa” như async – await vẫn tiếp tục lừa người thêm độ chục năm, cho đến khi người ta nhận ra chẳng có lợi ích gì ngoài những câu chữ oang oang, trơn tuột! Và cũng đã có những ngôn ngữ đã dùng trên hai mươi năm nhưng rồi cuối cùng thì người ta quyết định: thôi, tốt hơn là… bỏ, không đi tiếp nữa, ví dụ như Obj-C, Flash, thậm chí có thể cả Java! Nhưng chừng đó năm cũng đủ cho người ta mường tượng ra được một ngôn ngữ “tốt” tương lai nó sẽ trông như thế nào!

Đầu tiên là nó phải giống ngôn ngữ C, điều này… đơn giản như chân lý vậy, cứ phải giống C thì mới tốt! Thứ hai, ngôn ngữ phải strong-type, có kiểu rõ ràng và kiểm tra kiểu khi biên dịch, không đợi đến khi chạy. Thứ ba, dù gọi tên gì: reference, optional, thì cũng phải làm cho người ta hiểu rằng đây là con trỏ – pointer, ở điểm này thì C thẳng thắn đến mức trần trụi! Thứ tư là quản lý bộ nhớ bằng reference counting và lần nữa, phải làm từ lúc biên dịch (compile time), đừng đợi đến đến lúc run-time, quên garbage collector và những thứ khác đi! Thứ năm là làm sao để lập trình concurrent, thread, process dễ hiểu hơn! Và cuối cùng, rất quan trọng, dù thời đại đã đi tới mức zettabyte, nhưng một ngôn ngữ vẫn phải thật sự hiệu quả, hiểu theo nghĩa phải đếm từng bits khi cần. Xét những tiêu chí đó thì có lẽ Rust sẽ là ngôn ngữ phổ thông kế tiếp, dần thay thế C++! Đã nói rồi, phải cải tiến trước mới dùng, đừng dùng xong mới cải tiến, gọi là ++C có phải đã tốt rồi không!? :D

Đương nhiên, đây là ngôn ngữ phổ thông (general purpose) ở mức thấp (low level), những lĩnh vực đặc thù vẫn sẽ có những ngôn ngữ riêng! Nhưng với một ngôn ngữ phổ thông cấp thấp, ưu tiên hàng đầu là performance, những thứ khác vẫn chỉ là phụ. Rust thậm chí còn chưa phải là một ngôn ngữ OOP – hướng đối tượng đúng nghĩa, theo nghĩa thường hiểu trong C++ hay Java. Nói cho đúng hơn là mô hình OOP của Rust được thiết kế ưu tiên cho performance, chứ không phải cho sự tiện lợi của người viết code! Thậm chí ta còn có thể đặt câu hỏi rằng, có thực sự cần OOP hay không, ví dụ như glibc chỉ dùng “struct” của C để biểu diễn “class” đó thôi! Nhưng qua đó cho thấy rằng, đã rất nhiều thế hệ khác nhau của C++ rồi, mà vẫn không giải quyết được bài toán vtable – gọi hàm hướng đối tượng làm sao cho hiệu quả. Nên Rust đành phải đổi một cách tiếp cận khác, mang tính chất lai lai, một nửa là OOP và nửa còn lại vẫn là functional theo kiểu ngôn ngữ C truyền thống!

Quá trình hình thành một ngôn ngữ thực chất phản ánh muôn mặt của cái cộng đồng làm ra và sử dụng nó. Đầu tiên là từ góc độ tương đối hàn lâm, ngôn ngữ phải thể hiện được tính đúng đắn và hiệu quả tính toán! Cái yếu tố “hiệu quả – performance” này là yếu tố quyết định, đôi khi nó phủ quyết (veto) tất cả những yếu tố khác. Tiếp nữa mới đến chuyện cú pháp rõ ràng, tiện lợi, thân thiện với lập trình viên. Kế đến nữa mới là chuyện tổ chức, lớp lang, các hệ thống thư viện phụ trợ để dễ dàng phát triển phần mềm! Phần lớn lập trình viên chỉ tranh luận phía trên bề mặt, cú pháp như thế này, lớp lang như thế kia, họ không hiểu rằng yếu tố tiên quyết của một ngôn ngữ là vấn đề hiệu suất (performance). Những ngôn ngữ bỏ lơ vấn đề này… đều có kết cục thê thảm!!! Ví dụ như Objective-C, người ta bỏ vì nó đã trở thành một con quái vật, phức tạp đến mức vô lý, hay như một số code React – TypeScript, mới viết có cái app Hello – World là đã chiếm mất hơn 3GB đĩa cứng.

parade

Thông lệ hàng năm, 9 tháng Năm là ngày Gấu Nga trình diễn, khoe cơ bắp! Xem mãi các cuộc diễu binh cũng chán, mời các bạn xem trích đoạn bộ phim Người thợ hớt tóc ở Siberia, đoạn Sa-hoàng Alexander-3 dự lễ tốt nghiệp của các sĩ quan. Phim dựng lại theo đúng lịch sử, Alexander-3 là người to lớn, vạm vỡ với sức mạnh phi thường, cầm nguyên bộ bài Tây 54 quân, ông ta xé nó thành 2 mảnh. Hay đang ăn với chiếc đĩa bạc, ông ta dùng tay cuộn tròn cái đĩa lại như người ta cuộn bánh tráng vậy! Cái trò dùng tay cuộn đĩa kim loại này, đã có nhiều đời Sa-hoàng biểu diễn trên các bàn tiệc ngoại giao như một cách… hù đối phương!

Phim có đoạn Sa-hoàng Alexander-3 trò chuyện với hoàng hậu Maria Feodorovna bằng tiếng Anh: – Em còn phải lặp đi lặp lại bao nhiêu lần nữa, tại sao anh không bao giờ nghe em, Michael còn quá nhỏ, nó rất dễ bị kích động bởi các cuộc diễu binh cũng như các trò chơi quân sự. Alexander 3 trả lời rất hóm hỉnh, cũng bằng tiếng Anh: – Nếu tôi mà nghe theo em á, thì đến tận giờ chúng ta còn chưa có con được đâu! Haiza, xem phim để thấy rằng, đây đúng là một dân tộc kiêu hãnh và mạnh bạo, một nền văn hóa đầy màu sắc, một loại âm nhạc sinh động, tuôn chảy, phức tạp! Luôn tràn đầy sức sống, luôn tiến về phía trước!

space-time

U50 rồi, “hơn nửa đời hư” (chữ “hư – 虛” này không phải là “hư hỏng” như thường hiểu trong tiếng Việt nhé, gì chứ lão Vương kia là khá rành chữ Hán đấy). U50 rồi, không thể tránh khỏi có những giai đoạn giấc ngủ xáo trộn. Dù vẫn ngủ rất đủ, và rất sâu, y như thanh niên 20, nhưng thỉnh thoảng vẫn bị kiểu jet-lag rất khó chịu! Nhiều đêm trằn trọc, đưa tay chạm nhẹ cái đồng hồ đặt trên tủ đầu giường, nó có cái “máy chiếu” tí hon, phóng ảnh lên trần nhà để thông báo giờ hiện tại. Thời gian cứ thế trôi đi, một lúc lại chạm nhẹ xem giờ lần nữa, trằn trọc không ngủ nên suy nghĩ linh tinh…

Đêm nghe tiếng mưa rơi, đếm mấy triệu hạt rồi… Có một không gian nào đo chiều dài nỗi nhớ…, đương nhiên đây sẽ là không-thời-gian Minkowski (Minkowski spacetime) rồi, không thể là không gian Euclide hình học cổ điển được, bởi vì chỉ có trong không gian Minkowski thì khoảng cách giữa 2 sự kiện (events) là độc lập (không phụ thuộc) vào hệ quy chiếu quán tính (inertial frame of reference) dùng để quan sát, đo lường hai sự kiện đó. Nhưng, những điều này cần phải được đặt vào trong một phép biến đổi Lorentz (Lorentz transformation) thì mới có thể hình dung được!

nhiệt

Đến lúc này có thể khẳng định chắc chắn máy có thể chạy heavy – duty rất tốt, đã chạy 24 tiếng liên tục, lúc nào cũng 100% công suất, chương trình xử lý dữ liệu tạo ra 72 processes, dùng đến hơn 40GB RAM, mà nhiệt độ 2 con CPU ổn định ở mức 60~62°C, nhiệt độ dầu ổn định ở mức 41~42°C, còn nhiệt độ GPU và SSD còn thấp hơn nữa, chỉ loanh quanh 37~38°C! Tuy vậy nhìn lại, vẫn có chút tiếc nuối, vẫn có chút không hoàn hảo, vì vẫn có thể làm tốt hơn, vẫn có những giải pháp tản nhiệt tốt hơn nữa! Haiza, nhiệt, nhiệt độ, chính là vấn nạn của cả loài người!

Cứ mỗi năm mỗi nóng hơn thế này, năm nào cũng thiết lập kỷ lục mới! Cái quá trình không đảo ngược được, con người và xã hội đã bị đẩy vô guồng, bị gài vô một cái thế cứ phải hơn, hơn nữa! Ai cũng muốn có những cái máy chạy nhanh hơn nữa, kết quả là cái quả cầu màu xanh xanh kia nó sẽ cứ nóng đỏ dần lên thôi. Đây là chuyện mà không bất kỳ một loại khoa học, kỹ thuật nào, không bất kỳ một hệ tư tưởng nào có thể giải quyết được, càng không nói đến cái đám cứ xoen xoét green & clean kia! Có lẽ phải nghĩ đến chuyện đào hầm tránh nóng là vừa!

chiều tây bắc

Nhớ năm đó chạy xe máy qua đèo Pha Đin – Sơn La – Điện Biên… con đường đèo mới vừa làm xong, tráng nhựa rộng rãi, phẳng phiu, chạy song song với con đường cũ! Xe thì mạnh và đường thì tốt, chạy cái vèo, mới có chút xíu đã qua hết con đèo. Giật mình vì kiểu “Trư Bát Giới ăn nhân sâm”, còn chưa kịp thưởng thức cái gì, chưa thấy được cảnh nào đẹp thì đã hết mịa nó con đèo. Bèn quay ngược xe lại, rẽ vào con đường cũ, đi chậm, thong thả, dừng xe, leo lên các ngọn đồi chụp ảnh, cứ như thế chạy qua đèo cả thảy 3 lần! Các đèo lớn ở miền Bắc thì mình đi hết cả rồi, nên Pha Đin cũng không phải là ấn tượng lắm, nhưng không phải vì thế mà nó không lớn!

Khi nhỏ ở Sơn Trà, Đà Nẵng, chỉ là mấy cục đá cao mấy chục mét, nhưng leo cũng trầy vi tróc vẩy chứ không đùa. Mà không leo mấy chục mét, thì làm sao hiểu được độ cao vài trăm mét, không leo vài trăm mét, thì làm sao hiểu được con số ngàn!? Giờ công nghệ hiện đại rồi, cơ giới hóa lớn, xe ủi, xe xúc, nên đường làm ra cứ gọi là rộng rãi, thông thoáng! Đám trẻ chạy xe hơi qua dừng lại dè bỉu: tưởng thế nào, chỉ có thế thôi à!? Nhưng sẽ là chuyện khác nếu như không có đường làm sẵn, cứ bắt gùi 30kg, vạch cây, bám đá mà đi, thì sẽ tự hiểu, tự ngộ ra được núi cao bao nhiêu ngay thôi! Tranh: Nhớ một chiều Tây Bắc – sơn mài – Phan Kế An – 1955.