C/C++을 이용한 수치해석

geekforum의 이미지

저는 수치해석 관련 프로그램을 직접 만들어서 일하는 연구원입니다. 가장 익숙한 환경은 Linux 이고 C언어를 선호하는 편이지만 대규모 프로젝트에서는 Fortran으로 코드를 개발하는것이 불가피한 경우가 대부분입니다. 제가 생각하기에 그이유는 (1) 좋은 C 컴파일러가 없다는 점과 (2) 좋은 수치해석관련 라이브러리들이 대부분 Fortran으로 쓰여졌다는 점입니다.

같은 알고리즘을 써서 같은 목적을 수행하는 프로그램을 만들었을때 상용 Fortran Compiler가 허락하는 놀라운 속도를 상용 또는 GNU C Compiler 가 도저히 따라잡을 수 없다는 것은 지금까지 C Compiler를 설계해오신 분들이 시스템 관련 개발자들만을 염두에 두지 않았나 하는 생각을 하게 만드는군요. C 언어로 수치해석 관련 일을 할 수 있게 될 날은 과연 오지 않을까요?

nilz_의 이미지

본 질문과 약간 다르지만...

오늘 slashdot에 "Is FORTRAN Still Kicking?" 이라는 질문이 올라왔군요... 답장도...

질문한 사람은 계산 무지 많이 하는 일에 포트란 말고 다른 툴이 있냐고 마지막에 묻고 있네요...

외국에 있는 사람들은 어찌 생각하고 있는지 함 보시는 것도 좋을 듯 싶네요..

영어가 약해서리.. 내용은 이정도에서... ^^

답장중에 잼난 포트란 Joke ^^

"God is real; unless declared integer"

조규진의 이미지

헉..나 이제껏 C만 딥따 공부햇는뒈..
ㅠㅠ

익명 사용자의 이미지

C나 C++ 에서 함수호출없이, 그리고 필요한 메모리 및 변수스택을 미리 할당하고 하나의 함수 내에서 모든 루틴을 처리하면, 결국 포트란과 다를 게 없지 않나요.....

이 경우, 아무리 포트란 명령이 어셈블리어와 1:1 정도로 매칭되는 설계라고 하지만..
이런 특징은 C 도 마찬가지가 아닐까요.
또한 C++도 큰 클래스/함수/템플릿 호출이 아닌 다음에야... 같은 것일테구요.

속도문제로 포트란을 선택한다는 건 좀 이해가 안갑니다...

속도문제보다는 수치해석 관련자들의 관습과 기존의 포트란 소스들 때문같군요.

익명 사용자의 이미지

윗글의 겁쟁인데요.
다시 생각해보니...... 단순한 산술연산만이 아니겠군요. -_-;;
글 올리기 전에 생각하고 올려야지... -_-;;

그런데 여전히 질문하자면...
포트란에서는 미분/적분이나 sin(),cos() 뭐 이런 일반적인 함수를
어떻게 호출하나요 ?
이 역시도 스택에 push/pop 하는 거 없이 베이직의 gosub-return 인가요 ?

익명 사용자의 이미지

Call by Reference, Call by Value가 대세인 요즘 언어 세상에
Call by Name이라는게 오히려 이해하기가 더 어려울 수도 있겠지요.

FORTRAN은 Call by Name으로 파라미터를 넘깁니다.

요즘 나오는 FORTRAN90이나 FORTRAN95는 잘 모르겠군요.
아래 어떤 분 말로는 포인터도 지원한다고 하니 Call by Reference, Call by Value까지 지원 되는듯 합니다.

익명 사용자의 이미지

Call by Name 이라면,
완전히 '전역변수'를 통한 처리를 의미하는 것 같군요.
음.. GW-BASIC 을 보는 듯하네요. (혹은 어셈블러)
결국 '함수'라는 개념이 아니고, goto-return 식의 개념이네요..

이건 역시 예상한 대로구요. 진짜 문제는 사칙연산보다
log(), sin() 등의 함수연산이 어떤가 하는 부분인 듯 합니다.
이런 모든 연산이 합쳐저서 수치해석을 하는 거겠죠.. ?
함수연산을 호출할때도 Call by Name 이라면,
포트란 내부에는 정말 엄청난 전역변수가 사용되는 셈이네요.

그럼 결과가 나오지 않나요 ?
포트란의 빠른 속도 이야기는 결국 모든 변수의 전역화,
모든 함수의 goto-return 화...
이 두가지에서 비롯된 것에 불과하네요...

익명 사용자의 이미지

맞습니다. 정확히 보셨네요.

그러니 Pascal, C와 같은 구조적 언어가 처음 나왔을 때는
너무 느리지 않느냐는 비판을 받았었죠.

이것은 C++과 같은 객체지향 언어가 C 보다 느리다는 비판을 받는 것과
비슷한 맥락이죠.

익명 사용자의 이미지

감사합니다. =-)
확실한 답변을 들으니 이제 분명해지는군요.

익명 사용자의 이미지

C, C++ 와 FORTRAN mixed programming
프로그램을 작성하다보면, 기존의 라이브러리나 소스를 이용하는 경우가 많이 있다. 이 경우
기존의 유용한 라이브러리들이 현재 사용하고자 하는 언어가 아닌 다른 언어로 작성된 경우
에는 각 언어간의 함수를 호출하는 방법을 이해하고 이에 따라 적절한 방법으로 함수를 호
출해야만 원하는 결과를 얻을 수 있다. 한 언에에서 다른 언어로 작성된 함수를 호출하기
위해서는 먼저 함수의 이름을 구성하는 방법과, 인수를 처리하는 밥업을 알아야만 한다.

1. extern "C"
C 와 C++ 는 calling conventuion과 parameter-passing 방법이 동일하다.그러나 함수이름
의 경우, c++ 에서는 외부 symbol에 대하여 decoration을 하기 때문에, c와 c++ 소스코드상
에서 같은 함수의 이름으로 정의되더라도 실제 함수이름이 c 컴파일러를 사용한 경우와
c++ 컴파일러를 사용한 경우가 달라지게 된다. 따라서 만일 c 컴파일러로 컴파일된 함수(c
언어의 함수라도 c++로 컴파일된 경우는 상관없다.)를 c++ 언어로 작성된 함수에서 호출하
기 위해서는 이 함수가 c 의 naming convention을 따르는 함수라는 것을 알려주어야 한다.
이와같은 기능을 수행하는 것이 extern "C" 이다.
FORTRAN 으로 작성된 함수를 호출하는 경우에는 이보다도 더 복잡해지는데, g77의 경
우 특별한 옵션을 설정하지 않는 경우 기본적으로 함수의 이름이 소문자로 구성되고 함수의
이름 끝에 underbar _ 가 따라오게 된다. 따라서 c++에서 FORTRAN 함수를 호출하는 경
우 일단 함수이름을 소문자로 구성하고(g77의 기본설정만을 예로들고 있다) 함수이름 끝에
underbar를 붙인 함수를 extern "C" 선언으로 명시해주어야 한다.

아래에 간단한 c 함수와 FRTRAN 함수를 c++에서 호출하는 예제프로그램이 있다.

void cfn(float f)
{
printf(" c function val=%f \n",f);
}

SUBROUTINE FFN(V)
REAL V

WRITE(*,*) 'FORTRAN FUNCTION V=',V

RETURN
END

#define ffn ffn_

extern "C" { void ffn(float &v); }
//extern void cfn(float);
extern "C" { void cfn(float);}
main()
{
float v;
v=3.0;
cfn(1.0);
ffn(v);
}

OPT = -O2 CXX = g++ CC = gcc CXXFLAGS = -Wall -fPIC -DR__GLIBC $(EXTRA_CXXFLAGS) CFLAGS = -Wall -fPIC -DR__GLIBC $(EXTRA_CFLAGS) # Linker: LD = g++ LDFLAGS = $(OPT) $(EXTRA_LDFLAGS) SOFLAGS = -shared -Wl,-soname, SOEXT = so SYSLIBS = -lm -ldl -rdynamic XLIBS = -L/usr/X11R6/lib -lX11 -lXpm CILIBS = -lm -ldl -rdynamic CRYPTLIBS = -lcrypt THREAD = -lpthread # Fortran: F77 = g77 F77FLAGS = $(OPT) F77LIBS = -lg2c

.SUFFIXES: .cxx

%.o: %.cxx
$(CXX) $(OPT) $(CXXFLAGS) -c $<

%.o: %.c
$(CC) $(OPT) $(CFLAGS) -c $<

%.o: %.f
ifeq ($(F77),f2c)
f2c -a -A $<
$(CC) $(OPT) $(CFLAGS) -c $*.c
else
$(F77) $(F77FLAGS) -c $<
endif

OBJS= main.o cfn.o ffn.o

all: $(OBJS)
$(LD) $(LDFLAGS) $(OBJS) -o mixed.exe $(F77LIBS)

위의 Makefile에서 볼 수 있듯이 .c 는 gcc 로 컴파일을 하고, .f 는 g77, .cxx 는 g++ 로
컴파일을 하도록 하였다. main 함수에서는 ffn 와 cfn을 호출하는데 cfn 의 경우 단순히
extern "C" 로 함수를 선언해 주었지만, ffn의 경우 ffn 대신 ffn_ 으로 재정의해서 extern
"C" 로 선언한 것을 볼 수 있다. 또한 c와 c++에서는 변수전달이 기본적으로 변수자체가 전
달되는 것이 아니라 값이 전달되지만, FORTRAN의 경우 변수자체가 전달된다. c++에서 변
수자체를 인수로 전달할 수 있는데, 이것은 위와 같이 참조 &를 사용하면 된다..

2. COMMON 블록의 처리
FORTRAN COMMON BLOCK과 C++ 클로벌 변수와 데이터를 공유하는 것도 기본적으로
는 함수의 경우와 유사하다. FORTRAN COMMNOM 블록을 설정한 경우 이 블록의 시작
주소를 저장하기 위해 COMMON 블록의 이름을 변수이름으로 하는 전역변수가 설정된다.
함수의 경우와 마찬가지로 g77의 경우 변수이름은 소문자에 underbar 가 붙게 된다.
common 블록의 경우 연속된 메모리 영역을 차지하게 되므로 이것은 c나 c++의 구조체로
대신설정 하면된다.( c++의 경우는 구조체가 없고 클라스 객체만이 존재한다. 따라서 struct
로 선언된 경우도 실제로는 public 객체일 뿐이다.)
먼저 COMMON 블록이 정의된 FORTRAN 코드의 함수를 다음과 같이 작성한다.
SUBROUTINE FFN2()
COMMON/DATAS/DATA1,DATA2,DATA3

