자바 vs C 성능비교

select99의 이미지

자바가 C 와 성능차가 별로 안난다는 사람들혹은 글들을 종종 봅니다.

과연 그주장이 맞는지 직접 테스트해보았습니다.

일단 자바측에서 주장한 간단한 소스하나를 가져왔습니다.

==========================

public class Speed_K {
  static boolean c1 = true, c2=true;
  public static void main(String[] args) {
    long start = 0, end = 0, elapsed;
    try {Thread.sleep(5000L);} catch (InterruptedException e) {}
 
 
 
    for(int k=0; k<5; k++) {
      start = System.currentTimeMillis();
      if( end == 0 ) end = start;
      doo( (int)((end - start)/1000));
      end = System.currentTimeMillis();
      System.out.println("Elapsed time:"+((end-start)/1000.));
    }
  }
 
  static public int doo( int in ){
    int i,j;
    int count = 5;
    int n = 50000000;
    int sum =0;
 
	n = n + in;
    for(i=0; i< count;i++) {
      for(j=0; j<n;j++){
        if ( c1 == true){
          if (c2 == true) { sum ++;}
          else { sum--; }
        }
      }
      c2 = ! c2;
    }
    return sum;
  }
}

========================================

#include <sys/time.h>
#include <stdio.h>
double elapse_tm( void );
 
 
int c1 = 1, c2=1;
int main( void )
{
	int k;
    long start, end, elapsed;
    double dd;
 
    printf( "sizeof int=%d long=%d\n", sizeof(int), sizeof(long));
	elapse_tm();
    for( k=0; k<5; k++) 
    {
      doo( (int) dd );
 
      printf("Elapsed time:%f\n", (dd = elapse_tm()));
    }
}
 
int doo( int in )
{
    int i,j;
    int count = 5;
    int n = 50000000;
    int sum =0;
 
	n = n + in;
    for(i=0; i< count;i++) {
      for(j=0; j<n;j++){
        if ( c1 == 1){
          if (c2 == 1) { sum ++;}
          else { sum--; }
        }
      }
      c2 = !c2;
    }
    return sum;
}
 
double elapse_tm( void )
{
        static struct timeval et = { 0, 0 };
        struct timeval st;
 
        st = et;
        gettimeofday( &et, NULL );
 
        if( st.tv_sec == 0 && st.tv_usec == 0 ) return 0;
        return et.tv_sec - st.tv_sec + ( et.tv_usec - st.tv_usec ) / 1000000.;
}

=====================================================
소스가 약간달라 비슷하게 개선되었습니다.
=====================================================

컴파일옵션 -O3

결과

[localhost test_src]$ java Speed_K
Elapsed time:1082
Elapsed time:1054
Elapsed time:1160
Elapsed time:1181
Elapsed time:1204
[localhost test_src]$ cc -O3 Speed_K.c
[localhost test_src]$ ./a.out
Elapsed time:0.249474
Elapsed time:0.250046
Elapsed time:0.249660
Elapsed time:0.249515
Elapsed time:0.250348

자바는 밀리세컨드 C는 초단위 따라서 자바는 1.1 초정도이고 C는 0.25 초 정도입니다.
제가해본바로는..무려 400%의 성능차가나는데..

더구나 동일코드상으로는 C가 최척화되어 결과가 0에 가까웠습니다.
그래서 보시다시피 최적화 되지못하게 불리한코드 dd변수를 추가하였는데도불구하고 훨씬빠르네요.

자바가 어떤옵션으로 더욱성능이 증가된다거나 하는것이 있으면 테스트후 결과좀 올려주세요..

---컴파일러.-------
[localhost test_src]$ java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

[localhost test_src]$ cc --version
cc (GCC) 4.1.1 20070105 (Asianux 3.0 4.1.1-52.2.1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dhunter의 이미지

지금 당장 레퍼런스를 드리진 못해서 아쉬운데 (아마 위키백과에 링크가 있을겁니다)

MSVC에 따라오는 C 컴파일러는 x86-win32 기반에서 ICC 다음으로 빠르더군요. ICC를 1로 봤을때 MSVC 2005 에 최적화 옵션 건게 1.1, GCC는 mingw 로 1.5배 정도의 수행시간을 내더군요.

의외로 그렇게 느린 컴파일러는 아닙니다 :)
--
from bzImage
It's blue paper

from bzImage
It's blue paper

winner의 이미지

제가 말하고자 했던 것은 debug mode 니까요.
GCC가 성능면에서 좋은 compiler가 아니라는 것은 저도 많이 들었습니다.

우연한 기회에 아마도 그 Wiki 백과 page와 만날 날을 기다리죠. ^_^

select99의 이미지

주지말아야할이유가 없기때문이죠..
어떤이가 최적화옵션을주고 매우빠른 게임을 개발하여 배포했다해서 반칙이라하지 않기때문이죠..
비행기는 날아가고 자동차는 굴러가는데, 경주시에는 등에매고 달릴순 없는일이죠..

system77의 이미지

자바와 C를 저렇게 단순비교 하는건 코끼리 다리만지기 같습니다.
자바나올때 부터 저런 논쟁이 있었는데 각기 다른 조건에서는 조건에서는 결과가 틀리게 나오던데...

제생각에는 하드웨어가 발전속도는 소프트웨어보다 빠릅니다.
메모리지원은 날이갈수록 커지고 64비트 OS가 보급되는 시점이고
예전처럼 아기자기한 소프트웨어를 개발하는 것보단 대형공장에서 찍어내듯 생산하는
결과위주의 프로그래머를 원하고있습니다.

