Năm 2018 của tôi

Chuẩn bị khép lại năm 2018, cuối nằm ngồi tính lại sổ đời, 365 ngày chứ mô có ít.
Về phần mềm thường nên đi từ tổng quan tới chi tiết, đầu tiên phải ngo ngó được cái gọi là kiến trúc (ARCH) trước, rồi đi sâu vào chi tiết từng phần sau. Tuy nhiên nhìn lại một năm có khi làm ngược lại thì dễ hơn, nên ta thử đi từ bản thân ra thế giới.

Về bản thân, cũng là 1 năm có nhiều thay đổi, nhớ những ngày này năm ngoái đang vật lộn với mớ bùng nhùng khi làm BrSE. Thời gian đó nhiều lúc tôi đã phải tự hỏi “mk, mình đang làm cái dek gì thế này”, trong những ngày tháng đó lúc đi làm qua cái cầu chỗ Shin-yokohama tôi lại dành 5-10 phút đứng ngắm trời đất ngắm thiên hạ và ngẫm về mình =)). Một trong mấy cái ảnh chụp lúc đó đấy giờ tôi đã dùng làm ảnh của blog. Sau hơn 1 năm trải nghiệm để đi đến kết luận rằng mặc dù kỹ sư cầu nối (BrSE) là một cái nghề rất hay, nhưng đấy không phải việc hợp với mình, thôi bỏ, rồi sang làm việc khác, chuyển công ty luôn. Quyết định “em trở về đúng nghĩa trái tim em” để cố gắng làm một kỹ sư chân chính, cố gắng đạt được CHÂN-THIỆN-MỸ ở một chỗ nhỏ nào đó trong công nghệ điện toán vĩ đại.

Năm 2018 cũng là năm bắt đầu làm blog, tập tành viết lách, viết ra mới thấy viết nó khó thế nào, âu cũng do phần nhiều là kiến thức nông cạn, độ ngu vẫn đang còn ở mức độ cao. Lúc đầu chỉ muốn làm chút để viết lại và học thêm kiến thức về video coding coi như có duyên nợ với nó, tên blog cũng được đặt theo mục đích đó. Khi viết rồi mới thấy ngoài cái đó nhiều thứ cần học, nhiều cái tưởng biết hóa ra chưa, và cũng biết rõ đang tồn tại nhiều cái mà bản thân mình không biết rằng mình không biết. Rồi có blog thì cũng có chỗ để lâu lâu cũng ghi chép vài thứ linh tinh mà nhiều khi không có ai hứng thú nghe.
Từ ngày viết blog thấy được mình đọc gì cũng cẩn thận hơn, tiếp thu kiến thức từ người khác cũng thận trọng hơn. Tập viết blog nên cũng mò ra được các trang có tiếng của lập trình viên nhà mình, ấn tượng nhất là vnhacker, ông anh này nổi tiếng bài Gọi đò, mình cũng toàn nghe nhạc vàng nhưng không thích cha này hát, trước giờ chỉ chơi kiểu anh Chế, anh Vũ, chị Quỳnh, vì thế ấn tượng là ấn tượng về bài viết chứ không phải bài hát của ảnh, nên theo mình thì bỏ hát đi code có lẽ lựa chọn đúng đắn của ảnh. Khi biết đọc blog này thì thốt lên 1 điều: “giá mà mình biết blog này sớm hơn”. Thêm vào đó theo dõi thêm các blog hàng top của nhà người.
Làm một kĩ sư chân chính thì cần có học trước, bù lại có việc ngày xưa không phải học các bộ môn của IT (vốn dĩ dân điện mà) thì năm nay cũng lên bắt đầu chịu khó tu sách, tự học, tìm hiểu thêm về lịch sử vài thử nhỏ nhỏ xung quanh mấy dòng code …
Cơ bản 1 năm để dần dần định hình chính mình?

Điều đặc biết nhất là năm nay gia đình nhỏ đón thêm 1 thành viên mới, vậy là 2 nhóc, mẹ xinh nhất nhà. Hơn 30 tuổi đầu rồi mà bố mẹ không có gì quí ngoài Khoai và Sắn. Lúc trước vợ sinh thằng ku Khoai, mình xa nhà do đang đi công tác, giờ ku Sắn, chứng kiến 9 tháng bụng mang dạ chửa, rồi lúc chăm con ngủ, thấy thương các mẹ các chị quá.