WRITE(*,*) 'DATA=',DATA1,DATA2
DATA3=DATA1+DATA2

RETURN
END

다음으로 c++에서 이 common 블록과 함수에 접근하기 위해 FFN과 마찬가지로 FFN2
와 DATAS를 다음과 같이 정의 설정한다.

extern "C" void ffn2();
#define ffn2 ffn2_
#define DATAS datas_
그리고 DATAS를 다음과 같은 구조체로 선언해 준다.
extern "C"
{
typedef struct{
float data1,data2,data3;
}common_test ;
extern common_test DATAS;
}

이제 이 구조체 값을 설정해서 이 값이 FORTRAN common 블록에 어떻게 작용하는지 다
음과 같은 코드를 작성한다.
main()
{
DATAS.data1=1.0;
DATAS.data2=2.0;

ffn2();
cout << "sum=" << DATAS.data3 << endl;
}

3. 문자열을 인수로 갖는 함수

C(C++) 와 FORTRAN 은 문자열 인수를 ㅊ퍼리;하는 방법이 다르다.(같은 FORTRAN의
경우라도 컴파일러에 따라 함수에 문자열을 전달하는 방법에 차이가 있다.) fortran에서는
문자열을 전달할 때 자체의 문자열 데이터뿐 아니라 전달되는 문자열의 크기를 필요로 하
는데, g77의 경우 문자열과 일반변수를 같이 전달하는 경우 문자열의 길이에 관한 정보는
인수의 뒷부분에 한꺼번에 순서대로 전달한다. 이것은 예제를 통해 이해하는 것이 쉽기 ㄸ
문에 다음과 같은 문자열과 일반변수를 같이 같는 fortran 서브루틴이 있다고 가정하자
SUBROUTINE FFN3(C1,C2,I1,F1)
CHARACTER*20 C1,C2
INTEGER I1
REAL F1

WRITE(*,*) C1,C2,I1,F1

RETURN
END

이제 C++에서 이 함수를 사용하기 위한 과정을 살펴보자. 앞에서 설명한대로 먼저 함수이
름을 소문자 underbar를 같도록 다음과 같이 정의한다.
#define ffn3 ffn3_
다음으로 이 함수이름이 컴파일과정에서 decoration 되지 않도록 extern "C"를 선언한다.
그런데 이 때 함수의 인수로 문자열이 있기 때문에 다음과 같이 문자열 포인터뿐 아니라 문
자열의 길이정보를 추가로 전달해야 한다.
extern "C" { void ffn3(const char*,const char*,int &, float &, const int,const int);}
이제 이 함수를 호출하도록 다음과 같이 코딩해보아라.

char c1[20],c2[20];
for(int i;i<20;i++){ c1[i]=0;c2[i]=0;}
sprintf(c1,"this is");
sprintf(c2,"mixed language test");


ffn3(c1,c2,3,4.0,strlen(c1),strlen(c2)) ;

익명 사용자의 이미지

죄송합니다.
아래에 c 에서 FORTRAN 을 호출하는 방법에 답장을 달려구 했는데,
본문에 답장이 되어버렸네요

익명 사용자의 이미지

C 에서 포트란으로 짠 함수를 호출할수가 있었군요.

개인적으로 포트란 쓸일은 거의 없지만 .
꽤 유용한 정보같습니다.

익명 사용자의 이미지

좋은 정보 감사합니다....

익명 사용자의 이미지

SPICE라는 회로수준의 시뮬레이션 툴이 있습니다.. 수백만 X 수백만 정도의 sparce matrix를 다루기도 하고.. 반도체 시뮬레이션뿐 아니라 화학, 물리, 사회학등 sparce matrix로 모델링할 수있다면 다 쓰이고 있습니다...
SPICE는 변종이 많은데....
시작은 대학 4학년 과목의 컴프로젝트로 시작했습니다.. 포트란으로 처음 개발되어서.. 100% 완벽하게 C로 포팅된 버젼도 있습니다..
저도 C로된 SPICE3가져다가 컴파일해서 썼는데.. 이 넘 내부 구조가 장난아니죠...
이번 학기때 SPICE 내부 알고리듬에 관해서 배웠는데... 만든 사람의 엄청난 노동에 찬사를 보내고 싶은 마은이 들더군요...
이 과목 가르쳐주신 교수님이 SPICE를 텀프로젝트로 내주신 그 교수님에게서 박사 지도를 받으셔서 그런지 잘 알고 계시더군요..
HSPICE같은 경우 코어는 아직도 포트란이라더군요.. C와 포트란으로 크로스 링크해서 만든다더군요..
또 그 교수님이 미국 모토롤라사에서 파워칩을 설계하시다가 오셨는데...
모토롤라의 MSPICE같은 경우 C인데.. 소수만 26만 라인 정도 된다고 하더군요... 당시 개발자가 수십명 있었는데.. 어느 누구도 전체 구조를 모르고 있었다고 하시더라구요..
아주 흥미진진 했었습니다...

익명 사용자의 이미지

>> HSPICE같은 경우 코어는 아직도 포트란이라더군요.. C와 포트란으로 크로스 링크해서 만든다더군요..

혹시 C 에서 포트란 루틴을 호출하는 것이 가능할까요...
아시는 분 참고 링크라도 좀...

익명 사용자의 이미지

스파이스로 화학, 물리, 사회학 시뮬레이션을 한다는 이야기는 금시초문이네요. 스파이스2 까지가 아마 포트란이었고 3로 넘어가면서 C 로 개발되었을 것입니다. 스파이스로 시뮬레이션 하면 시간이 많이 걸려서 요즘에는 근사적으로 구하는 툴을 개발하는 회사들이 많더군요...

익명 사용자의 이미지

코어가 같다는 거죠.....
어파치 어떤 분야이던 간에 스파스 매트릭스로 모델링이 된다면 거기서 부터 푸는 방식은 동일 합니다... SPICE의 코어를 가져다가 문제를 푼다는 거죠..
물론 스파이스 자체를 가져다가 쓰지는 않죠..
스파이스에 쓰인 알고리듬이 느린건 사실이죠.. 요샌 AWE같은 방법도 나와서 거의 천배정도 빠르게 가능하다더군요.. AWE 처음 발명한 사람이 SPICE를 텀 프로젝트로 내줬던 필라지라는 교수인데... 아마 스파이스에도 이 AWE기법이 적용되겠죠...

익명 사용자의 이미지

스파이스는 미분 방정식을 푸는 것으로 알고 있는데 미방을 풀기 위해서 희소행렬로 모델링 하는 방식을 취하는 문제라면 동일하게 풀 수 있겠죠. 단지 희소행렬로 모델링 된다고 푸는 방식이 동일하다면 글쎄.... -_-;

익명 사용자의 이미지

위에 쓰신 분 글 중에서 sparce matrix란 용어가 나오는데...
이거 오타 아닙니다.^^;;

익명 사용자의 이미지

Watcom 포트란 컴팔러...어떤가요?
Maple같은 프로그램도 C나 C++로 짜여진거겠죠?

익명 사용자의 이미지

Watcom에서 FORTRAN도 만드나요?
오래전에 Watcom C/C++이 인기였었던 적은 있었는데.

하기사 누가 나에게 1억만 투자해준다면 2년안에 FORTRAN 컴파일러 하나 만들어 드리겠습니다마는.
요즘은 컴파일러 기술이 공개된게 많아서리.

익명 사용자의 이미지

만들었었죠...

Watcom C/C++보다 더 유명했던게 WATFIV 등등...

다른 컴팔러보다 월등히 성능이 좋았다구 하더라구요...

물론 지금은 없어졌지만...

익명 사용자의 이미지

여기 가보세요.

http://www.openwatcom.org/

익명 사용자의 이미지

우와~~~~~~

너무 좋다!!

빨리 open이 되었음 좋겠네요!!

익명 사용자의 이미지

마져... Maple은 안쓰시나요?

익명 사용자의 이미지

저는 몇십년 살아오다가 이제 수학의 중요함을 깨우치고 ㅋㅋㅋ 매스매티카를 공부하고 있습니다.. 헤헤헤

근데 Mathematica 와 Matlab 에는 차이가 있나요??

익명 사용자의 이미지

매스매티카는 기호적으로 처리를 해줍니다.
수치 넣고 해석하는 수치해석은 구현이 그다지 어렵지 않죠,
그런데 매스매티카는 수치 해석을 하는게 아니고 기호연산 즉 진짜 수학을 합니다.

sin(x)*exp(x)
이런 걸 미분하거나 적분합니다.
다항식도 단지 수치 해를 구하는게 아니라 기호적으로 해를 구합니다.
기타 이상한 함수 이름들도 잘 풀어주지요.
그렇다고 수치 해석을 하지 않는것도 아닌데,
Pi를 자릿수 제한 없이 구합니다.
1만자리까지를 본인의 PC에서 몇초(또는 몇분.)만에 해결했었던 기억이 드는군요.
그래픽도 지원되어, 뫼비우스띠처럼 마디가 꼬인 함수도 잘 그려냅니다.
프로그래밍 언어적이기때문에 문서로서의 가치도 있습니다.

수학을 할려면 Matlab보다는 Mathcad가 낫습니다. Matlab는 공학자를 위한 실험 용도입니다.

익명 사용자의 이미지

한마디로 Mathmatica는 수학용이고 Matlab는 공학용입니다.
Mathmatica는 수학적인 문제들 만을 해결하기 위한 프로그램이구 Matlab은 수학 문제 뿐만 아니라 신호처리, 제어등도 할 수 있는 수학 뿐만 아니라 제어쪽도 할 수 있는 프로그램입니다.

익명 사용자의 이미지

매쓰매티카도 공학쪽에서 쓰더군요. 제어쪽은 잘 모르겠습니다만 수치적으로 시뮬레이션하고 계산하고 하는 것들을 종종 봤습니다.

-Rica

익명 사용자의 이미지

