Làm thế nào một số lượng lớn mã cơ sở giòn giã dựa trên Fortran có thể được hiện đại hóa?

Một người bạn trong học viện đã hỏi tôi lời khuyên (Tôi là nhà phát triển ứng dụng kinh doanh C #).

Anh ta có một cơ sở mã di sản mà anh ta đã viết ở Fortran trong lĩnh vực hình ảnh y tế. Nó thực hiện một số lượng lớn crunching số bằng cách sử dụng vectơ. Anh ta sử dụng một cụm (30 lõi) và hiện đã tiến tới một máy trạm duy nhất có 500 GPUS trong đó.

Tuy nhiên, đi đâu tiếp theo với codebase vậy:

• Những người khác có thể duy trì nó trong chu kỳ 10 năm tới
• Nhanh hơn trong việc tinh chỉnh phần mềm
• Có thể chạy trên các cơ sở hạ tầng khác nhau mà không cần biên dịch lại

Sau một số nghiên cứu từ tôi (đây là một lĩnh vực siêu thú vị), một số tùy chọn là:

• Sử dụng Python và CUDA từ Nvidia
• Viết lại bằng một ngôn ngữ chức năng. Ví dụ: F # hoặc Haskell
• Dựa trên đám mây và sử dụng một cái gì đó như Hadoop và Java
• Học C

Kinh nghiệm của bạn với điều này là gì? Bạn tôi nên nhìn vào cái gì để hiện đại hóa cơ sở mã của mình?

CẬP NHẬT: Cảm ơn @Mark và tất cả những người đã trả lời. Lý do bạn tôi hỏi câu hỏi này là vì đây là thời điểm hoàn hảo trong vòng đời dự án để thực hiện đánh giá. Đưa các trợ lý nghiên cứu đến tốc độ trong Fortran mất nhiều thời gian (tôi thích C #, và đặc biệt là công cụ và không thể tưởng tượng được việc quay lại các ngôn ngữ cũ hơn !!)

Tôi thích đề nghị giữ số nguyên chất giòn trong Fortran, nhưng gói nó trong một cái gì đó mới hơn. Có lẽ Python dường như đang trở thành một thành trì trong giới học thuật như là một ngôn ngữ lập trình có mục đích chung khá dễ tiếp thu.

Xem hình ảnh y tế và một anh chàng đã viết một trình bao bọc Fortran cho CUDA, tôi có thể xuất bản hợp pháp các trình bao bọc Fortran 90 của mình lên thư viện CUFFT của Nvidias (từ SDK CUDA) không? .

Các yêu cầu bạn đã đặt thực sự đặt Fortran lên đầu danh sách, cho các vấn đề như thế này:

a) crunching
b) paralellable
c) nó đã và vẫn là ngôn ngữ thực tế được dạy bên ngoài các nghiên cứu cs (cho các kỹ sư không phải là lập trình viên chuyên nghiệp).
d) có sự hậu thuẫn đáng kinh ngạc (!), các nhà biên dịch cấp độ ngành công nghiệp, không có nhà cung cấp nào có dấu hiệu từ bỏ chi nhánh đó ít nhất. Một trong những đại diện của Intel cách đây không lâu đã tiết lộ rằng doanh số bán các sản phẩm Fortran của họ cao hơn bất kỳ công cụ phát triển nào khác.

Nó cũng là một ngôn ngữ rất dễ để chọn. Tôi không đồng ý rằng cần có thời gian để giúp các trợ lý nghiên cứu tăng tốc. Sách giáo khoa đầu tiên của tôi về nó không có nhiều hơn, ồ tôi không biết, 30 trang (?) Của văn bản in thưa thớt. Đó là một ngôn ngữ mà sau khi học 10 từ khóa, người ta có thể viết các chương trình cỡ trung bình. Tôi dám nói rằng 30 trang được viết bằng văn bản Word mặc định sẽ tạo ra một "hướng dẫn Fortran" toàn diện hơn cho hầu hết người dùng.

Nếu bạn quan tâm đến CUDA, bạn có thể muốn kiểm tra trình biên dịch của Tập đoàn Portland , nơi hỗ trợ nó . Tôi không quen thuộc với các chi tiết tốt hơn, nhưng mọi người thường nói về nó với lời khen ngợi.

Ngoài ra, đối với các chương trình song song, bạn có sẵn OpenMP, MPI và giờ là các mảng đồng sắp tới (và được chờ đợi từ lâu), trình biên dịch của Intel gần đây đã triển khai. Để không lãng phí từ ngữ, Fortran có một "thư viện" rất tốt để song song hóa các chương trình.