Ngoài bản thân và gia đình ra thì tiếp là năm 2018 trong mắt tôi. Đất Việt nhà mình, năm nay quả là 1 năm chính trường sôi động, anh ánh sáng tắt ngúm, nhạc sĩ thì được mặc áo Juventus, còn bang chủ cái bang nắm thâu tóm luôn ghế anh ánh sáng bỏ lại. Nhiều người chê, nhưng tôi thì đánh giá cao anh bang chủ Bần Khinh này, vì ảnh thật thà, lúc nhậm chức ảnh tâm sự “trình độ, năng lực còn hạn chế, sự hiểu biết không đáp ứng được yêu cầu”, tôi nghĩ ảnh nói thật chứ dek phải ảnh khiêm tốn, chỉ không hiểu sao cuối hội lại bầu cá nhân không đáp ứng được yêu cầu như vậy làm chủ tịch nác. Chính vì tính thật thà của anh mà thành ra ta biết nhiều việc do anh tiết lộ, vì dụ luật animal thật ra nhằm mục đích bảo vệ đoảng của ảnh chẳng hạn … À, có điều này tôi học được từ ảnh, trước đây ảnh phê phán “Nhất thể hóa”, nên giờ nhiều người kêu ảnh làm thế trước sau bất nhất thì ảnh bảo, cái này đéo phải “Nhất thể hóa” mà là “tình huống”, vậy là ảnh lật ngược tình thế, cái này làm tôi giật mình, quả thực sức mạnh thuật ngữ thật là đáng sợ. Dù sao cũng nên công nhận công đốt lò của ảnh mặc dù củi có lựa chọn, nhưng giờ các ông tướng, ông tai to mặt lớn tưởng hạ cánh an toàn lại toát mồ hôi hột, nghe gọi đến tên chắc như học sinh nghe cô gọi lên bảng, chỉ khác là học sinh có thể bị tát tập thể, còn các vị thì được các đồng chí cho đi ăn cơm nhà nước.

2018 cũng là năm mà lần đầu tiên dân mình biểu tình đẩy lui được luật mà cuốc hội định thông qua, luật đặc khu, cái luật mà không rõ chị Ngưn ăn phải bả gì mà trước đó đòi thông qua bằng được. À năm nay dáo sư Nạ có vẻ vượt mặt chị Tến về độ nát và độ dày mặt trong năm vừa qua.

Cuối năm này bóng đá Việt Nam(VN) vô địch AFF sau 10 năm đợi chờ, 10 năm không gặp tưởng tình đã cũ, nhưng dân mình vẫn đi bão như thường, đâu cũng thấy tự hào Việt Nam quá … dân mình chỉ có bóng đá là xuống đường tự do, bão thoải mái đi bay cả mạng. Tôi nghĩ bóng đá thôi vui thì vui chứ không nên tung hô tự hào Việt Nam, còn tự hào thì thiếu gì chỗ, ở Nhật đây dân mình phạm tội đứng đầu danh sách rồi, giờ xin visa cho mẹ sang chơi mà bổ sung đủ loại giấy tờ chi tiết, hay gần đây khách 152 du khách VN trốn lại Đài loan để lao động, làm gì có dân nước nào dám chơi qui mô cao vậy tự hào quá đi thôi.

Về quốc tế, Donal Trump đang là ngôi sao sáng nhất, mình rất thích ông này, vì không giống như các ông chính trị gia thông thường, có ông này cuộc chơi vui ơi là vui. Vừa tay bắt mặt mừng với a Tập xong, sang vn lại mang bà Trưng ra phang vào mặt ảnh (cái này chắc ông bảo đệ là “tao muốn chơi Tập, viết cho tao 1 bài”, chứ không nên hiểu là Trump biết bà Trưng, giờ hỏi khéo ổng nhầm sang bà Tưng cũng nên). Hôm trước chửi Ủn như gì, hôm sau bạn tốt. Trong khi các vị đức trị nhà sản cố giữ hình ảnh nói gì cũng kiểm duyệt trước sau,thì a bắn twitter liên hồi. Vì không chơi kiểu giữ hình ảnh, nên thằng nào éo theo anh thì a cắt kinh tế, dẹp chuyện bao cấp cho các tổ chức chung… đại loại là nhiều chuyện hay.