저는 예전에 포트란으로 프로그래밍을 했었습니다. 그러다가 나중에 C 로 바꾸었는데, 몇가지 수치해석에서 차이점이 있더군요. 일단 포트란(F77)은 무지 빠릅니다. 그 이유는 주로 단순한 배열의 사용과(단순해서 do loop 가 무지빠릅니다.물론 상용 컴파일러에 따라서는 무지 빠른 가속기가 존재할수도 있습니다.) 더우기 포트란은 프로그램 실행시에 모든 변수에 메모리를 한꺼번에 할당을 해서 시작합니다. 여기에다가 싱글연산과 더블연산을 하는 수학함수가 구별되어 있습니다. 더블연산은 시간이 더 걸리구요.
그러나 C 언어는 동적으로 메모리를 할당합니다. 프로그램 실행중에 함수나 malloc을 했을 때는 시스템에서 메모리를 새로이 할당을 해서 실행하기 때문에 시간이 걸리는 것 같습니다. 그리고 싱글 수학함수가 좀 빈약한 것 같구..
가장 큰 속도 차이는 데이타 타입에서 나옵니다. 포트란은 데이타 타입을 정해진 것만을 사용하는데 반하여 C 에서는 자기가 structure를 만들수 있습니다. 물론 편의상으로 structure 구문이 매우 편리하지만, 속도 면에서는 매우 느립니다. for 문에서 모든 배열의 어떤 특정 structure 값을 알고자 할때에는 stride를 하게 됩니다. continuous 하지 않은 이러한 stride 는 for 문을 가속시키는데 문제가 있습니다. 속도는 한 4배정도(경우에 따라 다르겠지만) 느려지더군요. 단순한 for 문에서요.
그리고 g77의 문제는 잘못된 계산결과(다른 상용 컴파일러에 비해서)가 나온다는데에 있습니다. 물론 문법적인 문제에 있어서 좀 까다롭게 컴파일을 하기때문에 컴파일이 잘 안되는 수가 있습니다. 그렇지만 g77에서의 이러한 문제는 컴파일러문제이기 보다는 실제로 코드가 g77(gcc)에서 요구하는 표준을 따르지 않아서 일경우가 많습니다. 제가 compaq, aix, solaris, gnu 컴파일러를 테스트하고 실제로 수치해석을 해본 결과 본인이 충분히 조심하면 같은 결과를 얻을 수 있습니다. 물론 속도는 상용 컴파일러가 조금 빠르더군요. 그리고 상용 컴파일러는 버퍼(오류에 대한)가 좀 큰 편입니다. 특히 메모리 오버플로우를 잘 커버를 하던데요. 그래서 실제로 코드에 문제가 있을 수 있는데 상용 컴파일러에서는 문제없이 정확히 계산이 됩니다.

이만 잡설이었습니다.

익명 사용자의 이미지

The C++ Programming Language, Third Edition by Bjarne Stroustrup.
에는 다음과 같은 구절이 등장하는군요. 이 토론에 참고가 될만하여 인용해 봅니다.

1.5 Use of C++[notes.use]에 등장하는 구절입니다.

Like C, C++ wasn't specifically designed with numerical computation in mind. However, much numerical, scientific, and engineering computation is done in C++. A major reason for this is that traditional numerical work must often be combined with graphics and with computations relying on data structures that don't fit into the traditional Fortan mold [Budge,1992][Barton,1994]

익명 사용자의 이미지

조금 빗나간 질문이기는 한데..
지금 얘기하는 포트란이 77인가요 아니면 최근(?) 나온 90 혹은 95에대한 얘기인가요? 제가 알기론 포트란 95는 그 속에서 포인터도 되고 그런다던데 (실제로 써보진 못했습니다) 그럼 님들께서 얘기하시는 포트란의 화려한 속도를 어느정도 어느정도까지 얻어낼수 있는가 하는 의문이 드네요..(추측입니다^^)

실제로 포트란의 과거 코드는 거의 77 코드로 제공되고 님들께서 지금 얘기하시는 수치해석용 언어 포트란도 77에 대한 얘기가 아니신지요. 포트란 95의 속도에 대한 얘기를 들어보고 싶은데요..

호진이의 이미지

일반적으로 f90넘어 오면서 더 빨라졌습니다. f77전용 컴파일러는 더 이상 최적화를 하지 않기 때문이라고 생각합니다. 아래 지적되어 있는데 f90/95는 c와 c++ 중간정도를 점하고 있다고 생각하면 됩니다. 심지어 제한적인 객체지향 개념도 사용할 수 있고 스크립트 개념도 들어가있죠. 숙제할 때 포트란으로 윈도우 프로그램도 짜봤습니다.

예전에 짠 코드를 보면 f77에서는 처음에 커다란 character배열을 잡고 컴파일러의 경고에도 불구하고 사용자 스스로 잘라서 사용하는 식의 메모리 관리를 합니다. 이거 그렇게 불편하지는 않는데 씨와 비교해서는 바보같다는 생각이 듭니다. 이런 문제를 해결하기 위해서 f90/95에서 메모리를 동적으로 할당하게 하였는데 씨의 배열과 다른 점은 각자 자기 배열의 크기가 얼마인지 알고 있다는 것입니다. c++의 수치해석용 vararray와 닮았다고 해야할까요. 역시 다루는 문제가 씨와 다르기 때문에 크 오버헤드가 걸린다고 생각지는 않습니다만 아무튼 매우 간단한 반면 연산이 많은 문제(사용자의 최적화 여지가 별로 없는)를 씨와 똑같이 포트란 코드를 이용해서 돌려봐도 더 빠릅니다.

호진이의 이미지

꼭 쓰고 나면 하나씩 내용을 빼먹는데 어떤 분은 20내지 30퍼센트 빠른것이 대수냐 좀더 빠른 컴퓨터 사면 되지라고 말씀하시는데 부분적으로 맞는 말이지만 사실 꼭 그렇지는 않습니다. 최적화 문제를 풀때 최적화 각각의 축차별로 유한 요소법을 몇번씩 풀기 때문에 때론 몇시간에서 몇일 걸리는 문제도 있는데 체감적으로 세시간 걸리는 것과 두시간 걸리는 것, 삼일 걸리는 것과 이틀 걸리는 것은 확연한 차이가 나죠. 그리고 많은 계산을 요구하는 문제를 풀때 업그레이드를 하는 방법도 있지만 차라리 크레이 계정을 열어서 계산합니다. 클럭이 바로 돈인거 아시죠? 빠를 수록 싸게 먹힙니다.

익명 사용자의 이미지

저는 수치해석을 잘 모르고 벤치마크도 안해봐서 진짜 겁쟁이입니다.
제 짧은 소견으로는 Fortran과 C는 비교의 대상이 되지만 C++은 안되지 않나 생각됩니다. 왜냐하면 아래에서 어느분이 지적하신 바와 같이 당연히 C++은 속도를 최적화시키는 코드가 아닙니다. 편의성은 증대하죠. C의 문법에도 그런거 많이 있습니다.제 생각에는 C 언어를 이용해서 Fortran과 같은 생각으로 ( 당연히 C다운 문법으로 ) 프로그램을 짜면 성능이 더 나으면 낫지 느리지는 않을거라 생각합니다.
무슨 말이냐하면 언어적인 또는 문법적인 차이에서 보면 당연히 C가 우월하다고 봅니다. 범용언어이므로 당연히 훨씬 유연하고 더 확장되어 있겠죠. 하지만 그런 부분은 컴파일러에 의존하다 보니 범용성이라는 한계를 넘어서지 못하는 것이라고 생각됩니다. 예를 들어 C에서 제공하는 재귀호출은 여러가지 편리한 점이 있습니다만 재귀 호출을 백만번 한다든지 하면 그 안에서 함수 호출할 때 마다 스택 생기고 또 변수 선언되고 하는 부분들이 모두 오버해드로 작용할 수 있다는 것이죠. DB에서 쿼리 커스트마이징 하는 것과 비슷하다고 하겠습니다. 편리한 것 같아 보이는 부분들을 쓰다보면 쓸데없는 오버해드 또는 필수적인 부가부분이 자꾸 들어가게 되는 것이죠. 그럼 당연히 뼈대만 있는 또는 베이직 처럼 길게 늘어쓴 C답지 않은 C코드보다 당연히 느리게 되지 않겠습니까? 즉 언어적인 차이에서 C는 편리함들이 있기 때문에 더 느리게 되는 부분들이 있다는 것이죠. 하지만 C는 잘 아시다시피 로우레벨 언어적인 측면도 많지 않습니까? 그러니 당연히 그런 부분을 활용하면 FORTRAN보다 빠르거나 같을수는 있지 느릴 수는 없다고 봅니다. 느린것은 옵티마이징이 안된것이라고 봅니다. FORTRAN 라이브러리는 당연히 그 속도로 지금까지 진화해 왔는데 그걸 C로 그냥 평범하게 짜서 따라 잡는다는건 FORTRAN개발자를 무시하는 처사라고 생각합니다. 단지 아직 개발된 또는 최적화된 C로 된 라이브러리가 너무너무 적다는 이유 때문에 제대로 패키지화 되지 못한거라고 생각됩니다. 이상 허접한 제 개인 생각입니다.

사족 : C에서는 인라인 어셈블러로도 코딩할 수 있는데 어떻게 C로 짠게 FORTRAN보다 느릴수 있죠? FORTRAN은 기계어가 아닌 별개의 코드로 링크되나요?

이경훈의 이미지

찬찬히 아랫글들 읽어보세요.
아니면 웹서치로 관련된 문서나 밴치마킹
결과를 보시던지요...
(한번 직접 test해보시는게 잴 좋겠습니다.^^)

익명 사용자의 이미지

아랫글들을 제대로 읽어보시지 않은 것 같군요.

수치해석 분야에서 포트란이 C보다 빠른 것은 여러가지 이유가 있습니다.
아랫글들을 제가 간단히 정리하고 부연 설명을 하겠습니다.

1) C는 범용언어이고, 포트란은 수치해석 전용언어입니다.
(물론 범용으로 쓸 수는 있지만요.)
컴파일러 자체에서 수치해석을 위한 최적화를 합니다.

2) 포트란은 '최초'의 고급언어입니다.
포트란 이전에는 기계어/어셈블리 밖에는 없었습니다.
포트란 언어 설계자들이 언어를 설계한 방법은,
어셈블리 프로그램에서 자주 사용되는 여러가지 코드의 패턴들을
하나의 명령어로 축약하는 아이디어를 사용한 것입니다.
(현재의 디자인 패턴의 아이디어와도 유사하지요.)

사실상 대부분의 포트란 명령어는
어셈블리 코드의 몇 줄과 거의 1:1로 대응되는 간단한 구조를 가지고 있습니다.
그만큼 최적화된 컴파일러를 만드는 게
복잡한 C/C++의 경우보다 훨씬 쉽지요.

