Theo dõi thời gian build của developer để quyết định có nâng cấp lên M3 MacBook hay không

• incident.io quyết định có thay laptop của developer sang M3 hay không dựa trên thời gian build Go thay vì cảm nhận chủ quan, và thu thập dữ liệu thực tế về vòng lặp phản hồi trong phát triển cục bộ
• Vì hot reloader Go hiện có khó cung cấp các giá trị cần thiết, họ tự xây công cụ riêng và nạp các sự kiện build như nền tảng, bộ nhớ, trạng thái nguồn điện, giai đoạn build, file kích hoạt và tổng thời gian vào data warehouse
• Sau khi lọc bỏ các bản build thất bại, bị hủy và chạy bằng pin trong khoảng 25k bản build, họ phân tích 12.525 bản build thành công và xác nhận có khác biệt thống kê rằng build khi cắm nguồn AC nhanh hơn build bằng pin
• Kết quả là người dùng M1 thường phải chờ gần 2 phút để build hoàn tất; M2 cải thiện lớn so với M1, còn M3 là cải thiện từng bước so với M2
• Với tổng thời gian build, khác biệt về bộ nhớ không rõ rệt, nhưng ở thời gian linker, máy 32~36GB có lợi thế, nên incident.io quyết định thay máy M1 bằng M3 Pro cấu hình cơ bản 36GB

---

Tiêu chí quyết định nâng cấp là vòng lặp phản hồi khi phát triển

• Tất cả developer của incident.io đều dùng MacBook cho công việc phát triển
• Sau khi Apple công bố M3 MacBook Pro vào tháng 10/2023, CTO Pete nói rằng sẽ thay máy nếu giá trị nâng cấp được chứng minh bằng dữ liệu
• Để quyết định có nâng cấp lên M3 hay không, đội ngũ chuẩn bị ba thứ
  • Hot reloader Go tùy chỉnh
  • Thu thập telemetry build từ laptop của developer
  • Phân tích dữ liệu bằng model mới nhất của OpenAI và code interpreter
• Dù khó định lượng trực tiếp năng suất của developer, incident.io cho rằng vòng lặp phản hồi nhanh rất quan trọng với hiệu suất của developer
• Các vòng lặp phản hồi thường lặp lại trong phát triển cục bộ gồm
  • Biên dịch monolith Go
  • Sinh code như API client và interface
  • Hot reload frontend và ứng dụng mobile
• Developer của incident.io chạy toàn bộ môi trường incident.io cục bộ trên laptop, duy trì vòng lặp phản hồi dưới 30 giây từ lúc đổi code đến lúc chạy
• Vì ứng dụng Go đang tiến gần tới 1 triệu dòng code, quá trình biên dịch Go vừa thường xuyên vừa tốn kém được chọn làm chỉ số so sánh hiệu năng MacBook

Cách thu thập telemetry build

• incident.io đã dùng codegangsta/gin làm hot reloader Go từ thời điểm tạo repository GitHub ban đầu
• Họ cũng xem xét các hot reloader thay thế, nhưng không tìm thấy công cụ nào cung cấp telemetry cần thiết để phân tích thời gian build
• Dữ liệu họ muốn thu thập ở mỗi bản build gồm
  • Cấp hệ thống: nền tảng M1/M2/M3, tổng bộ nhớ, v.v.
  • Chỉ số runtime: OS, mức sử dụng bộ nhớ, nguồn điện, dung lượng pin còn lại, v.v.
  • Telemetry build: tổng thời gian, các giai đoạn build Go, file gây ra build, v.v.
• Vì không có lựa chọn có sẵn, họ tạo công cụ riêng bắt đầu từ main.go, chạy và parse output của nhiều binary trên Mac để trích xuất giá trị cần thiết
  • memory_pressure
  • docker
  • sysctl
  • pmset
• Code liên quan được công bố dưới dạng Gist
• Sau khi tạo collector hệ thống và runtime, họ bọc lệnh build Go để thu thập thời gian theo từng giai đoạn như linker và compile, cùng file kích hoạt build
• Hot reloader cuối cùng chạy trong target make run hiện có, và đây là thay đổi không hiển thị với đội ngũ engineering
• Mỗi khi build kết thúc, sự kiện telemetry được gửi tới HTTP endpoint và nạp vào data warehouse bằng trình nhận webhook của Fivetran

Luồng phân tích bằng OpenAI Assistant

• Sau vài tuần tích lũy đủ dataset, họ export kết quả select * except(payload) from developer__build_events từ BigQuery ra CSV
• Họ cung cấp cho OpenAI Assistants một prompt mô tả mục tiêu và file CSV
• Họ bật model thử nghiệm gpt-4-1106-preview và code interpreter để dùng cho phân tích dữ liệu
• Thời gian build biến động lớn ngay cả trên cùng một hệ thống, và ảnh hưởng cache của Go compiler cũng lớn, nên chỉ so sánh trung bình theo nền tảng sẽ không công bằng
  • M3 Max không có cache có thể chậm hơn một Intel MacBook cũ có cache
