- Nhiều hệ thống hơn so với những gì nhiều người tưởng tượng có thể hoạt động đầy đủ tốt trên phần cứng cũ
- Nếu thực hiện tối ưu phần mềm một cách thực sự, khả năng đạt được mức hiệu quả này là rất cao
- Tín hiệu giá thị trường của tài nguyên điện toán khan hiếm tạo động lực cho hiệu quả phần mềm
- Cần chuyển đổi các sản phẩm microservice dựa trên trình thông dịch hiện có sang kiến trúc nguyên khối được xây dựng bằng mã native
- Mặt khác, nếu không có tài nguyên tính toán cực rẻ và có thể mở rộng, khả năng phát triển sản phẩm mới mang tính đột phá sẽ xảy ra thưa thớt hơn nhiều
1 bình luận
Ý kiến Hacker News
Có thể lập luận rằng trên thị trường, phần mềm nhiều lỗi và kém hiệu quả vẫn bán chạy ngang phần mềm hoàn hảo; một trong hai loại là phần mềm rẻ nhất để làm ra. Điều này giống với câu chuyện về “thị trường chanh”, tức thị trường giao dịch như thể mọi sản phẩm đều chất lượng cao nhưng trên thực tế lại hy sinh chất lượng để giảm chi phí. Vì người mua không thể phân biệt hàng chất lượng cao với hàng chất lượng thấp trước khi mua, nhu cầu dành cho hai loại bị kéo lại gần nhau một cách giả tạo. Đây là hệ quả của bất cân xứng thông tin. Hiện tượng này vốn đã có thật và ngày càng trở nên hiện thực hơn trong AI: người dùng không phân biệt được giữa ứng dụng machine learning tinh vi và chiếc máy giặt chỉ được dán nhãn “AI”. Bản thân nhãn AI đã tạo ra mức giá cao hơn, nên người dùng phải trả quá nhiều tiền cho chiếc máy giặt đó. Về bản chất, việc người mua trả tiền cho phần mềm tệ vì nghĩ đó là “phần mềm do chuyên gia thiết kế và viết” cũng là cùng một chuyện. Gần như mọi phần mềm đều được viết ở mức IC1-3, và nhân sự QA ở đa số công ty trở thành chỉ dấu duy nhất cho bất kỳ nỗ lực nâng chất lượng nào. Thỉnh thoảng có các thực tập sinh hô thần chú “LGTM” với hy vọng mọi thứ sẽ khá hơn, nhưng thực tế thì ngay cả điều đó cũng hiếm
Tôi từng cố xây một startup phần mềm khác biệt bằng chất lượng, tin chắc rằng nếu sản phẩm tốt hơn thì mọi người sẽ nhận ra và thành công sẽ đến, nhưng thực tế không phải vậy. Công ty có tăng trưởng, nhưng quá chậm nên hết tiền trước cả khi có lãi. Điều tôi nhận ra là chi phí thấp, và kéo theo đó là chất lượng thấp, lại là lợi thế cạnh tranh trong thị trường cạnh tranh. Tôi đã nghe điều này từ thời đại học, nhưng chỉ đến khi trải qua mới thấm tận xương tủy. Đó là lý do mọi thứ trên thị trường đều trở nên tầm thường, và cũng là lý do chất lượng cao bị xói mòn khi sản phẩm càng phổ biến. Càng mở rộng quy mô, áp lực cắt chi phí càng lớn. Mọi người muốn mua rẻ, nên sẽ có ai đó cắt chi phí (tức chất lượng) để bán rẻ hơn. Doanh nghiệp chỉ trả mức tối thiểu để tồn tại và có lợi nhuận. Dĩ nhiên đôi lúc có ngoại lệ, nhưng cuối cùng mọi thứ vẫn trôi về phía cắt giảm chi phí dần dần. Chắc hẳn hiện tượng này cũng có tên riêng, hơi giống thị trường chanh nhưng không hoàn toàn; thị trường không sụp đổ, mà tạo ra một trạng thái tầm thường ổn định ở khắp nơi
Có phản biện với góc nhìn cho rằng “thị trường” đang bán mọi sản phẩm như thể đều là hàng chất lượng cao. Ở đây điều quan trọng là “chất lượng cao” nghĩa là gì. Nghe như đang nói hiệu năng kém thì chất lượng thấp, nhưng thực tế các ứng dụng bị chê hiệu năng như Teams, Slack, Jira đều có đối thủ cho hiệu năng vượt trội hẳn. Tuy vậy, nếu bảo người dùng chọn Weechat với giao diện terminal, không gọi video, không emoji thay cho Slack, thì đa số vẫn sẽ coi Weechat là sản phẩm chất lượng thấp hơn. Hiệu năng cũng chỉ là một tính năng. Ví dụ, thành công ban đầu của Chrome là vì nó nhanh, và các lập trình viên Python cũng chuyển sang uv/ruff vì cải thiện hiệu năng. Nhưng nếu Slack khởi động trong 10ms thay vì 5 giây thì phần lớn người dùng cũng sẽ không quan tâm
Tôi không đồng ý rằng phần mềm kém hiệu quả là do cấu trúc thị trường chanh gây ra. Điều đó chỉ đúng khi có bất cân xứng thông tin. Trong đa số trường hợp, người ta không bận tâm lắm đến vài lỗi vặt và muốn giá rẻ hơn. Nếu trải qua QA cực kỳ nghiêm ngặt và quy trình nhiều kỹ sư cùng kiểm tra mã, chỉ cần so bảng giá là thấy ngay. Tôi từng làm phần mềm cho một hiệu sách nhỏ, làm nhanh và cũng không lấy nhiều tiền. Dù không hoàn hảo, nhưng có lỗi là sửa ngay, và khách hàng hài lòng vì họ biết đó là một thương vụ tốt
Tôi từng dùng những cổng HR, hoàn phí, theo dõi thời gian, bảo hiểm cực kỳ tệ ở các tập đoàn lớn. Chúng dở đến mức tôi phải nghi ngờ liệu người ký mua có từng dùng thử sản phẩm đó hay chưa. Nếu đội của tôi đem một sản phẩm đầy lỗi và ác mộng UI như vậy giao cho khách hàng, thì đáng bị quở trách ngay, giáng chức, thậm chí sa thải
Bản chất của việc thị trường vẫn mua “phần mềm đầy lỗi, kém hiệu quả” là thị trường đang mua <i>hỗ trợ</i>. Điều này đúng cả với Google lẫn các công ty thiếu hỗ trợ từ con người. “Hỗ trợ” xuất hiện dưới nhiều hình thức — tài liệu, video, bài blog, người sẵn sàng giúp, hỗ trợ môi trường tôi dùng (hệ điều hành, trình duyệt, v.v.), hỗ trợ loại công việc tôi muốn làm, v.v. Yếu tố số một giúp ngay cả ERP tệ nhất vẫn sống sót cuối cùng vẫn là có người thật đứng sau. Có hay không có hỗ trợ quyết định ranh giới sống còn của sản phẩm. Nếu một nhóm nhỏ muốn thắng trong cuộc chơi, cách khôn ngoan là giảm “nhu cầu hỗ trợ” và đưa hỗ trợ sang một chiều kích khác. Cách dễ nhất là thêm con người, và phải truyền đạt đúng thế mạnh của mình. Mỗi loại hỗ trợ lại được đánh giá khác nhau; ví dụ như mã nguồn mở so với mã độc quyền, nhiều người vẫn thích sản phẩm độc quyền hơn nếu họ nhận được nhiều hỗ trợ hơn là chỉ có mã
Một trong những lý do lớn khiến tôi thích mua sắm ở Costco là vì họ thường không bán đồ rác. Bộ lọc đó không phải lúc nào cũng trùng với tiêu chuẩn của tôi, nhưng vẫn là một bộ lọc chất lượng có ý nghĩa
Ngay cả khi người dùng có thể ra quyết định dựa trên chất lượng phần mềm và hiệu năng, nhìn vào danh sách ứng dụng tôi đang mở thì chẳng có ứng dụng nào có thể bị thay thế chỉ vì có cái khác chạy nhanh hơn. Ví dụ Docker, iterm2, WhatsApp đều được tôi dùng vì những lý do cụ thể. Dù có giải pháp nhanh nhất đi nữa cũng không dễ thay. Việc ngay từ đầu tồn tại một phần mềm đáp ứng đúng nhu cầu của tôi quan trọng hơn tiêu chí hiệu năng
99% phần mềm được viết mà không hề cân nhắc đến hiệu năng. Ngay cả trên HN cũng thường có xu hướng xem việc cải thiện hiệu năng là điều gần như cấm kỵ. Ngay cả kỹ sư cấp L4/5 trở lên nhiều khi cũng rất thiếu cảm giác về hiệu năng. Từ góc độ kinh doanh cũng vậy: cho đến khi phần cứng không còn chạy nổi phần mềm đó, người ta sẽ không mấy quan tâm tới hiệu quả; mà ngay cả khi đó thì giải pháp ưu tiên vẫn là mua thêm phần cứng
Cấu trúc thị trường hiện nay cho phép lúc nào cũng có thể mua phần cứng để chạy, nên phần mềm đầy lỗi và kém hiệu quả mới thống trị. Phần mềm phình ra để lấp đầy năng lực xử lý của phần cứng — đó là định luật “Andy cho, Bill lấy”. Vì thế không có động lực để làm phần mềm tinh gọn, chất lượng cao. Nhưng nếu đến một thế giới mà chip tiên tiến không còn dễ kiếm nữa, chẳng hạn vì khủng hoảng địa chính trị hay nhà máy lớn bị phá hủy, thì phần mềm tiết kiệm tài nguyên sẽ có giá trị kinh tế rất lớn — phần mềm phình to sẽ không còn chạy nổi nữa. Carmack nói rằng trong tình huống như vậy vẫn còn rất nhiều dư địa để tối ưu, nên cuối cùng ta vẫn có thể làm cho phần mềm chạy được trên những con chip đời cũ
Phần mềm được thiết kế tốt là phần mềm dễ thay thế. Ngược lại, một mớ spaghetti code đầy lỗi thì chẳng ai muốn đụng vào nên cứ ở lại mãi mãi. Nếu chỉ nhìn từ góc độ tiến hóa thuần túy, thì hiện tượng phần mềm tệ cuối cùng thống trị là điều hiển nhiên
Thị trường xe cũ trở thành thị trường chanh vì khó phân biệt xe được bảo dưỡng tốt với xe sắp hỏng. Nhưng thị trường xe mới được quản lý rất chặt nên không như vậy. Phần mềm thì lúc nào cũng là hàng mới. Cũng như chất lượng ô tô đã tăng lên suốt nhiều thập kỷ, phần mềm cũng có thể được nâng chất lượng. Chỉ cho phép bán khi đạt một chuẩn nhất định, nếu có lỗi nghiêm trọng thì phải thu hồi, cố tình bán hàng lỗi thì bị xử phạt; mọi ngành khác đều vận hành như thế
Nhờ sự xuất hiện của mô hình web 2.0 “beta vĩnh viễn” và SaaS, mức độ kiên nhẫn của người dùng cũng đã thay đổi. Microsoft qua nhiều thế hệ đã gieo vào đầu người ta ý niệm rằng “phần mềm hỏng hóc là chuyện đương nhiên”. Khi ai cũng bị thuần hóa bởi phần mềm tệ, họ sẽ không còn cảm nhận rõ giá trị của phần mềm tốt nữa
Tôi thật sự đã mua cái máy giặt gắn mác AI đó. Tôi thấy buồn cười vì marketing, nhưng giá hợp lý nên vẫn mua
Có lẽ họ chỉ đang nói về lỗ hổng bảo mật. Nếu Excel hay Photoshop đầy lỗi hiệu năng hoặc các lỗi khác, người ta sẽ sớm bỏ dùng. Nhưng bảo mật thì người dùng không nhận ra cho đến khi có sự cố, mà ngay cả khi bị hack họ cũng chẳng biết nguyên nhân là gì. Vì vậy nhà phát triển không có động lực. Còn về hiệu năng, khi đã đạt đến một mức đủ dùng thì người ta không muốn tiếp tục đổ thêm nguồn lực vào tối ưu nữa; đó là quy luật lợi ích giảm dần
Dù người dùng không phân biệt được AI tinh vi với “máy giặt AI” chỉ có vỏ ngoài, một AI tốt vẫn có thể giúp chính người dùng vượt qua bất cân xứng thông tin. Cuối cùng, chỉ cần có cách để chọn được AI tốt thì vấn đề có thể được giải quyết
Tôi không nghĩ việc làm ra “phần mềm rẻ nhất” lúc nào cũng thực sự rẻ. Ở quy mô startup thì làm ẩu có thể rẻ, nhưng khi đã lớn lên thì lại tốn kém hơn. Các hãng hàng không còn cắt giảm bằng cách bớt một quả olive, nên tôi thắc mắc vì sao bắt lập trình viên tối ưu lại bị xem là không hiệu quả. Chúng ta chỉ liên tục thêm tính năng mới, để rồi người dùng cảm nhận ứng dụng chậm đi sau mỗi lần cập nhật. Ngược lại, khi phần mềm nhanh hơn thì họ lại reo hò. Kỹ sư cư xử như MBA và chỉ lặp lại câu “không có giá trị”, nhưng “giá trị” của việc sửa bug phần mềm thực ra mang tính chủ quan rất lớn. Nhiệm vụ của kỹ sư là sửa lỗi. Thương hiệu cũng quan trọng, nhưng các thương hiệu lớn hiện nay lại xem nhẹ giá trị thương hiệu. Có lẽ vì người tiêu dùng không dễ đổi sản phẩm, nhưng ngay cả khi đổi thì cũng chỉ có thêm UI mới và thêm thứ phải học, đến mức ngay cả Apple cũng không còn trực quan
Thế giới hiện tại có lẽ vẫn có thể chạy trên phần cứng đời cũ hơn, nhưng vì CPU và phần cứng vẫn tiếp tục nhanh lên nên chẳng có lý do gì phải làm mã hiệu quả hơn
Vấn đề bất cân xứng thông tin có thể được khắc phục ở FOSS hoặc các sản phẩm độc quyền kiểu “shared source”. Nếu xem trực tiếp mã nguồn, ta có thể biết tổng thể chất lượng có tốt không. Dù không phát hiện được bug cụ thể, vẫn có thể nhìn vào độ dài hàm, chú thích, cách đặt tên để nhận ra văn hóa phát triển có tử tế hay không. Thật sự mà nói, khi nhìn thấy schema DB lộn xộn trong một sản phẩm độc quyền đắt tiền thì tôi không thể tin nó được
Phần mềm tệ về dài hạn sẽ có chi phí tạo ra và duy trì đắt hơn
Vì vậy mới nói thương hiệu đóng vai trò người bảo vệ chất lượng
Cũng như pháp luật cấm bán thực phẩm độc hại, hết hạn hay có phụ gia gây nghiện, phần mềm cũng cần có quy định. Nhưng trước khi có GDPR thì quy định gần như vô nghĩa, và đến giờ chuyện vi phạm vẫn là thường ngày
Từ năm 1980 đến nay, năng lực tính toán đã tăng khoảng 1000 lần. Nếu giả sử việc kiểm tra biên của mảng động làm giảm hiệu năng 5% thôi — thực tế còn thấp hơn nhiều — thì ngay cả khi bật kiểm tra, chúng ta vẫn có thể dùng máy tính nhanh hơn 950 lần. Nếu quay về năm 1980 và phải chọn giữa “máy tính nhanh hơn 950 lần, ít bug hơn, dễ debug hơn” với “máy tính chỉ đơn giản nhanh hơn 1000 lần nhưng vẫn đầy bug và còn khó debug hơn”, thì đa số sẽ chọn 950 lần. Nhưng cuối cùng chúng ta lại chọn 1000 lần. Cá nhân tôi nghĩ chính phe 1000 lần đã làm mọi thứ đi chệch hướng
Nhưng 1000 lần hiệu năng đó không bị tiêu tốn vào kiểm tra biên, mà bị lãng phí vào vô số tầng trừu tượng và sự kém hiệu quả
Tôi từng bắt nhà cung cấp phải chạy phần mềm chậm chạp, nhiều lỗi của họ trên Sparc 20. Kết quả là họ tối ưu phần mềm, và đó trở thành nền tảng để công ty thành công trên thị trường. Tối ưu là lợi thế cạnh tranh
Chỉ có thể nói như vậy nếu lấy mốc từ 1980. Một video gần đây tóm lại rằng “máy tính ngày nay không nhanh hơn máy tính 20 năm trước bao nhiêu, trừ khi được tối ưu đặc biệt thì mới cảm nhận rõ”. Tác giả bỏ qua tối ưu của compiler và một số thứ khác, nhưng trên thực tế mức tăng hiệu năng nhỏ hơn tưởng tượng rất nhiều, trong 15 năm chỉ tăng gấp đôi
Bạn nói kiểm tra biên mảng chỉ tốn 5%, nhưng không phải thuật toán nào cũng đơn giản như vậy. Tùy số lần xử lý, chỉ riêng việc thêm kiểm tra có thể làm chi phí tăng 3-4 lần. Với một số mục đích cụ thể, nếu ép buộc kiểm tra thì bản thân ngôn ngữ sẽ mất sức cạnh tranh. Trong đa số trường hợp có thể không sao, nhưng tôi nghĩ tốt hơn là tách chế độ an toàn và chế độ thường
Nếu chỉ tính riêng kiểm tra biên thì chi phí có thể thấp, nhưng overhead của bản thân ngôn ngữ an toàn còn lớn hơn nhiều. Ngôn ngữ có GC đôi khi làm mức dùng bộ nhớ tăng lên gấp nhiều lần
Đừng quên quy luật số lớn. Giảm 5% hiệu năng trên một hệ thống thì không đáng kể, nhưng nếu cộng dồn 5% tổn thất đó trên toàn bộ môi trường tính toán của thế giới thì tác động sẽ rất lớn
Tôi đồng ý rằng bản tính con người thích lợi ích ngắn hạn, nhưng kiểm tra biên động không giải quyết bản thân vấn đề bảo mật. Giải pháp cuối cùng vẫn chưa tồn tại
Gốc rễ khiến chúng ta thành ra như bây giờ là vì bị trói vào trình duyệt
Câu trả lời đầu tiên thực chất gần như là đáp án đúng; chỉ riêng việc C vẫn còn được dùng rộng rãi đã cho thấy bản chất vấn đề là sự thiếu hiệu quả ở các tầng thấp hơn trong stack
Cơ sở của con số “5%” khá mơ hồ. Tôi không tin được nếu không biết nó được tính theo tiêu chí nào, và cũng tò mò liệu mỗi lần ghi một giá trị vào mảng mà phải kiểm tra thì chi phí thực tế có thể tăng hơn gấp đôi hay không
Hiện nay đa số ngôn ngữ lập trình đều hỗ trợ kiểm tra biên mảng theo mặc định
Nó gợi tôi nhớ đến thời Node.js mới xuất hiện: ưu điểm lớn là nối liền coding phía client và server, nhưng giờ thì lại thành cơn ác mộng bảo mật, nên những ngôn ngữ tối giản với code base nhỏ cũng có cái hay của chúng
Chỉ cần mọi người nhận ra sớm hơn rằng một chuỗi có thể chứa dữ liệu cỡ gigabyte, thì chuỗi kết thúc bằng null đã biến mất và ai cũng đã bớt khổ hơn nhiều
Những người thật sự tận hưởng sản phẩm nhanh hơn 1000 lần — các 1000Xers — thực ra chỉ là thiểu số rất nhỏ. Phần mềm desktop mà người dùng phổ thông trải nghiệm vẫn chậm như thường
Thực ra nhanh hơn cỡ 100.000 lần. Chỉ riêng xung nhịp đã 1000 lần, số core thêm 10 lần, bản thân lệnh với AVX các kiểu cũng thêm 10 lần, về mặt cấu trúc là nhanh hơn 1-2 triệu lần. Vậy mà tốc độ cảm nhận được gần như chẳng thay đổi
Có người trích lời Robert Barton gọi những người như vậy là “các đại tư tế của một giáo phái hạ đẳng”
Từ 1980 đến nay thì đúng là nhanh hơn nhiều, nhưng nếu nhìn từ 2005 trở đi thì chỉ khoảng 5 lần
Xung nhịp 2000 lần, IPC nhờ SIMD các kiểu thêm 80 lần, nhân thêm số core vào thì cuối cùng nhanh hơn 1-2 triệu lần, vậy mà phần lớn chương trình lại được tác giả viết với tâm thế “chỉ cần chạy là tốc độ của nó như vậy thôi”. Số người thực sự nghĩ đến tối ưu là cực ít, và người dùng HN cũng vậy
Đáng lẽ từ năm 2001, CPU 1GHz phải là chuẩn thực thi cho phần mềm cơ bản. Trải nghiệm AI của tôi cũng rất đáng thất vọng. Tôi từng kỳ vọng LLM phải làm tốt những việc như chuyển đổi ngôn ngữ, tối ưu code, v.v., nhưng thực tế không phải vậy. Tôi còn trực tiếp bảo AI port mã Unix sed sang ngôn ngữ trên JVM, mà ngoài những thứ cơ bản ra thì mức trung cấp trở lên là thất bại hoàn toàn. Cuối cùng, toàn bộ xu hướng này nhắm tới “giảm việc làm” chứ không phải nâng chất lượng phần mềm. AI rồi sẽ tạo ra thêm nhiều phần mềm tệ
Đó chính là JavaScript, và là tương lai của người dùng
Tôi từng làm ở Google (và Facebook), và điều tôi cảm nhận rõ là phần cứng rẻ đến mức nào và việc tối ưu code phần lớn không có giá trị. Hơn 10 năm trước ở Google, quản lý tài nguyên datacenter đã là yêu cầu bắt buộc và mỗi dự án đều có ngân sách. Người ta quy đổi và so sánh tương đối giữa CPU, HDD, flash và các loại tài nguyên khác. Dù flash đắt hơn ổ cứng 20 lần, xét theo bottleneck thực tế thì nhiều lúc flash lại rẻ hơn. Các tài nguyên đó còn được quy đổi sang thời gian của kỹ sư phần mềm (1 SWE = 1 người/năm) và các đơn vị tương tự. Nếu tối ưu mà không tiết kiệm được hơn 5000 core CPU thì ngược lại còn lỗ. Chỉ các dự án rất lớn mới đáng tối ưu, còn lại thì code cũng sớm bị thay nên tối ưu là vô nghĩa. Ngoài ra, xét về khả năng sử dụng trên web, giao diện chuột cực kỳ kém hiệu quả; terminal dạng văn bản cách đây 30-40 năm còn hiệu quả hơn nhiều. Tôi từng kỳ vọng web sẽ được chuẩn hóa để tiến lên bước tiếp theo, nhưng chuyện đó đã không xảy ra. Đến giờ vẫn mỗi tuần một framework mới ra đời, và người ta còn tái hiện lại cả thanh cuộn theo cách không tương thích phần cứng. Tôi không biết lời giải cho chuyện này là gì
Theo tôi, đó là kiểu đánh giá chỉ đúng ở những công ty có chi phí kỹ sư cao, biên lợi nhuận lớn và nhiều dự án. Chỉ cần thực sự dư ra chút tiền thì tốt hơn là đưa kỹ sư đi tối ưu. Thực tế là các công ty chỉ mù quáng bắt chước Google, ra quyết định chẳng liên quan gì đến logic kinh tế, và điều đó giải thích được rất nhiều vấn đề
Tôi cũng từng ở Google, và đúng là Google hay nói đến tối ưu theo mức sử dụng trên từng CPU, nhưng trên thực tế họ nhấn mạnh cực mạnh vào hai thứ: độ trễ và mức sử dụng tổng thể của server. Cả hai đều là KPI rất quan trọng ở tầng tổ chức cao hơn nên có lượng lớn nguồn lực kỹ sư đổ vào. Khi số máy nhiều lên thì không ai muốn để chúng nhàn rỗi, và với các mảng kinh doanh nhạy với độ trễ, người ta cố giảm chỉ vài ms cũng làm
Đây là tiêu chí phù hợp với Google vì chi phí trên mỗi core ở đó rất lớn. Với đa số công ty bình thường thì hoàn toàn không áp dụng được. Đây là kiểu chỉ có tác dụng ở quy mô Facebook/Google/Netflix và tương tự
Việc Google nghĩ ra nén tốt hơn và các định dạng tuần tự hóa nhị phân cũng là để cải thiện khả năng sinh lời nội bộ của họ
Khi đọc tiêu đề bài viết, tôi đã tưởng Carmack đang chỉ trích việc tối ưu phần mềm cho phần cứng yếu. Thực ra không phải vậy; ông chỉ nêu một thí nghiệm tưởng tượng trong đó tiến bộ phần cứng dừng lại, rồi ở kết luận nói rằng “nếu không có computing rẻ và có khả năng mở rộng cao thì sẽ có ít sản phẩm đổi mới hơn”
Đây là câu chuyện có liên quan đến thread xuất hiện hôm qua
Về kết luận “không có computing rẻ và có thể mở rộng thì đổi mới sẽ giảm”, trên thực tế chúng ta gần như đã không còn đổi mới kể từ sau smartphone, và vì vốn đang phụ thuộc hoàn toàn vào tiến bộ phần cứng nên các sản phẩm mới cũng chẳng còn khác biệt về bản chất với các sản phẩm cũ
Cá nhân tôi không đồng ý với lập luận đó. Ngay cả nếu tạm dừng phát triển tính năng một thời gian, chỉ cần chuẩn bị đủ tốt thì đổi mới rồi sẽ quay lại. Có thể sẽ có một giai đoạn đi xuống, nhưng sẽ không kéo dài mãi
Cốt lõi là “bloat” không chỉ là lãng phí đơn thuần mà là sự gia tăng năng suất phát triển đến từ động cơ kinh tế. Tăng năng suất bằng những ngôn ngữ ít phức tạp hơn sẽ đem lại hiệu quả tuyển thêm người và giảm chi phí
Nếu có thể kéo dài tuổi thọ phần cứng thêm 5 hay 10 năm thay vì đào thải theo kế hoạch, chúng ta sẽ giảm được lượng rác thải điện tử khổng lồ, việc sử dụng khoáng sản hiếm và phát thải khí nhà kính. Nhưng thị trường phần mềm không phải gánh những chi phí ngoại tác đó. Sau khi phát hành thì cứ thử, sửa, lặp lại rẻ hơn nhiều so với thiết kế dài hạn. Một số mảng trong ngành game đã tìm ra công thức hiệu năng cao cộng doanh thu, nhưng nó không phổ biến rộng. Phần mềm doanh nghiệp và tiêu dùng chủ yếu chỉ quan tâm tới mức tối thiểu miễn là người dùng còn “chịu đựng được”, chứ không phải hiệu năng. Việc liên tục thêm tính năng mới và thay đổi khiến rất khó chăm chút cho hiệu năng, và trong ngân sách người ta còn để sẵn phần bù cho tỷ lệ lỗi. Khác với cách phát hành ở trạng thái tương đối “sẵn sàng”, đây là một môi trường có rủi ro từ độ phức tạp và thay đổi rất lớn
Trong hơn 10 năm qua, chúng tôi vẫn chạy toàn bộ matching engine của sàn giao dịch trên một single thread. Riêng chuyện xử lý giao dịch tuần tự thì sức mạnh tính toán đã không tăng nhanh đến thế. Nếu không phải hàng triệu TPS thì thậm chí chẳng cần scale ra cluster; thay vào đó có thể đơn giản hóa thiết kế để xử lý trên một máy duy nhất
Điểm này thật sự rất bực mình. Nhiều kiến trúc sư hệ thống cố làm hệ thống phức tạp hơn chỉ để khẳng định dấu ấn cá nhân, rồi từ đó tạo thêm hàng loạt vấn đề mới. Thiết kế ban đầu vốn đã đáp ứng được phần lớn nhu cầu, và với sức mạnh tính toán cục bộ hiện nay thì xử lý trên một máy cũng hoàn toàn ổn
Tôi tò mò tại sao việc matching lệnh lại không thể song song hóa — nếu áp dụng kiểu rút gọn log tương tự như sorting thì liệu xử lý song song có khả thi không, hay là vì trong quá trình matching ngoài việc sắp xếp đơn giản ra thì chẳng còn bao nhiêu phép tính khác?
Nếu chỉ là xử lý đơn giản thì single thread là được, nhưng nếu mỗi transaction đều cần tính toán phức tạp thì sẽ không thể. Chỉ là tôi không có đủ kiến thức miền để hình dung “xử lý phức tạp đến mức đó” trong thực tế sẽ là gì
Nếu công cụ phát triển tiếp tục tiến bộ, thì trước đây RAD giúp tạo GUI native hoàn chỉnh rất dễ, còn bây giờ Electron lại thành xu hướng chủ đạo. Kết quả là có nhiều trình duyệt web khác nhau, mỗi cái lại cài một biến thể dựa trên Chromium
Cuối cùng thì đây là bài toán kinh tế về phân bổ tài nguyên. Có nên để lập trình viên dành thời gian tối ưu phần mềm, hay để họ làm tính năng mới? Nếu vế sau tạo ra nhiều doanh thu hơn thì người ta sẽ chọn như vậy. Ngược lại, nếu tối ưu quan trọng hơn thì họ sẽ hành động theo hướng đó
Tôi đồng ý đó là vấn đề kinh tế, nhưng bản chất của nó là một ví dụ về việc công ty phần mềm đẩy ngoại tác tiêu cực cho toàn xã hội. Họ không quan tâm đến tiêu thụ năng lượng tăng thêm, sự lãng phí hay rác thải điện tử tăng lên
Đây là cấu trúc đẩy nợ kỹ thuật và nợ tài chính sang cho người khác, đồng thời làm tăng một lượng rác khổng lồ. Có thể nhiều trường hợp tối ưu thực sự không đem lại lợi ích, nhưng thói quen cứ thêm server là giải pháp thì vẫn rất đáng tiếc
Việc “thêm tính năng quan trọng hơn” còn tùy trường hợp. Tôi hầu như không dùng phần lớn tính năng mới của macOS, Windows hay Android hiện nay; điều tôi coi trọng hơn là môi trường hiệu quả và bảo mật. Với phần mềm thiết kế cũng vậy, tôi mong hiệu quả hơn là thêm tính năng. Thậm chí đôi lúc tôi còn muốn quay lại Illustrator/Photoshop của 10 năm trước. Với phần mềm làm nhạc, tính năng mới đúng là có thể cần cho nhu cầu sáng tạo, nhưng nếu làm giảm hiệu quả thì tôi vẫn khó chịu. Còn code editor thì VSCode đã đủ rồi; điều tôi muốn là nó nhanh và nhẹ hơn nữa
Trong đời sống của tôi, tối ưu hiệu quả rất quan trọng. Ví dụ khi vào bếp lấy đồ, tôi luôn tiện mang theo rác hoặc bát đĩa để không phải đi hai lượt. Phần mềm cũng tương tự. Nhưng giữa “bỏ thời gian kỹ sư đắt đỏ để tối ưu” và “thêm RAM/tài nguyên”, thì vế sau hầu như luôn rẻ hơn. Chỉ khi vấn đề đủ lớn thì tối ưu mới có lợi. Thị trường sẽ là bên quyết định lựa chọn nào có lợi hơn. Nếu lợi ích của việc bổ sung phần cứng giảm xuống, người ta sẽ chuyển sang tối ưu. Vì định luật Moore vẫn chưa chạm hẳn giới hạn nên hiện giờ vẫn là như vậy
Cuối cùng đây là vấn đề nhu cầu. Nếu người tiêu dùng coi trọng phần mềm nhanh hơn, họ sẽ sẵn sàng trả nhiều tiền hơn; nhưng trên thực tế, nếu hiệu năng kém hơn mà giá rẻ hơn thì họ thường lại chọn phương án đó
Đó chính là định nghĩa của “enshitification”
Ứng dụng Electron có rất nhiều điểm gây khó chịu về hiệu năng, nhưng nó cũng là đổi mới then chốt giúp tôi có thể chịu đựng được môi trường làm việc trên laptop Linux. Ví dụ, tôi có thể dễ dàng tham gia meeting Teams mà không cần cài đặt gì. Dù ai cũng hoài niệm về việc tối ưu code kiểu Winamp, trên thực tế sự tiện lợi trong khả năng tiếp cận của ứng dụng Electron vẫn rất hữu ích
Gần đây khi chơi game Balatro, tôi có cảm giác rằng ngay cả bây giờ, những game chỉ cần xử lý phép tính đơn giản và đồ họa đơn giản nhưng về bản chất có lẽ đã chạy được trên phần cứng thập niên 90 như Pentium II + 3dfx, thì vẫn cứ đòi cấu hình tối thiểu ngày càng cao. Tôi ngạc nhiên vì yêu cầu phần cứng bị đẩy quá mức đến độ như chỉ có laptop đời mới mới chạy nổi