현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

자바가 C(or C++?) 보다 8배 느리다?

leonid의 이미지
글쓴이: leonid / 작성시간: 금, 2006/09/01 - 5:29오후

음 일단 프로젝트는 자바로 하기로 결정했습니다.
무엇보다도 자신에게 익숙한 언어로 프로그래밍을 하는 것이
가장 현명하다고 판단했어요.

제가 어디서 들어보니

자바의 수행 속도가 C(C++이었나)보다 8배가량 느리다고 하는군요.

이 말이 진실인지 헛소리인지 알려주세요.

헛소리였으면 좋겠네요.

Forums: 
프로그래밍 QnA
kpserv의 이미지

글쓴이: kpserv / 작성시간: 금, 2006/09/01 - 5:55오후

어떻게 쓰느냐에 따라 달린것 같습니다!!
자바가 50배나 느리다라는 것을 본기억이 있습니다...
또 역서는.. 8배나 느리다고하구!!

결론은... 자바는 느립니다... 하지만 어떻게 최적화 되느냐에
그 차이를 줄일수 있을것 같습니다!!

#define DEBUG printf( "%s, %s, %d\n", __FILE__, __FUNCTION__, __LINE__ );

leonid의 이미지

글쓴이: leonid / 작성시간: 금, 2006/09/01 - 6:13오후


C로 하루 종일 걸릴 작업이
같은 수준으로 최적화된 자바로는 50일이 걸린다는 얘기로군요.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 일, 2007/01/07 - 6:10오후

실행환경
AMD Sempron 1.66GHz, 512M Ram, WIndows XP sp2
C: VC++ 6.0 (Release Mode)
Java: JDK 1.6 (Server Hotspot)

1. loop inline code

C Code 

#include <iostream>
#include <stdlib.h>
#include <time.h>
 
long sum = 0;
bool c1 = true, c2=true;
 
int main(int argc, char *argv[]) {
	time_t start;
	time_t end;
	time_t elapsed;
 
	int i,j;
    int n = 2000000000;
 
	int count = 5;
 
 
	start = time (NULL);
	for(i=0; i< count;i++) {
		for(j=0; j<n;j++){
			if ( c1 == true){
		if (c2 == true) {
			sum ++;
		}
		else {
			sum--;
		}
	}
		}
		c2 = ! c2;
	}
 
    end = time (NULL);
	elapsed = end - start;
 
 
	cout << "elapsed:" << elapsed;
    return(0);
}

Java Code

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

결과 :
VC : 31초
Java : 32453 miliseconds

2. Call function

C Code

#include <iostream>
#include <stdlib.h>
#include <time.h>
 
 
void calc();
 
long sum = 0;
bool c1 = true, c2=true;
 
int main(int argc, char *argv[]) {
	time_t start;
	time_t end;
	time_t elapsed;
 
	int i,j;
    int n = 2000000000;
 
	int count = 5;
 
 
	start = time (NULL);
	for(i=0; i< count;i++) {
		for(j=0; j<n;j++){
			calc();
		}
		c2 = ! c2;
	}
 
    end = time (NULL);
	elapsed = end - start;
 
 
	cout << "elapsed:" << elapsed;
    return(0);
}
 
void calc() {
	if ( c1 == true){
		if (c2 == true) {
			sum ++;
		}
		else {
			sum--;
		}
	}
}

Java Code

public class Speed {
	static boolean c1 = true, c2=true;
	static long sum = 0;
	public static void main(String[] args) {
		int i,j;
		int count = 5;
		int n = 2000000000;
 
		long start, end, elapsed;
 
		try {
			Thread.sleep(5000L);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		start = System.currentTimeMillis();
 
		for(i=0; i< count;i++) {
			for(j=0; j<n;j++){
				calc();
			}
			c2 = ! c2;
		}
 
		end = System.currentTimeMillis();
		System.out.println("Elapsed time:"+(end-start));
	}
 
	private static void calc(){
		if ( c1 == true){
			if (c2 == true) {
				sum ++;
			}
			else {
				sum--;
			}
		}
	}
 
}

결과 :
VC : 62초
Java : 36172 miliseconds

결과 종합

          C          Java
---------------------------------------------
Inline : 31초        32초
Call   : 62초        36초
---------------------------------------------

혹시나 싶어서 n을 한 자리수 줄여서 call 방식을 다시 측정해 보았다.

결과 :
VC : 6초
Java : 4초(3938 miliseconds)

이 경우에도 마찬 가지로 자바쪽이 우세했다.

또 혹시나 싶어서 한자리수 줄인 n을 절반으로 또 줄여서 call 방식을 다시 측정해 보았다.
결과 :
VC : 3초
Java : 2초(1734 miliseconds)

결론 : 비교문이 Inline되었을때는 C가 근소하게 빨랐다.
하지만, 비교문을 함수/메소드 호출로 바꾸고 나서 C는 함수 호출 비용 그대로 비례해서 느려진 반면, 자바는 실행시간 최적화를 통해 훨씬 빠르게 동작함을 확인할수 있다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 일, 2007/01/07 - 6:18오후

혹시나 컴파일 과정에 해당 코드를 그냥 inline해서 위의 결과가 나오지 않았나 싶어서 디컴파일 해 본 결과

// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page: <a href="http://www.kpdus.com/jad.html
//" rel="nofollow">http://www.kpdus.com/jad.html
//</a> Decompiler options: packimports(3) 
// Source File Name:   Speed.java
 
import java.io.PrintStream;
 
public class Speed
{
 
    public Speed()
    {
    }
 
    public static void main(String args[])
    {
        int count = 5;
        int n = 0x5f5e100;
        try
        {
            Thread.sleep(5000L);
        }
        catch(InterruptedException e)
        {
            e.printStackTrace();
        }
        long start = System.currentTimeMillis();
        for(int i = 0; i < count; i++)
        {
            for(int j = 0; j < n; j++)
                calc();
 
            c2 = !c2;
        }
 
        long end = System.currentTimeMillis();
        System.out.println("Elapsed time:" + (end - start));
    }
 
    private static void calc()
    {
        if(c1)
            if(c2)
                sum++;
            else
                sum--;
    }
 
