Phần mềm sẽ không còn lý do gì để chạy chậm nữa

Hôm nọ, tôi thấy một dòng tweet lan truyền nói rằng những người đang bàn tán về việc các LLM tạo ra mã nguồn chậm chạp, cồng kềnh sẽ phải "muối mặt" khi chúng viết lại mọi thứ bằng assembly được tối ưu hóa siêu cấp. Chúng ta chưa đến mức muốn viết mọi thứ bằng assembly, nhưng một biến thể từ những gì Nolan Lawson đã nói về kiểm thử — rằng bạn có thể chọn số lượng lỗi mình muốn ngay bây giờ — điều mà tôi đã ghi chú một cách kém tinh tế hơn ở đây, đang trở nên đúng hơn đối với hiệu năng.

Để phản hồi một bình luận trong bài viết trước của tôi rằng chi phí cho công việc tối ưu hóa hiệu năng vốn chuyên biệt trước đây đã giảm đi nhiều bậc độ lớn, và công việc từng đòi hỏi một cá nhân hoặc một nhóm có kỹ năng hiếm có nay có thể được thực hiện bởi bất kỳ ai biết gõ vài câu, điều đó có nghĩa là bạn có thể thực hiện đủ loại tối ưu hóa vốn từng quá đắt đỏ để đáng giá đối với bất kỳ dự án nào trừ những dự án quy mô lớn nhất hoặc mang lại lợi nhuận cao nhất, Marc Brooker đã phản hồi rằng:

Hoàn toàn đồng ý với điểm kết luận của bạn. Phần mềm tùy chỉnh động, được thiết kế riêng cho một khối lượng công việc cụ thể thay vì một lớp các khối lượng công việc, có vẻ là một kết quả rất dễ xảy ra. (Điều này đi kèm với đủ loại rủi ro và cơ hội thú vị của riêng nó). Nó làm tôi nhớ đến FFTW. Và hàng tá kỹ thuật demoscene cũ kỳ lạ vốn tập trung vào việc trở nên siêu nhanh và nhỏ gọn trên một bài toán rất cụ thể (và thường là trên phần cứng rất cụ thể). Ví dụ, tôi nhớ một bản demo đã tái sử dụng mã nguồn của nó làm kết cấu (textures) để đạt được tính cục bộ bộ nhớ đệm (cache locality) tuyệt vời.

Và Michael Malis đã lưu ý rằng:

Đang có một meme lan truyền về việc AI không giúp ích được gì vì "mã nguồn chưa bao giờ là phần khó". Tôi nghĩ điều đó đúng trong một số lĩnh vực, nhưng ở những lĩnh vực khác, việc viết mã thực sự là phần khó. Các trình biên dịch JIT là một ví dụ tuyệt vời cho điều đó. Đối với nhiều phần mềm, trình biên dịch JIT sẽ giúp ích rất nhiều trong việc tăng tốc mã nguồn. Sự khan hiếm của các trình biên dịch JIT khiến tôi tin rằng việc triển khai một trình biên dịch JIT trong lịch sử là quá khó để có thể đáng giá. Các LLM đã hạ thấp rào cản gia nhập và giúp việc viết trình biên dịch JIT trở nên dễ dàng hơn nhiều. Đây là luận điểm đằng sau pgrust. Các cơ sở dữ liệu trong lịch sử là phần mềm khó xây dựng nhất và bị hạn chế vì lý do đó. Giờ đây, với AI, chúng ta có thể tham vọng hơn về loại phần mềm mà chúng ta xây dựng.

Tối ưu hóa cho một lớp khối lượng công việc