À, năm nay tuy blockchain xuống, y như đồ thị giá cả của nó, thì từ khóa AI vẫn ở mức rất hot, chả hiểu sao mình vẫn bình chân như vại trước xu thế nhà nhà học AI, người người làm AI nhỉ, thực sự là rất đáng lo đây ;(. Iporn của nhà táo có xu hướng đi xuống, mình thì ngồi cầu mong cho thằng nào xóa sổ được nó, không phải ghét nhà Táo mà rất muốn biết sau smartphone sẽ là cái gì, cũng như mình ăn rồi mong cho có cái kernel OS nào vượt mặt Linux kernel OS thôi.

Ghi nhanh lại mấy điểm của năm, năm 2018 của tôi là như vậy …

Creative Commons License

bzip2 & x265

Từ khi biết đến mấy chuẩn nén video gần đây (nói là gần đây nhưng thật ra từ H.264 đến giờ cũng 14 năm có lẻ rồi) như H.264, H.265 đều hỗ trợ nén không mất dữ liệu (lossless compression), bằng cách bỏ quá trình transform và quantization, xem ở mục Perceptual redundancy. Đôi lúc tôi thắc mắc xem thử so sánh sánh nó với mấy cái tool nén thường dùng nén các dữ liệu nói chung như Zip, Rar xem xem tỉ lệ nén nó cỡ bao nhiêu.

Kiểm tra bên nào nén mạnh hơn là một việc làm khá là phi khoa học, vì mục đích và đối tượng của 2 thằng khác hẳn nhau, nên việc so sánh kiểu này rất khập khiễng, không có ý nghĩa gì nhiều, cũng chả nói được lên điều chi nốt. Cơ mà mình thích thì mình thử thôi, thử qua 1 lần để từ giờ về sau đỡ “bứt rứt”.

Tôi chọn bzip2 để nén kiểu zip, lựa chọn kiểu zip là khá là ngẫu nhiên vì tôi không biết nhiều về các tool & thuật toán nén này để lựa chọn, đơn giản zip là thuật toán nén có lẽ được dùng nhiều nhất, còn chọn bzip2 là do dựa vào bài này cho thấy bzip2 nén cao so với các phần mềm nén khác như gzip, lzmash.

Về nén video, tôi chọn H.265 vì thời điểm hiện tại nó là chuẩn nén video cho phép tỉ lệ nén cao nhất. Để nén video theo chuẩn H.265 thì chọn x265, theo những gì tôi biết thì đây có vẻ là open source phổ biến và cung cấp độ nén tốt nhất so với các bộ encoder theo chuẩn H.265. Bản thân x265 được xây dựng dựa trên HM tool (HEVC model), là công cụ được nhóm JCT-VC xây dựng trong quá trình xây dựng đặc tả của H.265/HEVC.
Ngoài ra x265 thừa kế rất nhiều thuật toán nén từ x264 (nhìn cái tên chắc cũng đoán được). Mà x264 là open source tốt nhất thực hiện nén theo chuẩn H.264, nghe đâu facebook, youtube cũng dùng (nhưng tôi không tìm thấy thông tin tham khảo ngoài website chính của x264), do đó tôi nghĩ chắc x265 ngon :-), và tất nhiên cái quan trọng nhất để lựa chọn ở đây là cả nó hỗ trợ mode lossless.

Với bzip2 thì file kiểu gì cũng không thành vấn đề, nhưng với x265 vì bản chất nó nén video, nên file đó phải là số nguyên lần của frame size nào đó 🙂 ví dụ 1920×1080 hay chí ít cũng phải là 16×16, vì thế nếu dùng file bất kì thì phải thêm 1 đoạn dummy data vào cho nó đảm bảo việc alignment đấy, sau này khi cần giải nén file đã nén thì ta cắt bỏ đoán dummy data đấy ra là được.
Tuy nhiên để đơn giản thì tôi chọn luôn 1 file raw video, đây cũng là tạo điều kiện thuận lợi cho x265, coi như bzip2 cửa trên, chấp 1 quả trước.

Đầu tiên, người nông dân phải tạo file raw video, để tạo raw video ta kiếm 1 file video nào đó dạng .mp4 chẳng hạn, cái này rất dễ vì a/e thường hay phim ảnh.

$ffmpeg -i conchocon.mp4 -vframes 100 -c:v rawvideo -pix_fmt yuv420p out.yuv

File đang dùng có định dạng yuv420p, 1440×1080 → 1 frame size = 1440x1080x1.5 = 2332800 (byte), vậy 100 frame thì 233280000 byte.

Nén bằng bzip2 với option cho tỉ lệ nén cao nhất.

$bzip2 –best -z -k out.yuv

Kết quả file nén = 85802555 byte, như vậy tỉ lệ nén là 233280000/85802555 ~ 2.71 lần.

Tiếp đến nén lostless bằng x265 với option “–preset placebo” tức tối ưu về tỉ lệ nén.

$x265.exe –input out.yuv –fps 30 –preset placebo –lossless –input-res 1440×1080 –frames 100 -o lossless.h265

Kết quả file sau khi nén có kích thước 32171670 byte, đạt tỉ lệ nén là 233280000/32171670 ~ 7.25. Dùng option nén này thì thời gian nén cực kì lâu, chỉ với 100 frame tức là khoảng 3 giây video nhưng nén hết hơn 30 phút với cấu hình máy Intel(R) Core(TM) i5-3470 CPU@3.20GHz 3.20GHz, 8.00GB.