    static boolean c1 = true;
    static boolean c2 = true;
    static long sum = 0L;
 
}

보는 바와 같이 컴파일러가 해당 코드를 inline 시키지 않았음을 확인할수 있었다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 10:35오후

동일한 문제에대해 C하는사람과 자바하는사람이 짠코드입니다.
요구사항은

그럼간단히 스트링내의 원하는 문자 제거하는 함짜보세여 예를들면 스페이스라던가..
아니그냥 간단히 "skdkglsldslfldsf dskfkfsls ** dflsdf" d 제거하여 "skkglslslflsf skfkfsls ** flsf" 요렇게 되는거 만들어보셔요. 말만하지마시고. 얼마나 쉽게 되나 함바여..

이렇게 해서 짜게되었는데요..
누가 두함수 성능테스트좀 해봐 주세요...

자바코드 
static public String deleteChar(String str, char deleted){
        StringBuilder sb = new StringBuilder();
        for(int i = 0; i < str.length(); i++){
                char ch = str.charAt(i);
                if( ch != deleted ){ sb.append(ch); }
        }
        return sb.toString();
}
 
 
 
C 코드
 
void aaa( char *src )
{
char *s;
for( s = src; *s; s++ ) 
if( *s != 'd' ) { *src = *s; src++; }
*src = 0;
return;
}
 
 
 
 
메인함수
 
int main( void )
{
    char    a[128];
	int i;
 
	time_t start;
	time_t end;
	time_t elapsed;
 
	start = time (NULL);
 
	for( i = 0; i < 5000000; i++ )
	{
		strcpy( a, "skdkglsldslfldsf dskfkfsls ** dflsdf" );
		aaa( a );
	}
 
    end = time (NULL);
	elapsed = end - start;
 
 
    printf( "[%s]\n", a );
    printf( "elapsed: %d\n", elapsed  );
 
    return 0;
}

sephiron의 이미지

글쓴이: sephiron / 작성시간: 화, 2007/01/09 - 11:03오후

void aaa(char *)의 경우 인자로 넘겨받은 char *src변수를 strlen해서 realloc해야 하는 것 아닌가요? 하나도 모르긴 하지만 자바는 동적할당도 하는 것 같은데......

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 11:16오후

위에도 말씀드렸듯이 동일한 요구조건에대해 자바는 자바주장하시는분이..
C 는 C 하시는분이 짠겁니다.. 요구조건에만 충분히 충실하면되는겁니다..

쓴귤의 이미지

글쓴이: 쓴귤 / 작성시간: 수, 2007/01/10 - 12:30오전

저 위에 자바 코드는 제가 짠 건데 저는 "자바 주장하는 사람"이 아닙니다. 자바는 거의 쓰지도 않아요. 그리고 자바가 빠르다고 한 적도 없거든요?

솔직히 C와 자바가 서로 빠르네 쉽네 하는 것도 우물안의 개구리 같은 얘기입니다. 정말로 최고의 퍼포먼스가 필요한 영역에서는 포트란을 씁니다. 그리고 고도로 추상적인 프로그램을 짠다면 리습이나 하스켈을 쓰죠.

http://mentalese.net
http://functional.or.kr


http://mentalese.net
http://functional.or.kr
익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 9:06오후

자바 하는사람들 이러니 무개념이라 하죠..

이이없네여..

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 9:24오후

제일중요한 컴파일 옵션을 밝히셔야지요..

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 10:11오후

C/C++ 의 꽃이라할만한게 포인터인데.. 저건포인터가하나도 안들어갔네요..

만약 포인터가 좀들아가는 코드라면 자바와비교해보면 수백%~수천% 성능차가 나는거도 흔히볼수 있죠..

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/09 - 10:18오후

그런소리 하지마시고
직접 동일한 작업하는 포인터 들어가는 프로그램 만들어보시죠..

BeEye의 이미지

글쓴이: BeEye / 작성시간: 수, 2007/01/10 - 3:37오후

62초 걸리는 function call 방식의 C code가 제가 쓰고 있는 환경에서는 50초 걸리더군요.
( Visual C++.NET 2003 / Xeon 3.06GHz / 2GB RAM )

컴파일 옵션 몇개 바꿔주고 나니 2초 걸립니다. -_-;
( compile 최적화 속성 꺼져있는 것을 켜줬을 뿐입니다. )

JAVA가 실행시간 최적화가 된다면
C도 컴파일 옵션을 통해 최적화 시켜주고 비교해야 공평하지 않을까요?

JAVA가 JVM이 계속 발전한 것처럼 C/C++의 compiler 또한 계속 발전했습니다.

+------------------------------------+
|항상 행복하고 싶은 평범한 지구인.|
+------------------------------------+

+------------------------------------+
|항상 행복하고 싶은 평범한 지구인.|
+------------------------------------+

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 수, 2007/01/10 - 7:05오후

전 core2duo 6300(1.8Ghz) / 2G 환경에서

C : 14초 / java : 28 초 나왔습니다...

VS 2005 인데 최적화 옵션이란 옵션은 다 체크 한거 같은데 어떻게 그렇게 나왔죠??

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2011/08/19 - 5:46오전

xeon인걸로보아 서버용 컴퓨터 쓰시고 계신것 같은데..

SoftOn의 이미지

글쓴이: SoftOn / 작성시간: 금, 2006/09/01 - 6:17오후

위키 피디아에 다음과 같이 비교해 놨습니다.
http://en.wikipedia.org/wiki/Comparison_of_Java_to_C%2B%2B

실행시간 비교는 위 문서 reference 3번에 2005년에 실행한 벤치마킹 자료를 참고하시면 될듯합니다.
http://www.ddj.com/184401976

한눈에 비교는 이 문서가 더 좋네요;;
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

leonid의 이미지

글쓴이: leonid / 작성시간: 금, 2006/09/01 - 6:22오후


JET(Excelsior JET을 말하는 건가-_-;)을 사용하면

자바도 왠만큼 빨라지는가 봅니다. -_-a

HotPotato의 이미지

글쓴이: HotPotato / 작성시간: 수, 2006/12/27 - 4:10오후

JIT를 말씀하신 게 아닐까 생각됩니다.
Just in time 컴파일러는 사용해본 적이 없지만,
이건 아예 바이너리 코드로 바꾼답니다.

즉, C나 C++로 컴파일한 결과와 같다고 해야지요.
소스 작성언어만 다른 꼴입니다.

그러면 자바의 특성이 사라집니다.
--
내게로~ 와줘~ 와줘!!

--
즐 Tux~

dormael의 이미지

글쓴이: dormael / 작성시간: 금, 2006/09/01 - 8:07오후

언어나 실행환경으로 인해 느려지는 상황보다는 개발자의 코드나 설계에 의해서 느려지는 상황이 더 많다고 생각합니다.
그리고 프로젝트의 성격에 따라 상황은 매우 다르다고 봅니다.
프로젝트의 성격을 좀 더 알려주시면 더 좋은 판단이 가능할듯 한데요.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

ohhara의 이미지

글쓴이: ohhara / 작성시간: 금, 2006/09/01 - 9:09오후


참고로...
엄청나게 똑똑한 사람이 짠 Java Program과 엄청나게 바보가 짠 C Program을 비교해 보면 엄청나게 똑똑한 사람이 짠 Java Program이 훨씬 빠릅니다. -_-;

Taeho Oh ( ohhara@postech.edu, ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
PLUS ( Postech Laboratory for Unix Security ) http://www.plus.or.kr

Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com

leonid의 이미지

글쓴이: leonid / 작성시간: 금, 2006/09/01 - 9:16오후

'자바 프로그램을 잘 짜려면 엄청나게 똑똑해야 한다'라는 뜻이 아니었으면 좋겠습니다.

dormael의 이미지

글쓴이: dormael / 작성시간: 금, 2006/09/01 - 10:38오후

제 생각엔 그렇게 이해하시기 보다는 leonid님과 함께 작업하실 분들께서 더 잘 할수 있는 것으로 하시는게 좋을듯 합니다.

실제 개발을 하다보면 단순한 코드로 비교하기는 매우 어려운 문제들이 많습니다.

알고리즘이나 언어 자체의 처리 능력, 속도가 중요할 때도 있지만 코드라는건 맨땅에서 돌아가지 않는 경우가 대부분입니다.
처리해야할 데이터의 성격이나 돌아가는 시스템이나 주로 쓰게되는 자원에 따라 모든 것이 상이하게 변할 수 있습니다.

이는 단지 '언어'에 대해서만 똑똑하다고 되는 상황은 아닐겁니다.
위의 여러가지 요소에서 똑똑해야 하는데 가능하면 이런 측면에서 가장 자신있게 할 수 있겠다고 생각되시는 여러 요소들을 잘 선택하시는게 좋을것 같습니다.

그래서 누군가 조언을 해드리려고 한다면 이런 여러 상황들을 알려주셔야 하구요.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/10/16 - 4:31오후

카우모춤

하얀_고양이의 이미지

글쓴이: 하얀_고양이 / 작성시간: 수, 2006/09/06 - 9:10오전

그건 어느 언어라도 마찬가지 겠죠?

같은 능력과 같은 실력이라면 C쪽이 훨씬 유리 하겠죠.
---------------------------------------------------
따뜻한 홍차의 여유 냐옹티~

따뜻한 홍차의 여유 냐옹티~

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 일, 2007/01/07 - 4:33오후

엄청나게 똑똑한 사람이 프로그램을 짤때는 C로하는게 자바보다 빠르다는 이야기 같네요.

체스맨의 이미지

글쓴이: 체스맨 / 작성시간: 금, 2006/09/01 - 9:24오후

용도에 맞는 도구를 쓰면 되는 일이라고 봅니다.

---------------------------------------
Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/

Orion Project : http://orionids.org

ganadist의 이미지

글쓴이: ganadist / 작성시간: 토, 2006/09/02 - 9:42오전

프로그램 실행속도도 중요하지만 프로그램 개발속도도 중요합니다.

익숙하지 못한 c++로 10일 걸릴 일을 익숙한 java로 하루만에 만들 수 있으면 성공한 셈이죠.

그리고 잘못된 알고리즘으로 만든 프로그램은 개발언어에 상관없이 느립니다;; 물론 제대로 된 알고리즘으로 만든 프로그램은 개발언어에 상관 없이 빠릅니다. :)

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

wish의 이미지

글쓴이: wish / 작성시간: 월, 2006/09/04 - 11:06오후

정답은...

Joel On Software 를 읽으세요!!! ^^

조엘이 최근 쓴 블로그에,

C#, Java, php 중 멀 써야 될까요?

라는 질문에 대한 답으로 C# 을 골라서 혹은 Java 를 골랐기 때문에 망한 프로젝트는 없다고 했죠. 중요한 것은 특정 플랫폼에 뼈속깊이까지 경험이 풍부한 아키텍트가 있으면 그 툴을 고르는 것이 정답이라고 썼습니다.

결국 답은 멀 하느냐에 따라 다르다.

죄송합니다 ;;

소타의 이미지

글쓴이: 소타 / 작성시간: 월, 2006/09/04 - 11:24오후

가장 성능이 뛰어난 웹서버들을 보면 그중 가장 빠른 것 중 하나가 자바로 짜여져 있습니다
가장 염두에 둔 부분은 IO계획 이라고 말하고 있습니다.

어떤걸 만드느냐, 누가 만드느냐에 따라 달라집니다. for를 백만번 돌리니 어떤게 빠르더라, if 백만번 돌리니 어떤게 빠르더라. 이딴거 별로 중요하지 않다고 생각합니다 ㅋ;
저는 자바를 별로 좋아하진 않지만 적재적소에 잘 쓰면 좋은 수단이라고 생각합니다.

개발속도, 수행속도 외에도 고려할게 엄청나게 많습니다~

kpserv의 이미지

글쓴이: kpserv / 작성시간: 월, 2006/11/20 - 4:16오후

자바... 미나(mina)라는 프로젝트가 있더군요!!

#define DEBUG printf( "%s, %s, %d\n", __FILE__, __FUNCTION__, __LINE__ );

#define DEBUG printf( "%s, %s, %d\n", __FILE__, __FUNCTION__, __LINE__ );

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2006/09/05 - 11:52오전

자바 가상머신을 호출하는 시간때문인거 같은데요. 실제로 코드수행시간은 둘다 비슷합니다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/09/22 - 5:24오후

ㅎㅎ... 설마요.

JIT 컴파일러가 일반화 되어 있긴 하지만...
그래도 JAVA는 인터프리터...
C는 컴파일러입니다.

HotPotato의 이미지

글쓴이: HotPotato / 작성시간: 수, 2006/12/27 - 4:51오후

자바가 C, C++보다 느린 이유 중 하나는 배열 객체마다 일일이 null검사를 하기 때문입니다. (이건 책에서 본 내용)

회사 주요 프로젝트에서 자바로 개발을 하기 때문에 자바를 좋아하기도 하지만 불편한 점도 같이 느낍니다. 미처리된 메시지를 처리하기 위해 무한 루프에 빠지게 되면 JVM이 계속 물고 늘어지기 때문에 (특히 swing을 쓴 GUI 프로그램은) 결국 메모리를 모두 잡아먹고 뿌옇게 뻗어버립니다.

메모리를 이미 점유한 까닭에 gc가 동작할 수 없어서 더욱 그렇겠지요.
--
내게로~ 와줘~ 와줘!!

--
즐 Tux~

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/09/22 - 5:23오후

위에 게시물들 찾아보시면 벤치마크 자료등 여러 객관적(?) 자료가 있습니다.

이론적으로도 그렇지만 실재로도 JAVA는 C보다 느립니다.

그 정도도 8배~50배까지 위 게시물들에 이것저것 있지만...
(벤치 자료보면 JAVA가 더 빠른경우도 있습니다.)

실재로 필드에서 런타임 돌려보시면 JAVE가 C보다 자료 이상으로 엄청나게 느린현상 격을 수 있습니다.

일단 비슷한(?) 업무를 하는 JAVA와 C로 된 코드를 돌려보시면
메모리 사용량에서 엄청난(?) 차이가 있는거 보실 수 있고

그 결과로 JAVA로 된 프로그램은 무겁고 느리단 느낌 받을 수 있습니다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/09/22 - 5:27오후

> 그 결과로 JAVA로 된 프로그램은 무겁고 느리단 느낌 받을 수 있습니다.

첨언하면 마지막에도 쓰셨지만, 느리다는 느낌을 받을 수 있습니다. 그러나 다 느린 것은 아닙니다. :)

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/09/22 - 6:27오후