Hãy thử nghiệm điều này với FRE, công cụ regex mà chúng tôi đã xây dựng trong bài viết trước. Hãy nhớ rằng nó được tạo ra bằng cách để một tác nhân chạy vòng lặp trong một tháng để cải thiện hiệu năng công cụ regex với quyền truy cập vào bộ benchmark regex rebar. Điều này dẫn đến việc FRE bị overfit (quá khớp) nặng nề với rebar cho đến khi chúng tôi cảnh báo tác nhân rằng chúng tôi có một bộ benchmark holdout, điều này khiến tác nhân khái quát hóa các tối ưu hóa đủ tốt để hiệu năng đạt mức tạm ổn trên bộ holdout của chúng tôi. Không có lý do cụ thể nào để sử dụng một công cụ regex "nhà máy phần mềm" mà không đánh bại được một công cụ regex đã được kiểm thử kỹ lưỡng trên các benchmark holdout, nhưng một điều đáng chú ý về FRE là phiên bản biên dịch AOT gốc hoạt động khá tốt ở các tìm kiếm dài hơn. Chúng tôi đã lưu ý điều đó, và có lý do để tin rằng người ta có thể chạy trình biên dịch mã gốc trong một luồng khác trong khi ripgrep đang chạy trình khớp (matcher) thông thường của nó, sau đó chuyển sang mã gốc khi quá trình biên dịch hoàn tất và nhìn chung sẽ đạt được hiệu năng tốt hơn. Tất nhiên, điều này thường sẽ dẫn đến hiệu năng kém hơn đối với các truy vấn ngắn vì chúng ta mất một luồng cho việc biên dịch, nhưng tôi quan tâm nhiều hơn đến thời gian ripgrep chạy trong nhiều giây hoặc nhiều phút so với khi nó chỉ chạy trong vài giây, vì vậy tôi chấp nhận sự đánh đổi đó.

Theo cách tương tự như việc chúng ta có thể xây dựng một công cụ regex trong vài phút thời gian của con người, chúng ta cũng có thể thử nghiệm này trong vài phút. Tôi đã gõ vài câu và một tác nhân đã thực hiện công việc để cho phép điều này xảy ra (vốn sẽ là một phần phẫu thuật mã nguồn đáng kể đối với con người) và nó đã chạy benchmark trên các truy vấn ripgrep thực tế đến từ lịch sử codex của tôi. Đối với các truy vấn dài hơn, chúng ta thấy hiệu năng cải thiện từ 2x-4x ở đây cho một vài truy vấn rất đơn giản. Nhưng hầu hết các truy vấn đều phức tạp hơn, và khi chúng tôi chạy trên các truy vấn holdout đại diện, đối với các truy vấn mà AOT nên được bật, chúng tôi nhận được mức tăng tốc khoảng 7%. Không phải là một kết quả chấn động, nhưng cũng không phải là một kết quả tồi khi chỉ dành vài phút gõ phím cho codex (và nó vẫn đang thực hiện nhiều tối ưu hóa hơn và có lẽ sẽ tăng tốc mọi thứ hơn nữa).

Xây dựng một chỉ mục (index)?

Đây có thể coi là một việc ngớ ngẩn, vì nếu chúng ta liên tục tìm kiếm văn bản trên máy tính, điều hiển nhiên cần làm để tăng tốc không phải là viết một trình biên dịch mã gốc cho việc khớp regex, mà là tạo ra một chỉ mục. Nhưng điểm mấu chốt ở đây chỉ là loại công việc kỹ thuật này, vốn từng tốn khá nhiều thời gian và chuyên môn, giờ đây có thể được thực hiện một cách đơn giản. Và nếu chúng ta muốn xây dựng một chỉ mục văn bản, tình cờ là tôi đã từng làm việc trên BitFunnel, chỉ mục tìm kiếm của Bing được chuyên biệt hóa cho việc nạp văn bản liên tục/nhanh chóng, vốn đã giành Giải thưởng Bài báo xuất sắc nhất tại SIGIR, vì vậy tôi có thể nghĩ ra một vài thí nghiệm để thử nếu chúng ta định xây dựng một chỉ mục cục bộ nhanh cho toàn bộ máy tính của mình (các dự án tôi thấy dường như chỉ nhằm mục đích lập chỉ mục các thư mục mã nguồn của bạn, nhưng điều thực sự làm giảm hiệu năng máy tính của tôi là khi codex quyết định chạy ripgrep trên các thư mục tạm khổng lồ với hàng tấn tệp được tạo ra và sau đó mở rộng ra việc tìm kiếm trên toàn bộ máy tính của tôi khi nó không tìm thấy kết quả, vì vậy tôi muốn một chỉ mục cho toàn bộ ổ đĩa của mình chứ không chỉ mã nguồn cho một vài dự án).

