Song song tính toán phát triển phần mềm ngôn ngữ?

18

Tôi muốn phát triển một phần mềm tính toán khoa học song song từ đầu. Tôi muốn một số suy nghĩ về ngôn ngữ để bắt đầu. Chương trình bao gồm đọc / ghi dữ liệu vào các tệp txt và thực hiện các tính toán nặng song song, với nhiều yếu tố LU và sử dụng các bộ giải tuyến tính thưa thớt. Các giải pháp ứng viên mà tôi đã nghĩ là Fortran 2003/2008 với OpenMP hoặc co-Array, C ++ với openmp cilk + hoặc TBB, python. Bất kỳ khác, tài liệu, đề nghị đều được chào đón! Tôi biết rất rõ C, Fortran và Java (theo thứ tự đó). Tôi đã thực hiện một số kịch bản trong python nhưng những thứ cơ bản.

Tôi biết fortran rất nhanh, nhưng, khó duy trì và song song. C ++ được cho là chậm trừ khi bạn sử dụng các thư viện bên ngoài, v.v. Tôi thích Python, nhưng có thực tế không khi viết một quy mô đầy đủ, phần mềm cấp công nghiệp?

Phần mềm cần có khả năng xử lý lượng lớn dữ liệu và có hiệu quả với các tính toán khoa học. Hiệu suất là điều cốt yếu.

Đối với nền, tôi đã có một phần mềm làm việc được viết bằng Fortran. Nhiều người đã tham gia phát triển trong nhiều năm và mã này thực sự bẩn. Duy trì và song song mã đã chứng minh một cơn ác mộng và tôi đang nghĩ đến các giải pháp thay thế.

Petros

— điện
nguồn

5

Là một won C ++, tôi sẽ không gọi Fortran để duy trì. Khả năng bảo trì được gắn với các thực hành tốt cho hầu hết các phần, không phải lựa chọn ngôn ngữ. Sự chậm chạp của C ++ là quá bán. Ngoài ra, tôi khuyên bạn nên tăng bài đăng này để mô tả kích thước dữ liệu và yêu cầu thời gian quay vòng của bạn. Tôi đã thấy "lớn" thay đổi theo 9 hoặc 10 bậc độ lớn tùy thuộc vào người tôi đang nói chuyện.

— Bill Barth

@BillBarth Vấn đề với mã Fortran hiện tại là ba người đã tham gia sử dụng các thực tiễn khác nhau. Tôi đến từ một nền C, một anh chàng từ nền F77 và một anh chàng khác từ Matlab. Dữ liệu không được phân bổ và có kích thước cho hệ thống kích thước lớn nhất (gần đây tôi đã tham gia). Mã này có thể mô phỏng hệ thống với 72000 vi phân và 74000 phương trình đại số trong khoảng thời gian 240 giây trong 350 giây (thời gian trôi qua). Tôi đã giảm xuống còn 170 giây bằng cách sử dụng OpenMP để song song hóa. Bây giờ tôi cần chạy song song một số trường hợp (để quét để kiểm tra bảo mật).

— Electrique

4

@BillBarth quá khiêm tốn trong việc bán các kỹ năng C ++ của mình, nhưng anh ấy cũng quá hào phóng khi tuyên bố rằng "sự chậm chạp của C ++ là quá bán". Đã có một số luồng C ++ so với Fortran trong scicomp.stackexchange.com đã thảo luận về câu hỏi này và kết luận chung là đơn giản là nó không đúng hơn C ++ chậm hơn Fortran trong hầu hết các trường hợp. Cá nhân tôi nghĩ rằng ngày nay nó có thể được coi là một huyền thoại đô thị. Có gì là rất nhiều đúng là nếu bạn đưa vào bảo trì tài khoản của mã này, sau đó Fortran không tỏ ra rất hữu tốt ngày hôm nay.

— Wolfgang Bangerth

2

@BillBarth và những người khác, nếu bạn muốn tiếp tục thảo luận về giá trị chung của Fortran, C ++ và các ngôn ngữ khác, vui lòng mang nó đến phòng trò chuyện scicomp và @ bất kỳ ai bạn muốn giải quyết cụ thể.