• Phân tích được thực hiện không phải bằng cách so sánh trung bình đơn giản, mà bằng cách chuẩn hóa điều kiện build rồi tách theo nền tảng, bộ nhớ và trạng thái nguồn điện

Làm sạch dữ liệu và điều kiện so sánh công bằng

• Toàn bộ dataset có khoảng 25k bản build, được thu thập ở nhiều thời điểm trong ngày, trên nhiều laptop và điều kiện khác nhau
• Để so sánh nền tảng một cách công bằng, họ loại trừ các bản build sau
  • Build thất bại hoặc bị hủy: vì công việc chưa hoàn tất nên không phù hợp để so sánh tốc độ build
  • Build chạy bằng pin: OS X có thể giới hạn hiệu năng để kéo dài thời lượng pin
• Sau khi loại các bản build thất bại, số bản build thành công được tổng hợp là 12.525
• Chênh lệch hiệu năng build giữa nguồn AC và pin được so sánh chủ yếu trên M1 Pro và M2 Max
• Trong kiểm định thống kê, thời gian build trung bình khi cắm nguồn AC thấp hơn, với p-value khoảng 0,0014
• Các phân tích sau đó chỉ dùng bản build thành công khi cắm nguồn AC

Vì sao thời gian build Go dao động

• Monolith Go của incident.io là đối tượng được theo dõi hiệu năng build liên tục; việc loại bỏ hoặc tinh chỉnh chính quy trình build cũng quan trọng không kém mua phần cứng
• Dự án Go gồm nhiều package, và Go compiler dùng cache để chỉ biên dịch lại những package mà nó cho là có thay đổi
• Ứng dụng incident.io được thiết kế với đồ thị phụ thuộc rộng và ít module nền tảng, để phần lớn thay đổi không dẫn tới biên dịch lại toàn bộ đồ thị
• Loại build có thể chia đại khái thành bốn nhóm
  • Hoàn tất tức thì, dưới 3 giây: thay đổi không liên quan đến Go compiler, có thể dùng binary đã cache
  • Build nhanh, dưới 30 giây: thay đổi một package đơn lẻ có ít package phụ thuộc, phần lớn cache được tái sử dụng, thời gian chủ yếu nằm ở link
  • Build trung bình, 30 giây~1 phút: sửa package tính năng có một số phụ thuộc cấp dưới, nhưng phần lớn vẫn có thể tái sử dụng
  • Build chậm, trên 1 phút: thêm type vào package nền tảng domain, khiến mọi package của ứng dụng phải được biên dịch lại
• So sánh nền tảng cần xét tới các khác biệt về tính chất build như vậy; nếu trộn mọi bản build lại với nhau sẽ thành so sánh khập khiễng

Kết quả so sánh M1, M2, M3

• Trước tiên, họ so sánh M1 Pro và M2 Max chỉ với các bản build thành công khi cắm nguồn AC
• M2 Max vượt M1 Pro đáng kể về tốc độ build, nhưng hai máy khác nhau không chỉ về chipset mà cả cấu hình bộ nhớ
• Phân bố sự kiện build thành công theo nền tảng và bộ nhớ như sau
  • Apple M1 Pro 16GB: 5.235 bản
  • Apple M2 Pro 16GB: 1.927 bản
  • Apple M2 Max 32GB: 3.842 bản
  • Apple M3 Pro 18GB: 321 bản
  • Apple M3 Pro 36GB: 899 bản
  • Apple M3 Max 36GB: 301 bản
• So sánh M1 Pro 16GB và M2 Max 32GB không hoàn toàn công bằng do khác biệt bộ nhớ
• Khi so sánh M2 Pro 16GB và M2 Max 32GB, ảnh hưởng của 32GB bộ nhớ tới tổng thời gian build có vẻ nhỏ
• M2 Pro và M2 Max nhìn chung dùng cùng một chip, trong đó Max có thêm 2 core tiết kiệm năng lượng
  • Các core này chỉ đạt khoảng 1/5 so với core hiệu năng, nên được cho là đóng góp nhỏ vào việc compile chương trình Go
• Để đánh giá M3, họ mua ba máy sau
  • M3 Pro 12-core, 6 core hiệu năng + 6 core tiết kiệm năng lượng, 18GB
  • M3 Pro 12-core, 6 core hiệu năng + 6 core tiết kiệm năng lượng, 36GB
  • M3 Max 14-core, 10 core hiệu năng + 4 core tiết kiệm năng lượng, 36GB