자바가 빠른 게 아니라 리얼 머신이 빠른 거 겠지요.

사랑천사의 이미지

글쓴이: 사랑천사 / 작성시간: 토, 2006/09/23 - 12:22오전

스승님께 한번 여쭌 적이 있습니다.(C/Pascal/Java/스몰토크? 등을 쓰실 줄 아는 분이셨지만 C와 스몰토크를 주로 쓰시는 분이셨죠. 가장 익숙한 언어라고 말씀 하신건... 기억이 안 납니다만.)

"저기... C, PHP 그리고 자바 중에 뭐가 제일 빠르고 뭐가 제일 느린가요?"

"글쎄? 하지만 자바가 PHP보다는 느리다. 그리고 PHP는 C보다 느리다. 내가 쓰는 스몰토크에 대해선 아직까지 정확한 자료를 가지고 비교 해 본 적이 없다."

"자바를 컴파일 해도 그런가요?"

"그렇다."

무슨 근거로 그렇다고 말씀 하신 건진 잘 모르겠습니다. 하지만 중요한 것은 전체적으로는 자바가 실행 속도가... 딸린다... 였습니다. 전반적으로...

이걸 보니.. Vyte code VS Native Code 라는 주제의 글을 본 것 같군요. 뭐... BASIC이 바이트 코드인지는 모르겠지만, (뭐 그렇다고 봐야 겠죠.) 베이직이 아마 C를 따라 간다는 소리는 못 들은 것 같습니다.

하지만 그것만 고려 해선 안 되겠죠... 스승님께서 하신 말씀 중에 이런 것이 있었습니다. 물론 제가 먼저 질문을 던졌었습니다.

"어떤 언어가 제일 좋을까요??? 제가 뭘 좀 할려고 하는데요..."

"어떤 언어가 가장 좋은가는 상황에 따라 프로그래머가 고려해야 하는 여러 조건에 따라 달라질 거다... 예를 들어 커뮤니티 사이트를 하나 구성하고 구축하는 프로젝트를 수행 한다고 할 때, 필요하다면 VBS도 써야 하며 C를 이용한 CGI와 PHP, Perl을 모두 써야 할 때도 있다. 필요하다면, 그리고 가능하다면 사용 가능하며 어느정도 익숙한 언어를 모두 사용해야만 한다. 하지만, 불필요한 것은 빼는게 좋겠지. 프로그램이 커지면 문제가 생기니까! 결론적으로 C가 좋다 자바가 좋다 이런건 중요하지 않다. 더 중요한건 코드를 조합 해야 할 때와 그렇지 않을 때를 생각 해야 하고 여러 언어 코드를 조합 할 때 적제 적소에 어덯게 잘 사용 하느냐가 가장 중요한 것이다."

뭐 이건 스승님 말씀이라 제가 늘 생각하고 따르는 부분입니다만...

제 경험으론 자바로 짜여진 프로그램이 작은 경우는 그렇게 느리다는 생각을 못 했습니다. 근대 메모리가 작은 경우엔 자바는 천적이 아닌가 생각 되는군요.. 이런건 PHP등도 마찬가지겠죠 아마도...

속도 이야기가 나왔지만, 중요한건 일단 고르셨으면 잘 쓰시는게 제일이라고 생각 됩니다.
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
MSN: ysnglee2000@hotmail.com
----
웃음... 행복... 평화... (진정한...) 희망... 사랑... 이 세상 모든것이 그렇다면 얼마나 좋을까...(꿈 속의 바램일 뿐인가...)

사람천사

plustag의 이미지

글쓴이: plustag / 작성시간: 토, 2006/09/23 - 11:31오전

acm프로그래밍 대회같은데를 보면..

동일한 알고리즘을 쓰더라도.. 자바는 시간을 5~10배 정도는 더 주는것 같더군요..

소스코드를 봐도.. 알고리즘 자체는 동일한데.. 실행속도를 비교해보면 좀 느립니다..

이쪽 동네는 그렇긴 한데..

다른 쪽 동네는 윗분들 말씀대로 상황에 따라 달라지는게 맞는것 같습니다..

누구냐 넌?

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 토, 2006/09/23 - 11:00오후

예전 문서이긴 하지만 http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends 을 참고하시길.

simpid의 이미지

글쓴이: simpid / 작성시간: 화, 2006/09/26 - 12:33오후

아직도 논쟁중.. 오래가는군요.

그냥 JAVA와 C가 실행되는 원리를 생각해보면 답 나온다고 봅니다.

JAVA와 C는 속도에서 비교할 수 있는 대상은 아니라고 봅니다.

차라리 PASCAL과 C중 어느게 빨라요?
란 질문이 올라온다면.. 이런저런 얘기꺼리도 있고 컴파일러 특성이라던지 여러가지 얘기할 수 있겠지만...

JAVA는 인터프리터 언어입니다.
JIT 컴파일러가 있다고 하지만 JAVA가 C 비해 갖고 있는 강점은 근본적으로 JAVA은 인터프리터이기 때문에 가능한겁니다.
C는 컴파일러기때문에 동적인 부분이 JAVA보다 적을 수 뿐이 없는거구요.

결론적으로 JAVA와 C는 속도에 대해선 비교 대상이 아니라고 봅니다.
속도나 메모리 소비량이나 당연히 C가 빠르고 그 차이도 크다고 생각합니다.

Root -의 이미지

글쓴이: Root - / 작성시간: 화, 2006/09/26 - 2:16오후

자바는 웬지 새로운 용어를 매우 잘만들어내는듯하네요.
저만 이런생각이 들었는지 모르겠지만..
알고보면 새로운개념이라할만한것은 별로 없고 다른언어에서 기존에 존재하는 비슷한개념을
기존개념에 새로운 이름을 붙였다고 해야할까..
한마디로 말장난에 맞장구치는식이라고 해야하나..

그게 자바의 강점인것같다.. 자바는 새로운용어를 드리밂으로써
그럴듯하게 감싸기쉬워 프로젝트따기에 유리하다고 해야하나..

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 월, 2006/12/25 - 8:38오후

인정할 수 밖에 없군요.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 수, 2007/01/10 - 7:36오후

요즘엔 매년 .NET버젼 업 해가던데..

매년 새로운 API들 만들어내고.. 한 10년에 한번정도 크게 개발환경을 바꾸기도 하죠