Các thư viện số tiêu chuẩn công nghiệp được phát triển cho nó, các ngôn ngữ khác theo sau ít nhiều trong danh mục chức năng / thói quen.

Tuy nhiên, tất cả những gì đang được nói, tôi sẽ (tùy thuộc vào thời điểm nó được viết ban đầu) đề nghị nếu nó nói, mã F77 trở lên, viết lại một phần qua thời gian cho các phương ngữ mới hơn - ít nhất là F90, nếu có thể với các tính năng F2003. Một bài báo / luận án về chủ đề đó đã được xuất bản gần đây (tệp PDF kích thước trung bình phía trước). Không chỉ có thể, nếu được thực hiện đúng cách, đảm bảo tính di động trên nhiều nền tảng, mà còn giúp việc bảo trì trong tương lai dễ dàng hơn.

ps Theo như "bảo trì trong tương lai", chỉ là một anegdote mà đôi khi tôi muốn đề cập đến. Trong khi viết luận án, tôi đã sử dụng lại một số mã từ người cố vấn của mình, được viết cách đây 35 năm kể từ thời điểm viết. Nó được biên dịch chỉ với một lỗi; một tuyên bố bị thiếu ở cuối, do lỗi sao chép dán :)

@DaveMateer (trả lời bình luận) - Tôi sẽ đưa ra nhận xét sau đây có thể hơi bất lịch sự, nhưng xin đừng hiểu sai, vì đó là ý định công bằng.

Dường như với tôi bạn đang giải quyết "vấn đề" này một cách sai lầm. Ý tôi là ở một vài điểm ngắn (vì ở đây rất muộn và khả năng tôi có thể tạo ra những câu có thể đọc được (huống chi là dễ hiểu) để lại cho tôi sau 10p.m.)

a) bạn đã đề cập đến việc bạn đang cố gắng giảm thiểu thời gian mã hóa thêm, nhưng bạn đang xem xét viết lại từ một ngôn ngữ chuyên về điện toán số sang một từ một lựa chọn ngôn ngữ đầy màu sắc , nếu bạn tha thứ cho biểu hiện của tôi

• một số trong đó không có hỗ trợ cho các mảng đa chiều, trong số những thứ khác
• hầu hết trong số chúng không phù hợp với công việc số nặng (khả năng xử lý song song của Haskell và Hadoop tôi thừa nhận, tôi không biết gì về ... nhưng chưa bao giờ nghe thấy chúng kể cả trong các vòng tròn đó)
• nó có thể đã được thử, nhưng tôi chưa bao giờ nghe về việc viết lại từ Fortran, một ngôn ngữ cho các vấn đề rời rạc, sang một ngôn ngữ chức năng
• gần đây đã có một cuộc thảo luận về comp.lang.fortran (thử tìm kiếm thông qua các nhóm google) về các khía cạnh của điện toán khoa học "trong đám mây"
  (không muốn thôi thúc bạn, nhưng công bằng mà nói, không ai thực sự chắc chắn thuật ngữ đó thậm chí đại diện cho điều gì, một mình ít có một ví dụ về một ứng dụng thành công. Hầu hết mọi người đều đồng ý rằng tiềm năng tồn tại nhưng cho đến nay họ vẫn hạnh phúc với cách mọi thứ hoạt động.). Rất nhiều vấn đề không phù hợp với kiểu song song đó.

b) chi phí của việc viết lại như vậy là gì? người / giờ.

c) -Các phiên bản chính xác của các thư viện để biên dịch ...- là một vấn đề trong bất kỳ ngôn ngữ nào, không thể tránh được, tuy nhiên bạn nhìn vào nó.

d) Tôi đã nghe nói về Python (một ngôn ngữ rất hay) được sử dụng trong các ứng dụng song song trong một số trường hợp, nhưng sự thâm nhập của thị trường đó dường như vẫn không tăng, và bản chất luôn thay đổi của nó khiến nó trở thành một lựa chọn rất kém cho một dự án dài hạn (nghĩ tương thích ngược). Một số người thích nó rất giống như một ngôn ngữ "keo".

Ugh, nếu tôi nghĩ về bất cứ điều gì khác, sẽ thêm nó vào ngày mai. Phải ngủ một chút ...

Tôi nghi ngờ Fortran sẽ chết - nó có một phần lớn phần mềm và libs được viết trong đó đến nỗi mọi người vẫn đang làm việc với nó, chỉ ổn định tình trạng này. Ngoài ra, đây vẫn là một ngôn ngữ rất tốt nếu bạn không muốn làm gì hơn là bấm số - cú pháp rất thanh lịch và logic, cộng với trình biên dịch có thể dễ dàng đoán được những gì đang xảy ra. Do đó, đảm bảo rằng bất kỳ công nghệ tăng tốc phần cứng mới nào cũng sẽ hỗ trợ C, Fortran và một số loại OpenCL (khi cuối cùng nó sẽ hội tụ thành một thứ gì đó vững chắc).