— Aron Ahmadia

1

@AronAhmadia: ah, thôi nào, tôi có rất nhiều điều muốn nói với Jed ;-) (Jed: một lúc khác. Trong trường hợp của chúng tôi, không có STL cho ma trận thưa thớt, nhưng rất nhiều trong cấu trúc dữ liệu lưới thích ứng.)

— Wolfgang Bangerth

19

Hãy để tôi thử và phá vỡ các yêu cầu của bạn:

Bảo trì
Đọc / ghi dữ liệu văn bản
Giao diện / khả năng mạnh mẽ cho các yếu tố LU
Giải quyết tuyến tính thưa thớt
Hiệu suất và khả năng mở rộng dữ liệu lớn

Từ danh sách này, tôi sẽ xem xét các ngôn ngữ sau:

C, C ++, Fortran, Python, MATLAB, Java

Julia là một ngôn ngữ mới đầy hứa hẹn, nhưng cộng đồng vẫn đang hình thành xung quanh nó và nó chưa được triển khai trong bất kỳ mã mới nào.

Đọc / ghi dữ liệu văn bản

Điều này là dễ dàng để có được ngay trong bất kỳ ngôn ngữ lập trình. Hãy chắc chắn rằng bạn đang đệm một cách thích hợp và kết hợp lại quyền truy cập I / O của bạn và bạn sẽ có được hiệu suất tốt từ bất kỳ ngôn ngữ nào bạn nên xem xét. Tránh các đối tượng truyền phát trong C ++ trừ khi bạn biết cách sử dụng chúng một cách hiệu quả.

Giao diện / khả năng mạnh mẽ cho các yếu tố LU

Nếu bạn đang thực hiện các yếu tố LU dày đặc, bạn sẽ muốn sử dụng LAPACK hoặc ScaLAPACK / Elemental cho chức năng song song. LAPACK và ScaLAPACK được viết bằng Fortran, Elemental được viết bằng C ++. Tất cả ba thư viện là hiệu suất và được hỗ trợ tốt và tài liệu. Bạn có thể giao tiếp với chúng từ bất kỳ ngôn ngữ nào bạn nên xem xét.

Giải quyết tuyến tính thưa thớt

Các bộ giải tuyến tính thưa thớt có sẵn miễn phí hàng đầu hầu như đều có sẵn thông qua PETSc , được viết bằng C, được ghi chép lại và hỗ trợ tốt. Bạn có thể giao tiếp với PETSc từ bất kỳ ngôn ngữ nào bạn nên xem xét.

Hiệu suất và khả năng mở rộng dữ liệu lớn

Các mô hình lập trình song song duy nhất bạn đề cập là dựa trên bộ nhớ được chia sẻ, điều đó có nghĩa là bạn không xem xét phương pháp tính toán bộ nhớ phân tán (dựa trên thông điệp) dựa trên MPI. Theo kinh nghiệm của tôi, việc viết mã có tỷ lệ tốt hơn rất nhiều so với hàng chục lõi sử dụng giải pháp bộ nhớ phân tán sẽ dễ dàng hơn nhiều. Hầu như tất cả các "cụm" Đại học đều dựa trên MPI ngày nay, các máy có bộ nhớ chia sẻ lớn rất đắt tiền và tương ứng là rất hiếm. Bạn nên xem xét MPI cho cách tiếp cận của bạn, nhưng lời khuyên của tôi sẽ được áp dụng bất kể mô hình lập trình bạn chọn.