암튼.. SUN이 MS 따라가려면 멀었습니다.

아르아의 이미지

글쓴이: 아르아 / 작성시간: 일, 2006/11/19 - 5:42오후

수치연산 쪽의 속도는 어느 정도 차이가 나는지 궁금합니다.
요즘 자바는 20세기 시절의 자바가 아니라 무지 빨라져서
C++에 근접했다는 벤치마킹 자료를 예전 KLDP글에서 본적이 있는데 못찾겠네요.

궁금한것이 대충(?)짜면야 비슷할지 몰라도
템플릿을 충분히 활용할경우(사실 Blitz++같은 훌륭한 라이브러리가 이미 존재하니 그런걸 쓰면 되겠죠)
자바가 C++따라가기는 많이 힘들듯 하지 않을까요?

아 사실 디자인패턴, 리팩토링같은 책도 대부분 자바 위주고 이클립스+자바 조합도 너무 근사해서 자바가 굉장히 부러워요
C++을 써야 하긴 하는데 괴롭습니다. C++은 쓰레기수집기능도 없고 말이죠.
지금은 템플릿이 제 유일한 위안입니다

kalstein의 이미지

글쓴이: kalstein / 작성시간: 화, 2006/11/21 - 2:15오전

빠릅니다. 물론 어떻게 짜느냐가 문제지만...C만큼 빠릅니다. ^^;

게다가 가상함수 대신 템플릿으로 단위전략을 사용하면 메모리 사용도 C와 같습니다.
(별도의 가상함수를 위한 메모리를 사용하지않음)

쓰레기 수집 기능요? 스마트 포인터를 이용하면 됩니다. 언어자체에서 제공하는건 무한한 가능성입니다.

(물론...아주 무한하진않지만...현존하는 언어중에서는 가장 강력한것 같습니다. 그만큼 진입장벽이 높긴하죠)

C++에서 가비지 콜렉션을 사용하고 싶으시다면...Boost에서 Shared ptr 을 보시면 되실것 같네요 ^^

자바는...템플릿이 제대로 없다는 이유만으로 아직 다가서고 싶지않네요~

아참..참고로 말씀드리면...단순한 수치연산은 어떤언어든지 큰 상관이 없을듯 싶네요.

어차피 자바든 파이썬같은 스크립트 언어든, C같은 기계어 종속적 컴파일 언어든...

수치연산은 어차피 기계어로 번역되고 그 번역 시간이 그다지 길지않으며, 실제로 오래걸리는것은 CPU사용타임

이기 때문에, 언어는 큰 문제가 없어보이네요.


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

Necromancer의 이미지

글쓴이: Necromancer / 작성시간: 화, 2006/11/21 - 2:50오후

자바는 그래도 중간 컴파일 단계가 있지만.
php는 100% 인터프리터죠. zend optimizer같은 컴파일러 안쓴 이상은.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

magingax의 이미지

글쓴이: magingax / 작성시간: 화, 2006/11/21 - 6:20오후

자바로는 보통 어떤 분야의 프로그램을 짜죠?
웹에 많이 쓰이는건 알겠는데..일반어플을 짜긴 너무 느리지 않나요

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

dormael의 이미지

글쓴이: dormael / 작성시간: 화, 2006/11/21 - 7:42오후

제 경험으로 말씀 드리면 우선 소켓서버와 관련된 코드를 많이 작성했습니다.

쓰레드, 동기화와 관련된 작업이 꽤 쉽습니다.
사실 다른 언어는 많이 해보질 않아서 비교가 될수는 없겠네요.
아무튼 저는 그렇게 느꼈습니다.

그리고 예전에 메신저나 증권그래프 같은걸 그리는 클라이언트 어플리케이션도 작성했습니다.

신기한게 기본 컴포넌트들은 버그도 버그지만 반응 속도가 많이 느렸는데 맨땅에 직접 그리는건 그래도 꽤 쓸만한 속도가 나왔었습니다. 버퍼링 같은걸 이용하긴 했지만요.
하지만 GUI와 관련된 부분은 '배포'의 문제때문에 결국 포기하게 되었습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

fender의 이미지

글쓴이: fender / 작성시간: 화, 2006/11/21 - 8:28오후

음... 이제까지 본 Java의 속도에 대한 논쟁 중에 가장 잘못된 정보나 오해가 많이 보이는 글타래 같군요;;

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

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

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 목, 2006/11/23 - 10:44오전

C가 빠릅니다.

같은 능력의 두 개발자가 각각의 언어로 같은 구현을 하면 C가 위에 나열한 몇몇 올바른 이유때문에 빠를 수 밖에 없습니다.

다만...

구현의 요구사항이 실행 속도에만 한정될때에는 속도가 의미가 있겠지만

경험상.... 유지보수가 쉬운 언어(자신에게 맞는)의 선택이 생명 연장에 큰 도움을 주더 군요 ;;;;

futari의 이미지

글쓴이: futari / 작성시간: 금, 2006/11/24 - 10:56오전

중요한건.

자바도 비지니스에서 쓸 수 있을 만큼은 빠릅니다. ^^

speed critical 한 것이라면

C를 쓰거나 더 필요하면 어셈모듈을 넣든 뭘 하든 하면 되겠지요.

project 설계시에 아주 용도를 잘못 파악한 것이 아니라면야.. 느려서 자바 못 쓰겠다는 시대는 지나지 않았나 생각합니다. ㅎㅎ

-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5

-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 금, 2006/11/24 - 11:13오전

그건 아니라고 봅니다..

빠르면 빠를수록좋죠. 옛날에는 서울에 걸어서 3일 걸렸는데 요즘은 자동차로 5시간이면갈수 있으니 더이상 빨리 갈필요 없다고 생각하시나요?

더빠르면 더좋은겁니다.

남들 한번갔다 올동안에 두번도 갔다올수 있는거구요.
시스템도 그만큼 빠르면 하드웨어사양을 그만큼 싼걸로 구해도 동일 성능을 낼수 있다는뜻입니다.


----------------------------------------------------------------------------

purple의 이미지

글쓴이: purple / 작성시간: 금, 2006/11/24 - 2:29오후

그말도 아니라 생각합니다.

서울에서 부산까지 여객기로는 1시간 걸리는데 초음속기로는 10분도 안 걸린다 한들, 공항에서 도심까지 오는데 교통 체증으로 2시간 이상 걸린다면 아무 의미없습니다.

마찬가지로 CPU에서 아무리 빨리 처리한들 IO에서 정체되면 빠른 속도가 의미없습니다. 자바가 IO 처리 속도를 따라가지 못한다면 모를까 이미 자바는 그정도의 속도는 내고 있다 봅니다. 그리고 자바는 그런 곳에서 이미 훌륭히 쓰이고 있죠.

위에서 어느 분이 쓰신대로 이 스레드는 그간 스레드 중 자바의 속도에 대해 가장 많은 편견을 드러내고 있는 스레드인 거는 맞는 거 같네요.

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 금, 2006/11/24 - 2:43오후

위에도 나왔지만.. 어떤 특수한경우나 일부상황에서 별차이 안날수도 있습니다.

하지만 일반적으로 느리다는 의견입니다.


----------------------------------------------------------------------------

youlsa의 이미지

글쓴이: youlsa / 작성시간: 금, 2006/11/24 - 11:32오전

DB-dependent한 소프트웨어들은 이미 DB가 충분히 실행시간을 까먹어(?) 주기 때문에 C/C++이나 Java나 별 차이 없습니다. 머신의 리소스를 쥐어 짜서 작업을 해야 하는 알고리즘 위주의 소프트웨어의 경우에는 비교가 안됩니다만..

근데, 제 경우에는 오히려 C/C++과 Java의 비교는 만든 사람들과 만들어진 과정을 자꾸만 비교하게 됩니다. 사견이지만 K&R이나 Stroustrup에 비하면 고슬링은 참 재수 없습니다. ^_^;

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

serialx의 이미지

글쓴이: serialx / 작성시간: 목, 2006/12/14 - 1:44오후

걸어서 3일 걸려 서울 가는건 자동차 만드는 시간이 걸리지 않지만, 한달걸려 자동차를 만들고 5시간 가는것보다 그냥 3일 걸려 서울 걸어가는게 나을수도 있습니다. 그때그때 다른거죠.

경우에 따라서 적절한 프로그래밍 언어를 사용하면 되는겁니다. 단순히 언어 선택을 '속도'로 했다면 다 어셈을 하지 않겠습니까?

자바보다도 8~10배 느린 PHP/파이썬/루비등을 그럼 그 많은 사람들이 왜 쓰겠습니까..

속도만 보고 언어를 선택하는건 정말 근시안적이고 바보같은 선택이 아닐 수 없습니다. 속도가 8배 느려서 무슨 일을 처리 못하는건 아주 극한의 상황밖에 없습니다.(게임이라던지, DBMS를 개발한다던지 등등의 일이죠) 그리고 개발 속도가 100배 빨라진다면 언어가 10배 느리더라도 하드웨어를 10배 더 많이 사는게 훨씬 나은 선택일 수 있는겁니다. 생각해보세요, 개발자 한달 월급이면 서버 한대 살 수 있는 돈입니다.