Tuy nhiên ngay cả lúc tôi chấp nhận không chọn ưu tiên mức độ nén mà chọn việc tối ưu cho tốc độ ” –preset ultrafast” để rút ngắn thời gian nén, lúc đấy hết tầm 16 giây, thì file sau khi nén cũng đạt được 40435062 byte, tỉ lệ nén là 233280000/40435062 ~ 5.77. Kết quả ngoài dự đoán của tôi.

Để chắc ăn là x265 đã thực hiện nén lostless, ta có thể dùng ffmpeg giải nén (decode) và so sánh nó với file gốc lúc đầu.

$ffmpeg -i lossless.h265 dec.yuv
$diff dec.yuv out.yuv

Do việc nén video phải cân đo đong đếm nhiều thứ để thỏa mãn đặc trưng khi nén video, như về tốc độ, về sử dụng memory …, nên tôi nghĩ rằng cho dù ở top đầu nén video như x265 đi chăng nữa thì khó ăn được bzip2 khi so sánh ở mode lossless. Thành ra kết quả nhận được làm tôi khá bất ngờ. Có vẻ như việc lựa chọn file raw video, đồng thời ít có sự chuyển cảnh đã tạo nhiều điểm lợi thế cho x265, y hệt như đang đá bóng sân nhà của x265 công thêm việc trọng tài thiên vị cho nó nốt. Lúc đầu chỉ định chơi nhởi đến đây, nhưng có vẻ quá thiệt cho bzip2, để công bằng hơn chút, lúc nào rảnh thì thử xem với kiểu file văn bản, text, doc … thì điều gì xẩy ra.

Còn nữa …

Tham khảo
[1] https://hevc.hhi.fraunhofer.de
[2] https://tukaani.org/lzma/benchmarks.html
[3] https://www.itu.int/en/ITU-T/studygroups/2013-2016/16/Pages/video/jctvc.aspx
[4] https://github.com/videolan/x265

Creative Commons License

Trình biên dịch

Làm phần mềm ít ai không biết đến cái gọi là trình biên dịch, tuy nhiên cũng đặc thù từng công việc mà mức độ hiểu biết về trình biên dịch có khác nhau.
Tôi làm về hệ thống nhúng (rất không muốn dùng từ này thay từ embedded trong tiếng Anh, nhưng cũng phải dùng cho đậm đà bản sắc dân tộc), là mảng công việc rất rất cần hiểu sâu sắc về trình biên dịch, nhưng đáng buồn là giờ tôi mới tìm hiểu, thôi thì chậm hơn là không.

Trong công việc phần mềm, thì trình biên dịch được hiểu ngắn gọn là phần mềm chuyển từ mã nguồn do lập trình viên viết ra, biến thành mã máy (trong trường hợp dotNET hay Java chắc phải hiểu khác chút).

Trình biên dịch thường là do các công ty phát triển môi trường phát triển (IDE) cho lập trình viên viết ra, nổi bật như Microsoft, với trường hợp này trình biên dịch tích hợp trong môi trường phát triển nên lập trình viên cũng không cần để ý quá nhiều. Bên cạnh đó các trình biên dịch mã nguồn mở cũng chả kém cạnh, mà đứng đầu là GCC.

Có thể tham khảo về các thể loại trình biện dịch trên Wiki, với trình biên dịch cho ngôn ngữ C thì chỗ này.

Trình biên dịch phải được phát triển rất cẩn thận, vì nếu trình biên dịch mà có lỗi thì ảnh hưởng rất lớn trong việc phát triển các phần mềm dùng trình biên dịch đó. Nếu xuất hiện tình huống lỗi phần mềm đang phát triển, mà nó lại do cái lỗi kia của trình biên dịch thì đúng là ác mộng, không khác gì việc vẽ đường thẳng bằng một cái thước cong. Tuy nhiên trên thực tế lỗi của trình biên dịch vẫn như sao trời mùa hạ, ví dụ danh sách lỗi dược báo cáo của GCC chẳng hạn, biết làm sao được nó cũng chỉ là phần mềm thôi mà. Cách đấy hơn 2 năm, tôi cũng đã từng ăn quả đắng khi trình biên dịch cho hệ thống firmware video encoder bị lỗi khi biên dịch phép tính 64bit, do không thể đợi lỗi này được xử lý ở trình biên dịch, mà phải đi vòng (workaround) bằng cách thay thế toàn bộ tính toán 64bit bằng một thư viện mới xử lý thông qua trình toán 32bit.