• Biểu đồ thời gian build của M3 Pro 18GB và 36GB tương tự nhau, nhưng dữ liệu M3 ít hơn các nền tảng khác
• Khi loại các bản build rất nhanh dưới 3 giây và so sánh M3 Pro với M3 Max, M3 Max không cho thấy cải thiện nổi bật đủ để biện minh cho mức giá cao hơn 60% so với M3 Pro cơ bản
• Đánh giá tổng thể như sau
  • Người dùng laptop M1 thường phải chờ gần 2 phút để build hoàn tất
  • M2 là nâng cấp lớn so với M1
  • M3 là cải thiện từng bước so với M2
  • Người dùng M1 sẽ nâng cấp lên M3 Pro cơ bản
  • Người dùng M2 không cần nâng cấp

Bộ nhớ thể hiện rõ hơn ở thời gian linker

• Khi so sánh tổng thời gian build, việc tăng từ 16~18GB lên 32~36GB không cho thấy cải thiện đáng kể rõ ràng
• Vì hiệu ứng bộ nhớ không hiện rõ trên biểu đồ như dự đoán, họ phân tích riêng thời gian linker trong các giai đoạn build
• Sự kiện telemetry có chứa thời gian của giai đoạn link và compile; họ tạo cột linker_time từ build_stages.link.duration_seconds để phân tích
• Khi so sánh linker_time theo nền tảng và cấu hình bộ nhớ, một mẫu hình khác xuất hiện
  • Các máy M1, M2, M3 có bộ nhớ 32~36GB gần như luôn hoàn tất link trong dưới 20 giây
  • Máy có bộ nhớ 18GB trở xuống thường gặp trường hợp link vượt quá 20 giây
• Việc thêm bộ nhớ tuy kém rõ ràng hơn ở tổng thời gian build, nhưng được xác nhận là hữu ích trong giai đoạn linker
• Họ cũng đang xem xét phương án loại Docker khỏi máy phát triển; với máy ít bộ nhớ, việc tăng bộ nhớ hệ thống khả dụng khi không có Docker có thể cải thiện thời gian link
• Trong phát triển ứng dụng mobile, simulator dùng nhiều bộ nhớ hệ thống, nên họ cho rằng nâng RAM cũng hợp lý như một khoản chi cho tương lai

Quyết định cuối cùng và tác dụng phụ

• incident.io quyết định nâng cấp máy M1 lên M3 Pro cấu hình cơ bản với 36GB bộ nhớ
• Máy M2 vốn đã có hiệu năng đủ tốt nên tạm thời không nâng cấp
• Ngoài quyết định mua laptop, họ cũng hiểu thêm về môi trường và công cụ phát triển
• Kết quả đội ngũ thu được gồm
  • Tìm ra thời gian build Go là benchmark tốt để đo hiệu năng máy developer
  • Tự xây hot reloader Go theo dõi các metric cần thiết, đồng thời có thêm cải thiện về khả dụng
  • Hiểu rõ hơn những yếu tố khiến build Go nhanh hoặc chậm
  • Xác nhận có thể dùng OpenAI Assistants cho các bài toán phân tích dữ liệu tương tự
  • Định lượng mức cải thiện của các dòng chip Apple từ góc nhìn developer Go
  • Bộ nhớ quan trọng, nhưng thể hiện rõ hơn ở thời gian linker so với tổng thời gian build

[GN⁺]

Ý kiến trên Hacker News

