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

leonid의 이미지

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

제가 어디서 들어보니

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

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

헛소리였으면 좋겠네요.

narusas의 이미지

추가적으로 실행시간 레벨의 최적화 기법도 많습니다.

public class Speed {
  static boolean c1 = true, c2=true;
  public static void main(String[] args) {
    long start, end, elapsed;
    try {Thread.sleep(5000L);} catch (InterruptedException e) {}
 
    for(int k=0; k<5; k++) {
      start = System.currentTimeMillis();
      doo();
      end = System.currentTimeMillis();
      System.out.println("Elapsed time:"+(end-start));
    }
  }
 
  static public long doo(){
    int i,j;
    int count = 5;
    int n = 1000000000;
    long sum =0;
 
    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;
  }
}

실행 결과

D:\work\workspace\Test>d:\Java\jdk\jdk1.6.0\bin\java -server Speed
Elapsed time:37734
Elapsed time:38563
Elapsed time:11203
Elapsed time:13187
Elapsed time:11188

보시면 알겠습니다만, 3회 이후에는 JVM에 의해 실행시간 최적화가 되어 근 280%의 성능 향상을 보여줍니다.

동일한 코드를 C로 제작해서 실행결과는

narusas@rakka ~
$ gcc -O3 sp.cpp
 
$ ./a
34
32
34
32
34

로 평균 33초 정도 나오는 군요.

손으로 직접 최적화 하지 않았지만 자바는 25초 정도 줄어듭니다.

물론 말씀하고자 하는 것은 잘 알겠습니다만, 자바에서는 실행시간이 길어질수로 실행시간 최적화에 의해 더 빨라질수 있다는 걸 보여드리고 싶었습니다.

narusas의 이미지

님의 코드를 조금만 바꿔서 5회 연속 테스트 하게 변경해 보았습니다.

#include <stdlib.h>
#include <time.h>
 
long sum = 0;
int c1 = 1, c2=1;
 
int calc();
 
int main(int argc, char *argv[])
{
 
int count = 0;
 
time_t start;
time_t end;
time_t elapsed;
 
 
for(count = 0; count < 5; count++) 
{
  start = time (NULL);
  calc();
  end = time (NULL);
  elapsed = end - start;
 
  printf( "time %d\n", elapsed );
}
    return(0);
}
 
int calc() {
  int i,j,k=0;
  int n = 20000000;
 
  int count = 5;
 
 
  for(i=0; i< 1000;i++)
  {
    for(j=0; j< n;j++)
    {
      k++;
     }
  }
  return k;
}

결과

$ gcc -O3 sp2.c
 
$ ./a
time 27
time 30
time 24
time 25
time 24

동일한 코드를 자바로 구현해 보았습니다.

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

결과

D:\work\workspace\Test>d:\Java\jdk\jdk1.6.0\bin\java -server Speed2
Elapsed time:53344
Elapsed time:53812
Elapsed time:0
Elapsed time:0
Elapsed time:0

처음 2회 이후에는 1ms 이내에 처리가 끝났습니다. 이 코드가 만약 장기간 여러번 실행되는 코드라면 자바의 압승이겠군요.

익명사용자의 이미지

C는 최적화옵션 적용되면 처음부터 0 으로 나옵니다.

narusas의 이미지

뭐 다른 옵션도 적용할수 있겠지요?

님이 아시는 모든 최적화 옵션을 주셔서 다음의 코드의 성능이 어떻게 나오는지 테스트 해주시겠습니까?

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/times.h>
#include <time.h>
#include <stdio.h>
 
void calc();
 
 
long sum = 0;
int c1 = 1, c2=1;
 
 
 
int  main() {
 
int i,j, k;
    int n = 2000000000;
 
int count = 5;
 
 
 
for(k=0; k< 5; k++) {
start = time (NULL);
for(i=0; i< count;i++) {
for(j=0; j<n;j++){
if ( c1){
if (c2 ) {
sum ++;
}
else {
sum--;
}
}
}
c2 = ! c2;
}
    end = time (NULL);
elapsed = end - start;
 
printf("%d \n", elapsed);
}
    return(0);
}
 
void calc() {
if ( c1){
if (c2 ) {
sum ++;
}
else {
sum--;
}
}
}

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

컴파일 및 실행은 가급적 JDK 1.6 Server hotspot으로 실행해주시면 좋겠습니다.
GCC쪽은 님께서 아시는 최적화 옵션을 주시고요..

익명사용자의 이미지

[localhost test_src]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
[localhost test_src]$ cc -O3 t7.c
[localhost test_src]$ ./a.out
time 0
time 0
time 0
time 0
time 0
[localhost test_src]$
[localhost test_src]$ gcc -O3 t8.c
[localhost test_src]$ ./a.out
0
0
0
0
0
[localhost test_src]$

8.c 가 위에 소스이고 7.c가 아래소스입니다.
(8.c에 time 변수 선언이 빠져서 넣었습니다... )

둘다 0초로 나옵니다.

youbit의 이미지

런타임 최적화든, 컴파일러 최적화든 결과값 0은 이게 빨라서 그런건지 아니면 (컴파일러나 런타임이) 편법을 쓰는지 알 수 없습니다.
개인적으로는 최적화같은 건 제외하고 디폴트 옵션으로 테스트하는게 더 객관성이 있다고 생각됩니다만, 별로 동의하시지는 않을 것 같군요.
여하튼 지금 테스트 방법이 그다지 효율적이지도 않고 무엇을 알아보는데 도움이 되지않고 있다고 생각합니다.

좀 더 테스트 방법을 신중하게 고려해서 합의점을 찾는게 어떨런지요? 그게 아니라면 특정 '요구사항'을 각자 C/C++ 및 자바코드로 표현해서
퍼포먼스를 비교하는 것도 괜찮을 것 같습니다. 어차피 '동일한 코드에서...'라는 걸 비교하는게 아닌 이상(이런 건 현실성이 없지요)
특정 요구사항을 더 효율적으로 수행해내는 언어가 '성능에서 우월하다'고 말할 수 있는게 아닐까요. 요구사항이 복잡하지만 않으면
코드가 아무리 개선되어도 한계의 여지가 있을테고, 그 지점에서 C/C++과 자바의 성능을 비교해보는 것도 괜찮을 것 같습니다.

익명사용자의 이미지


일단 자바와 C가 일반적으로 단순연산이라도 수행되는경우는 거의 자바가 C의 2~3배의 저하가 일어납니다.
물론 다른경우는 또 비교해봐야알겠지만 더걸리는것이 있을수도 있고 덜걸리는것이 있기도하겠죠..

그러나 자바는 일반적으로 라이브러리 제공되는 범용함수를 사용해야하고 C는 대부분 그함수조차도 프로젝트에맞게최적화할수 있습니다.
아마도 실제라면 더큰차이가 나겠지요..

그러나 자바가 C보다 몇배 느리다고 못쓴다는건 아닙니다. 실제로 과장했다치고 10배느리다고 못쓸이유는 없습니다.
C/C++로 짠프로그램 10배느린시스템에서 돌려도 잘도는것들 많거든요..

느려도 상관없는것들을 한다면 충분히 가능한일이지요...그러니까 적제적소에 맞게 사용해야한다는말에 백번동의하는겁니다.
버스가 느리다고 택시만 있고 버스는 없어져야할물건이 아니듯이말이죠..

그러나 분명한건 상당한 차이가있음에도 차이가 거의 안난다고 1~2%수준에불과하다고 말하는게 분명 잘못알고 있지 않는가라는겁니다.

youbit의 이미지

1~2% 수준은 분명 아닙니다. 그 정도면 온 세상이 자바 어플리케이션으로 뒤덮였을 겁니다. 설사 그게 가능하다고 해도 그냥 된다는 것도
아닙니다.

자바와 C/C++의 성능차이를 부정하는 사람은 없습니다. 문제는 한 쪽에서 '10~20%까지 좁힐 수 있다'라고 말하는데 반해서
다른 쪽은 '수백~수천%'라고 말하는데 있습니다. 그 10~20%라는 수준은 GC나 각종 오버헤드까지 고려하여 심혈을 기울여 디자인한
어플리케이션을 가정한 것임에도 불구하고 몇 배나 차이가 난다고 말하는건 좀 이상하지 않습니까?
'잘만들면 10 ~ 20% 차이까지 줄일 수 있다'는데 다른쪽에서 '너네가 아무리 잘만들어봐야 몇 배나 느려'라는 말을 듣고 '그런가?'
할 사람이 어디에 있겠습니까?

상당한 차이라는 말은 좀 애매합니다. '상당한'이라는 기준은 어떤 애플리케이션이냐에 따라 좀 다르기 때문입니다. 10~20% 라도
도저히 감당하지 못할 격차가 될 수 있고, 몇 배가 되더라도 넘어갈 수 있는 상황이 있습니다.

중요한 건 어떤 도구냐가 아니라 누가 그 도구를 쓰느냐는 것이라는 말에는 동의할 것 입니다.
설령 자바를 쓰더라도 충분히 숙련된 개발자는 C/C++과 비교해도 떨어지지 않는 어플리케이션을 만들 수 있습니다. 이런 관점을
유지하면서 '자바가 C/C++보다 8배나 느린가?'라는 질문에 대답해보자면,

'그건 당신이 자바 코드를 어떻게 짜느냐에 따라 다르다. C/C++과 비교해도 뒤지지않을 수 있고, 8배가 아니라 80배가 차이
날 수도 있다. 언어자체의 성능은 생각보다 크지않다. 결국 그것은 만드는 사람에 따라 좁힐 수 있다'

라고 대답할 수 있겠습니다. 이게 잘못알고 있는 건가요? '자바는 원래 느리니까 당신이 아무리 잘짜도 느리다'라고 대답해야
하는걸까요? 여기서 서로 대립하고 있는 것은 '자바 코드를 만드는 사람에 따라 그 차이는 없어질 정도로 좁혀질 수 있다'와
'자바 자체가 느리므로 C/C++을 따라올 수 없다'는 것이지 '자바랑 C 중에 누가 잘났냐'는게 아닙니다.

'자바로 만든 프로그램이 아무리 잘나봤자 C/C++을 따라올 수 있을 것 같아?'라는게 오히려 잘못알고 있는게 아닙니까?

익명사용자의 이미지

세상엔 서로의 다양함을 인정해야하듯 서로장점을 인정해야하지 않나요..
바꿔말해서 자바가 C보다 개발도 쉽고 vm 위에 안정적으로 돌고 속도도 C나 별차이 안나고.. 그렇게 말하면..
C하는사람들은 다들 바보인가요? 어찌그리 매번 C/C++과 비교해가며 C하는사람들을 무시하나요...
그럼 그토록 오랜세월 발전되어온 C/C++컴파일러에의해 최적화된 코드만을 생산하여 수행하도록한 C가
vm 위에도는 자바랑 별반차이도 안나는걸 뭣하러 개발하나요.. 다자바로하지..
그러한 말들은 상당히 C/C++ 을 무시하는처사입니다. 자바하시는분들이 번번히 C/C++을 들추어가며 속도도 별반차이 없네 무시하는데
그런근거없는말들도 자꾸들으면 화납니다.
분명한건 아직도 상당한 차이가 있으며 차이날수밖에 없다고 봅니다. 자바가 발전하는만큼 C/C++ 컴파일러도 발전하게되있습니다.
아니오히려 오랬동안 발전되어온 C/C++의 기법을 자바가 배워서 적용한다고 봐도 과언이 아니겠지요..

youbit의 이미지

엄밀히 따지면 C/C++은 주류 계층입니다. 자바/닷넷은 특정 영역을 제외하면 언어의 세대교체를 주장하는 비주류 계층입니다.
주류에서 비주류를 무시한다는 말은 들어봤어도 비주류에서 주류를 무시한다는 말은 처음듣는군요.
애시당초 자바와 같은 버추어 머신상의 언어는 그 복잡함으로 인해 C/C++ 프로그래머들에게서 '느리다'는 평가를 받아왔습니다.
시간이 지나면서 그 단점을 극복하기 위해 미리 VM 자체에서 컴파일 최적화를 수행한다던가, 실행도중 편법을 쓴다던가 하는 식으로
C/C++과의 격차를 최대한 줄이려고 노력하며 발전해왔습니다. 하지만 아무도 인정하려하지 않았습니다. '발전했지만 그래봤자...'
정도랄까요? 이게 오히려 무시가 아닙니까?

설령 자바가 C만큼 빨라진다고 해도 C/C++이 가진 장점은 많습니다.
포인터는 양날의 검이죠. 엄밀히 말해서 그건 단점이 아닙니다. 그저 다루는게 까다로워서 다들 기피하는 것 뿐이죠.
무거운 JVM 위에서 돌아가는 어플리케이션과 비교해서 네이티브 어플리케이션은 운영체제와의 협조도 쉽고 가볍고 빠릅니다.
자바가 아무리 빨라진다고 하더라도 완전히 동등해질 수는 없습니다. 뒤에서 수행하는 일이 더 많으니까요. 배포 역시 네이티브
어플리케이션이 용량도 작고 수월합니다. 이건 '플랫폼에 독립적인 프로그램'과 '플랫폼에 종속적인 프로그램'이 서로 나눠가지는
장점과 단점입니다. '속도차이가 별로 안 난다고? 그럼 누가 C/C++하냐?'라는 질문은, C/C++의 장점은 속도하나밖에 없다는 말로
들리는군요. 정말 그렇습니까? 아닐텐데요.

