누가 자바를 느리다고 했나?

C 코드 역시 속도면에서 컴파일러에 의존적인 부분이 있는게 아닌지.. C코드를 그 칩셋에서 최적의 성능을 발휘하는 컴파일러로 컴파일을 했다면.. 결과는 다르지 않았을까요. (또한 동일한 코드로 비교를 했다면 약간의 억지가 있지 않나.. 라는 생각을 합니다.)

코더의 능력과 컴파일러에 의존적이지만 특정플랫폼에서 최적의 속도를 내는 결과물을 낼 수 있는 언어는 단연 C 라고 생각합니다.

아닌것은 아닌것이다.

아닌것을 맞다고 우겨도 맞을수 없지 않은가

자바는 그 생소한 아이디어에 혹해서 많은 이들이 하고 있지만 기대만큼은 발전속도가 빠르지 못해 조만간 도태될 것이 확실하니 빨리 프로그래머들은 줄을 바꾸세요.
차라리 IBM에서 자바의 라이센스를 관리하고 발전시켰다면 지금 상황이 많이 달라졌을 것인데....
언제 망할지 모르는 썬사에서 이런 것을 한다는 것은 많은 프로그래머에게는 재앙과도 같은 것이다.

누가 속도 안빠르다구 그랬나..
GUI 속도가 너무 느리다구 그랬지..

그러니 만년 서버 프로그램 이외에 별다른
대 쓰이지 않는것 아닙미까...

자바로 게임을 만들고 유틸도 만들수 있어.. 이러지만
단순한 생김새에.. 속도가 거북이..니 탈이지..

개인적으로.. 자바도 역시 C++이다라구 생각합미다..

"프로그래머들은 자랑좀 하지말자.... "

전... 아무꺼나 빨라도 상관없습니다.
C든 C++이든 자바든 아니면 아무 프로그래밍 언어나 똑빠로 짤 수 있었으면 좋겠습니다. ㅜ.ㅜ

29살 먹고도 프로그램 제대로 못 짜는 초보 ㅜ.ㅜ

정말 전부다 똑똑이들 밖에 없군요.
아직도 속도타령을 하시다니...
설계하기에 따라 필요에 따라 적절히 얼마나 잘 사용하는가가 중요합니다.
그리고 무엇보다도 먼저........
여러분은 지금 프로그래밍의 환상에 사로잡혀있지만,
결국 10년 후면 여러분은 그 때는 프로그래밍의 세계에서 떠나야한다는 것입니다.
전부다 한때의 불나방인 것을.........

글쎄요, 객체지향으로 인한 오버헤드의 차이는
자바나 C++이나 마찬가지라고 생각합니다.

그러나 C++은 자바가 가지지 못한 엄청난 성능향상 방법인 inlining(인라이닝) 기술이 있습니다. 인라인 기능을 잘 쓰면 엄청난 속도 향상을 얻을 수 있습니다. 대표적인 예가 ANSI C++의 STL이지요.

엄청나게 오래 걸리는 컴파일 시간을 투자한 STL 프로그램의 성능 향상은 실로 놀랍습니다.
"C++이 C보다 훨씬 빠르다!"라는 것이죠.
실험에 따르면(출처: Effective STL)
C++의 sort()가 C의 qsort()보다 무려 "６７０００"배나 빨랐습니다.
qsort()가 함수 포인터에 의해 매번 비교 함수를 호출해야하는 오버헤드가 있는 반면에,
sort()는 컴파일 타임에 코드가 조립되어서
전혀 함수 호출이 필요없게 되어 버리는 것이죠.

이러한 템플릿과 inlining 메커니즘이 없는 자바는 코딩을 통한 최적화에 한계를 보일 수 밖에는 없습니다.

자바가 최적화된 상태에서 최적화되지 않은 상태의 c/c++을 비교한 것 같습니다.

아~~~ 그리고 자바에 최적화된 자바용 프로세서가 있는데, 그거라면 또 달라지지요.

보통 일반적으로 자바는 c/c++을 따라올수가 없습니다.

님의 말은 즉 c/c++이 어셈블리보다 빠르다는 이야기와 동격입니다.

펀글들을 적당히 정리해서 올려봅니다.
=====================================

JIT 컴파일러에 의한 최적화가 C++보다 앞선다?
가능한 얘기입니다.
다만. 전제조건이 메모리가 엄청나게 많아야 한다는 겁니다. 중간코드를 다시 컴파일 할려면 기존의 응용프로그램이 메모리에 모두 올라가야 되구요. (이럴경우 Lock에 대해서도 궁금한데... 누구 아시는 분 설명좀 부탁드립니다.)
또다른 문제점은 반드시 처음 실행할때는 다소 느리다는 거죠. 왜냐구요?
profile을 할려면 최소한 한번은 실행을 해야 하걸랑요.
프로그램이 실행이 되어야 성능을 체크하죠. 게다가 각종 리소스를 메모리로 가져와야 하는데.

제 생각은 PC들이 모두 메모리 1기가 이상은 되어야 가능한 얘기입니다.

고슬링의 이번 인터뷰도, 썬이 C/C++ 진영을 공략하기 위해 써던 전략의
재탕입니다. 자바 코드가 C++ 코드와 같거나 조금 더 빠르다고 주장하기를 매번 업데이트마다
계속했었지요. 그래서 어떻게 됐습니까.

JBuilder와 같이 절대적으로 pure 자바를 지향하는 경우 외에는, 데스크탑 솔루션은 자바로 만드는
경우는 거의 없습니다. 대표적인 경우가 넷스케이프 브라우저로, 넷스케이프에서는 몇년전에 이넘을
자바로 포팅하려는 야심찬 프로젝트를 하다가 포기한 바 있습니다.

개발자들은 대체로 좀 꼼꼼하다보니, 특정 연산에서 빠르다 아니다에 영향을 많이 받는데요.
그러다보니 나무만 보고 숲은 못보는 경우가 허다합니다. 특정 연산에서 빠를 수도 있습니다.
IT 기술이 발전하는 거니까 당연한 거지요. 하지만 자바의 경우 데스크탑에서 분명히 실패했습니다.

자바가 일반 데스크탑이 아닌 모바일이나 엔터프라이즈에서 특히 각광받는 것은 당연한 것입니다.
원래 자바는 모바일(정확하게는 가전제품)에서 사용되기 위해 설계된 것이었고, 또한 엔터프라이즈
레벨에서는 최악의 경우 대수를 늘리거나 사양을 높임으로써 하드웨어 비용을 높이는 대신 개발
비용을 낮추는 방법으로 공략이 가능했기 때문입니다. 일반 데스크탑 사용자들에게 당장 512MB로
메모리를 증설하고 CPU를 2G로 업그레이드하라는 것은 대단히 어려운 일이지만, 서버를 구축하면서
1GB쯤 메모리와 최신 제온 프로세서를 증설하거나 아예 서버 한대쯤 더 놓는 것은 쉬운 일이니까요.

자바나 C#이 데스크탑에서 위력을 발휘하는 것은 가까운 시일이 되지는 못할 겁니다.
우리나라에서야 PC에 메모리 하나 더 꽂는 것을 연례행사 정도로 여기고 있지만 미국이나 다른 나라들은
우리나라보다 업그레이드에 좀 더 보수적이니까요.
자바나 C#이 데스크탑에서 C++의 강력한 경쟁자가 되기 시작하는 것은 아주 빨라도 5년 정도는 걸리거나,
혹은 거의 불가능할 수도 있습니다.