확실히 3.0 이상 버전이 성능 면에서 떨어지는 것 같기는 합니다. atlas 라이브러리를 컴파
일 할 때도 2.95.3에서보다 최소한 20% 이상의 성능 감소가 있다는 주의가 있더군요. 저도 처
음엔 그냥 3.0대 버전으로 쓰다가 다시 2.95.3으로 돌아왔습니다. 생각보다 성능차이가 만만
치 않은 것 같아서요... : MPICH-1.2.3 컴파일시 다음과 같은 메시지가 나옵니다. 2.95.3으로 :
컴파일 할때는 조용하더군요. Redhat 7.2(updated) + Ximian : : 삽질하실때 참고하세요. 아래 질문
이냐 팁이냐 물었는데 물음표는 제가 :
: 지식이 짧아서 단순히 MPICH에서 뱉어낸 쓰레기인지 실제로 존재하는
:
: 버그인지 몰라서 입니다. 그리고 MPICH 컴파일시 컴파일러며 기타등등을
:
: 지정해주어야 한다고 말씀하시는데 정말 기억이 가물가물 할 정도로
:
: 오래전에 작업해본 것 같군요. 시간이 있으면 아래 메시지들을 손수
:
: 일일이 테스트 해보겠는데 그렇지 못합니다.
:
:
: 좋아진 점은 2.95.3으로 컴파일할때 40분 걸리던 것이 gcc-3.0.3 로
:
: 하면 10분 정도로 컴파일 시간이 단축되더군요.(C++ 고급(?)기능사용시)
:
: 나빠진 점은 그렇게 컴파일된 코드가 2.95.3으로 컴파일 한 것보다
:
: 실행속도가 25배 가량 느리지더군요. 어디까지나 제가 사용하는
:
: 라이브러리에 국한된 이야기 입니다. 지금은 다시 2.95.3을 사용합니다. --;;
:
:
:
:
:
: ===
:
: 방금 확인했는데 MPICH-1.2.3소스안에 C 버그 체크하는 프로그램이 있네요.
:
: 버그 있는 것 맞습니다. mpich-1.2.3/ccbugs 안에 보면 여러가지 버그를
:
: 체크하는 C 프로그램이 있습니다. 그것을 컴파일해서 결과를 확인하는 모양인데
:
: 공학하시거나 중요한 프로그램 작성하시는 분들은 3.0.3 을 사용하지
:
: 않는 것이 좋겠군요.
:
:
: 그런데 mpich-1.2.3/ccbugs 에서 에러난다는 소스를 3.0.3으로 컴파일
:
: 해보았는데 에러(틀린 결과)가 나오지 않네요. --;; 허참. 암튼 찝찝하니깐...
:
:
:
:
:
:
:
:
:
:
: checking for correct handling of #elif... no
: *# ******************************************************************
: *# * Your C compiler can not properly handle the #elif preprocessor *
: *# * directive. Report the problem to your vendor; you may want to *
: *# * using the GNU C compiler instead. *
: *# * *
: *# * Please file a bug report with your vendor. If you do not get *
: *# * satisfaction from your vendor, we suggest that you consider *
: *# * gcc. *
: *# * *
: *# ******************************************************************
: Output from compile step was:
: In file included from /usr/include/_G_config.h:44,
: from /usr/include/libio.h:32,
: from /usr/include/stdio.h:65,
: from conftest.c:18:
: /usr/include/gconv.h:172: array size missing in `__data'
: checking that constant folding in arrays works... yes
: checking that compiler truncates unsigned char correctly ...... no
: *# ******************************************************************
: *# * YOUR C COMPILER HAS A BUG!!!!!! *
: *# * *
: *# * Your C compiler fails to properly handle truncations of data *
: *# * to unsigned char properly. This should not affect MPICH but *
: *# * may cause errors in user programs and in some parts of the *
: *# * MPICH test suite. *
: *# * *
: *# * You may find that the compiler will generate correct code *
: *# * a lower levels of optimization. *
: *# ******************************************************************
: Output from compile step was:
: In file included from /usr/include/_G_config.h:44,
: from /usr/include/libio.h:32,
: from /usr/include/stdio.h:65,
: from conftest.c:1:
:
: /usr/include/gconv.h:172: array size missing in `__data'
: checking that compiler/hardware has commutative arithmetic ...... no
: *# ******************************************************************
: *# * YOUR C COMPILER / HARDWARE HAS NON-COMMUTATIVE ARITHMETIC!!! *
: *# * *
: *# * Your C compiler believes that x*y-y*x can be different from *
: *# * zero. This may be the result of inconsistent rounding in *
: *# * your computers hardware when multiply-add instructions are *
: *# * used. *
: *# * *
: *# * On some systems, a Multiply-Add combination whose results are *
: *# * different from a Multiply and an Add can cause this to happen. *
: *# * Results on this system, if it alleges to be IEEE, will differ *
: *# * from IEEE systems where arithmetic is commutative. *
: *# * *
: *# * At least one vendor views this behavior as a feature; if *
: *# * commutative arithmetic is important to you, consider using *
: *# * compilation options to reduce the amount of optimization or *
: *# * eliminate the use of Multiply-Add (this may reduce *
: *# * performance but will make it possible to compare computations *
: *# * on different systems). *
: *# * *
: *# ******************************************************************
: Output from compile step was:
: In file included from /usr/include/_G_config.h:44,
: from /usr/include/libio.h:32,
: from /usr/include/stdio.h:65,
: from conftest.c:1:
: /usr/include/gconv.h:172: array size missing in `__data'
: checking that compiler assigns to char correctly ...... no
: *# ******************************************************************
: *# * YOUR C COMPILER HAS A BUG!!!!!! *
: *# * *
: *# * Your C compiler fails to properly handle assignments or *
: *# * references to char arrays properly when the most significant *
: *# * bit in the character bit is set. This should not affect MPICH *
: *# * but may cause errors in user programs and in some parts of the *
: *# * MPICH test suite. *
: *# * *
: *# * You may find that the compiler will generate correct code *
: *# * a lower levels of optimization. *
: *# ******************************************************************
: Output from compile step was:
: In file included from /usr/include/_G_config.h:44,
: from /usr/include/libio.h:32,
: from /usr/include/stdio.h:65,
: from conftest.c:1:
: /usr/include/gconv.h:172: array size missing in `__data'
: checking that compiler does not call unknown routines for long doubles... yes
: checking that compiler accepts args correctly ...... no
: *# ******************************************************************
: *# * YOUR C COMPILER IS SERIOUSLY BROKEN!!!!!! *
: *# * *
: *# * Your C compiler fails to accept macro definitions to strings *
: *# * with embedded blanks. This often means that your compiler is *
: *# * improperly implemented as a shell script. You should file a *
: *# * bug report and require a fix *
: *# * *
: *# * MPICH is able to work around this bug; however, any compiler *
: *# * that can not handle this simple case is highly suspect. *
: *# * *
: *# * You may find that the compiler is an sh script with a *
: *# * statement containing $*. This is a common error; consider *
: *# * replacing $* with "$@". *
: *# ******************************************************************
: *#
:
: --
: 장미가 장미라는 것은 장미인가?