대규모 포트란 기반의 크 런칭 코드베이스를 어떻게 현대화 할 수 있습니까?

학계의 친구가 조언을 구했습니다 (저는 C # 비즈니스 응용 프로그램 개발자입니다).

그는 의료 영상 분야에서 Fortran에 작성한 레거시 코드베이스를 가지고 있습니다. 벡터를 사용하여 엄청난 수의 크 런칭을 수행합니다. 그는 클러스터 (30ish cores)를 사용하고 있으며 500ish GPUS가 포함 된 단일 워크 스테이션으로 이동했습니다.

그러나 코드베이스로 다음에 갈 곳은 다음과 같습니다.

• 다른 사람들은 다음 10 년주기 동안이를 유지할 수 있습니다
• 소프트웨어 조정 속도 향상
• 재 컴파일없이 다른 인프라에서 실행 가능

나에게서 조사한 후 (이것은 매우 흥미로운 분야입니다) 몇 가지 옵션은 다음과 같습니다.

• 사용 파이썬과 CUDA 에서 엔비디아
• 기능적 언어로 다시 작성하십시오. 예를 들어, F # 또는 Haskell
• 클라우드 기반으로 이동하여 Hadoop 및 Java와 같은 것을 사용하십시오.
• C 배우기

이것에 대한 당신의 경험은 무엇입니까? 친구가 코드베이스를 현대화하기 위해 무엇을보고 있어야합니까?

업데이트 : @Mark와 답변 한 모든 사람에게 감사드립니다. 내 친구 가이 질문을하는 이유는 프로젝트 수명주기에서 검토를하기에 완벽한 시간이기 때문입니다. Fortran에서 연구 보조원의 속도를 높이려면 시간이 걸립니다 (C #, 특히 툴링을 좋아하며 이전 언어로 돌아가는 것을 상상할 수 없습니다 !!)

나는 Fortran에서 순수한 숫자 크 런칭을 유지하지만 더 새로운 것으로 감싸는 제안을 좋아했습니다. 아마도 파이썬은 꽤 쉽게 배울 수있는 범용 프로그래밍 언어로 학계에서 강점을 얻고있는 것 같습니다.

Medical Imaging 및 CUDA 용 Fortran 래퍼를 작성한 사람을 참조하십시오. Fortran 90 래퍼를 Nvidias의 CUFFT 라이브러리 (CUDA SDK에서)에 합법적으로 게시 할 수 있습니까? .

다음과 같은 문제에 대해 실제로 포트란을 목록의 최상위에 두어야합니다.

a) 숫자 크 런칭
b) 병렬화
c) cs 연구 외부에서 (전문 프로그래머가 아닌 엔지니어에게) 실제로 가르치는 언어 였지만 여전히 언어이다.
d) 업계 수준의 컴파일러 수준에서 믿을 수 없을만큼 (!) 업계 지원을 제공하며, 벤더 중 어느 것도 해당 지점을 포기한 징후가 가장 적습니다. 얼마 전까지 인텔 대표 중 한 명이 자사 포트란 제품의 판매량이 개발 툴의 판매량보다 높다고 밝혔습니다.

또한 매우 쉽게 배울 수있는 언어입니다. 연구 조교를 빠르게 데려 오는 데 시간이 걸린다는 데 동의하지 않습니다. 저의 첫 번째 교과서에는 30 페이지가 넘는 희소 인쇄 텍스트가 없었습니다. 10 개의 키워드를 학습 한 후 중간 크기의 프로그램을 작성할 수있는 언어입니다. 나는 기본 Word 텍스트로 작성된 30 페이지가 대부분의 사용자에게 더 포괄적 인 "Fortran manual"을 만들 것이라고 감히 말할 것입니다.

당신이 CUDA에 관심이 있다면, 당신은 확인 할 수 있습니다 포틀랜드 그룹의 컴파일러 , 그것을 지원합니다 . 나는 세밀한 세부 사항에 익숙하지 않지만 사람들은 일반적으로 칭찬으로 이야기합니다.

그 외에도 병렬 프로그램의 경우 OpenMP, MPI 및 현재 출시 된 (그리고 오랫동안 기다려온) 공동 배열을 사용할 수 있습니다. 인텔 컴파일러는 최근에 구현했습니다. 단어를 낭비하지 않기 위해, 포트란은 프로그램 병렬화를위한 "라이브러리"의 아주 좋은 감마를 가지고 있습니다.