Công việc từ trước đến này tôi chỉ dùng GCC, ngoài việc hỗ trợ nhiều ngôn ngữ, nó còn hỗ trợ hầu hết các platform, thành ra tôi luôn nghĩ nó là “độc cô cầu bại” trong thế giới công việc nhúng. Nhưng ai có ngờ lời xưa đã chứng, đâu ra lại xuất hiện 1 thằng clang đã có chiều hướng đè bẹp GCC? Tôi chưa thử so sách xem chất lượng mã máy được biên dịch ra thế nào, còn về tốc độ biên dịch thì GCC hít khói. Nói về clang thì nó chỉ là mặt tiền (bước phân tích mã nguồn) của một thứ đang sợ hơn là LVMM, dự án này bắt đầu từ nghiên cứu của Chris Lattner. Cầu thủ này được Apple thuê hơn 10 năm, trong thời gian đó thì clang xuất hiện và thay thế GCC trong các môi trường phát triển của Apple. Sau khi không đá cho Apple nữa mà chuyển sang chơi ô tô với Elon Musk, nhưng chỉ đá được gần 6 tháng chắc thấy đá không vừa chân nên chuyển qua chơi AI với google.

Cưỡi ngựa xem hoa thế là đủ rồi, đã đến giờ “học đi đôi với hành”, để hiểu hơn về trình biên dịch thì cũng nên một lần trong đời thử viết 1 con compiler be bé xem nó ra cái gì. Để làm được cái “be bé” đó trước hết chắc phải đọc kỹ cái đống dưới.

BOOK.
[1] https://www.amazon.com/dp/0321486811/?tag=stackoverflow17-20
[2] https://www.amazon.com/dp/0471976970/?tag=stackoverflow17-20
[3] https://holub.com/goodies/compiler/compilerDesignInC.pdf

Other.
[1] https://www.quora.com/How-do-I-make-a-compiler-using-C-language
[2] https://holub.com/compiler/
[3] https://norasandler.com/2017/11/29/Write-a-Compiler.html
[4] http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
[5] https://softwareengineering.stackexchange.com/questions/165543/how-to-write-a-very-basic-compiler
[6] https://www.codeproject.com/articles/30353/designing-a-compiler

Creative Commons License

Câu chuyện từ khóa Volatile

Về từ khóa volatile thì có rất nhiều bài giải thích rồi, ví dụ như đây, đây đây nữa, tôi không muốn nhai đi nhai lại nhiều nữa.

Tuy nhiên vấn đề các tác giả đề cập đến thường là việc giá trị “biến thay đổi bất thường”, tôi không hiểu ý bất thường ở đây cụ thể là gì, bất thường đối với ai, nhưng có vẻ như là bất thường theo nghĩa trình biên dịch đọc code.
Để chắc bắp, nên tham khảo chính xác đặc tả C (or C++) xem nó nói gì, nhưng sờ vào đặc tả mới thấy nó không dễ đọc như tôi vẫn tưởng 😦

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.

Có thời gian nữa thì chắc nên nghiền ngẫm thêm chút vì thuật ngữ nghe là lạ, nhưng có thể tạm hiểu là từ khóa volatile để chỉ ra rằng biến đó có thể được thay đổi theo cách không rõ, không nhận biết được (mk, tiếng việt mình ngu quá, dài dòng vậy chứ có khi dùng từ “bất thường” là hợp lý nhất), cho nên việc tham chiếu biến đó phải tuyệt đối tuân thử đúng qui tắc máy :-o. Kết hợp thêm các ví dụ tham khảo thì tôi đang tạm hiểu ý là những chỗ đã liên quan đến từ khoá volatile thì phải tuyệt đối làm theo đúng từng mệnh lệnh mà mã nguồn đã được viết ra.
Dùng Google tìm kiếm thì có thể tóm tắt vài tình huống dưới, mà biến bị thay đổi một cách bất thường đối với trình biên dịch, làm cho nó không nhận thức được việc thay đổi đó.
– Trong chương trình có xử lý ngắt, vì xử lý ngắt tạo tình huống đặc biệt.
– Xử lý song song đa luồng, các luồng có sử dụng biến chung.
– Vùng nhớ sử dụng cho IO map.
Chính vì trình biên dịch không có khả năng (?) nhận thức, nhận biết được toàn bộ những thay đổi liên quan đến biến có mang từ khoá volatile, do đó nó phải tuân thủ từng dòng code chứ không được suy đoán, mà mục đích thường là để tối ưu khi biên dịch mã nguồn.
Tôi thì vẫn nghĩ chỉ có trường hợp 3 do trình biên dịch không thể đủ thông tin nên mới có thể làm sai khi tiến hành tối ưu code, chứ trường hợp interrupt hay xử lý đa luồng, thì rõ ràng mọi thứ trình biên dịch đều có thể nhận thức được, tôi không cho rằng cái đó là biến được thay đổi một cách bất thường. Tuy nhiên vì chưa có hiểu biết gì về cách tối ưu của trình biên dịch nên tôi cũng chỉ đưa ra nhận định chủ quan.