자바로 한달걸려 만들 솔루션을 1년걸려 10배 빠른 C로 짜봤자 돈이 들면 더 들었지 싸지는 않을겁니다.

그리고, 솔직히 언어의 수행시간 자체는 그리 중요하지 않습니다. 개발을 하다보면 항상 '병목'인 부분이 따로 존재하기 마련입니다. 그러한 '병목'인 부분만 잘 잡아주는 똑똑함을 가지고 있다면 C를 쓰던 자바를 쓰던 언어 자체의 속도는 그렇게 중요한 문제는 되지 않습니다.

정리하자면, 그때그때 달라요~

--
Captue the one shot in your life!

dirtyi의 이미지

글쓴이: dirtyi / 작성시간: 금, 2007/01/26 - 9:57오전

자동차를 만드는데 한달 걸릴수도 있지만..

그 자동차를 이용하는 사람은 5시간만에 갈수 있게되죠..

과정도 중요하지만 산출물만을 이용하는 사람들에게는 그 성능이 평가 자체가 될 수도 있습니다..

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 목, 2006/12/21 - 5:09오후

머 이런게 논의의 쟁점이 되고있지 =ㅅ=

플랫폼에 따라 다른거고.

만약 java vm 을 통해서만 하드웨어에서 제공하는 가속을 사용할 수 있다면

당연히 그 머신에서는 java가 빠를것이고

같은 조건에서는 C 를 어떻게 따라올 수 있다고 생각하시는건지

그리고

결국은 다 할 줄 알게 되어야 한다는걸 금방 알게 되실겁니다.

언어는 필요에 의해서 선택되는거지

절대적인 성능을 따지는건 의미가 없잖습니까

개발효율과 실행효율의 절충선에서 정해지는걸 쓰는거죠

어느게 빠르다는 고민은 하지 마시고

어느분야에 어느 언어가 왜 유행인지를 유심히 보세요

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 금, 2006/12/22 - 11:26오전

유행만 따라다니면... 결국 누가 새로운시도를 하죠?

그새로운시도의 선구자는 현재의 유행 이라는 말에 짖밟힐수도 있죠.

제가볼때는 끈임없이 다양한시도가 개발자의자세 같은데...뷁뷁


----------------------------------------------------------------------------

unknown2의 이미지

글쓴이: unknown2 / 작성시간: 목, 2006/12/21 - 5:22오후

... 둘다 현업에서 사용하고 있지만(물론 둘다 허접합니다; )
둘다 속도때문에 문제가 되거나 그런 경우는 없습니다.

똑같은 프로그램을 서로간 버전으로 포팅하기도 하지만 사실 속도는 물론.. 단순 비교로는 c가 유리한점이 많으나
.... 어디 그게 중요합니까;?

단지 짜고만 치울것이냐.. 아니냐 에 따라서 언어가 바뀔수 도 있고,
노력비용 .. effort .. 등의 이유로 어떤 언어가 더 낫다 일수도 있는거 아니겠습니까? :)

자바는 못해먹을만큼 느리지 않습니다 :)

그리고 어떤 분이 말씀하셨는데 C로 10일이 걸릴걸 자바로 단 몇일안에 끝내고 속도도 문제 없을 레벨이라면...
당연히 자바가 더 나은 선택이 될 수 있는것 처럼요 :) 개념적인 작성에도 아무래도 C 보단 자바가 더
낫다는건 부정할수 없잖습니까? ~ (물론 C가 개념적이지 않냐!? 라는... 그런 소린 부디;; )

coremaker의 이미지

글쓴이: coremaker / 작성시간: 목, 2006/12/21 - 5:31오후

속도로 비교하는건 약간 넌센스 라고 봅니다...
플랫폼.. 작업성능.. 팀 프로젝트 적용성.. 재 사용성.. 이런 것들을 기준으로 비교하는게 맞다고 생각합니다..
물론.. 어떤 가정이냐에 따르지만...

한코드에 대한 실행 속도는 모든걸 다 포함해서.. C가 빠를 가능성이 높습니다..

그 외에는 쉽사리 일반적인 상황이라고 생각하고 아무런 것에 대입해서 이야기하는건 의미가 없다고 생각되네요..

떵꺼리의 이미지

글쓴이: 떵꺼리 / 작성시간: 목, 2006/12/21 - 6:12오후

언어의 속도 논쟁은 아직까지 진행형인것 같네요.

다 써봤지만

언어 둘을 단순 속도로만 비교하려면 너무 한도끝도 없어보입니다.

더 이상의 이런 논쟁은 무의미해보입니다. ^^;

전 속도보다 얼마나 빨리 개발하고 얼마나 유지보수하기 쉽냐에

올인입니다. ^^

==============================================
Susia

blueskya의 이미지

글쓴이: blueskya / 작성시간: 일, 2006/12/24 - 2:02오전

위에 제가 이런 글을 포스트 해볼까요?

"C가 어셈블러보다 8배 느리다??"
"자바가 어셈블러보다 80배 느리다??

이렇게 글을 올렸다면 여기 포스트랑 별반 다를게 없어보이는군요. 쩝...

"제가 어디서 들어보니" - 이말이 이 포스팅된 글의 의도를 알 수 없네요. 출처도 알 수 없는 자신이 그냥 그렇게 들은것 같은데.. 라는 글인것이지요.

언어 퍼포먼스에 대한 이야기는 정말 한정적인 상황에서 이야기하는것입니다.
임베디드 시스템에서 임계시간까지 처리가 되어야할 때 같은 경우지요.

그런게 아니라면 언어가 중요한게 아니라 프로젝트에 적합한 언어 그리고 팀원들이 잘사용할 수 있는언어가 우선시 되어야합니다.

그리고 언어보다는 아키텍처적인 접근이 가장 큰 이슈가 되어야합니다.

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

narusas의 이미지

글쓴이: narusas / 작성시간: 일, 2006/12/24 - 3:26오전

C는 빠르다. 다만 한번 컴파일 되면 더이상 않빨라진다.
자바는 충분히 빠르고, 실행시간중에 C보다도 더 빨라질 수도 있다.

입니다만..

자바가 (실행시간중에) C보다도 빨라질수 있는 매우 다양한 실시간 최적화 기법이 VM에서 제공되기 때문인데요,
간단한 예를 들자면

class A{
int a;
int b;
int getResult(){return a+b;}
}

같은 코드가 있다고 getResult()를 호출하면 C는 무조건 a연산을 합니다. 당연한 거겠죠.

하지만 자바에서는 a와 b가 변하지 않았다면 함수 호출자체를 하지 않고 캐쉬된 값을 반환합니다. 캐쉬 자체도 매우 최적화 되어 있고, 이것 이외에도 JIT를 통해, 상수 값을 반환하는 native code를 만드는 런타인 최적화도 있습니다.

이렇게 매우 다양한 런타임 최적화들로 인해 C/C++보다도 더 빠른 런타임 성능이 가능한 거죠.

많은 분들이 이부분을 오해 내지는 착각 하시는 거죠. 자바가 인터프리터라 무조건 느리다면 그 어떤 벤치마크에서도 C/C++보다 빠른 결과가 나올수 없어야 합니다. 하지만 아니죠. 상당히 많은 벤치마크에서 자바가 C/C++를 능가하는 성능을 보여주는 부분이 있고, 그런 부분이 점차 늘어나고 있다는 것이 사실(Fact)입니다.

그래도 많은 경우에 컴파일 타임 최적화된 C가 빠른건 사실입니다만, 자바는 단순히 VM이 바뀌는 것 만으로도 빨라진다는 점이 다르겠죠. 공짜로 얻게되는 최적화인 셈이죠. 뭐 JDK 1.6이 JDK 1.5 보다 평균 10~20% 정도의 성능향상이 있었다는 것이 대표적인 예겠죠. C에서 10~20%의 평균 성능 향상을 얻으려면 얼마나 심하게 최적화를 해야하는지는 해보신 분들이면 아마 다 아실겁니다.

그리고 이러니 저러니 해도 자바나 C나 진짜 성능은 외부 IO에서 결정되는게 현실입니다. ^^
파일,DB, 네트워킹, 사용자 UI... 이런데서 성능이 결정되는 거죠. ^^

당연히 언어는 용도와 환경에 맞는 것을 골라 쓰시면 되고요.
과학분야 대규모 수치연산에서 C보다 2~4배 빠른 포트란을 않쓸수 없는 것이 대표적인 예겠죠. C/C++/java는 스택머신이라는 근본적인 한계때문에 대규모의 수치연산에서 포트란을 앞지르기가 매우 어렵죠.

수치적인 실험을 하고 싶다면 엑셀 VB Script나 매스매티카를 사용하면 되겠죠.

빠른 프로토타입을 하고 싶다면 파이썬등의 스크립트 언어를 사용해보는 것도 좋죠.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 월, 2006/12/25 - 8:51오후