업계 표준 수치 라이브러리 는 무엇보다도 기능 / 루틴 포트폴리오에서 다소 다른 언어를 따르도록 개발되었습니다.

모든 존재는 나는 그러나, 것이라고 말했다 (이 원래 작성된 경우에 따라 다름) F90를 적어도, 가능하면 F2003 기능 -이하자의 말, F77 코드 또는 오래된 경우, 추천 새 방언에 시간을 통해 부분적으로 재 작성. 해당 주제에 대한 논문 / 논문이 최근에 출판되었습니다 (중간 크기의 PDF 파일). 올바르게 수행하면 여러 플랫폼에서 이식성을 보장 할 수있을뿐만 아니라 향후 유지 관리를보다 쉽게 ​​수행 할 수 있습니다.

ps "미래 유지 보수"가 진행되는 한, 가끔 언급하고 싶은 일 화일뿐입니다. 논문을 쓰는 동안 35 년 전에 쓴 시점에서 작성된 멘토의 코드를 다시 사용했습니다. 하나의 오류로 컴파일되었습니다. 복사 붙여 넣기 실수로 인해 끝에 문장이 없습니다. :)

@DaveMateer (댓글에 답장) -약간의 무례한 내용이 될 수있는 다음의 설명을하겠습니다. 그러나 공정한 의도이므로 잘못된 방식으로 취하지 마십시오.

이 "문제"를 잘못된 방식으로 다루고있는 것 같습니다. 몇 가지 짧은 요점에서 의미하는 것은 (여기서는 매우 늦기 때문에 읽을 수있는 문장을 만들 수있는 능력은 오후 10시 이후에 떠납니다.)

a) 여분의 코딩 시간을 최소화하려고한다고 말했지만 숫자 표현에 특화된 언어에서 다채로운 언어 선택의 언어로 다시 작성하는 것을 고려하고 있습니다 .

• 그중 일부는 다차원 배열을 지원하지 않으며 무엇보다도
• 그들 중 대부분은 많은 수치 작업에 부적합합니다 (하스켈과 하둡의 병렬 처리 기능에 대해서는 인정합니다. 아무것도 알지 못하지만 그 서클에서 언급 된 적이조차 없습니다)
• 아마도 시도되었지만, 이질적인 문제를위한 언어 인 포트란 (Fortran)을 기능적 언어로 다시 쓴다는 말은 들어 본 적이 없습니다.
• comp.lang.fortran (Google 그룹을 통해 검색해보십시오)에 대한 "클라우드에서의"과학 컴퓨팅 측면에 대한 토론이 최근에
  있었습니다. 대부분의 사람들은 잠재력이 존재한다는 것에 동의했지만 지금까지는 그것이 일하는 방식에 만족합니다.). 많은 종류의 병렬 처리가 그런 종류의 병렬 처리에도 적합하지 않습니다.

b) 그러한 재 작성의 비용은 얼마입니까? 사람 / 시간.

c) -컴파일 할 라이브러리의 올바른 버전 ...-은 피할 수없는 모든 언어의 문제이지만, 살펴보십시오.

d) 몇 개의 occation에서 병렬 응용 프로그램에 사용되는 Python (정말 좋은 언어)에 대해 들었지만 그 시장의 보급률은 여전히 ​​상승하지 않는 것 같습니다. 장기 프로젝트 (역 호환성을 생각하십시오). 어떤 사람들은 "접착제"언어처럼 그것을 아주 좋아합니다.

내가 다른 것을 생각하면 내일 추가 할 것입니다. 잠 좀 자야 겠어 ...

나는 Fortran이 죽을지 의심합니다. 소프트웨어와 라이브러리가 너무 많아서 사람들이 여전히 작업 중이며이 상황을 안정화시키는 것입니다. 또한 숫자 크 런칭 이상의 것을 원치 않으면 여전히 좋은 언어입니다. 구문은 매우 우아하고 논리적이며 컴파일러는 무슨 일이 일어나고 있는지 쉽게 추측 할 수 있습니다. 따라서 새로운 하드웨어 가속기 기술은 C, Fortran 및 일종의 OpenCL을 지원할 것입니다 (결국 확실한 것으로 수렴 될 때).