3) C는 모든 코드가 함수 호출입니다.
모든 코드마다 함수 파라미터와 지역변수를 스택에 push/pop하는 오버헤드가 있다는 얘기입니다.
반면에, 포트란은 그런 개념이 아예 없는 서브루틴의 개념입니다.
베이직의 GOSUB ... RETURN과 유사하지요.
X86 어셈블리라면 현재 CS:IP를 기억시켜둔 후, JMP로 서브루틴이 있는 코드에 갔다가 돌아올 때는 기억시켜둔 CS:IP로 되돌아오는 기능 밖에는 없습니다.
때문에 지역변수의 개념도 없고 오로지 전역변수 밖에는 없습니다.
이런 방식은 버그 발생 가능성도 높고 소스 코드의 유지 보수도 어렵지만,
(이런 문제 때문에 포트란이 전산학의 발전을 10년 이상 후퇴시켰다는
비판이 있습니다. -_-;;)
C와 같은 오버헤드가 전혀 없기 때문에 속도는 엄청 빠릅니다.

그리고 포트란과 C는 비교의 대상이 되고, C++이 비교의 대상이 안된다는 글을 쓰셨는데, 오히려 그 반대입니다!
C++로 코드 레벨에서 최적화를 하면 오히려 C보다 훨씬 빠르고,
포트란의 속도에 근접하거나 능가할 수도 있습니다.

C언어의 숙명적 한계인 함수 호출 오버헤드를,
C++은 인라이닝(inlining)과 템플릿을 사용하여 해결할 수 있습니다.
특히 C에서 함수 포인터를 사용하는 코드(예, qsort, bsearch 등)
속도도 느리고, 인라이닝이 불가능하지만,
함수 객체(function object)로 바꾸면 이것조차도 인라이닝을 할 수 있습니다.
그래서 C++/STL의 sort 알고리듬이 C의 qsort 보다 67000배나 빠릅니다!
(출처: Effective STL)

아랫글들에 많이 소개된 Blitz++ 라이브러리도
C++의 템플릿을 intensive하게 사용해서
포트란의 속도에 근접하고 있습니다.

익명 사용자의 이미지

겁쟁이가 쓴 글을 찬찬히 읽어보지 않으셨군요.
태생적인 한계라고 지적하셨는데 제가 말씀 드리고 싶은것은 언어적인 한계는 별로 중요하지 않다는 것입니다. 그럼 포트란으로 만든 함수가 기계어나 어셈블리어로 짠 함수보다 빠를수 있다는 겁니까?
C++을 잘 하지는 못하지만 C와 C++은 당연히 다른 언어이며 C의 qsort가 C++의 sort기능보다 느리다는 지적은 옳지 않습니다.
그럼 C++로 qsort 함수를 새로 작성한 것과 기존의 C의 qsort를 비교했을때 과연 C++가 여전히 빠르겠습니까? C++로 작성했건 C로 작성했건 첫번째로 중요한것은 속도에 대한 배려라는 것입니다. 알고리즘이 형편없으면 아무리 좋은 언어라도 소용없다는 점을 지적하고 싶군요.

말씀 하신 중에서
>> 1) C는 범용언어이고, 포트란은 수치해석 전용언어입니다.
>> (물론 범용으로 쓸 수는 있지만요.)
>> 컴파일러 자체에서 수치해석을 위한 최적화를 합니다.

수치해석을 위한 최적화를 한다는 것은 컴파일러가 얼마나 지원하느냐의 문제인것 같습니다. C로도 속도에 대한 옵티마이저 가능합니다.

>> 2) 포트란은 '최초'의 고급언어입니다.
>> 포트란 이전에는 기계어/어셈블리 밖에는 없었습니다.
>> 포트란 언어 설계자들이 언어를 설계한 방법은,
>> 어셈블리 프로그램에서 자주 사용되는 여러가지 코드의 패턴들을
>> 하나의 명령어로 축약하는 아이디어를 사용한 것입니다.
>> (현재의 디자인 패턴의 아이디어와도 유사하지요.)

C언어의 탄생설화를 보시면 C도 어셈블리와 상당히 매치 됩니다. 태생적으로 그랬죠. 그리고 C언어 컴파일해서 디버깅 할때 보면 많이 비슷합니다. 특히 속도에 최적화 시키면요.

>> 3) C는 모든 코드가 함수 호출입니다.
>> 모든 코드마다 함수 파라미터와 지역변수를 스택에 push/pop하는 오버헤드
>> 가 있다는 얘기입니다

이 부분은 윗글에서 제가 지적한 바와 같습니다. C언어로도 이런 함수 호출에 대한 오버헤드 줄여가면서 코딩할 수 있습니다. 물론 C언어 답지 않죠. 하지만 어느 정도의 편의성만 훼손하고도 C로된 라이브러리 구축할 수 있다고 생각합니다. C로도 베이직 처럼 프로그램 짜고 코볼처럼도 짤 수 있습니다.
네트웍 프로그램에서 속도가 가끔 문제될 때는 일부러 thread 안쓰고 재귀호출 절대 안쓰고 다차원 배열 안쓰고 코드를 최적화 하는 경우가 있습니다. 보기 어려워지고 디버깅 힘들어지지만 확실히 속도가 빨라집니다.

>> 그리고 포트란과 C는 비교의 대상이 되고, C++이 비교의 대상이 안된다는
>> 글을 쓰셨는데, 오히려 그 반대입니다!
>> C++로 코드 레벨에서 최적화를 하면 오히려 C보다 훨씬 빠르고,
>> 포트란의 속도에 근접하거나 능가할 수도 있습니다.
>> C언어의 숙명적 한계인 함수 호출 오버헤드를,
>> C++은 인라이닝(inlining)과 템플릿을 사용하여 해결할 수 있습니다.
>> 특히 C에서 함수 포인터를 사용하는 코드(예, qsort, bsearch 등)
>> 속도도 느리고, 인라이닝이 불가능하지만,
>> 함수 객체(function object)로 바꾸면 이것조차도 인라이닝을 할 수 있습니>> 다.
>> 그래서 C++/STL의 sort 알고리듬이 C의 qsort 보다 67000배나 빠릅니다!
>> (출처: Effective STL)

지엽적인 문제입니다. qsort 라이브러리는 속도에 대한 고려보다 일반성 즉 범용성에 대한 고려입니다. C++이 먼저나오고 C가 나중에 나왔다면 당연히 더 빠른 sort 알고리즘이 연구되어 적용되었겠죠.
제가 말씀드리는 C로 된 수치해석용 라이브리는 기존의 C 라이브러리만을 이용하는 라이브러리가 아닌 수치해석을 위한 새로 개발될 라이브러리를 의미합니다. 즉 속도에 최적화를 둔 범용성을 생각하지 않는 라이브러리를 개발하면 포트란의 속도도 따라잡을 수 있으며 C의 장점을 살릴수 있다는 생각에 쓴 글이었습니다.

제가 아는 지식으로는 C++은 속도를 빠르게 할 수는 있겠지만 C++은 과학 계산용도 아니고 속도 최적화 용도 아니고 C의 속도 빠름 버전도 아닌것으로 알고 있습니다. 단순화 시켜 말하면 아마 유지보수의 편리성을 강조한 프로그램(?) 정도 되지 않겠습니까?

cedar_의 이미지

STL에서 알고리듬(container)이라는 용어는,
함수의 인자로 컨테이너(container) 자체가 아니라
반복자(iterator)를 인자로 갖는 일종의 '함수'를 말하는 겁니다.

STL의 sort와 stdlib.h의 qsort 내부의 알고리듬 구현의 차이로
속도 차이가 나는 것은 아닙니다.

함수 포인터대신 함수 객체를 사용해서 인라이닝을 가능케 했기 때문에 그런겁니다.

참고로 gcc나 Borland C++Builder 6는 SGI STL을 사용합니다.
SGI STL의 sort 알고리듬(다시 한번 말하지만 이건 '함수'를 말합니다.)은
퀵소트(quicksort)를 개선한 인트로소트(introsort, introspective sorting)를 사용합니다.
퀵소트는 최악의 경우에 O(N^2)가 되지만,
인트로소트는 최악의 경우에도 O(N log N)을 유지합니다.

인트로소트 알고리듬에 대해 자세히 알고 싶으신 분은
다음 논문을 참고하세요.

D. R. Musser, "Introspective sorting and selection algorithms.", Software Practice and Experience, 8:983-993, 1997

cedar_의 이미지

앗, 첫줄에 오타입니다.
알고리듬(algorithm)입니다.

참고로 algorithm의 한글 표기를 알고리'즘'으로 쓰는 사람들이 많은데,
th/ð/의 발음은 '즈'가 아니라(일본식 발음의 영향인듯) '드'이므로
알고리'듬'이 맞습니다.
사실 정확한 영어발음대로라면 '앨거리듬'이 맞지요.

익명 사용자의 이미지

1) C는 범용 언어이기 때문에 여러가지 상황에 대한 대처를 더 해줘야 합니다. 그리고 그런 점에서 '단순한' 포트란보다 몇가지 오버헤드가 더 생기게 되는 것이죠. C라고 만능이 아닙니다.

2) 어느정도의 편의성... 좀 극단적으로 말하자만 프로그래밍 언어는 타이핑량을 줄이는 방법으로 발전이 되어 왔습니다. 님께서 하시는 말씀은 '베이직으로도 못할거 없다'고 주장하는 것과 다를 것이 없습니다. peek, pork로 윈도우즈 개발하시렵니까? -_-;

3) C++/STL의 qsort 알고리즘이나 C의 qsort의 알고리즘이나 똑같습니다. 뭔가 '알고리즘'이라는 용어에 대해 잘못 알고 계신 거 같군요. (아니면 지난 몇십년 동안 '퀵소트 알고리즘'에 뭔가 변화라도 있었던 겁니까? -_-;)

익명 사용자의 이미지

2번에서 혹시 Apple 시절 프로그래밍 얘기라면 peek, pork가 아니라 peek, poke입니다.. 딴지였음..

익명 사용자의 이미지

GW-BASIC 책 본지가 너무 오래되서... 어쨌거나 지적 감사합니다. 한해 만용운-_-;

익명 사용자의 이미지

C++/STL 의 sort 알고리즘이 qsort 보다 정말로 67000배나 빠른가요?
인라인이라는게,, 인라인 어셈블러는 당연히 아니겠죠.??-_-;;

그리고 stdlib.h 안에 있는 qsort() 말씀하시는 거 맞죠?
67000 배라.. 가능한가요?
몰라서 이렇게 답장 남기는 것인데,,
좀 믿기지가 않네요..
URL이라도 있으면 좀 걸어주셨으면 합니다..
공정한 비교를 했나 해서요..