여기서 덩치가 작고 날렵한 대신에 자기 동네에서 달리기는 최고인 아이와 덩치가 크고 둔중하지만 여러 동네를 전전하는 아이가 있다고
가정해보죠. 날렵한 아이 쪽에서 덩치 큰 아이에게 '넌 왜 그렇게 둔해빠졌냐'라고 놀려서 여러가지 방법으로 달리기 속도를 올렸습니다.
예전에 비해 눈에 띄게 발전해서 덩치 큰 아이가 '이제는 나도 너에게 그리 뒤지지않아'라고 말했더니 날렵한 아이가 화를 냈습니다.
'그 덩치로 나를 따라올 수 있다고? 너 나를 무시하는거 아니야?' ... 자, 누가 누굴 무시하고 있는 건가요? 누가 화를 내야 맞습니까?

왜 도대체 다들 '상당한 차이'를 들먹거리는지 모르겠습니다. 그냥 '2배 차이' 아니면 '10배 차이'라고 정확히 말하면 안됩니까?
그게 아니라면 '어떤 상황에서 몇 배의 차이'라고 말하면 안됩니까? '내가 예전에 어떤 걸 만들었는데... 재보니 자바가 2배는 느리더라구'
라고 구체적으로 말해주시면 안됩니까? 속도 차이가 문제가 아니라 '무조건 그렇다'는 식의 말이 답답해서 화가 나는 겁니다.
그게 그냥 그런거라면 '천민하고 양반은 상당한 차이가 난다'는 시대착오적인 논리와 무엇이 다릅니까. 원래 그런거고 앞으로도 그런거라면요.

자바가 발전하는만큼 C/C++ 컴파일러도 발전한다는 말은 앞 뒤가 바뀌어 있군요.
C/C++ 컴파일러가 발전하면 C/C++로 만드는 JVM에 성능 향상이 있습니다. C/C++의 발전이 없다면 자바의 기반인 JVM은 한계에 부딪힙니다.
자바가 발전해봤자 C/C++ 에는 아무런 도움이 안되지만 C/C++의 발전은 자바에 엄청난 도움이 됩니다. 그리고 C/C++의 기법을 배워서
적용한다는 것은 당연한 것입니다. 후발주자가 선발주자의 것을 배우지않으면 어디서 배운단 말입니까? 모르는 것을 배우고 부족한 것을 극복하
려는 노력은 부끄러운 것이 아닙니다. 오히려 그것을 인정하지 않는 것이 부끄러운 것이죠.

marzok의 이미지

Concepts of Programming Languages by Robert W. Sebesta의 책을 보면

랭쥐지 평가 기준으로 크게 4가지를 들고있습니다.
1. 읽기 쉬운가?
2. 쓰기 쉬운가?
3. 믿을만 한가?
4. 얼마나 저렴한가?

그러한 점에서 바라보면 위에서 이야기한 포인터는 4번중에서도 아주 일부에 도움이 될뿐 나머지 모든 항목에 반합니다.

물론 실제로 구현하는데 많은 제약이 있기 때문에 위의 4가지를 모두 만족하는 랭귀지는 없습니다.
그렇지만 적어도 지금 새로이 만들어지는(진화하는) 랭귀지는 위의 4가지 항목을 잘 만족시키는 방향으로 가고있습니다.

c가 만들어질 당시에는 하드웨어의 비용이 가장 비싸서 하드웨어 성능을 최대로 끌어 올리는게 가장 효율적인 방식이었지만
지금와서는 트레이닝 비용이나 유지보수 비용이 훨씬 큰 상황입니다.

랭귀지 설계/평가에 대한 관점을 좀 대중적으로 가져갈 필요가 있지 않나 싶습니다.

youbit의 이미지

포인터는 확실히 가독성, 사용성, 신뢰성 모두에 장애물이 된다는 것에 동의합니다. 개인적으로 그래서 포인터를 싫어합니다.
무엇보다 사용성은 개발자가 고난을 감수하면 그만이지만 가독성과 신뢰성의 손상은 어플리케이션 전체의 죽음이니까요.
그래서 포인터는 C언어의 장점이자 단점이지만, 굳이 나눠야한다면 장점에 가깝다는 생각입니다. 포인터가 있음으로해서 C언어는
로우레벨과 하이레벨의 광범위한 영역을 모두 다룰 수 있지 않습니까?

비베, 델파이, 자바, 닷넷 등의 대중적인 언어가 필요한 부분이 있는가하면 C/C++이 없으면 안되는 부분도 많습니다. 만약 당장에
C/C++를 사용할 수 없게 되어버린다면 도저히 그 공백을 메울 수 없을테죠. 다루기가 까다로워서 싫기는 하지만, 포인터는 C/C++의
특징이자 장점이라고 생각합니다. 포인터를 단점으로 생각해서 제거한다면 C언어는 죽음을 맞이할 것 같습니다. (좀 과장일까요? ;;)
음... 잘못손대면 파멸을 이끌어오지만 컨트롤만 할 수 있다면 엄청난 힘을 얻을 수 있는 마검 정도의 비유가 좋겠군요? ^^

솔직히 요즘 프레임워크가 대세다보니 자칫 포인터와 같은 기본적인 것을 무시하게될까 걱정됩니다. 프레임웤이 편하긴한데 말이죠.
물론 똑똑한 10명이 잘다루는 엄청 효율적인 언어보다는 1000명이 그럭저럭 효율적이면서 안정적으로 돌릴 수 있는 언어로 설계/평가에 대한
관점을 가져야한다는 것은 동의합니다. 요즘 나오는 언어들이 확실히 그렇더군요. 둘러보면 재밌는 언어가 많습니다.
배울 것은 많고 아는 것은 작기 그지없군요. 한숨만 나올 따름입니다.

익명사용자의 이미지


0에서부터 8까지 무한소수점에서부터 점차증가시켜가며 어쩌고저쩌고 전체의 합을구하여 x의 증가분만큼 y의 증가분으로 나누고 어쩌고..

줄줄줄.. 이런식으로 썻습니다..

수학책을 이런식으로 써놓으면 일반인들은 좋아하겠죠... 진짜 좋아할지 도 잘모르지만...

저걸 기호로써놓으면 어떨까.. 아마도 대부분 첫인상은 이게머야.. 아골치아파.. 이런식의 인상일겁니다.

그러나 어느것이 맞습니까? 과연가독성이 떨어지나요? 사용성이 떠어지나요? 신뢰성이 떨어지나요?

님이 잘모르는기호가 나왔다하여 그게 수학자전체적으로 가독성사용성신뢰성이 떨어진다고 할수 있습니까? 자신이 수학자인가 부터 생각해보셔야지요..

수학책이 수학의 기본지식이 있음을 감안하여 쓰여진책이라고 봐야지.. 기본도 없는사람 보라고 만든책아닙니다.

마찬가지지요.. C프로그램또한 최소한 포인터는 안다고 생각하고 소스를봐야지.. 기본도 없는사람한테 가독성등을 논할순 없습니다.

그러면 과연 포인터에 자유로운사람은? 매우편하죠.. 간편하게 표현되니 가독성더좋고.. 자신이 사용해도 포인터쓰면더쉽고..

신뢰성좋고... 왜항상 자신이 모르겠다하여 그런식으로말하면안되죠.. 수학도 깊이가있듯.. 프로그래밍도 마찬가지 아니겠어요?

대학교수가 어려운 수식을쓴다고 탓하실겁니까?

youbit의 이미지

요즘은 언어들을 보시면 포인터 연산을 제공하지않는 단순한 레퍼런스 뿐이지만 그럼에도 아무런 문제가 없습니다.
뒤에서 모두 알아서 처리해주기 때문이죠. 즉, (연산이 가능한) 포인터를 굳이 사용하지 않아도 일부 영역을 제외하면
실질적으로 아무런 장애가 없다는 말입니다. 만약 포인터가 말씀하신대로 가독성, 사용성, 신뢰성에 도움이 된다면
C++ 이후의 언어들이 굳이 포인터 연산을 제거할 필요가 있었을까요? 그게 양날의 검이었고 한 쪽날이 자신을 해치는 경우가
있었기 때문에 한 쪽날을 제거해버리고 검이 아니라 한 날의 도(레퍼런스)로 만들어버린 것 아니겠습니까?

굳이 쓰지않아도 해결할 수 있는 문제를 불편함을 감수하면서까지 사용한다는 것은, 대학교수가 일상적인 말로 설명할 수 있음에도
불구하고 번거롭게 수식을 늘어놓는다는 것과 같습니다. 같은 대학교수라면 알아들을지 모르지요. 그런데 프로그래머도 마찬가지일까요?
열 줄의 코드를 한 줄로 표현할 수 있다며 자랑하는 프로그래머를 어떻게 생각하십니까? 그 한 줄을 다시 열 줄로 풀어서 해석해야하는
동료 프로그래머는요? 애시당초 코드 자체가 수식이나 다름없는데 가능하면 빼도 괜찮은 건 빼는게 이해하기 좋지않습니까?

제가 말하는 가독성, 사용성, 신뢰성은 모두 상대적인 것입니다.
레퍼런스만을 사용하는 언어에서는 포인터를 쓰면서도 따로 포인터를 쓴다는 인식이 없습니다. 포인터지만 포인터가 아니니까요.
그래서 상대적으로 사용성이 높습니다. 읽는 입장에서도 포인터라는 걸 인식하지 않아도 상관없습니다. 그래서 상대적으로 가독성이 높습니다.
'설마 이게 코드 어디선가 다른 주소를 참조하도록 바뀌지는 않았겠지?'라고 생각할 필요가 없습니다. 아예 불가능하니까요. 그래서 상대적으로
신뢰성이 높습니다.

물론 사용성은 쓰는 사람이 숙련되면 해결되는 것이고(이게 뭐가 불편해?), 가독성도 읽는 사람이 숙련되면 해결되는 것이고(이게 뭐가 어때서?)
신뢰성은 실수만 하지않으면 그만입니다(그건 초보나 하는 실수지!). 그게 코드의 학문적인 깊이하고 연결된다고 생각하지는 않습니다.

제가 부족하면 보충하면 그만입니다. 하지만 제 코드를 읽는 사람에게 (가능하면) '너 내 수준도 안돼? 이게 읽기 어려워?'라고 말하고 싶지는
않습니다. 그리고 최대한 '실수가 일어날 수 없었으면' 좋겠습니다. 어디까지나 제가 원하는 것은 스스로에게도 그리고 상대방에게도 깔끔하고,
읽기쉽고, 신뢰성 높은 코드일 뿐입니다. 그게 학문적으로 깊이가 낮은 목표라면 - 그렇게 생각하지는 않고있었지만 - 어쩔 수 없지요. 복잡한
수식은 일단 알아만두고 나중에 찾아서 깊이있는 코드는 필요할 때 만들어보도록 해보죠.

옷이 몸에 딱 맞으면 입고있다는 걸 의식하지 않습니다. 신발이 딱 맞으면 신고있다는 걸 느낄 필요가 없습니다. 포인터를 굳이 사람의 손으로
다루지않아도 된다면 굳이 인식하면서 사용할 필요가 없습니다. '인식하지 않고도 사용하고, 읽을 수 있는 것을 굳이 인식하면서 사용해야
하는 것' 그리고 '그렇기에 조심해야할 필요가 잇는 것'. 이게 제가 말하는 포인터의 사용성, 가독성, 신뢰성의 상대적인 불리함입니다.
검이든 도든 적을 확실하게 베어버릴 수만 있다면 그만이니까요.

아, 예전에 무협지에... '백일창, 천일도, 만일검'이라고 했던가요? 도는 천일이면 익히지만 검은 만일이 지나야 익힐 수 있다. 그래서
만병지왕이라고 부른다-라고 했습니다. 검이 익히기 힘들고 오래걸린다는 건 검의 특징입니다. 실수하면 자신이 다치기 쉽다는 것도 검만의
특징입니다. 이걸 굳이 특징이 아닌 단점이라고 부를 필요는 느끼지 못하겠습니다.
그래서 '여러가지 단점에도 불구하고 C/C++의 포인터는 단점이 아니다'라고 생각합니다.
그저, 지금의 세태가 요구하는게 검이 아니라 도일 뿐 아닙니까?. 워낙 빨리돌아가는 세상이니 '萬日'이나 기다려줄 수 없는거죠.

익명사용자의 이미지

님은 프로그램하실때 누가('P'자도 모른는사람)와서 그거머그렇게해.. 그저 if else 로 계속하면되지.. 멋하러 어렵게 for 는머야..
님이 생각할때 분명 for루프돌며 switch case 문도는게 맞다고 생각되는데 그게 어렵다고 if else로 줄줄이 써달랍니다..
어떻게 생각하세요...?
님은 그렇게 할수 있나요? 전못하겠습니다. 안하고 맙니다.
이것이 옳고 그름을떠나 마땅히 해야할것과 그렇지 않아야할것이 있습니다..
님이 for 문을 몰랐다면 if else 로 일관했을수도 있지요.. 하지만 아는이상.. 그렇게 하긴힘들겁니다.
너잘난체하느라고 for 쓰는거 아니냐? 라는비판에 무서워 마땅히 해야할것을 하지 않는다면 당신의 존재는먼가요?