따라서 숫자 부분을 명확하게 분리하고 Fortran에 남겨두고 명확한 바인딩을 만들고 나머지를 원하는대로 작성해야한다고 말하고 싶습니다.

파이썬은 실제로 과학 컴퓨팅 커뮤니티에서 많은 관심을 받고 있습니다 (약간 구식 인 경우 CiSE 9 권 3 번 참조 ). 필자는 Python / Fortran 하이브리드가 훌륭한 방법이라고 생각합니다. 모든 GPU를 활용하기 위해 PyCUDA 또는 PyOpenCL을 사용할 수 있습니다 .

저는 부분 미분 방정식에 대한 수치 솔버를 분석하고 쓰는 수학자입니다. 나는 최근에 당신의 친구와 비슷한 상황에있었습니다. 해당 포트란 77 코드는 잘 알려진 Clawpack 소프트웨어 입니다. 우리는 파이썬에서 최상위 코드 (빠르지 않아도되는 모든 부분)를 다시 작성하고 f2py를 사용하여 하위 수준 부분을 자동으로 감쌌습니다.

이로 인한 강력한 결과는 하이브리드 Python / Fortran 코드 ( PyClaw )를 병렬 라이브러리 PETSc와 거의 사소하게 연결 하여 처음으로 65K 코어에서 잘 작동하는 확장 가능한 병렬 버전의 Clawpack을 만들 수 있다는 것입니다. 우리가 작성해야하는 모든 병렬 코드는 300 줄 미만의 Python에 포함되어 있습니다. 이제는 기존 코드로는 해결할 수 없었던 문제를 해결하고 있습니다. 마찬가지로 파이썬은 친숙한 언어이며 컴파일 타임이 아닌 런타임에 거의 모든 것이 수정 될 수 있기 때문에 새로운 사용자가 코드를 선택하는 것이 훨씬 쉬워졌습니다.

우리의 접근 방식과 결과에 대한 자세한 내용을 보려면 arXiv에 대한 논문이 있습니다 .

자기 광고에 대한 사과지만 내 개인적인 경험이 여기에 관련이있는 것 같았습니다. 더 많은 아이디어를 듣고 싶다면 새로운 http://scicomp.stackexchange.com 에도 게시 하십시오 .

나는 현재 당신의 친구와 매우 비슷한 상황에 처해 있습니다. 또한 40 대 KLOC Fortran-77 레거시 코드를 "현대화"하는 데 필사적입니다. 그리고 포트란은 여전히 ​​숫자 크 런칭 애플리케이션에서 왕으로 여겨지지만 모든 것이 손실되지는 않는다고 말하고 싶습니다. (따라 오는 것은 불분명하므로 나와 함께 참 아라).

포트란이 숫자 코드를위한 최고의 언어라고해서 우리가 항상 복잡하고 복잡한 코드를 대량으로 운반해야한다는 의미는 아닙니다 (예 : 포트란 코드는 지저분합니다. 특히 포트란 -77은 말 그대로 소프트웨어 엔지니어링을 고려하지 않은 언어, 특정 KLOC를 넘을 때) 숫자 처리를 위해 Fortran을 옹호하는 사람들은 이러한 코드의 성능 분석을 수행 할 때 성능 집약적 코드의 5 % 또는 10 %에 불과하고 나머지 90 % + Fortran은 쓸모없는 오버 헤드라는 일반적인 관찰을 잊습니다. "소프트웨어 엔지니어"로서 당신의 인생을 살아있는 지옥으로 만들기 위해.

Fortran-77에서 Fortran-90으로 전환 할 때 언어 기능과 성능을 어느 정도 교환 할 수 있습니다. 포트란은 주로 포트란 -77로 인해 강력한 숫자 처리 장치입니다. Fortran-90은 빠르지 만 Fortran-90 / 2003 기능을 추가하면서도 Fortran-77 성능을 유지하는 동안 컴파일러 작성자가 처리해야하는 최적화 문제는 C 컴파일러 작성자가 처리해야하는 문제와 크게 다르지 않습니다. (따라서 C도 빠르다고 간주하지만 C는 인라인 어셈블리도 허용합니다). Fortran-77 코드에 C 코드를 Fortran-90 대신 비트 단위로 추가하지 마십시오. 내 코드는 이미 C 조각과 Fortran-77 조각을 가지고 있으며 문자열 전달, 제로 인덱싱 / 1 인덱싱 등과 같은 일부 문제에 크게 영향을받습니다. 그러나 C에서 얻는 이점,

