Vì sao nên khuyến khích việc phân chia ở Julia?

Question

Có vẻ như viết mã devectorized được khuyến khích trong Julia. Thậm chí còn có package cố gắng thực hiện điều đó cho bạn.

Câu hỏi của tôi là lý do tại sao?

Trước hết, nói từ khía cạnh trải nghiệm người dùng, mã vectơ ngắn gọn hơn (ít mã hơn, ít khả năng xảy ra lỗi), rõ ràng hơn (do đó dễ debug hơn), cách viết mã tự nhiên hơn (ít nhất là cho một người đến từ nền tảng điện toán khoa học, người mà Julia cố gắng phục vụ). Có thể viết một cái gì đó như vector'vector hoặc vector'Matrix*vector là rất quan trọng, bởi vì nó tương ứng với biểu diễn toán học thực tế, và đây là cách mà những người tính toán khoa học nghĩ về nó trong đầu của họ (không phải trong vòng lồng nhau). Và tôi ghét thực tế rằng đây không phải là cách tốt nhất để viết điều này, và lặp lại nó thành vòng lặp sẽ nhanh hơn.

Hiện tại có vẻ như có xung đột giữa mục tiêu viết mã nhanh và mã ngắn gọn/rõ ràng.

Thứ hai, lý do kỹ thuật cho điều này là gì? Ok, tôi hiểu rằng mã vectơ được tạo ra thêm thời gian, v.v., nhưng các hàm vectơ (ví dụ, broadcast(), map(), v.v.) có khả năng đa luồng chúng, và tôi nghĩ rằng lợi ích của đa luồng có thể lớn hơn chi phí của thời gian và các nhược điểm khác của các hàm vectơ làm cho chúng nhanh hơn các vòng lặp thông thường.

Thực hiện các chức năng vectơ hiện tại trong Julia có thực hiện đa luồng ngầm dưới mui xe không?

Nếu không, liệu có phải là công việc/kế hoạch để thêm đồng thời tiềm ẩn vào các hàm được vector hóa và để làm cho chúng nhanh hơn các vòng lặp không?

Answer 1

Để đọc dễ dàng, tôi quyết định chuyển marathon bình luận của mình ở trên thành câu trả lời.

core development statement đằng sau Julia là "chúng tôi tham lam". Các nhà phát triển cốt lõi muốn nó làm mọi thứ và làm điều đó nhanh chóng. Đặc biệt, lưu ý rằng ngôn ngữ được cho là để giải quyết "vấn đề hai ngôn ngữ", và ở giai đoạn này, có vẻ như nó sẽ thực hiện điều này bằng cách truy cập thời gian v1.0.

Trong ngữ cảnh câu hỏi của bạn, điều này có nghĩa là mọi thứ bạn đang hỏi đều là một phần của Julia hoặc được lên kế hoạch cho v1.0.

Cụ thể, điều này có nghĩa là nếu vấn đề lập trình của bạn tự vay mượn mã vectơ, thì hãy viết mã vectơ. Nếu nó là tự nhiên hơn để sử dụng vòng, sử dụng vòng lặp.

Vào thời điểm v1.0 truy cập, hầu hết mã được vector hóa phải nhanh hoặc nhanh hơn mã tương đương trong Matlab. Trong nhiều trường hợp, mục tiêu phát triển này đã đạt được, vì nhiều hoạt động vector/ma trận trong Julia được gửi đến các trình tự BLAS thích hợp bởi trình biên dịch.

Về đa luồng, native đa luồng hiện đang được triển khai cho Julia và tôi tin rằng một tập hợp thử nghiệm các thường trình đã có sẵn trên nhánh chính. Trang vấn đề có liên quan là here. Ngụ ý đa luồng cho một số hoạt động vector/ma trận đã có sẵn trong lý thuyết có sẵn trong Julia, vì Julia gọi BLAS. Tôi không chắc chắn nếu nó được bật theo mặc định.Tuy nhiên, hãy chú ý rằng, nhiều hoạt động được vector hóa sẽ vẫn (hiện tại) nhanh hơn nhiều trong MATLAB, vì MATLAB đã viết các thư viện C đa luồng chuyên dụng trong nhiều năm và sau đó gọi chúng dưới mui xe. Khi Julia có đa luồng gốc, tôi hy vọng Julia sẽ vượt qua MATLAB, kể từ thời điểm đó, toàn bộ cộng đồng dev có thể tiêu diệt các gói Julia chuẩn và nâng cấp chúng để tận dụng lợi thế của đa luồng gốc ở bất cứ nơi nào có thể.

Ngược lại, MATLAB không có đa luồng gốc, do đó bạn dựa vào Mathworks để cung cấp các thường trình đa luồng chuyên biệt dưới dạng thư viện C cơ bản.

Answer 2

Bạn có thể và nên viết vector'*matrix*vector (hoặc có lẽ dot(vector, matrix*vector) nếu bạn thích đầu ra vô hướng). Đối với những thứ như phép nhân ma trận, bạn nên sử dụng ký hiệu vector hóa tốt hơn, vì nó gọi các thư viện BLAS cơ bản được tối ưu hóa nhiều hơn mã được tạo ra bởi sự kết hợp ngôn ngữ/trình biên dịch cơ bản.

Ở những nơi khác, như bạn nói, bạn có thể được hưởng lợi từ devectorization bằng cách tránh trung gian tạm thời: ví dụ, nếu x là một vector, khái niệm

y = exp(x).*x + 5 

tạo 3 vectơ tạm thời: một cho a = exp(x), một cho b = a.*x và một cho y = b + 5. Ngược lại,

y = [exp(z)*z+5 for z in x] 

không tạo trung gian tạm thời. Vì các vòng lặp và sự hiểu biết trong julia rất nhanh, nên không có bất lợi khi viết phiên bản được phân tách, và thực tế nó sẽ hoạt động tốt hơn một chút (đặc biệt là các chú thích hiệu suất như @simd, nếu thích hợp).

Sự xuất hiện của chủ đề có thể thay đổi mọi thứ (làm cho véc tơ exp nhanh hơn "ngây thơ" exp), nhưng nói chung tôi sẽ nói bạn nên coi vấn đề này là vấn đề "trực giao": julia có thể làm cho việc đa luồng trở nên dễ dàng sử dụng bản thân bạn có thể viết các hoạt động bằng cách sử dụng nhiều luồng, và do đó thói quen "thư viện" được vector hóa vẫn không có lợi thế so với mã bạn có thể tự viết. Nói cách khác, bạn có thể sử dụng nhiều luồng nhưng vẫn viết mã được phân tách để tránh những thời gian đó.

Về lâu dài, "sufficiently smart compiler" có thể tránh được thời gian bằng cách tự động phân chia một số hoạt động này, nhưng đây là một con đường khó hơn nhiều, với bẫy tiềm năng cho người không thận trọng.

Tuyên bố của bạn rằng "mã vectơ luôn ngắn gọn hơn và dễ hiểu hơn", tuy nhiên, không đúng: nhiều lần khi viết mã Matlab, bạn phải đi đến cực đoan để tìm ra cách viết vector thực sự là các hoạt động đơn giản khi nghĩ về vòng lặp. Bạn có thể tìm kiếm danh sách gửi thư cho vô số ví dụ; cái mà tôi nhớ trên SO là How to find connected components in a matrix using Julia.