계산량이 많은 경우 Fortran을 C보다 최적화하는 것이 더 쉬운가요?

때때로 나는 포트란이 무거운 계산의 경우 C보다 빠르거나 빠를 수 있다고 읽었습니다. 정말 맞습니까? 나는 Fortran을 거의 알지 못한다는 것을 인정해야하지만, 지금까지 본 Fortran 코드에는 언어에 C에없는 기능이 있음을 보여주지 않았습니다.

사실이라면 그 이유를 알려주십시오. 숫자 크 런칭에 적합한 언어 나 라이브러리가 무엇인지 말하지 말고, 앱이나 라이브러리를 작성하지는 않습니다. 궁금합니다.

언어에는 비슷한 기능 세트가 있습니다. 성능 차이는 EQUIVALENCE 문을 사용하지 않는 한 포트란이 앨리어싱이 허용되지 않는다는 사실에서 비롯됩니다. 앨리어싱이있는 코드는 유효하지 않지만 Fortran은 아니지만 프로그래머가이 오류를 감지합니다. 따라서 포트란 컴파일러는 가능한 메모리 포인터의 앨리어싱을 무시하고보다 효율적인 코드를 생성 할 수 있습니다. C의이 작은 예를 살펴보십시오.

void transform (float *output, float const * input, float const * matrix, int *n)
{
    int i;
    for (i=0; i<*n; i++)
    {
        float x = input[i*2+0];
        float y = input[i*2+1];
        output[i*2+0] = matrix[0] * x + matrix[1] * y;
        output[i*2+1] = matrix[2] * x + matrix[3] * y;
    }
}

이 기능은 최적화 후 Fortran 기능보다 느리게 실행됩니다. 왜 그래? 출력 배열에 값을 쓰면 행렬 값을 변경할 수 있습니다. 결국, 포인터는 겹쳐 져서 동일한 메모리 덩어리 ( int포인터 포함 )를 가리킬 수 있습니다. C 컴파일러는 모든 계산을 위해 메모리에서 4 개의 행렬 값을 다시로드해야합니다.

Fortran에서 컴파일러는 매트릭스 값을 한 번로드하여 레지스터에 저장할 수 있습니다. Fortran 컴파일러는 포인터 / 배열이 메모리에서 겹치지 않는다고 가정하기 때문에 그렇게 할 수 있습니다.

다행히도이 restrict문제를 해결하기 위해 키워드 및 엄격 앨리어싱이 C99 표준에 도입되었습니다. 요즘 대부분의 C ++ 컴파일러에서도 잘 지원됩니다. 키워드를 사용하면 프로그래머가 포인터가 다른 포인터와 별명을 지정하지 않는다고 약속하는 힌트를 컴파일러에 제공 할 수 있습니다. 엄격한 앨리어싱 수단 프로그래머 약속 서로 다른 유형의 포인터 엔 절대 오버랩 예 A에 대한 double*의지하지 오버랩을 갖는 int*(즉, 특정의 예외 char*와 void*아무것도 겹칠 수있다).

당신이 그들을 사용하면 C와 포트란에서 같은 속도를 얻을 것이다. 그러나 restrict키워드를 성능에 중요한 기능으로 만 사용할 수 있다는 것은 C (및 C ++) 프로그램이 훨씬 안전하고 작성하기 쉽다는 것을 의미합니다. 예를 들어, CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30)대부분의 Fortran 컴파일러는 경고없이 즐겁게 컴파일하지만 일부 컴파일러, 일부 하드웨어 및 일부 최적화 옵션에만 표시되는 버그를 유발 하는 잘못된 Fortran 코드 :를 고려하십시오 .

네, 1980 년에; 2008 년에? 의존하다

전문적으로 프로그래밍을 시작했을 때, 포트란의 속도 우위는 도전이되었습니다. Dobbs 박사에서 그것에 대해 읽은 것을 기억 하고 나이든 프로그래머들에게 기사에 대해 이야기했습니다.

이론과 실용에 대한 두 가지 견해가 있습니다. 이론상 Fortran은 오늘날 C / C ++ 또는 어셈블리 코드를 허용하는 모든 언어에 본질적인 이점이 없습니다. 실제로 오늘날 포트란은 여전히 ​​수치 코드 최적화를 기반으로하는 역사와 문화의 유산의 이점을 여전히 누리고 있습니다.