Nếu tôi đang làm việc tại một phòng thí nghiệm AI và có quyền truy cập vào các thứ như các mô hình SOTA chạy trên chip Cerebras hoặc các bộ tăng tốc khác giúp tăng đáng kể tok/s và do đó tăng tải/nhu cầu tìm kiếm, tôi có thể thực sự khảo sát các bộ lập chỉ mục hiện có để xem chúng có đủ nhanh không hoặc liệu tôi có muốn tự xây dựng một cái gì đó tùy chỉnh hay không. Trong khi phiên bản mã nguồn mở của BitFunnel "chỉ" chứa một trình thông dịch bytecode và một JIT, phiên bản Bing chứa nhiều trình biên dịch JIT. Một dự án đạt được mức tối ưu hóa đó từng là một công việc lớn, nhưng "Tôi có thể làm điều đó trong một cuối tuần" giờ đây thực sự đúng với một số loại dự án này. Với tài khoản khiêm tốn $200/tháng của mình, tôi nghĩ một ripgrep nhanh hơn một chút cộng với bất kỳ chỉ mục có sẵn nào là ổn, vì vậy có lẽ dự án chỉ mục toàn bộ máy tính với tốc độ nạp nhanh này có thể để lại như một "bài tập cho người đọc (đang làm việc tại một phòng thí nghiệm AI)".

Tối ưu hóa rất rẻ

Sự sụt giảm mạnh mẽ về chi phí tối ưu hóa đã diễn ra từ tháng 11 năm 2025 và có lẽ thậm chí sớm hơn một chút với các mô hình công khai (và tôi chắc chắn là trước đó nữa với những gì các nhân viên tại các phòng thí nghiệm AI có quyền truy cập). Ví dụ từ thời GPT-5.1 hoặc 5.2, không có kiến thức về AI trò chơi, tôi đã thử xây dựng một AI cho trò Azul. Kết quả là nó trở thành AI mạnh nhất thế giới cho trò chơi đó với khoảng cách khá lớn. Từ việc đọc luận văn mô tả AI mạnh thứ 2, tôi nghĩ AI của mình có lẽ tốt hơn một chút về khía cạnh "AI", nhưng điểm chính mà nó chiến thắng là ở khía cạnh tối ưu hóa. Ví dụ, AI kia là đơn luồng còn AI của tôi là đa luồng. Vì tôi có phiên bản mã gốc cũng như phiên bản wasm bộ nhớ chia sẻ + javascript tồi tệ, và hai kiến trúc tìm kiếm khác nhau cho hai phiên bản khác nhau, vốn "đòi hỏi" các thuật toán đa luồng hoàn toàn khác nhau (minimax cho một mạng rất nhỏ và nhanh, và MCTS cho một mạng lớn hơn), đây sẽ là một công việc khá lớn nếu làm thủ công. Và, vì tôi đã để LLM chọn thuật toán đa luồng dựa trên lý luận (sai) của chính nó vài lần trước khi tự mình dành 30 phút đọc về các thuật toán đa luồng cho AI trò chơi, tôi đã phải viết lại (yêu cầu codex viết lại) thuật toán đa luồng nhiều lần.

Có rất nhiều thứ tiêu chuẩn cần làm để gỡ lỗi và xác minh một thuật toán đa luồng cho những thứ như thế này, chẳng hạn như triển khai phát lại từ nhật ký gỡ lỗi có thể tái tạo các lỗi mặc dù thuật toán là không tất định. Chỉ riêng việc đó thôi có lẽ đã tốn vài ngày đến một tuần nếu tôi làm thủ công, nhưng đó chính xác là loại công việc mà một tác nhân có thể thực hiện một cách đơn giản trong một vòng lặp (chỉ cần yêu cầu nó thử phát lại nhật ký và chèn ghi nhật ký cho tính không tất định mỗi khi bạn không nhận được bản phát lại hoàn hảo). Rất nhiều sự tẻ nhạt từng tốn để làm cho một tối ưu hóa khó khăn như thế này hoạt động đã biến mất.