> 하지만 자바에서는 a와 b가 변하지 않았다면 함수 호출자체를 하지 않고 캐쉬된 값을 반환합니다. 캐쉬 자> 체도 매우 최적화 되어 있고, 이것 이외에도 JIT를 통해, 상수 값을 반환하는 native code를 만드는 런
> 타인 최적화도 있습니다.
> 이렇게 매우 다양한 런타임 최적화들로 인해 C/C++보다도 더 빠른 런타임 성능이 가능한 거죠.

음. 다음의 사실을 간과하고 계시는군요.
저런 최적화는 C/C++에서도 할 수 있습니다.
그렇다면 Java 는 C/C++ 을 능가할 수 없습니다.
더구나, C/C++ 에서는 캐쉬관리를 통해 효율적으로 속도를 올릴 수 있습니다.
(미리 계산된 값들을 여러 셋 가지도록 캐쉬관리를 한다면...)
하지만, Java 에서는 하나의 미리 계산된 결과만을 가지고 있을 수 있거나,
다중의 미리 계산된 값을 가질 수 있다손 치더라도, 메모리소비를 얼만큼 할지에 대한 세부적인 관리가 힘들죠...
만약 캐쉬관리를 Java 응용 프로그램에서 직접 한다손 치더라도.. C/C++ 을 속도나 리소스 사용 면에서 능가할 수 없습니다.
이런상황에서 최적화 문제로 Java 가 C/C++ 을 따라갈 수 있을까요 ???

> 많은 분들이 이부분을 오해 내지는 착각 하시는 거죠. 자바가 인터프리터라 무조건 느리다면 그 어떤 벤치
> 마크에서도 C/C++보다 빠른 결과가 나올수 없어야 합니다. 하지만 아니죠. 상당히 많은 벤치마크에서 자
> 바가 C/C++를 능가하는 성능을 보여주는 부분이 있고, 그런 부분이 점차 늘어나고 있다는 것이 사실
> (Fact)입니다.

물론, Java에서 최고의 성능이 나올 수 밖에 없는 벤치마크라면 당연하죠.
물론 Java 진영에서 만든 벤치마크일테니, Java가 더 빠를 수 밖에 없겠죠.
그럼 C/C++ 진영에서 만든 벤치마크는 어떨까요..
Java 가 어느 하나도 이길 수가 없겠죠..
벤치마크, 그대로 믿으시나요 ???

> 그래도 많은 경우에 컴파일 타임 최적화된 C가 빠른건 사실입니다만, 자바는 단순히 VM이 바뀌는 것 만으
> 로도 빨라진다는 점이 다르겠죠. 공짜로 얻게되는 최적화인 셈이죠. 뭐 JDK 1.6이 JDK 1.5 보다 평균
> 10~20% 정도의 성능향상이 있었다는 것이 대표적인 예겠죠. C에서 10~20%의 평균 성능 향상을 얻으려면
> 얼마나 심하게 최적화를 해야하는지는 해보신 분들이면 아마 다 아실겁니다.

Java 의 경우, 얼마나 최적화가 되어있지 않으면, 10~20% 정도 성능향상을 시킬만한 여지가 있는건지...
VM 바꾸는 것으로 10~20% 성능향상을 가져올 수 있다는 것은, 그만큼 VM이 엉터리로 짜여져서 최적화가 되어있지 않다는 얘기와 동일한 것 아닌가요 ???

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 월, 2007/01/29 - 5:01오후

쯧쯧쯧, 그럼 지금 최고성능의 C++ 컴파일러 몇년후에 10~20% 빠를게 만들수 있는 컴파일러 나오면 지금 최고의 성능을 내는 C++컴파일러는 엉터리로 짠겁니까?

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 화, 2006/12/26 - 11:28오전

윗분말씀처럼 잘못알고 계신겁니다.

자바로 할수있는것은 C로 도 가능하지만 C로 가능한건 자바로 다할수 있는건 아닙니다.


----------------------------------------------------------------------------

moonend의 이미지

글쓴이: moonend / 작성시간: 일, 2006/12/24 - 11:26오전

IO 문제나 기타 등등 문제를 제외하더라도,
자바가 C보다 8배정도 느리다는 것이 사실이라고 해도,
별로 체감할 수 있을 정도의 성능 저하는 없다고 생각합니다.
php를 쓴다고 해서 보통 딱히 느리다는 느낌을 갖는 사람은 없습니다...

구현언어의 선택으로 실제로 성능저하를 체감할 수 있을 정도의 상황이라면,
기계를 더 좋은 것으로 바꾸는 것이 더 빠릅니다.

포트란의 경우, 스택 연산에 관련된 문제보다는 몇 십년동안 축적된 신뢰성, 안정성, 관계자의 익숙성, 교육 수준이 더 큰 영향을 끼친다고 생각합니다.
포트란의 주 용도로 쓰이는 수치연산에서는 소수점 단위의 엄밀성을 증명해야하기 때문이겠죠. [C는 아직 무리]

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 월, 2006/12/25 - 8:55오후

> 몇 십년동안 축적된 신뢰성, 안정성, 관계자의 익숙성

C/C++ 은 몇십년 동안 축적된 저런 성격이 없나요???
혹시, 그 사실 아십니까.. ??
C/C++ 이 포트란 보다 신뢰성과 안정성 그리고 관계자의 익숙성에서 더 뛰어나다는 사실을...

> 포트란의 주 용도로 쓰이는 수치연산에서는 소수점 단위의 엄밀성을 증명해야하기 때문이겠죠. [C는 아직 무리]

음...
공부 좀 더 하고 글을 올리시기 바랍니다.
무슨 포트란이 소수점 단위의 엄밀성을 증명하기 위해서 입니까..
어이없군요.

sunyzero의 이미지

글쓴이: sunyzero / 작성시간: 수, 2006/12/27 - 11:59오전

모든 것은 비용 문제를 생각해 봐야 합니다. 대규모로 운영되는 장비에서는 속도 문제도 크리티컬합니다.

예를 들어 유투브를 생각해 봅시다. 하루에 1억개의 클립파일이 올라옵니다. 속도를 생각하지 않는다면

이것을 처리하기 위해서 소비되어야 하는 장비가 얼마나 될까요?

A 라는 언어가 B 라는 언어보다 일반적으로 2배 빠르다고만 해도 1000억짜리의 장비가 투입되어아 하는 경우에는
B 라는 언어를 선택함으로서 2000억이 투입되어야 합니다. 거기에 관리비용까지 더하면 아주 엽기적이죠.

사실 대용량 처리가 요새의 대세인데, 그런 점에서 굳이 느린 언어를 선택해야 하는 이유는 실시간성이나 비용이
전혀 고려되지 않은 것입니다. 우리나라의 가장 큰 문제죠. 외국에서는 상상도 못하는 일입니다.

그리고 위에 어떤 분이 네트워크에 대한 이야기를 하시면서 차이가 없다고 하는데, 네트워크에서 C 의 성능은 독보적입니다.
특히 자바같은 컴파일 언어가 아닌 경우는 사실상 JVM 레벨에서 다시 C 로 짜여진 시스템에 호출하는 방식을 사용합니다.
한두단계를 더 거치는데 차이가 없다니요? 네트워크 관련 전공자들이 보면 황당해 합니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.

========================================
* The truth will set you free.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 수, 2006/12/27 - 12:38오후

파이썬은 자바보다 더 느린언어죠.
그럼에도 불구하고 구글은 파이썬을 이용하고 있습니다.

과연 특정 언어가 성능을 좌지우지 하는걸까요?

야후나 네이버에서 PHP로 짤거 C로 짜서 FAST_CGI를 이용하면 웹사이트를 더욱더 빠르게 할수 있겠죠.

그런데 그냥 PHP를 사용합니다. 그 이유가 뭘까요?

그네들은 1년에 서버 유지 비용만도 어마어마하게 들어가는 거대 포털업체들인데 말이죠.

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 목, 2006/12/28 - 2:16오후

그쪽이 그렇다는건 아니고..생각보다 불합리한것이 많습니다.

이유가 있을수도..

시작.
1.잘몰라서 그렇게 한경우..
2.별로 안좋은줄알면서 상대가 그쪽에 관심있어하기에..
3.그저 남들이 좋다하니까 생각없이..
4.업체간영업적인 이유가 연관..

계속 유지하는이유..
그누구도 개선해야할 이유를 느끼지 못한다.
1.사장의 입장 이미 운영되고 있기때문에.. 다시 거액을투자하는 모험은 위험하다.
2.개발팀장입장 자신의 주분야인데 갈아 업는다면 자신의 존재까지 위험해질수 있다.
3.개발자입장 잦은오류와 느린시스템은 개발자의 생명을 연장시켜준다.
4.주변업체입장 시스템이 느림으로써 더욱많은 교류가 발생하며 하드웨어또한 많은교체가 일어나 장사꺼리가된다.

조금만생각해보면 좋은언어나 시스템이 도입되기가 훨씬 힘듭니다.


----------------------------------------------------------------------------

fender의 이미지