youbit의 이미지

누가 10을 10번 더하고 있으면 그것보다는 '곱셈'을 가르치는게 물론 맞는 말입니다. 그건 산술연산을 위해 반드시 알아야할 것을
모르고 있는 것이니까요. 하지만 그래프의 기울기를 알려주는 시간에 미분을 가르치지않고, 넓이를 구하는 시간에 적분을 가르치지는 않습니다. 게다가 만약 그래프의 기울기나 넓이를 구하는 것만으로도 아무런 지장이 없다면, 그래서 필요하지 않다면 미적분을 사용하라고 강요할 필요는 없다고 생각합니다. '미적분은 무엇이다' 정도만 이해하고 있으면 언젠가 다시 교과서를 들춰서 사용할 수 있습니다.

if~else를 남발하는 사람에게 switch 문을 가르쳐주는 것도 마찬가지입니다. 이건 가르쳐주는데 문제도 없을 뿐더러 잘못사용할
가능성은 거의 없습니다. 읽는데도 마찬가지죠. 하지만 포인터가 남발된 코드도 마찬가지입니까? 가르치는 것도 간단히 안되고,
디버깅하는 것도 힘듭니다. 리팩토링은 두말할 필요가 없지요. switch 문과 포인터를 동격으로 보기에는 좀 격이 다르지않습니까?
포인터의 이해가 아니라 사용이 프로그래밍의 기본이라고 생각하시는 것 같은데, 그렇다면 요즘 언어들은 기본도 없다는 말이 됩니다.
기본이 없는 언어가 어떻게 무너지지않고 잘 버티겠습니까? 막상 그렇게 말씀하시는 님도 분명히 포인터의 사용은 가능하면 자제하라는
말을 수없이 들으셨지 않습니까. 포인터의 포인트는 반드시 필요한 곳에만 쓰는 것이라고 말이죠.

그렇다면 만약 포인터를 사용하지 않고도 문제를 해결할 수 있다면 굳이 포인터를 사용하기를 고집해야 하겠습니까?
그건 취사 선택의 문제입니다. 포인터로 얻는 것이 크다고 느끼는 사람이 포인터를 사용하지 않을 이유는 없습니다. 상대적으로
얻는 것보다는 잃는 것이 많다는 사람은 포인터없이 레퍼런스만을 사용하면 되는 것이죠. if~else 문이 switch 대신에 쓰여서
이익을 얻을 수 있는 상황이라면 굳이 switch 문을 사용할 필요가 없습니다. 아는 이상 그렇게하긴 힘들지요.
하지만 그게 이득이 없다는 걸 알기 때문에 힘든거지 어느 상황에서나 switch 문이 if ~ else 보다 낫다고 생각해서가 아닙니다.

'너 잘난체하느라고 for 쓰는거 아니냐?'라고 묻는다면 그냥 '쉬우면서 더 편한 방법을 알고있다'라고 얘기해주면 그만입니다.
배우길 원하지않는다면 (그래도 괜찮다는 가정하에서) 그냥 냅두면 그만입니다. 그런데 잘난체 한다는 것은... 포인터를 사용하면
뭔가 좀 더 잘난 프로그래머가 된다는 것인가요? 그건 그냥 포인터를 쓰느냐, 레퍼런스를 쓰느냐의 선택문제 아니었던가요?
각 자 추구하는 바가 다르고, 중요시 여기는 것이 다릅니다. 그 어느것도 우월하지 않고 미천하지도 않습니다.

그리고 만약 정말로 무식한 사람이라서 기본도 없이 '너 잘난체 하는거지? 그렇지?'라고 저를 비판한다면 저는 그것에 대해 설명해주고,
그래도 무조건 잘난체라고 소리친다면 그냥 비난을 받아들이겠습니다. 대화도 비슷한 수준에서야 가능한거지 굳이 그런 사람의 비난에
가치를 둘 필요가 있습니까? 음... 그리고 잘못 이해하셨는데 저는 포인터의 사용이 얻은 것보다 잃는 것이 많기 때문에 지양하는거지
그걸 사용하면 누군가 '너 지금 잘난체 하는거냐?'라고 말할까 무서워서 피하는게 아닙니다.
오히려 '난 포인터를 사용해. 근데 포인터 사용 안하는 저놈들은 뭐지? 수준이 낮아서 그렇군.'이라는 생각은 위험하지 않겠습니까?
초기 어셈블러들이 C 프로그래머를 보면서 비웃었듯이 말이죠.

익명사용자의 이미지

포인터가 익히는데 그리어렵지도 않으며 위험하지도 않습니다.
여테누가 포인터 자제하란소리는 못들은것같군요..
제가 만일 누가 포인터 남발한? 소스를본다면 참재미있을것같습니다.
보고 싶군요..물론 불필요하게 어거지로 사용한걸말하는건 아닙니다.
나름데로 의미가 있다면 한수배웠다는생각에 매우감사히 생각하겠죠..

무얼하는데 더쉬우면서 편하고 효율적인방법을 알고 있습니다.
그건 포인터건 뭐건 적절한곳에 적절히 사용하는것입니다.

쓴귤의 이미지

레퍼런스, 배열, 원시 문자열 자료형을 쓰지 않고 꼭 포인터를 써야하는 경우가 어떤 것이 있는 지 사례를 들어 설명해주시기 바랍니다.

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

익명사용자의 이미지

포인터를 꼭쓰지말아야하는 사례를 들어 설명해주시기 바랍니다.

youbit의 이미지

님이 사용하시기에 어렵지도 위험하지도 않다면 그걸로 충분합니다.
하지만 '내가 쉬우니까 다들 쉽겠지. 어렵다고 생각하는 사람은 나보다 덜 떨어진 사람이군'이라고
생각하시지는 않으시겠지요? 실제로 제대로 사용할 줄 알면서도 포인터를 어렵다고 하는사람을 많이 봤습니다.
사용의 문제가 아니라 일단 그렇게 '느낀다'는 말입니다. 알면서도 언제든지 실수할 수 있기 때문에 말이죠.
무엇보다 약간 오해하신게 있군요. 포인터를 익히는게 어렵다는게 아닙니다. 개념은 쉽지만 그걸 익힌 다음
실제로 다루는 걸 어렵게, 좀 더 정확히 말하면 까다롭게 느낀단 말입니다. 사용할 수 있느냐, 아니냐의 문제가
아니라는 말이죠.

비유하자면 '운전히 어렵냐'고 운전할 줄 모르는 사람이 물으면 다들 웃을 겁니다. '그게 뭐가 어렵냐'고.
하지만 정말로 운전이 그렇게 쉽습니까? 교통신호, 카메라, 끼어들기, 촉박한 시간... 운전이 그렇게 쉬워서
대충해도 되는거면 좋겠습니다(별로 신경 안써도 교통사고가 안날테니까요). 운전 경력이 아무리 많더라도
이제는 쉽다며 대충 신호살피고 대충 끼어들어서 대충 교통신호 지키는 사람이 있을까요? 그건 좀 위험한
행동아닙니까? 익숙해졌다고 정말로 그게 쉬운 겁니까?

무엇보다 중요한 건 님이 '포인터는 마땅히 해야할 것'이라고 말하는 반면에 저는 '다른 방법' 있으며
그리고 선택하지 않는다고 '우월하다'거나 선택한다고 '수준낮다'는 판단은 틀렸다는 말입니다.
'마땅히'와 같은 말은 사용에 주의를 기울여야하는 말입니다. 마땅하지 않으면 도대체 뭐란 말입니까?
왜 굳이 선을 그어놓고 '여기는 맞고, 저기는 나쁘고'라는 식으로 말씀하시는지 모르겠군요.
상대적으로 왜 편하고, 왜 사용하는지 구구절절히 설명을 했는데 '난 어렵지도 않고 좋기만하다'라고
대답하시니 굉장히 무안하군요. 그런 식으로 말하시면 저도 더 이상 굳이 논리적으로 말할 필요를
못 느끼겠습니다. 전 포인터보다 레퍼런스가 좋습니다. 그냥 각자 좋은 것 쓰죠.

익명사용자의 이미지

탁구하는사람들이 맨날 축구하는사람보고 축구공이 크네 무거워서 다칠수도 있다..축구공은 버리고 탁구공만가지고 놀아라..
볼때마다그럽니다.
이것은 축구자체를 부정하는것이지요... 당연히 화날수밖에 없습니다. 남들이야 축구공을 가지고 놀든 볼링공을가지고놀든. 상관하지 마십쇼.. 다치건말건 그들이 할일입니다.
그들이 그것으로 무슨결과를 냈는지를 두고 말씀하세요..
자신들이 그들과더좋은결과를내고 결과를 가지고 말하세요.. 아무것도 낸것도 없이 남의것을가지고 그건 좋으네 안좋으네..
이무슨 매너없는 짓입니까.?

youbit의 이미지

매너없는 짓이라고 느끼셨다면 죄송합니다. 가능하면 객관적으로 말하려고 노력하고 있습니다만, 기분나쁘셨다면 사과드립니다.

'축구공이 크니까 무거워서 다칠 수 있다'라고 말하는 탁구하는 사람들은 물론 아무것도 낼 수 없습니다. 도대체 탁구하는 사람이
왜 축구하는 사람에게 축구공가지고 주의를 줘야합니까? 그건 축구하는 사람들이 사용하는 것인데 말이죠. 지나친 참견입니다.

하지만 저는 포인터를 사용한 것이 레퍼런스를 사용하는 것보다 상대적으로 까다롭고 위험하다고 말한 것이지,
그게 위험하니까 사용하지 말라고 한 적은 없습니다. 탁구하는 사람이 축구하는 사람에게 '축구공은 탁구공보다 크다. 만약 맞으면
더 아플 것이다'라고 말한다면 그게 잘못된 일입니까? 물론 축구공을 가지고 노는 사람이 축구하다가 다치는 건 상관할바가 아닙니다.
그것까지 충분히 감안하고서 축구를 하는 사람들일테니까요. 하지만 '축구공이 탁구공보다 크다. 맞으면 아프다'를 말하는 것까지
'지나친 참견'이라고 말하는 건 말그대로 좀 지나치지 않습니까? 어떤 의도로 해석하셨는지 모르겠지만 한마디로 정리하도록 하죠.

첫째, 포인터보다는 레퍼런스를 사용하는 것이 효율성을 제외한 가독성, 신뢰성, 사용성에서 이점이 있다고 생각됩니다.
둘째, 요즘 나오는 언어는 효율성보다는 다른 것을 중시하고 있는데 바람직한 현상이라고 생각합니다. 환경이 변했으니까요.

이것도 참견이라고 생각하신다면, 일단 먼저 사과드립니다. 나름대로 객관적인 판단이라고 생각했는데 아닌가보군요.

익명사용자의 이미지

그건 아닙니다.

물론 프로그램 맨처음하시는분이 포인터 사용하면좀 헷깔릴수 있겠죠.. 그리 어렵다고 생각되지도 않지만..

일단 경력1년도 안된사람이면 어려우면 잘사용안하면되고 대부분 1년이 넘어가면 자기생각에 좀한다싶어 상요합니다.
그러다 오류내기도 하는건 사실이지만..

한 3년을 넘어가면 포인터때문에 뭐가 잘안된다거나 어렵다거나 하진 않습니다..
대부분 3년을 넘어가면아마도..
포인터때문에..
1. 읽기쉬운가? 그렇다.
2. 쓰기 쉬운가? 그렇다.
3. 믿을만한가? 물론이다.
4. 얼마나 저렴한가? 매우저렴하다.
가됩니다.

그렇다면 경력1년도 안되는사람들의 푸념을 덜어주기위해 포인터를 없애야할까요 있어야할까요?

목공소에 전기톱이 어린이들에게는 위험하다하여 전기톱을 없애고 수동톱만 써야한다는거나 마찬가집니다.
물론 어린이들에게는 위험할수있고 처음사용하는 신입에게는 위험할수도 있겠죠.. 신입들은 그저구경하고 좀배워서쓰면됩니다.
그렇다해서 그편한 전기톱을 없앨겁니까?그런목공소는 아무데도 없을겁니다.
어렵고쓰기힘들고 하면 C하는사람들은 mi쳤다고 그걸 사용할까요?
더좋으니까 쓰지요...
맨날 손 톱만 사용하던사람은 그럴겁니다. 저게머하러 필요하나.. 잘못하다간 다치고..무섭고 손으로 해도 다되는데..
뭐라고 님들은 뭐라고 설명하시겠어요?

쓴귤의 이미지

포인터가 어렵지 않다고 해도 대부분의 상황에서 포인터를 쓰지 않고 더 쉽게 할 수 있는 방법이 있습니다. 레퍼런스, 배열, string 원시 자료형만으로도 C 포인터의 상당부분은 대체할 수 있습니다. 메모리를 자동관리하면 더 간단하고요. 물론 메모리를 직접 건드려야하는 일들이 있고 이건 무조건 C에서 포인터로 해야합니다. 안 그렇게 해도 될 일을 굳이 C나 포인터로 할 필요는 없죠.