Điều này cũng áp dụng cho nhiều tối ưu hóa khó khăn khác. Từ việc đã viết vi mã CPU, thực hiện xác minh CPU, làm việc trên việc tối ưu hóa chỉ mục công cụ tìm kiếm, v.v., tôi có nhiều kinh nghiệm nhìn vào các tối ưu hóa và nghĩ "hừm, cái này sẽ tăng hiệu năng thêm 2%, nhưng sẽ mất N ngày công để xác minh xem tối ưu hóa khó khăn này có hoạt động không" và đưa ra quyết định có tiếp tục hay không dựa trên việc liệu có đáng thời gian để làm cho tối ưu hóa đó hoạt động hay không. Giờ đây, khi N này đã giảm đi một hệ số khủng khiếp (biến đổi nhưng, xét về thời gian con người, thường là 1000x / 10000x / 1000000x, có lẽ giống 1000x về chi phí đô la nếu bạn so sánh chi phí token theo mức sử dụng so với kỹ sư Bing đã viết các trình biên dịch tại JIT mà chỉ mục tìm kiếm sử dụng), số lượng các loại tối ưu hóa này mà việc thực hiện trở nên hợp lý đã tăng lên rất nhiều. Điều tương tự cũng áp dụng cho các tối ưu hóa mà bạn không chắc chắn sẽ thành công. Tôi từng đôi khi nhìn vào một tối ưu hóa mà tôi không chắc liệu nó có tăng tốc mọi thứ hay không và nghĩ "việc này sẽ mất M giờ để triển khai đến mức chúng ta có đủ phép đo để đoán về tác động hiệu năng". Nhiều tối ưu hóa trong số đó giờ đây đã trở nên hợp lý để thử nghiệm.

Quay lại trường hợp AI trò chơi, ít nhất là đối với AI mà tôi đã thử, có vẻ như bạn đạt được khoảng 100 Elo cho mỗi lần tăng gấp đôi tốc độ (nhiều hơn trong cờ vua, tôi nghi ngờ vì các ván hòa rất hiếm). Chỉ riêng việc thêm đa luồng đã đủ để đánh bại hoàn toàn một AI tương đương trên một máy tính lớn. Nếu bạn xếp chồng thêm 10-20 tối ưu hóa khác mà hầu hết mọi người cảm thấy quá phiền phức để làm thủ công, sự khác biệt về sức mạnh là rất lớn và thực sự không hợp lý khi cố gắng theo kịp một AI viết tay.

Trường hợp AI trò chơi hơi phiền phức hơn so với hầu hết các phần mềm vì rất nhiều tối ưu hóa bạn muốn thực hiện thực sự làm thay đổi kết quả và không có cách nào rẻ, đơn giản để biết liệu việc tăng tốc + thay đổi kết quả có mang lại kết quả thực tế tốt hơn hay tệ hơn hay không. Và, như chúng tôi đã lưu ý trước đó, các mô hình SOTA công khai hiện nay khá tệ trong việc thiết kế thí nghiệm, vì vậy tôi phải thiết lập khung mà chúng sử dụng để xác định xem một tối ưu hóa có tốt hay không, nhưng một khi đã có khung đó, nó giống như bất kỳ bài toán tối ưu hóa nào khác. Tôi đoán những người làm việc trên các tối ưu hóa LLM cũng phải đối mặt với loại bài toán này nhưng hầu hết các bài toán tối ưu hóa đều đơn giản hơn nhiều.