한 걸음 더 나아갈 것입니다. C (그리고 확실히 포트란 -90/95/2003)조차도 번호 크 런칭 코드에 대한 훌륭한 "인간적인"인터페이스를 원한다면 너무 낮은 수준입니다. Python-Fortran-77 또는 Python-C 하이브리드로 전환하려고합니다. 코드의 90 %가 Python (Numpy, Scipy, plotability 및 모든 단맛 포함) 인 코드이며 성능 집약적 5 % -10 % 만 Fortran-77 또는 C 코드로 유지됩니다.

이전 버전은 최신 Windows2000 시스템에서만 실행되므로 현대 산업 환경에서 사용할 이전 FORTRAN95 코드베이스를 업데이트하는 중입니다. FORTRAN 코드베이스 자체는 관개 시뮬레이션과 관련된 대량의 크 런칭을 수행합니다.

그래서 내가하고있는 일은 FORTRAN을보다 현대적인 언어로 다시 쓰는 대신 Silverfrost FTN95 라는 상용 컴파일러 를 사용하여 FORTRAN 코드베이스를 WPF 응용 프로그램의 백엔드로 사용하는 .Net 4.0 라이브러리로 컴파일하는 것입니다 . 이렇게하면 알려진 버그를 시뮬레이션 코드에 가져올 위험이 없으며 코드베이스를 .Net 4.0 프레임 워크로 이동하여 현대화하여보다 현대적인 환경에서 실행할 수 있습니다.

그러나 시뮬레이션이 얼마나 큰지에 따라 C #과 같은 더 현대적인 언어로 모든 것을 간단히 다시 작성하고 싶을 수도 있습니다. 출력을 비교하기 위해 실행중인 버전의 시뮬레이션이 있으면이 작업을 계획하고 있습니다.

내 expieriance가 도움이되기를 바랍니다, Alex.

FORTRAN에서 C #으로 100KLOC Windows 응용 프로그램을 이식 한 2001-2003 년 프로젝트를 이끌었습니다. Win32 라이브러리에 대한 자체 사용자 정의 GUI 바인딩이있는 번호 크 런칭 응용 프로그램이었습니다. C # 및 WinForms 로의 포트는 코드 관리를 훨씬 간단하게 만들었으며 Visual Studio에서 모든 사람에게보다 풍부한 개발 환경을 제공했습니다. 초기에 (특히 형식 설명 측면에서) 약간의 저항이 있었지만 결국에는 그만한 가치가있었습니다.

제 생각에는 총알을 물고 가능한 한 많은 양의 FORTRAN 코드를 제거하는 것이 좋습니다. 속도는 결코 문제가되지 않았습니다. FORTRAN에 비해 C #에서 코드를 실행하는 초기 테스트에서는 C #이 관리 코드를 실행하더라도 성능 차이는 무시할만한 수준으로 나타났습니다. 그러나 벡터에 대한 요구는 약간 다를 수 있으며, 소량의 FORTRAN 코드가 남아있을 수도 있습니다.

이를 수행하는 또 다른 이유는 C # 개발자와 비교하여 코드를 유지할 수있는 FORTRAN 경험이있는 사람들의 장기적인 가용성 때문입니다. 또한 팀 사기가 현대적이고 잘 지원되는 언어로 작업하는 데 도움이됩니다.

많은 상황에서 MATLAB 은 과학 컴퓨팅 응용 프로그램을 위해 FORTRAN을 대체 하고 있다고 들었습니다 . 현대적이고 높은 수준 일뿐만 아니라 작업 속도도 매우 빠릅니다. 의료 영상 소프트웨어를 개발하는 많은 개발자들이 이미 MATLAB을 사용하고 있기 때문에 의료 상상력 전용 라이브러리가 여러 개 있습니다. 이는 MATLAB을 사용하는 경우 도구와 도메인 전문가 지원을 모두 찾을 수 있음을 의미합니다.