글쓴이: fender / 작성시간: 수, 2006/12/27 - 12:51오후

비유를 하나 해보겠습니다.

A라는 사람은 자동차 전문가입니다. 그런데 서울에서 부산까지 아주 급하게 갈일이 생겼습니다. 아주 급한 일이기 때문에 차의 속도가 무엇보다 중요하다는 판단을 했고 그래서 F1 레이싱카를 구해서; 고속도로로 부산에 가기로 결정했습니다. 한편 A의 친구 B는 비슷한 일로 SUV에 가족들을 태우고 역시 부산으로 출발합니다.

자동차 전문가인 A는 B를 보고 생각합니다. "아니 왜 이렇게 급할 때 느려터지고 크기만 한 저런 걸 몰고 가는 거지? 자동차 전문가 입장에서 이해할 수 없군... 외국에선 상상도 못할 일이야..."

그리고 설날 귀경 차량으로 꽉 막힌 고속도로...에 레이싱카를 몰고 들어갑니다;

...

과연 A가 B보다 훨씬 먼저 - 즉, F1 레이싱카와 SUV의 속도 차이만큼 빨리 부산에 도착했을까요? 그리고 넓직한 차에서 TV도 보고 쉬기도 하면서 운전한 B에 비해 오직 속도를 위해서 불필요한 모든 편의시설을 빼버린 좁은 공간에 헬멧까지 쓰고 운전한 A가 더 합리적인 판단을 한 것일까요? 꽉 막힌 고속도로나 차량의 속도, 그리고 차의 편의시설 등이 각각 무엇에 대한 비유인지는 굳이 설명할 필요는 없을 듯 합니다.

......

그리고 이건 이 글타래에 흔히 등장하는 오해 내지는 편견인 듯 하지만, '자바는 컴파일 언어가 아니다. 그러니까 컴파일 언어인 C/C++ 등보단 무조건 느리다' 내지는 'JVM도 C/C++이니까 그 위에서 도는 건 최소한 C/C++보다는 느릴 것이다'라는 생각을 하신다면 위에 몇몇 분이 언급하신 대로 우선 JIT에 대한 기본적인 개념을 찾아보시기 바랍니다.

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

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

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 목, 2006/12/28 - 1:46오후

비유가 좀잘못된듯.

보통 서비스들은 상업적이며 전문적이며 수없이 반복적인 작업이므로..
명절날 단한번내려가는 비유와는 틀리다고 봐야죠.. 항상운행하는 버스라던가.. 택시등으로비교.
그런데 택시가 불필요하게 기름많이 먹는 트럭이라던가 혹은 요금은 똑같이 받는데 5000cc 차에 무거운장비까지 항상 싣고 다니는격이죠..

즉 택시를 운행하는데 최적화된 차량으로 택시를 운행해야지.. 불필요한 무거운장비를 붙여다닐필요가 없죠.


----------------------------------------------------------------------------

fender의 이미지

글쓴이: fender / 작성시간: 목, 2006/12/28 - 2:37오후

음... 위의 글이 무엇을 비유한 것인지는 이런 주제로 토론하시는 분이라면 너무 기초적인 부분이라 부연 설명이 불필요할 것으로 생각했는데 그렇지 않은 것 같군요.

자동차 자체의 최고 속도가 언어의 raw performance이고 교통 정체는 디비나 네트워크 등의 I/O 보틀넥입니다. 자동차의 편의시설 등은 유지보수나 생산성 쯤으로 생각하시면 되겠죠.

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

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

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 목, 2006/12/28 - 3:45오후

일반적인 상황을 비유한것이 아니고 DB와 네트웍이 연관된거라면..

C가 최고속도도 더높고 가벼우며 더안정적이고 DB나 네트웍 성능도
좋으며 포인터라는 편리한도구도 있고 유지보수와 생산성도 떨어지지 않는데.

자동차로비유하자면 두자동차의 장점만을 모은자동차가 될듯..


----------------------------------------------------------------------------

fender의 이미지

글쓴이: fender / 작성시간: 목, 2006/12/28 - 4:06오후

아무래도 쉽게 풀어서 설명할 필요가 있겠군요...

인터넷 기반 서비스에서 예를들어 하나의 리퀘스트에 대한 응답시간이 1초라면 좀 과장되게 말해서 네트워크에서 잡아 먹는게 0.6초, 디비 쿼리 시간이 0.3초, 기타 프로그램이 돌아가는 시간이 0.1초라고 하겠습니다.

대부분의 경우 C/C++이 자바보다 4배씩 빠르지도 않지만 설사 그렇다고 쳐도, 위의 예에서 자바로 0.1초 걸리는 작업을 C/C++로 했을 때 0.075초를 단축할 뿐입니다. 최종 사용자 입장에서 브라우저로 웹사이트 띄우는데 0.075초 빨리뜬다는 게 과연 얼마나 의미가 있는 것일까요?

그런 서비스에서 성능이란 병목을 줄이고 디비를 잘 설계하고 시스템 아키텍처를 얼마나 적절하게 구성하느냐에 달려있지 언어의 raw 퍼포먼스에 따라 결정 되는 게 아닙니다. 그렇기 때문에 자바나 닷넷이 엔터프라이즈 시스템 구축에서 각광받는 것이겠죠.

그리고 C/C++이 덮어놓고 '자바보다 더 안정적이고 빠르고 생산성도 높고 편리하다'라는 건 일반적 상식과는 동떨어진 개인적 취향으로 생각합니다. 국내외를 막론하고 기업 사이트에 자바와 닷넷이 압도적으로 많이 쓰이는 상황을 고려하면 그 모든 개발자들이 다 뭘 모르거나 C/C++할 실력이 없어서 그렇다는 결론 보다는 ㅡ,.ㅡ;;님께서 인터넷 기반 서비스의 성능에 대한 이해가 부족하신 듯 하다는 결론이 더 개연성 있는 것이 아닐까요?

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

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

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 목, 2006/12/28 - 4:21오후

많이 쓴다고 그것이 성능이더좋다 혹은 안정적이다 혹은 유지보수가 편리하다란뜻일까요..

님이 일반화를 예를드셨는데.. 그렇다면 아직도 자바보다는 C가 훨씬 많은 분야에 다양하게 쓰이고 있습니다.

그렇다면 님논리라면 다른분야사람들은 다 뭘모르거나 자바 할줄몰라서 그럴까요?
그렇기보다는 특히 인터넷 기반서비스에 만 사람들의 인식이 부족하신게 아닌가 하는생각은 안해보셨는지요.ㅡ,.ㅡ;;

물론 자바가 인터넷서비스기반으로 각종 개발방법이나 라이브러리등을 내놓음으로써 사람들을 다양하게 유도하고 있다는거 압니다.

하지만 그게 거기에만 있다거나 자바만 가능한건 아니거든요...


----------------------------------------------------------------------------

fender의 이미지

글쓴이: fender / 작성시간: 목, 2006/12/28 - 7:28오후

님은 분야에 관계없이 C/C++이 자바보다 빠르고 편하고 어쨌든 무조건 좋다는 식으로 말씀하셨지만 저는 자바가 C/C++보다 항상 빠르다거나 무조건 편하다고 한 적이 없는데요? 또 이건 인터넷/네트워크 기반 서비스에 대한 답글입니다만... -ㅅ-a;

그리고 전 C/C++이 널리 쓰이는 분야 사람들이 자바 좋은지 몰라서 그걸 쓴다고 한적은 없습니다만, 아래 답글을 보면 님은 자바가 널리 쓰이는 분야의 경우도 윗사람들이 뭘몰라서, 혹은 기타 정치적인 이유로 자바를 쓰는 것이라는 투의 주장을 하셨는데요?;

어쨌든 굳이 더 이상 반론 달지 않겠습니다.

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

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

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 목, 2006/12/28 - 4:30오후

자바로 0.1초 걸리는 작업을 0.075초로 줄이는 작업은 상당히 중요하다고 생각합니다.

한명의 사용자를 대상으로 한다면 정말 미미한 차이이지만

대용량 인터넷 서비스를 한다면 빨리 처리하고 리소스를 반환하는 것이 전체 시스템 성능에 영향을 미치게 됩니다.

사용자 입장에서는 별 차이를 못느껴도 개발자나 운영자 입장에서 보면 서비스 장비의 증설에 관한 이슈가 되는거죠.

fender의 이미지

글쓴이: fender / 작성시간: 목, 2006/12/28 - 5:26오후

말씀하신 부분은 유효한 지적입니다. 하지만 실제적으로 1초의 응답시간 중 0.1초와 0.025초의 차이가 중요하다면 나머지 0.9초는 그만큼 훨씬 더 중요할 것이고 따라서 최적화를 한다면 우선적으로 고려할 대상이 될 것입니다. 그런 이유로 최적화에서 아키텍쳐의 변화나 쿼리 튜닝등을 우선적으로 고려하게 되는 것이겠지요... 그 부분을 제외하면 언어를 바꿨을 때 얻을 수 있는 속도상의 이점과 추가로 드는 비용 간의 트레이드 오프를 고려해야할 문제이고 이는 프로젝트 성격에 따라 상당한 차이가 있을 것입니다. 다만 인터넷 기반 서비스에 국한해서 말하자면 그런 고려에서 전자를 우선해야 하는 경우는 상대적으로 그렇게 흔하지 않다고 생각합니다.

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

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