• Bài viết rất hay và tôi cũng thích cách thu thập, phân tích dữ liệu khá đa dạng, nhưng có lẽ sẽ dễ và chính xác hơn nhiều nếu đặt các laptop cạnh nhau rồi chạy build có đo thời gian trong cùng một kịch bản
  Có thể so sánh vài trường hợp như build toàn bộ, build gia tăng cho các thay đổi gần đây, build gia tăng cần build lại một mô-đun cụ thể; hoặc có lẽ chỉ trong một ngày là viết được script lần lượt áp dụng 100 commit Git gần nhất và đo thời gian build gia tăng
  Nếu gom thống kê toàn công ty thì độ lệch có thể lớn. Ví dụ, nhân viên mới có khả năng dùng M3, nhân viên lâu năm dùng M1; nhân viên mới thường tạo nhiều thay đổi nhỏ hơn, còn người có kinh nghiệm xử lý các phần sâu trong code hoặc những khu vực phức tạp hơn nên thời gian build có thể dài hơn
  Vì vậy bản phân tích tự thân rất tuyệt, nhưng xét đến các thiên lệch vốn có trong mẫu, tôi nghĩ trước khi xây kiến trúc thu thập dữ liệu toàn công ty thì nên bắt đầu bằng cách đơn giản: benchmark các commit gần đây trên từng laptop

  • Tôi hoàn toàn đồng ý với đề xuất này, và với tư cách người viết bài, trước hết tôi đã spot check hiệu năng của một vài tác vụ phổ biến
    Lý do thu thập dữ liệu này không chỉ là để so sánh giữa các thiết bị, mà còn để tích lũy dữ liệu lịch sử về thời gian build của lập trình viên và liên tục đo hiệu năng build nhằm phát hiện hồi quy
    Khi thấy thời gian build tăng lên, chúng tôi thường điều chỉnh cấu trúc codebase để build nhanh hơn
  • Tôi không thấy phần phân tích build qua mạng như một phương án thay thế cho M3. Dự án của tôi có khoảng 40 triệu dòng, và khi vượt qua một ngưỡng nhất định thì máy local dù nhanh đến đâu cũng không thắng được hệ thống build qua mạng do đội hạ tầng xây dựng
    M3 có thể build nhanh hơn M1 30%, nhưng build qua mạng nhanh hơn 15 lần. Có thể cân nhắc liệu đáng ra nên đầu tư vào build qua mạng thay vì cấp M3 cho lập trình viên hay không
  • Thiên lệch của mẫu là vấn đề về phương pháp phân tích. Điều này cho thấy nếu bản thân không đủ hiểu chủ đề thì không thể dựa vào trợ lý AI
    Họ đã làm kiểm định t trên dữ liệu không được lấy mẫu độc lập; nhiều điểm dữ liệu đến từ những người khác nhau, và mỗi người làm các tác vụ khác nhau nên nhu cầu tính toán có thể khác, tạo ra yếu tố gây nhiễu. Điều này vi phạm giả định cơ bản của kiểm định t, nhưng trình thông dịch code đã không chỉ ra
    Thay vào đó, có thể dùng mô hình hiệu ứng hỗn hợp tuyến tính, đưa các yếu tố như chủ sở hữu laptop, thâm niên làm hiệu ứng ngẫu nhiên
    Dù vậy dữ liệu tự nó vẫn thú vị, đặc biệt là phần RAM. Cache rất mạnh, và nhiều RAM mang lại lợi ích lớn hơn mọi người thường nghĩ. Một chiếc MacBook có nhiều RAM hơn mức thường cần sẽ dùng phần lớn RAM dư để làm cache
  • Không hiểu vì lý do gì mà có vẻ như họ đã chọn cách tốn kém nhất có thể để trả lời câu hỏi. Và họ cũng kết luận M2 là đủ, vậy tại sao kết luận cuối cùng lại là nâng cấp người dùng M1 lên M3 đắt hơn?
  • Có lẽ nên ghi lại họ đã build cái gì và như thế nào, ví dụ “repository bắt đầu từ commit này”, “áp dụng diff này”, “chạy build bằng lệnh này”
    Thu thập khoảng một tuần là có thể có được một lát cắt về tải công việc thực tế; các build đó có thể được chạy lặp lại trên từng hạng phần cứng và sau này cũng tái sử dụng được cho phần cứng mới

• Với tư cách một nhà khoa học, tôi thấy cách các lập trình viên máy tính xử lý dữ liệu khá thú vị
  Họ vẽ biểu đồ đẹp, tự động hóa phân tích rất nhanh bằng ChatGPT, và ChatGPT đưa ra một kiểm định t nghe khá hợp lý
  Nhưng có biến động theo dung lượng bộ nhớ và loại chip mà lại không nghĩ đến hồi quy tuyến tính, đồng thời vẽ các histogram khó so sánh. Có thể bổ sung trung bình đơn giản và thanh lỗi, hoặc dùng hàm phân phối tích lũy (CDF) để dễ thấy độ chồng lấn hay dịch chuyển

  • Với tư cách nhà nghiên cứu khoa học máy tính, tôi cũng có phản ứng tương tự. Hồi đại học tôi học thống kê khi học song ngành sinh học/khoa học máy tính, nhưng hình như phải đến cao học tôi mới dùng hàm phân phối tích lũy trong phân tích dữ liệu
  • Thông thường đó là việc của nhà khoa học dữ liệu, và hầu hết các đội hạ tầng kỹ thuật không có nhà khoa học dữ liệu; phần lớn thời gian cũng không thực sự cần
    Nói chung, người ta xử lý dữ liệu theo cách công cụ hiển thị, điều này cũng khá liên quan đến các bộ sản phẩm phần mềm phân tích, phân tích hiệu năng và khả năng quan sát
    Kỳ vọng một kỹ sư phần mềm trung bình phải biết CDF cũng giống như kỳ vọng họ phải biết quaternion trong đồ họa 3D hay các nền tảng viết shader
  • Phân phối rõ ràng có vẻ không phải phân phối chuẩn, và chênh lệch trung vị cũng có thể khá quan trọng. Nếu làm bước đầu, tôi có lẽ sẽ dùng kiểm định Wilcoxon
    Hoặc cũng có thể dùng hồi quy phân vị. Nếu có giả thuyết M3 > M2 > M1 thì kiểm định Jonckheere–Terpstra nổi tiếng cho các trung vị có thứ tự có lẽ rất hợp với kiểu phân tích quyết định này
  • Ở một vài chỗ họ đã dùng biểu đồ hộp, giúp so sánh rõ hơn. Nếu hiển thị toàn bộ dữ liệu bằng biểu đồ hộp thì có lẽ sẽ hiệu quả hơn
  • Với kiểu so sánh này, tôi muốn khuyến nghị biểu đồ hàm phân phối tích lũy thực nghiệm. Mỗi phân phối trở thành một đường cong, và có thể đặt nhiều đường trên cùng một biểu đồ để dễ so sánh
    Có thể xem ví dụ ở biểu đồ cuối trang này: https://ggplot2.tidyverse.org/reference/stat_ecdf.html