Fortran 77까지는 언어 디자인 고려 사항이 최적화에 중점을 두었습니다. 컴파일러 이론과 기술의 상태로 인해 컴파일러 최적화에 코드를 최적화하기 위해 기능과 기능을 제한하는 경우가 종종 있었습니다. Fortran 77을 속도를 위해 기능을 희생시키는 전문 경주 용 자동차라고 생각하는 것이 좋습니다. 요즘 컴파일러는 모든 언어에서 더 좋아졌으며 프로그래머 생산성을위한 기능이 더 중요합니다. 그러나 과학 컴퓨팅에서 사람들이 주로 속도에 관심을 갖는 곳이 여전히 있습니다. 이 사람들은 아마도 포트란 프로그래머였던 사람들로부터 코드, 훈련 및 문화를 물려 받았을 것입니다.

코드 최적화에 관해 이야기하기 시작할 때 많은 문제가 있으며, 이것을 느끼는 가장 좋은 방법 은 빠른 숫자 코드를 가진 사람들이있는 곳 을 찾는 것입니다 . 그러나 매우 중요하게 민감한 코드는 일반적으로 전체 코드 라인의 일부에 불과하고 매우 전문화되어 있습니다. 많은 포트란 코드는 다른 언어의 다른 코드와 마찬가지로 "비효율적"이며 최적화도 그러한 코드의 주요 관심사 .

포트란의 역사와 문화에 대해 배우기 시작하는 가장 좋은 곳은 위키피디아입니다. Fortran Wikipedia 항목 은 훌륭하며 Fortran 커뮤니티에 가치를 만들기 위해 시간과 노력을 기울인 사람들에게 대단히 감사합니다.

(이 답변의 단축 버전은 Nils가 시작한 우수한 스레드에 대한 주석 이었을 것입니다. 그러나 나는 그것을 할 카르마가 없습니다. 실제로, 아마도이 스레드가 실제로는 아무것도 작성하지 않았을 것입니다. 이 주제에 대한 나의 주요 경험 인 화염 전쟁과 언어 편견과는 반대로 정보 내용과 공유 나는 압도되어 사랑을 공유해야했다.)

Fortran은 어느 정도 컴파일러 최적화를 염두에두고 설계되었습니다. 이 언어는 컴파일러가 병렬 처리 (특히 멀티 코어 프로세서)를 활용할 수있는 전체 배열 작업을 지원합니다. 예를 들어

고밀도 행렬 곱셈은 다음과 같습니다.

matmul(a,b)

벡터 x의 L2 규범은 다음과 같습니다.

sqrt(sum(x**2))

또한 FORALL, PURE& ELEMENTAL프로 시저 등과 같은 명령문 은 코드를 최적화하는 데 도움이됩니다. Fortran의 포인터 조차도이 간단한 이유 때문에 C만큼 유연하지 않습니다.

다가오는 Fortran 표준 (2008)에는 병렬 코드를 쉽게 작성할 수있는 공동 배열이 있습니다. CRAY의 G95 (오픈 소스) 및 컴파일러는 이미이를 지원합니다.

따라서 컴파일러는 C / C ++보다 더 잘 최적화 / 병렬화 할 수 있기 때문에 포트란이 빠릅니다. 그러나 인생의 다른 모든 것들과 마찬가지로 좋은 컴파일러와 나쁜 컴파일러가 있습니다.

언어를 모르는 것에 대한 많은 답변이 여기에 있습니다. 이는 FORTRAN 77 코드를 열고 오래된 취약점을 논의한 C / C ++ 프로그래머에게 특히 해당됩니다.

속도 문제는 대부분 C / C ++와 Fortran 사이의 문제라고 생각합니다. 거대한 코드에서는 항상 프로그래머에 따라 다릅니다. 포트란이 능가하는 언어의 일부 기능과 C가하는 일부 기능이 있습니다. 따라서 2011 년에는 어느 쪽이 더 빠른지 아무도 말할 수 없습니다.

현재 언어 자체에 대해 Fortran은 현재 전체 OOP 기능을 지원하며 이전 버전과 완전히 호환됩니다. Fortran 2003을 철저히 사용했으며 사용하기가 기뻤습니다. 일부 측면에서 Fortran 2003은 여전히 ​​C ++ 뒤에 있지만 사용법을 살펴 보겠습니다. 포트란은 주로 Numerical Computation에 사용되며 속도 때문에 멋진 C ++ OOP 기능을 사용하는 사람은 없습니다. 고성능 컴퓨팅에서 C ++은 갈 곳이 거의 없습니다 (MPI 표준을 살펴보면 C ++이 더 이상 사용되지 않음을 알 수 있습니다!).