Liên quan đến hiệu suất trên nút, nếu bạn đang tự viết các thói quen số, thì dễ nhất để có được hiệu suất nối tiếp tốt trong Fortran. Nếu bạn có một chút kinh nghiệm về C, C ++ hoặc Python, bạn có thể có hiệu suất rất tương đương (C và C ++ đã chết ngay cả với Fortran, Python và MATLAB chỉ mất khoảng 25% thời gian mà không cần nhiều nỗ lực). MATLAB thực hiện điều này thông qua trình biên dịch JIT và biểu thức đại số tuyến tính rất tốt. Bạn có thể sẽ cần phải sử dụng Cython, numpy, numexpr hoặc nhúng các hạt nhân số để có được hiệu năng được yêu cầu từ Python. Tôi không thể nhận xét về hiệu suất của Java, vì tôi không biết rõ ngôn ngữ này, nhưng tôi nghi ngờ nó không xa Python nếu được viết bởi một chuyên gia.

Một lưu ý về giao diện

Tôi hy vọng tôi đã thuyết phục bạn rằng bạn sẽ có thể làm mọi thứ bạn muốn bằng bất kỳ ngôn ngữ lập trình nào bạn đang xem xét. Nếu bạn đang sử dụng Java, các giao diện C sẽ có một chút thách thức. Python có hỗ trợ giao diện C và Fortran tuyệt vời thông qua ctypes, Cython và f2py. LAPACK đã được bọc và có sẵn thông qua scipy. MATLAB có tất cả các chức năng bạn cần trong các thư viện riêng, nhưng không dễ mở rộng hoặc đặc biệt dễ chạy trên các cụm. Java có thể hỗ trợ các giao diện C và Fortran với JNI , nhưng không được tìm thấy phổ biến trên các cụm và trong phần mềm song song cho tính toán khoa học.

Bảo trì

Rất nhiều điều này sẽ đi vào hương vị cá nhân, nhưng sự đồng thuận chung về khả năng bảo trì là bạn muốn giảm thiểu số lượng dòng mã trong phần mềm của mình, viết mã mô-đun với giao diện được xác định rõ và cho phần mềm tính toán, cung cấp kiểm tra xác minh tính đúng đắn và chức năng của việc thực hiện.

sự giới thiệu

Cá nhân tôi đã có rất nhiều may mắn với Python và tôi giới thiệu nó cho nhiều dự án tính toán. Tôi nghĩ bạn nên mạnh mẽ xem xét nó cho dự án của bạn. Python và MATLAB có lẽ là ngôn ngữ biểu cảm nhất cho tính toán khoa học. Bạn có thể dễ dàng giao tiếp Python với bất kỳ ngôn ngữ lập trình nào khác, bạn có thể sử dụng f2py để bao bọc triển khai Fortran hiện tại của bạn và viết lại từng phần bất kỳ phần nào bạn muốn trong Python trong khi xác minh rằng bạn đang duy trì chức năng. Tại thời điểm này, tôi sẽ đề xuất kết hợp triển khai Python 2.7 chính thức với scipy . Bạn có thể bắt đầu rất dễ dàng với ngăn xếp này từ Phân phối Python có sẵn miễn phí .

Bạn cũng có thể làm hầu hết điều này trong C, C ++ hoặc Fortran. C và C ++ là những ngôn ngữ rất hấp dẫn đối với các nhà phát triển chuyên nghiệp có nhiều kinh nghiệm, nhưng thường xuyên vấp phải các nhà phát triển mới và theo nghĩa này có lẽ không phải là một ý tưởng tuyệt vời cho một mã học thuật hơn. Fortran và MATLAB là phổ biến trong tính toán học thuật, nhưng yếu về cấu trúc dữ liệu nâng cao và tính biểu cảm mà Python cung cấp (ví dụ, nghĩ về một đối tượng dict Python).

Câu hỏi liên quan:

Đề xuất cho một thư viện ma trận Java nhanh, có thể sử dụng?

— Aron Ahmadia
nguồn

1

Một tài liệu rất tốt, tất cả các câu trả lời bao gồm. Dưới Fortran tôi sử dụng rất nhiều Lapack. Tôi sẽ xem xét python và cố gắng bọc mã Fortran của tôi để bắt đầu và từ từ chuyển sang Python. Điều duy nhất làm tôi sợ là 25% thời gian tôi có thể có. Nhưng nếu nó đi kèm với lợi ích của mã biểu cảm hơn và xử lý tính toán song song tốt hơn, tôi sẽ sử dụng nó. Tôi chỉ đề cập đến bộ nhớ dùng chung vì phần mềm hiện đang chạy theo cách tương tác (thực hiện thay đổi dữ liệu và chạy lại) trên các máy tính bộ nhớ dùng chung 2,4,8,24,48 lõi của các nhà nghiên cứu trong Uni dưới Windows và Linux.