Sau khi đọc bài viết chỗ này, tôi đã thử 1 sampe code để test với gcc 6.3.0, dùng signal interrupt từ bàn phím, nhưng tối ưu hóa đủ mọi option vẫn không bị lỗi. Sau khi được tác giả gợi ý dùng fake interrupt bằng timer thì lại đúng là bị lỗi nếu không dùng volatile thật.
Dù sao chăng nữa thì tôi vẫn giữ quan điểm volatile chỉ cần trường hợp map IO do tác động thực sự từ yếu tố bên ngoài mà trình biên dịch có mắt cũng chả thấy được, à hoặc có thể một trường hợp là cố tình dump code theo ý người viết, mà thường thấy là tạo delay  cái này thường thấy khi lập trình cho vi điều khiển, do thư viện không hỗ trợ hàm delay, điều này cũng làm cho trình biên dịch phán đoán là đoán mã đó thừa và thực hiện tối ưu, do nó không hiểu “ngu ý” của người viết. Còn lại với những trường hợp mà bản thân trình biên dịch có đầy đủ thông tin nhưng vẫn biên dịch lỗi nếu không có volatile thì tôi nghĩ có khi phải xem xét lại bản thân trình biên dịch.

Tóm lại từ khóa volatile dùng để nói cho trình biên dịch đấy là vùng cấm, code thế nào thì hãy làm đúng như thế, mày mới chỉ biết 1 chứ chưa biết 2, phần mày đang biên dịch chỉ là 1 phần nhỏ trong hệ thống lớn, nên đừng có khôn lỏi vào chỗ đó, đừng dựa vào nhận định chủ quan mà tiến hành thay đổi code để thực hiện tối ưu.

Câu chuyện đến đây có lẽ là xong rồi, tuy nhiên có lẽ  ta dễ thấy có gì đó hơi không tự nhiên lắm, do nó chỉ bị lỗi khi yêu cầu trình biên dịch thực hiện tối ưu, vậy nếu trình biên dịch “ngây thơ” bảo gì làm nấy thì có lẽ là ta chẳng cần từ khóa volatile làm gì. Mà về tính năng tối ưu trong trình biên dịch thì tôi nghĩ nó chỉ phát triển sau này. Lúc xây dựng C không rõ trình biên dịch mà cụ Dennis Ritchie dùng có những tính năng gì (tôi không rõ ông làm thế nào để xây dựng ra C nên chỉ phán đoán thôi, nhưng dù sao chắc cũng phải vừa xây dựng đặc tả thì cũng phải song song xây dựng 1 trình biên dịch để kiểm thử).
Kiểm ra lại đặc cả ngôn ngữ C phiên bản đầu tiên thì chưa có thật, nó chỉ được thêm vào từ phiên bản số 2. Từ đó liệu ta có thể phán đoán là trong quá trình phát triển tính năng tối ưu code của trình biên dịch, nó lại yêu cầu ngược lại đặc tả phải thêm từ khóa volatile?

Như vậy “điều lệ” ban ra đã rõ ràng, tuy nhiên “chi bộ” Kernel Linux lại không tuân thủ, à cũng nói thêm là “chi bộ” này được “đồng chí” Tovard Linux thành lập từ 1990 (chú ý là “đồng chí” Ngô Thời Nhiệm không nằm trong chi bộ này). “chi bộ” này đã ra 1 “thông tư” nói không với volatile cơ bản có 2 điểm.
1. Trong mọi trường hợp trong kernel linux đều không thấy cần volatile.
2. Nếu cần thì đấy là BUG.
“Thông tư” đã viết rất rõ ràng nên ai muốn biết mời tham khảo. Tìm hiểu thêm về “chi bộ” này ta còn bắt gặp nhiều điểm bất thường khác nữa, phải chăng chính điều đó tạo nên đặc trưng cho Kernel Linux.

Tham khảo
http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html
http://publications.gbdirect.co.uk/c_book/

Creative Commons License

Con đường nào dẫn đến một ngày vui

– 2018/09/12
Sau lần đầu tiên chuyển công ty, công việc dường như vẫn không thay đổi nhiều lắm so với cách đây gần 2 năm. Cũng làm hẳn trong dự án với khách hàng, cũng là khách hàng đó luôn :-), tuy trước là mảng video coding còn giờ là 3D sensor, đúng là “mọi nẻo đường đều dẫn tới thành Rome”.

32 tuổi …
Thời điểm này, tôi đang làm ở VTI, một công ty outsource non trẻ, với quyết tâm cùng ông anh người quen xây dựng nhóm embedded software thật mạnh, có được sự tôn trọng từ khách hàng. Trước này toàn bị khách hàng nó miệt thị quen rồi.

Cơ mà, haizz…zz
Đôi lúc đọc page của top programmer, tôi lại tự hỏi không biết mình đang bỏ thời giờ ra làm cái gì thế này?