Vì vậy, tôi muốn nói rằng bạn chỉ nên phân tách rõ ràng phần số, để nó trong Fortran, ràng buộc rõ ràng và viết phần còn lại vào bất cứ điều gì bạn muốn.

Python thực sự đã đạt được rất nhiều lực kéo trong cộng đồng máy tính khoa học (để có cái nhìn hơi lỗi thời, xem tập 9 số 3 của CiSE ). Tôi nghĩ rằng một con lai Python / Fortran là một cách tuyệt vời để đi. Để tận dụng tất cả các GPU đó, bạn có thể sử dụng PyCUDA hoặc PyOpenCL .

Tôi là một nhà toán học, người phân tích và viết các bộ giải số cho phương trình vi phân từng phần. Gần đây tôi đã ở trong một tình huống tương tự như bạn của bạn; mã Fortran 77 trong câu hỏi là phần mềm Clawpack nổi tiếng . Chúng tôi viết lại mã cấp cao nhất (tất cả các phần không cần phải nhanh) trong Python và sử dụng f2py để tự động bọc các phần cấp thấp.

Kết quả thực sự mạnh mẽ của điều này là sau đó chúng tôi đã có thể kết nối gần như một cách tầm thường mã Python / Fortran lai (được đặt tên là PyClaw ) với thư viện song song PETSc, lần đầu tiên tạo ra một phiên bản song song có thể mở rộng của Clawpack hoạt động tốt trên lõi 65K. Tất cả các mã song song mà chúng tôi phải viết được chứa trong ít hơn 300 dòng Python . Bây giờ chúng ta đang giải quyết các vấn đề không thể giải quyết được chỉ bằng mã kế thừa. Cũng quan trọng không kém, giờ đây người dùng mới dễ dàng nhận mã hơn, vì Python là một ngôn ngữ thân thiện và hầu hết mọi thứ có thể được sửa đổi trong thời gian chạy thay vì thời gian biên dịch.

Nếu bạn muốn xem chi tiết hơn về cách tiếp cận và kết quả của chúng tôi, chúng tôi có một bài viết về arXiv .

Xin lỗi vì tự quảng cáo, nhưng dường như kinh nghiệm cá nhân của tôi sẽ có liên quan ở đây. Nếu bạn muốn nghe thêm nhiều ý tưởng, bạn cũng có thể đăng bài này trên http://scicomp.stackexchange.com mới .

Tôi hiện đang ở trong một tình huống rất giống với bạn của bạn. Tôi cũng mong muốn "hiện đại hóa" mã di sản KLOC Fortran-77 của mình. Và mặc dù Fortran vẫn được coi là vua trong các ứng dụng khủng hoảng số, tôi muốn nói rằng tất cả không bị mất. (Những gì tiếp theo là rant-ish vì vậy hãy chịu đựng với tôi).

Chỉ vì Fortran là ngôn ngữ tốt nhất cho mã số không có nghĩa là chúng ta phải mang theo hành lý to lớn này với một mã lộn xộn, phức tạp mọi lúc (Có mã Fortran bị ràng buộc là lộn xộn, đặc biệt là Fortran-77 ngôn ngữ hoàn toàn không liên quan đến công nghệ phần mềm, khi nó vượt qua một KLOC nhất định). Những người ủng hộ Fortran cho việc bẻ khóa số quên đi quan sát chung rằng khi bạn thực hiện phân tích hiệu suất của các mã đó, chỉ có 5% hoặc 10% mã được sử dụng chuyên sâu và 90% còn lại + Fortran là một chi phí vô dụng, chỉ là ở đó để biến cuộc sống của bạn như một "kỹ sư phần mềm" thành một địa ngục trần gian.

Khi bạn chuyển đến Fortran-90 từ Fortran-77, về cơ bản, bạn sẵn sàng đánh đổi hiệu suất với các tính năng ngôn ngữ ở một mức độ nào đó. Fortran là một cruncher số mạnh mẽ chủ yếu là do Fortran-77. Bạn có thể nói Fortran-90 nhanh như vậy, nhưng loại vấn đề tối ưu hóa mà người viết trình biên dịch phải giải quyết trong khi thêm các tính năng của Fortran-90/2003 và vẫn giữ hiệu suất của Fortran-77 không khác nhiều so với các vấn đề mà người viết trình biên dịch C phải giải quyết với (và kết quả là C cũng được coi là nhanh, chưa kể C cũng cho phép lắp ráp nội tuyến). Vậy tại sao không bắt đầu thêm mã C từng chút một (thay vì Fortran-90) vào mã Fortran-77. Mã của tôi đã có các phần trong C và các phần trong Fortran-77 và nó hoạt động rất tốt đối với một số vấn đề như truyền chuỗi, không lập chỉ mục / lập chỉ mục một, v.v. Nhưng lợi thế tôi có được từ C,