포인터를 안전하고 편리하게 쓸 수 있는데 3년이면 충분하다고 하지만 리눅스 커널에도 포인터 관련 버그가 잔뜩 있습니다. 리누스 토발쯔나 리눅스 커널 프로그래머들이 '어린애'들이라서 그런 건 아니죠. 그만큼 포인터를 잘 다루기가 어려운 겁니다. 그리고 3년이면 충분하다는 데 그 3년 동안 다른 언어 쓰는 사람은 손놓고 놀고 있는 게 아닙니다. 굳이 C를 써야할 곳이 아니면 안 쓰는 게 이익입니다.

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

익명사용자의 이미지

님이 아직도 포인터를 이해못하기때문에 이런말합니다.
포인터로 하면 간단히 처리될일을 궂이 어렵게 처리해야할이유가 없죠..
포인터 쓰지 않고 더쉽게 되는방법이 있는데 쓰는바보는 없습니다.
모든걸 고려할때 가장쉽고 효율적인 방법을 고려할뿐입니다.. 그방법중에 포인터쓰는방법이 있는것이고요..
님은 생각하겠죠.. 그럼 없이도 다할수있는데 머하러쓰냐? 없이도 가능하겠지만 훨씬 더어렵고 비효율적이거든요..
맨날 걸어다니던사람은 자동차가 편리한줄조차 모르겠죠.. 그러나 둘다타본사람은 자동차가 편리한줄압니다.그러기때문에 차를타지요..
편리하지도 않고 효율적이지도 않는데 궂이 자동차타는바보가 어있을까요?

리눅스커널에 포인터관련 버그가 있다구요?(뭔가요?) 있을수도 있겠죠..하지만 포인터를쓰지 않았다면 더많은 버그가 있었을겁니다.
또한 그렇게 효율적으로 만들수도 없었을겁니다.
자바로 만들면 버그없나요? 다른버그가생기죠.. 자동차타면 사고날수도 있습니다. 하지만 자동차 안탄다고 사고안나나요?
자동차타고 서울-부산을 100번왕복하면 평균 1회의 사고가난다칩시다. 걸어서 서울-부산 100번왕복해보면 차사고는안나도..
걸어가다 짐승한테 물리거나 돌부리 넘어지거나 눈비로 감기걸리거나 발이 부르트거나 사고가 더적을것같습니까?
너무 답답하신소리만하시네요.. 자신의 실력을키우면되는거지 궂이 남이하는걸깍아내리려는 자세로 무슨발전이 있을까요?

쓴귤의 이미지

도대체 누가 C를 깎아내렸다는 건지. 여기 C가 나쁘다고 말한 사람 한 명도 없습니다. 단지 몇몇 익명 사용자가 C 만능주의에 빠져있을 뿐이죠.

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

youbit의 이미지

님 글을 읽다가 궁금한 부분이 있어서 질문 드립니다.

'리눅스 커널에 포인터를 쓰지않았다면 효율적으로 만들 수 없었다'는 말은 맞습니다. 커널은 소프트웨어 중에서도 로우레벨한 영역이라
직접 접근이 없다면 사실상 불가능하다고 생각되니까요. '포인터의 비사용은 비효율성을 댓가로 안정성을 확보한다'는 이점이 강합니다.
커널에서 비효율성을 댓가로 지불할 수는 없지요. 좀 안전하자고 목숨을 내놓을 수는 없지않습니까.

궁금한 것은 포인터를 쓰지않았다면 더 많은 버그가 있었을 것이라는 부분입니다. 포인터를 사용하지않고 레퍼런스를 사용했기 때문에
버그가 발생할 수 있는 경우란 어떤 경우를 말씀하시는건가요? 그게 궁금합니다.

PS :
비유 중에 '자동차를 타고가는 것'과 '걸어가는 것'의 비유를 드셨는데, 레퍼런스는 '사용자가 변경할 수 없는 포인터'에 불과합니다.
자동차로 가는 것과 걸어가는 것은 적절한 비유가 아닌 것 같습니다. 빠르지만 교통사고시 위험이 큰 스포츠카와 상대적으로 느리지만
교통사고시 더 안전한 SUV 정도의 비유가 적절할 것 같습니다. 즉, 질문은 'SUV가 안전하기는 하지만 그렇다고 교통사고 안나느냐?'가
더 적당할 것 같군요. 그런데 SUV가 교통사고가 나는 것은 '스포츠카를 안타서'가 아닙니다. 말씀하시는 바를 정확히 모르겠습니다.
여하튼 제가 묻는 것은 '포인터 대신 레퍼런스를 사용해서 버그가 나는 경우', 즉 '스포츠카 대신 SUV를 타서 위험한 경우' 입니다.
비유가 적절하지 않으다면 바꿔서 대답해주십시오. (그런 경험이 있었던 듯하여, 진짜 순수하게 궁금해서 질문드리는 겁니다)

익명사용자의 이미지

하나의 프로젝트를 완성하기위해 모든면에서 종합적으로 효율적인 방법을 동원해야함은 두말할것없겠죠..
설계부터도 어떤것을 상요할것인가 말것인가에따라 설계도 달라질수있고.. 모든것은 사소한것에서부터 바뀔수있습니다.
포인터를 사용하지 않을것이라면 애초 설계부터 달리해야함은 당연하겠죠..
또한 그것을배제한만큼 그에상응한 뎃가를 치르기위해 어느부분에선가 허리띠를 졸라매야함도 당연하구요..
어떤것을 포기한만큼 뎃가는 치르게 되있습니다.
실제로 어떤프로젝트에서 전문규약이매우 지저분?한곳에 처음엔 포인터를 쓰지 않고 처리하는로직이었으나..
너무 많은 오류로 인하여 무너질뻔하다가.
핵심부분을 님이우려하던 그포인터로 도배되면서..매우 안정적으로돌아갔습니다.
또한 효율적이며 단기간내에 개발되었고.. 매우 유동적이고 가변적으로 설계되었습니다...
그러면 포인터를 쓰지않고는 그렇게 되지 않았을것인가..? 안했을겁니다.. 개발기간이 더길어졌을것이며
쉽게 개발하지도 못했을것이기때문이죠..또한 속도가문제였습니다.속도또한장담못하는상황을 갈순없죠..
또한 포인터를 쓰지않을것이면 현제의것과 별반차이가 안날것이기때문이죠...
프로그래밍의 버그는 결국 인간의 실수입니다. 인간의 실수란 고난이도에서 발생할수도 있지만..
느슨하고 지루한 많은 양적으로 많은코드중에 발생할소지도큽니다. 오히려실수란.. 그런곳에서발생하지요..

말하자면 매일 100K로 9시간 단기간 근무하는 총알택시 운전수가 사고를 많이내는가...?
시속 50K로 매일 18시간씩 장기간 피곤하게 운행하는. 버스가 운전수가 사고를많이 내는가....?
난이도가 높다하여 사고가많다고 장담하실수 있습니까?

youbit의 이미지

'난이도가 높으면 사고가 많은 법이다'라는 말은, 그다지 틀린 것 같아 보이지 않습니다.
하지만 거기에 반박하지는 않겠습니다. 그게 아니라 '난이도가 높아도 숙련자라면 실수가 없다'
라는게 말씀하시는 의도겠지요?
(음... 원래 어려운 건 실수하기 쉬운 법인데, 말 그대로의 의미라면 이해가 안 갑니다)

하지만 말씀하신 예는 적합하지 않은 부분이 있습니다.

첫째, 속도 또한 장담할 수 없다는 말로 보아 속도가 중요한 프로젝트로 추측이 됩니다.
그런 경우 포인터를 쓰는게 당연합니다. 타임크리티컬한 프로젝트에 누가 자바를 쓰겠습니까.
레퍼런스로 인한 오버헤드가 문제가 되지않을 정도의 일반적인 프로젝트에서도 굳이 포인터가
최고라며 고집할 필요가 없다는거지, 레퍼런스 접근이 최고라는게 아닙니다. 마찬가지로
레퍼런스가 최고라며 요구사항을 무시한 선택을 한다면 둘 다 실패를 자초하는게 아닐까요.

둘째, 전문규약이 지저분하고 로직이 너무 많은 오류를 발생시킨다는 것은 레퍼런스냐 포인터냐를
사용하기 이전에 설계와 준비의 문제라고 생각됩니다. 님은 레퍼런스와 포인터를 완전히 별개의
것으로 생각하고 계신듯한데, 저는 그냥 포인터의 두 종류라고 생각합니다. 따라서 레퍼런스로
해결할 수 없는 문제를 포인터로 해결할 수 있다는 건 뭔가 이상합니다. 레퍼런스나 포인터나
결국 주소값이라는 건 변하지 않습니다. 차라리 레퍼런스로 했더니 너무 느려서 문제가 되었던 걸
포인터로 바꿔서 해결했다는 말이라면 이해가 갑니다.

셋째, 논쟁의 여지가 있지만 개발기간과 개발의 용이성은 도구자체보다는 설계와 준비 단계의
영향이 더 큽니다. 제대로 설계되었고, 준비된 프로젝트라면 시작할 때 선택했던 방법을 아주
못쓰겠다는 이유로 바꾼다는 건 좀 이상합니다. 시작 단계부터 무엇을 써야할지 완전히 오판했단
말인가요? 제가 이해할 수 없는 부분이 이 부분입니다. 도대체 무슨 경우에 속도(효율성) 문제를
제외하고 레퍼런스 방식때문에 프로젝트가 망가질 수 있습니까? 만약 그렇다면 레퍼런스 방식의
'안정성'이라는 장점은 사라지고 레퍼런스는 말 그대로 쓸모없는 방식이 되어버립니다.

넷째, 포인터 사용자가 100Km로 9시간 단기간 근무하는 총알택시 운전수라고 가정했는데 왜
레퍼런스 사용자는 18시간씩 장기간 근무하는 버스 운전사가 되어야하는지 모르겠습니다.
속도가 느린 건 맞습니다만, 느린 이유는 그만큼의 편리성을 제공하기 위해서 입니다. 비유가
적절치 못한 것 같군요. 포인터 사용자와 레퍼런스 사용자의 차이는 스틱 기어를 쓰냐 오토매틱을
쓰느냐와 같습니다. 효율성과 반응성이냐, 편리함과 안정성이냐의 차이가 아닙니까? 그 외에
무슨 차이를 찾을 수 있을지 모르겠습니다. 사용하는 언어와 방식에 따라서 개발자가 그렇게 차이가
납니까? 사용하는 말이 다르고 생김새는 달라도 미국인이나 일본인이나 둘 다 '사람'입니다.
굳이 한 쪽은 '택시 운전사' 한 쪽은 '버스 운전사'라고 나눌 필요가 있습니까. 어차피 똑같은
사람이고 똑같은 환경인데 사용하는 도구가 다를 뿐입니다.

다섯째, 저는 '포인터 대신 레퍼런스를 사용해서 버그가 날 경우'가 궁금한 것 뿐입니다.
'정말 그런 경우도 있단 말이야?'라는 의문이 들었는데, 도대체 어떤 경우인지 추측이 안가서요.
다시 한 번 말씀드리지만 정말로 그게 궁금한 것 뿐입니다. 설계나 그 외적인 문제가 아닙니다.

질문을 정정해야겠군요. 설계나 기타 외적인 환경은 완전히 동일하다고 가정하고, 포인터와
레퍼런스라는 '도구'를 바꿔 사용했을 때 '포인터 대신 레퍼런스를 사용했기 때문에 버그가 발생하는'
경우가 궁금합니다. 간단히 말하면 '이 프로그램은 포인터를 써서 개발했는데, 포인터 부분을 레퍼런스
방식으로 바꾸면 버그가 난다'라는 상황이 궁금합니다.
귀찮으시겠지만 간단한 코드로 보여주실 수 있다면 정말 감사하겠습니다.

익명사용자의 이미지

첫째:애초에는 속도에문제가 생길거란생각을 못했겠죠.. 나중에 해놓고보니 느렸던겁니다.
둘째:이런말계속해봐야 제자랑밖에 안되는데.. 어쨋든 기존사람은 설계를 그렇게 했었습니다..
그건 그사람의 스타일과도 관계있겠죠.. 물론저는 제스타일입니다. 그스타일은 바로 포인터를 쓰기때문에 생긴스타일입니다.
제가 그당시 포인터를 쓰지말아야한다는제약이 있었다면 결코그렇게 설계하지 않았을겁니다.
왜인지는 위에 이미 윗글에 이미 말했구요..저는 코딩스타일도 규제한다면 설계도 달리합니다.
동의못하시나요? 아마도 님도은연중에 그럴꺼라고 보는데요 크게차이는 안난다해도 조금씩달라질겁니다.

셋째:설계단계에서 완전히 오판한건 없습니다. 다만 프로젝트진행중에 예외사항에대해선 case by case 로 문제해결구조였고..그러나 수많은 케이스에 완전히 대처하지 못했던거죠..
넷째: 장기간근무라는건 긴코드를 의미합니다. 길게코딩해야한다면 그만큼 오타확률도 높겠죠?
또한 이런경험들한두번씩은 해봤을겁니다. 수정사항에대해 분명히 수정했는데..변한게 하나도 없이 여전히 오류가나더라..알고보니 밑쪽에 그런비슷한코드가 또있더라..길면한눈에 안들어오기마련이고 실수하기마련입니다. 꼬리가길면 밟힌다고 했던가요..
다섯째: 위에 이미 말한듯하네요..