– 2018/09/16
Tôi rất thích xem phim đối kháng, khi mà chỉ cần 1 sơ suất đều phải trả giá rất đắt. Lúc lâm trận thì chỉ cần thua 1 tí, 1 kĩ năng nhỏ là phải trả giá bằng mạng sống. Nghĩ điều này giúp tôi nghiêm túc hơn để rèn luyện kỹ năng, cũng như cẩn thận hơn khi coding =))

– 2018/10/17
Công ty tôi đang làm cũng có 1 cái tech blog, viết blog kỹ thuật cho công ty là công việc luân phiên, tôi phụ trách nhóm embedded nên cũng sớm đến tay. Có vẻ ai nấy được giao đều cố trả bài cho xong. Tôi thì không ngại lắm, vì tôi copy từ đây ra =))
Cả tháng nay vật lộn với đống code của mấy thằng Bỉ, mk trước giờ toàn code C thuần là C, giờ nó chơi C++11, toàn thư viện lạ hoắc …
Cho đến giờ, tôi vẫn lười nhác nên có nghe C++11 cũng chả quan tâm, thấy mỗi C “cổ điển” theo đại ka Linus là đủ giải cứu thế giới rồi =)).
Nhưng ngẫm kỹ lại, có khi mình đang nghĩ ngu thật. Việc phát triển C++ vẫn chưa dừng, chắc là không bao giờ, ngừng vận động là ngỏm mà. Ghi lại cái link còn xem lý do tại sao nó không chịu dừng cho đỡ mệt.
https://isocpp.org/std/the-standard

À, trong lúc cao hứng nghe lại bài ngày đã đơm bông tôi đặt cái tiêu đề vậy, mà lỡ có tiêu đề rồi thì cũng cố gõ vài dòng mặc dù chả liên quan gì đến cái tiêu đề đã chọn 😀

Creative Commons License

Cảm biến 3D – TOF

Từ khi ipornX Iphone X của Apple được giới thiệu, cảm biến 3D trở thành 1 hot keyword, làm cho nhà nhà đua nhau tích hợp 3D vào điện thoại, người người thi nhau mua điện thoại có cảm biến 3D. Ông trùm SONY về mảng điện tử một thời của Nhật, mà hiện giờ mảng cảm biến đang mang lại một trong những nguồn sống chính, đã nhanh chân mở ví ra mua luôn Softkinetic, một startup của Bỉ với tầm 77 nhân sự vào 2015.
Tôi vô tình cũng bị cuốn vào xu thế đó khi tham gia dự án làm platform & driver cho con hợi này. Do đó vừa học vừa viết lại đôi điểm cho đỡ quên, nội dung rút ra từ tài liệu [1] ở phần tham khảo. Có thể học thêm về TOF ở kho tài liệu của Texas Instrument [2], rất phong phú và chi tiết.

Trong vấn đề xử lý hình ảnh, việc thu và tái hiện lại hình 3D không phải vấn đề gì mới, trước TOF đã có 2 phương pháp được sử dụng để tái tạo hình ảnh 3D.
Stereo Vision : Sử dụng 2 camera để tái hiện lại 3D, vị trí của 1 điểm sẽ được xác định nhờ vị trí tương đối của nó đối với 2 camera. Phương pháp này sử dụng tương tự hệ thống mắt người.
stereo-vision
Nguyên lý Stereo Vision (Ảnh lấy trong tài liệu[1])

Structured-light: Phương pháp này sử dụng 1 chùm tia sáng với mô hình xác định trước (dạng lưới, quét ngang …) , để chiếu lên vật thể cần quan sát, thu lại hình ảnh khi tia sáng đập lên bề mặt vật thể để xây dựng lại hình ảnh 3D của nó.
structure-ligh
Nguyên lý Structured-light  (Ảnh lấy trong tài liệu[1])

Vậy TOF là gì? so với 2 thằng ở trên thì TOF có gì khác? TOF là viết tắt của Time Of Flight, dựa trên nguyên lý đo khoảng cách bằng sóng điện từ (sóng ánh sáng ở dải mắt người không nhìn thấy). Trong hệ thống TOF, sử dụng 1 nguồn phát sóng ánh sáng, quan sát nguồn phản hồi từ đối tượng quan sát, bằng cách đo thời gian từ lúc phát ra đến lúc phản hồi thì sẽ tính được vị trí của đối tượng đó.
tof
Nguyên lý TOF (Ảnh lấy trong tài liệu[1])
Dễ thấy nguyên lý của TOF giống hệt như dùng sóng siêu âm để đo độ sâu đáy biển, tất nhiên từ lý thuyết đến thực tiễn là 1 khoảng cách không nhỏ về thời gian cũng như tiền bạc.