cedar_의 이미지

위에도 썼지만, 출처는 Scott Meyers의 'Effective STL'의 Item 46입니다.
인포북 번역판의 경우 299페이지입니다.

익명 사용자의 이미지

"C언어의 숙명적 한계인 함수 호출 오버헤드" 라고 그러셨는데, C 도
인라이닝을 사용할 수 있습니다.

C++/STL의 sort 루틴이 C의 qsort 보다 67000배나 빠른것은 언어의 구조적인 문제라기 보다는 STL 만드는 사람들이 속도에 주안점을 두고 인라이닝을 잘 활용한것이고, qsort 는 그 만큼 활용을 안한 루틴이기 때문입니다.

C 도 인라이닝을 잘 활용한다면 그만큼 빠른 루틴을 만들 수 있습니다.

약간 주제랑 어긋나서 죄송합니다.

익명 사용자의 이미지

인라이닝 함수를 C에서도 지원하는 가요? C++에서 추가된 기능인줄 알았는데 그렇다면 도움이 될만한 예제같은게 있을까요?

익명 사용자의 이미지

gcc에 보면 모든 함수 호출을 가능한 한 인라인으로 바꾸는 옵션이 있습니다.
그러나 함수 포인터와 재귀 호출의 경우는
당연히 인라인 변환이 불가능하지요.

익명 사용자의 이미지

그러게요 아마도 macro를 말씀하신 거 같은데요, 아니면 짧은 함수의 경우 컴파일러 차원에서 inlining을 구현해주는 것을 말씀하신 것 같기도 하구요.

하지만, C에서 그런 기능을 활용하손 치더라도 그렇게 구현한 qsort는 C++에서 구현된 sort에 비해 엄청난 핸디캡을 지닙니다. 바로 일반성이 없어진다는 것이죠. macro나 컴파일러 차원에서의 inlining으로 qsort의 속도를 향상시킨다면 그것은 결국 compare 하는 function이 하나로 고정된 qsort를 의미하는 것이고 그럼 일반적인 qsort 함수의 의미가 없어지지 않을까요?

익명 사용자의 이미지

매크로라면 위험한 습관이 될지도 모르겠는데요 :)

익명 사용자의 이미지

Blitz를 조금 사용해봤는데 그쪽 벤치 마크에는 포트란과 비슷한 빠르기를 보인다고 하는데 저뿐만 아니라 많은 사람의 경험에 의하면 그렇지 못하다는 결론이 나더군요. 또한 컴파일할 때 엄청난 시간을 요구합니다. 그럼에도 Blitz library를 조금이라도 열어보면 정말 c++를 이렇게 까지 예술로 승화할 수 있구나 하는 생각이 듭니다. 좋은 느낌 나쁜 느낌이 교차했는데 이렇게 복잡한 것을 보며 무엇인가 잘 못되어가고 있다는 느낌이 강했습니다. 어쨌거나 한동안 개발이 안되고 있습니다.

익명 사용자의 이미지

미묘한 속도차이란 것이...

A가 B보다 0.1% 빠르다고 가정

B에서 1시간정도 연산해야 한다면 (약 3600초)
A에서 0.999시간정도 (약 3596초)

B에서 하루정도 연산해야 한다면 (약 1440분)
A에서 0.999일정도 (약 1438분)

B에서 한달정도 연산해야 한다면 (약 720시간)
A에서 0.999달정도 (약 719시간)

B에서 6개월정도 연산해야 한다면 (약 4320시간)
A에서 5.994개월정도 (약 4315시간)

음... 6개월정도 돌리니 겨우 연산속도 0.1% 차이나는데 5시간가량 차이나는군요. -_-;;;

익명 사용자의 이미지

역시 자바로 수치해석을 하는 미친놈입니다.

자바가 물론 느려 터집니다.
그런데 말씀하신 것 처럼 "같이" 일할 때는
그놈이 좀 쓸만 하다는거죠.

느리다고하는데 오브젝트 생성이 오버헤드가 크다는것을 말하는거겠죠? 그래서 수치해석을 할때는 오브젝트의 최대 개수를 미리 산출해서
resizing이 일어나지 않게하고 새로운 오브젝트
생성을 최대로 억제해서 하고있습니다.
충분히 만족할 만한 결과를 얻고있습니다.

물론 씨나 포트란에 비해 느리겠진만 충분히 쓸만합니다.

-영희-

익명 사용자의 이미지

역시 자바로 수치해석을 하는 미친놈입니다.

자바가 물론 느려 터집니다.
그런데 말씀하신 것 처럼 "같이" 일할 때는
그놈이 좀 쓸만 하다는거죠.

느리다고하는데 오브젝트 생성이 오버헤드가 크다는것을 말하는거겠죠? 그래서 수치해석을 할때는 오브젝트의 최대 개수를 미리 산출해서
resizing이 일어나지 않게하고 새로운 오브젝트
생성을 최대로 억제해서 하고있습니다.
충분히 만족할 만한 결과를 얻고있습니다.

물론 씨나 포트란에 비해 느리겠진만 충분히 쓸만합니다.

익명 사용자의 이미지

대규모 프로젝트라고 위에 적혀있습니다.
대규모 프로젝트에 충분히 쓸만한게 중요한것이 아니지 않습니까?

익명 사용자의 이미지

그 대규모 라는게 얼마나 대규모인가요?
하나 만드는데 1~2년 걸리구 한번 테스트 하는데 1달 걸리구
문제 없는지 테스트 하려면 2년 걸리는 그런걸 말하는건가요?
그럼 결국 제대로 되서 테스트 하는데까지 걸린 시간은 얼마나 되는건가요?

그렇다면 한번 만든것을 다시 사용하려는 사람은
그 코드를 다 뜯어 보는데 역시 엄청 많은 시간이 걸릴거 같군요.

차라리 그정도 고급인력이 그 프로그램 만들지 말고 좀더 깔끔한 알고리즘을
생각하고 그분에겐 좀더 비싼 컴퓨터를 사주는게 어떨까요?

20~30프로 성능차라구요? 컴퓨터 한대 더 사주는게 편할거 같네요.

-영희-

익명 사용자의 이미지

영희님 글쎄요. 대규모 프로젝트가 당신이 발주한거라면

자바로 짜두 되구요. ㅋㅋㅋ

익명 사용자의 이미지

위에 호진이 님이 답변을 달아주셨군요.

익명 사용자의 이미지

>> 왜 그렇게 하시죠?
>> 자바로 꼭 그렇게까지 해야할만큼 장점이 있나요?

익명 사용자의 이미지

서비스팩 다 까니가 그나마 조금은 낫던데요.

익명 사용자의 이미지

헉... 실수로 답장을 이상한데 올렸군요. 죄송합니다.

logout_의 이미지

수치해석 분야는 딜레마가 많습니다. 저는 수치해석을 잘 하지는 못합니다만...

우선 수치해석 프로그래밍을 해 보시면 알겠지만, 수치해석 알고리즘 자체는 복잡합니다만 구현은 단순 노가다 그 자체입니다. 행렬 계산하는데 별 수가 있겠습니까. 무조건 루프 몇번 돌리면서 무식하게 해야죠. :)

루프를 몇번 돌리다보면 아무래도 함수를 이용해서 좀 일반화된 프로그래밍을 하고 싶어지겠죠. 이쯤되면 수치해석 라이브러리를 쓰게 됩니다. 썩 깔끔한 것은 아니지만 객체지향의 개념이 없이도 충분히 쓸만하죠.

그리고 수치해석에는 속도라는 요소가 거의 결정적으로 작용합니다. 아무리 쓰기 좋고 사용자가 이해하기 쉬운 솔루션이 있어도 속도가 느리면 수치해석쪽에서는 대접을 못받습니다. 실제, 포트란과 씨의 속도차가 나봐야 얼마 나겠습니까... 그런데도 이 '얼마 아닌' 속도차이가 크게 체감되어야 하는 곳이 수치해석이라는 분야입니다.

그런데 여기서 좀더 큰 그림을 봅시다. 과연 수치해석쪽에는 객체지향도, 사용자의 편의성도 고려할 필요가 없는 것일까요?

유한요소법(fem)만 보더라도 개념이 복잡합니다. 그런데 이론을 좀 보다보면 이런 거 누가 패키지로 잘 설계해 주면 좋겠다는 생각이 듭니다. 그런데 막상 이미 만들어진 코드를 고쳐서 쓰려고 하면 골치가 아픕니다. 루프의 인덱스 하나만 실수해도 답이 개판으로 나오는 곳이 수치해석이고 알고리즘들끼리 연동이 무척 유기적인 곳이 수치해석입니다. 포트란 코드나 씨코드를 보고 필요한 부분을 떼어 낸다든지 기능을 추가한다든지 하기가 보통 힘든게 아닙니다. 소위 최적화는 진짜 도사들만 할 수 있는게 아닌가 하는 생각까지 들 정도이죠.

그래서 이 동네도 C++이나 기타 방법을 이용해서 객체지향적인, 그래도 포트란보다는 진보적인 개념을 많이 갖고 있는 언어의 특성을 도입할 필요가 있는 겁니다. 언제까지나 빠르다고 포트란만 쓸 수는 없는 것이라는 거죠.

여기에 재미있는 솔루션이 하나 나왔습니다. 바로 매트랩입니다. 매트랩은 다들 알다시피 스크립트 랭귀지입니다. 느립니다. 그래도 매트랩이 성공한 이유는 이렇습니다. 배우기 쉽고 프로그래밍하기 편합니다. 행렬 짜집기는 기본이고 씨나 포트란으로 수십줄 써야 하는 것들이 단 몇줄로 해결됩니다. 툴박스도 기가막히게 만들어 놨습니다. 모르면 툴박스 불러 쓰면 만사 끝입니다. 툴박스도 돈드는게 장난이 아니긴 합니다만. :)

그런데 매트랩의 한계는 이게 범용 언어가 아니라는 점입니다. 매쓰웍스에서 나오는 매트랩이 매트랩 언어 솔루션의 전부입니다. 컴파일링이 요즘은 가능하다고 그러지만 아무래도 속도가 느리다는 단점을 극복하기가 힘이 듭니다. 특히 유한요소법과 같이 메모리와 시피유를 동시에 많이 요구하는 분야에서는 아직도 찬밥 취급을 받습니다. 매트랩으로 유한요소법 프로그래밍을 해보면 씨나 포트란보다 수십배는 쉽게 프로그램을 만들 수 있는데도 말입니다.