요즘에는 포트란과 C / C ++로 간단히 혼합 언어 프로그래밍을 할 수 있습니다. 포트란에는 GTK +를위한 인터페이스도 있습니다. 무료 컴파일러 (gfortran, g95)와 많은 훌륭한 상용 컴파일러가 있습니다.

포트란이 더 빠를 수있는 몇 가지 이유가 있습니다. 그러나 중요한 양은 중요하지 않거나 어쨌든 해결 될 수 있으므로 중요하지 않습니다. 요즘 Fortran을 사용하는 주된 이유는 레거시 응용 프로그램을 유지 관리하거나 확장하기 때문입니다.

• 함수에 대한 순수 및 요소 키워드. 부작용이없는 기능입니다. 이는 컴파일러가 동일한 함수가 동일한 값으로 호출 될 것이라는 것을 알고있는 특정 경우 최적화를 허용합니다. 참고 : GCC는 언어의 확장으로 "순수"를 구현합니다. 다른 컴파일러도 가능합니다. 모듈 간 분석도이 최적화를 수행 할 수 있지만 어렵습니다.

• 개별 요소가 아닌 배열을 다루는 표준 함수 세트. sin (), log (), sqrt ()와 같은 것은 스칼라 대신 배열을 취합니다. 이를 통해 루틴을보다 쉽게 ​​최적화 할 수 있습니다. 자동 벡터화는 대부분의 경우 이러한 기능이 인라인 또는 내장 인 경우 동일한 이점을 제공합니다.

• 내장 복합 유형. 이론적으로 이것은 컴파일러가 특정 경우에 특정 명령어를 재정렬하거나 제거 할 수 있지만 struct {double re, im; }; C에서 사용되는 관용구. 운영자가 포트란에서 복잡한 유형에 대해 작업하지만 개발 속도가 빨라집니다.

Fortran에 유리한 점은 벡터 및 배열 기반 수학을 표현하는 데 약간 더 적합한 언어라는 것입니다. 휴대용 코드는 실제로 컴파일러에게 무언가를 말할 수 있다고 가정 할 수 없기 때문에 위에서 지적한 포인터 분석 문제는 실제로 실제입니다. 도메인이 어떻게 보이는지에 더 가까운 방식으로 표현 컴퓨터에 대한 이점이 항상 있습니다. C는 실제로 배열을 가지고 있지 않습니다. 자세히 보면, 일종의 행동 만 할 수 있습니다. 포트란은 진짜 소란 스러웠습니다. 특정 유형의 알고리즘, 특히 병렬 시스템에 대해 더 쉽게 컴파일 할 수 있습니다.

런타임 시스템 및 호출 규칙과 같이 C와 현대 Fortran은 차이가 나는 것이 무엇인지 알기에는 충분히 유사합니다. 여기서 C는 실제로 기본 C입니다. C ++은 매우 다른 성능 특성을 가진 완전히 다른 문제입니다.

한 언어가 다른 언어보다 빠르다는 것은 없으므로 정답은 ' 아니요' 입니다.

실제로 물어봐야 할 것은 "Fortran 컴파일러 X로 컴파일 된 코드가 C 컴파일러 Y로 컴파일 된 동등한 코드보다 빠릅니까?"입니다. 물론이 질문에 대한 대답은 어떤 두 컴파일러를 선택 하느냐에 달려 있습니다.

또 다른 질문은 "컴파일러를 최적화하는 데 같은 노력을 기울이면 어느 컴파일러가 더 빠른 코드를 생성 할 수 있을까요?" 이에 대한 대답은 실제로 포트란 입니다. 포트란 컴파일러에는 다음과 같은 장점이 있습니다.

• Fortran은 일부 사람들이 컴파일러를 사용하지 않겠다고 약속 한 날 어셈블리와 경쟁해야했기 때문에 속도를 높이기 위해 설계되었습니다. C는 유연하게 설계되었습니다.
• Fortran의 틈새 시장은 숫자 위기였습니다. 이 도메인 코드는 결코 빠르지 않습니다. 따라서 언어를 효율적으로 유지해야한다는 압박이 항상 컸습니다.
• 컴파일러 최적화에 대한 대부분의 연구는 Fortran 번호 크 런칭 코드의 속도를 높이려는 사람들이 수행하므로 Fortran 코드 최적화는 다른 컴파일 된 언어를 최적화하는 것보다 훨씬 더 잘 알려진 문제이며, Fortran 컴파일러에서 새로운 혁신이 먼저 나타납니다.
• Biggie : C는 Fortran보다 더 많은 포인터 사용을 권장합니다. 이로 인해 C 프로그램에서 모든 데이터 항목의 잠재적 인 범위가 크게 증가하여 최적화하기가 훨씬 어려워집니다. Ada는이 영역에서 C보다 훨씬 우수하며 일반적으로 사용되는 Fortran77보다 훨씬 현대적인 OO 언어입니다. C보다 빠른 코드를 생성 할 수있는 OO 언어를 원한다면 이것이 옵션입니다.
• Fortran 컴파일러의 고객은 수의 틈새 시장으로 인해 C 컴파일러의 고객보다 최적화에 더 관심을 갖는 경향이 있습니다.