• Phân tích rất chắc chắn, nhưng từ trải nghiệm cá nhân, tôi muốn đưa ra một cảnh báo
  Ở một công ty phần mềm cỡ vừa khoảng 2.000 nhân viên, chúng tôi đã cố nâng cao năng suất phát triển và từng tìm hiểu phương án chuyển stack phát triển lên các instance AWS thay vì mua laptop mới
  Kết quả là nó trở thành một dự án kéo dài nhiều năm với khoảng 4 developer làm toàn thời gian, và nhìn lại thì lợi ích không xứng với chi phí. Việc tái hiện trải nghiệm phát triển hoàn toàn local trên cloud vẫn còn quá khó
  Vì vậy tôi nghĩ nâng cấp laptop là lựa chọn tốt hơn

  • Nhóm của chúng tôi đã phát triển nhắm tới một cụm K8s hoàn toàn remote suốt vài năm nay, và nó mang lại trải nghiệm developer khá mạnh
    Code nằm trên laptop, nhưng được đồng bộ theo thời gian thực với các service remote mà không cần Docker build hay deploy K8s, nên cảm giác thật sự như local
    Đặc biệt, có thể chạy ngay các bài test từ mức integration test trở lên trong lúc code, tránh được vòng lặp commit-push-pray
    Chúng tôi dùng Garden(https://docs.garden.io) cho việc này. Dù có dùng Garden hay không, nếu có công cụ phù hợp thì việc tận dụng sức mạnh của cloud trong vòng lặp phát triển nội bộ có thể rất tuyệt
    Bài viết ghi lại thêm trải nghiệm: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
  • Có thể liên quan đến quy mô. Công ty tôi khoảng 7.000 người, vài năm trước cũng bắt đầu đi theo hướng tương tự; phải mất thời gian để remote trở nên tốt hơn local, nhưng giờ thì rõ ràng là tốt hơn
    Nhiều thứ từng không thể làm được với phiên bản chỉ local nay cũng khả thi. Ví dụ khi chuyển qua lại giữa nhiều branch, thay vì đổi file local thì đổi máy, độ trễ khi chuyển ngữ cảnh thấp hơn nhiều
  • Hoàn toàn đồng ý. Nếu không thể chạy toàn bộ solution hoàn toàn ở local, sẽ có rất nhiều ma sát trong việc hiểu và suy luận về solution đó
    Khi phải dựng hơn 200 bộ phận để làm một việc gì đó, ngay cả việc xử lý một phần đơn lẻ chỉ tương tác với vài phần cũng trở nên khó
    Trong thời đại đã có server 128 core trở lên, 256 thread trở lên, tôi ngày càng nghiêng về suy nghĩ rằng với phần lớn phần mềm, quay lại monolith là tốt hơn
  • Công ty tôi nhồi quá nhiều thứ như antivirus Linux và đủ loại linh tinh khác vào cloud developer box mà không suy nghĩ, khiến build trên cả các instance type lớn cũng chậm hơn laptop hơn 10 lần và chậm hơn các máy phát triển thực thụ như Threadripper hàng trăm lần
    Đúng là lãng phí tiền bạc và thời gian. Có thể thấy việc hook mọi system call bằng phần mềm rác của vendor có hại cho toolchain kiểu Unix vốn chạy rất nhiều subprocess
  • Tôi nghĩ đây gần với vấn đề nhân sự hơn
    Ở các công ty công nghệ lớn như Google, Meta, môi trường phát triển nằm trên cloud đối với phần lớn kỹ sư phần mềm
    Đó là trải nghiệm phát triển tốt hơn local rất nhiều

• Kết luận tôi tự khảo sát, có tính cả chi phí, cho phát triển iOS là như sau
  M2 Pro tốt, nhưng mức cải thiện so với M1 Pro 10 core không quá lớn. Theo XcodeBenchmark là 136 giây so với 120 giây: https://github.com/devMEremenko/XcodeBenchmark
  M3 Pro có cảm giác bị làm yếu đi để tách biệt với M3 Max, và vì chỉ có 6 performance core nên thực chất khá giống M2 Pro
  Cuối cùng tôi đã mua một chiếc M1 Pro 10 core đã qua sử dụng nhẹ và rất hài lòng. Với chi phí chưa bằng một nửa giá M3 Pro bản cơ bản, tôi có được 85% hiệu năng; tôi cũng tính đến việc thông thường CPU phải nhanh hơn ít nhất 33–50% thì mới cảm nhận được khác biệt

  • Chuyện M3 Pro bị làm yếu đi đã được lặp đi lặp lại trên Internet từ sau khi ra mắt, nhưng thực tế nó là một lựa chọn tuyệt vời
    Nó hiệu quả hơn M2 Pro rất nhiều trong khi hiệu năng nhỉnh hơn một chút. Ở laptop, đó là điều tôi muốn, còn băng thông bộ nhớ thì tôi không có mấy dịp dùng đến
  • Trải nghiệm của tôi cũng tương tự. Trong thời gian compile thực tế, M1 Pro vẫn bám khá sát các mẫu M2, M3 dành cho laptop hiện nay
    Không có khác biệt lớn như trong bài này. Có thể tùy ngôn ngữ hoặc dự án, nhưng khi benchmark cùng một lệnh compile đặt cạnh nhau, tôi không thấy chênh lệch lớn như vậy
  • Thú vị là mức cải thiện của M2 nhỏ hơn so với những gì bài này cho thấy
    Toolchain compile khác nhau nên cũng không đáng ngạc nhiên, và ngay cả với Go toolchain cũng có thể thấy các thông số cụ thể tác động khác nhau lên từng giai đoạn build, chẳng hạn bộ nhớ bổ sung giúp hiệu năng linker
    Tôi cũng đã nhiều lần thấy phản ứng rằng hiệu năng M3 bị giới hạn một cách kỳ lạ, hy vọng điều đó sẽ không tiếp diễn ở các mẫu từ M4 trở đi
  • Gần đây tôi cũng tính toán tương tự và cuối cùng mua một chiếc M1 Pro nâng tối đa bộ nhớ và ổ đĩa. Đó là một món hời và là một chiếc máy tính tuyệt vời
  • Tôi thích M1 MacBook Air cho phát triển iOS. Thứ tôi muốn ở dòng Pro chỉ là màn hình, đặc biệt là PPI
    Có 120Hz cũng tốt, nhưng có lẽ nó sẽ không xuất hiện trên các laptop Air

• Tôi từng là người đóng góp cốt lõi cho Chromium và Node.js, hiện là người đóng góp cốt lõi cho gRPC Core/C++, nhưng chưa bao giờ thấy thời gian build là điều khiến mình quá bận tâm
  Có “build tương tác”, tức build tăng dần để chạy lại các unit test liên quan trong lúc làm việc, và build không tương tác, tức chạy rồi đi uống cà phê hoặc đọc email. Tôi chưa từng thấy việc đổi phần cứng biến một build không tương tác thành tương tác
  Máy cá nhân của tôi là Intel i7 đã hơn 5 năm tuổi với 16GB RAM, và khi biết cần thêm bộ nhớ để link Node.js trên WSL, tôi đã gắn thêm 16GB
  Laptop công việc là Intel MacBook Pro có Touch Bar, và tôi không nghĩ nó ảnh hưởng lớn đến năng suất. Điều quan trọng là kích thước và chất lượng màn hình, cùng tốc độ lưu trữ. So với tiến bộ CPU, hệ thống build như tốc độ build tăng dần và hỗ trợ build phân tán có tác động lớn hơn. Với dự án cá nhân tôi dùng Bazel

  • Có vẻ lập trình viên đã chấp nhận việc compile và link mất nhiều thời gian dù chỉ thay đổi rất nhỏ trong một hàm đơn lẻ, khiến binary chỉ đổi vài byte
    Compile và link thực ra nên xong gần như tức thì, nhanh đến mức bạn không cảm thấy có bước compile
    Release build có các kỹ thuật như tối ưu hóa toàn chương trình thì lâu cũng được, nhưng vòng lặp compile/debug/test thông thường có thể tức thời. Việc compile của các ngôn ngữ hệ thống chậm đến khó tin vì lý do legacy, nhưng không nhất thiết phải như vậy
  • Tôi cũng từng dùng Blaze rồi định thử Bazel cho dự án cá nhân, nhưng vì đó là dự án backend và frontend đã Docker hóa nên các rule build nhanh chóng trở nên kỳ lạ và rất đặc thù
    Vì mất nhiều thời gian chỉnh file BUILD, tôi tự hỏi liệu nó có đáng giá hơn một Makefile bình thường không. Đó là chuyện 3 năm trước, nên có thể hệ sinh thái public hiện giờ đã tốt hơn
  • Tôi nghĩ dòng M có màn hình và tốc độ lưu trữ vượt trội khá nhiều so với Intel MBP. Khi chuyển từ Intel MBP sang M1 cho công việc, màn hình chắc chắn tốt hơn rất nhiều
    Tốc độ lưu trữ thì tôi không rõ, và toàn bộ build của chúng tôi đều chạy trên các máy phát triển từ xa rất mạnh
  • Đó là vì bạn đã quen với Bazel rồi. Tôi cũng từng như vậy
  • Chromium là một dự án khổng lồ. Với các dự án có quy mô phổ biến hơn, bạn có thể full build trên laptop trong khoảng thời gian hợp lý

• Với những người muốn phân tích dữ liệu bằng AI như trong bài viết, tôi nghĩ đưa dữ liệu vào R hoặc Stata rồi tự truy vấn sẽ dễ hơn nhiều
  Lệnh ngắn hơn, chính xác hơn, và quan trọng nhất là khả năng tái lập cao hơn
  Phần khó nhất trong phân tích dữ liệu là hiểu dữ liệu và cơ chế đã tạo ra nó. Để làm được vậy cần có mô hình nhân quả của miền vấn đề
  Nếu AI chưa được huấn luyện trước trên các dữ liệu khác của lĩnh vực đó, tôi không rõ nó có thể tạo ra mô hình nhân quả hữu ích hay không. Không có mô hình đó thì không thể diễn giải dữ liệu một cách hợp lý, và tôi cũng tò mò liệu các mô hình AI hiện tại có phát hiện được nhiễu, ảnh hưởng quá lớn của outlier, hay các biến điều tiết hiệu ứng thú vị hay không

  • Trợ lý AI dựa trên GPT-4 về cơ bản đang làm việc đó
    Khi tôi làm thì dùng Python và pandas, và có thể yêu cầu nó cho xem code đã dùng để phân tích
    Khác biệt là giữa việc đưa dữ liệu vào R/Python rồi tìm “làm xyzzzy thế nào” để tự viết code, hoặc dùng ChatGPT

• Phần “mọi developer chạy cục bộ một môi trường incident.io hoàn chỉnh trên laptop, và có vòng phản hồi dưới 30 giây từ thay đổi code đến khi chạy” có vẻ là thành quả lớn nhất
  Ngoài vài lần hỗ trợ startup trong thời gian ngắn, tôi chưa từng thấy công ty nào có thể chạy toàn bộ môi trường dev/instance cục bộ của công ty trên một máy
  Luôn có thứ gì đó không thể truy cập, và luôn có bẫy

  • Trước công việc gần đây, tôi không thể chạy cái app chết tiệt đó cục bộ và thật sự phát điên
    Tôi không hiểu vì sao mọi người không tức giận hơn với trải nghiệm developer tệ hại như vậy. Có vẻ các bạn mới ra từ đại học ngày nay không biết mình đang bỏ lỡ điều gì
  • Tôi từng làm ở một công ty như vậy, và sau khi rời đi tôi đã nhớ nó rất nhiều
    Người chưa sống trong thế giới đó không hiểu nó tốt hơn đến mức nào và sẽ hợp lý hóa theo đủ mọi cách
  • Thật khó tưởng tượng nếu không có điều này. Chúng tôi dùng k3s để chạy mọi thứ cục bộ và nó hoạt động tốt
    Tuy nhiên năm ngoái chúng tôi thêm Snowflake; nó thực sự giải quyết được vấn đề, nhưng phát triển lặp lại cho phần đó thì rất đau đớn
  • Trước đây thì có thể, nhưng khi quy mô lớn lên thì khó hỗ trợ. Mức nỗ lực tăng gần như theo bậc hai so với quy mô công ty
    Nó tuyến tính theo số dịch vụ cần hỗ trợ, và cũng tuyến tính theo số kỹ sư cần hỗ trợ. Rồi xuất hiện nhiều use case khác nhau không khớp nhau, chẳng mấy chốc đội hạ tầng trở thành nút thắt cho việc ra mắt tính năng, và mọi người bắt đầu dùng các cách riêng
    Khi chiếc hộp Pandora đó đã mở thì gần như không thể quay lại. Dù vậy, rút chu kỳ phát triển từ vài giờ/vài ngày xuống vài phút quan trọng hơn nhiều so với giảm vài phút đi 25%
  • Tôi đang cố hết sức để làm điều này khả thi trong ứng dụng đang xây. Vì phải chạy mô hình object detection và Stable Diffusion, tôi đã phải thuyết phục CEO rằng M2 Max sẽ hữu ích
    Cho đến giờ mọi thứ vẫn ổn

• Với tư cách tác giả bài viết, cảm ơn vì đã đăng
  Bài có nhiều nội dung như profiling quá trình compile Go, xây hot reloader, phân tích dataset build bằng AI, v.v.
  Kết luận là M1 đáng nâng cấp lên M3 Pro, còn trong thử nghiệm Max không tạo ra khác biệt lớn. M2 khá gần M3 nên với chúng tôi không đáng nâng cấp
  Nếu có câu hỏi tôi có thể trả lời

  • Cảm ơn vì phân tích chi tiết; tôi tò mò liệu bạn có tính chi phí thời gian kỹ thuật dành cho phân tích này không
    Tôi cũng tò mò chi phí đó ảnh hưởng thế nào đến thời gian hoàn vốn
  • Tôi tò mò bạn đã đi đến kết luận SKU Max không nhanh hơn đáng kể bằng cách nào. Phân bố trong biểu đồ trông có vẻ nhanh hơn, nhưng phần văn bản bên dưới chỉ nói là trông tương tự
  • Có thể hiểu lý do M3 Max chỉ có lợi ích nhỏ là vì workload không tận dụng tốt các core không?
    Hoặc cũng có thể công việc kết thúc quá nhanh nên trong sử dụng thực tế không tạo khác biệt
  • Tôi tò mò liệu quản lý có hoãn một số deliverable để tạo thời gian cho việc này, hay bạn làm nó như việc phụ
  • So sánh rất thú vị. Nếu có thể, tôi cũng muốn xem thêm kết quả build trên máy có 8GB RAM

• Ý tưởng thì thú vị, nhưng chất lượng phân tích dữ liệu có vẻ khá thấp và tôi không chắc liệu có thực sự học được điều mình đang nghĩ hay không
  Đặc biệt, rất khó hiểu vì sao khi chuyển từ M1 Pro sang M2 Pro, các bản build dưới 20 giây lại tăng mạnh đến vậy. Trong tác vụ biên dịch code, chênh lệch hiệu năng thực tế giữa hai máy vào khoảng 20–25%
  Việc máy M3 có ít bản build dưới 20 giây hơn máy M2, hay M3 Pro với số nhân chỉ bằng một nửa lại có nhiều bản build dưới 20 giây hơn M3 Max, cũng không hợp lý lắm
  Nhiều khả năng khác biệt trong hành vi của lập trình viên, chẳng hạn những người dùng các loại laptop khác nhau thường làm những việc khác nhau, đã tạo ra các chênh lệch này
  Một vài quan sát sau khi đọc lướt: có vẻ trình biên dịch Go không tận dụng thêm nhân CPU được nhiều; cách gộp dữ liệu về cơ bản khá bất tiện; cách so sánh cũng thiếu nhất quán vì trộn histogram với biểu đồ mật độ chia theo khoảng, và phạm vi trục y cũng khác nhau
  Mac không throttle hiệu năng CPU chỉ vì đang dùng pin. Nếu build thực sự chậm hơn khi chạy pin thì chỉ nhìn biểu đồ khó mà chắc chắn, nhưng có lẽ là do đã bật thiết lập “Low Power”

  • M3 có băng thông bộ nhớ thấp hơn, nên trong một số trường hợp sử dụng, thực chất đó là một bước lùi

• Hơi lạc đề một chút, nhưng tôi tò mò các công ty khác cân bằng giữa quản lý endpoint, phần mềm bảo mật và năng suất của lập trình viên như thế nào
  Công ty chúng tôi đang chạy hơn 5 dịch vụ nền trên cả Mac lẫn Windows của laptop lập trình viên. Bao gồm quản lý endpoint, chặn/can thiệp việc nâng quyền, chặn và kiểm tra TLS, chống mã độc, và VPN client
  Tổ hợp này ảnh hưởng lớn đến hiệu năng. Dù làm gì trên máy, các dịch vụ này cũng ngốn CPU và hiệu năng I/O, và các lập trình viên đã phàn nàn về tình trạng máy ngẫu nhiên bị đơ và khựng
  Xét việc ransomware và đánh cắp sở hữu trí tuệ đang gia tăng, tôi hiểu là cần có bảo mật, nhưng tôi tò mò liệu có công ty nào đã tìm được cách tốt hơn để cung cấp bảo mật mà ít ảnh hưởng hơn đến năng suất của lập trình viên không

  • Cách duy nhất tôi từng thấy là khi tình hình trở nên tệ thì báo cho IT/nhóm hỗ trợ, đồng thời cho họ biết các thư mục và tệp cần loại trừ để những thứ như file tạm của build không bị quét rồi làm chậm máy