논란이 있기는 하지만 매트랩이 수치해석에 새로운 가능성을 열어준 것은 확실합니다. 문제는 매트랩의 장점 --- 배우기 쉽고 쓰기 편하고 툴박스 솔루션이 많은 ---을 어떻게 범용 랭귀지에도 이식할 수 있는가이죠.

제 개인적으로는 python에 관심이 있는데 python에 보면 재미있는 솔루션이 또 있습니다. 다들 아시다시피, python은 처음부터 객체지향을 고려하고 만든 언어입니다. 스크립트 언어이기때문에 다른 언어, 특히 씨나 씨뿔뿔과의 연동도 쉬운 편입니다. 모듈이 지원되기 때문에 매트랩 툴박스와 같은 솔루션을 만들기도 좋습니다. 대표적인 python의 수치해석 솔루션으로는 NumPy가 있습니다. 이건 완전히 씨로 모듈을 짜서 속도를 높였다는군요.

NumPy 메뉴얼을 보면 대단합니다. 거의 매트랩과 별 차이 없는 문법, 여기에 python의 객체지향적 특성까지 추가되어 있습니다. 뭔가 가능성이 보이죠. 잘만하면 매트랩보다 나을수도 있지 않을까...

그 다음은 잘 모르겠습니다. 그 이후로는 제가 전공을 바꾸는 바람에. :)

얘기가 조금 옆으로 샜는데요.... 어쨌든 수치해석에서도 분명히 객체지향쪽의 특성을 살려서 라이브러리 외에 고차원적인 패키지를 많은 사람이 쓸 수 있도록 틀을 짜 줘야 할 필요성이 많이 제기되고 있습니다. 제가 이 토론을 보면서 하나 우려하는 점은, 실상 포트란이나 C 컴파일러의 속도는 궁극적으로 볼 때 큰 문제가 아니라는 겁니다. 막말로, 6개월만 기다려서 새 컴퓨터 사면 예전에 도는데 한나절 걸리던 수치해석 프로그램이 적어도 서너시간은 빨리 돌게 됩니다. 컴파일러 뜯어고쳐 속도 올리느니 그 시간에 아르바이트나 해서 컴퓨터 살 돈 모으는게 나은 것이 현실입니다.

그렇다면 이제는 수치해석도 '어떻게 개발을 쉽게, 빨리 할 수 있는가' 라든가 '만들어진 솔루션을 어떻게 쉽게 재사용 할 수 있는가'에 관심을 기울여야 한다고 봅니다. 십년 이십년 유한요소법 대학원 실험실이 돌아가고 수많은 사람들이 졸업을 해도 거기서 쓸만한 상용코드 하나 안나오는 것이 수치해석입니다.

아직까지 수치해석쪽에 새로운 언어나 기술적인 패러다임은 나오지 않고 있는 것 같습니다. C++쪽이 가장 가능성이 있었으나 알고리듬 배우기 바쁜 수치해석 전공자들이 씨뿔뿔의 어려운 문법과 객체지향의 개념을 도데체 배우려고 하지 않더군요. 솔직히 C로 수치해석 하는 분들도 malloc() 함수의 메모리 할당 개념을 정확히 알고 프로그래밍하시는 분들 드뭅니다.

어쨌든 '속도'라는 요소에 다른 가능성이 상대적으로 많이 무시당하는 분야가 수치해석 쪽입니다. 포트란이 빠르네.... 씨가 빠르네.... 라는 전통적인 속도 논쟁보다 장기적으로 좀 더 수치해석분야 종사자들에게 도움이 될 수 있는 솔루션의 개발쪽으로도 토론이 좀 이루어 졌으면 하는 바램으로 이 글을 써봤습니다. 글이 지나치게 길어져 버렸군요. :)

익명 사용자의 이미지

웬지 하는일이 같은거 같네여.
저는 유한요소법 솔버 코드 짜는일 하는데~
으~ 예전 포트란 코드 보면서 돌아버릴것 같아~
왜 포트란 코드는 변수명을 사람들이 길게 않쓰는겨~

익명 사용자의 이미지

intel fortran compiler for linux가 무료로 배포되고 있더군요(non-commercial license). Fortran 95까지 지원되고, intel home page에서 받을 수 있습니다.

호진이의 이미지

무심코 놓치고 있는 것을 우선 짚고 넘어가지면 indexing문제가 엄청나게 스트레스를 준다는 사실입니다. 저도 C가 더 익숙한 사람인데 전공은 계산 역학/최적화를 합니다. 대부분 수치해석 책을 보면 번호가 1부터 올라갑니다. 유한 요소 법만 생각해봐도 요소의 번호 절점 번호등은 1부터 올라갑니다. 씨로 프로그램할 때 인텍싱을 1로 조정하거나 혹은 하나 더 크게 잡아서 무리 없게 하는 식의 방법은 있지만 때때로 엄청난 혼란을 느낍니다.

속도 상의 문제는 연구실에서 시험을 해본 결과 저도 믿을 수 없는 시간 차이가 나오더군요. 특히 visual fortran 6.0은 느린편이었는데 6.5대가 오면서 갑자기 속도가 빨라졌습니다. 신기하더군요. 물론 아시다시피 visual c는 다소 느린 컴파일러라고 알려져있습니다. 저도 gsl에 코드도 보내보고 씨가 더 편하지만 포트란을 낡은 언어라고 생각하고 우습게 보는 사람들 보면 기가 막힙니다. 포트란 95대가 넘어가면서 씨와 씨++중간쯤의 언어가 되었다고 느껴집니다만. 불행인지 다행인지 포트란을 즐겨 사용하는 분들은 77표준을 중심으로 제한 적인 부분만 90 이상의 기능을 이용합니다.

이제는 가리지 않고 때때로 필요한 것을 선택하여 씁니다. g95프로젝트가 있다는 것은 알고 있는데 아직 쓸만하지 않기 때문에 당장 필요한 포트란 95를 위해서 리눅스를 못쓰고 있습니다. 흑... 결국 cygwin 깔고 대부분 작업을 그 창에서 놀고 있다는~

호진이의 이미지

아참 포트란을 사용해보면서 감탄했던 점은 매트랩과 같은 스크립트 언어를
사용하고 있다는 느낌입니다. 이를 테면 (정확히 예제를 기억이 안나지만)
intary(1:2) 에 각각 10과 20이 들어있다면, 적당한 배열
rary = realary(intary) 식으로 사용하여 realary(10), realary(20) 식의 결과가
바로 rary(1:2)에 들어가는데 이거 엄청나게 편합니다.

익명 사용자의 이미지

또 하나 궁금한 점은.

두 언어간의 성능차가 나는 이유가

언어의 구조적 차이점에서 기인하는 것인지,

아니면 단순히 수학관련 라이브러리들와 FPU등을

이용하는 아키텍쳐 디펜던트 코드의 효율 (즉 일부 부품의 문제로 국한되는) 때문인지도 궁금하네요.

익명 사용자의 이미지

플로팅연산에서 포트란이 다른언어에 비해빠르다고 들었던거 같던데
이게 원인이 아닐까 생각이 드네요.

하도 오래전에 들어서 긴가민가 한데 이에대해 누구 아는사람 없나요?

익명 사용자의 이미지

fottran이나 C모두 CPU레벨에서 보면 어차피 같은 명령어를 사용합니다.
다만 fortran은 하에레벨 언어이므로 자료형을 CPU에 최적화 시킬수 있고 쓸 수 있지만, c는 자료 크기와 속도를 개발자가 절충할 수 있으므로 속도가 떨어질 수 있습니다.

예를들어 c에서 float x[1000]의 자료를 다 합하는 것보다, double y[1000]값을 다 합하는게 더 빠르답니다. 왜냐하면 CPU 내부적으로는 double로 계산된 후 double은 변환없이 연산이 가능하지만, float은 double로 바꾸었다가 연산이 끝나면 다시 float으로 변환하므로 엄청난 오버헤드가 생기죠. (vc++을 이용하면 바로 어셈 코드의 차이를 확인하실 수 있습니다)

지리즈의 이미지

사실 요즘들어서...
제가 사용하는 컴파일러가 과연 신뢰할 수 있는지 자꾸 의심이 갑니다.
(전에 gcc2.96에 관한 글을 올렸던 놈입니다.)

컴파일러에 대한 공부좀 해야되겠내요.

There is no spoon. Neo from the Matrix 1999.

지리즈의 이미지

전 ENTP입니다.

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

이런 글 말고
좀 이제 전산하는 사람도 공부 얘기만 말고
우리 밥 그릇 좀 챙기면 안 되나요

권순선의 이미지

그럼 본인이 스스로 밥그릇 챙기는 것에 대한 글을 한번 올려 보시죠. 가치가 있다고 생각되면 승인하도록 하겠습니다. :-)

그리고 위의 글은 C/C++을 이용한 수치해석과 관계가 없으므로 -1점으로 조정합니다....
--
WTFM :-)

liberta의 이미지

수치해석 코드는 다른 분야가 아닌 과학/공학 계열에서 필요로 하고, 또 그쪽의
개발자들이 작성하죠. 프로그래밍 언어를 설계하고 개발하는 건 컴퓨터 과학 내지
수학자들이구요. 포트란 이후 컴퓨터 과학의 발전이 가져온 게 바로 C/C++언어지만,
컴퓨터 분야의 신기술이 나온다고 해서 일반 과학/공학자들이 그걸 곧바로 채택할
순 없습니다. 두 가지를 다 잘하는 게 얼마나 힘든지는 잘 아시겠죠.. ^^

결국 아직도 수치해석 코드가 포트란으로 되어 있는 부분이 많지만, 이것도 시간이
지나면 보다 객체지향적이라거나, 아무튼 더 진보된 기술이 적용된 코드로 대체될
겁니다. 이건 특별히 과학기술 프로그래머들이 보수적이라거나, 아니면 포트란만이
과학기술 프로그래밍을 하는데 적합하다거나 하는 문제가 아닌 것 같네요. 언어라는
건 과학자나 공학자들이 보기에 하나의 "생소한(?) 도구"일 뿐이고, 새로운 게
나왔다고 해서 하루이틀에 몽땅 갈아치우기에는 그동안 해온 것도 많을 뿐더러
그 도구의 이용법을 익히는 것도 그다지 쉬운 것이 아니라는 거죠. 더 나은 것이라
해서 즉각적으로 통용되기에는 너무 관례의 비중이 크다는 사실의... 한 예일
뿐이죠.