그러나 누군가 C 컴파일러의 최적화에 많은 노력을 기울이지 않고 플랫폼의 Fortran 컴파일러보다 더 나은 코드를 생성하는 것을 막을 수는 없습니다. 실제로, C 컴파일러가 생성 한 판매량이 많을수록이 시나리오를 실현할 수 있습니다.

포트란이 C와 다르고 잠재적으로 더 빠른 다른 항목이 있습니다. Fortran은 C보다 최적화 규칙이 더 우수합니다. Fortran에서는 식의 평가 순서가 정의되어 있지 않으므로 컴파일러가이를 최적화 할 수 있습니다. 특정 순서를 강제하려면 괄호를 사용해야합니다. C에서는 순서가 훨씬 엄격하지만 "-fast"옵션을 사용하면보다 느슨하고 "(...)"도 무시됩니다. 나는 포트란이 중간에 멋지게 놓여있는 방법을 가지고 있다고 생각합니다. (IEEE는 특정 평가 순서 변경으로 인해 오버플로가 발생하지 않기 때문에 라이브를 더욱 어렵게 만듭니다. 오버플로가 발생하면 무시하거나 평가를 방해해야합니다.)

더 똑똑한 규칙의 또 다른 영역은 복소수입니다. C 99까지 C가 가지고 있었을뿐만 아니라 Fortran에서 규칙이 더 좋습니다. gfortran의 포트란 라이브러리는 부분적으로 C로 작성되었지만 포트란 의미론을 구현하기 때문에 GCC는 옵션을 얻었습니다 ( "일반"C 프로그램과 함께 사용 가능).

-fcx-fortran-rules 복잡한 곱셈과 나눗셈은 포트란 규칙을 따릅니다. 범위 축소는 복소수 나눗셈의 일부로 수행되지만 복소수 곱셈 또는 나눗셈 결과가 "NaN + I * NaN"인지 여부는 확인되지 않으며,이 경우 상황을 구조하려고합니다.

위에서 언급 한 별칭 규칙은 또 다른 보너스이며, 적어도 원칙적으로는 컴파일러의 최적화 프로그램에서 올바르게 고려할 경우 전체 배열 작업이 더 빠른 코드를 생성 할 수 있습니다. 반대로 특정 작업에 더 많은 시간이 걸리는 경우가 있습니다. 예를 들어 할당 가능한 배열에 할당을 수행하는 경우 많은 검사가 필요합니다 (재 할당? [Fortran 2003 기능], 배열 보폭 등). 간단한 조작은 뒤에서 더 복잡하므로 느리지 만 언어는 더 강력합니다. 반면에 유연한 범위와 보폭을 사용하는 배열 연산을 사용하면 코드를보다 쉽게 ​​작성할 수 있으며 컴파일러는 일반적으로 사용자보다 코드를 최적화하는 것이 좋습니다.

전체적으로 C와 Fortran은 모두 똑같이 빠르다고 생각합니다. Fortran의 전체 배열 작업을 사용하는 것이 어떤 언어를 더 좋아하는지 또는 더 나은 이식성이 더 유용한 지 또는 C의 시스템 및 그래픽 사용자 인터페이스 라이브러리와의 인터페이스가 더 좋을지 선택해야합니다.

Fortran 및 C 언어 에는 특정 목적을 위해 다른 언어 보다 빠른 언어 가 없습니다 . 이 언어들 각각에 대한 특정 컴파일러에 대한 것들이 있는데, 이는 특정 작업에 대해 다른 작업보다 유리하게 만듭니다.

수년간 Fortran 컴파일러는 숫자 루틴에 흑 마법을 적용하여 많은 중요한 계산을 미치게 만들었습니다. 현대의 C 컴파일러도 그렇게 할 수 없었습니다. 그 결과 Fortran에서 많은 훌륭한 코드 라이브러리가 성장했습니다. 잘 테스트되고 성숙하고 훌륭한 라이브러리를 사용하려면 Fortran 컴파일러를 사용하십시오.

