시뮬레이션 쪽에서 여전히 C가 대세인가요?
글쓴이: 해봐 / 작성시간: 토, 2005/03/12 - 10:55오후
시뮬레이션 관련 프로그램을 작성하거나
할때 여전히 C가 대세인지요?
적어도 제가 봐온 상황에서.. hardcore한 시뮬을 하기위해서
일반인(?) 의 관점에서는 C를 대세로 생각하고 있더군요
(그렇지 않은 상황에서는 matlab이나 systemview와 같은
다소 편한 환경을 고려하는듯.)
그러나 제가 알기로는 Java 가 오히려
반복적인 작업시의 효율성은 C를 능가할 '가능성'이
많은것으로 알고있습니다. 시뮬레이션 시의 스타트업 타임이
크게 중요한것도 아니고요..
그리고 Java에서는 안되고 C에서는 되는 hardware specific한
것 때문에 C를 쓰는 경우도 없는것 같고요
C로 시뮬레이션 했을때 시뮬레이션을 위해 구현한 알고리즘 코드를
하드웨어로 구현하기 위해 HDL 같은 걸로 컨버전 하기가 더 쉽다 하는것도
말이 안되는것 같고요.. 그런 측면에서는 Java나 C나 마찬가지또는 Java가 약간 더 유리하다고 생각됩니다.
그럼에도 불구하고 C가 대세인 이유가 무엇일까요?
ps>궁금해서 찾아본 최근의 java와 c의 퍼포먼스 차이자료를 첨부하겠습니다.
File attachments:
| 첨부 | 파일 크기 |
|---|---|
 SciMark-P4.png | 18.53 KB |
