About ichigo

zero starting

Lướt web

“Lướt web” là là thuật ngữ lai tạp giữa Việt lẫn Anh, nó xuất hiện cùng với sự phát triển mạnh mẽ của internet, đặc biệt là trong 5-10 năm gần đây khi internet về với cả bản làng. “Lướt web” hiểu một cách nôm na là bật máy tính hoặc điện thoại “thông minh”, vào trình duyệt web, và lướt qua các trang tin tức, mạng xã hội để cập nhật thông tin nóng mà “thế giới” đang có, phần lớn là thông tin khá vô bổ, và không hữu ích.
Theo tác giả quyển Tôi tài giỏi, bạn cũng thế thì tất cả mọi việc đều có thể chia thành 4 loại theo tính mục tiêu (tôi thích hiểu theo nghĩa cần thiết hơn), và tính cấp bách (cần làm ngay hay không).

1. Hướng đến mục tiêu và khẩn cấp, ví dụ: chiều nay không nộp tiền điện thì tối nay nóng khỏi ngủ luôn, hay là làm bài tập về nhà kẻo mai ăn con zero.
2. Hướng đến mục tiêu và không khẩn cấp, ví dụ: cải thiện công việc hiện tại.
3. Không hướng đến mục tiêu và khẩn cấp, ví dụ: comment lại cái comment của thằng bạn, trả lời tin nhắn fb msg của con bạn …
4. Không hướng đến mục tiêu và không khẩn cấp, chính là phần lớn việc “lướt web”.

Chính vì ai cũng ý thức, hoặc ngầm ý thức được việc “lướt web” xếp vào loại thứ 4, nên không ai dành thời gian chính thức cho nó, nên nó thường len lỏi vào khe thời gian tranh thủ của mọi người, ví dụ trên tàu xe, đợi gấu, đợi khám bệnh, đợi thủ tục hành chính … nhưng hiện tại dễ thấy nó chen chân vào cả những lúc đáng lẽ ra không nên/được lướt, ví dụ: vừa trông con vừa “lướt web”, vừa làm việc cũng tranh thủ “lướt web” …
“Lướt web” giúp đốt thời gian dư thừa rất là tốt, tối tối mở máy lên lướt web là 2-3 tiếng đi tong một cách nhanh như 15 phút. Einstein đang sống chắc cần bổ sung vào việc co ngắn thời gian khi lướt web vào thuyết tương đối hẹp.
Nói đến các thực thi cũng vô vàn cách, có người “lướt web” dựa vào một số trang quen thuộc, vừa vào đấy, nó post gì thì đọc nấy, có người chuyên nghiệp hơn là lướt theo từ khóa, quan tâm từ nào thì google từ đó rồi đọc, ví dụ “Ngọc Trinh + váy xuyên thấu”, “Khá Bảnh + múa quạt” … Cũng có người chỉ thích vào một vài chuiyên mục đặc biệt, ví dụ mục tâm sự của Vnexpress chẳng hạn, vào đấy đọc cách anh chị nhà báo thả sức tưởng tượng để nói phét … Thời giờ thì hầu như nhà nhà người người lướt bằng mạng xã hội, phần lớn là fuckbook, vào đấy nó biết mình thích thông tin gì là nó đưa cho mà đọc, càng đọc càng thấy “ôi, thông tin mình biết thật ra hữu hạn” và lướt …

Lảm nhảm vậy thôi, chứ “lướt web” có tác dụng rất tốt trong việc xả stress, tuy nhiên lướt có mục tiêu sẽ giúp kiếm chác được gì đó nếu không tương xứng thì cũng đỡ phí thời gian bỏ ra.
https://news.ycombinator.com
https://www.reddit.com/r/programming
https://github.com/trending
https://github.com/ZuzooVn/machine-learning-for-software-engineers
https://github.com/jwasham/coding-interview-university

Creative Commons License

Thời gian