비공식 관찰에 따르면 요즘 사람들은 많은 계산 언어를 오래된 언어로 코딩하고 있으며 시간이 오래 걸리면 저렴한 계산 클러스터에서 시간을 찾습니다. 무어의 법칙은 우리 모두를 바보로 만듭니다.

포트란, C 및 C ++의 속도를 netlib의 클래식 Levine-Callahan-Dongarra 벤치 마크와 비교합니다. OpenMP와 함께 사용되는 다국어 버전은 http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors입니다 . C는 자동 번역, 특정 제한 및 pragma 삽입으로 시작되어 더 추악합니다. 컴파일러. C ++은 해당되는 경우 STL 템플릿이있는 C입니다. 내 견해에 따르면, STL은 유지 보수성을 향상시키는 지에 대한 혼합 백입니다.

예제는 인라인에 거의 의존하지 않는 전통적인 포트란 (Fortran) 관행을 기반으로하기 때문에 최적화를 어느 정도까지 향상시킬 수 있는지 자동 함수 인라인으로 최소한의 연습 만합니다.

가장 널리 사용되는 C / C ++ 컴파일러에는 자동 벤치마킹 기능이 부족하여 이러한 벤치 마크에 크게 의존합니다.

Fortran에서 괄호를 사용하여 더 빠르고 정확한 평가 순서를 지시하는 몇 가지 예가 있습니다. 알려진 C 컴파일러에는 더 중요한 최적화를 비활성화하지 않고 괄호를 관찰 할 수있는 옵션이 없습니다.

저는 취미 프로그래머이며 두 언어 모두 "평균"입니다. C (또는 C ++) 코드보다 빠른 포트란 코드를 작성하는 것이 더 쉽다는 것을 알았습니다. Fortran과 C는 모두 "역사적"언어이며 (오늘날 표준에 따라) 많이 사용되며 무료 및 상용 컴파일러를 잘 지원합니다.

역사적인 사실인지 모르겠지만 Fortran은 평행 / 분산 / 벡터화 / 많은 코어 크기로 구축 된 것처럼 느낍니다. 그리고 오늘날 우리가 속도에 관해 이야기 할 때 "표준 측정 기준"과 거의 같습니다. "확장합니까?"

순수한 CPU 크 런칭을 위해 나는 포트란을 좋아합니다. IO와 관련된 것은 C로 작업하기가 더 쉽다는 것을 알았습니다 (어쨌든 두 경우 모두 어렵습니다).

물론, 병렬 수학 집약적 코드의 경우 GPU를 사용하고 싶을 것입니다. C와 Fortran은 모두 CUDA / OpenCL 인터페이스 (현재 OpenACC)가 어느 정도 통합되어 있습니다.

내 객관적인 대답은 다음과 같습니다. 두 언어를 똑같이 잘 / 잘 모르면 Fortran에서 C보다 병렬 / 분산 코드를 작성하는 것이 더 쉽다는 것을 알기 때문에 Fortran이 더 빠르다고 생각합니다 (한 번 "자유형"fortran 및 엄격한 F77 코드뿐만 아니라)

다음은 첫 번째 답변이 마음에 들지 않기 때문에 저를 공감하려는 사람들을위한 두 번째 답변입니다. 두 언어 모두 고성능 코드를 작성하는 데 필요한 기능이 있습니다. 따라서 구현하는 알고리즘 (cpu 집약적-io 집약적-메모리 집약적 인?), 하드웨어 (단일 cpu? 멀티 코어? 수퍼 컴퓨터 배포? GPGPU? FPGA?), 기술 및 궁극적으로 컴파일러 자체에 따라 다릅니다. C와 Fortran은 모두 멋진 컴파일러를 가지고 있습니다. (Fortran 컴파일러가 얼마나 고급이지만 C 컴파일러도 놀랍습니다).

추신 : Fortran GUI 라이브러리에 대해 나쁜 말이 많기 때문에 특별히 libs를 제외 시켰습니다. :)

FORTRAN과 C를 사용하여 몇 년 동안 광범위한 수학을하고있었습니다. 내 경험에 따르면 FORTRAN이 때로는 C보다 낫지 만 속도는 좋지 않지만 (적절한 코딩 스타일을 사용하여 C가 FORTRAN보다 빠르게 수행 할 수 있음) 오히려 LAPACK과 같이 매우 최적화 된 라이브러리 때문에 큰 병렬화. 내 의견으로는, FORTRAN은 실제로 다루기가 어려우며 그 단점은 그 단점을 취소하기에 충분하지 않기 때문에 계산을 위해 C + GSL을 사용하고 있습니다.