그리고 실제로 과학/공학(적어도 제가 관련된 물리학에 있어서~) 계열에서 기존의
컴퓨터 기술보다 더 나은 기술을 도입하는 추세는 분명히 있습니다. C/C++로
멀쩡히 새로 작성된 코드를 일부러 Fortran으로 옮기는 예는... 혹시 누구
아는 분 있으시면 좀 알려 주세요. ^^ 다음은 이 반대의 예입니다.

* OOPIC - 이론 플라즈마 분야에서 Grid Cell에 초점을 맞춘 시물레이션 방식,
PIC 모델이란 게 있습니다. 플라즈마 물리학에 컴퓨터가 쓰이기 시작한 초창기에
Fortran위주로 작성된 코드들이 있죠. 이것을 C/C++로 다시 작성한 것이 바로
Object-Oriented 'Particles In Cell' 코드며, 실제 이 분야에서는 가장
중요한 도구 중 하나로 널리 쓰이고 있습니다.

* GSL - GNU Scientific Library, http://sources.redhat.com/gsl

* ROOT - 물리학, 특히 입자물리학의 메카라 할 수 있는 CERN에서 개발되는
'기존의 CERN Library에 대한 객체지향적(C++) 대체물'입니다. 물론 기존의
라이브러리는 포트란 위주였지만, CERN의 프로그래머들은 객체지향언어라는 새로운
기술로 관련된 수치계산 코드와 인터페이스, 시스템과의 인터랙션 등을 몽땅
포함하는 거대한 시물레이션 프레임을 구축하고 있습니다. http://root.cern.ch/

결론은... 포트란으로 구축된 그 간의 코드는 한 두번의 대체로 무너지지 않을 것이며,
또한 그것을 무너뜨리기(?!) 위한 '새 기술을 습득한 세대의 도전'도 계속될 것이란
말입니다.. 저는 다행인지 불행인지 주로 '새 기술을 상당부분 받아들인' 플라즈마
물리학을 합니다.

-------------------
(이제부터 꼬랑지글을 가장한 광고(?)가 시작됩니다...! :-)

실제로 어떻게 전개될지는 모르겠지만, 자유 소프트웨어를 이용하는 전산물리학도들의
모임을 추진하기 위한 메일링 리스트가 운영되고 있습니다. 물리학과 공학의 관계에
대해 고려해 볼 때 수치계산이나 시물레이션을 연구에 활용하는 분이라면 다 한 식구(?)
라고 할 수 있겠죠...

http://korea.gnu.org/mailman/listinfo/gcps

자세한 내용은... 늘 그렇듯이(?) 리스트 아카이브를 참조해 주시기 바랍니다.
많은 참여와 발전적인 제안/비판(?)에 미리 감사드립니다.. ^^

익명 사용자의 이미지

ROOT 는 CERN 라이브러리의 대체물이라고 하기에는 문제가 있습니다.
CERN 라이브러리에는 입자충돌시뮬레이션 프로그램(jetset 혹은 pythia ), 입자의 트래킹 시뮬레이션검출기등 입자물리와 관련된 라이브러리들과 그래픽라이브러리, 유저인터페이스 라이브러리, 포트란인터프리터 라이브러리, zebra 등의 데이타베이스 라이브러리 등의 방대한 라이브러리를 포함하고 있습니다.
ROOT 는 근본적으로는 c/c++ 인터프리터를 기반으로하며 객체지향데이터 베이스의 구성등 강력한 기능을 갖는 개발툴입니다. cern 라이브러리중 검출기 시뮬레이션과 관련된 부분은 GEANT4 프로젝트로 객체지향 환경으로 변하고 있고, 그래픽이나 유저인터페이스, 데이터베이스와 같은 물리외의 부분은 ROOT
등의 객체지향 환경으로 변하고 있습니다. ROOT 는 현재 상당히 안정적이고
강력한 툴로서 입자물리학실험의 많은 프로젝트에 채택되어서 사용되어지고
있지만, GEANT4 는 아직 여러가지 실제 실험에 적용하기에는 여러가지
문제가 있습니다. 현재 입자물리학 실험에서는 포트란과 c++ ,c 등이
혼용되어 사용되고 있는 과도기라고 할 수 있습니다.

익명 사용자의 이미지

CERN의 GEANT4 역시 oop인데요.

그리고 한번 연산하는데 한달 가까이 걸리는 그런 프로그램을
누가 왜 만드는지 궁금하네요.

-영희-

익명 사용자의 이미지

에혀 물리학 전공학생입니다.
석사지요. 지안트포... 참 이거 깔기도 힘듭니다.
지안트 쓰리는 포트란 기반이죠. 아시는 분은 아시겠지만.
그러나 필요합니다. 적어도 우리 쪽에서는.. 굉장히.
이 넘은 의료기 쪽에서 쓰는걸로 알고있슴니다. 외국에서요.
눈에 보이지도 않고 잠시(만분의 1초? 이런넘은 굉장히 오래사는
입자입니다. )살다가 가는 그런 친구들이 어떻게 움직이나?
머 그런데 쓰이는 프로그램이지요.
하여튼 안에 소스코드 보면 그간 배웠던 물리학의 관련된 이론
기타등등이 다 있다고 보시면 되지요.

이 툴을 이용해 시뮬레이션 하기위한 패키지 만들려면 작은 프로젝트야
머 몇개월 걸리겠지만 적어도 제가하는 실험은 보자~ 하여튼 수년동안
유지 보수 그리고 사용되고 있습니다. 수입도 글케 많지도 않습니다.
단지 뛰어드는데는 먼가 알고자 하는 호기심임돠.

돌리는데 2달? 1달? 이정도 걸리는 프로그램 많습니다. 비단 물리학만이 아니고
. 그래서 요즘 클러스터니, 또 나아가 그리드니 하는거 아니겟습니까.
멋하러 만드나 글케 비판하지 마시고.
힘내라고 응원이나 함 해주십쇼. 같은 붉은 악마끼리...
다들 자기가 나의 길이라고 믿고 나가는 사람한테 그런말씀은 실례가 아닐런지요.

익명 사용자의 이미지

GEANT 의 목적은
1. 막대한 돈이 들어가는 입자 검출기를 제작하기 전에 설계된 검출기가 효과적으로 작동하는지를 시뮬레이션을 통해 알아보고 이 정보를 다시 검출기 설계에 반영하여 효과적인 검출기를 제작하기 위한 것과
2. 실제 디텍터에서 측정된 실험 데이타를 획득하고 저장하기 위해 시뮬레이션을 통해 데이타를 효과적으로 획득, 저장하는 방법을 찾아내고
3. 또한 실험데이타를 해석하기위해 입니다.
GEANT 는 양성자, 전자, 중성자등 여러가지 소립자들이 물질내에서 이동하고 붕괴하는 과정 그리고 이런 입자들이 검출기에 검출되는 과정을 시뮬레이션하고 이들 데이타나 실제 검출기에서 관측된 데이타를 분석하는 프로그램을 만들기위해 필요한 라이브러리들로 되어 있습니다. GEANT 의 목적은 주로 높은 에너지를 갖는 입자들을 대상으로 설계된 라이브러리이기 때문에 geant 를 의료용 가속기와 같이 낮은 에너지의 입자 시뮬레이션에는 적합하지 않습니다.(의료용 가속기에해당하는 에너지에 맞는 여러가지 다른 시뮬레이션 툴이 있는걸로 알고 있습니다.)
또 geant 이런 고에너지 물리학을 위한 특수 목적용이기때문에 물리학과에서
배우는 물리이론이 다 들어가 있지는 않습니다. 고에너지 입자의 경우 입자의 속도가 빠르기 때문에 모든 운동학은 특수상대론을 기반으로 하고 있고 입자들이 물질과 반응하는 것과 관련된 이론(쿨롱산란, 광전효과, 컴프턴 효과, 제동복사 .. 등등 )과 입자붕괴 데이타 테이블등 입자물리학과 관련된 일부 이론들이 들어가 있을 뿐 입니다.
또한 GEANT 로 만들어진 디텍터 시뮬레이션 프로그램을 돌리는데는 몇번의 사건에 대해 시뮬레이션을 하느냐에 따라 달라지겠지만 단 한번의 사건을 다루는데는 현재 CERN 에서 추진중인 CMS 나 ATLAS 같은 대규모 실험에서 조차도
일반적으로 몇시간이면 충분합니다. 물론 실제 실험결과를 해석하기 위해서는 수많은 사건에 대한 시뮬레이션이 있어야하므로 충분한 데이타를 얻기 위해서는 많은 시간이 소요되겠지요.

익명 사용자의 이미지

geant이야길 한 이유는 찾아놓은 해가 제대로 된것인가?
어떻한 분포를 갖는가 뭐 그런 적합성 판정이라는게
그것과 유사하여 그냥 사례로 들은겁니다.

내부의 알고리즘이 같은것도 있고, 다른것도 있겟지만
커다란 틀은 비슷한거 같아서요.

-영희-

익명 사용자의 이미지

왜 그런 프로그램을 만드냐구요?
님이 타고다니는 자동차가 얼마나 안전한지 만들때마다
뽀개가면서 만들면 차한대값이 수천만원은 넘어갈겁니다.
자동차 한번 충돌시키는 시물레이션이 보통 얼마나걸릴거라고
보나요? 그리고 그런 시물레이션을 몇번쯤해야할까요?
님이 가끔 타는 비행기 날개 디자인을 해서 시물레이션을
안하고 매번 비행기 만들어서 떨어지면 또만들고 그러나요?
날개 한번 해석하는데 보통 피시로는 한달이상 걸리는건 기본이죠
님이 맨날 뉴스에서 보는 일기예보 슈퍼컴어쩌고 해석은
제대로 지구전체를 돌릴라면 몇달은 돌죠?
님이 쓰고 있는 서버에 팬 어디에 달것인지를 고민하고 해석하는
프로그램은 족히 한달은 넘어들죠.
타이거 우즈가 쳐대는 골프공에 구멍어디 뚫을까를 해석하기 위해서
보통 한달이상 돌아가죠.

왜 만드냐구요? 님같은 사람들이 그나마 좀 편하게 살게 해줄라고
하는거죠. 님손바닥으로 눈을 가린다고 하늘이 사라지는게 아니죠.

익명 사용자의 이미지