Tôi sẽ tiến thêm một bước nữa. Ngay cả C (và chắc chắn là Fortran-90/95/2003) ở mức quá thấp nếu bạn muốn có một giao diện "nhân văn" đẹp với một mã số giòn. Tôi đang nghĩ đến việc chuyển sang một con lai Python-Fortran-77 hoặc Python-C. Một mã trong đó 90% mã là Python (bao gồm Numpy, Scipy, tính dễ vẽ và tất cả sự ngọt ngào đó) và chỉ hiệu suất chuyên sâu 5% -10% vẫn là mã Fortran-77 hoặc C.

Tôi hiện đang trong quá trình cập nhật một cơ sở mã FORTRAN95 cũ để sử dụng trên các môi trường công nghiệp hiện đại vì phiên bản trước sẽ chỉ chạy trên các máy Windows2000 mới nhất. Bản thân cơ sở mã FORTRAN thực hiện một số lượng lớn khủng hoảng liên quan đến mô phỏng tưới tiêu.

Vì vậy, những gì tôi đang làm là thay vì viết lại FORTRAN bằng ngôn ngữ hiện đại hơn, tôi chỉ đơn giản là sử dụng trình biên dịch thương mại có tên Silverfrost FTN95 để biên dịch mã cơ sở FORTRAN sang thư viện .Net 4.0 mà tôi đang sử dụng làm phụ trợ của ứng dụng WPF . Bằng cách này, tôi không gặp rủi ro khi đưa các lỗi đã biết vào mã mô phỏng và tôi hiện đại hóa nó bằng cách di chuyển cơ sở mã sang khung .Net 4.0 để nó chạy trên các môi trường hiện đại hơn.

Nhưng tùy thuộc vào mức độ mô phỏng của bạn lớn đến mức nào, bạn có thể chỉ muốn viết lại toàn bộ nội dung bằng ngôn ngữ hiện đại hơn như C #, bản thân tôi đang lên kế hoạch thực hiện điều này một khi tôi có phiên bản mô phỏng đang chạy để so sánh đầu ra.

Hy vọng sự giúp đỡ của tôi sẽ giúp, Cảm ơn, Alex.

Tôi đã dẫn đầu một dự án từ năm 2001-2003, đã chuyển một ứng dụng windows 100KLOC từ FORTRAN sang C #. Đó là một ứng dụng khủng hoảng số có các ràng buộc GUI tùy chỉnh riêng cho các thư viện Win32. Cổng tới C # và WinForms giúp việc quản lý mã trở nên đơn giản hơn rất nhiều và mang đến cho mọi người môi trường phát triển phong phú hơn trong Visual Studio. Có một chút kháng cự sớm (đặc biệt là về các tuyên bố định dạng), nhưng cuối cùng nó chắc chắn là đáng giá.

Theo ý kiến ​​của tôi, việc cắn viên đạn và loại bỏ số lượng mã FORTRAN tối đa có thể là điều hợp lý. Tốc độ chưa bao giờ là vấn đề - các thử nghiệm ban đầu chạy mã trong C # so với FORTRAN thấy sự khác biệt về hiệu suất là không đáng kể, mặc dù C # đang chạy mã được quản lý. Tuy nhiên, nhu cầu của bạn với các vectơ có thể hơi khác một chút và việc có một lượng mã FORTRAN còn lại cũng sẽ được chấp nhận.

Một lý do khác để làm điều đó tất nhiên là sự sẵn có lâu dài của những người có kinh nghiệm FORTRAN có thể duy trì mã của bạn so với các nhà phát triển C #. Ngoài ra, nó giúp tinh thần làm việc nhóm được làm việc trong một ngôn ngữ hiện đại, được hỗ trợ tốt.

Tôi đã được thông báo rằng trong nhiều bối cảnh, MATLAB đang thay thế FORTRAN cho ứng dụng máy tính khoa học. Không chỉ hiện đại và cao cấp, nó còn khá nhanh với những gì nó làm. Rất nhiều nhà phát triển làm việc trên phần mềm hình ảnh y tế đã sử dụng MATLAB, vì vậy nó có một số thư viện dành riêng cho tưởng tượng y tế. Điều này có nghĩa là bạn sẽ tìm thấy cả công cụ và hỗ trợ chuyên gia về miền nếu bạn sử dụng MATLAB.