Để chọn một ví dụ khác, như một phần của việc chuẩn bị cho các cuộc phỏng vấn về hiệu năng, Jamie Brandon đã thử bài kiểm tra hiệu năng tại nhà hiện đã công khai của Anthropic. Sau khi thử, anh ấy đã để Claude tiếp tục từ nơi anh ấy dừng lại và nó đã đạt được kết quả tốt hơn nhiều. Khi anh ấy nhìn vào những gì Claude đã làm mà anh ấy chưa làm, anh ấy nói rất nhiều tối ưu hóa là những thứ đã xuất hiện trong đầu anh ấy nhưng anh ấy chưa kịp thực hiện, và "[n]hững cái khác chỉ là những thứ điên rồ mà tôi sẽ không bao giờ thử trừ khi tôi làm việc này trong nhiều tuần". Anh ấy là một kỹ sư hiệu năng hợp lý và anh ấy đã nhận được lời mời làm việc cho công việc hiệu năng mà anh ấy muốn, nhưng trên một bài toán tối ưu hóa được xác định rõ ràng, anh ấy không có cơ hội chống lại một mô hình tử tế (tôi chưa tự mình thử bài toán này, nhưng tôi nghi ngờ rằng tôi cũng sẽ không có cơ hội với thời gian kiểm soát tương đương).

Tối ưu hóa đặc thù cho khối lượng công việc

Quay lại phần này trong bình luận của Marc Brooker:

Phần mềm tùy chỉnh động, được thiết kế riêng cho một khối lượng công việc cụ thể thay vì một lớp các khối lượng công việc, có vẻ là một kết quả rất dễ xảy ra.

Điều này có vẻ khá tất yếu. Trong một phản hồi khác cho bài viết của tôi, Michael Malis của pgrust đã nói điều tương tự:

[thảo luận về các tối ưu hóa pgrust]... Tôi nghĩ việc tạo ra các tối ưu hóa này đủ dễ dàng để chúng ta có thể xem xét khối lượng công việc của khách hàng và thêm chúng khi cần.

Không có bất kỳ khung hoặc thiết lập nào, ngay trước khi tôi bắt đầu viết bài này, tôi đã yêu cầu một tác nhân thực hiện tối ưu hóa đặc thù cho khối lượng công việc cho các truy vấn ripgrep của tôi (không phải chuyển đổi trình biên dịch mã gốc, chỉ là các tối ưu hóa cho công cụ FRE chung dựa trên một tập hợp các benchmark), mất khoảng 2 phút để tôi khởi chạy. Các tối ưu hóa chạy trên một tập hợp các truy vấn, và sau đó có một tập hợp truy vấn holdout sau đó để chạy thử. Việc đó vẫn đang chạy, nhưng kết quả ban đầu có vẻ hứa hẹn. Sau một lượt tối ưu hóa, phiên bản được tối ưu hóa theo khối lượng công việc nhanh hơn 2% so với ripgrep tiêu chuẩn trên tập holdout và nó vẫn đang tiếp tục nhanh hơn. 2% không phải là vấn đề lớn đối với việc sử dụng ripgrep cục bộ của tôi, nhưng xét rằng việc này chỉ mất vài phút và các tối ưu hóa được thực hiện ở đây bắt đầu khi tôi bắt đầu gõ điểm này và vẫn đang cải thiện, tôi sẽ chấp nhận mức thắng 2% ở đây (lưu ý rằng điều này không kết hợp với trình biên dịch mã gốc, vốn sẽ mang lại mức thắng tổng thể lớn hơn nếu được kết hợp đúng cách). Và hãy nhớ rằng điều này đang tận dụng công cụ regex FRE, vốn chậm hơn đáng kể so với công cụ regex của Rust trên các benchmark holdout và bị mắc kẹt với sự cải thiện chậm trên các tập holdout vì với việc tôi không biết gì về các khối lượng công việc regex và các LLM SOTA không đủ tốt trong việc thiết kế thí nghiệm để thực hiện các vòng lặp tự cải thiện mở không được hướng dẫn, chúng tôi không có cách tốt để cải thiện hiệu năng trên các tập holdout của mình. Nhưng nếu điều tôi quan tâm là hiệu năng trên khối lượng công việc của chính mình, tôi có rất nhiều dữ liệu và đang tạo ra nhiều hơn mọi lúc. Như Marc Brooker đã lưu ý ở trên, chúng ta phải cẩn thận về việc overfit nếu có sự thay đổi chế độ không có trong dữ liệu cũ, v.v., nhưng chúng ta vẫn ở trong tình thế tốt hơn so với trước đây.

