Nghệ thuật của điện toán hiệu năng cao
(theartofhpc.com)- The Art of HPC là loạt giáo trình về điện toán hiệu năng cao do Victor Eijkhout của TACC biên soạn, kết nối thành một mạch từ nền tảng của tính toán khoa học đến lập trình song song và các công cụ phát triển
- Quyển đầu tiên là sách nền tảng về tính toán khoa học, trình bày cách kiến trúc máy tính, số học, đại số tuyến tính và ODE/PDE gắn kết với nhau trong các phép tính quy mô lớn
- Quyển thứ hai giải thích MPI và OpenMP làm trọng tâm của lập trình song song, đồng thời cũng đề cập ngắn gọn đến PETSc, Kokkos, Sycl và Co-array Fortran
- Quyển thứ ba trình bày C++17 và Fortran2008 được dùng trong lập trình khoa học và kỹ thuật, có thể đọc cả cho người mới bắt đầu lẫn lập trình viên C
- Quyển thứ tư giới thiệu các công cụ quy trình phát triển cần thiết cho công việc HPC thực tế như trình biên dịch, hệ thống build và quản lý mã nguồn
Cấu trúc giáo trình The Art of HPC
- The Art of HPC là loạt giáo trình về điện toán hiệu năng cao do Victor Eijkhout của TACC biên soạn
- Loạt sách được chia theo từng tập, lần lượt bao quát nền tảng tính toán khoa học, lập trình song song, ngôn ngữ lập trình khoa học và hệ sinh thái phát triển HPC
Phạm vi từng tập
-
Volume 1: The Science of Computing
- Trình bày kiến thức nền tảng tổng quát cần thiết để hiểu về tính toán khoa học
- Bao gồm kiến trúc máy tính, kiến trúc máy tính song song, số học máy tính, đại số tuyến tính và ODE/PDE
- Giải thích cách từng thành phần kết hợp trong tính toán quy mô lớn, và cùng với Volume 2 tạo thành phần “cái gì/tại sao” và “như thế nào” của HPC
-
Volume 2: Parallel Programming for Science and Engineering
- Đây là tập nói về lập trình song song, yếu tố quan trọng trong tính toán khoa học
- Giới thiệu xoay quanh các phiên bản hiện đại của MPI và OpenMP
- Cũng có các mục ngắn về PETSc, Kokkos, Sycl và Co-array Fortran
- MPI và OpenMP được trình bày với C, Fortran, C++, còn MPI cũng bao gồm cả Python
-
Volume 3: Introduction to Scientific Programming
- Dựa trên bối cảnh C/C++ và Fortran vốn được dùng nhiều trong lập trình khoa học và kỹ thuật, sách giảng dạy C++17 và Fortran2008 hiện đại
- Chọn cách tiếp cận ưu tiên C++17 hơn C
- Có thể đọc như sách nhập môn lập trình khoa học từ đầu, hoặc như tài liệu học C++ dành cho lập trình viên C
- Bao gồm nhiều dự án lập trình dài
-
Volume 4: HPC Carpentry
- Tập này nhấn mạnh rằng hệ sinh thái tính toán khoa học không chỉ gồm ngôn ngữ lập trình và các hệ thống lập trình song song
- Giới thiệu các yếu tố cần thiết cho quy trình làm việc khoa học như trình biên dịch, hệ thống build và quản lý mã nguồn
- Thay vì là tài liệu tham khảo bao quát mọi thứ, sách gần với một bộ nhập môn phù hợp cho quy trình làm việc khoa học hơn
1 bình luận
Ý kiến trên Hacker News
Khía cạnh phần cứng/trung tâm dữ liệu của chủ đề này cũng thú vị không kém
Trước đây tôi làm bên phần mềm/dịch vụ ở AWS, và thỉnh thoảng lại lén đi nghe các buổi trình bày của đội trung tâm dữ liệu
Điều khiến tôi ngộ ra nhiều nhất là việc tăng năng lực tính toán trong trung tâm dữ liệu thực ra gần với bài toán nhiệt động lực học hơn là bản thân việc tính toán. Mật độ nút quá cao nên việc đưa điện vào rồi đưa nhiệt ra, lại còn phải cộng thêm đủ kiểu dự phòng, trở nên cực kỳ khó. Kể cả có phát hiện ra chỗ kém hiệu quả thì cũng không thể sửa như cập nhật phần mềm
Đây là chuyện của khoảng 10 năm trước nên giờ có lẽ cũng đã khác đi phần nào, nhưng việc Amazon, khởi đầu là một hiệu sách trực tuyến, lại đang ở tuyến đầu của bài toán nhiệt động lực học vẫn thật đáng ngạc nhiên
Với Cray-2, ông chọn một cách còn cực đoan hơn, dùng cấu trúc làm mát ngâm các chồng bảng mạch dày đặc trong một chất lỏng đặc biệt không dẫn điện tên là Fluorinert™: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
Nước có nhiệt dung rất lớn và có thể làm mát nhanh với khối lượng lớn tới mức nhiệt tối ưu. Dù vẫn cần quạt và điều hòa để lấy nhiệt từ những linh kiện không thể làm mát bằng chất lỏng, nhưng với các linh kiện tiêu thụ điện lớn như CPU hay GPU/động cơ tính toán thì có thể rút lượng nhiệt khổng lồ ra một cách nhanh chóng và trực tiếp
Độ phức tạp và rủi ro của rò rỉ đúng là một vấn đề, nhưng với các trung tâm dữ liệu ở quy mô của Amazon thì có lẽ đó không phải nỗi lo quá lớn
Tôi tò mò không biết công nghệ làm mát tối tân hiện nay trông như thế nào
Điều thú vị là HPC có vẻ được trừu tượng hóa khỏi phần cứng khá nhiều
Có vẻ các sách nói nhiều về lập trình SPMD, thuật toán và cấu trúc dữ liệu, song song hóa công việc, đồng bộ hóa, v.v., nhưng lại ít nói về các chi tiết kiến trúc máy tính như hệ thống con bộ nhớ của siêu máy tính, các liên kết băng thông cao như CXL, hay kiến trúc GPU
Tôi cũng tò mò không biết có phải các lớp trừu tượng và công cụ đã đủ tốt để không cần bận tâm đến những chi tiết đó nữa, hay là người làm HPC thực tế vẫn phải vặn rất nhiều nút của “hộp đen” để moi hiệu năng
Về nguyên tắc chung, để đạt khả năng mở rộng tối ưu, topology của phần mềm phải khớp với topology của phần cứng càng nhiều càng tốt. Phần mềm HPC hiệu quả bị chi phối rất mạnh bởi đặc tính phần cứng
Khi viết mã cho phần cứng HPC mới, mỗi khi tôi xin tài liệu về phần cứng và kiến trúc hệ thống thay vì tài liệu lập trình, mọi người luôn ngạc nhiên. Khi hiểu thiết kế phần cứng, cách phải thiết kế phần mềm phía trên nó trở nên rõ ràng từ những nguyên lý đầu tiên. Trong tài liệu lập trình có khá nhiều “nửa sự thật” nhằm làm cho mọi thứ trông dễ hơn thực tế đối với lập trình viên
Một số nền tảng HPC, để trông như “dễ dùng”, đã liên tục truyền đạt sai lệch về việc lập trình viên phải làm gì để đạt hiệu năng tối đa, và nếu viết phần mềm theo cách mà marketing ám chỉ thì có khi thất bại nặng nề vì không thể khai thác được hiệu năng mà silicon thực sự có thể cho ra
Bạn có thể viết mã HPC trên các lớp trừu tượng, và trên thực tế nhiều người vẫn làm vậy, nhưng tổn thất về hiệu năng và khả năng mở rộng thường là những bội số nguyên không thể tránh khỏi. Cũng như các loại phần mềm khác, nếu điều đó cho phép những lập trình viên ít lành nghề hơn vẫn có thể thiết kế mã, thì đôi khi mức tổn thất ấy vẫn được chấp nhận
HPC cũng như các lĩnh vực phần mềm khác: có rất nhiều người, trên danh nghĩa là lập trình viên chuyên nghiệp, nhưng vẫn khó tạo ra kết quả tốt một cách ổn định. Một phần đáng kể của phần cứng đắt đỏ dùng trong HPC tồn tại để bù đắp cho tổn thất hiệu năng do thiết kế phần mềm kém gây ra
Nếu muốn đạt hiệu năng tối đa thì không có đường tắt nào ngoài việc thực sự hiểu phần cứng vận hành ra sao. Không khác phần mềm nói chung, chỉ là trong HPC hệ thống phần cứng lớn và phức tạp hơn mà thôi
Nhưng nó khác với kỳ vọng. Tôi tưởng mình sẽ làm nhiều việc thiên về hiệu năng hơn, phân tích số liệu và vắt đến giọt hiệu năng cuối cùng từ cụm máy. Nói thật thì lúc đầu còn chẳng có cả hệ thống giám sát. Tôi tự dựng lên nhưng hầu như không ai dùng. Thỉnh thoảng ban lãnh đạo chỉ hỏi “cụm này bận đến mức nào” vì những lý do như biện minh ngân sách
Phần lớn “tối ưu hóa” là kiểm tra để mọi người không xin 384 CPU trong khi script chỉ dùng 16 CPU, hoặc thử xem một phần mềm nào đó có thể chạy đến bao nhiêu CPU mà chưa bị giảm hiệu năng. Tôi mới chỉ mở Intel profiler đúng hai lần
Phần lớn công việc thực ra giống hỗ trợ các nhà nghiên cứu hơn. Thường là chạy các chương trình thương mại hoặc mã nguồn mở và xử lý sự cố, hoặc lấy mã do nhóm khác viết trên cụm khác rồi làm cho nó build và chạy được trên cụm của chúng tôi. Lục tung mã Python tệ hại, cố build các dự án C++ trong môi trường CentOS 7 trên một cụm hiện đại hơn
Dù vậy vẫn khá vui. Vì tôi đã làm với nhiều ngôn ngữ khác nhau nên tôi thích cảm giác làm cho thứ gì đó chạy được, rồi đào vào crash và stack trace. Khi làm việc với thiết bị lớn, chuẩn “bình thường” của bạn sẽ bị lệch hẳn khi nhìn một máy chủ chỉ có 128GB RAM hoặc 20TB đĩa
Điều đáng sợ là những kết quả này được dùng trong thế giới thực, trong khi đôi khi những người chạy mô phỏng lại làm không đúng. Tôi từng thấy mã sai, mã nguồn bị trộn lẫn, dùng dữ liệu khác với dữ liệu mà họ tưởng là họ đang dùng, và cả những lỗi khổng lồ tồn tại suốt 3 năm. Khi đó bạn sẽ tự hỏi liệu toàn bộ công việc trong chủ đề này có trở nên vô hiệu hay không
Điểm trừ là khá nhiều công việc HPC đòi bằng thạc sĩ dù thực tế chỉ là vận hành cụm máy. Tôi không thật sự hiểu điều đó. Tôi đâu có viết phần mềm mà mình đang chạy, cũng không vận hành cụm TOP500 mới nhất. Chỉ đơn giản là nối nhiều máy với nhau qua mạng và chạy mã trên đó
Theo kinh nghiệm làm việc với các lập trình viên CUDA, họ vặn rất nhiều nút để moi hiệu năng. Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, trong một số nơi trong ngành còn gọi là “wedge”) là một trong những công cụ cốt lõi của việc tối ưu hóa hằng ngày
Tuy vậy tôi không chắc có nên gọi đó là hộp đen hay không. Cuối cùng thì có thể cũng gần như vậy. Bạn biết các nút đó làm gì và hoạt động ra sao, có thể đưa ra phỏng đoán có cơ sở, nhưng khi đo thực tế thì vẫn thường xuất hiện những bất ngờ lớn. Quy tắc đầu tiên của tối ưu hóa là đo đạc
Tôi luôn nhớ đến chương đầu của “Black Book” của Michael Abrash, “The Best Optimizer is Between Your Ears” http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf. Dù không nói về HPC hiện đại mà chủ yếu xoay quanh game PC, đây vẫn là một bài viết tuyệt vời thể hiện rất rõ triết lý hiệu năng cao
Liên quan đến trừu tượng hóa, phần tinh chỉnh nút nặng nhất nên để ở cuối quá trình tối ưu hóa. Vì nếu bạn refactor hoặc thay đổi gì đó thì sẽ phải tinh chỉnh lại từ đầu. Chỉ một thay đổi nhỏ trong register spill hay mẫu truy cập cache cũng có thể xóa sạch các tinh chỉnh chi li như cấu hình luồng, cache hay kích thước bộ nhớ dùng chung
Dù vậy, vẫn cần một lượng tinh chỉnh nút vừa phải trong suốt quá trình. Để kiểm tra, giữ cân bằng, và xây dựng trực giác về không gian hiệu năng quanh đoạn mã đó
Trên phần cứng x86_64 ngày nay không có thứ gì như hệ thống con bộ nhớ của siêu máy tính cả. Nó chỉ là các hệ thống NUMA hào nhoáng, và vấn đề lớn nhất là giữ bộ nhớ gần các lõi, tức là giữ dữ liệu cục bộ trong NUMA node tương ứng để giảm độ trễ
Việc ánh xạ tài nguyên do scheduler xử lý. Scheduler biết phần cứng, nên nó sẽ tạo ra các cgroup đáp ứng yêu cầu và được tối ưu nhiều nhất có thể, rồi đặt ứng dụng vào cgroup đó để chạy
Hiện tại, vua của các kết nối liên thông hiệu năng cao là InfiniBand, và nó tăng tốc MPI ở cấp độ fabric. Việc truyền thông điệp, broadcast và reduction kết quả có thể được thực hiện rất nhanh. Khi thông điệp đến nơi thì nó đã được reduction sẵn, và khi broadcast thì chỉ cần gửi một thông điệp duy nhất, rồi nó sẽ được broadcast ở tầng fabric. Card IB đa ngữ cảnh có nhiều queue, nên có thể chạy nhiều tác vụ MPI trên một node/card với sự cách ly queue/ngữ cảnh
Khi dùng framework cho tác vụ GPU, cấu trúc và tối ưu hóa thường được xử lý tự động ở cấp đó. Phần khó chủ yếu do các nhà phát triển framework đảm nhiệm. Driver NVIDIA cũng đúng là thứ ma thuật đen thuần túy, và xử lý một phần việc tối ưu hóa. Kết nối giữa các GPU do fabric vật lý đảm nhiệm và được quản lý bởi driver cùng daemon riêng của nó
Nếu nút thắt là CPU, thư viện thường đã được nhà cung cấp tinh chỉnh thủ công sẵn. Intel MKL, BLAS, Eigen đều như vậy, và Eigen mà cá nhân tôi từng dùng có bao gồm các gợi ý và tối ưu hóa theo từng bộ xử lý
Điều cần quan tâm là biên dịch mã cho đúng kiến trúc, và xác nhận phần cứng chạy nó có thể đáp ứng yêu cầu. Ví dụ như không truy cập bộ nhớ ngẫu nhiên quá nhiều, nếu muốn đi nhanh “hết mức có thể” trên node thì phải căn cho prefetcher và bộ dự đoán nhánh hoạt động tốt, đồng thời không lạm dụng truy cập đĩa
Trong mảng tính toán số, mấu chốt là giữ các tác vụ độc lập để có thể khai thác song song mức lệnh/vector hóa, không thực hiện các phép tính không cần thiết, và không lạm dụng MPI, tức là giảm giao tiếp giữa các node xuống mức thật sự cần thiết
Nói thì dễ, nhưng khi đã quen thì việc nghĩ đến những điều này trở thành bản năng thứ hai. Tức là nếu kiểu việc này hợp gu của bạn thì sẽ như vậy
Vừa đúng mà cũng vừa không
MPI và OpenMP là các phương tiện chính để trừu tượng hóa phần cứng trong HPC. MPI là lớp trừu tượng cho tính toán song song bộ nhớ phân tán, còn OpenMP là lớp trừu tượng cho tính toán song song bộ nhớ chia sẻ. Nhiều nhà nghiên cứu viết mã chỉ với hai thứ này, và cũng có nhiều trường hợp dùng cả hai trong cùng một mã nguồn. Khi dùng chúng, phần lớn thời gian bạn không cần bận tâm đến chi tiết kiến trúc
Dù vậy, các nhà nghiên cứu thích tối ưu sâu hơn vẫn can thiệp vào nhiều chi tiết kiến trúc nhỏ để vắt thêm hiệu năng. Ví dụ, mở cuộn vòng lặp là kỹ thuật khá phổ biến, và cá nhân tôi thấy nó có thể khá rối. Tôi mơ hồ nhớ từng nghe rằng vì một số kiến trúc CPU cụ thể mà người ta ưu tiên phép cộng hơn phép nhân để vector hóa phép tính, nhưng tôi chưa từng tận mắt thấy điều đó
Ngăn cache miss cũng là một chủ đề lớn. Một số đoạn mã được viết để giữ thông tin cần thiết nhất trong cache CPU thay vì trong bộ nhớ. Phần lớn mã chỉ xử lý ở mức bảo đảm duyệt theo cột cho phép toán mảng trong Fortran và theo hàng trong C, nhưng ý tưởng này có thể mở rộng hơn nữa. Nếu biết kích thước cache của bộ xử lý, bạn cũng có thể tối ưu một số phép toán để giữ toàn bộ thông tin cần thiết trong cache, từ đó giảm thiểu cache miss. Tôi chưa từng tận mắt thấy, nhưng trong lớp tính toán khoa học tôi học năm 2013 thì đây là chủ đề được bàn đến khá nhiều
Việc có dùng GPU cụ thể hay không phụ thuộc rất lớn vào bài toán cần giải. Có bài toán chạy rất tốt trên GPU, có bài toán thì quá khó. Phần đó thì tiếc là tôi không biết rõ lắm
Thật đáng khâm phục khi Victor đã tập hợp được bộ tư liệu tuyệt vời như vậy
Cá nhân tôi không quen biết ông ấy, nhưng hồi làm nghiên cứu sinh ở UT Austin vào những năm 1990, tôi đã hoàn thành nghiên cứu bằng cách sử dụng các tài nguyên do TACC quản lý (Cray Y-MP, IBM SP/2 Winterhawk, và hostname Lonestar khi đó dùng để chỉ Cray T3E). Một thành viên trong hội đồng bảo vệ luận án của tôi đến giờ vẫn còn ở đó. Nếu tôi nhớ không nhầm thì hồi đó TACC được gọi là HPCC hoặc CHPC
Khi ấy lập trình viên phải tự mình song song hóa mã nguồn, và trong trường hợp của tôi là dùng MPI trên Cray T3E trong môi trường UNICOS. Vì lĩnh vực này khi đó vẫn còn ở giai đoạn đầu, nên cũng cần hiểu phần nào về phần cứng. Tôi giải quyết vấn đề bằng cách đọc cuốn sổ tay Cray dạng binder vòng màu xám và cuốn sách của Gropp cùng cộng sự mà tôi có trong tay, và tất nhiên những mối liên hệ am hiểu mà tôi đã nhắc đến cũng giúp ích rất nhiều
Thời đại không bao giờ dừng lại
Dù hơi lệch khỏi lĩnh vực của tôi, nó vẫn rất hấp dẫn. Tôi định sẽ xem tiếp phần còn lại và khuyên bất kỳ ai quan tâm cũng nên thử đọc
Tôi quan tâm đến phía quản trị phần cứng của HPC
Tôi tò mò về cách sự cố được phát hiện và chẩn đoán, rồi được ánh xạ sang các hành động như khởi động lại/cài đặt lại/sửa chữa, những việc này được lên lịch ra sao và tối ưu thế nào để cung cấp mức dịch vụ tốt nhất có thể
Khi có nhiều mục tiêu cần tối ưu đồng thời như khả dụng của node và tổng thông lượng thì người ta xử lý ra sao, các topology khác nhau ảnh hưởng thế nào đến những điều trên, các ràng buộc khác tác động ra sao, và rộng hơn là cách tiếp cận những vấn đề này từ góc nhìn động lực học hệ thống
Tôi không tìm được nhiều tài liệu nói tốt về những vấn đề này. Nếu ai biết tài liệu nào thì rất mong được chỉ giúp
Lý thuyết hàng đợi khi mới học có vẻ nhỏ nhặt và dễ, nhưng vẫn còn rất nhiều bài toán mở
Ví dụ, ngay cả các chỉ số hiệu năng của hệ thống có thời gian đến ngẫu nhiên, thời gian phục vụ độc lập và k máy phục vụ (M/G/k) vẫn còn là bài toán mở
https://www.sciencedirect.com/science/article/pii/S0895717704905341
Trái với những gì người ta có thể nghĩ, lý thuyết hàng đợi thật sự có rất nhiều bài toán mở
Meta có vài video YouTube khá ổn giải thích các vấn đề liên quan đến việc vận hành số lượng GPU ở quy mô như vậy
Meta cũng công bố rất nhiều bài báo, blog và dự án mã nguồn mở trên trang kỹ thuật của họ [2]
James Hamilton của AWS cũng gần như năm nào cũng nói về hạ tầng. Các bài nói chuyện qua nhiều năm đều đáng xem [3]
[1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
[2] https://engineering.fb.com/category/data-center-engineering/
[3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
Về cơ bản, nó tối ưu ở cấp độ khối lượng công việc, ở đây là tác vụ deep learning, để cho phép co giãn kích thước tác vụ và preemption
[1] https://arxiv.org/pdf/2202.07848.pdf
Năm 2013 tôi học một môn về tính toán khoa học
Đó là môn mở chéo giữa khoa khoa học máy tính và toán ứng dụng. Vấn đề là lĩnh vực này nhìn chung quá rộng, nên rất nhiều chủ đề, bao gồm cả HPC và lập trình song song, chỉ được lướt qua rất hời hợt. Tôi không hối tiếc vì đã học, nhưng với ứng dụng mà tôi theo đuổi thì nó quá rộng
Tôi đã không theo dõi xem vài năm gần đây họ mở những môn gì, nhưng khi còn là nghiên cứu sinh, một môn chuyên biệt dành trọn cả học kỳ cho tính toán song song hẳn sẽ thực sự hữu ích. Đặc biệt là một lớp đào sâu vào các thuật toán và cấu trúc dữ liệu cụ thể cho tính toán song song và phân tán
Trong lớp tính toán khoa học mà tôi học, những nội dung này được đề cập quá sơ sài, cứ như thể ngay từ lần đầu thử là có thể biết chính xác cách song song hóa. Sau đó, giống như nhiều người trong HPC, qua nhiều năm tôi đã tự học và học từ đồng nghiệp rất nhiều, nhưng những cuốn sách như thế này sẽ cực kỳ quý giá nếu là một phần của môn học chuyên biệt kéo dài cả học kỳ
Thật ngạc nhiên khi tác giả đã tạo ra những cuốn sách toàn diện như vậy, bao gồm cả việc dạy C++ và các công cụ Unix, rồi còn chia sẻ miễn phí
Ngay cả khi không chuyên về HPC, mọi lập trình viên đều có điều để học từ đó
Có thêm một tài liệu liên quan là cuốn “Matters Computational” của Jorg Arndt và thư viện FXT: https://www.jjj.de/fxt/
Tôi tò mò về cách tiếp cận dạy C++ ở đây. Liệu có nhược điểm đặc biệt nào không?
Tôi đã dùng Python rất lâu, cũng có đụng đến C, C++, CUDA một chút và đang làm nghiên cứu ở cấp độ ứng dụng trong môi trường HPC (ML/DL). Tôi muốn nâng cao kỹ năng C++, và sau khi xem lướt qua 3 quyển thì thấy chúng rất hợp với trình độ của mình. Cách triển khai không quá chậm, và thay vì nhắm tới tính bao quát, nó dạy những thực hành tốt nhất mà tác giả đề xuất
Tôi có tìm các vòng lặp for dựa trên phạm vi, std::array, std::span và rất mừng vì chúng đều có mặt
Vì bộ sách này liên quan đến HPC, tôi muốn bổ sung thêm vài điểm. Sẽ tốt hơn nếu có giải thích về tối ưu hóa giá trị trả về, ngữ nghĩa di chuyển, và trong phần hàm đệ quy thì có thêm tối ưu hóa lời gọi đuôi
Là tài liệu cho người mới bắt đầu thì tôi rất khuyến nghị
Xin nói thêm rằng MPI chỉ là một trong những cách để làm HPC bằng Python
Nếu tôi nhớ không nhầm thì ipyparallel có thể chạy tác vụ MPI trên các tunnel do chính nó tạo ra
Sẽ cập nhật hơn nữa nếu có các chương về dask-scheduler, CuDF, CuGraph(NetworkX), DaskML, CuPy, dask-labextension
Vì Dask không tự xử lý việc lưu trữ dữ liệu thay bạn, nên trách nhiệm của người dùng là đảm bảo kho dữ liệu trước mỗi rào chắn không trở thành nút thắt hiệu năng
Tài liệu Dask về máy tính hiệu năng cao: https://docs.dask.org/en/stable/deploying-hpc.html
Nguồn số ngẫu nhiên cũng có thể là nút thắt. Không thể biết trước khi profiling tác vụ trên toàn bộ cụm
Về các công cụ truy vết dựa trên eBPF: https://news.ycombinator.com/item?id=31688180
Sau đó, cũng sẽ hay nếu có thêm các nội dung như GitOps và ChatOps, review mã và revision, hay quota tài nguyên dự án
Tôi từng được đề nghị chia sẻ vai trò trợ giảng cho một môn cao học về HPC cách đây 10 năm, nhưng đã từ chối
Sau khi xem lướt qua, tôi có thể thành thật nói rằng nếu khi đó đã có bộ sách này thì tôi đã nắm lấy cơ hội ấy
Cách định khung như một nghệ thuật gợi nhớ tới Knuth, góc nhìn ví nó với nghề mộc, và yêu cầu phải trở thành một người DevOps giỏi hơn cả người phụ trách DevOps của mình, khi kết hợp lại, đều rất thuyết phục
Xin chúc mừng thành tựu của tác giả. UT Austin dường như đã làm được trong khoa học máy tính điều tương tự như North Texas State đã làm trong âm nhạc
UT Austin là một cơ sở thật sự xuất sắc về HPC và phương pháp tính toán
Khi tôi gia nhập một công ty nhỏ hỗ trợ các kỹ sư HPC cho một hãng sản xuất ô tô lớn, tôi đã ngạc nhiên vì có quá nhiều script nội bộ được phát triển xoay quanh bộ lập lịch LSF
Mãi về sau, khi tự mày mò SLURM trên một mini-cluster cá nhân, tôi mới nhận ra rằng các phiên bản của phần mềm lập lịch nhìn chung không tương thích thay thế cho nhau. Tức là không thể dùng một phiên bản trong cụm và một phiên bản khác trên máy khách bên ngoài
Vì vậy cần có phần mềm keo để từ bên ngoài đẩy công việc vào bộ lập lịch rồi lấy kết quả về sau. Cá nhân tôi thấy điều này làm giảm giá trị của bộ lập lịch
Tôi đã nghĩ rằng sau khoảng 30 năm làm tính toán phân tán hiệu năng cao, các yêu cầu hẳn đã được hiểu rõ, và ít nhất giao thức trao đổi lệnh và dữ liệu cũng phải được cố định rồi. Nhưng có vẻ không phải vậy
Trước đây cũng từng có các nỗ lực tiêu chuẩn hóa API quản lý công việc cơ bản, và DRMAA là một ví dụ đáng chú ý. Tuy nhiên DRMAA v2 chỉ được Grid Engine triển khai, và thực chất nó giống một lớp trừu tượng mỏng trên API nội bộ hơn, nên không giành được hỗ trợ hạng nhất trong Slurm/PBS/LSF
Trong Slurm, REST API được xem là hướng đi về sau. Vấn đề xác thực được đẩy sang cho quản trị viên xử lý thông qua proxy Apache/NGINX theo bất kỳ cách nào họ muốn nối vào. API cơ bản cho việc gửi tác vụ và truy vấn trạng thái hiện đã đủ ổn định để gần như mọi ứng dụng khách ở bất kỳ phiên bản nào trong tương lai cũng có thể sử dụng được