Nhớ thầy dạy Vật lý cấp 3 thường chế diễu chúng tôi,
“Đồ ma trơi quỷ đế, ở nhà thì sách để chổng chơ, để lúc tau gọi lên hỏi bài
cũ thì lật đật mở sách ra, hối hả vừa đọc vừa cầu: Thời gian ơi, ngươi đẹp lắm đừng trôi”. Vậy mà cũng 15 năm rồi, thời gian nhanh hơn chó chạy, nhân dịp này khóa học cấp 3 tổ chức gặp mặt, tôi không thu xếp về được, rõ tiếc. Lâu lắm rồi không về thăm thầy, mà giờ thầy bị tai biến, mặc dù nói năng vẫn minh mẫn, vẫn kể chuyện thời trai trẻ rất rành rọt nhưng học sinh thì thầy không nhớ đứa nào, thành ra muốn gọi điện hỏi thăm thầy cũng không được.

Thằng bạn quen hồi cấp 3 nhưng không cùng trường, nó học chuyên lý tổng hợp (cách nói ngắn gọi của khối chuyên đại học KHTN-HN), nói mới dịch quyển The Order of Time, và nhờ mình đọc bản thảo, kiểm tra luôn lỗi cú pháp với xem chỗ nào còn khó hiểu cho nó.
Lại nhớ ngày xưa đọc lược sử thời gian, một quyển sách phổ biến kiến thức Vật lý hiện đại của Stephen Hawking, một quyển sách mà nhiều người cho rằng “bestseller chưa được đọc”, tức là nhiều người mua để trên giá và không có đọc. Tôi cũng đã từng cố đọc hết nó, nhưng không hiểu,cái đọng lại chỉ là những khái niệm như “chân trời sự cố” hay “sự kiện” gì đó của lỗ đen, đó là cái tới hạn mà bất kỳ thứ gì rơi vào đó là không còn đường về, bản thân lỗ đen con người cũng vậy, các vị nào tìm được lỗ đen rồi thì cũng nên tránh xa xa cái “chân trời sự cố” của lỗ đen bên ngoài kẻo hết đường về nhà, nếu Stephen Hawking đi thêm 1 bước ngoài Vật lý nữa thì có khi rút ra được định luật kinh điển bảo vệ hạnh phúc gia đình.
Trong quyển đó ông dành nguyên 1 chương trong đó để bàn về “mũi tên thời gian”, giờ chỉ nhớ mỗi việc thời gian trôi từ quá khứ đến tương lai lại tương đương với entropy của hệ kín luôn không giảm. Entropy lại đại lượng, được xuất phát từ nhiệt động lực học trong việc tìm kiếm lý do không tồn tại động cơ vĩnh cửu loại II, là cái loại biến hoàn toàn nhiệt thành công kiểu như hòn đá tự lạnh lại và biến cái nhiệt đó thành năng lượng để nhảy lên bàn, còn loại I là loại động cơ vĩnh cửu, không cần củi mà lò vẫn cháy (cụ đảng tổng cũng hổng có thích động cơ loại này). Rồi entropy, nó lan sang vật lý thống kê, và mò luôn đến cả lý thuyết thông tin vì nó là đại lượng đặc trưng cho tính hỗn độn của hệ thống, càng hỗn loại thì chứa đựng trong đó nhiều thông tin.
Việc entropy luôn không giảm trong hệ kín cũng có thể hiểu một cách thô thiển là anh em nhà coder phát triển phần mềm mà không thường xuyên bảo trì, tái cấu trúc thì dần dần nó trở thành một đống rác, đâu đó gọi là software entropy.
Trong quyển Trình tự thời gian (The Order of Time) trên, tác giả đã đi một bước phân tích sâu sắc hơn khi kết hợp cả vấn đề hấp dẫn lẫn vật lý lượng tử, để cố gắng phân tích sâu sắc hơn khía cạnh thời gian và cái quan hệ với Entropy, chỉ có nó mới bắt thời gian phải trôi theo chiều nào, chứ không phải bất kỳ một định luật nào khác trong Vật lý, ai muốn biết tìm đọc vì tôi quảng cáo cho nó nên không được tiết lộ nhiều.