youbit의 이미지

어떤 상황인지 이해했습니다. 힘드셨겠군요.
저는 코드레벨에서 레퍼런스 방식에 속도말고 어떤 결점이 있는지(예컨대 메모리 누수가 일어난다던가)가
궁금했었는데, 순수한 도구 자체보다는 외적인 것에서 생겨나는 버그를 말씀하신거였군요.
하긴, 변명의 여지없이 버그는 결국 사람이 만드는 것이니까요.

익명사용자의 이미지

> c가 만들어질 당시에는 하드웨어의 비용이 가장 비싸서 하드웨어 성능을 최대로 끌어 올리는게 가장 효율적인 방식이었지만
> 지금와서는 트레이닝 비용이나 유지보수 비용이 훨씬 큰 상황입니다.

자바가 C에 비해 트레이닝이나 유지보수에 상대적으로 유리하다는 뜻으로 해석하겠습니다.
실제로 그런가에 대해서는 지금 논의와는 상관없으니 넘어가기로 하고요.
성능은 여전히 중요한 이슈입니다. 이 글타래만 봐도 사람들이 성능에 얼마나 민감한지 잘 알 수 있잖습니까.
자바 진영에서 성능 향상을 위해 얼마나 노력을 기울이는지는 잘 알고 있습니다.
그것은 자바가 성능면에서 아직 개선해야 할 점이 많다는 반증이기도 합니다.
그런데 그런 현실을 외면하고 자바가 성능상으로도 문제 없어, 정 안 되면 하드웨어를 좋은 거 쓰면 되지
이런 식으로 생각하는 한 자바는 영원히 성능 논란에서 벗어나지 못할 것입니다.

marzok의 이미지

cost라는건 단순히 하드웨어 비용만 있는건 아니란 걸 이이기 한것입니다.

프로그래밍 랭귀지에 대한 책이 이러한 것들에 대한 이해를 도울거라 봅니다.

랭귀지는 어떻게 진화하고 발전하는지,
랭귀지가 성공하기 위해서는 어떠한 전략을 선택해야하는지,
지금 나와있는 랭귀지의 특징은 무엇인지,
지금 나와있는 랭귀지는 무엇을 목표로했는지 등을 알수있을겁니다.

단순히 개인의 느낌과 경험에 의존해서 가부를 이야기 할게아니라
프로그래밍 랭귀지의 역사와 그 발전 방향을 봐줬으면 합니다.

익명사용자의 이미지

느낌도 그렇고 경험도 그렇고..

랭귀지의 역사와 발전방향을봐도 그렇습니다.

얼핏들으면 그럴싸하지만.. 깊게 생각해보면.. 그건 아니다싶죠..

한마디로 초기에 뭔가를 간과한.. 오판이라고 생각되는데요..

youbit의 이미지

자바 진영에서는 성능 향상을 위해 노력을 기울이고 있고, 그건 자바가 성능면에서 개선해야할 점이 많기 때문입니다.
그저 많은 정도가 아니아 아주 많습니다. 일반적으로 보았을 때 만약 성능에 대한 동일한 관심정도로 프로그래밍한다면
즉, 프로파일링과 튜닝이라는 추가 필수 과정을 거치지않는다면 C/C++에 비해 성능상 격차가 벌어지는 걸 막을 수 없습니다.
간단히 말하면 C/C++ 프로그래머가 메모리 누수 찾는 시간에 자바 프로그래머는 병목지점 찾아야한다는 소리입니다.

그런 노력도 없이 '성능상 문제없어'라는 건 현실 외면이 틀림없습니다. 몇가지 일을 더 하면서 성능상 동일하다는 건 말이 안되죠.
하지만 왜 C/C++ 진영은 자바 진영의 노력마저도 '성능상 문제있어'라는 걸로 외면합니까? 간단한 벤치마킹으로 '성능상 문제없어'라고
맹신하는 건 문제지만 '그런 건 의미없어. 성능상 문제있어'라고 맹신하는 것도 문제입니다. 둘 다 모두 영원히 성능논란을 야기시킵니다.

저는 어떤 익명사용자 분이 '수백~수천%'라는, 이해할 수 없는 수준의 격차를 들기 때문에 여기에서 계속 말하고 있습니다.
자바 프로그램이 '몇 배에서 몇 십배나 느리다'는 말을 정말로 납득하십니까? 스크립트 언어 수준의 퍼포먼스라고 말이죠. 느리다는 걸
부정하는게 아니라 '성능상 문제있어'라며 어느정도인지 생각도 않고 무조건 느리다고 생각하는게 문제라는 겁니다.
인정하지 못하는 건 자바의 성능 문제가 아니라 사람들의 '근거없는 편견'입니다. 말로 하지말고 그냥 증거로 보여달라고 말하고 있습니다.
못 참겠는 건 자바가 낮게 평가받는게 아니라 불합리입니다. 왜 그렇게 일반적인 평가라는 것을 믿으십니까? 직접 테스트하고 평가해서
자신의 결과를 믿고, 그걸 다른 사람에게 제시하면 안됩니까?

'현실을 외면하지 말라'고 말씀하신다면 눈 앞에 '자바 진영의 노력은 인정하지만, 봐라. 아직도 이만큼의 성능차이가 나지않는가?'라고
하셔야지 무턱대고 '성능이 느리다는 사실을 인정해라'라고 말하는게 아닙니다. 하다못해 아이에게 꾸짖을 때도 '너, 이건 나쁜짓이야'부터
말하지 무조건 '잘못했지? 잘못했다고 말해'라고 윽박지르지는 않으실 겁니다.

무언가를 탐구할 때 기존의 '틀린 것'을 모두 '맞는 것'으로 가정해야할 때가 있습니다. 편견에 가려서 그냥 넘기지 않기위함 입니다.
말싸움이 아닌 논의를 하고싶으시다면 '당연한 것'을 먼저 면밀히 검토한 후에 '이게 당연하다는 증거는 바로 이거다!'라고 말해주시기
바랍니다.

참고로 여기서 논의되고 있는 건 몇 배 ~ 몇 십배의 성능 격차입니다. 저는 이클립스를 C/C++로 만든다면 좀 더 빨라질거라는 생각은 하지만
그게 10배나 빨라질 거라고는 생각하지 않습니다. 하다못해 2배나 빨라질거라고 생각치않습니다. 많아야 50% 정도가 아닐까 합니다.

익명사용자의 이미지

결론은 그겁니다. 과연 몇배느린가..

저런단순 벤치마킹이라는것도 믿을것은 못된다는겁니다.

테스트하는측이 어느쪽에서 했냐에따라서도 상당한차이가나겠죠..

결국 보통 비슷한프로그램끼리 비교해보든지 동일한프로그램의 성능을테스트해봐야겠죠..

youbit의 이미지

그러니까 소모적인 논쟁은 하지말고 좀 더 객관적으로 그걸 알아보는게 좋지않겠냐는 겁니다.
그렇지 않을 바에야 '자바가 느리다'나 '아니다. 빠르다'라는 논쟁은 의미가 없다는 말이지요.

익명사용자의 이미지

n값이 C에서는 20억, java에서는 2천만으로 돼있길래 똑같이 20억으로 맞췄구요.
C에서도 msec 단위로 출력하게 수정했습니다.

[c:\Speed] speed
15750
15046
15734
15016
15719
 
[c:\Speed] java -server Speed
Elapsed time:56907
Elapsed time:56906
Elapsed time:50609
Elapsed time:53532
Elapsed time:57703

여전히 3배 이상 차이납니다.
그리고 위에 C는 처음부터 0초 나온다는 거 진짜예요.
컴파일 타임에 계산이 다 끝나거든요.
narusas의 이미지

저는 Free로 구할수 있는 컴파일러인 Borland C/C++ Compiler 5.5.1, cywgin GCC 3.4.4, 로 테스트 해봤는데

자바 13초
Borland C Compiler 37초(-O3은 않먹길래 -02로 컴파일)
Cygwin GCC 26초 (-O3 옵션)

정도 나오더군요.

돈이 없다 보니 Free compiler밖에 못쓰는 지경이라...

어떤 환경에서 컴파일하셨는지 좀 알려주세요. 다른 사람 집에 가서 좀 해보게..

소타의 이미지

http://sota.nonun.com/moniwiki/wiki.php/tmp?action=recall&rev=1.84

위 코드에 오류가 있는것 같은데요. C는 2000000000번 돌고 자바는 20000000번 돌게 되어 있어서 둘 다 2000000000번 돌게 맞추고 테스트 했습니다
좀 더 다양한 환경에서 해보면 좋을텐데 서비스에 들어가 있는 서버들의 jdk버전은 건드리기 겁나서요..
사내 테스트 서버로 이시간에는 로드가 0 인 서버입니다

위 링크대로 테스트 했고 결과만 아래에 적어놓겠습니다

root@linux:/home/nonun/test# javac Speed.java ; java -server Speed
Elapsed time:54747
Elapsed time:55978
Elapsed time:47449
Elapsed time:48084
Elapsed time:48213
root@linux:/home/nonun/test# gcc test.c -O3 ; ./a.out
6.594091
8.330031
6.278779
8.565731
6.292024
root@linux:/home/nonun/test#

dormael의 이미지

당연히 C가 빠르게 나오는건 당연하지만 java소스와 C소스를 비교할때 java소스에 오버헤드가 좀 있을것 같아서 바꿔 봤습니다.
우선 java에서 long type의 경우 8바이트인데 현재 로직에서 보면 Integer.MAX_VALUE 값을 초과하지 않는것 같아서 int type 으로 바꿨습니다.
sum의 경우도 제가 돌려본 환경에서는 sizeof(long)이 4바이트라 그냥 int로 바꿨습니다.

혹시라도 64비트 환경이라면 다르게 생각해야 할수도 있겠네요.

제가 한 결과는 대충 자바는 20초대(JDK1.4), C는 13-14초대(gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4))로 나왔습니다.

다른분들도 혹시 제 소스에 C언어와 비교해서 문제가 될 부분이 있으면 알려주세요.

c1, c2의 타입이 자바쪽이 boolean인게 좀 걸리긴 하는데 제가 기억하기로는 내부적으로 int와 같은걸로 알고 있습니다.

좀더 정확한 테스트 결과가 궁금하네요.
사실 몇몇 서비스 중인 프로세스가 돌고있는 서버에 몰래 들어가서 한거라 완전 다른 결과가 나올수도 있거든요.
올려주신 환경과 컴파일러, 런타임이 다르기도 하구요.

^^

소스는 첨부했습니다.

---

처음에 올린 소스가 c와 달리 c1,c2,sum이 메소드내 로컬 변수로 선언되어 있어서 글로벌로 뺀 소스를 다시 첨부합니다.
이렇게 하니 자바에서 30초 정도 나오네요.

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

소타의 이미지

동일한 환경이구요~

root@linux:/home/nonun/test# javac Speed.java ; java -server Speed
1=2000000000
1=2147483647
Elapsed time:45592
Elapsed time:45182
Elapsed time:45152
Elapsed time:45421
Elapsed time:45600

수치가 안정적(?)이고 약간 빨라졌네요 ㅎ
뛰어드셨군요 ㅋㅋ
전 어제오늘 제 생애 두번째 자바프로젝트를 마쳤습니다 -.-;;
아놔 자바 어려워요 ㅠㅠ 누가 쉽데요
dormael의 이미지

혹시 둘다 sum, c1, c2를 스택(?)을 이용하도록 main함수내의 로컬 변수로 옮기고 테스트 해봐 주실 수 있을까요?

제가 테스트(gcc3대)한 경우에도 test.c를 main함수로 옮겼을때 5초 정도로 매우 단축된 결과를 얻을 수 있었거든요.

혹시, gcc4의 경우 이런 최적화가 된건지 아니면 컴파일러가 gcc3에 비해 비약적으로 성능이 좋아지는 코드를 만들어 낸건지 궁금하네요.
자바의 경우도 static을 빼고 main함수내의 로컬 변수로 옮겼을때 30초대에서 15초대로 빨라졌거든요.

사실 자바가 느린게 당연하고 위의 소스의 경우엔 더 확실하게 결과가 나올거라고 예상은 했지만 소타님의 결과가 제 예상보다 차이가 훨씬 커서 결국 이 글타래에 말려들고 말았네요. ㅋㅋ
소타님 결과에 상처받았어요. 흑.

아 그리고 여담으로 자바도 쉽지 않습니다. ㅋㅋ
저도 거의 7년정도 자바로 개발하고 있는데 아는거보다 모르는게 더 많습니다.
물론 제 개인적인 생각(핑계?)으로는 좋지 않은(우리나라에서 개발하면 다 비슷할거라 생각합니다) 환경에서 7년을 해왔기 때문에 기간에 비해 스킬이 많이 부족할 거라고 봅니다. 개인적으로 부족한 부분도 많을테구요.
역시 모든 툴은 익숙하다=쉽다 라는게 거의 적용되지 않을까 싶네요.
c도 항상 제대로 공부해 보고 싶은 생각이 들지만 아직 자바도 이것밖에 못하는 상황에서 두가지를 하려고 했을때의 부작용을 고려해 참고 있습니다.