Trong trường hợp tổng quát hơn, nếu bạn là người như Marc Brooker tại Amazon hoặc Michael Malis đang làm việc trên pgrust, việc không chỉ thực hiện điều này như một lần duy nhất mà làm việc với khách hàng để thí điểm một chương trình sử dụng dữ liệu của họ để tối ưu hóa mọi thứ cho họ và sau đó tìm cách mở rộng quy mô cho khách hàng nói chung là điều hợp lý. Tôi không làm việc tại một công ty nơi đó là cách sử dụng thời gian tốt nhất của tôi, nhưng thật điên rồ khi bạn có thể thấy rằng điều này sắp xảy ra đối với các công ty lớn hơn với quy mô lớn hơn, và vì chỉ mất vài phút thời gian của tôi để chạy các thí nghiệm này cho các quy trình làm việc cá nhân của mình, việc nghịch ngợm với loại công việc này trên các dự án cá nhân là khá hợp lý.

Cảm ơn Jamie Brandon, Michael Malis và Max Bittker vì những bình luận/chỉnh sửa/thảo luận.

Tái bút: Như tôi đã lưu ý trong vài bài viết gần đây, với các tác nhân lập trình, thời gian để chạy một thí nghiệm và thấy đủ kết quả để thỏa mãn sự tò mò của tôi đã giảm đi rất nhiều trong khi thời gian để làm cho một kết quả thực sự chặt chẽ không thay đổi hoặc đã tăng lên, vì vậy việc viết mọi thứ theo cách tôi từng làm sẽ có nghĩa là chạy rất ít thí nghiệm so với băng thông tôi có cho chúng. Kết quả là, tôi chỉ chạy các thí nghiệm này và chia sẻ kết quả với một vài người bạn. Như một thí nghiệm, tôi đang cố gắng viết những điều này theo cách rất nhanh và không chặt chẽ thay vì hàng năm trời các thí nghiệm này chỉ được biết đến bởi một vài người bạn. Giống như bài viết trước, tôi đặt mục tiêu viết bài này và thực hiện tất cả việc dọn dẹp trong nửa giờ và không bấm giờ nhưng khá chắc chắn là tôi đã trễ một chút.

Ngay cả khi làm điều này, thời gian để viết chúng ra đủ lâu để tôi bị tụt hậu trong việc chia sẻ các kết quả gần đây, nhưng tôi chưa có ý định chuyển sang các bài viết do LLM viết (chưa?), và tôi không nghĩ mình có thể thực tế có đủ thời gian để dọn dẹp dữ liệu và viết một bài như thế này đủ nhanh để hoàn thành trong vòng chưa đầy nửa giờ. Chỉ riêng về độ dài của bài viết này, việc gõ nó ra sẽ mất khoảng 20-30 phút bao gồm cả thời gian dừng lại và suy nghĩ về những gì tôi đang viết, và sau đó khi tôi nhìn vào dữ liệu, đôi khi có thứ gì đó trông sai đến mức tôi cần xem xét kỹ hơn để xem liệu có vấn đề cần khắc phục hay không (điều này đã xảy ra nhiều lần ở đây, và tôi mong đợi điều đó, vì tôi không dành nhiều thời gian hơn, có những vấn đề dữ liệu khác mà tôi không biết).

Dù sao đi nữa, nếu bạn có ý kiến về những bài viết nhanh (và chắc chắn là sai sót nhiều hơn) này, hãy cho tôi biết bạn nghĩ gì (X Bsky Mastodon)!

Phụ lục: Không còn lý do gì để phần mềm chậm chạp nữa