Fortran과 C의 속도 차이는 컴파일러 최적화 기능과 특정 컴파일러에서 사용하는 기본 수학 라이브러리가 될 것입니다. Fortran에 C보다 빠르다는 본질적인 것은 없습니다.

어쨌든, 훌륭한 프로그래머는 모든 언어로 Fortran을 작성할 수 있습니다.

Fortan이 C보다 훨씬 빠르다는 말은 들리지 않았지만 특정 경우에는 더 빠를 수도 있습니다. 그리고 핵심은 존재하는 언어 기능이 아니라 (보통) 부재하는 언어 기능에 있습니다.

C 포인터가 그 예입니다. C 포인터는 거의 모든 곳에서 사용되지만 포인터의 문제점은 일반적으로 컴파일러가 동일한 배열의 다른 부분을 가리키는 지 알 수 없다는 것입니다.

예를 들어 다음과 같은 strcpy 루틴을 작성한 경우 :

strcpy(char *d, const char* s)
{
  while(*d++ = *s++);
}

컴파일러는 d와 s가 겹치는 배열 일 수 있다는 가정하에 작동해야합니다. 따라서 배열이 겹칠 때 다른 결과를 생성하는 최적화를 수행 할 수 없습니다. 예상 한대로 수행 할 수있는 최적화 종류가 상당히 제한됩니다.

[C99에는 포인터가 겹치지 않도록 컴파일러에 알려주는 "restrict"키워드가 있습니다. 또한 Fortran도 C와 의미가 다른 포인터를 가지고 있지만 C와 같이 포인터가 어디에나있는 것은 아닙니다.]

그러나 C 대 Fortran 문제로 되돌아 가면 Fortran 컴파일러는 (직선적으로 작성된) C 프로그램에서는 불가능한 일부 최적화를 수행 할 수 있습니다. 그래서 나는 그 주장에 놀라지 않을 것입니다. 그러나 성능 차이가 그다지 크지 않을 것으로 기대합니다. [~ 5-10 %]

빠르고 간단 함 : 둘 다 똑같이 빠르지 만 포트란이 더 간단합니다. 결국 실제로 더 빠른 것은 알고리즘에 달려 있지만 어쨌든 속도 차이는 없습니다. 이것이 2015 년 독일 슈 투트 가르드 고성능 컴퓨팅 센터의 Fortran 워크숍에서 배운 내용입니다. 저는 Fortran과 C와 함께 일하며이 의견을 공유합니다.

설명:

C는 운영 체제를 작성하도록 설계되었습니다. 따라서 고성능 코드를 작성하는 데 필요한 것보다 더 많은 자유가 있습니다. 일반적으로 이것은 문제가되지 않지만 신중하게 프로그래밍하지 않으면 코드 속도가 느려질 수 있습니다.

Fortran은 과학 프로그래밍을 위해 설계되었습니다. 따라서 Fortran의 주요 목적이므로 빠른 코드 구문 작성을 지원합니다. 여론과 달리, 포트란은 구식 프로그래밍 언어가 아닙니다. 최신 표준은 2010이며 새 컴파일러는 정기적으로 게시됩니다. 대부분의 고성능 코드는 Fortran에서 작성됩니다. Fortran은 컴파일러 지시문 (C pragma)으로 최신 기능을 지원합니다.

예 : 우리는 큰 구조체를 함수에 대한 입력 인수로 제공하려고합니다 (fortran : 서브 루틴). 함수 내에서 인수는 변경되지 않습니다.

C는 참조 별 호출과 값별 호출을 모두 지원하므로 편리한 기능입니다. 우리의 경우, 프로그래머는 우연히 가치에 의한 호출을 사용할 수 있습니다. 구조체를 메모리 내에서 먼저 복사해야하므로 속도가 상당히 느려집니다.

Fortran은 참조로만 호출하여 작동합니다. 프로그래머가 실제로 값별 호출을 원할 경우 프로그래머가 직접 구조체를 복사해야합니다. 우리의 경우 포트란은 C 버전만큼 자동으로 호출됩니다.

일반적으로 FORTRAN은 C보다 느립니다. C는 프로그래머가 수동으로 최적화 할 수 있도록 하드웨어 수준 포인터를 사용할 수 있습니다. FORTRAN (대부분의 경우)은 하드웨어 메모리 주소 지정 해킹에 액세스 할 수 없습니다. (VAX FORTRAN은 또 다른 이야기입니다.) 70 년대 이후로 FORTRAN을 켜고 끌었습니다. (정말.)