게다가 복잡한 기능을 하는 소프트웨어를 여럿이서 개발하게 된다면 다른 여러가지 요소들도 좋은 결과물이 나오기 어렵게 만들기도 하구요.
제가 원래 성격이 그래서 그런건지 세상은 참 복잡하고 이해하기도 쉽지 않네요.
공부 많이 해야겠다는 생각이 항상 듭니다.

언제 '미유'공부 한번 같이 하실까요? ^^

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

소타의 이미지

public static void main(String[] args) {
	boolean c1 = true, c2=true;
	int sum =0;
 
        long start, end;
	int i, j, k;
...
 
 
root@linux:/home/nonun/test# javac Speed.java ; java -server Speed
1=2000000000
1=2147483647
Elapsed time:28015
Elapsed time:29685
Elapsed time:28141
Elapsed time:29232
Elapsed time:28149

빨라졌네요 희한하네연~ ㅋㅋ 클래스 멤버에 접근하는건 뭔가 더 체크하나 보네요
C는 테스트 안했습니다 ㅋ;

미유 가 머에여? 여잔데.. 동급생2 여자 말씀하시는거에요? ㅋㅋ

dormael의 이미지

소타님이 알고계신 동급생2의 미유와 제가 알고있는 일본 av배우 미유.. ㅋㅋ

제 생각이지만 보통 자바든 c든 함수내의 로컬변수(아마도 스택에 자리잡게 될듯)에 대한 접근이 글로벌(보통 힙이나 코드 영역)한 곳에 존재하는 변수에 대한 접근보다 더 빠르다고 알고 있습니다. 이유는 접근방식(스택과 힙) 혹은 구조? 때문이라고 알고 있습니다.

정규교육을 통해 알고 있는것도 적고(전공이 아니고 곁다리로 배웠습니다.) 또 여러 상황들이 많이 바뀌었을 가능성과 다양성들이 있기 때문에 정확하지 않은 생각일 수도 있습니다.

지금 예측하기로 gcc4에서는 글로벌한 영역의 변수도 최적화시에 상황을 봐서 이런 기능을 할수도 있다고 생각되어서 c에 대한 테스트도 부탁드렸던 겁니다. gcc3에서는 변수의 위치에 따라서 큰 차이가 났었거든요.

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

소타의 이미지

root@linux:/home/nonun/test# gcc test.c -O3 ; ./a.out
6.725809
4.645465
6.645556
6.657618
4.694392

요래 나오네요~ ㅎㅎ
dormael의 이미지

4초대가 두번이나 나왔네요.

6초대가 나올거라 예상했는데 조금 다른 결과도 있군요.
제가 알고있는 영역 밖의 일이거나 일반적으로 인지하지 못하는 환경의 차이일수도 있을듯 합니다.

그래도 gcc3에서의 차이보다는 많이 적은걸로 보아 제가 생각하는 최적화 방법이 아닐까 조심스럽게 생각해 봅니다.
참고로 제가 테스트한 gcc3에서는 함수밖에서 15초대, 안에서 5초대가 나왔었습니다.

이런 최적화는 자바의 특성상 거의 불가능한 것이죠. 코드를 그렇게 작성하기 전에는요.

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

익명사용자의 이미지

좀더 현실적으로.. C의 명시적인 포인터에의한 메모리 관리와 Java의 GC에 의한 메모리 관리
를 비교.. 추가적으로 C와 Java의 function call에 대한 overhead 역시 포함되어 짐.

Java
-----------------------------------------------------
public class Speed3
{
public static void main(String[] args)
{
long start = System.currentTimeMillis();

for(int i = 0; i<1000000; i++)
test();

System.out.println(System.currentTimeMillis() - start);
}

private static void test()
{
for(int i = 0; i<1000; i++)
{
Integer a = new Integer(0);
}
}
}

C
-----------------------------------------------------
#include
#include
#include

long sum = 0;
int c1 = 1, c2=1;

void test()
{
int i;
for(i=0; i<1000;i++)
{
int *j = (int*)malloc(sizeof(int));
*j = 0;
free(j);
}
}

int main(int argc, char *argv[])
{
time_t start;
time_t end;
time_t elapsed;

int i;
start = time (NULL);

for(i=0; i< 1000000;i++)
{
test();
}

end = time (NULL);
elapsed = end - start;

printf( "time %d\n", elapsed );
getchar();
return(0);
}

-----------------------------------------------------------------
WINXP / VC++ on VS 2003 vs. JDK 1.6

Java : 7.39s
C : 974s

-----------------------------------------------------------------
Solaris / gcc 2.95.4 vs JDK 1.4
Java : 79.901s
C : 209s

익명사용자의 이미지

좀더 현실적으로.. C의 명시적인 포인터에의한 메모리 관리와 Java의 GC에 의한 메모리 관리
를 비교.. 추가적으로 C와 Java의 function call에 대한 overhead 역시 포함되어 짐.

public class Speed3
{
public static void main(String[] args)
{
long start = System.currentTimeMillis();

for(int i = 0; i<1000000; i++)
test();

System.out.println(System.currentTimeMillis() - start);
}

private static void test()
{
for(int i = 0; i<1000; i++)
{
Integer a = new Integer(0);
}
}
}

---------------------------------------------------------------
#include
#include
#include

long sum = 0;
int c1 = 1, c2=1;

void test()
{
int i;
for(i=0; i<1000;i++)
{
int *j = (int*)malloc(sizeof(int));
*j = 0;
free(j);
}
}

int main(int argc, char *argv[])
{
time_t start;
time_t end;
time_t elapsed;

int i;
start = time (NULL);

for(i=0; i< 1000000;i++)
{
test();
}

end = time (NULL);
elapsed = end - start;

printf( "time %d\n", elapsed );
getchar();
return(0);
}
-----------------------------------------------

WINXP / JAVA 1.6 vs VC++ on VS 2003

Java : 7.9s
C : 약 15분-_-

Solaris / Java 1.4.1 vs gcc 2.95.3

Java : 79.9s
C : 209s

익명사용자의 이미지

public class Speed3
{
public static void main(String[] args)
{
long start = System.currentTimeMillis();

for(int i = 0; i<1000000; i++)
test();

System.out.println(System.currentTimeMillis() - start);
}

private static void test()
{
for(int i = 0; i<1000; i++)
{
Integer a = new Integer(0);
}
}
}

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

#include
#include
#include

long sum = 0;
int c1 = 1, c2=1;

void test()
{
int i;
for(i=0; i<1000;i++)
{
int *j = (int*)malloc(sizeof(int));
*j = 0;
free(j);
}
}

int main(int argc, char *argv[])
{
time_t start;
time_t end;
time_t elapsed;

int i;
start = time (NULL);

for(i=0; i< 1000000;i++)
{
test();
}

end = time (NULL);
elapsed = end - start;

printf( "time %d\n", elapsed );
getchar();
return(0);
}

익명사용자의 이미지

public class Speed3
{
public static void main(String[] args)
{
long start = System.currentTimeMillis();

for(int i = 0; i<1000000; i++)
test();

System.out.println(System.currentTimeMillis() - start);
}

private static void test()
{
for(int i = 0; i<1000; i++)
{
Integer a = new Integer(0);
}
}
}
////////////////////////////////////////////////////////////////////////
#include
#include
#include

long sum = 0;
int c1 = 1, c2=1;

void test()
{
int i;
for(i=0; i<1000;i++)
{
int *j = (int*)malloc(sizeof(int));
*j = 0;
free(j);
}
}

int main(int argc, char *argv[])
{
time_t start;
time_t end;
time_t elapsed;

int i;
start = time (NULL);

for(i=0; i< 1000000;i++)
{
test();
}

end = time (NULL);
elapsed = end - start;

printf( "time %d\n", elapsed );
getchar();
return(0);
}

.............................................

narusas의 이미지

code 태그로 소스를 감싸시면 됩니다.

익명사용자의 이미지

님도 컴파일옵션주시고 재대로 돌려보세요..

익명사용자의 이미지

자바와 C 벤치마크한 것중 하나입니다.

결과 : http://www.ddj.com/184401976
소스코드 : http://www.tommti-systems.com/mainDateien/reviews/languages/bench.zip

옵션 : http://www.ddj.com/dept/cpp/184401976?pgno=20

여기 결론은...
자바가 빠른 부분도 있다...

익명사용자의 이미지

*******************results (-9223222076133905159)**********************
Int arithmetic elapsed time: 1500 ms
Double arithmetic elapsed time: 878 ms
Long arithmetic elapsed time: 4574 ms
Trig elapsed time: 4455 ms
IO elapsed time: 41 ms
Array elapsed time: 33 ms
Exception elapsed time: 893 ms
HashMap elapsed time: 679 ms
HashMaps elapsed time: 603 ms
HeapSort elapsed time: 70 ms
List elapsed time: 343 ms
Matrix Multiply elapsed time: 921 ms
Nested Loop elapsed time: 89 ms
String Concat. (fixed) elapsed time: 69 ms
String Concat. (dynamic) elapsed time: 296 ms
Object Creation / Methode Call elapsed time: 95 ms

*********************************************
Average Java benchmark time: 15539 ms

*******************results (-9223222076133905159)**********************
Int arithmetic elapsed time: 1260 ms
Double arithmetic elapsed time: 860 ms
Long arithmetic elapsed time: 3760 ms
Trig elapsed time: 610 ms
IO elapsed time: 88 ms
Array elapsed time: 30 ms
Exception elapsed time: 1468 ms
HashMap elapsed time: 854 ms
HashMaps elapsed time: 753 ms
HeapSort elapsed time: 38 ms
List elapsed time: 241 ms
Matrix Multiply elapsed time: 616 ms
Nested Loop elapsed time: 9 ms
String Concat. (fixed) elapsed time: 162 ms
String Concat. (dynamic) elapsed time: 232 ms
Object Creation / Methode Call elapsed time: 203 ms
*********************************************
Average C++ benchmark time: 11184 ms

옵션은
$g++ -O3 -march=pentium4 -msse -msse2 -mfpmath=sse Benchmark.cpp
$./a.out

$javac Benchmark.java
$java -server Benchmark

익명사용자의 이미지

이런식의 벤치마킹은 항상...

일단 여러가지 테스트를 한거 같은데요..
소스를 다볼순 없고. 맨마지막
Object Creation / Methode Call elapsed time: 203 ms
이부분이 두배이상으로 차이가 크니 이부분만 말씀드리겠습니다.

일단 결과나 눈에보이는것만보지마시고 항상 소스를 면밀히 검토해보시기 바랍니다.
일단 소스를 열어보시면..

자바는 대충 이렇고..
tmp.doSomething(i, i, i, i, i, i);
tmp.doSomething(i, i, i, i, i, i);

C++ 은
tmp->doSomething(i, i, i, i, i, i);
tmp->doSomething(i, i, i, i, i, i);
이러한식으로 포인터 계산이 들어갔습니다.
테스트명도 메스드콜 이듯이 메소드콜이 주테스트인 이것을 저런식으로 하면
당연히 포인터 계산이 들어간것이 엄청불리하지요.
말해야무엇하겠습니까. C에서 포인터로 -> 이것은 결국 주소번지 계산하여 다시 점프하는과정을 거칩니다.
당연히 C++도 tmp.doSomething(i, i, i, i, i, i); 형태로 할수 있음에도 궂이 저런식으로 한번더 부하를먹게 코딩해두고
이걸 벤치마킹이네.. 하면서 내놓으니참 어이가 없습니다..

다른것은 귀찮아 보지 않았으나 대부분이런식으로 사기성테스트를 해두니 뭐라 할말이 없습니다.

익명사용자의 이미지

자바 메소드 호출 구문

tmp.doSomething(i, i, i, i, i, i);
tmp.doSomething(i, i, i, i, i, i);

과 동일한 의미의 C++ 메소드 호출 구문은

tmp->doSomething(i, i, i, i, i, i);
tmp->doSomething(i, i, i, i, i, i);

입니다.

익명사용자의 이미지

님께서 생각하시는 정당한 방법으로 테스팅한 후 결과를 포스팅 바랍니다.

익명사용자의 이미지

무식한 정도가 도를 지나치셨습니다.

깔려면 기초나 제대로 알면서 까시죠.

youbit의 이미지

논의는 끝이군요. 결국 이제까지의 셀 수도 없는 자바의 성능 문제에 관한 프레임처럼
이 프레임도 배울 것 없이 끝나는가 봅니다. 자신이 아는 것에 대한 확신이 있으시다면
끝까지 냉정하고 논리적인 자세를 견지해주셨으면 합니다. 별 소득도 없이 편갈라서 싸우자고
여기 있는게 아니지 않습니까?

좀 뭔가 서로에게 이득이 되어서 매듭이 지어질 분위기로 흘러갈 수 있을까 싶었는데...
자바나 C언어의 문제가 아니라 결국 개발자의 문제였군요. 성능에 대한 진실도, 그에 따른 논의도
결국 언어가 문제가 있는게 아니라 개발자의 문제인 것 같습니다.

맞습니다. 자바가 C보다 몇 배에서 수십배는 느립니다. 근거나 자료는 필요없습니다. 그냥 그대로
멈추십시오.

그리고 저는 프로그래머에 따라 자바와 C언어의 성능 차이는 근소하게 좁혀질 수 있다는 의견을 바꿀만한
객관적인 근거를 보지 못했으므로 여기서 멈추겠습니다. 애시당초 서로 이해하려는 의지 자체가 없다면 그냥
여기서 관두도록 하는게 어떻습니까.

무슨 남북전쟁도 아니고, 종교전쟁도 아니고 서로를 이해하려는 노력도 용납될 수 없다니 서글프군요.
그깟 기계덩어리가, 전기신호의 집합따위가 사람에 비해서 뭐가 그렇게 중요한지 모르겠습니다.

익명사용자의 이미지

위에 글은 자바하시는분인듯합니다만..

youbit의 이미지

잘못 봤군요. 하지만 그게 중요한 건 아니지않습니까?
중요한 건 서로 공격하는 감정적인 글들은 아무것도 얻어내지 못한다는 것이니까요.

남은 기껏해서 구구절절히 설명해가며 얘기하고 있는데, 성의없는 몇 줄의 글로 몽땅
허탈하게 만드는 몇몇 익명사용자분들 때문에 솔직히 좀 지칩니다. 죄송합니다.

PS :
익명 사용자 분들은 왜 로그인 안하시는지 모르겠군요. '내가 누구다'라고 밝히는 것은 자신의 말에
스스로 책임을 지겠다는 말이고, 그게 틀렸다면 겸허히 그걸 인정하겠다는 의미입니다. 아이디가
없다고해도 가입하는데 5초도 안 걸립니다. 자신의 말에 떳떳하다면 자신을 밝히는데 꺼리낌이 있을 이유가 있습니까?

익명사용자의 이미지

생각이 다르다하여 비난하는이가 있을수 있기때문입니다.

youbit의 이미지

생각이 다른 사람하고 만나면 비판을 받을 수도 있겠지요. 비판은 오히려 배움에 도움이 됩니다.
그리고 아무런 쓸모도 없는 비난을 받을 때도 있겠지요. 하지만 그게 기분나쁘다고 자신의 생각을 말하지 못한다는 것은
비난받는 것보다 더 기분나쁜 일이 아닐런지요. '똥이 더러워서 피하지 무서워서 피하냐?'라지만 더럽다고 피하기만한다면
점점 걸어갈 수 있는 길이 줄어들 것 같습니다.

생각이 다르다며 비난하는 사람이 있다해도 당당하게 맞이하지 않으면 자신의 생각을 아무도 믿어주지 않지 않겠습니까?
제가 가장 무서워하는 것은 옳다고 말해야할 때 더러워지는 것, 아픈 것을 걱정해서 옳지않다고 말하게 되는 것입니다.
사소한 것이라고 그냥 피해가면 나중에 정말 사소하지 않은 일에서 당당해질 수 없을까 두렵습니다.

권순선의 이미지

이 글타래를 보고 저는 좀 다른 생각이 들었습니다.

우리나라에서 자바와 C의 논쟁 대신에 특정 오픈소스 application A와 다른 오픈소스 application B에 대해 이 글타래에서처럼 어느 것이 빠른지 논쟁이 붙습니다. 그래서 사용자들이 벤치마크도 해 보고 성능향상을 위해서 패치도 올리고 테스트도 하고 하면서 둘다 발전해 나가는 그런 글타래는 없을까요? 이 글타래를 보니 가능할 것 같기도 하네요. :-)