— Electrique

3

Tôi không biết làm thế nào bạn có thể đưa ra yêu cầu 25% phí cho các hạt nhân số được viết bằng Python. Các hạt nhân Python thuần túy thường chậm hơn 100 lần so với C. Numpy và numexpr có thể thực hiện công việc tốt với một số biểu thức nhất định, nhưng điều đó hầu như không viết các hạt nhân số mới trong Python. Cython có thể thực hiện một số thứ nhanh chóng, nhưng thường không nằm trong 25% C. Python là ngôn ngữ "keo" tốt, nhưng tôi nghĩ Aron đang giám sát nó như một giải pháp cho mục đích chung cho các nhiệm vụ nhạy cảm với hiệu suất.

— Jed Brown

I / O là điểm yếu của Fortran, bởi vì Fortran đòi hỏi rất nhiều cấu trúc trong I / O. Trải nghiệm cũ của tôi từ việc nói chuyện với các đồng nghiệp trong phòng thí nghiệm của tôi, người làm việc với Cython phù hợp với những gì Jed nói về Cython; ít nhất một trong số họ viết C điều chỉnh bằng tay để thay thế Cython cho các nhiệm vụ đòi hỏi hiệu năng cao, và sau đó tôi tin rằng hiệu suất của Python khi gọi mã C kết quả gần với yêu cầu của Aron. Ngoài ra, nếu bạn sẽ đề cập đến PETSc và Python, bạn cũng có thể đề cập đến petc4py. Lần cuối cùng tôi nhìn thấy (đây là một vài năm trước), không có giao diện MPI tốt cho Java. Điều đó đã thay đổi?

— Geoff Oxberry

@GeoffOxberry: Các ràng buộc MPI Java tồn tại nhưng chưa được cập nhật trong gần một thập kỷ. Tôi xem xét tình trạng của họ đáng ngờ. Fortran có nhiều tùy chọn I / O có thể được thực hiện để đi rất nhanh. Tôi khuyên bạn nên khám phá Parallel HDF5 (và HDF5, nói chung). Nếu I / O thực sự chiếm ưu thế (hơn 50% thời gian chạy), các biện pháp nghiêm trọng hơn có thể theo thứ tự, nhưng nếu không, chất lượng và tính di động của giao diện giống HDF có lẽ đáng giá.

— Bill Barth

@BillBarth: Tôi sẽ phải kiểm tra xem. Nhận xét của tôi về Fortran I / O xuất phát từ quan điểm của một ai đó đã từng khuyên tôi nên viết một trình phân tích cú pháp tệp đầu vào trong Fortran. Có thể, bằng cách thực thi rất nhiều cấu trúc, nhưng tôi chưa thấy thư viện trình phân tích cú pháp regex hoặc thư viện phân tích cú pháp XML dễ sử dụng và rộng rãi trong Fortran (để đưa ra một số ví dụ). Có lý do chính đáng cho điều đó: chúng tôi là những người duy nhất sử dụng Fortran nữa. Có lẽ chúng tôi đang nghĩ về các trường hợp sử dụng khác nhau.

— Geoff Oxberry

2

Ngoài câu trả lời rất toàn diện của Aron, tôi sẽ xem xét các chủ đề khác nhau trên scicomp.stackexchange liên quan đến câu hỏi nên sử dụng ngôn ngữ lập trình nào - cả về tốc độ của các chương trình cũng như câu hỏi về mức độ dễ hay khó đó là viết và bảo trì phần mềm bằng các ngôn ngữ này.

Điều đó nói rằng, ngoài những gì đã được viết ở đó, hãy để tôi thực hiện một vài quan sát:

(i) Bạn bao gồm Fortran đồng mảng trong danh sách của bạn. Theo hiểu biết của tôi, số lượng trình biên dịch thực sự hỗ trợ nó là rất nhỏ - và trên thực tế, con số của tôi là bằng không. Trình biên dịch Fortran có sẵn rộng rãi nhất là GNU gfortran và trong khi các nguồn phát triển hiện tại phân tích một tập hợp con của các mảng, tôi tin rằng nó không thực sự hỗ trợ bất kỳ phần mềm nào (nghĩa là nó chấp nhận cú pháp nhưng không thực hiện được ngữ nghĩa nào) . Tất nhiên đây là một quan sát chung về các tiêu chuẩn Fortran mới hơn: độ trễ mà các trình biên dịch thực sự hỗ trợ các tiêu chuẩn mới được đo lường trong vài năm - các trình biên dịch chỉ thực hiện đầy đủ Fortran 2003 trong vài năm qua và chỉ hỗ trợ một phần cho Fortran 2008. Điều này không nên ngăn bạn sử dụng bất kỳ ứng dụng nào nếu bạn có trình biên dịch tình cờ hỗ trợ những gì bạn sử dụng,

(ii) Điều tương tự cũng đúng với C ++ / Cilk +: Có, Intel đang phát triển điều này trên một nhánh của GCC nhưng nó không có sẵn trong bất kỳ bản phát hành GCC nào và có thể sẽ không tồn tại trong một thời gian. Bạn có thể hy vọng sẽ mất thêm 2-3 năm nữa cho đến khi bạn tìm thấy Cilk + với các phiên bản GCC được cài đặt trên các máy linux thông thường.

(iii) C ++ / TBB là một câu chuyện khác: TBB đã xuất hiện được một thời gian, có giao diện rất ổn định và có thể tương thích với hầu hết mọi trình biên dịch C ++ đã tồn tại trong nhiều năm qua (trên linux cũng như trên windows) . Chúng tôi đã sử dụng nó trong deal.II trong vài năm với kết quả tốt. Ngoài ra còn có một cuốn sách rất tốt về nó.