몇번쯤? 전 그것이 궁금하네요?
그럼 그건 개별 수행인가요?
아니면 첫단의 출력이 다음단의 입력으로 들어가야 하는건가요?
첫단의 출력이 다음 단의 입력이라면 그건 횟수 라는게 의미 없지 않나요?
그냥 한번 수행이 겁나게 오래 걸린다 라고 해야죠.

그냥 단순히 횟수가 문제라면
그냥 컴퓨터 한대 더 놓고 작업하는게 편할거 같은데요.

-영희-

익명 사용자의 이미지

GM에서 사용하고 있는 컴퓨터 댓수가 얼마인지는 모르겠지만
충돌해석에 CPU 16개 짜리 SGI Origin을 50대 두고 있죠.

몇번쯤이라고 보면 될까요? 개별수행인 동시에 전나 오래걸리는
수행이죠. 몇대를 더 두믄게 아니라 수천대를 두고 그걸 수천시간
켜두면 되져...

님은 님의 좁은 소견을 여기서 자바로 백날 주장하고 싶어서
말고리를 잡는데, 더 이상 수치해석이던 수치실험이던 관심없으면
그냥 웬만하면 계속 님 일이나 하세욤...

익명 사용자의 이미지

그럼 다시 한번 묻죠.
그렇게 거대한 프로그램을 만드는데 들어간 시간은 얼마나 될까요?

그리고 국내 연구소에서 그러한 프로그램을 만들어 돌리려면
얼마나 많은 프로그래머가 달려 들어야 할까요?

보통은 연구소 일하는 사람들이 알아서 이것저것
쓸만한거 붙여서 만들지 않나요?

그리고 다른 사람이 만들어 놓은것을
수행하려는 실험 목적에 맞게 변경해
사용하는게 그리 어렵지 않은가보죠?

돈많은 외국 연구소에서야 충분한 돈과 사람이있으니
빠른 시간에 개발이 가능하겠지만, 보통의 경우
그 프로그램이 완성 되기까지 시간은 얼마나 걸리나요?

모의 실험 돌려서 그 결과로 학위 받으려는 사람이
한번 돌리는데 1달씩 걸리는걸 만들었다면
그걸 만드는덴 얼마나 시간을 허비했을까요?
언제 결과를 봅니까?

뭐 그냥 누군가 만들어 놓은거 돌리기만 한다면
툴을 그냥 이용하는거지 컴파일러랑은 상관 없잖아요?
개발이랑도 상관 없는거고.

뭐 제가 하고픈 이야기는 간단히 말해서
그 복잡한걸 언제 누가 어떻게 만들고 검증하냐는 겁니다.

-영희-

익명 사용자의 이미지

..."영희"님은 java나라에서 노세요..
철수랑 놀면 되겠네.^^
제발 문제제기한 이유를 제대로 파악하고
질문 좀 해주세여...

익명 사용자의 이미지

누가 언제 만들고 검증하냐면
보통 박사 1년차때 들어가서 만들고
프로그램의 결과 검증은 논문으로 끝나죠.

그러고 연구소에서는 보통 학교에서 만든걸 갖고 다시 돌리죠.
얼마나 걸리나... 보통 1명이 한 6개월~1년 걸리고 (물론
이건 앞에 비슷한거 한사람들이 있을때 거기에 알고리즘 추가하는거고...)

아예 첨부터 새로 짜는거 걸리는 넘은 졸업하는데 보통 천년만년걸리죠.

그러고 님이 일하는 곳이 연구소인지 모르지만 그런데서는 남의거
툴로 이것저것 가져다가 붙여서 만드는지 모르겠지만 대부분의 Fortran
Library들은 돈을 주고 사던지 아니면 연줄로 얻어오던지 아님 공개된거를
쓰던지 해야죠.

실험목적에 맞게 변경하는것도 뭘 알아야 코드를 뜯어고치죠.

중요한것은 수치실험이라는것은 프로그램 백날 잘짜봐야 소용없음다.
그 프로그램의 수행 결과로 나타나는 물리적 현상을 얼마나 잘 이해하는것이
중요하고 그걸 위해서 C/C++/Fortran 이던 뭐든 자기 편한거 쓰는거죠.

하지만 물리적 현상을 이해하고 그걸 컴퓨터로 시물레이션해서 결과를
해석하는 시간이 코드 도는 시간보다 곱절은 필요한데... 가뜩이나 시간없는데
프로그램까지 느리게 돌면 미치죠.

더더구나 새로운 알고리즘(여기서 말하는 알고리즘은 전산학적인 그런거
말고)-루틴이라고 하는게 낫겠군요-을 추가한다음에 그 몇줄이 과연 얼마나
제대로 물리적현상을 따라가는지 보는데 한달쯤 걸린다면 거의 돌아버리겠죠?

님이 보기에 기계공학하는 사람들은 한달씩 걸리는 결과로 어떻게 졸업했는지
신기하죠? 다들 그렇게 졸업하고 그나마 좀 빨리 해볼라고 병렬처리도 도입하고 별난리 다 피우는거죠.

어떤 사람은 10년간 박사학위하는동안 딱 결과 12개 만들고, 그래프 한장 그렸던 사람들도 있어요.

지도교수왈. '결과가 좀 이상한데. 약간 고쳐서 다시돌려봐'
학생왈 '알겠읍니다. 교수님 6개월후에 뵙죠'

농담같죠? 사실이어요.

익명 사용자의 이미지

저도 그걸 아니까 이런 미친짓을 해아 한다는 거죠.

선택 언어야 어느거든 상관 없다 이겁니다.
물론 조금 느릴수도 있지 만, 그걸 만드는 사람이
쓸데없이 남의 코드 보고 머리 아파 하해서는 안된다 이거죠.

결과 한번 다시 보려고 몇줄을 고쳐봤는데
그 결과가 과연 그 몇줄에 의한 것인지
그거 디버깅 하려면 죽어 날거 같지 않습니까?

그렇게 중요한 데이터를 다룬다면 적어도
모두가 공감 할 수 있는 코드 이어야 한다 이겁니다.

가뜩 이나 공부하느라고 머리아파 죽겠는데
남의 코드나 뜯어보고 있음 정말 피곤하잖아요?

-영희-

익명 사용자의 이미지

심각한 차이가 뭐냐면
'남의 코드를 뜯어본다'라는것에 대한 개념차이인데... 보통 코드에서 우리가 남의 코드를 뜯어본다 라고 하는것은 그 코드를 만들때 사용된 논문을 뜯어본다라고 보시면됩니다.
즉, 객체지향의 라이브러리를 아무리 잘만들어도 그 라이브러리에 함축되어 있는 논문의 내용을 모르면 아무리 구조적으로 짜도 힘들다는거죠.

그러고 님이 생각하는것보다 포트란 코드는 대단히 뜯어보기 편하게 짜여있읍니다. 거의 순차언어니까요.

님이 말하는것과 같은 범용의 라이브러리는 대부분 Matrix 뒤집기 루틴 이런거고 그런것은 굳이 가져다가 쓰면 되니가 랭귀지에 상관이없죠.

IMSL이나 BLAS 등을 보면 똑같은 Matrix 뒤집는것이 한 수십개의 루틴이 있읍니다. 이게 C나 C++이 되서 가져다 쓰기 편하다고 해서 다들편해지는 것이 아닙니다. 즉, 행렬이 어떻게 생겼는지, 거기서 구하고자하는것이 eigenvalue인지 eigen vector인지 아니면 단순히 역행렬인지, transformation만 할것인지 등등...

여기에 글을 올린 사람의 성향을 잘 보기 바랍니다. 발제자나 대부분의 사람들은 프로그램 개발자가 아니라 프로그램 이용자 입니다. 단지 그 이용자가 소스를 자기 입맛에 맞춰서 조금씩 고치는것이고 그게 개발로 비치는거죠. 소스 고치고 만드니까.

이렇게 생각하면 심플합니다. 실제 수치실험말고 실험을 한다고 보면...

- 실험 장비를 공급하는 회사들도 있읍니다. (이건 라이브러리 개발에 해당)
- 하지만 기본 실험에 쓰이는 도구룰 실험자가 직접 도면그리고 만들기도 합니다.(이게 대부분의 수치해석하는 연구자에 해당)

첫번째에 해당되는 것은 범용의 언어나 좀 general한 방식으로 만들어야하는것이 맞지요. 하지만 두번째는 워낙 특수한 케이스가 많고, 그 특수한 몇가지의 케이스 덕분에 근본적인 회사들이 옃십년간 만들어서 튜닝한 장비를 다시 설계한다면 그것도 엄청난 문제이지요.

그러고 모두가 공감하는 코드는 적어도 연구분야에서 님이 생각하는 C++이나 Java라기보다는 Fortran이죠.

남의 코드를 뜯어보면 그 코드에 한줄한줄이 바로 논문의 결과이고 그것이 바로 현재 과학기술을 발전시킨 토대죠. 그건 당연히 뜯어봐야하는겁니다.

익명 사용자의 이미지

그렇군요. 제가 잘 몰라서 헛소리 한건가 봅니다.
죄송합니다.

그런데 처음에 우리가 포트란, c로 만든 프로그램을
자바로 포팅할때 2-3시간 걸리던걸
이것저것 최신 알고리즘고 최적화를 통해서
6개월후에 20-30분
그리고 다시 6개월호 2-3분
그리고 지금 2-3초로 되었습니다
물론 그중간에 필요없는 루틴을 제하고 이것저것 랜덤에다 카오스 이론등 잡한
것들을 추가했지만 말입니다.

마지막 알고리즘은 지난 3개월 전보다 10배 빨라졌습니다.
지금은 1초가 안걸립니다.

하긴 우리가 하던거는 대형은 절대 아닙니다.
그냥 단순히 최적해를 구하는 단순한 알고리즘입니다.

그렇지만 그것을 만들수있는(제가 알기론) 곳은 한국에서 2-3곳 뿐이더군요.

-영희-

knight2000_의 이미지

이글을 보니...
"수치해석과 알고리듬은 서로에게 양날검으로 작용한다."
라는 말이 생각나는군요.

... 어디서 읽은 것인지 기억이 나지 않네요.
그거나 찾으로 가야겠습니다.

익명 사용자의 이미지

글을 읽어 보니 수치해석 보다는 알고리즘에 가까운거 같은데요.

liberta의 이미지

그, 그러게 말입니다... ^^

하, 하지만 세상에는 당장 눈에 보이는 결과가 없어도 미래를 위해(?) 거금을
쏟아 붓고 밤낮없이 연구해야할 그런 일이 많이 있나 보죠 뭐.. :-)

페이지