C의 연산속도니 메모리를 얼마나 알뜰하게 사용하는지는 어쩌면 점점 과거얘기가 될듯

wish의 이미지

씨가 느려서 포트란을 사용하는 분야도 아직 있고(심지어 자바보다 포트란 수명이 더 길 것이다라는 기사도 있었었죠), 하드웨어가 아무리 발전해도 근본적인 체계가 바뀌지 않는 이상 빠른 계산이 필요한 분야는 매우 많습니다. 결국 분야마다 사용하는 언어와 환경이 달라지는 것 뿐이죠.

kimying의 이미지

뭐 C던 자바던 못하는 놈이지만... ㅡ_ㅡ;;
주제넘게 한마디 남겨요~ ^^;;
C던 자바던 자기 자신이 좋다고 생각되는 언어를 쓰면 되는 거 아닐까요?
A라는 상황에서는 C가 좋을수 있고 B라는 상황에서는 자바가 좋을수 있고 하는거니...
자바랑 C랑 모두 장단점이 있으니 두개를 같은 관점으로만 평가 하려하시는 것보다
일정 상황에 따라 어느쪽에서는 이게 좋다 어느쪽에서는 이게 좋다가 맞는거 같은데요.

주저리주저리 글을 썼지만 굳이 자기 자신이 쓰는 언어가 다른 언어보다 나쁜 것이
아니실텐데 굳이 다른 언어까지 같은 관점으로 평가하려 하시는건 마치 엄마친구아들은
연세대다니고 나는 고려대 다니는데 고려대 관점으로 연세대를 보는 것 같은 느낌이..

고려대,연세대분들 죄송.. ㅡ_ㅡ;; (비유를 하다보니..)

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

나름 생산적인 방향으로 가고 있고, 별로 격한 분위기도 아니니 진정할 필요는 없겠는걸요. :D

김일영의 이미지

생산성 운운하거나 "나는 자바 쓸테니 당신은 C++ 써라" 식의 댓글을 다는 분들은 논점 이탈인듯 합니다.
select99님은 자바의 생산성을 깎아내리거나 "성능이 좋으니 C++로 바꿔라" 식의 글을 쓴 것이 아닌데
그런 버럭질(?) 하시는 분들은 뜬금없는듯.

여하튼 HotSpot 해도 자바 성능은 C++에 비해 의미있는 차이가 나타난다고 이해하면 되는 것이겠죠?

plusme의 이미지

앞서 언급했다 시피.. 성능만을 놓고 볼때도 Java < C/C++ 로 단정지을수 없고, Java > C/C++ 인 경우도 있습니다.

그러나 '본질적인' 생산성 차이로 인한
애플리케이션의 Quality 차이는 고려 대상이 되는것이 맞다고 봅니다.

어떤 상황에서든
시간은 제한되어 있고
주어진 시간안에 어떤 애플리케이션을 설계하게 됩니다.

시간이 무제한 주어진다면.. 이를테면 10년줄테니 뭐 하나 만들라 하면
생산성 고려 안하고
가장 Low Level에서부터 제어가 가능한 언어를 사용하여
자기가 처음부터 다 다시 만들면 됩니다. OS도 올리지 말고요..그게 최선이죠 성능상으론.

그렇지만 실상 이런경우는 없습니다.
길어야 1년.. 보통 몇주안에 뭔가를 만들어서 프로토타입이라도 Boss에게 보여줘야 하는게
현실이란건 너무나 자명합니다.

이런상황에서 본질적인 생산성을 빼놓고 성능을 논하는건 의미가 없습니다.

아시다 시피..

Assembler 로도 충분히 Library를 만들어서 쓸수가 있습니다. 단지 High Level Language에 비해서 그걸 관리함에 있어서
'간지'가 안나는 차이죠. 이식성은 말할필요도 없고.

이런상황에서 단지 극한의 성능을 끌어 낼수 있는건 특정 분야로 한정됩니다.

현실적인 상황에서 성능 이슈는 생산성을 '철저히 배제한' 상태에서는 아무 의미가 없다고 봅니다.

free1002의 이미지

(버럭질은 모르겠고 뜬금없는 논점일탈 1인 입니다;)