그러나, 90 년대부터 FORTRAN 본질적 병렬 알고리즘으로 최적화 될 수있는 특정 언어 구조를 포함하도록 진화하고 있다 실제로 멀티 코어에 비명. 예를 들어 자동 벡터화를 사용하면 여러 프로세서가 데이터 벡터의 각 요소를 동시에 처리 할 수 ​​있습니다. 16 개의 프로세서-16 개의 요소 벡터-처리에는 1/16 시간이 걸립니다.

C에서는 다중 처리를 위해 자체 스레드를 관리하고 알고리즘을 신중하게 설계 한 다음 많은 API 호출을 사용하여 병렬 처리가 올바르게 수행되도록해야합니다.

FORTRAN에서는 다중 처리를 위해 알고리즘을 신중하게 설계해야합니다. 컴파일러와 런타임이 나머지를 처리 ​​할 수 ​​있습니다.

High Performance Fortran 에 대해 약간 읽을 수 있지만 많은 죽은 링크가 있습니다. 병렬 프로그래밍 (예 : OpenMP.org )과 FORTRAN 이이를 지원하는 방법 에 대해 읽는 것이 좋습니다 .

더 빠른 코드는 실제로 언어에 달려 있지 않습니다. 컴파일러이므로 ".exe"안에 묶여있는 부풀어지고 느리고 중복되는 객체 코드를 생성하는 ms-vb "컴파일러"를 볼 수 있지만 powerBasic이 너무 많이 생성됩니다 더 나은 코드. C 및 C ++ 컴파일러가 생성 한 객체 코드는 일부 단계 (최소 2 단계)로 생성되지만 설계 상 대부분의 포트란 컴파일러에는 고급 최적화를 포함하여 5 단계 이상이 있으므로 설계에 따라 포트란은 항상 고도로 최적화 된 코드를 생성 할 수 있습니다. 결국 컴파일러는 당신이 요구 해야하는 언어가 아닙니다. 내가 아는 가장 좋은 컴파일러는 Intel Fortran Compiler입니다 .LINUX와 Windows에서 얻을 수 있고 VS를 IDE로 사용할 수 있기 때문입니다. 저렴한 Tigh 컴파일러로 OpenWatcom에서 항상 릴레이 할 수 있습니다.

이에 대한 추가 정보 : http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html

Fortran은 더 나은 I / O 루틴을 가지고 있습니다. 예를 들어, 암묵적인 do 기능은 C의 표준 라이브러리가 일치 할 수없는 유연성을 제공합니다.

Fortran 컴파일러는보다 복잡한 구문을 직접 처리하므로 이러한 구문을 인수 전달 형식으로 쉽게 줄일 수 없으므로 C는이를 효율적으로 구현할 수 없습니다.

현대적인 표준과 컴파일러를 사용하면 안됩니다!

여기에있는 사람들 중 일부는 컴파일러가 앨리어싱에 대해 걱정할 필요가 없기 때문에 FORTRAN이 더 빠르다고 제안했습니다 (따라서 최적화 중에 더 많은 가정을 할 수 있습니다). 그러나 이것은 C99 (제 생각에) 표준 이후 제한 키워드가 포함 된 이후 C에서 처리되었습니다. 기본적으로 컴파일러에 알려주는 범위 내에서 포인터의 별칭이 지정되지 않습니다. 또한 C는 적절한 포인터 산술을 가능하게하며 앨리어싱과 같은 것이 성능 및 리소스 할당 측면에서 매우 유용 할 수 있습니다. 최신 버전의 FORTRAN이 "적절한"포인터를 사용할 수 있다고 생각합니다.

최신 구현의 경우 C 일반은 FORTRAN보다 성능이 뛰어납니다 (매우 빠르지 만).

http://benchmarksgame.alioth.debian.org/u64q/fortran.html

편집하다:

이것에 대한 공정한 비판은 벤치마킹이 편향 될 수 있다는 것입니다. 여기에 더 많은 맥락을 제공하는 또 다른 출처 (C 기준)가 있습니다.

http://julialang.org/benchmarks/

대부분의 경우 C가 일반적으로 Fortran보다 성능이 뛰어남을 알 수 있습니다 (다시 여기에 적용되는 비판 참조). 다른 사람들이 말했듯이 벤치마킹은 한 언어를 다른 언어보다 선호하기 위해 쉽게로드 할 수있는 부정확 한 과학입니다. 그러나 Fortran과 C의 성능이 어떻게 비슷한 지에 대해 설명합니다.