아무튼 재미있는 글타래입니다.

youbit의 이미지

좀 동떨어진 생각일지 모르겠지만 권순선님의 글을 읽다보니 문득 이런 생각이 들었습니다.
세상에 윈도우만 있었다면? 맥만 있었다면? 리눅스만 있었다면? C언어만 있었다면? 자바만 있었다면? '무엇'만 있었다면?
오픈소스 A와 B가 서로 경쟁하며 발전하듯 어떤 소프트웨어든... 아니 세상의 어떤 것이든 상대되는 것, 경쟁자가 있기에
발전하는게 아닐까... 하고요.

하긴, 까만색이 싫다고해서 온통 하얀색으로 세상을 도배해버리면 그 얼마나 정신병동같은 세상이 되겠습니까. ^^
권순선님의 말처럼 우리나라에도 그런 글타래가, 이왕이면 우리나라의 우수한 오픈소스 프로젝트 2개를 주제로 있었으면 좋겠습니다.
(우리나라에 그게 힘든 이유는... 상대적으로 더 먹고살기 힘들어서가 아닐까 싶습니다. 음... 좀 우울하군요. 경제가 발전해야할텐데...)

익명사용자의 이미지

이 논쟁을 보면서 C/C++ 이 빠른지 Java 가 빠른지는 서로의 주장이 엇갈려서 잘 모르겠읍니다.
그런데 요즘 프로젝트 예기를 들어보면 온통 JAVA 입니다.
C/C++ 로 진행되는 프로젝트는 아주 드물게 듣고 있읍니다.
이런 C/C++ 프로젝트에 참여하는 분들은 최하 몇 년씩의 상당한 실력자들 아니겠읍니까.
근데 자바는 국비 6 개월 과정이 있길래 몇 군대 전화해서 수료후 취업은 어떻게 되느냐고 물어 보니까
'거의 대부분 취업된다' 혹은 '없어서 못 내 보낸다' 라는 답변을 들었읍니다.
이것을 보면 신입일 경우에 Java 가 월등히 진입이 쉬운 것 같습니다.
C/C++ 을 6 개월 했다고 어느 프로젝트에 참여시킨다는 얘기를 못들은 것 같습니다.
그래서 저는 이렇게 생각합니다.

"초/중급자에게는 Java 가 C/C++ 보다 단연 밥먹고 살기 좋다."

틈틈이 C/C++ 을 봐왔었는데, 이 보다는 Java 를
이런 국비학원에서 배워서 수료후 취업할까 궁리하다가 생각을 정리해 봤습니다.
정말 C/C++ 은 저같이 어중간한 사람한테는 어디다 활용해야 돈이 될지 감을 못잡겠더라구요.
위의 "Java 가 밥먹고 살기 좋다" 는 제 생각이 (물론 초/중급자에게는 큰 돈은 안되겠지만)
틀리진 않겠지요.

익명사용자의 이미지

이쓰레드에 테스트된 성능비교는 결국 둘다 최신컴파일러및vm 일때 자바가 C의 2~3배정도 성능이떨어졌습니다.
물론 실제로 더차이나는것도 있을것이고 덜차이나는것도 있겠지요..

자바로 개발하면 쉽다 개발기간이 단축된다 라는말은..근거를 찾지 못하겠습니다.
즉, 이말이 숙련자에게 해당하는말인지 초보자에게 해당하는말인지..에따라 다르다는것이죠..

다만 님말씀대로 신입이 자바를하면 바로 써먹을수 있다는건 맞습니다.
몇년전 IT전체가 어려워지면서 최근부족해졌거든요..
C/C++도 2000년도경엔 신입들도 다 취직되었습니다. 다른언어에비해 대우도 좋았죠..
자바가 현재 그현상이 있다는거죠..
그러나 그리좋아할일만은 아닙니다. 그렇다는건 곧 사람들이 몰리게 되고..
결국남아돌게되면 다시 칼바람이 불죠..

익명사용자의 이미지

'개발속도'를 좌우하는 여러 요인들을 나열해봅시다.

1. 언어의표현력.

2. 언어를지원하는플렛폼.

3. 개발툴, IDE지원여부.

4. 기반라이브러리.

5. 문서지원.

6. 언어의학습곡선. 숙련도.

7. 유지보수용이성.

8. 배치신속도.

...

머 여러가지가 더 있겟지만...

이중에 Java보다 C가 나은 항목이 있음 하나라도 말해보시길...

자기가 C밖에 모르니까 C면 다되는 세상이길 바라겠지만.

왜 대부분의 대형프로젝트에서 Java를 사용하는지 생각한번 안해봤소?

정신좀 차리시구랴 ㅎㅎ

익명사용자의 이미지

너무 어거지세요..

1. 언어의표현력.
솔직히 C/C++가 간결하고 낮죠

2. 언어를지원하는플렛폼.
C/C++가 더많죠

3. 개발툴, IDE지원여부.
이것도 C/C++가 더많죠..
또한 없어도 크게 영향받지 않고도 할수있으니 더좋구요.

4. 기반라이브러리.
C/C++이 더많음은 물론이죠.. 공개소스도 비교도 안되고.

5. 문서지원.
물론 C/C++ 더많음은 두말할것도 없죠.

6. 언어의학습곡선. 숙련도.
자바는 일정수준에서 정채되는현상이 있지만 C/C++은 계속 깊어지는건 당연하죠.

7. 유지보수용이성.
여기쓰레드에서도 많이 나왔듯이 자바가 나을건하나도 없습니다.
오히려 소스의 간결함으로인해 C/C++가 낫다봐야죠..

8. 배치신속도.
속도가 C/C++이훨씬빠름은 두말할것도 없죠.

대부분의 대형프로젝트에서 자바를사용하는게 아니라.
우리나라에서 대기업들 프로젝트라해봐야 홈페이지 주로 많이 만들구요.
그외에 자바 잘 안사용하죠..
전체로따져봐도.. 자바보다 C/C++이훨씬 프로젝트 많습니다.
왜자꾸 어거지 우기는지 이해하기 힘들군요..

개발속도란 초보들만 데리고 속도측정하는게 개발속도도 아니고.
또한 초보라하더라도 자바로 하면되는것이 그소스 거의 흡사하게 C로 해도 거의 비슷하게 다되는데
오히려 C로되는것이 자바로는 안되는게 많은데 어찌 자바가 쉽다는건지 참 이해못할 일이네요..
자바만알고 자바진영에서 하는말만들으니 마치그게 다인양 생각하시면 곤란합니다.

익명사용자의 이미지

(1. 언어의표현력.) C++ 은 모르되 C 는 자바보다 떨어집니다.
(2. 언어를지원하는플렛폼) 는 님이 맞습니다.

나머지에 대해서는 sourceforge/freshmeat 에서 언어별로 프로젝트 순위를 찾아보세요. 그중에서 실제로 파일을 릴리즈하고 살아있는 프로젝트의 수를 또 따져보세요. 님이 얼마나 말도 안되는 소리를 하고 계신지 알게 될겁니다.

익명사용자의 이미지

-- 다만 님말씀대로 신입이 자바를하면 바로 써먹을수 있다는건 맞습니다.

자바로 말을 갈아타려는 저에게 도움이 되는 내용이었읍니다.

-- 몇년전 IT전체가 어려워지면서 최근부족해졌거든요..
-- C/C++도 2000년도경엔 신입들도 다 취직되었습니다. 다른언어에비해 대우도 좋았죠..
-- 자바가 현재 그현상이 있다는거죠..
-- 그러나 그리좋아할일만은 아닙니다. 그렇다는건 곧 사람들이 몰리게 되고..
-- 결국남아돌게되면 다시 칼바람이 불죠..

근데 자바는 쇠퇴하거나 수그러들지는 않을 것 같습니다.
선이 강력하게 밀고 수많은 플랫폼들로 중무장해 있는데 과연 '칼바람이 불지는' 잘 모르겠읍니다.

-- 전체로따져봐도.. 자바보다 C/C++이훨씬 프로젝트 많습니다.

어 정말이예요. 저는 온통 Java 외에는 잘 보이지도 않던데
이랜서 같은 사이트는 봐도 프로젝트는 거의 Java 지 C/C++ 은 아주 극소수더라구요.

정말 C/C++ 프로젝트가 많다면 실제로 어떤 프로젝트인지 예를 들어주실 수는 없을까요.

익명사용자의 이미지

어느쪽이 많은지는 통계가 없어서 알수 없지만
웹사용자 접근성이 필요 없는 프로젝트에는 상당수가 C/C++입니다.
그리고 외주 안주죠.

익명사용자의 이미지

재밌게 잘 봤네요...
뭐..저는 자바랑 C/C++이랑 둘다 하는 사람인데...
나름대로의 장단점이 있는것 같고..
뭐..자바가 8배...이렇게 느릴것 같진 않아요..
뭐...c는 어셈블리와 1:1대칭이 되고 바로 돌아가니깐..
컴파일 옵션 다 신경 안쓰고..생각했을때..
좀더 빠를테고...
자바는 버츄얼머신을 거쳐서 조금 느려지겠지요..
(아무리 컴파일 옵션을 켜도 필요한 명령은 다 들어가야 한다는 전제하구요..)

뭐...그정도 결론이면 충분한거 아닐까요???
같은거면 c가 빠를테고....
메모리 할당, I/O요청, 개발시간...
나름대로 장단점이 있다고 보이네요...

그냥 C는 C고..자바는 자바라고 하는게 가장 좋을것 같고..
자바분들도 C의 최 강점으로 치는 속도라는 부분을 건드리면
C프로그래머는 싫어해요..

그리고 C프로그래머 여러분은 JAVA의 잘 만들어진 API를 무시하면
싫어하구요..

이제 이정도면 충분한 논쟁이 된것 같은데요..^^;;

익명사용자의 이미지

-- 그냥 C는 C고..자바는 자바라고 하는게 가장 좋을것 같고..
-- 자바분들도 C의 최 강점으로 치는 속도라는 부분을 건드리면
-- C프로그래머는 싫어해요..

-- 그리고 C프로그래머 여러분은 JAVA의 잘 만들어진 API를 무시하면
-- 싫어하구요..