Giống như Lược sử thời gian, thì quyển này gần như không dùng bất kỳ phương trình rối rắm nào cả, đọc 1 lúc thì cứ như đọc sách triết. Tôi thích cái kết của tác giả về “thế giới này tạo thành tự những sự kiện chứ không phải sự vật” :-). Có vẻ như là hoàng đế La mã Marcus Aurelius trong tác phẩm Suy tưởng cũng có chung quan điểm: “Thời gian là một dòng sông, một dòng chảy mãnh liệt của các sự kiện, chảy lướt và bị mang đi qua chúng ta, rồi dòng khác chảy đến và chảy đi” hay là “3 ngày trong đời hay 3 thế hệ: có gì khác nhau”.

Vậy thay vì tập trung vào sự vật để níu giữ thời gian, kiểu các chị thường phủ mặt đầy phấn để che đi vết thời gian, thì liệu rằng ta nên tập trung vào sự kiện chăng?

Có những việc bây giờ không làm , thì 5 năm nữa sẽ thấy khá tiếc, 10 năm nữa sẽ thấy rất tiếc, và 15 năm nữa sẽ thấy tiếc vô cùng tận ;-). Lâu lâu tôi mới có dịp về nhà một lần, mỗi lần về là trong xóm có vài người đi, vì bệnh tật, vì tai nạn lao động khi xa xứ làm thuê … Đúng là mỗi lần tạm biệt ai đó, cũng có thể đấy là lần cuối cùng bạn gặp người đó cho nên …
Mũi tên thời gian nó đâu có quay ngược lại được.
Entropy không giảm mà. Ôi! thời gian 🙂

Bàn phím cơ

Bàn phím có lẽ là thứ rẻ tiền nhất trong các bộ phận tối thiểu cấu thành nên cái PC đủ để dùng, đấy là cách tôi nghĩ trước đây. Đến 2013, làm việc trong công ty của Nhật thì tôi mới thấy hầu như tụi nó mang bàn phím cá nhân đến hơn là dùng bàn phím công ty cấp, từ đó mới biết để thể loại bàn phím cơ, có con giá đến tiền trăm $. Có loại hồi đó nhìn không thể mê nổi, phím thì không đủ phải dùng ké qua nút Fn, nút enter thì bé tẹo …

Khi bạn không thích, bạn có lý do cho việc đó, toàn lý do chuẩn cả, còn khi bạn thích thì cũng tương tự 😀

Khi tôi nghe đến bàn phím đến cả tiền triệu thì đây là lý do tôi nghĩ không nên phí tiền vào việc đó.
– Bàn phím bình thường, mấy chục ngàn cũng dùng được như thường,thậm chí là dùng tốt.
– Dùng phím cơ quen tay, không dùng lại được phím thường.
– Bàn phím đắt, lại mất công bảo về, xách đi xách về, phiền bỏ mịe.

Còn giờ, khi thấy muốn mua thì tôi nghĩ ra vài lý do thấy không nên trì hoãn, tạm thời bỏ qua các lý do quá bình thường như làm việc tốt hơn, hiểu suất ngon hơn … thì dưới đây là lý do của tôi.
– Với lập trình viên, bàn phím là thứ vĩnh cửu, cấu hình máy tính sớm lỗi thời, màn hình cũng vậy đổi liên tục, chỉ có bàn phím là có thể đi cùng ta đến cuối sự nghiệp, vì thế nên đầu tư cái cho tốt, làm bạn với mình 😀
– Khi đầu tư bàn phím thì kể từ đó kết quả gì cũng gắn với nó, sau này có chuyện kể cho con cháu, ví dụ như bàn phím này đã cùng bố đánh dự án này, dự án kia, bàn phím này cũng ông viết nên những dòng code bất tử đã được lưu ở repo kia (thực tế có thể là code lởm).
– Gõ bàn phím cơ nhẹ nhành hơn, mà thao tác thường xuyên với ngón tay nghe đầu có lợi cho sức khỏe hơn bàn phím cao su (việc này chưa kiểm nghiệm, cũng chưa biết có thống kê khoa học nào không).

Định mua con HHKB Pro2, nhưng giá chát chúa quá, đành dùng trước con FLICO Minila, bao giờ giàu mua thêm con kia nữa vì ở nhà và công ty đều dùng, vợ thì chỉ có 1 chứ bàn phím chắc ít nhất phải 2 cái.

IMG_3152
Creative Commons License

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