select99 님이 약간 다른 차원에서 언급을 하셨습니다만.. (http://kldp.org/node/96772#comment-453992)

잘못해석한것인지 모르겠지만, 제게는 'C++ 비슷한 코드 대비 퍼포먼스가 더 높은 결과물을 냈으므로 생산성이 더 높다' 로 들렸고, 이는 대부분의 사람들이 이야기하는 '생산성'의 개념과 달라보여서 덧글 달았습니다.

* 그래도 퍼포먼스 영 안나오면.. JNI로 밀어버리는 방법이 있겠죠.; 단, 시니어 분들이라면 절대로 막겠지만요. '24시간 돌아야 할 서버에서 메모리 릭 나면 니가 책임질꺼야?' (예전에 모 포탈 알바할때 JNI 지원하는 Template Engine 에 대해 함 찔러봤었는데, 그때 지적된 문제점이 '메모리 릭이 없다는 점을 장담할 수 없다' 였습니다.)

fender의 이미지

음... 로그인한 김에 한 마디... -ㅅ-;

(1) 같은 아파트에 사는 A와 B는 같은 회사에 다닙니다. 운동을 잘하는 A는 100m를 10초에 뛰고 그렇지 못한 B는 30초에 뜁니다. 그럼 A가 차타고 한 시간 거리인 회사에 B는 세 시간 만에 도착할까요?

(2) 추석 때 최고속도가 120km/h인 버스를 타고 꽉막힌 고속도로를 달려 고향에 가면 6시간이 걸립니다. 그럼 최고속도가 360km/h인 경주용 차를 타고 가면 두 시간만에 갈 수 있을까요?

(3) C로 15줄로 짤 수 있는 '하노이의 탑'문제를 해스켈로 4줄만에 짤 수 있습니다. 해스켈의 LOC가 거의 1/4 수준이니 당연히 생산성도 4배이고 따라서 C로 하면 4달 걸릴 프로젝트가 해스켈로 하면 한 달만에 끝날까요?

쓰신 글을 보니 자바나 C/C++이 사용되는 실무에서 '성능'이나 '생산성'의 개념이 어떠한 것인지에 대해 아직 정확한 이해를 못하고 계신 듯 합니다.

어느 기술이나 주류가 되어 오래 쓰이다보면 이를 둘러싼 hyph나 myth, 혹은 관성 따위도 많이 생기는 건 사실입니다. 하지만 어떤 기술이 동일한 일을 하는 다른 기술에 대해 생산성이나 라이브러리 지원은 비슷한 반면 실무에서 4배 이상 성능차가 날 정도라면 그런 허접한 기술을 10년 넘게 주류로 쓸만큼 IT기업이나 엔지니어들이 멍청하지는 않습니다.

선입관을 배제하고 JIT나 실무에서의 벤치마크/최적화에 대해 좀 더 공부를 하신다면 그런 단순 루프로 성능을 이야기하는 것이 얼마나 부질 없는 일인지 깨닫게 되실 것 같습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

pythonart의 이미지

속도 때문에 VM 을 쓴다 라고 주장하시는 분도 없는거 같은데 불필요하게 길어질 필요가 없을 듯.

C 라면 하나의 파일에 다 때려넣고(static link), 모두 캐시에 올라가면 엄청난 속도로 실행 되지요.
느린 자료구조나 특정 검색 알고리즘에 기반한 것이라도 ++ 의 STL 을 동원하면 직접 알고리즘 코딩 안해도
어셈블리 다음으로 빠릅니다.
그런데 위를 보니 직접 해보자고 하시는 분들도 있는데 귀찮으니 직접 해보자고 하지 마세요. ㅋㅋ

이건 너무나 당연한 얘기고..

안 당연한 얘기를 하나 해보죠.

대부분의 시간이 최적화 된 코드로 짜여진 VM 내에서 소요되는 경우라면 두 코드간의 속도 차이는 확 줄어 듭니다.
극단적인 예를 들면 DB 에 쿼리를 날리고 결과를 받기까지 10 초 걸린다.
콜에 0.01 초 걸리는 C 코드나
콜에 0.1 초 걸리는 JAVA 나 속도 차이는 거의 없다 말이죠, 어차피 대부분의 시간이 DB 에 걸리기 때문에.

이와는 반대로 속도가 매우 중요한 경우가 있습니다.

0.5배 0.2배 같은 속도가 차가 별거 아닌거 같지만 동영상 인코딩 따위를 생각해보면
30분이나 1시간 걸리는 작업일 때 그 차이는 어마어마 합니다.

결론만 말하자면..

CPU 최적화를 동원해야 하는 특수한 경우를 제외하고는 차이는 별로 없습니다.

그 이유는.. 지금 사용하는 컴퓨터의 프로세스들의 CPU 점유율을 보시면 압니다.
대부분의 프로세서가 놀고(?)있는 상태죠.
이런 어플리케이션들은 뭘로(?)짜도 커다란 속도 차이는 못 느낍니다.

사용중인 코드의 대부분의 시간이 API 나 VM 내부의 루틴을 부르고 있기 때문이라고 생각하면 될거 같습니다.
사실 우리가 만드는 어플리케이션이 거의 모두가 요렇게 돌아갑니다.
아 뭐.. 대량의 데이터(압축, 이미지, 동영상 등)나 극한 수준의 다사용자(게임서버 같은)를 취급하거나..
엔진이나 라이브러리 자체를 개발하는 경우는 제외 합니다.

요는...
저렇게 "속도가 그다지 중요하지 않은" app 개발에 있어서, 굳이 어렵게(장치 의존적으로) 개발할 필요가
있겠느냐 하는 것 입니다.
장치 비의존적이게 되면, 한번의 코딩만 해두어도 이식과 유지보수가 너무 편한데다가
개발 속도도 상당히 빠릅니다(저는 이것이 디버깅이 손쉽고 빠르기 때문에 얻는 이득이라 봅니다)

어쨌건 이런 요구들로 인해 우리가 접하는 많은 프로그램들(더이상 c/c++ 로 cgi 개발 안하죠)이
VM 형태로 개발되고 그 영역을 확장해 나가고 있습니다.

추세가 그렇게 갑니다..
과거의 어셈이 하던 일을 c/c++ 가 물려 받고, 그 상위 언어가 등장하는 시대지요.
굳이 쉽게 만들걸 어렵게 해야 할 시대는 지나가고 있습니다(지났습니다 라고 쓰자니 좀 그렇네요)

막 삽질하다가... 해결책을 발견했을 때.. 모두가 그런 생각을 하죠..
삽질 했구나....
저는 java 가 처음 나왔을 때 그걸 보고 생각했죠.. 아 ㅅㅂ.. 여태까지 삽질했네...

그래도 어쨌거나..
현재로는, 속도나 하드웨어 의존성이 큰 부분을 asm 이나 c 가 아닌 언어로 짠다는건 생각하기 어렵습니다.

P.S 이건 사족 입니다만.

opengl 을 파이썬으로 핸들링 했는데(폴리곤이 백만개 정도?, 숫자가 작을땐 쓸만 합니다)
도저히 느려서 쓸 수가 없더군요 -_-.
그래서 랜더링은 부분적으로 C 로 모듈을 만들고 메모리를 공유하는 방법 밖에 없었습니다 -_-.
C/C++ 에 비하면 "개발" 자체에 걸리는 시간은 매우 빨랐습니다.
한 10배 정도 빠른듯.. 도깨비 방망이 처럼 순식간에 뚝딱!! 하고 만들어짐 -_-.
하지만 결정적으로 실행이 더디다는거 ㅋㅋㅋㅋ....

그리고 저는 자바 안씁니다. 자바가 싫어서가 아니라.
쓸 일이 없었습니다 요구도 없었고요(C++ 만 써도 충분해서리, 나이 좀 먹어서 그렇습니다 이해 바람).
어쨌건 그래서 자바에 대해서 더 깊이 물으시면 할 말이 없습니다.
윈도에서 python 과 mingw 장난삼아 씁니다. 특히 STL 은.. ++ 의 꽃. ㅋㅋ.

DarKMinD의 이미지

어느 분께서 넘겨 주신 7페이지 글은 재미로 읽었지만 이글은 지쳐서인지 그렇지 못하겠네요 =_=;;

어찌되엇건 순수하게 속도는 이미 결론 난거 아닌가요?
더이상의 이 동작의 최적화 된 소스다. 뭐 이런식으로 해봐야 결론이 바뀔거 같지 않네요.

논 외로 글을 좀 쓰자면...
실제 프로그래밍으로 일을 하게 되면서 언어적 속도 차이 때문에 메인 언어 자체를 바꾼적이 없네요.
핵심이 되는 부분이 해당 언어에서 더이상 최적화가 될 수 없다 라는 결론이 나게 되면 그 때서야 C언어로 코드를 작성하여 DLL로 불러 들이는 방법을씁니다. (만약 처음부터 C언어로 작성하게 되었다면.... 메모리 해제 문제, 함수 사용법등등 때문에 저런 최적화는 엄두도 못내고 있었겠죠. 또한 기간이 늘어나고 신경 쓸게 많아질수록 코딩하는데 드는 힘과 비용은 자연스럽게 늘어나게 되어있습니다. 결국 결과물 속도 때문에 이러한 비용이 추가 되어 나중엔 엉망이 될 수 있습니다.)

언어적 속도만을 따지게 된다면 C나 어셈이 결국 답입니다.
하지만 같은 동작을 하는 코드, 프로그램을 만드는데 실제로 속도 때문에 문제가 될 것이 아니라면 더 쉬운 언어로 작성하는 것이 더 현실적입니다.
부수적인 최적화 때문이라면 해당 언어에서 네이티브 C언어로 작성 된 DLL을 임포트하여 대신 처리하게 하면 되는것입니다.
자바나 닷넷이나 기타 다른 많은 언어들은 C언어로 작성 된 외부 라이브러리를 임포트 하여 쓸 수 있습니다.
한가지 언어를 고집하는 것 보다 저 언어는 뭐가 좋은거지? 정도는 생각해 보는 것도 좋지 않을까요?

어느 상용 게임 서버는 스크립트 언어가 임베디드 되어 돌아가고있습니다. 스크립트 언어로 작성 되어진 로직으로 처리가 되는 것임에도 실제 서비스에 문제가 없다고합니다. 또한 언어적 장점 때문에 많은 업데이트가 고급 프로그래머가 아닌 기확자들 선에서 이루어 진다고합니다. 서버이니까, 빨라야 되니까 C를 쓴다. 라는 결론이 나게 된다면... 아마 저런 것은 불가능 했겠죠. 뭐가 더 빠른가.. 를 아는 것은 좋다고 생각됩니다. 하지만 뭐가 더 빠르기 때문에 더 좋은 것이다. 라고 결론 지어 지는 것은 왠지 좀 아니라고 생각됩니다. 물론 개인적으로, 개인용으로 뭔가 만들 때는 개인적인 사상으로 하는 것은 문제라고 생각되지 않습니다. 하지만 실제 일을 하게 되면 수많은 개발자들은 속도 보다는 효율을 찾게됩니다. (저 또한 개인적인 취미로 만드는 것은 델파이나 C++을 이용합니다. 하지만 실제 일을 할 때는 C#이나 자바를 더 선호합니다. 예외적으로 윈도우즈 98에서도 돌아가며 추가적인 라이브러리가 없어도 실행 되면 좋겠다. 라고 요구 되는 것은 종종 델파이로 작성합니다.)

암튼 결국은 코드 대결이 되어 지는 댓글들을 보니 서로의 약점을 공격하고 약점을 감추려하고 노력하는거 같아 별로 좋게 느껴지지 않습니다. 혹시나 위의 소스를 작성 하신 분은 실제 프로그래밍 할 때 위의 소스를 많이 이용 하실건가요? 이런 상황에서 밖에 예가 되지 않는 코드를 보려고 이 메인 글이 작성 된거 같지 않은데... 라고 느껴지는 댓글을 보니 좀 씁쓸합니다.

덧. 이 글에도 반문이 달리겠죠? =_=

bookgekgom의 이미지

자바가 느리던 빠르던

씨가 빠르던 느리던

어쩌라는건지

톱으로 회를 만들지 못하고

식칼로 나무를 배지못하는법.

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

codepage의 이미지

이 글들 다 읽어 봤는데
도중에 어떤 분의 말씀처럼 실제 사례를 놓고 이야기 하는 것이 합리적이지 않나 생각되네요.
또한가지는 다른 곳에서 이미 논쟁이 벌어졌던 일을 다시 논쟁하는 것은 무의미하다?
이건 아닌 것 같은데요.

일단 제 의견을 말씀 드리면

요즘 실제 시스템에서 돌아가는 프로그램 중에 위의 예처럼 I/O 없이 메모리 연산만 하는 프로그램이 얼마나 있을까요?
그리고 그것도 Single Thread에서...
Multiple Thread쓸 경우에 C에서 MUTEX나 Condition Variable을 쓸 경우와 JAVA의 synchronized하나 잘 씀으로써 구조적 안정성을
확실하게 보장하는 뭐 그런 '생산성'(이런 문제에 의해서 발생하는 오류를 잡는데 들어가는 시간이나 노력 절감)도 있을 수 있겠구요.
Application의 성능을 높이는 방법은 사실 얼마나 CPU 점유율을 효율적으로 유지하면서 I/O를 효율적으로 처리할 수 있는냐가 관건일 거구요
뭐 처리할 양은 엄청 많은데(1000만 건의 고객 데이타를 주어진 시간에 처리) 맨날 I/O만 하고 있고 CPU 점유율 10%미만인 상황...이런 어플리케이션은 생각하기도 싫습니다.
그런 상황에서 메모리로 데이타 Move하는것보다 일반적으로 Cost가 100배 이상 쓰는 I/O의 효율화에 촛점이 맞춰지는 것은 당연하고요
전체 실행 시간에서 아주 미미한 비중을 차지하는 CPU-to-Memory 연산만 갖고 드립다 성능 비교 sample을 쓰는 것은 좀 맞지 않다고 보여지는군요.

klutzy의 이미지

벤치마킹이라는게 그리 쉬운 일이 아닙니다. 특히나 성능을 평가할 때는 이런 식의 코드는 아무 대답도 해주지 않습니다. 마라톤 선수들한테 50m 뛰게 해놓고 시간 재는 거죠.. :P

며칠전에 dW에 재미있는 글이 올라왔길래 링크합니다.
http://www.ibm.com/developerworks/kr/library/j-benchmark1.html
"믿을 만한 자바 벤치마킹, Part 1: 다양한 이슈"

mulgo79의 이미지

자바나 C나 각각의 장단점이 있을 터인데.. 어떤게 빠른가를 과연 정할수 있을지

개발 환경 컴파일 환경 운용 환경 개발자 역량 등 여러가지 요소를 전부 조합해야

최적의 코드와 최적의 실행 환경을 만들수 있을것이라 생각합니다.

저같은 경우는 개발기간이 너무 초박한데 비해 성능에 대하여 제약을 받지 않는 것

이라면 자바쪽을 택하고 성능에 제약을 많이 중시하는 것이라면 C를 택하고 있습니다.

비단 이것들 뿐만이 아니라 자바나 C나 서로의 장단점이 있을 것이라 생각합니다.

그 무슨 언어를 사용하든간에 프로그래밍은 기본은 같은 것이라 생각합니다. 아움~~ 라면 묵어야지 ㅎㅎ

brianjungu의 이미지

C가 더 빠르면 뭐가 좋은거죠?

월스트릿에서 파생상품거래 같은거 하는 플랫폼도
자바로 만드는 판에, C가 Java보다 훨씬 빠르다는 걸 증명해서
뭘 얻고자 하는지 모르겠습니다.(트레이딩 플랫폼은 잠깐의
딜레이도 심각한 손실로 이어지기 때문에, 결코 용납되지
않습니다. 최적화에 병적으로 집착하는 영역중에 하나입니다.)

시장주의자의 논리 같기는 하지만, 현실적으로 C보다 Java를
쓰는 곳이 훨씬 많습니다. 윈도우가 거지 같다고 20년전부터
그렇게 욕을 했지만, 어쨌건 지금은 윈도우 세상입니다.

불필요하고 소모적인 논쟁에 시간 보내지 말고, C가 필요하면
C를 쓰고, Java가 필요하면 그러면 됩니다. 무슨 학교서열
매기는 것도 아니고, 이게 무슨 짓입니까.

gurugio의 이미지

저는 어셈블리를 공부하면서 어셈블리 사이트를 운영하기 시작했습니다.
저 나름대로는 약간의 최적화 지식과 노하우를 알고있다고 생각합니다만
현실세계의 문제를 가지고 말 몇마디로 판단하고 싶지 않아서
항상 최적화에 대한 문의가 들어올때마다 고사하곤 했습니다.

자바와 C의 속도 비교에 대한 이 글타래를 보니
요즘 지식e 인가하는 EBS 방송이 생각닙니다.

그리스인들이 수많은 논쟁과 토론으로 문제를 해결해왔는데
그게 비효율적이고 문제도 많았지만
결국 지금 민주주의의 시초가 되었다는 방송이었습니다.
이런 토론으로 많은걸 배울 수 있어서 감사드립니다.

단지 저 사람이 지금 뭔가 옳지 않은 짓을 하고 있다는 사명감을 자제하면 좋겠습니다.

----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio

김일영의 이미지

부정적이신 분들이 상당히 계시군요.
그런데 그러면 이렇게 소스 코드 가지고 비교하는건 무의미한겁니까?
이런 류의 비교는 Sun사도 하고 있고 자료도 배포하는데 그 자료들만 의미가 있고 이렇게 다른 결과가 나오는 테스트는 무익한 것인가요?
테스트한 소스가 일반적이지 않다고 해도 분명한 하나의 비교 자료가 되는 것이고
또 이런 식으로 많은 종류의 소스를 비교해보면 충분히 일반적인 결과가 나올 것이겠지요.
Java나 C에 호불호를 가리지 않는 사람으로서 충분히 관심이 가는 내용인데
테스트 자체에 부정적인 분들이 많은 점은 좀 뜻밖이로군요.
오히려 이런 류의 비교 테스트 자료가 많아지면 구체적으로 어떤 알고리즘을 수행할 때는 평균적으로 얼마나 차이가 나는지
잘 알 수 있어 많은 도움이 되리라 생각됩니다.
앞으로 더 많은 내용 기대합니다.

brianjungu의 이미지

그게 의미있는건 그 과정을 통해서 무언가가 도출돼서 실행될 때입니다.
아무런 실행없는 논쟁과 토론은 탁상공론이나 소모적인 일에
다름아니라고 생각합니다.

그리스인들도 분명 많은 시간과 노력을 들여 논쟁과 토론을 했지만,
그들은 그것을 통해 분명히 결론을 도출하고 실행에 옮겼습니다.

마르쿠스 아이렐리우스같은 철학자 황제가 왜 제국을 쇠망의
길로 이끌었는지도 눈여겨 보아야 할 필요가 있습니다.

자바와 C의 성능논쟁을 본게 제 기억으로 벌써 7년이 넘은 것 같습니다.
처음에는 C가 압도적이었다가, 이후에 JVM성능이 개선되고, HotSpot같은
기술이 도입되면서, 무게추가 기울었고, 지금은 자바자체가
시장에서 워낙 많이 쓰이는 기술이 돼버린 상황이라서, 어느정도 이런
논쟁이 수그러 든걸로 봅니다.

제가 이 논쟁이 불필요하다고 말하는 건,
첫번째 너무 오랫동안 지속돼 왔습니다. 특히나 한국에서 말이죠.
두번째 이 논쟁이 전혀 생산적이지 못한데에 있습니다. 그동안 이런
류의 토론을 여러차례 봐왔지만, 이런 논쟁이 C나 자바세계의 지평을
넓혔다거나, 뭔가 새로운 방향이 제시되었다거나 하는 것을 본적이
없습니다.

오직
C가 최고냐 자바가 최고냐, 내가 빠르다 네가 느리다
이 예기의 반복이었을 뿐입니다. 특히나 이 논쟁의 주도자들이
C를 주로 사용하는 인력들이라는데 더 문제를 제기하고 싶습니다.

이런 속도논쟁을 하는 것보다, 자바가 C세계를 얼마나
풍부하게 해줄수 있는지, C가 자바를 얼마나 풍부하게 해줄수 있느지에
대해서 논의하는게 훨씬 더 유익한 일이라고 봅니다.

자바 기반으로 수많은 프레임웍이 나오는 상황에서,상대적으로 기업
시장에서 입지가 줄고있는 C가 자바와의 연결접점을 찾아, 보다
확장될 수도 있는 문제가, 자바 역시 그 반대로, Mission Critical
한 부분에서 C와 연결되어, 획기적인 성능향상을 이루어낼수도
있습니다.

Ruby같은 경우는 자바나 다른 랭귀지들과 지속적으로 연결접점을
만들어내며 그 세계를 넓혀가고 있는데, C는 언제까지 무가치한
속도논쟁으로 세월을 보내고 있을겁니까?

왜 이런 종류의 글을 보는 사람들이 대부분 부정적인 반응을 보이는지
정말 모르시나요?

bookgekgom의 이미지

제가 하고싶은 말을 이렇게 논리적이게 ;ㅅ; 추천한방하고 갑니다.

저 감동먹었음.

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

김일영의 이미지

성능을 따져 보는 것이 무가치하다면
전산학과가 있어야 할 이유가 절반은 없어질 겁니다.

CPU가 그냥 빨라지는구나 생각하십니까?
Sun이나 MS는 왜 성능 비교 자료를 만들었다고 생각하십니까?
JVM 자체는 성능에 대한 고민 없이 그냥 빨라진다고 보십니까?

이게 다 남의 일이 아니라 이걸로 밥먹고 사는 우리 일입니다.
디딤돌 하나라도 댄 분에게 쪽박을 깰 필요야말로 없는 것이 아니겠습니까.

fender의 이미지

문제는 저런식의 성능비교와 논쟁이 정말로 '디딤돌 하나'라도 먼저 쌓는 건설적인 것이냐는 것아닐까요?

정말 건설적으로 벤치마크에 대해 이야기를 하고 싶다면 우선 실무에서 중요한 '성능'의 개념이 무엇인가부터 제대로 이해하고 시작해야 합니다. 설사 처음에는 이해를 못하고 문제제기를 했다 하더라도 최소한 다른 사람이 지적을 하면 열린 자세로 배운다는 생각은 있어야겠지요.

저런 식의 마이크로 벤치마크가 큰 의미가 있는 건 아니지만 그럼에도 불구하고 구글링만 잠깐 해봐도 훨씬 다양한 알고리즘, 환경에 대한 비교 자료도 얼마든지 나오고 동적최적화에 대해 궁금하다면 역시 JIT에 대한 기술자료 역시 별 노력없이 얼마든지 구해볼 수 있습니다.

그런 상황에서 기존 자료나 다른 사람의 지식을 먼저 이해하려는 노력을 하지않고 간단한 코드 하나 가지고 마치 특정 언어가 빠르다는 주장이 거짓말이라는 식의 표현으로 논쟁에만 불을 붙이는 것이 결코 생산적이 될 수는 없다고 생각합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

DarKMinD의 이미지

- 이게 다 남의 일이 아니라 이걸로 밥먹고 사는 우리 일입니다.

네. 전 프로그래밍으로 밥먹고 삽니다만...
이러한 성능 비교로 뭐가 더 빠르다고 단순 연산 결과물로 먹고살지 않습니다.
왜냐고 물으신다면... 그거에 연연하면 프로잭트가 망하거든요..

http://www.python.org/ 파이선 홈페이지 메인입니다.
NASA uses Python... 이라는 제목이 보이시나요?
속도가 빨라서 나사에서 파이선을 쓰는 것일까요?

다음은 왜 C로 짜여진 CGI를 벋어났을까요?
혹시 C가 더 빠른데 왜 다른 언어를 쓰느냐고 생각 하시는건 아니겠죠?
왜 수많은 기업들은 C언어 말고도 다른 언어를 쓰는 것일까요?
혹시나 알고 계신가요?

이 글이 속도에 중점을 둔 글이라 어떻게 하면 같은 소스로도 더 빨라지더라. 라는 결론과 어떠한 구조로 바꾸면 해당 언어에선 더 효율적이더라. 이러한 결론이 생겼으면 좋겠습니다.
한가지 코드가지고 뭐가 더 빠르더라. 라는건 마치 3D Mark가지고 그래픽카드 성능을 비교해서 결론을 내어 버리는 것과 다를거 없다고 생각됩니다.
그러한 비교 속에서도 자신은 무엇을 하는데 여기에 더 좋은건 뭔가요? 하면 이 카드가 3D Mark성능 점수가 놓아서 이걸로 쓰면 된다. 라고 하는 사람 거의 없습니다.

프로그래밍이라는건 어디에 어떻게 사용될지 모르는 것입니다.
또한 전산학이 성능을 비교하고 성능이 더 빠른 것을 이용하도록 하기 위한 것인가요?
효율도 생각 해야 하는것은 당연하다고 생각 되는데요.. 절반이라고 하시니 전산학의 절반이 성능을 따져서 무언가로 하는 것 처럼 보이네요..

mulgo79의 이미지

왜들 이렇게 열을 내시고 그러시나요

C나 Java나 다 좋은 언들이고 다 각각이 필요할때가 있는 법인데....

적절히 쓰면 다들 좋은 언어들이고 좋은 기술들인데...

전부 빠른게 필요하다면 다들 비행기를 타지... 개발에 필요한 요소요소를 고려하면

필요합니다...

jokerol의 이미지

논쟁을 부추길 만한 마음은 추호도 없습니다. 토론, 토론은 즐거운 거죠. 토론이 격해지면 논쟁이 되기도 하지만,

제 생각은 '노력 없이 이루어 지는 건 하나도 없다' 입니다. 어떤 이득을 취하기 위해선 뭔가 다른 대가를 지불하게 되는 경우가 거의 되부분이며, 세상의 오래된
이치죠. 자바는 개발자의 편의와, 플랫폼 의존성을 해결 하기 위해 OS 위의 또다른 존재 에서 동작하기를 택했고 결국 이것은 한 과정을 더 거처서
동작하는 것이 되므로 기타 위에 말한 장점을 위해 속도를 어느 정도 희생한 거죠.

씨 역시 어셈블리에서 좀더 개발하기 쉬운 언어를 만들기 위해 속도를 조금 포기하고 컴파일이란 과정을 이용하게 되었습니다.

이처럼 나중에 나오는 언어들은 점점 복잡하게 커지는 프로그램을 쉽게 만들고 관리하기 위해 속도를 조금씩 포기하며, 진화한 것이죠.자바는 그렇게 원하지는
않았 겠지만 속도를 많이 잃은 케이스라고 생각합니다.

그러니, 순수하게 속도만을 고려한다면 나중에 나온 언어가 전에 나온 언어를 속도의 관점에서 따라잡기란 여간 어려운게 아니겠죠.
그래서 제가 생각하기에 여기서 C나 C++ 자바의 순수 속도를 논하는건 컴파일 언어의 승리라고 생각합니다.
만일 그렇지 않다면 , 제가 아는 한 상용이 된 자바 기반의 3D게임이 없다는 것이 잘못된 것인것 같네요.

그래서 자바 진영에서 JVM을 각 OS에 맞게 최적화를 시키고, 곧바로 바이너리 로 만드는 기술이 나오고는 있지만 아직은 역부족인 듯합니다.
하지만 격차가 계속 줄어들고 있고 기술이 계속 발전하니까 거의 느낄수 없는 수준까지 가능할꺼란 생각은 듭니다.

게다가 요즘 같은 세상에 순수 속도 대결은 의미가 없다고 봅니다. 진짜는 실제로 수만줄의 코드가 맞물리며 생기는 여러가지 원인과 결과에 의한
퍼포먼스와 유지보수의 편이성 생산성이 다 고려된 것이라고 봅니다. 그런 관점에서 보면 순수 C는 많이 뒤 떨어지게 되겠죠.
그렇다고 자바 개발자들이 희희낙락할수는만은 없겠죠. JVM과 같은 프로그램은 누가 만들었겠습니까?

결말은. 뻔한 얘기지만,(거창하게 말하다 뻔한 결말을 지으려니 창피해서 웃음이 나네요ㅋ)
속도문제 같은걸로 서로 헐뜯지 말고 서로의 장점을 인정하고 필요에 따라 사용을 할수 있는 실력과 경험을 가지는게 중요하다고 생각됩니다.
진정한 프로그래머라면 두루두루, 가능하다면 하드웨어 까지 알아야 한다고 생각합니다.

모든 계산이 컴퓨터를 사용해 가능하다고, 직접 계산하는 법이나 수학을 등한시 하지 않는 것 처럼요.
우리가 수학등을 알기에 컴퓨터를 더 잘사용하는 것처럼 어쨋든 세상은 점점 상위레벨 언어에 유리하게 굴러가겠지만
상위레벨 언어도 하위 레벨을 잘 알아야 더 잘 할수 있고 존재 할수 있다는 거죠.

it takes a day to make you yawn, brother

it takes a day to make you yawn, brother

jokerol의 이미지

제 글이 마지막 이였으면 좋겠습니다 ~

it takes a day to make you yawn, brother

it takes a day to make you yawn, brother

DarKMinD의 이미지

마지막이 되야겠지요 ㅎㅎ;
그나저나 자바는.. 솔라리스에서 더욱 빠르다는 소리가 있던데 거기에 대한 성능 향상의 %가 측정 된 값이 있는지 찾아 봐야겠네요 ㅎ;

jokerol의 이미지

it takes a day to make you yawn, brother

솔라리스야 선에서 만든 거니 당연히 최적화를 훨씬 잘 해놨겠죠.. 자바도 선에서 만든건데~ ㅋㅋ

it takes a day to make you yawn, brother

hongminhee의 이미지

이런 류의 논쟁을 볼 때마다 생각나는 것은…

  1. 엄밀히 따지면 언어의 성능 비교가 아니라, 언어 구현의 성능 비교이니 C가 느리니 Java가 빠르니 할 것이 아니라, 어떤 컴파일러 혹은 어떤 VM 같은 구체적인 “어떤 구현”이 느리고 빠르더라 해야하지 않을까 하는 생각이 듭니다.
  2. 같은 코드라도 C++나 D의 템플릿 같은 것을 이용해서 컴파일 시간 메타프로그래밍(compile-time metaprogramming) 기법으로 작성한다면 특정 케이스에서 심지어 상수 시간 내의 결과를 얻어낼 수 있는 경우도 있습니다. (아예 루프를 돌지 않는다던가.) 언어 혹은 언어 구현의 성능 비교에서 이런 부분도 포함시켜서 생각해야 할까요?
gh0st의 이미지

원래의 글이 C와 자바의 성능비교(실행성능이라 생각됩니다)였는데...

댓글 읽다가 다시 처음 글을 보니 어리둥절 하네요.

자바가 C보다 빠를 수도 있는 건... 자바쪽 마케팅의 결과라 생각하고

인터넷의 수많은 논쟁을 보면 어느 정도 성공한 거 같아요.

뒤늦게 뚱딴지 같은 글 죄송합니다. 총총총...

--------------------
네트워크의 미래는...

네트워크의 미래는...

kalstein의 이미지

C 언어 상세표를 보시면 아시겠지만...매우 간단합니다. 덕분에...C 가 porting 되지않는 환경은 없죠. (최적화는 그 후에 문제죠. 일단 언어부터 있어야 ^^;;) 대신 JAVA는 뭔가 해줘야되는게 많죠. (C++은...뭐....ㅡ _-;; 언어가 워낙 복잡해서리)

C의 경우는 정말 다양하게 쓰일 수 있는 그런 환경이 필요하고, 성능의 주요팩터가 되는 라이브러리의 핵심코어 구현에 잘 어울리는것 같습니다. 거의 모든 언어가 C와의 연동문제를 매우 중요시하고 있지요. 반면에, 언어 자체에서 OOP를 지원하지는 않기 때문에, SW개발의 대세와는 조금 어울리지않는 모습을 하고 있는거죠. (못한다는건 아닙니다. 리눅스처럼 여러환경의 포팅을 생각하고 있다던가 하면, C만한 언어가 없지요 ^^)

뭐 JAVA는 반대적인 성향이 있는거구요. 그 중간에 걸친게 C++이 되겠지요.

그런데...Performance Critical 한 프로젝트 하시는분들 많습니까? 해당 영역에서 프로젝트를 진행중이시라면 어느정도 성능 최적화가 되어있으신가요? 제 생각입니다만....성능이 매우 문제시 되는 영역은 크게는 많지않은것 같은데 말이죠 ^^;;;; 일단 우리나라 SW에서 SI가 대다수... 어느정도 빠르면 되죠. 즉, 10초 이내에 실행되면(반응을 보이면) 될껄? 이런식이지... 0.1초 이내에 뭔가 해야된다던가...그정도 레벨은 크게 많지않을꺼 같은데요. 흠... 게임엔진 개발쪽이라면 좀 다르긴하지만요.

뭐...제가 있는 곳에서는 최적화를 잘해야된다고 하고 그것이 매우 중요한 factor입니다만...여기저기에 난무하는 if문에 대해서는 아무런 개념이 없더라구요. 계산에서 1cycle 줄이는것보다 if문 하나 없애는게 월등히 유리한건데 말이죠 ㅎㅎㅎ

------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

taehun3718의 이미지


전 이런거 별로 신경안씁니다.

그럴꺼면 c와 어셈블리어와 성능 최적화 한것을 보여주세요.
c와 어셈블리어 성능 차이를 모르시는건 아니겠지요?ㅋㅋ

asm > c > c++ > java 순이겠지만

님들이 암만 java쓰지 말라고 해도.
쓸사람은 다 씁니다.

근대 c보다는 개발도 편한 java를 쓸꺼에요.
같은 시간이면 java가 개발 시간이 더 빠르니까요.

페이지