Bảng dưới đây cho thấy hình ảnh tổng quan của TOF khi so sánh với 2 kỹ thuật còn lại. Công nghệ thay đổi chóng mặt chả khác gì “chó chạy ngoài đồng” , nên cần chú ý rằng thông tin trong bảng này chỉ đúng với tầm thời điểm hiện tại (~2018).
tof

So sánh TOF với Stereo Vision và Structured-light (Ảnh lấy trong tài liệu[1])

Tham khảo:
[1] http://www.ti.com/lit/wp/sloa190b/sloa190b.pdf
[2] http://www.ti.com/3dtof
[3] https://en.wikipedia.org/wiki/Structured_light
[4] https://en.wikipedia.org/wiki/Time-of-flight_camera
[5] https://en.wikipedia.org/wiki/Computer_stereo_vision

Creative Commons License

3 định luật XYZ

Sau khi được nhà quí tộc Brahe để lại 1 khối lượng dữ liệu quan sát thiên văn hơn 30 năm, thì Kepler đã hoàn thành thuyết nhật tâm một cách có hệ thống bằng 3 định luật chuyển động thiên thể và những năm 1609 – 1619, lúc đấy ở Đại Việt ta bắt đầu thời kì Trịnh – Nguyễn phân tranh nên chắc chả ai có thời gian đâu mà quan tâm đến thiên với chả thể.
Tuy là tìm ra 3 định luật, nhưng Kepler cũng không hiểu “vì sao lại thế, tại vì sao lại thế, các thiên thể không chuyển động thế này mà lại là thế kia”. Người trong giang hồ phải chờ đến xuất hiện một quái kiệt mới “để tìm ra ngọn ngành”, người mà khiêm tốn nhận mình trông xa hơn vì được đứng trên vai những người khổng lồ, Newton đã đưa ra 3 định luật cơ bản, hình thành nên cơ học cổ điển hay còn gọi là cơ học Newton, cùng với định luật vạn vật hấp dẫn, đã giải thích thấu đáo tại sao qui luật chuyển động thiên thể. Cơ học Newton đã thống trị mọi lĩnh vực của Vật lý học cho đến đầu thế kỉ 19, khi mà mọi ngành nghiên cứu từ chuyển động của phân tử, đến những đối tượng to vật vã như thiên thể, hành tình đều được xây dựng theo các định luật cơ bản của Newton, mà đưa ra nhiều dự đoán đúng. Mô hình vật lý học trở nên thống nhất, rất đẹp đẽ.
Nói đến ngành nghiên cứu về tập hợp các phân tử tuân theo chuyển động cơ học, hay còn gọi là nhiệt động lực học, cũng cho ra đời 3 định luật nhiệt động lực học, trong đó từ định luật số 2 định nghĩa ra một khái niệm mới là entropy, mà nó còn dùng để định nghĩa lượng thông tin trong lý thuyết thông tin.

Tưởng chừng như “con thuyền Vật lý học cấp bến bình yên” như huân tước Kelvin (nhiều tài liệu dẫn tuyên bố này của Kelvin, tuy nhiên thực tế hình như không có thông tin chính thống), thì “2 gợn mây nhỏ” đã nổi lên thành 2 cơn giông tố làm rung chuyển và thay đổi hẳn bộ mặt ngành Vật lý. Trong cơn giông lượng tử, ta lại bắt gặp 3 định luật quang điện

Con số 3 chưa dừng ở đó, ta lại tiếp tục gặp 3 định luật về di truyền Mendel khi học sinh học hình như tầm năm lớp 9.
Hôm nay vô tình biết đến tồn lại 3 định luật hơi bị hay của Arthur C.Clarke, người nổi tiếng về những dự đoán của ông trong các tác phẩm khoa học viễn tưởng đã dần dần thành hiện thực. Nguyên văn của nó như sau:
1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
3. Any sufficiently advanced technology is indistinguishable from magic.

Tạm dịch nó như sau:
1. Khi một bậc lão thành cho rằng một chuyện gì đó là có thể xảy ra được thì ông ta hầu như chắc chắn đúng. Song khi vị này bảo rằng chuyện gì đó là không thể được, thì phần chắc là ông ta sai.
2. Cách duy nhất để xác định biên giới của cái có thể là mạo hiểm vượt qua lằn ranh đó để đi về hướng cái không thể.
3. Bất kỳ công nghệ tiên tiến nào đều không khác gì phép thần thông.

P/S: Áp dụng định luật Clarke ở trên, ta dễ dàng thấy được tuyên bố sau của Steve Wozniak là sai, thật là một định luật thú vị 🙂
http://genk.vn/dong-sang-lap-apple-tri-tue-nhan-tao-se-khong-bao-gio-du-thong-minh-de-dieu-khien-mot-chiec-o-to-20181001104135133.chn

Creative Commons License