M.W.Park의 이미지

글쓴이: M.W.Park / 작성시간: 목, 2006/12/28 - 5:29오후

I/O bound일때, 예를 들어 I/O에 1초 걸리고 CPU time 0.5초일때, 현대적인 OS나 하드웨어 서브 시스템에서는 결과가 1초에 뜹니다. 이런 상황에서는 CPU time을 0.0001초로 만들어도 어차피 결과는 I/O가 끝나야 볼 수 있습니다.
반면 CPU bound일때는 이야기가 다릅니다. I/O가 없거나 수행 초기에 데이터를 읽어들이는 I/O가 끝나고 나서 많은 계산을 하는 상황에서는 보통 CPU bound가 됩니다. 계산이 끝나야 결과를 보는 상황이되는 것이죠.
인터넷 서비스는 많은 경우 I/O bound가 예상됩니다만... 실제로는 어떤지는 잘 모르겠네요.
장황하게 썼지만, 결론은 어차피 I/O bound일때는 CPU time을 줄이는 것보다는 I/O 성능 개선이 전체성능에 미치는 영향이 더 크다는 것입니다.

마지막으로 첨언 하자면(밑에서도 글을 하나 썼지만), 성급한 최적화는 만악의 근원입니다. 시스템이 I/O time에서 성능제한을 받는지, CPU time에서 성능 제한을 받는지 정확하게 프로파일링하지도 않고, 위에 언급한 상황(I/O bound)에서처럼 CPU time을 죽을 고생해서 0.5초에서 0.0001초로 만들었다해도 시스템은 결코 더 빨라지지 않는 것입니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/12/29 - 10:16오전

과장하시거나 곡해하신것같은데요..

"성급한 최적화.. 죽을고생을해서....0.0001초.. I/O 성능개선이 영향이 더크다.."

성급한 최적화를 하자는건 아니지요 또한 죽을고생을 해서 하자는것도 아니고.. 성능개선의 우선순위를따지자는것도 아닙니다.

무겁고툰탁한 삽과 날렵하고 가벼운삽두개를가지고 똑같은 삽질100번하고 구덩이를 누가더 잘파느냐를 따지는것입니다.

동일한 노력과 희생을하고 뭐하러 결과가 안좋은걸 선택하느냐는것이지요..

삽은도구(언어) 에해당하죠..

M.W.Park의 이미지

글쓴이: M.W.Park / 작성시간: 금, 2006/12/29 - 1:11오후

무슨 말씀이신지?
좀 논리적으로 설명해주시죠.
제 글은 인터넷 서비스에 관한 언급이 있는 글에 대한 답글이란건 알고 계시죠?

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 금, 2006/12/29 - 3:19오후

job processing 에서 I/O bound job만 있는것도 아니며, CPU bound job만 있는 것도 아닙니다.
대부분의 작업은 이들이 병행되죠.

그런면에서 big system 에서는 I/O 에서 waiting 이 발생하면 다른 job으로 switching 을 하도록 설계됩니다.
따라서 시스템의 병행성에서는 I/O 의 대기시간에 다른 작업을 처리하도록 하는데, 이 과정에서 최적화가 일어납니다.

그런면에서 PC 급이 아닌 server 에서 고성능을 필요로 한다면 대부분의 guru 들은 C & Java 를 선택할겁니다.
realtime 이나 perf 영역에서는 분명히 C 로 처리하고 나머지 영역을 Java 로 처리하겠죠.

여기 글타래를 보면 한국의 Java 예찬론자들은 뻔한 이야기로 java 에 대해 과도한 환상을 설파합니다.
그러나 우물안 개구리입니다. 똑같은 하드웨어로 둘다 최고의 기술로 만들어보도록 하면 누가 더 빠를까요?
java 가 최근에 성능개선이 되었다고 하더라도 OS 의 극한의 능력을 끌어올리는데는 분명히 한계가 있습니다.
그것은 애초에 설계의 목적이 성능위주가 아니기 때문이죠.

그런데도 한국에서는 문제없이 사용되는 이유는 한국은 아직까지 극한의 기술을 사용하지 않는 그저그런 웹사이트 처리뿐이고
SW 의 기술보다 HW 에 우위를 두는 이상한 현상때문이죠. 설계감사에서 보다보면 도저히 성능이 안나올거 같아서 물어보면
대답은 한결같더군요. HW 를 더 고사양으로 올리죠. 이거 미국에서였으면 boss 한테 짐싸라는 소리 나옵니다.

M.W.Park의 이미지

글쓴이: M.W.Park / 작성시간: 토, 2006/12/30 - 2:37오전

구체적인 예를 하나만 들어주신다면 이해가 빠를것같습니다.
저는 java 예찬론자도 아니며, 언제나 최적 솔루션을 찾으려고 노력하는 사람입니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

purple의 이미지

글쓴이: purple / 작성시간: 화, 2007/01/02 - 10:56오전

java에 대한 과도한 환상이라기 보다는 java에 대한 오해가 많기 때문에 그에 대한 답을 하는 거라 생각합니다. java가 인터프리터이기 때문에 늦다라든가 gc 때문에 늦다는 것은 명백한 오해인 거죠.

java로 OS 또는 하드웨어의 극한의 능력까지 끌어 올리는 데 사용하지는 않죠. 원래 그런 목적으로 만든 것은 아니니까요. 그러나 그런 관점에서 보자면 C나 어셈블리 외에 살아남을 언어는 없을 겁니다.

OS 또는 하드웨어의 극한의 능력까지 끌어 올리는 것이 개발의 다라 생각하지 않습니다. C/C++로 개발하다 보면 그런 쪽에 촛점을 맞출 수밖에 없구요. 우물안 개구리라 하셨지만 님이 그 경우가 아닌지도 생각해 보셨으면 하네요.

플레임을 계속 일으키고 싶진 않지만 하도 자바가 느리다는 편견 때문에 고생한 기억이 많아서 -- 경영진이나 기획, 운영진들이 어디서 자바가 느리다는 소리를 듣고 와서 쪼는 게 한두번이 아니었습니다 -- 한마디 올려 봅니다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/02 - 11:14오전

> 플레임을 계속 일으키고 싶진 않지만 하도 자바가 느리다는 편견 때문에 고생한 기억이 많아서 -- 경영진이나 기획, 운영진들이 어디서 자바가 느리다는 소리를 듣고 와서 쪼는 게 한두번이 아니었습니다 -- 한마디 올려 봅니다.
그건 편견이 아니라 사실입니다. 분명히 느린 걸 체감하고 있는데도 이렇고 저렇기 때문에 느리지 않다고 우기니까 문제지요.
java가 성능을 목적으로 한 것이 아니라는 건 님도 인정하시잖습니까?
그런데도 성능면에서 처진다는 것은 인정하기 싫으신 거 아닙니까?
만약 경영진에서 속도 문제를 거론한다면 java가 상대적으로 느리긴 해도 우리 목적에 문제가 될 만큼 느리지는 않으며 java로 개발하면 그 대신 이러이러한 장점이 있다고 하셨어야 합니다.

purple의 이미지

글쓴이: purple / 작성시간: 화, 2007/01/02 - 1:37오후

상황이 어떠했는지 자세히 아시지도 못하면서 그렇게 말씀하시면 곤란하죠. 무엇 때문에 느린지도 모르면서 무조건 자바니까 느리다는 식으로 몰아붙이는 것이 경영진 등이 말했던 거와 똑같습니다.

이제까지 경험상 자바 환경 자체의 속도 때문에 서비스가 느렸던 적은 없었습니다. 리소스 반환, 동기화 문제 등 버그가 있는 경우 아니면 대부분 DB 처리에서 속도 문제가 발생하였죠. 아마 C나 C++로 개발하였다면 이런 문제는 더 많이 발생했을 겁니다.

익명사용자의 이미지

글쓴이: 익명사용자 / 작성시간: 화, 2007/01/02 - 2:05오후

DB처리가 워낙에 느려서 자바가 느린 건 표가 나지 않는 겁니다. 20:80 법칙 아시죠?
그렇게 뚜렷한 병목이 없는 분야에서 java로 개발해보시면 생각이 달라질 겁니다.

> 이제까지 경험상 자바 환경 자체의 속도 때문에 서비스가 느렸던 적은 없었습니다. 리소스 반환, 동기화 문제 등 버그가 있는 경우 아니면 대부분 DB 처리에서 속도 문제가 발생하였죠. 아마 C나 C++로 개발하였다면 이런 문제는 더 많이 발생했을 겁니다.

그렇죠. 이렇게 우리 서비스는 java의 속도가 문제가 되지 않을 만큼 충분히 느리다고 경영진에게 얘기하면 되는 겁니다.

페이지

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.