(iv) Tôi có ý kiến rất riêng về OpenMP, cụ thể đó là giải pháp tìm kiếm vấn đề. Nó hoạt động tốt để song song các vòng lặp bên trong, đây là điều có thể quan tâm nếu bạn có cấu trúc dữ liệu rất đều đặn. Nhưng đó hiếm khi là những gì bạn muốn làm nếu bạn cần song song một cái gì đó - bởi vì những gì bạn thực sự muốn làm là song song các vòng lặp bên ngoài . Và vì thế, các giải pháp như TBB là giải pháp tốt hơn nhiều vì chúng sử dụng các cơ chế của ngôn ngữ lập trình thay vì cố gắng mô tả những gì xảy ra bên ngoài ngôn ngữ (thông qua #pragmas) và theo cách mà bạn không có quyền truy cập vào xử lý luồng , chỉ báo trạng thái kết quả, vv, từ trong chương trình của bạn.

(v) Nếu bạn đang thử nghiệm, bạn cũng có thể xem các ngôn ngữ lập trình mới được thiết kế để lập trình song song và đặc biệt, cho các tác vụ như các ngôn ngữ bạn mô tả. Về cơ bản, có hai cái tôi muốn xem: X10 và Nhà nguyện . Tôi đã thấy các hướng dẫn tốt đẹp về Nhà nguyện, và nó có vẻ được thiết kế tốt, mặc dù cả hai ngày nay đều là giải pháp cơ bản.

— Wolfgang Bangerth
nguồn

Đối với bản ghi, Intel tuyên bố có một Fortran đồng bộ (bộ nhớ phân tán) song song được tích hợp vào trình biên dịch hiện tại của họ. Chúng tôi đang xem xét nó tại TACC, nhưng tôi chưa có gì để báo cáo. Cray cũng có một triển khai trong trình biên dịch của họ, nhưng điều này chỉ có sẵn trên một số lượng nhỏ máy trên toàn thế giới. Tôi không nghĩ có ai thực hiện đầy đủ tiêu chuẩn Fortran 2008 đối với các mảng đồng, tuy nhiên, có nhiều hơn sự hỗ trợ mới trong một vài trình biên dịch. Cilk +, tất nhiên, cũng có sẵn với các trình biên dịch Intel, nhưng việc phụ thuộc có lẽ vẫn chưa khôn ngoan.

— Bill Barth

Tiêu chuẩn Fortran 2008 không được phê duyệt cho đến cuối năm 2010, vì vậy sẽ mất vài năm trước khi CAF được phổ biến rộng rãi. G95 thực sự đã có một triển khai (không miễn phí) nhưng không được phát triển nữa (nhà phát triển đã tham gia PathScale).

— stali

Hầu hết g95 cuối cùng đã kết thúc ở gfortran nhưng có thể CAF không phải là một phần của điều đó.

— Wolfgang Bangerth

Tôi tin rằng trình biên dịch Intel cung cấp hỗ trợ tốt cho đồng mảng. Họ đã xây dựng nó bằng mpiexec. Nó sẽ không phải là lựa chọn đầu tiên của tôi. Điều tuyệt vời là cùng một triển khai có thể chạy trên bộ nhớ được chia sẻ và phân phối (tôi đã chạy một vài thử nghiệm). Với bộ xử lý bộ nhớ chia sẻ opteron đạt tới 60 nhân với mức giá thực sự hợp lý, tôi muốn xem các tùy chọn bộ nhớ chia sẻ của mình trước tiên.

— Electrique

2

Nói chung, nếu bạn thực sự nghiêm túc với dự án phần mềm này, tôi sẽ đề nghị viết lại hoàn toàn bằng bất kỳ ngôn ngữ nào mà bản thân bạn cảm thấy thoải mái nhất. Có vẻ như bạn sẽ làm việc một mình, và do đó bạn sẽ có được kết quả tốt nhất trong ngôn ngữ mà bạn cảm thấy thoải mái nhất ở nhà.

Cụ thể hơn, mặc dù, liên quan đến sự song song, tôi sẽ khuyến khích bạn cố gắng suy nghĩ một chút bên ngoài hộp. OpenMP có những điểm mạnh của nó, nhưng bị mắc kẹt trong một suy nghĩ về việc lấy mã liên tiếp và tát song song ở đây và đó. Tương tự, về bản chất, đối với Intels TBB.

Cilk chắc chắn là một bước đi đúng hướng, tức là nó buộc bạn phải suy nghĩ lại vấn đề / giải pháp của mình trong một thiết lập song song vốn có. Tuy nhiên, điều tôi không thích là nó là một ngôn ngữ khác . Ngoài ra, vì nó chỉ có thể suy ra đại khái mối quan hệ giữa các tác vụ song song, bộ lập lịch có thể khá bảo thủ và có thể không mở rộng tốt cho một số vấn đề nhất định.

Tuy nhiên, tin tốt là, một lần nữa, nếu bạn nghiêm túc với việc triển khai của mình, bạn có thể làm những gì Cilk làm, ví dụ viết lại vấn đề của bạn dưới dạng một tập hợp các nhiệm vụ phụ thuộc lẫn nhau và phân phối chúng qua một số bộ xử lý / các lõi, tất cả đều tự mình sử dụng pthread hoặc sử dụng sai OpenMP để sinh ra các quy trình. Một ví dụ điển hình về cách thực hiện điều này là bộ lập lịch QUARK được sử dụng trong thư viện PLASMA . Một so sánh tốt về hiệu suất của nó so với Cilk được đưa ra ở đây .

— Pedro
nguồn

Tôi sẽ xem xét các liên kết được đề xuất. Các giấy so sánh là rất tốt đẹp! Cảm ơn! Tôi đã suy nghĩ về pthreads nhưng tôi muốn chương trình đa nền tảng. Từ những gì tôi biết pthreads có vấn đề dưới cửa sổ (sai?).

— Electrique

@ p3tris: "p" trong pthreads là dành cho POSIX, vì vậy nó có khả năng di động như nó có thể. Có một số triển khai Windows tuân thủ như pthreads-win32hoặc trong cygwindự án.

— Pedro

Dựa trên stackoverflow.com/q/2797690/801468 tôi thấy có rất nhiều thứ cần thiết để sắp xếp để sử dụng nó. Cho rằng tôi không phải là lập trình viên, tôi thích gắn bó với thứ gì đó được thử nghiệm nhiều hơn.

— Electrique

2

Có rất ít thảo luận về coarray fortran trong các ý kiến trên. Tại thời điểm này, và theo hiểu biết hạn chế của tôi, hỗ trợ coarray trong trình biên dịch đại khái như sau:

Cray có một trình biên dịch hỗ trợ ít nhất các tính năng coarray cơ bản. Tôi đã sử dụng nó để viết mã được dự định là "giáo dục", nhưng tôi nói rằng bạn có thể viết mã thực sự trong coarray fortran. Cú pháp và khái niệm hầu hết đơn giản hơn nhiều so với MPI, nhưng như mọi khi, có rất nhiều bẫy và các bẫy khác với MPI.
Intel fortran có hỗ trợ coarray được xây dựng trên thư viện MPI của họ. Giả sử điều này giới hạn hiệu suất cao nhất về mặt lý thuyết của họ, nhưng tôi chưa thấy bất kỳ số liệu nào.
Gfortran hỗ trợ các cuộc tranh luận, nhưng chỉ cho một hình ảnh duy nhất (hoặc xếp hạng đơn, trong MPI speak). Do đó, không có song song thực sự có sẵn cho đến khi gfortran 4.8 hoặc 4.9 ra ngoài.

Nói chung, tôi sẽ cẩn thận nếu bắt đầu mã dựa trên coarray. Cú pháp đơn giản và thuận tiện hơn nhiều so với Fortran / C / C ++ với MPI, nhưng sau đó, nó không đầy đủ tính năng. Ví dụ, MPI hỗ trợ rất nhiều hoạt động giảm, vv có thể rất thuận tiện cho bạn. Nó thực sự sẽ phụ thuộc vào nhu cầu giao tiếp của bạn. Nếu bạn muốn có một ví dụ, hãy cho tôi biết và tôi có thể cung cấp cho bạn một vài ví dụ, nếu tôi có thể đào các tập tin.

— pletnes
nguồn

Vâng, thêm thông tin về sự sẵn sàng của coarray Fortran cho loại vấn đề này chắc chắn sẽ hữu ích. Chào mừng đến với scicomp!

— Aron Ahmadia

1

Hãy xem Spark đó là một khung phân tán cho các tính toán trong bộ nhớ, tận dụng lợi thế của lập trình chức năng. Cấu trúc của một chương trình trong Spark rất khác so với MPI, về cơ bản, bạn viết một mã giống như cho một máy tính, được tự động phân phối dưới dạng các hàm cho dữ liệu nằm trong bộ nhớ. Nó hỗ trợ Scala, Java và Python.

Hồi quy logistic (scala):

//load data to distributed memory
val points = spark.textFile(...).map(parsePoint).cache()
var w = Vector.random(D) // current separating plane
for (i <- 1 to ITERATIONS) {
  val gradient = points.map(p =>
    (1 / (1 + exp(-p.y*(w dot p.x))) - 1) * p.y * p.x
  ).reduce(_ + _)
  w -= gradient
}
println("Final separating plane: " + w)

Có một phần mở rộng được gọi là MLib (thư viện Machine Learning) sử dụng thư viện Fortran cho một số tính toán cấp thấp (đối với Python tôi đoán numpy được sử dụng). Vì vậy, ý tưởng rất đơn giản, tập trung vào thuật toán của bạn và để tối ưu hóa ở mức thấp hơn (thứ tự xử lý, phân phối dữ liệu, v.v.).

— Lăng mộ
nguồn