포트란은 배열, 특히 다차원 배열을 매우 편리하게 처리 할 수 ​​있습니다. Fortran에서 다차원 배열의 슬라이스 요소는 C / C ++의 요소보다 훨씬 쉽습니다. C ++에는 Boost 또는 Eigen과 같은 라이브러리가 작업을 수행 할 수 있지만 모든 외부 라이브러리 뒤에 있습니다. 포트란에서 이러한 기능은 본질적입니다.

Fortran이 개발에 더 빠르거나 편리한 지 여부는 주로 완료해야하는 작업에 따라 다릅니다. 지구 물리학의 과학 계산 담당자로서, 나는 Fortran에서 대부분의 계산을 수행했습니다 (현대 포트란,> = F90을 의미합니다).

이것은 컴파일러의 품질과 다른 것보다 더 중요하기 때문에 다소 주관적입니다. 그러나 언어 / 컴파일러의 관점에서 C에 비해 Fortran에 대해 본질적으로 C보다 더 빠르거나 더 나은 것으로 만들 수있는 질문에 더 직접 대답하기 위해, 수학 연산을 많이 수행하는 경우에는 컴파일러의 품질, 각 언어의 프로그래머 기술 및 주어진 연산에 대해 어느 것이 더 빠른지를 결정하기 위해 이러한 연산을 지원하는 내장 수학 지원 라이브러리.

편집 : @ Nils와 같은 다른 사람들은 C에서 포인터 사용의 차이와 C에서 가장 순진한 구현을 느리게 만드는 앨리어싱 가능성에 대해 좋은 지적을했습니다. 그러나 C99에서는이를 처리하는 방법이 있습니다. 컴파일러 최적화 플래그 및 / 또는 C 작성 방법 이것은 @ Nils 답변과 그의 답변에 따르는 후속 의견에 잘 설명되어 있습니다.

대부분의 게시물은 이미 설득력있는 주장을 제시하므로 잠언 2 센트를 다른 측면에 추가합니다.

결국 처리 능력 측면에서 포트란을 더 빠르거나 느리게하는 것이 중요 할 수 있지만, 포트란에서 무언가를 개발하는 데 5 배 더 많은 시간이 걸리는 경우 :

• 순수한 숫자 크 런칭과 다른 작업을위한 좋은 라이브러리가 없습니다.
• 문서화 및 단위 테스트를위한 적절한 도구가 없습니다.
• 표현력이 매우 낮은 언어로 코드 줄 수가 급상승합니다.
• 문자열 처리가 매우 좋지 않습니다.
• 그것은 다른 컴파일러와 아키텍처 사이에서 미친 듯이 많은 문제를 가지고 있습니다.
• IO 전략이 매우 열악합니다 (순차 파일의 읽기 / 쓰기. 예, 임의 액세스 파일이 있지만 사용 된 적이 있습니까?)
• 좋은 개발 관행, 모듈화를 권장하지 않습니다.
• 표준을 완벽하게 준수하는 오픈 소스 컴파일러의 효과적인 부족 (gfortran 및 g95는 모든 것을 지원하지는 않습니다)
• C와의 매우 낮은 상호 운용성 (관리 : 하나의 밑줄, 두 개의 밑줄, 밑줄 없음, 일반적으로 하나의 밑줄이 있지만 다른 밑줄이 있으면 두 개).

그런 다음 문제는 관련이 없습니다. 무언가가 느리면 대부분 주어진 시간을 초과하여 향상시킬 수 없습니다. 더 빠른 것을 원하면 알고리즘을 변경하십시오. 결국 컴퓨터 시간이 저렴합니다. 인간의 시간은 아닙니다. 인간의 시간을 줄이는 선택의 가치를 평가하십시오. 컴퓨터 시간을 늘리면 어쨌든 비용 효과적입니다.

Fortran은 전통적으로 -fp : strict와 같은 옵션을 설정하지 않습니다 (ifort는 f2003 표준의 일부인 USE IEEE_arithmetic의 일부 기능을 활성화해야 함). Intel C ++은 또한 기본값으로 -fp : strict를 설정하지 않지만 ERRNO 처리에 필요하며 다른 C ++ 컴파일러는 ERRNO를 끄거나 시뮬레이션 감소와 같은 최적화를 얻는 것이 편리하지 않습니다. gcc와 g ++에서는 위험한 조합 -O3 -ffast-math -fopenmp -march = native를 사용하지 않도록 Makefile을 설정해야했습니다. 이러한 문제 이외에도 상대 성능에 대한이 질문은 더 까다 롭고 컴파일러 및 옵션 선택에 대한 로컬 규칙에 따라 달라집니다.