Tôi đã ghi nhận từ lâu rằng tôi hoàn toàn không đồng ý với quan điểm chung rằng các nhà phát triển của X là tồi tệ và nên cảm thấy tồi tệ vì viết mã chậm vì có rất nhiều loại chuyên môn lập trình khác nhau và không chỉ là trường hợp hầu hết các lập trình viên không có chuyên môn về hiệu năng, mà có lẽ thậm chí không hợp lý để họ phát triển (từ quan điểm những gì doanh nghiệp quan tâm, thị trường việc làm trông như thế nào, v.v.), vì vậy tất nhiên hầu hết các dự án sẽ có hiệu năng rất kém so với những gì một chuyên gia hiệu năng có thể làm.

Đối với ví dụ trên, Jamie Brandon đã nhận được lời mời từ Anthropic và bạn có lẽ không đủ khả năng chi trả cho anh ấy hoặc một người như anh ấy trừ khi bạn là OpenAI, nhưng bạn có đủ khả năng sử dụng một tác nhân lập trình có thể đánh bại anh ấy trên một bài toán tối ưu hóa có giới hạn. Tác nhân không có sự phán đoán mà anh ấy có và sẽ làm tệ hơn trên một bài toán mở (hãy nhớ rằng khi chúng tôi thử xây dựng một công cụ regex được tối ưu hóa và chỉ bảo nó không được overfit, nó tệ hơn hơn một bậc độ lớn so với các công cụ regex tốt nhất trên các benchmark holdout của chúng tôi, nhưng cũng hãy nhớ rằng sau khi nói với tác nhân rằng có một tập holdout mà nó đang làm kém, nó đã tăng tốc hiệu năng công cụ regex đủ để nhìn chung khớp với các công cụ regex hạng 2 về mặt hiệu năng, điều này vẫn cực kỳ tốt so với mức tối ưu hóa hiệu năng chung trong hầu hết các mã nguồn ngày nay), nhưng điều đó là quá đủ để đạt được hiệu năng hợp lý trên đủ loại bài toán. Bài viết này nhìn chung đã thảo luận về các vấn đề hiệu năng backend, nhưng các tác nhân dường như không tệ hơn ở hiệu năng front-end nếu bạn muốn giảm một tập hợp các chỉ số như LCP, INP, v.v.

Phụ lục: Codex đang chạy ripgrep như thế nào?

Đây là một số thông tin về sự phân bổ các truy vấn ripgrep trên máy tính của tôi. Tôi không khẳng định rằng đây là đại diện cho bất cứ điều gì đang xảy ra ở nơi khác. Sự phân bổ mẫu về độ dài của mẫu được tìm kiếm có nhiều mẫu dài hơn tôi mong đợi. P50 là 55 điểm mã unicode (tôi sẽ gọi đây là các ký tự cho đơn giản), vốn đã dài hơn những thứ tôi grep thủ công, và p90 là 119!

Chúng ta cũng có thể nhìn vào số lượng các nhánh thay thế (alternation arms) trong các regex, vốn một lần nữa phức tạp hơn nhiều so với những gì tôi làm thủ công.

Một góc nhìn khác là xem xét cách chúng tương quan với nhau. Chúng ta có nhận được nhiều nhánh thay thế hơn trong các regex khi các regex dài hơn không? Có.

Rốt cuộc thì những regex siêu dài này là gì? Nếu chúng ta nhìn vào chúng, hầu hết các regex dài nhất là các chuỗi thay thế dài qua các tên hàm hoặc tên kiểm thử, chẳng hạn như regex sau đây, dường như liên quan đến quá trình phát triển FRE.

Nhưng một số là các cấu trúc số thú vị, chẳng hạn như:

Điều này tương đương với:(?:1[3-9]|[2-9][0-9])[0-9]{2}: (nếu chạy qua ripgrep trên đầu vào gốc, nó có hiệu năng xấp xỉ như nhau). Toàn bộ quy trình cho việc đó là:

điều này có thể là một việc kỳ lạ đối với con người, nhưng các tác nhân dường như làm loại việc này mọi lúc.