그렇기는 합니다만 C 에 대해서 한 가지 의문을 달자면
C/C++ 로도 얼마든지 안정적인 프로그램을 만들 수 있다고 생각하지만
왜 Window 시리즈는 그리도 버그가 많고 무거운지...
Window NT 계열만 해도 window2000 이 나올 때까지 무지하게 깨졌지 않습니까.
또 Window95,98 은 어떻습니까. 또 윈도우가 버전업 될 때마다
컴의 사양은 왜 자꾸만 하늘을 찌르죠.
빌게이츠가 윈도우를 만들 때 틀림없이 전문가들을 썻을 텐데
이 전문가들이 설마 C/C++ 를 잘 몰랐겠읍니까.
아니면 납기일에 쫓겼었나요.

Window 만으로 비교해서 좀 그렇지만
아무래도 Java 가 프로그램제작에는 더 안전하다고 말할 수 있지 않을까요.

나중에 개발자로 먹고 살을려고 그동안 C/C++ 을 독학했었는데
어중강한 실력으로는 쓸 데가 없어서 너무 허망한 생각에 제 생각을 끄젹여 보앗읍니다.

익명사용자의 이미지

일단 자바로는 M$윈도우도같은거 아예 만들지도 못하죠?
비슷한거라도 만든거 있으면좀알려주시죠..
자바가 다되느니 머니해도 실제로 해놓은거 머있나요?
대부분 홈페이지 같은거 밖에 더만드나요?
스크립트수준으로 만들수 있는프로그램만 만드는데 안전하지 않으면그게 더이상한거죠..
그리고 M$윈도우 님이 생각하는것처럼 간단한프로그램은 아닙니다. 매우 복잡하죠...
M$윈도우에 담긴철학이 개인적으로 별로 맘에 안들지만.. 그것때문에 오류가 많은것같군요..
유닉스나 리눅스를 보시죠.. C로만들어졌는데 얼마나 안정적입니까.
자바를보면 운영체로비유하자면 M$윈도우쪽을 매우닮았습니다.
속도나 성능을봐도 그렇고 주로 내세우는것도 그렇고..
실제보다는 항상 말이나 광고로 모든걸 해결하려는것도 그렇고..
자신들의 운영체를 한회사가 비공개로 독점적으로 가져가는것도그렇고..
그럴수밖에 없으며 그렇게할수밖에 없다는것도 이해합니다.
그렇게라도 하기때문에 그런운영체나 언어도 살아남을수있게되죠..

익명사용자의 이미지

좀덧붙이자면 어중간한 실력으로 써먹으면..

다른사람은어쩌라는건가요? 어중간한사람이 남고 기존 실력자는 밀려나야하는건가요?

아니면 자신의실력이 어떠한곳에 쓰일수 있을정도로 발전해서 쓰이는게 맞나요?

아니면 회사가 어중간하던 실력자든 모두다 사용해야하는건가요?

자신이 이분야에 그저 스처지나가는생각이 아니라면.. 자신의 실력을 키우려하세요.

아니면 좀 개발이 쉬운것부터 프로젝트 하시던가..

일분일초의 이미지

그 글이랑 별로 차이가 없는 수준의 글들 같네요...이거

kanie의 이미지

KLDP도 참 유치하군요. 예전부터 이랬나요?

익명사용자의 이미지

-- 자바가 다되느니 머니해도 실제로 해놓은거 머있나요?
-- 대부분 홈페이지 같은거 밖에 더만드나요?
...
-- M$윈도우에 담긴철학이 개인적으로 별로 맘에 안들지만.. 그것때문에 오류가 많은것같군요..
-- 유닉스나 리눅스를 보시죠.. C로만들어졌는데 얼마나 안정적입니까.

결국 철학의 차이였나요. 윈도우가 유닉스나 리눅스가 철학이 모질라서 오류가 많고 무거운 거로군요.
결국 오류가 없을려면 철학이 있어야 되는 거였네요.

-- 좀덧붙이자면 어중간한 실력으로 써먹으면..
-- 다른사람은어쩌라는건가요? 어중간한사람이 남고 기존 실력자는 밀려나야하는건가요?
-- 아니면 자신의실력이 어떠한곳에 쓰일수 있을정도로 발전해서 쓰이는게 맞나요?
-- 아니면 회사가 어중간하던 실력자든 모두다 사용해야하는건가요?
-- 자신이 이분야에 그저 스처지나가는생각이 아니라면.. 자신의 실력을 키우려하세요.
-- 아니면 좀 개발이 쉬운것부터 프로젝트 하시던가..

C/C++ 쪽은 쉬운 프로젝트라도 없더라구요. 자바는 6 개월 국비학원 나와도 일 할 수 있는데...
그래서 C/C++ 쪽 진입장벽이 높다는 푸념을 했었는데 그것을 아주 아니꼽게 보셨네요
실력도 쥐뿔도 없는게, 지 못난 생각도 안하고, 실력을 키울 생각도 하지 않는다고...
그러니 님은 전문가라 버그 있는 프로그램은 만들지도 않으며 윈도우가 갖지 못한 철학까지 갖고 있는
대단한 분이라는 거죠. 저는 그렇게 자신 있어 하는 님을 믿습니다. 님같은 철학자가 이나라에 있는 것을 참 다행으로 생각하며 저같은 어중간한 놈이 감히 C/C++ 이 어떻네 캉캉 짖어대는 일은 없을 것입니다.
C/C++ 을 때려치기로 작정한게 역시 잘했다는 생각이 듭니다.
역시 저같은 무철학 인간한테는, 님같은 전문가만이 쓸 수 있는 C/C++ 은 전혀 어울리자 않으며
그보다 못한 사람들이나 쓰는 자바가 어울릿 것 같습니다. 자바도 님과 같은 특권층만 쓰는 것이라면
뭐 그땐 자바스크립트나 해야 겠지요.

역시 송충이는 솔잎을 먹는제 맞습니다.

좋은 지적 감사합니다.

익명사용자의 이미지

맞아요.. 잘생각하신거에요..
물흐려놓는다는말도 있자나요..ㅎㅎ

말을 굉장히 고깝게 들으신거 같은데
그리 감정적으로 들으실필요는 없어요.
전문가만이 쓴다한적도 없고 특권층만이 쓴다라고 한적도 없는데 님이 그렇게 오독한거죠.

저는 정당한 경쟁에서 살아남아야한다라고 말한것뿐이에요..
실력이아닌 다른것으로 주변사람을 밀어내서는 안된다는말이죠..

나도좀껴주면 안되겠니? 라고 묻고 싶겠지만 당신을 껴주기위해 누군가는 빠져야하죠.
그럼 누가빠져야할지는 답이나오죠?
자바하신다는데.. 자바는 어중간한실력으로도 기존사람 밀어낼수 있나보죠? 님말발이 좋으신가봐요.
아니면 자바는 다어중간한사람들이란뜻인가요?

ydhoney의 이미지

이 정도 길게 말씀하셨으면 다들 어느정도 의견 정리가 되셨겠지요?

자..결론이 뭔가요? =_= (이렇게 다시 불타오른다 ㅡoㅡ)

==
아 씨끄러 씨끄러~ 조용해!!
레드햇 9 이하 사용금지!

익명사용자의 이미지

-- 맞아요.. 잘생각하신거에요..
-- 물흐려놓는다는말도 있자나요..ㅎㅎ

오 이런 어물전 망신은 꼴뚜기가 시킨다더니 제가 그럴 뻔 한 거군요
님이 없었으면 저는 평생 모를 뻔 했네요.

-- 말을 굉장히 고깝게 들으신거 같은데
-- 그리 감정적으로 들으실필요는 없어요.

감정적으로 듣긴요 님은 저의 선생님입니다.

-- 전문가만이 쓴다한적도 없고 특권층만이 쓴다라고 한적도 없는데 님이 그렇게 오독한거죠.

왜 특권층에 있는 것을 거부하시는지
특권층에 있다는 것은 님의 능력이 그 정도 된다는 것을 보여주는 것이지 전혀 죄가 아닙니다.
이 세상에 인간은 평등하다는 말도 새빨간 거짓말 중의 하나라고 생각합니다.

-- 저는 정당한 경쟁에서 살아남아야한다라고 말한것뿐이에요..
-- 실력이아닌 다른것으로 주변사람을 밀어내서는 안된다는말이죠..
--
-- 나도좀껴주면 안되겠니? 라고 묻고 싶겠지만 당신을 껴주기위해 누군가는 빠져야하죠.
-- 그럼 누가빠져야할지는 답이나오죠?

그러니까 당신은 누군가를 실력으로 밀어내고 오늘의 위치에 오른거로군요.
그런데 당신이 밀어낸 사람도 누군가를 실력으로 밀어내고 그 자리에 올랐다가
무엇때문인지 다시 당신한테 밀렸단 말이예요.
아마 공부를 할때 누구를 밀어낼지 미리 정하고, 상대의 허술한 점을 많이 연구를 하셨나 보네요.
아님 무슨 고시공부를 하셨나요. 그도 아니면 산속에서 도를 딲았나요.
윈도우가 철학이 없어서 버그가 많다고 하는 것을 보면 서양에서 도를 딱은 분인 것 같기도 하고...

-- 자바하신다는데.. 자바는 어중간한실력으로도 기존사람 밀어낼수 있나보죠?
-- 님말발이 좋으신가봐요. 아니면 자바는 다어중간한사람들이란뜻인가요?

누구를 밀어낸다고 한 적 없는데...
아니면 자바도 주제에 맞지 않으니 넘보지 말라는 뜻인 것 같습니다.
전문가가 판단한 것이니 맞을 겁니다.

님한테 다시 한 번 감사를 드립니다.
님의 충고가 있어서 이제야 비로소 제 주제를 알게 되었읍니다.

언제 한 번 술 한잔 하면서 님의 철학을 들을 기회가 있으면 좋겠읍니다.

몽룡의 이미지

자바가 느리다는 것은 동작을 하는 속도보다는 Java VM이 뜨는 속도가 더 크게 좌우하지 않나 생각합니다.
물론 자바를 사용할 경우, 대부분의 개발자가 라이브러리를 사용하게 되고,
그 라이브러리라는 것이 범용성을 지향하는 것이기 때문에 최적화 보다는 사용성에 중점을 두고 있기 때문에 기능면에서 떨어지기도 하지요. 프로그램의 효율성과 재사용성간의 문제겠지요.
여하튼.. 풀링등을 사용한다거나, WAS 등을 띄워 EJB를 사용하는 등, VM에 탑재되는 시간을 제한다면 그닥 속도차는 나지 않습니다.

cronex의 이미지

개인적으로는 언어가지고 이게 좋다 저게 좋다 하는 사람 치고
그 언어 가지고 제대로 하는 사람은 못본거 같습니다만... -_-

정말 잘하는 사람은 이걸 쥐어주던 저걸 쥐어주던 다 잘하더군요 -_-
그런 사람을 볼때마다 한없이 작아지는 저 자신을 발견하곤 합니다. orz

그리고 그 잘 하는 사람은 자기가 지금 쓰고 있는 언어의 장점을 잘 알고 쓰기도 합니다만.
단점을 더 잘 파악해서 그 단점이 드러나지 않도록 쓰더군요.

각기 자신이 자주 쓰는 언어의 단점에 대해서 얼마나 잘 알고 있으신지요?

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

익명사용자의 이미지

그러니까 X도 모르는 것들이 떠드니 눈꼴시다 그말이요?
할말 없으면 가만 있으면 되지 왜 남들 얘기하는데 와서 하나마나한 소리를 합니까?

cronex의 이미지

모두들 자기가 좋아하는 언어의 장점만 가지고 말씀하시는데....
그전에 그 언어의 단점에 대한 걸 알고 계시는지 그게 궁금해서 말이죠.
세상에 완벽한 것이라는 것은 존재할 수 없는 것이니 어느 프로그래밍 언어던지
장점과 단점을 가지고 있을겁니다.
이 언어는 저 언어보다 이런면에서 나쁘다.그러니 이 언어를 써라.... 라고 하는 것보다는
저 언어에 비해서 이 언어의 단점은 이런게 있는데 나는 이걸 이렇게 보완해서 쓰니 좋더라...
이런 내용이 훨씬 건설적이고 도움이 되는 토론이 될거 같은데요.
그렇게 생각되지 않으신가요?

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

sbkim2의 이미지

김혜수가 고소영보다 훨씬 이뻐. 하는 말이랑 뭐가 다를까요?
어셈블리 언어가 아닌 이상에는, 대부분 비슷비슷할겁니다.
하지만 자바가 아무리 빠르다고 해도 그건 컴퓨터가 너무너무 빨라져서 그런것이지, CPU에 최적화되어서 컴파일/링크된 C++을 따라갈수는 없겠지요.

appler의 이미지

덩치가 크다 이런건 의미가 없을듯....

역시나 뼛속 까지 스며든 노하우는

속도를 극복하는군요.

저는 지금 궁금증이라는 불치병에 걸렸어요.

- guru 는 나의 꿈


laziness, impatience, hubris

不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.

익명 사용자의 이미지

이 글이 왜 올라와있는지 모르겠는데..
요즘 기준으론 일반적인 용도론 그렇게 격차가 심하진 않습니다. 물론 경우에 따르고 포인터등이 중요한 작업이라면 여전히 꽤 밀립니다만..

페이지

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.