Forums:
답은 아니고 또다른 질문입니다. VC++의 최적화 옵션에 비해 i
답은 아니고 또다른 질문입니다.
VC++의 최적화 옵션에 비해 icc, gcc의 최적화 옵션은 많이 못 미치는 거 아닌가요?
gcc 는 최적화 옵션이 O3 까지 있을텐데 -_-)
gcc 는 최적화 옵션이 O3 까지 있을텐데 -_-)
[quote="Anonymous"]gcc 는 최적화 옵션이 O3 까지 있
있기는 O9까지도 있을걸요.. 결과를 보장 못할 뿐 =3=33
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
[quote="정태영"][quote="Anonymous"]gcc 는 최적
4이상은 모두 3과 같습니다. -O3이나 -O4나 -O5나 모두 -O3과 같습니다. (manpage 참조)
You need Python
아마도 그것은.
시뮬레이션에서 프로그램 언어의 선택이 현재 프로그램을 돌리는 사람에게 달려있는 경우보다 그렇지 않은 경우가 많기 때문일꺼라고 생각합니다.
시뮬레이션을 위해 처음부터 프로그램을 다 짜는 경우보다는 기존에 알려진 소스에 자신이 필요로 하는 기능을 추가하는 경우가 많기 때문이겠죠. 마이크로디프렉션쪽의 타무라 코드등 라인수가 20만줄에 이르는 포트란 코드가 존재하는 경우, 다음 세대 사람들은 새로이 프로그램을 짜기 보다는 기존의 코드를 이용하는 편이 유리하니까요. NRC (Numerical Recipe in C) 조차 사실은 포트란 소스를 기본으로 하고 있고요. 이래저래 과거의 유산때문이 아닐까 추측해 봅니다.
게다가 시뮬레이션을 주로 하는 물리나 화학, 재료쪽 사람들에선 프로그래밍 언어를 자유자재로 다루는 사람이 적기 때문에 새로 짤 엄두를 못 내는 경우도 많지요. 제가 있는 대학의 물리과 대학원 수업중에 C와 포트란, 그리고 Matlab은 가르치고 있지만, JAVA는 배우지 않습니다. 다른 곳도 사정은 마찬가지 일테고, 대략 생각해봐도 물리과 학생중에 C 와 Fortran 을 쓸 줄 아는 사람은 많지만. 병특으로 IT 회사에 있던 경우가 아니면 JAVA를 다룰줄 아는 사람은 거의 없을꺼라고 생각합니다.
Re: 시뮬레이션 쪽에서 여전히 C가 대세인가요?
저도 컴퓨팅을 많이 다루는 물리학의 한 분야에 종사하는 사람입니다만... 제분야의 한해서는 Java는 거의 안 쓰고 C++이 대세입니다... 제 분야는 일반적으로(?) 잘 알려진 시뮬레이션 및 어날리시스 툴로는 할 수 없는 일들이라서 직접 랭귀지로 실험에 맞게 패키지들을 만들어 사용하는데... 물론 예전에는 포트란을 사용하기는 했지만... 적어도 10년전 부터는 C++을 사용하기 시작했었고 지금은 몇몇 보수적인(?) 곳을 제외하고는 완전히 C++로 이행ㅤㅎㅒㅆ다고 볼수 있는 상황입니다 아무래도 oop의 개념을 가진 랭귀지가 코드의 유지 보수에 훨씬 좋고 나중에 company로 가는 사람에게는 포트란보다는 C++이 낫겠죠. 물론 예전에 Java로 시도했던 적도 있었기는 합니다만... 저희 분야처럼 대용량의 데이타를 처리하는 곳에서는 처리속도가 아주 중요하기 때문에 Java보다는 C++을 선택한 것 같습니다.
대표적인 시뮬레이션 및 분석 툴킷 사이트들을 구경해 보세요 :D
http://geant4.web.cern.ch/geant4/
http://root.cern.ch/
그런데 이 벤치마크는 중립적(?)기관에서 한건가요...어느정도 객
그런데 이 벤치마크는 중립적(?)기관에서 한건가요...
어느정도 객관적 위치의 기관이 했다면....
대중성(?)있는 코드로 짜여진 프로그램에서 자바가 저 정도 성능을 낸다면
정말 JAVA가 경이로운 발전을 했네요.
한 가상머신에서 여러개를 올리 수 있는 기술을 개발한다던데...
메모리 잡어먹는 귀신만 잡아내면 java도 막강해지겠군요. :)
그나저나 백수 언제 탈출하냐... ㅡㅡ; 배고파라.
[quote="alsong"]그런데 이 벤치마크는 중립적(?)기관에서 한
NIST (National Institute of Standards & Tech.) 에서 행한것입니다.
미국표준기술연구소... 라져..
http://math.nist.gov/
정말 자바가 빨라 진 것 인가요?
제가 전에 몇가지 시뮬레이션 프로그램을 짜본적이있는데...
Java와 C의 속도차이가 엄청 났거든요.
예전에
속도 테스트를 해볼려고.
두개의 언어를 가지고 동등하게
2^32-1번 만큼의 난수를 발생시키면서,
mod 10 했을 때 나오는 숫자의 갯수를 세는 프로그램을 짰었는데.
(psuedo random number generator에 대해서 아시겠지만, modular op 후에 나오는 stochastic 숫자의 갯수는 동일 합니다. ^^)
C로는 3시간쯤 걸렸는데
Java로는 대충 8시간 정도 걸렸던 기억이 납니다.
(짤때부터 참 느릴꺼 같다라는 생각이 들었어요 -_-;
object instance만들때 마다 버벅이는 cpu의 영혼이 느껴졌다라고나 할까...)
또, 그후에도... 몇가지 시뮬레이션 프로그램을 자바로 짜보면서
앞으로는 자바로 짜지 말아야지;; 라고 다짐 했었는데
위의 통계치는 놀랍네요.
요즘 자바는 정말 저렇게 빨라졌나요? 궁금합니다.
(특히 CPU bound job에 대해서 말입니다.)
정말 놀랍습니다.
제가 있는 쪽의 시뮬레이션은 거의 포트란이 지배적입니다. 자바로 조그마한 프로젝트를 수행 할 때도 이것의 연산 속도가 상당히 불만족 스러웠던 것으로 기억합니다. 포트란도 아직 많은 부분에서 쓰이고 있을 것이라 생각합니다.
5년전의 그 자바가 아닌가 보네요. 속도가 장난이 아닙니다.
==========================
부양가족은 많은데, 시절은 왜 이리 꿀꿀할까요?
=====================
"지금하는 일을 꼭 완수하자."
포트란!저희 분야에서는 절대적으로 포트란입니다. 아직도 쓰이는 정
포트란!
저희 분야에서는 절대적으로 포트란입니다. 아직도 쓰이는 정도가 아니라 제가 본 사람들은 죄다 포트란이 가장 많이 사용하는 언어였습니다. 저는 일기예보와 지구환경모델링을 하는 대기과학 분야 대학원생입니다.
예전에 대전에 있는 슈퍼컴퓨터센터인가 하는 곳에서 오셔서 사흘동안 매일 8시간씩 강행군으로 강의를 들은 적이 있었는데 포트란 컴파일러와 C 컴파일러 사용법은 배웠어도 C++이나 java에 대한 언급은 없었습니다.
또한 수치연산용으로 특화된 포트란과 C 컴파일러를 따로 파는 것은 많이 봤어도 C++과 java 컴파일러 따로 파는 곳은 잘 모르겠네요.
이런 로그인을 안 했었군요. 윗글은 제가 쓴 것입니다.
이런 로그인을 안 했었군요. 윗글은 제가 쓴 것입니다.
항공분야인데, 시뮬레이션은 역시 포트란이 아직도 대세입니다. 공력, 구조
항공분야인데, 시뮬레이션은 역시 포트란이 아직도 대세입니다. 공력, 구조 해석은 대부분 포트란으로 아직도 작성되고 있지요.
제 생각엔 먼저 방대한 legacy 코드에 기인한 점이 많다고 생각되고 -- 왜냐면 from the scratch로 처음부터 하지 않는 이상 기존의 코드를 계속 업데이트 하니까요, 물론 "기본의 코드"란 포트란으로 되어 있지요. 아무래도 이것이 가장 큰 이유가 아닌가 싶습니다.
두 번째로 역학을 다루는 분야에서 그다지 프로그래밍에 익숙치 않아서 이전에 다루었던 포트란, C 정도가 고작입니다. 따로 관심을 가지지 않는 이상에서야 OOP인 C++, Java 를 다룰 수 없지요.
p.s.
음.. 분명히 포트란 코드가 가장 빠른 성능을 보여주지만, 제가 from the scratch로 시작하면 소스 관리면에서 C++로 하겠습니다.
...Java는 Sun이 쥐고 있어서 왠지 정이 안갑니다. -_-;
It's better to burn out than to fade away. -- Kurt Cobain.
원자력공학(물리/화학) 포트란!
포트란 라이브러리가 워낙 많아서요...
몬테카를로 시뮬레이션 같은거 할때도 라이브러리코드가 전부 포트란이다 보니...
자바로 어플 만들어도 포트란 라이브러리 import 해서 씁니다...
저쪽 쓰레드에도 썼었는데....제가 쓰는 분야에서 거의 대부분은
저쪽 쓰레드에도 썼었는데....
제가 쓰는 분야에서 거의 대부분은 자바/C/C++ 로 front end 를 작성하더라도 내부는 포트란입니다.
대개 포트란이 계산을 맡아서 하고, C/C++ 이 입출력쪽을 담당하고(데이터 포맷 변환 등등...), 자바로 겉모습을 꾸미는 정도입니다. 그마저도 귀찮으면 그냥 포트란으로 계산 한 뒤에 엑셀이든 오리진으로든 그래프만 그립니다.(사실 대부분 이렇게 합니다.)
경험상, 속도면에서 자바는 아직 택도 없고, C/C++ 은 한 80 % 쯤 따라온 것 같습니다.
- 제가 주로 했던 분야는 소숫점 30 자리 이하를 계산하는 경우가 많기 때문에 더 그런지도 모르겠습니다.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
시뮬레이션
물리학을 전공하는 대학원생입니다만,
저희쪽 분야에선 포트란이 압도적입니다. c도 있기는 하구요.
같은 물리학 분야라도 c를 많이 사용하는 경우도 있습니다. 주로 새롭게 자신이 코드를 개발하는 경우가 그렇습니다.
하지만, 대용량의 숫자계산에는 아직 포트란이 빠르고 안정적이라서요.
예전에 c로 만든 lib와 포트란으로 만든것을 비교했었는데
여전히 포트란이 빠르더군요.
그이외의 언어들은 사용하질 않습니다. c,fortran으로 해도 시간이 너무 많이 걸려서 어떻게든 계산 시간을 줄여보려 시도하는데
JAVA같은 것을 쓸리가 없죠./
Re: 시뮬레이션
저희 분야(고에너지물리실험)에서는 대부분의 포트란 패키지들이 c++로 랩핑내지 완전히 새롭게 짜여져서 몇년후면 포트란을 더이상 안쓰게 될 날이 올것 같습니다. 자바는 OOP로의 대대적인 이동시(몇년전)에 재미로(?) 해본적들이 있지만 역시 속도의 문제때문에 결국은 C++만 살아남게 되었구요. 코어 패키지들은 C++로 짜여있어도 패키지사용에 있어서 파이썬이나 루비를 사용하는 경우도 있더군요
Re: 시뮬레이션
제가 1991년에 대학 들어갈 때도 대학원에서 포트란 패키지를 C 또는 C++ 로 다시 바꾼다고 했는데, 지금도 여전히 하고 있더군요. 몇년... 은 아닐 것 같습니다. 10년은 넘을 것 같습니다.
고에너지물리... 예전에 좀 관심 있게 보다가... 머리 터지는 줄 알고 포기했습니다. T.T
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
포트란일수밖에 없습니다. C는 call을 할때 stack에 쌓지만 포트란
포트란일수밖에 없습니다. C는 call을 할때 stack에 쌓지만 포트란은 쌓지않기때문에 포트란이 빠를수밖에 없습니다.
Re: 시뮬레이션
현재는 코어패키지들이 이미 다 완전히 c++로 업그레이드되어서 새로 짜여져 있어서 새로운 실험들을 위한 소프트웨어 개발은 더이상 포트란을 전혀 사용하지 않습니다. 단지 아직도 데이터를 받고 있는 실험들이 예전에 개발된 소프트웨어들이라서 포트란을 직접 사용하거나 랩핑해서 사용하고 있을 뿐입니다
[quote="Anonymous"]포트란일수밖에 없습니다. C는 call
요즘에는 최적화된 프로그램보다는 Grid와 같은 프로젝트에 참여해서 컴퓨팅의 극대화로써 시뮬레이션이나 데이타분석에 소요되는 시간을 단축하려는 경향을 가지고 있는것 같습니다. 아무래도 최적화를 하려면 프로그래밍 자체가 어려워지니까 컴퓨팅을 단순히 응용하는 분야에서는 그리드와같은 컴퓨팅파워의 극대화를 선호하는게 당연하다는게 제 생각입니다
Re: 시뮬레이션
분야에 따라 다릅니다. 제가 있는 표면물리쪽은 아직도 포트란이 대세입니다. 저 위에 제가 썼듯이 코어쪽은 포트란, C/C++ 과 자바는 보조 하는 역할을 하고 있습니다. 물론, C계열이나 자바 계열의 코어패키지들이 계속 나오고는 있습니다.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
Re: 시뮬레이션
저의 분야쪽의 이야기였습니다 :) 아마도 귀찮아서 그대로 놔두는 경우도 있을테고, 그 분야에 있는 학생들의 진로하고도 관련있는 것 같기도 합니다. 저의 분야에서는10년전부터 c++로 옮겨가기 시작했는데... 아시겠지만 저의 분야는 순수물리쪽이라서 졸업후 진로라는게 상당히 제한되어 있습니다. 그래서 그 당시의 학생들이 사회에서 안쓰는 포트란보다 c++ 같은거 배워두는게 나중에 전공과 관련없는 일을 하더라도 더 낫지 않게느냐는 요구들이 많았다고 하네요
Re: 시뮬레이션
씁쓸한 얘기군요.
제가 있는 분야 역시도 포트란이 대세입니다. 대세가 아니라 포트란 뿐입니
제가 있는 분야 역시도 포트란이 대세입니다. 대세가 아니라 포트란 뿐입니다. 새로 개발 되는 시뮬레이션 프로그램도 마찬가지 입니다. 심지어 포트란 90/95로 개발되지도 못하고 포트란77로 가던데요. ^^;;;;;
한 7년전 부턴가 맷랩을 쓰기 시작하더군요. 그런데 역시 속도가 느리고 사이즈가 큰 매트릭스를 다루기엔 좀 무리가 있더군요. 더구나, 포트란77 스타일로 루프 몇개만 돌려 놓으면 죽음입니다.
리눅스 박스 + 상업용포트란 컴파일러: 이게 제가 아는 최적입니다. 동일한 컴에 윈도우2000박스 + 상업용포트란 컴파일러가 조금 더 느립니다.
==========================
부양가족은 많은데, 시절은 왜 이리 꿀꿀할까요?
=====================
"지금하는 일을 꼭 완수하자."
Re: 시뮬레이션
순수이론쪽이 좀 그렇지요. 제가 학교에 있을 때 이론 실험실 쪽은 영 취직이 힘들더군요. 저는 어떻게든 어디 하나 들어갔지만 ... 쩝...
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
저는 시뮬레이션을 하는 쪽 분야가 아니기 때문에 자세히는 모릅니다.그
저는 시뮬레이션을 하는 쪽 분야가 아니기 때문에 자세히는 모릅니다.
그러나 대부분 시뮬레이션 분야가, 방대한 양의 정수와 실수 연산, 메트릭스 연산을 포함하고 있고, 이런 작업을 위해 가장 적당한(최적화된) 언어라면, 당연 포트란입니다.
몇 가지 이유가 있는데, 첫째, 포트란은 포인터 개념이 없습니다. 따라서 컴파일러 입장에서 대부분의 경우, 실제 계산을 해야 하는 주소값을 바로 알 수 있기 때문에 최적화가 쉽습니다.
둘째, alasing을 만들기도 힘들기 때문에, 오히려 컴파일러가 optimization을 수행하기가 훨씬 수월합니다. alias를 간단히 말하면, 두 개의 파라메터가 하나의 메모리 위치를 가리키고 있는 것을 말합니다.
세째, C 언어에서는 자유롭게 loop나 jump를 쓸 수 있습니다. 예를 들어, loop 안으로 점프한다거나 setjmp/longjmp를 써서 함수 밖으로 바로 탈출할 수 있다거나 등등.. 이러한 것이 프로그래머에게 좀 더 많은 기능을 제공하는 역할을 하지만, 반대로 컴파일러가 최적화하기 어렵게 만듭니다.
네째, 기계어에 가까운 C 언어의 증가/감소 연산자가 strength reduction 최적화를 하는데 어려움을 줍니다. 예를 들어, 상수 계산이라든지, 필요 없는 계산 등을 컴파일러가 최적화를 위해, 미리 계산한다거나 제거할 수 있는데, 이런 최적화가 더 어렵습니다.
이외에도 여러가지 문제가 더 있습니다만 이 정도로도 충분한 설명이 될 것 같습니다. 결론을 말씀드리면, 좀 더 다양한 표현 방식과 자유스러움을 제공하는 언어의 경우, 그렇지 않은 언어에 비해 언어적 측면에서 우수하고, 개발자에게 매력적이지만, 그 반대로 최적화 기법을 적용하기 까다롭기 때문에, 주어진 수식에 따라 대용량의 데이터를 계산하는 목적으로는 포트란과 같은 언어가 쓰이는 게 현실적으로 어울립니다.
게다가, 일반 소프트웨어 개발자라면 다양한 언어 기능을 활용하고, reusability를 높이는 코드에 좀 더 관심이 가기 마련입니다. 물리학자와 수학자라면, 언어의 기능을 다양하게 활용하는 것보다는 계산 그 자체에 더 관심이 가기 때문에, 포트란과 같이 직관적이고 간단한 언어가 더 효과적이기도 합니다.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/