-- C로 된 원래 퀘이크 2가 245프레임인데, 자바로 된 jake 2는 260프레임 나옵니다.
-- 코드이외의 게임 데이터는 모두 동일하고요.
-- 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
위 글로 볼 때 우기고 싶어 좀이 쑤신다는 것이 역력하잖아요
그래요. 자바가 더 빠릅니다. 설령 현재는 일부에서 빠를 지라도 좀 있으면 전 부문에 걸쳐
빠르겠네요. 그 정도 되면 세상이 온통 자바일겁니다.
VM 도 자바, OS 도 자바, 게임도 자바, 워드도 자바, 자바, 자바...
그 느린 C/C++ 을 어디다 쓰나요.
데니스 리치나 스트라우스트럽 아저씨는 참 세상 물정 모르네요.
자바가 이렇게 좋은데 아직도 C/C++ 로 작업하고 있을 거 아니예요.
>> 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
>> 물론 전체적으로 본다면 C코드가 빠릅니다. 벤치마크에서 자바가 앞선것도 한 시스템에서만이고 다른 시스템에서는 10~20%정도 느리죠.
>> 하지만 님이 말한 것 처럼 전체적으로 수백%~수천% 차이나나요? (물론 그런 차이가 나는 일부 영역도 분명히 존재할겁니다)
뒤쪽글은 않읽으셨나요?
저는 자바가 빠르다고 주장하고 싶어서 좀이 쑤신게 아니라, 개발자들의 오래된 편견이 지겨울 뿐인겁니다.
뭐든지 자기 경험에 없으면 우선 무시하고 보는 그런 편견들 말입니다.
더 나은 방법, 더 빠른 개발, 더 좋은 가독성, 더 쉬운 유지보수. 고객의 요구사항 만족..
이런 지향점을 향해 나아가야 하는데,
C가 제일 빠르고 제일 쉬워요. 다른 언어는 쓰래기에요. 라고 주장하는 사람들이 지겨울 뿐인 거죠.
기술이 계속 발전된다라는 기본적인 마인드 조차 없는 사람들이 정말 많으니까요.
기술이 자기가 속한 영역에서만 발전하는줄 아는 사람들 말입니다. 다른 영역에서 발전된 기술은 무시하고 보는 사람들 말입니다.
-- C가 제일 빠르고 제일 쉬워요. 다른 언어는 쓰래기에요. 라고 주장하는 사람들이 지겨울 뿐인 거죠.
물론 그런 개발자는 반성해야죠. 근데 혹시 '자바가 C 보다 더 빠르고(혹은 더 느리지 않고) 더 쉽다' 라는 믿음을 굳혀가는 사람들은 안지겨우신가요
-- 기술이 계속 발전된다라는 기본적인 마인드 조차 없는 사람들이 정말 많으니까요.
-- 기술이 자기가 속한 영역에서만 발전하는줄 아는 사람들 말입니다.
-- 다른 영역에서 발전된 기술은 무시하고 보는 사람들 말입니다.
지당하신 말씀입니다만 이곳도 거시기한게
-- C로 된 원래 퀘이크 2가 245프레임인데, 자바로 된 jake 2는 260프레임 나옵니다.
-- 코드이외의 게임 데이터는 모두 동일하고요.
-- 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
자바 VM 이 260 프레임정도로 최적화 기술을 발전시켜 온 동안 C 의 최적화 기술은 가만히 있었겠읍니까.
그런 시각으로 저 벤치마킹 자료를 바라보셨어요.
그러면서 '다른 영역에서 발전된 기술은 무시하고 보는 사람' 을 비난하신다면 제 얼굴에 뭐 뱉기 아닐까요.
자바가 이렇게 발전할 때 C/C++ 진영은 도데체 뭘 하고 있었을까요.
자바의 성장을 눈치 못채고 있었을 까요. 아마 그럴 것 같습니다.
이제는 명백해졋읍니다. java 진영에 워낙 우수한 인재들이 몰려 있어
이제는 C 쪽에서 날고 기어 봤댔자 개발속도, 실행속도 등 거의 모든 면에서 java 를 못 쫒아 가네요.
승리한 자바에(아니면 조만간 승리할 자바에)축하를 보내면서
하루 속히 Java 로 Windows 를 만들어서 우리가 빌게이츠의 손에서 벗아나게 해주시면 좋겠읍니다.
그 선봉에 narusas 님의 활약 기대해 봅니다.
>>"3개월 교육받은 신입도 유사하게 만들수 있느냐? 그럼 쉬운 거고, 아니면 어려운 겁니다.
C로 교육한 신입의 성과는 보통 형편없었습니다. 어느정도 자리잡는데 1년 이상 걸리더군요"
일단 어느정도 일리는 있습니다. 그러나 이것하나 생각해보시죠. C가 자바처럼 만들어도 안돌겠어요?
됩니다. 그렇게만드는데는 C도 3개월만 교육하면 됩니다. 하지만 좀더 효율적인 코드를 만들려한다거나..할때 좀더 기간이 필요하죠"
그런데 그기간이 지난 1년뒤의 모습은 어떠할까요? 자바는 전혀발전없이 1년전이나 지금이나 똑같은제자리 걸음이지만..
C는 기간이 지나면지날수록 내공이 깊어집니다. 한 5년이상되는 사람은 과연 어떤것이 쉽게 보일까요?
언어자체를 익히는데는 더걸렸다해도 이미 익힌후 써먹는데는 훨씬 유리하다는겁니다. 개발도 자바보다 C가 더쉽고요..
머 3개월된 초짜들만데리고 개발할꺼면 자바가 유리할수도? 있겠죠..(이부분도 위에말했듯이 C도 그냥 자바처럼개발하면됩니다.)
그러나 객관적으로 생각해보시죠.. 어느것이 더쉬운가..
C는 언어차원에서 무언가 만드는데 요구하는 LoC가 크다보니 뭐하나 변경하는데 고쳐야 하는 부분도 엄청 많죠.,
그 강력함이 오히려 약점으로 작용하게 된단 말입니다.
C가 메인 언어인 사람들의 특징이, low level, high performance 여기에 너무 신경쓰는 경향이 생긴다는 거죠.
물론 embedded 하는 사람들에게는 나쁜 경향이 아닙니다.
하지만 enterprise 하는 사람들에게는 나쁜 경향이라는 겁니다.
한 사람이 big picture를 완전히 파악하기도 어려운 큰 프로젝트에서 자잘한건 몽땅 언어가 알아서 해줘도 모라잘 판인데,
C 프로그래머들은 그 big picture를 잘 못보고 detail에만 집착하는 프로그램을 만들어내는 경향이 있단 말입니다. 그놈의 성능때문에.
xml, web service, distribute object access 이런거 C로 하면 LoC 자체가 엄청 커집니다. 물론 완전히 끝냈을때 성능이야 좋겠죠. 그런데 그 사이에 개발에 걸린 시간은?
그리고 요구사항이 계속 바꿀때는?
자바 프로그래머가 전혀 발전이 없다고 생각하시는가 본데, 큰 착각이십니다.
큰 SI 프로젝트에서는 C 프로그래머가 오히려 OOP를 이해 못하고, 객체지향적인 사고방식을 못가져서 프로젝트가 망한경우가 더 많아요
C 프로그래머들은 보통 2만 LoC까지는 잘 따라오다가 그 이상되면 맨날 디버깅에, 요구사항 하나 바뀌면 맨날 밤샘하면서 뜯어 고치고... 프로그래머마다 누군 포인터쓰고 누군 레퍼런스 써서 통합 에러 맨날 나고.. 코드 커지면 컴파일만 몇시간씩 걸리고.. 그러면서 자기가 맞다고 우기는건 정말 잘하죠. "왜 성능을 무시합니까!"라면서요
C로 자바처럼 개발하면된다?
실행시간 중에 네트워크에서 플러그인을 다운 받아서 프로그램 중단 없이 기능이 확장되는거 Posix C로 LoC 얼마나 나와요?
자바로는 기본 라이브러리로 짧게는 A4용지 한장 분량이면 Prototype 만들수 있는데요?
C로 멀티쓰래드 Echo 서버 만드는데 LoC 얼마나 나와요? 자바는 A4용지 한장분량이면 대부분의 구현이 나오는데요?
C로 멀티인코딩을 사용하는 여러 텍스트 파일을 읽어들여 데이터 관리해야 할때, posix 라이브러리로 해결되요?
low level 내공과 high level 내공은 서로 다르거든요? C로 할때는 low level 내공은 쌓아지지만 High level 내공을 제대로 쌓는 사람 거의 못봤습니다.
C 프로그래머들이 보통 서비스 관점을 전혀 이해 못해요.
C++했던 사람은 그나마 좀 나은 편입니다. OOP를 하다보면ㅕ, 메시징이라는 관점과 그에 따른 서비스라는 관점을 어느정도 이해하거든요.
그런데 엔터프라이즈 영역에서 서비스 관점을 이해 못하면, 진짜 C 코드밖에 못짠다고 구박받는 코드를 양산해내는 사람이 되는 거죠. 맨날 하는 이야기가 "그게 확장/변경 될일 있겠어?". 그런데 변하죠. 그리고는 밤샘 수정.
OOP가 단순히 프로그래밍 기법이라고만 생각하는 C 프로그래머도 참 많죠. 그래서 "그거 C로도 다 되!"라고 억지 주장하죠.
C로 고수가 되는데는 3년이면 되지만, OOP에서 고수가 되려면 5~6년 정도 걸리는 깊은 내공이 필요합니다.
그리고 C 고수가 OOP고수가 되는것은 거의 불가능하다고 보지만, 자바 고수가 OOP고수가 되는데 필요한 시간은 5년정도죠.
C 프로그래머는 "성능"과 "디테일 한 관리"라는 관점을 도저히 못버리더군요.
다익스트라 교수가 베이직을 배운 사람을 자기 제자로 절대뽑지 않았습니다. "베이직을 배운 사람은 프로그래머로써 팔다리가 잘린것과 다름없다"라면서요.
비슷하게 "C를 오래한 사람은, 엔터프라이즈 영역에 들어오게 하지마라."라는 격언도 있지요. 아 물론 속도를 요구하는 모듈 같은거야 시킬수 있죠. 하지만 C프로그래머들은 big picture를 이해하려고 들지를 않죠. 아니 이해를 못하죠. 자기가 가진 패러다임과 원체 다르니까.
>>C는 언어차원에서 무언가 만드는데 요구하는 LoC가 크다보니 뭐하나 변경하는데 고쳐야 하는 부분도 엄청 많죠.,
>>
>>그 강력함이 오히려 약점으로 작용하게 된단 말입니다.
착각이십니다. 약점으로 작용안하거든요? 강점이거든요.. 장점을 단점으로 억지로 끌어내리려하니 대화가되겠어요?
>>
>>C가 메인 언어인 사람들의 특징이, low level, high performance 여기에 너무 신경쓰는 경향이 생긴다는 거죠.
>>
너무 신경안쓰거든요? 아무생각없이해도 자바보다 났다는뜻이거든요? 자바랑 거의 비슷한코드도 단순언어의 선택여하에 자바보다 성능이 더잘나오거든요..
>>물론 embedded 하는 사람들에게는 나쁜 경향이 아닙니다.
>>
>>하지만 enterprise 하는 사람들에게는 나쁜 경향이라는 겁니다.
>>한 사람이 big picture를 완전히 파악하기도 어려운 큰 프로젝트에서 자잘한건 몽땅 언어가 알아서 해줘도 모라잘 판인데,
>>C 프로그래머들은 그 big picture를 잘 못보고 detail에만 집착하는 프로그램을 만들어내는 경향이 있단 말입니다. 그놈의 성능때문에.
천만에말씀.
>>xml, web service, distribute object access 이런거 C로 하면 LoC 자체가 엄청 커집니다. 물론 완전히 끝냈을때 성능이야 좋겠죠. 그런데 그 사이에 개발에 걸린 시간은?
>>
>>그리고 요구사항이 계속 바꿀때는?
자바보다 훨씬 쉽게 바뀌거든요...
>>자바 프로그래머가 전혀 발전이 없다고 생각하시는가 본데, 큰 착각이십니다.
>>
>>큰 SI 프로젝트에서는 C 프로그래머가 오히려 OOP를 이해 못하고, 객체지향적인 사고방식을 못가져서 프로젝트가 망한경우가 더 많아요
OOP 개념의 자바보다 C에먼저있었다는건 아시나요? C ->C++->자바 에게 전수해줬다해도 과언이 아니죠..
실무에서 대부분 자바하시는분이 개념을 못잡던데요..
>>C 프로그래머들은 보통 2만 LoC까지는 잘 따라오다가 그 이상되면 맨날 디버깅에, 요구사항 하나 바뀌면 맨날 밤샘하면서 뜯어 고치고... 프로그래머마다 누군 포인터쓰고 누군 레퍼런스 써서 통합 에러 맨날 나고.. 코드 커지면 컴파일만 몇시간씩 걸리고.. 그러면서 자기가 맞다고 우기는건 정말 잘하죠. "왜 성능을 무시합니까!"라면서요
보통 짜는데 C가 자바보다 더빨리짜고 디버깅이라해봐야 전체다해도 보통 하루도 안걸리거든요..
요구사항바뀌면 간단히 수정만 하면끝이거든요.. 자바하시는분들 밤샘하는거 무지많이봤어요..
>>C로 자바처럼 개발하면된다?
>>
>>실행시간 중에 네트워크에서 플러그인을 다운 받아서 프로그램 중단 없이 기능이 확장되는거 Posix C로 LoC 얼마나 나와요?
>>자바로는 기본 라이브러리로 짧게는 A4용지 한장 분량이면 Prototype 만들수 있는데요?
C로는 상용라이브러리로 한장도 안되거든요..
>>C로 멀티쓰래드 Echo 서버 만드는데 LoC 얼마나 나와요? 자바는 A4용지 한장분량이면 대부분의 구현이 나오는데요?
한장도 안되요.
>>C로 멀티인코딩을 사용하는 여러 텍스트 파일을 읽어들여 데이터 관리해야 할때, posix 라이브러리로 해결되요?
라이브러리 사용하면되요..
>>low level 내공과 high level 내공은 서로 다르거든요? C로 할때는 low level 내공은 쌓아지지만 High level 내공을 제대로 쌓는 사람 거의 못봤습니다.
둘다 더많이 쌓이거든요? 지식은 상호보완적이라고 Low 를알면 High 도 더빨리 파악되거든요?
우물안개구리처럼 하나만알고 둘을 모르는사람하고 다르죠..
>>
>>C 프로그래머들이 보통 서비스 관점을 전혀 이해 못해요.
천만에요..
>>C++했던 사람은 그나마 좀 나은 편입니다. OOP를 하다보면ㅕ, 메시징이라는 관점과 그에 따른 서비스라는 관점을 어느정도 이해하거든요.
>>
>>그런데 엔터프라이즈 영역에서 서비스 관점을 이해 못하면, 진짜 C 코드밖에 못짠다고 구박받는 코드를 양산해내는 사람이 되는 거죠. 맨날 하는 이야기가 "그게 확장/변경 될일 있겠어?". 그런데 변하죠. 그리고는 밤샘 수정.
>>
>>OOP가 단순히 프로그래밍 기법이라고만 생각하는 C 프로그래머도 참 많죠. 그래서 "그거 C로도 다 되!"라고 억지 주장하죠.
님이 몰라서 지금 어거지쓰시는거에요..
.
>>C로 고수가 되는데는 3년이면 되지만, OOP에서 고수가 되려면 5~6년 정도 걸리는 깊은 내공이 필요합니다.
이것도 어거지시고..
>>그리고 C 고수가 OOP고수가 되는것은 거의 불가능하다고 보지만, 자바 고수가 OOP고수가 되는데 필요한 시간은 5년정도죠.
자바하시는분.기본을 모르니 많이 걸리죠..
>>
>>C 프로그래머는 "성능"과 "디테일 한 관리"라는 관점을 도저히 못버리더군요.
>>다익스트라 교수가 베이직을 배운 사람을 자기 제자로 절대뽑지 않았습니다. "베이직을 배운 사람은 프로그래머로써 팔다리가 잘린것과 다름없다"라면서요.
>>비슷하게 "C를 오래한 사람은, 엔터프라이즈 영역에 들어오게 하지마라."라는 격언도 있지요. 아 물론 속도를 요구하는 모듈 같은거야 시킬수 있죠. 하지만 C프로그래머들은 big picture를 이해하려고 들지를 않죠. 아니 이해를 못하죠. 자기가 가진 패러다임과 원체 다르니까.
아마도 "까마귀노는곳에 백로야 가지마라" 겠죠...
참고로 불과 몇년전만하더라도 사람들은 "자바도프로그램이냐" 라고 했죠.. 한마디로 프로그램축에도 안껴줬어요..
그만큼 개념도 없고 프로그램같지도 않았단소립니다.
물론 최근의 Swing은 많은 발전을 해서 예전과 비교할수 없을정도의 반응성을 보여줌니다.
하지만, High level 추상화를 선택한 대부분의 UI Toolkit이 그렇듯이 반응성 향상에 한계가 있죠.
그래서 빠른 반응성을 낼수 있는 low level UI Toolkit 을 지향하면서 SWT가 나왔죠.(SWT는 운영체체의 Component를 사용하여서 빠른 속도를 낼수 있게 만들어 졌죠)
그리고 SWT를 high level 추상화한 클래스로 래핑한 JFace가 나온거고요.
그래도 최근 비교로는 JDK 1.6 Swing과 SWT의 속도차이는 거의 나지 않습니다.
Swing이 내부적으로 Java2d를 드로잉에 사용하는데, java2d가 OpenGL pipeline을 기본 지원하면서 렌더링 속도가 대폭 향상되면서, 반응성도 엄청 올라갔거든요. (대충 JDK 1.5 스윙과 비교할때 30%정도 빨라졌다는게 일반적인 평가입니다)
다만 swt에 비해 스윙은 메모리를 많이 먹기때문에 ^^ SWT는 eSWT라고 임베디드 시스템에서 사용할수 있을정도로 작게 만들어지고 있으니까요.
"The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java."
그리고 위의 quake2 게임은 예로 드시기가 무리인게
C 코드는 십년가까이 전에 나온것으로 3D 게임쪽 알고리즘이 그다지 발달하지 않았을 시기이고 CPU 의 각종 SSE 등의 옵션을 고려한 math lib 을 근간으로 구성하지도 않았던 코드입니다.
지금 나오는 Jake 코드는 최신 이론을 기반으로 다시 알고리즘을 편성한 게임입니다. ( 즉 아예 다른 방식으로 짠겁니다. )
(Some simple optimizations (vector arrays, optimized memory handling in loops etc.) show remarkable effect on performance and there surely is still room for further improvements. ) - 게다가 앞으로 더 개선할 사항도 있다고 합니다.
과거에 at least 60%였고, 0.9.2 에서 fastjogl을 이용해서 85% 수준까지 올릴수 있다고 나오죠. (Jake2 0.9.2 can achieve up to 85% of the framerate of the C version)
그후 차례대로 0.9.3, 0.9.4 에서 괄목할 만한 성능 향상을 거두었고, 여전히 빠르게 할 여지가 남아 있다고 나옵니다
제가 제시한 성능은 0.9.4에서의 성능이죠. 원문을 제대로 다시 ""읽어"" 보세요.. 에휴..
quake 2 소스는 현재의 sse등에 최적화 된 libc나 libmath를 이용해 컴파일해도 컴파일시킬수 있는 코드고, 그렇게 했을때의 결과들이죠.
그리고 jake2는 id의 quake 2엔진의 자바 포팅입니다. 새로짠게 맞긴하지만, 기본 구조나 알고리즘은 quake2와 동일합니다.
quake 2가 오래된 소스라는 건 맞는 이야기 입니다. 최신 게임들에 비교하면 많이 떨어지겠죠.
하지만 동일한 BSP나 OpenGL 코드를 기반으로 동일한 알고리즘을 가지는 jake2를 아예 다른 알고리즘을 사용하고 있다.. 뭐 부분부분 달라 졌겠죠.
하지만 제가 0.9.3 시절에 분석해본 BSP 구조등은 quake 2와 거의 유사했습니다. 아예 다른 방식으로 짠게 아닙니다. 그렇게 짰다면 기존의 quake 2 데이터들을 못사용하죠.
>> 게임업계에서 일하는 사람으로썬 Java 는 정말 쓰고 싶어도 쓸수가 없는 상황입니다.
물론 자바로 하드웨어의 성능을 극한까지 뽑아내는 게임은 만들기 어려울 겁니다. 하지만 핸드폰에서 돌아가는 수많은 자바 게임들이나,한세대 정도 전의 게임정도는 충분히 가능하다고 봅니다.http://lwjgl.org/shop.php 같은 곳을 보면 말이죠. 결국엔 자바로 게임을 만들어 본 사람이 없기 때문에 방법도 축적이 잘 않된다는 악순환적인 문제가 있지요.
물론 자바로 게임제작을 허가하는 기업이 없으니까 문제긴 하죠. 그러니 쓰고 싶어도 못쓰죠.
The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java. In comparison with object oriented C++ Code Java would look even better
FPS가 C와 자바의 절대정 성능비교는 아니지만, C의 """최소한""" 60%의 성능을 낼수 있다. C++과 비교하면 더 좋을수 있다.
The 0.9.2 release shows a big improvent due to the new “fastjogl” OpenGL renderer.
0.9.2는 fasljogl Opengl render를 이용하여 큰 진전이 있었다.
Jake2 0.9.2 can achieve up to 85% of the framerate of the C version.
0.9.2는 C버전의 85%까지 FPS를 올릴수 있었다.
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop.
0.9.3은 주로 게임 루프에서 메모리 할당의 회수를 줄여서 갭을 더 줄여서 C버전과 성능차를 거의 줄였다.
The new release 0.9.4 brings yet another incredible performance boost.
0.9.4는 또다른 엄청난 성능 향상을 얻을수 있었다.
C 대비 각버전별 성능(제일 느린 결과/빠른결과)
0.9.1 : 53% / 70% (평균 60%정도)
0.9.2 : 80% / 86%
0.9.3 : 82% / 98%
0.9.4 : 91% / 106%
jake2는 오래전 부터 제가 트래킹해오던 사이트고, 홈페이지 관리가 잘 되지 않기 때문에 밑부분에 조금씩 추가만 되는 형태로 홈페이지가 유지되오는 사이트입니다.
60%가 처음 제시된게 0.9.1시절이였던거죠. 게다가 현재 0,9.5로 업데이트 되었는데도 불구하고 홈페이지가 아직 갱신되지 않은 상태이고요.
제가 읽어 보라고 말씀드린건, 읽고 직접 계산해보고 판단해 보시라는 것이였습니다. 문장에 %가 나온게 85까지이지만, 그 이후의 결과를 직접 계산해 보시면 알거라고 생각했는데 제가 조금 짧게 글을 쓴거 같군요.
제가 제시한 내용은 "스타크래프트를 자바로 만들면 10배는 느려질꺼다"라는 주장에 대한 반론이였습니다. 스타크래프트는 자바로 만들어 진게 없으니, 동일한 게임이 java와 C로 존재하는 quake 2와 jake2를 들었던 겁니다. 다른 벤치마크를 못믿으시니 실제 비교 가능한한 동일한 어플리케이션을 예로 들수밖에 없었던 거죠. quake 2 엔진이 오래되긴 했어도 아직 현역으로 사용되는 엔진이니까요.
제 글은 "일반론으로 자바로 게임을 만들면 10배 느릴것이다"라고 하는 주장에 대한 실제 반증을 들었던 겁니다.
"자바로 게임을 만들어도 그렇게 느리지 않다"라고 말이죠.
ps. 저야 두세대 이상 전에 게임을 만들었던( 진짜로 퀘이크 2 나오던 시절에 말이죠 ) 사람이라 그당시에 카멕이 공개한 코드 가지고 분석하던 오래된 기억으로 jake 2를 봤으니 아마 최근에 보셨다는 neogeo님의 아시는 분 말씀이 맞겠지요.
(소스들여다 보고, 유즈넷에서 검색하고 해서 어찌어찌 BSP 개념을 알아내고 좋아하던 시절이였는데요..^^ 이제는 GPG같은 책까지 번역되어서 참 접하기 쉬워졌죠. 게임 프로그래밍을 않한지 몇년 되니 다 까먹었네요.^^ 제가 게임 프로그래밍 배울때 바이블은 스트리트파이트 소스였습니다. ^^ )
ps.2 앞으로는 수사학적인 표현은 쓰지 말아야 겠네요. 은유나 비유를 쓰면 어김없이 오해를 불러 일으키는 군요..
The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java. In comparison with object oriented C++ Code Java would look even better
FPS가 C와 자바의 절대정 성능비교는 아니지만, C의 """최소한""" 60%의 성능을 낼수 있다. C++과 비교하면 더 좋을수 있다.
라고 시작하고 있습니다. 즉 FPS(Frame per second)를 벤치마크의 지표로 삼겠다는 이야기죠.
그다음도 지속적으로 FPS에 대한 이야기를 하고 있습니다.
The 0.9.2 release shows a big improvent due to the new “fastjogl” OpenGL renderer.
0.9.2는 fasljogl Opengl render를 이용하여 큰 진전이 있었다.
Jake2 0.9.2 can achieve up to 85% of the framerate of the C version.
0.9.2는 C버전의 85%까지 FPS를 올릴수 있었다.
0.9.2 의 성능은 벤치마크 대상이 된 시스템에서 최저 80% / 최고 86%의 성능을 내게 되었습니다.
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop.
0.9.3은 주로 게임 루프에서 메모리 할당의 회수를 줄여서 갭을 더 줄여서 C버전과 성능차를 거의 줄였다.
0.9.3의 성능은 최저 82% / 최고 98% 였습니다.
The new release 0.9.4 brings yet another incredible performance boost.
0.9.4는 또다른 엄청난 성능 향상을 얻을수 있었다.
0.9.4의 성능은 최저 91% / 최고106% 였습니다.
제가 제시한 성능은 0.9.4의 성능이라고 분명히 말씀드렸습니다.
그리고 어떻게 읽으셨는지 모르겠습나다만, at least는 최소한 이라는 의미입니다.
실제의 quake 2 소스도 동일한 CPU에 동일한 그래픽 칩셋을 사용하더라도 그래픽 카드 벤더등에 따라 성능차가 많이 있었습니다. 거기에서 at least 30 fps가 나온다.. 라고 하면 quake 2 엔진의 성능은 30 fps인가요?
문제는 0.9.2 를 언급하기 전에 전체적으로 at least 60% 라는 문장을 현재형으로 썼다는데 주목하자는 겁니다.
즉 벤치마커 역시 아직 최소 60% 수준으로 보고 있는 거지요.
0.9.2 는 맨 아래 란에서 60% 아래의 성능을 분명 보였습니다. ( 최저 82% 가 아닙니다 )
원저자의 의도를 무시하고 무조건 0.9.4 로 제시를 한다는것 자체가 오류라는 겁니다.
그리고 up to 역시 최대한 이란 의미 입니다.
그리고 0.9.4 나 0.9.3 을 먼저 제시하지 않고 적어도 60% 라고 언급한것은 분명 그것이 C 와 java 를 비교하는데 적절한 대상이었기에 먼저 언급한 것이라고 봅니다.
애초에 언급하신 예인 java 가 C 의 성능에 필적한다는 논점과는 벤치마커의 의도 조차 전혀 다르다는게 제 요지였습니다.
즉 벤치마커 역시 60% 수준 이상을 보인다라고 말하는 ( 전체 논지가 분명 그렇습니다 ) 글을 가지고 증거로 삼기에
잘못된 논리라고 이야기를 한 것이지요. ( 절대 감정적인게 아니라 내용 자체가 그렇습니다. )
왜 제가 자꾸 이렇게 이야기 하냐면 저역시 저 사이트를 2004년 인가 부터 계속 봐왔습니다.
저 사이트에서 Jake2 버젼은 계속 변했지만 60% 정도의 수준이라는건 계속 그 문장 그대로 내용이 있어왔습니다.
절대로 저 벤치마크는 내용을 뒤에 추가한것이 아니라 새로운 벤치결과가 있을 때마다 내용을 다시 쓴 것입니다.
따라서 벤치마커 역시 그 문장의 의도를 그대로 전달하고 싶다는게 제 글의 요지입니다.
즉 벤치마커 조차 적어도 60%로 생각하는 C vs Java on FPS app 벤치마크를 narusas 님의 의도로 가져다 쓰는게 애초에 논리가 맞지 않는다 라는 의미입니다. ( 10~20% 부족은 아무리 많아도 20% 부족 수준이 되어야 그 수준이라고 할 수 있습니다. )
The following table shows the framerates of jake2-0.9.1. 에서 The following table shows the framerates of our Jake2 releases. 로 바뀐것과 , We have not done profiling and optimization yet.라는 문장이 빠진것 이외에는 동일합니다.
Our new release shows a big improvent due to the new ?fastjogl? OpenGL renderer. The new renderer reduces the number of native interface calls. JNI calls produce a considerable overhead and were the main bottleneck in our application. Jake2 0.9.2 can achieve up to 85% of the framerate of the C version. It depends on the relative performance of the CPU and GPU
라는 문장이 추가 됩니다.
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop. But as you see the Java support for fullscreen modes is still not where it should be.
The new release 0.9.4 brings yet another incredible performance boost. Some simple optimizations (vector arrays, optimized memory handling in loops etc.) show remarkable effect on performance and there surely is still room for further improvements.
라는 문장이 추가 되죠.
이렇게 보면 0.9.2 이후로는 처음 3문단은 몇년간 전혀 수정하지 않고 있는 겁니다. 고쳐지는게 아니죠. 저는 이것을 일반적인 프로그래머/엔지니어들의 특성인 문서 쓰기 귀찮아함의 결과라고 봅니다.
원 저자의 의도가 뭘까요? 전체 논지가 뭘까요? jake2가 이만큼 발전했습니다 일까요? 아니면 아직도 60%밖에 않되요 일까요?
저는 전자라고 보고 있습니다.
ps. 그리고 FPS는 최고 수치를 기반으로 벤치마킹하는게 일반적이죠.
둠3돌리면서 "제컴에서 60 FPS가 나와요~"라고 말하지, "제컴에서 제일 느릴때는 10fps에요"라고 말하는 건 자학할때나 쓰이는 방법이죠 ^^
그리고 실제로 제 컴에서 둠3돌리면 10프레임도 않나옵니다 -_-;; 그래서 아직도 카스는 그냥 카스 하지 카스 소스는 꿈도 못꾸고 있습니다.
과거에 at least 60%였고, 0.9.2 에서 fastjogl을 이용해서 85% 수준까지 올릴수 있다고 나오죠. (Jake2 0.9.2 can achieve up to 85% of the framerate of the C version)
그후 차례대로 0.9.3, 0.9.4 에서 괄목할 만한 성능 향상을 거두었고, 여전히 빠르게 할 여지가 남아 있다고 나옵니다
제가 제시한 성능은 0.9.4에서의 성능이죠. 원문을 제대로 다시 ""읽어"" 보세요.. 에휴..
quake 2 소스는 현재의 sse등에 최적화 된 libc나 libmath를 이용해 컴파일해도 컴파일시킬수 있는 코드고, 그렇게 했을때의 결과들이죠.
그리고 jake2는 id의 quake 2엔진의 자바 포팅입니다. 새로짠게 맞긴하지만, 기본 구조나 알고리즘은 quake2와 동일합니다.
quake 2가 오래된 소스라는 건 맞는 이야기 입니다. 최신 게임들에 비교하면 많이 떨어지겠죠.
하지만 동일한 BSP나 OpenGL 코드를 기반으로 동일한 알고리즘을 가지는 jake2를 아예 다른 알고리즘을 사용하고 있다.. 뭐 부분부분 달라 졌겠죠.
하지만 제가 0.9.3 시절에 분석해본 BSP 구조등은 quake 2와 거의 유사했습니다. 아예 다른 방식으로 짠게 아닙니다. 그렇게 짰다면 기존의 quake 2 데이터들을 못사용하죠.
>> 게임업계에서 일하는 사람으로썬 Java 는 정말 쓰고 싶어도 쓸수가 없는 상황입니다.
물론 자바로 하드웨어의 성능을 극한까지 뽑아내는 게임은 만들기 어려울 겁니다. 하지만 핸드폰에서 돌아가는 수많은 자바 게임들이나,한세대 정도 전의 게임정도는 충분히 가능하다고 봅니다.http://lwjgl.org/shop.php 같은 곳을 보면 말이죠. 결국엔 자바로 게임을 만들어 본 사람이 없기 때문에 방법도 축적이 잘 않된다는 악순환적인 문제가 있지요.
물론 자바로 게임제작을 허가하는 기업이 없으니까 문제긴 하죠. 그러니 쓰고 싶어도 못쓰죠.
진지하게 토론 하려는 사람이 거의 없는 가운데,
이렇게 진지하게 코드 까지 제시해 주시는 harisoo님 참 멋지시네요^^ 님같은 분들이 많아야 제대로 된 토론이 될텐데요
아무튼, 자바 플랫폼 스펙에서 char은 utf-16 code unit 입니다.
다만, 이것을 지원하기 위한 자바 플랫폼의 내부적 인코딩은 UTF-16일수도 있고 그때그때 다르다가 정답으로 알고 있습니다. 내부적으로 UTF-8과 UTF-32 등 현존 하는 유니코드를 지원하기 위한 코드들이 존재했고, 혼합해서 관리하기 때문에 예전 JDK에서는 문자열 처리 성능이 많이 떨어졌었습니다.
제가 자바 내부에 대해서 말씀 드린 것은 JDK 1.3 기준이였는데, JDK 1.4인가 1.5에서 문자열 처리 루틴의 성능을 대폭 향상시켰다고 하는데, 저는 아직 검증해 본적이 없기 때문에 뭐라 말씀드리기 어렵네요. (제 업무 환경이 JDK1.3이라서요 ^^ 정확하게는 J2ME CDC 환경이었죠. )
그리고 읽어들인 raw data를 이용해 String 객체를 만듭니다. 이때 인코딩을 명시해야되죠. (명시 않하면 시스템 인코딩을 사용합니다)
byte[] rawText = intpuut();
String str = new String(rawText, "euc-kr");
이때 내부적으로 인코딩 전환이 일어날겁니다. (겁니다라고 말하는 것은 JVM마다 처리하는 방식이 다를수 있기때문입니다)
그래서 그 다음 부터는 문자열을 java.lang.String으로 다루던가 char의 배열 또는 CharSequence 로 처리할수 있게 됩니다.
char[] ch = str.toCharArray();
그리고 다시 raw data를 얻어 내는 것도 유사하게 됩니다. 단, 생산해낼 raw data의 인코딩이 필요하죠.
byte[] raw = str.getBytes("utf-8");
이런 변환과정이 번거롭기 때문에 Input/OutputStream 대신 Reader/Writer라는 문자열 전문 처리 클래스를 입출력에 사용하죠.
Socket s = serverSocket.accept();
Reader r = new InputStreamReader( s.getInputStream(), "euc-kr");
char ch = r.read();
자바에서 java.lang.String 문자열은 변하지 않는 Value Object입니다.
문자열 연산을 수행하면, 새로운 문자열이 만들어 집니다.
이것은 Side effect를 제거하기때문에 오류를 줄이는데 큰 도움을 주지만, 그만큼 메모리를 더 사용한다라는 단점도 있지요.
그래서 썬에서 문자열에서 사용하는 메모리를 줄이기 위해, 각각의 문자열을 Flightweight pattern을 사용하여 캐싱합니다.
이러한 과정은 어디까지나 JVM 내부에서 동작하기 때문에, 일반적인 자바 프로그래머는 저 사실을 고려할 필요가 없지요.
이처럼 자바의 문자열 지원은 장단점이 뚜렷합니다.
많은 일을 알아서 해주기때문에 프로그래머는 좀더 비지니스 로직에만 신경쓸수 있게 됩니다. 반면에 그만큼의 메모리와 비용을 소비하게 되는 거죠.
우리모두 닷넷플렛폼 쓰면 더이상 언어에 대한 속도 논쟁은 없을듯.
저는 주 종목이 자바입니다. 그래서 자바가 가장 빠른 언어라고 생각합니다.
내친구는 주 종목이 c++입니다. 그래서 c++이 가장 빠르다고 생각한다고 합니다.
왜냐하면 어느게 더 빠르냐는 의미를 어느게 좋은 언어냐라고 생각하는 편견이 개발자들 머리 한구석에 자리잡고 있기때문입니다.
처음 논점과는 다르게 무익한 논쟁으로 번지는 것 같아서 그냥 재미로 보고만 있었습니다만 좀 어이가 없군요.
자바는 인터프리터 언어가 아닙니다. JIT 컴파일러는 실행전 혹은 실행중에 자주사용되는 바이트코드를 기계어 레벨로
컴파일해서 캐싱하는 방법으로 수행되는데다 바이트코드 자체가 기계어 레벨의 기능을 수행하도록 설계되어 있기 때문에
일반적인 스크립트 언어처럼 파싱에 들어가는 비용이 크지않습니다. 그래서 Just-In-Time 컴파일러인 것이죠.
하다못해 스크립트 언어도 컴파일 언어와 비교했을 때 수십배 정도의 성능차이를 보입니다. 그런데 기계어 레벨로 컴파일
되어서 수행되는 언어가 수백~수천배나 느리다니요? 상식적으로 말이 안되지 않습니까.
게다가 개발자는 누구나 자신이 사용하는 도구의 장단점을 알고 있습니다. 황금 망치가 없다는 건 누구나 아는 사실입니다.
C/C++을 만지면서 메모리 관리에 신경을 쓰듯 어느정도 자바를 알고있다고 자부하는 사람들은 당연히 최적화에 신경을 씁니다.
디자인 설계부터 캐싱, 비동기화, 부분적인 JNI로 교체, 코드레벨에서의 간소화, GC를 고려한 타이밍 분배를 통해서죠.
이런 과정을 통해서 네이티브 언어와 비슷하거나 더 빠른 자바 어플리케이션이 만들어지는 겁니다. 아, 물론 이런 최적화 역시
C/C++ 프로그래머도 할 수 있습니다. 하지만 그렇다면,
'숙련된 자바 프로그래머라도 해도 숙련된 C/C++ 프로그래머가 만든 동일한 어플리케이션에 비하면 수백~수천배나 느려!'
라고 생각한단 말입니까? 분명히 말해서, 그건 상대방을 낮춰보는 '오만'입니다.
그리고 무엇보다 우스운 건, C/C++의 발전이 C/C++로 만들어진 JVM에 적용된다는 생각은 왜 못하십니까. 잘 생각해보면 JVM은
고도의 추상화 덩어리에 불과합니다. 하다못해 C/C++로 만든 스크립트 언어도 그 정도 성능차이가 나지않는데 C/C++로 만든
컴파일용 범용언어가 수백배나 성능이 느리다고요? 그게 개발자로서 납득이 가십니까? 제가 C/C++ 프로그래머 입장이라면
'그거 누가 만들었어? 바보아냐? 뭔가 잘못 만들었겠지?'라고 말해줄 것 같습니다만.
팔은 안으로 굽는다고, 편견일 수도 있습니다만 위에서 자바가 빠르다고 말씀하시는 분들 중에 '어느모로 봐도 자바가 빠르다'라고 말한 분은
없었습니다. 대개 '일반적인 관념과는 다르다'라고 주장했을 따름이죠. 일반적으로 아무런 생각없이 '자바는 느려'라고 생각하니까 '알면
그냥 생각했던 것과는 다르다'라고 말하는거지 '말도 안되는 소리마, 내 언어가 최고야'라고 말한적이 없습니다. 그런데 C/C++ 언어를 옹호
하시는 분들(최소한 그렇게 보이는)이 도대체 왜 그렇게 과장해서까지 상대를 깎아내리는 건지 모르겠습니다. 정말 진심으로 자바가 수십배~
수천배나 느리다고 생각하신다면 '인터프리터 방식인 스크립트 언어보다 못한 수준인 컴파일 방식언어' 자바의 열등함을 자료로 제시하는게
나을 것 입니다.
에휴, 아닙니다. 지금 언어의 우월함을 논쟁하자는 말이 아닙니다.
설령 언어의 우월함이라는게 있어서 어느게 최고냐고 싸우는게 할만한 일이 라고해도 그건 자신을 높여서 증명할 일이지 상대방을 깎아내려서
증명할게 못됩니다. 손에 들고 있는 도구가 맘에 들지만, 다른 도구를 들고있는 것만으로도 상대방과 싸워야한다면 그 도구를 버리는게
'프로그래머'로서는 안될 일일지 모르지만 '인간'으로는 할 법한 행동아닙니까?
자바든 C든 C#이든, 동적언어든 정적언어든, 인터프리터 방식이든 컴파일 방식이든 중요한 것은 '좋아하되 헤어나지 못할 정도가 되지않는 것'
입니다. 우리 모두 상대방 먼저 바라봅시다. 자신 먼저 바라보는건 항상 하는 일이 아닙니까?
일단 자바가 느립니다.
위에서 많이 안느리다고는 하나 실제로 짜여진건 밴치마크의 셈플처럼 전부 저런코드만 있는게 아닙니다.
대부분 스트링처리나 네트웍 db 그래픽 관련 인데 그런곳에서는 매우큰차이가 있습니다.
윗쪽에 스트링처리하나만하더라도 자바는 범용함수를 사용하여구현해야하는반면 c 는 그자체엔진에 적합한 맞춤형함수를
사용할수 있기때문에 성능차이는 매우큽니다. 함수하나에서만해도 수백%이상 성능차이가 나죠..
어쨋거나 전체적으로 따져보면 꽤성능차이가 납니다. 10~20% 정도가 아니고 보통 수백% ~수천% 정도 성능차가 납니다.
못믿으시겠지만 사실입니다..
단적인 예로 자바로 스타크레프트 만든다면 어찌될지...아마도 최소한 10배는 느릴겁니다.
그렇다고 자바가 전혀 쓸모 없는것이란 말은 아닙니다. 누구나 공감하듯 개똥도 약에쓸일이있다고 그리 속도가 중요하지 않은곳에 쓰입니다.
하지만 분명한건 자바하시는분들은 왜그리 속도도 빠르다고 우기시는지..그건 아니라고 봅니다.
아마도 sun 의 자신들의 자바를 홍보하기위해 내놓은 그런 말만믿고 사실믿고 싶겠죠.. 그걸그대로 말하는경향이 있습니다.
이런 말들은 과거에는 없었는데 자바가 나오면서 이런현상이 나타나는것같습니다..
역시 자바때문에 말들이 많네요...
--------------------------------------------------------------------------------------------------------------------
라고, 글타래 중에 하나가 있습니다. 보시다시피 '수백~수천%' 정도 성능차이가 나고 '개똥도 약에 쓸일이 있다'는 식으로 말하므로 '오만'
이라고 한 겁니다. 하긴, 정말로 그렇게 생각하는 사람이라면 익명으로 남길 일도 없을텐데 그냥 지나가는 소리에 어이가 없어서 좀 흥분
했군요. 죄송합니다.
제 개인적인 생각으로는 최적으로 튜닝된 자바 프로그램이 C/C++에 비해 그다지 떨어지지 않는다고 생각합니다. 여기서 떨어지지 않는다는
의미는 수치상의 문제가 아니라 '사용상에 있어서 문제가 되지않을 정도'라는 의미입니다. 물론 0.01초를 다투는 타임 크리티컬한 부문은
요구사항 자체가 시간을 포함하기 때문에 사용상의 문제가 되므로 제외하고 말이죠.
분명 자바 어플리케이션은 태생적인 한계로 네이티브 어플리케이션보다 느립니다. 문제는 '얼마나 느린가'라는 것 입니다.
많은 분들이 '상당히 느리다'라고 하시는데, 그렇다면 숙련된 자바 프로그래머와 숙련된 C/C++ 프로그래머가 있다고 가정하고, 동일한 스펙을
구현했을 때 자바 프로그램와 네이티브 프로그램의 성능차를 얼마로 보십니까? 프로파일링을 통해서 병목부분을 제거하고 멀티쓰레드로 성능을
높이고 캐싱기법 등을 통해 최종적인 튜닝을 거친 동일한 스펙의 자바 프로그램과 네이티브 프로그램의 성능차이를 어느정도로 보는지 묻고
싶습니다. C/C++로 만든 프로그램이 10초 정도일 때 자바로 만든 동일한 스펙의 프로그램이 20초 정도 걸릴까요? JIT의 특성상 시작시간이
오래걸리는 건 어쩔 수 없는 사실입니다. 그렇다면 런타임 도중에는 어떻게 보십니까?
솔직히 '자바하시는 분들 그걸 모르고 계시죠'라거나 '사실을 부정하고 싶겠지'라는 부분은 기분이 나쁩니다. 왜냐하면 그건 누구나 알고 있는
사실인데 '넌 그것도 모르지?'라는 식으로 들리기 때문입니다. 분명히 말하건대, 자바를 사용하면서 장점만 알고 단점을 모르는 사람이라면
그건 자바 프로그래머가 아닙니다. 특정 도구를 선택한다는 것은 그 단점마저도 같이 선택하는 것이기 때문입니다. 단언컨대, 자바 프로그램이
느리다는 건 모든 자바 프로그래머가 압니다. 그렇기 때문에 자바 개발자는 퍼포먼스 튜닝에 심혈을 기울입니다. 다시 말씀드리지만 C/C++
개발자가 메모리 누수에 민감하듯이, 자바 개발자는 퍼포먼스 저하에 대해 민감합니다. '그걸 모르고 계시죠'라는 말은 모든 자바 개발자를
'그렇지 않다던데? 벤치마킹도 비슷하던데, 그냥해도 되겠지'라고 생각하는 기본도 모르는 코더로 본다는 뜻으로 들려서 기분이 나쁜 겁니다.
여하튼 요지는 이렇습니다. 설계, 분석부터 튜닝에 이르기까지 모두 실무에 숙련된 자바 프로그래머와 마찬가지의 C/C++ 프로그래머가 동일한
스펙의 요구사항을 받아 프로그램을 만들 때, 그게 정말 '상당한'이라고 불릴 정도의 차이가 날 것인가? 라는 점입니다.
아 그리고 상업화에 관해서 안타깝다는 의견은 개인적으로 이해가 잘 안갑니다. 자바 플랫폼은 이미 J2EE가 오픈소스화 되어있고, J2SE가
오픈소스가 결정되었으며 J2ME도 오픈소스화 될 계획입니다. IDE는 이클립스와 넷빈즈가 있어서 사실상 언어, 개발환경부터 라이브러리,
소스코드에 이르기까지 오픈되어 있는데 상업화...라는 건 어떤 부분을 말씀하시는 것...인지? 잘 모르겠군요.
PS : 아... 수백 수천배가 아니라 수백~수천%였군요. 워낙 수치가 커서 '수십, 수백배'라고 느껴버린 모양입니다.
자바 퍼포먼스 튜닝의 기본은 파일, 네트워크, DB 액세스와 관련된 I/O 접근의 최소화 및 최적화입니다.
더 정확히 말하면 병목지점을 없애는 것이지만 상당부분이 I/O 에서 일어나므로 일반적으로 I/O를 어떻게 다루느냐가 관건이라고
봐도 무방합니다. 사실 이건 언어를 막론하고 모든 튜닝의 기본입니다.
그 다음부터는 GC에 따른 오버헤드와 같은 메모리나 비효율적인 코드의 문제로 넘어갑니다.
그런데 이런 튜닝은 I/O 만큼 눈에 띄는 성과는 없는데다가, 수많은 벤치마킹이 보여주는 '상업적인(?) 샘플코드'에서도 보듯이 루프나
메서드 호출과 같은 기본적인 사항에 있어서 C/C++과 자바의 성능차이는 없다고 봐도 무방합니다. 이건 당장 테스트 코드 몇개만 돌려봐도
간단하게 증명될 수 있는 내용입니다.
그렇다면 I/O 부분에서 수백~수천% 정도나 차이가 나느냐하면, 그럴리가 없지요. JVM의 I/O는 기본적으로 C/C++로 작성된 것인데요. -_-;;
JVM에서 네이티브 함수를 호출하는데 들어가는 오버헤드 때문에 그런 차이가 난다는 건 상식적으로 말이 안됩니다. 오버헤드가 있긴 하지만
그게 몇 배나 느리게 만든다고 말하기에는 무리가 있습니다. 90년대 후반의 초기 JVM의 성능문제도 다른 것이 아니라 인터프리팅 부분에
있었으니까요. 그래서 JIT 컴파일러가 나온다음에 상당부분 해소된 것이죠.
요약하면 다음과 같습니다.
첫째, 메모리 영역에서의 연산능력의 차이는 코드가 증명하듯이 사실상 없습니다.
둘째, 물리적 혹은 비물리적 I/O에 관계된 오버헤드가 존재하는 것은 분명하지만 그것이 몇 배나 차이를 불러오지는 않습니다. 게다가 I/O의
상당부분은 캐시나 풀링과 같은 기본적인 튜닝 기법만으로도 성능저하를 막을 수 있습니다.
하지만 그럼에도 불구하고 다음과 같은 이유로 자바 어플리케이션이 몇 배나 느리게 '보일 수도 있습니다'.
첫째, 스윙과 같은 GUI 툴킷은 플랫폼 독립성을 유지한다는 이유로 고도의 추상화를 사용하고 있습니다. 즉, 거치는 과정이 많다는 것이죠.
게다가 OS의 지원도 상대적으로 적게받기 때문에 영점 몇 초 정도의 성능차이가 발생할 수 있습니다. 하지만 그 정도라면 충분히 사용자의
눈에 띄고도 남는 시간이죠. 수치상으로는 적을지도 모르지만 사용하는 입장에서는 몇 배나 느리게 '보입니다'.
해결이 가능하지만 신경쓰이는 문제입니다. 귀찮다면 SWT와 같은 가벼운 GUI 툴킷을 사용하면 그만입니다.
둘째, 제대로 자바 언어에 대한 이해없이 동기화를 남용하거나 지나친 객체 설계로 인한 GC의 오버헤드 발생, 애시당초 성능은 고려하지도 않고
만들면서 무조건 '이건 내가 잘못한게 아니라 이게 원래 느려서 그래!'라는 변명 등... 오로지 학습만이 해결할 수 있습니다. -_-;;
셋째, JIT 컴파일러의 준비시간 및 제한된 자원에서의 JVM 구동 등은 어플리케이션의 성능과는 관련없는 소요시간이지만 사용자 입장에서는
충분히 '이거 왜 이렇게 늦게시작해! 느려터졌구만!'이라고 말할 수 있겠죠.
다시금 다른 분이 말씀하셨던 부분을 강조해야겠군요.
'자바 가상머신(JVM)의 발전으로 그다지 느리지않거나 일부 영역에서는 자바가 빠른 경우도 있다'
라고 말이죠. 하지만 그럼에도 불구하고 JVM이 C/C++로 작성되어 운영체제 위에 몇개의 추상레이어를 덧붙여 돌아가는만큼 발전에 따라
한없이 동일한 성능에 가까워질 뿐이지 기계어로 컴파일된 프로그램과 완전히 동일한 속도를 낼 수는 없습니다. 그래서 자바는 느립니다.
그리고 자바 프로그래머는 누구나 알고있습니다. JVM의 한계를 말이죠 (JVM이 몽땅 어셈으로 작성되었으면 좋겠습니다)
자바 느리다는 사실은 누구도 부정하지 않습니다. 대부분 자바가 빠르다라고 말하는 사람들은 자바가 C/C++ 보다 빠르다거나 동일한 성능을
낸다고 말하고 싶은게 아닙니다. 실제로 성능은 어떤지도 모르고 무조건 '몇 배나 느리게 보이니까' 곧이곧대로 '당연하지 이건 원래 느려'라고
생각하는 사람들의 '고.정.관.념'입니다.
페이지를 완전히 로딩하기전에 미리 보여주는 걸로 웹 브라우져가 빠르다고 생각하십니까?
만약 미리보기 없이 페이지를 완전히 로딩하고 나서야 화면에 출력해주는 웹 브라우져가 있다면 그게 일반적인 웹 브라우져보다 약간 더 빠릅니다
하지만 수치상으로는 빠를지 몰라도 당장 눈 앞에 결과가 없으니 '느리다'고 생각할 겁니다.
자바가 몇 배나 느리다는 말은 '내가 경험한 바로는 8배 느려'가 아니라 '8배나 느린 것 같아'가 정확합니다.
수치로 재보기 전에는 누구도 얼마나 느린지 판단할 수 없고 인간의 시간 감각은 아주 쉽게 속.아.넘.어.갑.니.다.
저는 자바를 좋아하지만, 다른 사람이 자바가 느리다고 말해도 좋습니다. 사람을 사귈때 외모만을 보지않듯이 언어의 성능만을 보면서 사귀지는
않습니다. 하지만 제발 그렇게 말하기 이전에 고정관념부터 버리십시오. 느리다고 말해도 좋지만 '이건 원래 2배나 느려'라는 건 바람직못한
태도입니다. '원래 그런 것은 아무것도 없기' 때문입니다. 다음부터 제게 말하실 때는 '재보니까 이건 2배나 시간이 들더라'라고 말해주십시오.
그러면 저는 거기서 '어떤 부분이 최적화가 덜 되었는지' 공부할 수 있을테니 감사히 듣겠습니다.
자바보다 개발에 편리한 문법이나 어떤것에대해서 : 그런것없어도 충분해
자바에만 있는것들 : 이것이 있기때문에 우리가 월등해..
자바보다 느린 언어에대해서 : 저언어는 느려서 못쓰지..
자바보다 빠른언어에 대해서 : 빨라봐야 소용없어 이정도면되..
매우 자기합리화이며 자기 변호적인 이라고 생각지 않으신지..
냉정하게 객관적인 판단을 하려하지 않는다.
일단 속도에관해서 벤치마크라해서 일부특수한경우를 테스트한부분,
그것도 대부분 잘못된테스트 컴파일옵션을 제대로 안주었거나
소스가 동일한 동작을 하는것이 아니거나.. 하드웨어의 지원이 한쪽은 되고 한쪽은 안되는
혹은 신기술을 한쪽만포함하는 테스트를하고 그것을 믿고 싶어하한다.
또한 그것으로 오직 자신들의 방패막이로 사용하진 않으셨는지..
그리고 개발이나 유지보수가 좋다는 막연한 감언이설을 스스로 받아들여 믿고 있다.
따져보면 과연무엇이 유리한지도 알수 없는지경이며 실제론 더불리하다는걸 알수있음에도 그를 부인한다.
혹은 자바에만 라이브러리가 있으며 다른언어에는 그런것이 있으리란 생각조차 하기 싫어하진 않으셨는지...
또한 침소봉대하는경향이 있다.
아주작은장점이 있을수 있으나 매우크게 침소봉대하지 않으셨는지...
일단 성능개선이란면에서도 볼때 작은효과 오히려 때에따라 역작용이 발생할소지도있는 그러한걸 절대적이라믿으며
그것으로 모든것이 해결된양 생각하며 또한 그렇게 말한다.
실제 성능을 비교해보면 매우 미약함을 알수있다.
C보다 개발에 편리한 문법이나 어떤것에대해서 : 그런것없어도 충분해
C로만 되는것들 : 이것이 있기때문에 우리가 월등해..
C보다 느린 언어에대해서 : 저언어는 느려서 못쓰지..
C보다 빠른언어에 대해서 : C보다 생산성이 떨어져..(어셈블리)
매우 자기합리화이며 자기 변호적인 이라고 생각지 않으신지..
냉정하게 객관적인 판단을 하려하지 않는다.
일단 속도에관해서 벤치마크... 일부특수한경우라고 믿는다.
그것도 대부분 잘못된테스트 컴파일옵션을 제대로 안주었거나
소스가 동일한 동작을 하는것이 아니거나.. 하드웨어의 지원이 한쪽은 되고 한쪽은 안되는
혹은 신기술을 한쪽만포함하는 테스트를하고있다고 하고 그것을 믿고 싶어하한다.
또한 그것으로 오직 자신들의 방패막이로 사용하진 않으셨는지..
그리고 C역시 개발이나 유지보수가 좋을수 있다는 막연한 생각을 스스로 받아들여 믿고 있다.
따져보면 과연무엇이 유리한지도 알수 없는지경이며 실제론 더불리하다는걸 알수있음에도 그를 부인한다.
혹은 C로만 가능한 것이 있으며, 다른언어에는 그런것이 있으리란 생각조차 하기 싫어하진 않으셨는지...
또한 침소봉대하는경향이 있다.
아주작은장점이 있을수 있으나 매우크게 침소봉대하지 않으셨는지...
일단 성능개선이란면에서도 볼때 작은효과 오히려 때에따라 역작용이 발생할소지도있는 그러한걸 절대적이라믿으며
그것으로 모든것이 해결된양 생각하며 또한 그렇게 말한다.
실제 성능을 비교해보면 매우 미약함을 알수있다.
일부를 보고 모두가 그렇다고 생각하시는 건 아닌지요. 그리고 무엇보다 이런 상대방을 공격하는 듯한 글은 아무것도 얻을 수 없습니다.
그리고 무엇보다 그런 점에 대해서는 반박할 수 있습니다.
자바보다 개발에 편리한 문법이나 어떤것에대해서 :
그루비(Groovy)가 있습니다. 루비와 같은 동적언어에서 제공해주는 매력적인 기능들을 정적 언어인 자바에서 사용하기 위해서 만들어진
스크립트 방식의 언어입니다. 클로져, 프로퍼티, 동적 타입검사 등의 주요 기능들은 자바보다는 차라리 타 언어에서 가져온 것들이 더 많습니다.
물론 문법상으로는 비슷하지만 이것들은 자바보다 개발에 편리한 문법이나 어떤 것을 자바에서도 쓸 수 있기를 바라며 만들어진 언어입니다.
물론, 오픈소스 프로젝트이므로 기여하고 싶다면 얼마든지 참가할 수 있습니다.
자바에만 있는것들 :
자바의 이념은 말그대로 '모든 플랫폼에서의 코드 재사용'이라는 프로그래머의 이상에서 출발했습니다. 너무 이상적으로 들릴지도 모르겠지만,
그 이상을 포기하지 않음을 자랑하는게 뭐가 이상합니까? 자바 프로그래머의 이상은 '언어'에 얽매여있는게 아니라 궁극적으로는
'Write Once, Run Anywhere'로 표현됩니다. 개발자라면 모든 언어, 환경을 막론하고 모든 환경에서의 코드 재사용에 대한 열망을 비난할
수는 없을 겁니다. 차라리 '그건 불가능해. 그런 걸 시도하다니'라고 비웃으면 몰라도 말이죠.
자바보다 느린 언어에 대해서 :
Java6 부터는 JVM에서 스크립팅 언어 엔진을 포함할 수 있습니다. 기본적으로 자바스크립트 엔진이 내장되어 있습니다. 만약 느린 언어라서
못쓴다고 생각했다면, 굳이 자바플랫폼에 스크립팅 환경을 넣을 필요가 있었을까요. 애시당초 자바가 느리다고 평가받는 상황에서 자바보다
느린 언어에 대해서 '못쓴다'라고 평가하는 경솔한 자바 개발자는 없습니다. 애시당초 자바가 그렇게 취급받고 있잖습니까.
자바보다 빠른언어에 대해서 :
우리나라에서는 관심이 부족합니다만, 자바의 퍼포먼스 튜닝에 관한 열망은 여타 언어보다 더 강합니다. 태생적으로 속도의 한계를 느끼니까요.
외국의 퍼포먼스 튜닝에 관한 원서나 사이트를 찾아보시죠. 애시당초 '이 정도로 충분해'라고 생각하는 개발자는 언어를 막론하고 기본이 잘못된
겁니다. 프로그램은 진화합니다. 충분하다는 것은 말 그대로 개발자로서의 정체를 뜻하는거죠.
그리고 '침소봉대'라거나 '실제 성능을 비교해보면'이라는 부분에서 아무런 근거가 없는 것은 글전체를 무조건적인 비난으로 만들고 있습니다.
'감언이설을 스스로 받아들여 믿고있다'는 것은 상대방이 '아무런 생각이 없다'는 뜻과 동일합니다. 이런 글은 아무런 이득도 없을 뿐더러
보는 이의 기분을 상하게하고 스스로의 품격을 떨어뜨리는 것 입니다. 왜 비판이 아니라 비난을 자처해 스스로의 품격을 떨어뜨리십니까?
아, 그리고 하나 더하자면... 정체된 믿음과 절대적인 신용은 신념을 퇴락시킵니다. 특정 종교에 대해 '무조건'이라고 말하면서 다른 종교는
무시하는 분들이 대표적인 예죠. 하지만 끝없이 다른 의견을 받아들여 자신의 신념을 시험하며 지켜나간다면 그것은 인간을 강하게 만듭니다.
모든 선각자들이 예외없이 '미쳤다'는 소리를 들었습니다. 광신자라고 해도 좋고 미쳤다고 해도 좋습니다. Write Once, Run Anywhere로
표현되는 코드 재사용을 통해서 코드를 예술의 경지로 끌어올릴수만 있다면 미친들 어떻습니까. 개발자로서 완벽한 프로그램을 만드는 것보다
중요한 건 없습니다. 제게 자바는 그런 의미에서의 도구입니다.
또 혹시나 싶어서 한자리수 줄인 n을 절반으로 또 줄여서 call 방식을 다시 측정해 보았다.
결과 :
VC : 3초
Java : 2초(1734 miliseconds)
결론 : 비교문이 Inline되었을때는 C가 근소하게 빨랐다.
하지만, 비교문을 함수/메소드 호출로 바꾸고 나서 C는 함수 호출 비용 그대로 비례해서 느려진 반면, 자바는 실행시간 최적화를 통해 훨씬 빠르게 동작함을 확인할수 있다.
ps. 처음에 쓰신분 JDK 1.6을 설치하시고 프로그램 실행시키실때 -server 라는 옵션을 주고 다시한번 테스트 해주시겠습니까?
java -server HelloWorld 같은 식으로 말입니다.
Path에 JDK가 않잡히고 JRE가 잡히신 분이라면 -server 옵션이 않먹을수가 있는데요, 그럴때는 JDK\bin\java 로 JDK가 설치된 디렉토리의 java.exe를 사용하시면 됩니다.
자바에서는 사용환경에 따른 최적화 방식이 다른 Hotspot 엔진이 있습니다. 보통 client/server 두개의 엔진으로 구분되며 성능적으로는 server가 더 우월한 엔진입니다. cc로 컴파일 하실때 -O3로 최적화 옵션을 주신 것처럼, 자바에서 더빠른 실행을 원할때는 server hotspot 엔진을 사용하죠.
ps2. 가급적이면 테스트 환경도 같이 기술해주시면 다른 분들에게도 참고가 될것입니다 ^^
$ gcc -O3 sp.c
$ ./a.exe
33
$ gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C : case 1과 case 2의 결과가 동일한 33초가 나온결과로 보았을때, gcc 3.4.4 의 -O3 옵션은 calc의 내용을 inline 시켜서 컴파일을 수행을 시킨다고 보입니다.
따라서 결과는 성능을 C를 100%로 보았을때
Case 1일때 자바 103%, Case 2일때 자바 92%정도의 성능을 보여주는 것으로 나오네요.
참고로 최초 JVM 구동시 가상머신 자체의 오버헤드가 발생할 수 있습니다. (JVM 자체의 작업을 위해 쓰레드를 사용하므로
실행시 메인쓰레드의 실행이 지연된다는 뜻입니다) 하지만 의도하신게 '순간 느리다'는 것은 아닐테니 오버헤드로 인한 지연은
제외시켰습니다. 즉, 위 코드를 10회 테스트하여 평균값을 냈습니다. 똑같은 코드인데 GCC로 컴파일한 제 PC에서 3초가 걸린 작업이
8초가 걸리는걸 보니 테스트 환경이 좀 좋지못한 것 같군요. 테스트 환경을 좀 밝혀주셨으면 합니다. 그래야 공정하겠지요?
하지만, 설사 스크립트 언어라고 해도 소요되는 시간은 대부분 파싱에서 오지 연산에서 오지 않습니다. 요즘의 CPU나 램, 메모리의
속도는 반복문과 같은 단순 연산에서 엄청난 오버헤드가 있지않는 이상 그게 어떤 언어라도 차이를 무시할 정도로 빠릅니다.
그리고 제가 위에서 언급했듯이 프로그램의 성능저하는 메모리 영역에서 일어나지 않습니다. 이런 코드의 성능은 어떤 언어라도 큰
차이를 보일 수 없습니다. CPU와 메모리의 속도가 너무 빠르기 때문이죠. 설령 스크립트 언어라도 '파싱'에 소요되는 시간을 제외하면
C와 차이가 안 날 겁니다. 이런 테스트는 실질적으로 자바가 빠르다거나 느리다는 것 중 아무것도 증명할 수 없습니다.
자바나 GCC 모두 디폴트로 포함되는 옵션 이외에는 아무것도 붙이지 않았습니다. 그게 일반적이라고 생각되서 말이죠.
하긴, 컴파일 옵션에 따라 결과가 달라진다면 그것도 흥미로운 얘기죠. 구체적으로 어떤 환경에서 어떤 옵션으로 테스트하셨습니까?
테스트를 재현하기 위한 정보가 부족하군요.
아, 그리고 가능하면 로그인을 좀 해주시면 안될까요? 익명이면 누구하고 얘기를 하고있는지, 누가 누구를 사칭해서 말하는건지 전혀
알 수 없습니다.그리고 답변을 간단하게 하시는건 괜찮지만 필요한 정보 정도는 좀 알려주셨으면 합니다. 테스트 환경이나 컴파일러, 기타
옵션 등이 없으면 정확하게 테스트를 재현할 수가 없고 결과에 차이가 있어도 왜 차이가 났는지 추측할 수가 없습니다.
저는 여기서 자바가 낫냐, C/C++이 낫냐는 케케묵은 유치한 논쟁을 하자는게 아닙니다. 가능하면 객관적인 방법으로, 자바가 느리다는 것이
편견인지 아니면 사실인지, 사실이라면 어떻게 그걸 알아낼 수 있을 것인지, 사실이 아니라면 어느정도가 사실이고 어느정도가 사실이 아닌지
가벼운 마음으로 '가지고 놀아보자'는 얘기입니다. 논쟁보다는 그 편이 더욱 흥미롭지 않습니까? 저는 그게 더 흥미롭군요.
여기서 안된다면 따로 C/C++에 자신있는 사람을 구해서라도 실험해봐야겠군요. 음... 재밌을 것 같군요.
C++ 실행시간이 평균 3초에서 1초로 단축되었습니다.
그렇다면 님 PC에서의 C++ 8초, 자바 17초의 결과도 이상한 일이 아니군요.
하지만 좀 맘에 걸리는 부분은... 저는 제 컴퓨팅 환경이 그다지 좋다고 생각하지 않습니다. (셀 2.0 -> 2.2 오버, 512MB PC2100)
433Mhz에서 셀2.0으로 업그레이드를 한지 한 5년정도 되었습니다. 즉, 5년전 컴퓨터를 아직도 사용하고 있는데... 제 컴퓨터에서 1초면
끝나는 작업이 님의 테스트 환경에서는 8초나 걸리는군요.
1초와 2.6초의 차이는 1.6초입니다. 그 정도의 차이는 사용자에게도 용인될 수 있는 정도입니다. (루프를 10억번이나 돈 걸 감안하면...)
하지만 8초와 17초의 차이는 무려 9초. 이건 사용자가 기다리다가 컴퓨터를 던져버릴 정도의 차이입니다. 이런 환경에서는 자바 어플리케이션
못 씁니다. CPU 사양이 낮은 걸로 보이는데 그렇다면 램도 넉넉치 못할테고, JVM 같이 기본적으로 메모리를 많이잡고 들어가는 프로그램은
스왑의 원인이 될 수도 있으므로 이런 환경에서 자바를 사용한다면 도구를 잘못선택한 겁니다.
뭐, 굳이 '수치상으로는 어차피 2배 아니냐'라고 말하신다면 더 이상 할 말은 없습니다.
지금의 컴퓨팅 환경이 과거와는 비할 수 없을 정도로 발전되었다고 해도 아직 셀러론 2.0 이하의 컴퓨터를 쓰시는 분들도 있으니까요.
하지만 저 2배라는 수치가 듀얼코어가 보편화되고 512MB는 기본인 요즘 컴퓨팅 환경에서도 그렇게 빛나는 수치인지는 의문입니다.
똑같은 2배라도 1초와 2초의 차이는 용납되지만 5초와 10초의 차이는 사용자 입장에서 용납할 수 없기 때문입니다.
실제적으로는 테스트 코드처럼 극단적인 반복문을 돌 필요가 없으니만큼 이것이 실제적인 자바 어플리케이션에 있어서 '몇 배나 느리다'라고
말할만한 근거로는 불충분하다고 생각합니다. 하지만 C/C++의 최적화 옵션을 고려하면 예상보다 차이가 벌어진다는 것은 잘 알겠습니다.
음, 그런데 실례가 될지 모르겠습니다만... 자바로 만든 프로그램을 돌리기에 저 테스트 환경은 (상대적으로 추측컨대) 너무 열악한게 아닌가
싶습니다. 저런 환경에서는 제 아무리 최적화를 잘해도 실제로 쓸만한 자바 어플리케이션이 나올 수가 없겠군요. 1990년 후반에 자바가 처음
나왔을 때 엄청난 비판을 받았습니다. 당시의 컴퓨팅 환경은 지금와서 보면 최악, 네트워크 속도도 최악... 자바의 추상화는 시스템에서 감당할
수 없을 정도의 복잡함이었죠. 지금 굳이 그 당시의 환경까지 고려해서 프로그래밍을 할 필요가 있을런지요?
위에 테스트 코드 3개를 모두 해봤습니다. 환경은
CPU Intel P4 3.0GHz
memory 1.5GB
Windows XP, SP2
Java SE 1.6과 VC++ 2005을 사용하였습니다.
C++ 코드는 elapsed time을 msec 단위로 출력하도록 하고
계산 결과도 같이 출력하도록 하였습니다.
물론 서버 핫스팟을 사용하면, C의 컴파일 옵션처럼 구동시간이 길어지는 대신에 런타임 실행시간은 줄어들겠지요.
하지만 최종사용자에게 JRE 보다 용량이 큰 JDK를 설치하도록 강요할 생각도 없을 뿐더러, 특별한 경우를 제외하고 성능을 빠르게 해주자고
프로그램의 안정성을 떨어뜨려서 줄 수는 없습니다.
아직까지 첫번째 질문의 요지가 논점에서 살아있는지는 잘 모르겠습니다만, 대부분 자바 프로그램이 느리다고 지적받는 부분은 서버가
아니라 클라이언트 쪽입니다. 초기 자바의 '무조건 느리다'는 편견이 팽배한 것도 실제적으로는 잘 쓰이지않고 있는 클라이언트 쪽이구요.
서버가 아닌 클라이언트에서 대부분의 일반적인 자바 어플리케이션은 서버 핫스팟을 사용하지 않습니다. 그러니 일반적인 사용자가
'자바는 느리다'라고 느낄 때의 환경, JRE의 클라이언트 핫스팟에서의 디폴트 옵션으로 테스트를 해야한다고 생각합니다.
'C는 최적화 옵션을 붙이고, 자바는 안 붙이고 실행하면 그건 불공평하지 않느냐'라고 생각될지 모르지만, 실제로 사용자들이 사용하고
있는 환경이 그렇다면 그렇게 비교를 해야 현실적인 비교가 됩니다. C 컴파일러가 최적화 옵션을 붙여서 컴파일 했을 때 핫스팟과 마찬가지로
약간 불안정하다고 알고있습니다만, 일반적으로 그렇게해서 배포한다면 그게 기준이 되어야겠지요. 자바 어플리케이션은 C 어플리케이션에
비해 배포의 불편함이라던가 실행시 옵션을 더한다던가 JVM 자체의 안정성을 떨어뜨린다던가 하는 문제 때문에 일반적으로는 서버 핫스팟을
고려하지 않습니다. 그렇다면 그걸 기준으로 해야하지 않겠습니까.
벤치마킹은 지금까지 많이도 나왔습니다. 가능하면 '실제 배포하고 사용자가 사용했을 때' 어떤 차이를 보이는지 알아보는게 낫지않을까요?
최종 배포시에 '순수한 언어의 성능'은 중요하지 않습니다. 오로지 사용자의 눈에 보여질 성능만이 중요하죠.
윈도우용 JRE에는 Server hotspot이 포함되어 있지 않지만, 솔라이스용이나 리눅스 용에는 포함되어 있늘 것으로 알고 있습니다.
다만, 자바의 client hot spot은 Swing 어플리케이션등 실행패스의 변화가 빈번하게 일어나는 코드에 적합한 엔진입니다. 다이나믹한 환경에 최적화 되어 있는 거죠.
server hot spot은 동일한 실행패스를 자주 실행시키는 서버 어플리케이션에 최적화 되어 있고요.
유저 입장에서의 성능이 중요하다라는 것은 동의 합니다.
그렇다면, 사용자는 어떤 것을 보게될까요? 실질적으로 보았을때 자바로된 GUI 어플리케이션 보다는 웹어플리케이션을 더 많이 보고 있을겁니다. 웹어플리케이션 서버는 무조건 server hotspot이니까 Server hotspot을 더 많이 보고 있을 겁니다. 그렇다면 server hotpot을 이용하는게 더 현실적 아닐까요?
어떤 익명분은 C 소스를 컴파일 할때 옵션을 주는 건 당연하다고 하셨습니다. 왜 C는 최적화 옵션을 주는게 당연하고,자바는 아닐까요? 마찬가지로 자바에서 어플리케이션의 용도에 따라 hotspot 엔진을 선택하는 것 역시 당연한 겁니다.
각각의 언어/기술은 나름대도 장점과 단점이 있습니다.
그리고 각각의 언어/기술은 자신들의 장점을 강화하고 단점을 보완하기 위해 많은 노력들을 기울여 왔죠.
벤치마크란 쉽게 이야기 하면 그런 노력들을 객관적으로 평가해보기 위한 주관적인 노력입니다.
youbit님이 말씀하신대로라면 "눈에 보이는 성능"만이 중요하다면, 최신의 하드웨어의 성능을 극한으로 뽑아내는 게임들을 만드는 언어가 제일일껍니다. youbit님의 보시는 유저는 PC에서 직접 돌아가는 프로그램을 사용하는 유저이니까요.
하지만, C/C++을 기상청의 핵심 연산 프로그램을 위한 언어로 사용하지는 않습니다. 무조건 포트란이죠. 연산속도가 8~16배정도 차이 나는데 당연한 거죠. 그럼 기상청의 해당 프로그램을 사용하는 유저도 "눈에 보이는 것"을 기반으로 성능을 생각해야 할까요?
각각의 언어/기술이 서로 환경이 다른데 가급적 동일한 환경을 구성하려는 노력은 필요하겠지만 완전히 동일한 환경은 만들수가 없습니다.
그러니 현재의 이슈, 주어진 코드를 기반으로 각 언어에서 어느정도의 성능이 나올까? 이런 테스트에서 고려/무시해야 되는 것은 무엇일까? 또 다른 코드를 테스트할때는 어떨까? 이런 논의가 될수 밖에 없는 겁니다.
어플리케이션의 용도에 따라서 핫스팟 엔진을 선택하는 것은 물론 맞는 말씀입니다. 상황에 따라 맞는 옵션을 주는 것이 당연하지요.
제가 의도하는 바는 일반적으로 '어느정도 느리다'는 것도 아닌 무조건 '느려서 못써먹어'라고 평가받는 부분이 서버가 아니라 클라이언트
부분이기 때문에 애시당초 '순수하게 어느게 더 빠르냐'라는 유희적인 논쟁이 목적이 아닌 이상, 그렇게 평가받는 부분의 환경을 고려해서
테스트를 해야한다는 것입니다.
아쉽게도 솔리리스나 리눅스는 아직까지 데스크탑에서 주류가 아닙니다. 실제적으로 사용자들이 체감하는 것의 대부분은 윈도우에서의 성능을
말하는 것입니다. 그런 이상 아무리 '리눅스나 솔라리스에서는 다르다'라고 말해도 '그거? 느리지않나?'라는 생각 자체는 변하지 않을 것
같습니다. 웹 애플리케이션의 성능 역시 클라이언트의 성능보다 더 중요하지만 문제는 그걸 사용자들이 인식할 수 없지 않습니까?
제가 지적하는 것은 '자바는 느리다'라는 일반적인 인식에 객관성이 결여되어 있음에도 불구하고 사람들이 무조건 '자바? 그거 느리지'라고
납득한다는 것 입니다(이전에도 말했지만 얼마나 느린지는 아예 빠져있죠). 그리고 그런 인식을 전환하기 위해서는 사람들이 실제적으로
보여지는 영역에서의 성능을 객관적으로 비교할 필요가 있다는 것 입니다. 애시당초 인식 자체가 '이거 척 보기에도 몇 배는 느리잖아?
몇 배는 느린게 맞아'라는 거니까요. 저는 실제적인 성능보다 '느리다'라는 일반적인 인식 자체가 더 방해가 된다고 생각하기 때문에 얼마나
빠르냐보다는 '일반적인 인식이 얼마나 객관적이지 않느냐'에 관심이 있습니다. 애시당초 '자바가 C(or C++?) 보다 8배 느리다?'라는 질문도
그런 일반적인 인식을 근거로 묻는 것이 아니겠습니까?
그리고 화려하고 복잡해서 극한의 속도 없이는 끊겨버리는 화려한 게임이야 물론 자바로 짜면 안됩니다. 가능한지를 떠나서 그런 비효율성을
감수할 이유가 없지요. 하지만 그런 고성능 위주의 게임이 아니라면 자바로도 충분히 구현할 수 있습니다. 문제는 '자바는 느려서 안되지'라는
인식이죠.
Jake와 같은 예는 '자바가 C/C++의 몇% 따라잡았다'가 아니라 '일반적인 인식과 다르게 자바로도 충분히 이런 게임을 만들 수 있다'는 데에
의미가 있다고 봅니다. 사용자 입장에서야 80프레임이건 50프레임이건 끊기지만 않으면 문제가 없으니까요. 결국 '성능' 문제가 아니라 '인식'
문제라는 것입니다. narusas님이 말씀하시고 싶으신 것도 '자바가 C/C++ 못지않게 빠르다'라는게 아니라 결국은 '무조건 자바가 느리다'는
편견이 문제라는 것이 아닌가요? 저는 그렇게 느꼈습니다만...
언제인지는 기억이 정확히 안납니다만, 사내에서 사용되는 관리툴을 자바로 만들어서 아는 사람에게 준 적이 있습니다. 원래는 웹으로 만들어진
툴이었기 때문에 소스코드를 보고, 필요한 정보만 HTTP로 보내주면 되는 간단한 툴이었습니다. 솔직히 성능에 특별한 관심없이 대충만든 것이라
'느리다'고 불평할까봐 걱정했습니다만 문제없냐고 물어보니까 아무런 문제없다며 다른 기능을 추가할 수 있는지 물어보더군요. SWT도 아닌
스윙을 사용해 운영체제의 룩앤필을 흉내낸 것이었는데, 실제적으로 아무것도 모르는 사용자 입장에서는 기타 C/C++로 작성된 프로그램과 구분
하지 못했습니다. 겉보기가 똑같고 성능도 초단위의 눈에 띄는 차이가 아니라면 사용자 입장에서는 그게 자바냐, C냐는 구분할 필요조차도
느끼지 못한다는 말입니다.
'자바가 몇 배는 느리다'라는 말 속에는 단순히 성능의 문제가 아니라 '느려서 못 써먹어'라는 생각이 숨어있습니다. 사용자 입장에서는
'느려서 못쓴다고들 하잖아? 다들 그러니까 그게 맞겠지'라는 무비판적인 생각이. C/C++ 프로그래머 입장에서는 '역시 C/C++이 최고야'라는
우월주의가 말이죠. 그래서 '순수한 언어의 성능'의 문제가 아니라 '실제적인 사용에서의 성능'을 고려해야 벤치마킹이 의미가 있지않을까...
생각합니다.
추가 ------------------------------------------------------------------------------------------------------------
HotSpot Server Optimization 중에 'Loop unrolling'이 있었군요. 벤치마킹에 있어서 -server 옵션을 통해서 동일한 정도의 최적화를
거치는 것이 공정성에 문제가 없다는 것에 동의합니다.
제가 말하는 것은 벤치마킹을 떠나서 실제로 대부분의 C 어플리케이션이 최적화된 옵션으로 컴파일되어 배포되고, 자바 어플리케이션이 최적화
되지 않은 상태에서 실행된다면 그 상태를 고려해서 성능을 평가해야한다는 것이었습니다. 벤치마킹에 있어서는 어느 한쪽은 비효율적인 방식을
사용한다면 그건 공정한 비교가 안되겠죠.
그렇게 느린 부분도 있지만, 전체적으로 그렇게 느리지는 않습니다.
최적화된 코드를 기반으로 논의을 하고 계신데, 게임이 최적화의 대표적인 예겠죠? 그래서 스타크래프트를 예로 드셨을거고요.
실제 구현도 없는 스타크래프트 예를 드셨는데 저는 실제 구현된 퀘이크 2 vs jake2 예를 들죠
퀘이크2는 게임 프로그래머 사이에서 "프로그래밍의 신"으로 추앙 받고 있는 존 카멕이 만든 게임이죠.
http://bytonic.de/html/benchmarks.html
C로 된 원래 퀘이크 2가 245프레임인데, 자바로 된 jake 2는 260프레임 나옵니다.
코드이외의 게임 데이터는 모두 동일하고요.
제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
물론 전체적으로 본다면 C코드가 빠릅니다. 벤치마크에서 자바가 앞선것도 한 시스템에서만이고 다른 시스템에서는 10~20%정도 느리죠.
하지만 님이 말한 것 처럼 전체적으로 수백%~수천% 차이나나요? (물론 그런 차이가 나는 일부 영역도 분명히 존재할겁니다)
저 결과로 볼때 스타크래프트를 자바로 만들면 10배 느려질꺼라고 생각되세요? 자바 2D는 OpenGL을 사용하기 때문에 오히려 더 빠르지 않을까 생각됩니다만..뭐 만들어지지 않았으니 이야기꺼리가 않되죠.
뭐 제가 주장하는건 단순합니다. 자바가 전체적으로 봤을때 C보다 그렇게 느리지는 않다. 일부 영역에서는 오히려 더 빠르게도 된다. 정도 입니다.
셀수 없이
셀수 없이 많은게임과 프로그램중에.. 어쩌다가 단하나의 게임이....
그것도 수많은 사람들이 테스트한것중에.... 단한곳에서....
그것도 수많은 장비들중에.... 단하나의 장비가....
아주조금 더잘나왔다고 우기시렵니까?
사실 실제로 잘나왔을리도 없겠지만..
좀구차하지 안나요? 느린걸 느리다한들 머어떻다고 그렇게 인정하지 않으려하고.. 느려도 덜느리다느니.. 일부 어쩌다가 빠를수도 있다느니.... 왜그러세요?
그냥 내가 박지성보다 축구못한다 하면되는거지.. 아 어떤날은 어쩌다가 일부 상황에서는 내가 박지성보다 공더 잘찰수도 있다..
이런식으로 우겨봐서 머가남나여?
걍느리면 느린겁니다.
오독하고 계시네요.
그러니까 실제 퀘이크 2랑 jake 2 구해서 님 컴에서 실행시켜 보세요^^
그리고 제가 자바가 전체적으로 빠르다고 우긴적 없습니다만?
분명히 10~20%정도 느리다고 써놨는데 글을 못읽으시는 건가요?
그리고 그 수치는 절대로 수백%~수천%이 아닌 10~20%라는 것도 부인하시나요?
퀘이크가 최적화 되지 않았다고 생각하세요? 퀘이크의 소스가 커버하고 있는 영역이 극히 일부분이라고 우기시렵니까?
어시스트, 출장시간, 팀 기여도, 득점, 기타등등 오랜기간에 걸쳐 다양한 평가를 하게 되면 축구도 상당히 객관적인 측정이 가능합니다만?
>> 사실 실제로 잘나왔을리도 없겠지만..
꼭 이렇게 사실을 무시하시는 분들이 계시죠. 보통은 자기 경험에 의해 "그럴리가 없어"라면서요.
인라인 어셈을 꼬박꼬박 사용하며 프로그래밍 하면서, "컴파일러가 만들어낸 기계어가 내가 짠거 보다 나을리가 없어"라고 외치던것 처럼요.
그래서 그당시에 "컴파일러가 만든 기계어는 사람이 짠 기계어를 절대 따라올수 없다"라고 외치던 분들. 그러던 분들 요즘도 있나요?
그렇게 자기 경험만 주장하다가 결국 시대에 늦춰져서 "난 기술은 잘 모르는데"하는 관리자가 되어 가죠.
저는 그렇게 되기 싫어서 죽어라 저를 갈고 딱아서 트렌드를 따라가려고 노력하렵니다.
-- 그리고 제가
-- 그리고 제가 자바가 전체적으로 빠르다고 우긴적 없습니다만?
우겼다는 명백한 증거는 없지만
-- C로 된 원래 퀘이크 2가 245프레임인데, 자바로 된 jake 2는 260프레임 나옵니다.
-- 코드이외의 게임 데이터는 모두 동일하고요.
-- 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
위 글로 볼 때 우기고 싶어 좀이 쑤신다는 것이 역력하잖아요
그래요. 자바가 더 빠릅니다. 설령 현재는 일부에서 빠를 지라도 좀 있으면 전 부문에 걸쳐
빠르겠네요. 그 정도 되면 세상이 온통 자바일겁니다.
VM 도 자바, OS 도 자바, 게임도 자바, 워드도 자바, 자바, 자바...
그 느린 C/C++ 을 어디다 쓰나요.
데니스 리치나 스트라우스트럽 아저씨는 참 세상 물정 모르네요.
자바가 이렇게 좋은데 아직도 C/C++ 로 작업하고 있을 거 아니예요.
여전히 오독이십니다.
>> 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
>> 물론 전체적으로 본다면 C코드가 빠릅니다. 벤치마크에서 자바가 앞선것도 한 시스템에서만이고 다른 시스템에서는 10~20%정도 느리죠.
>> 하지만 님이 말한 것 처럼 전체적으로 수백%~수천% 차이나나요? (물론 그런 차이가 나는 일부 영역도 분명히 존재할겁니다)
뒤쪽글은 않읽으셨나요?
저는 자바가 빠르다고 주장하고 싶어서 좀이 쑤신게 아니라, 개발자들의 오래된 편견이 지겨울 뿐인겁니다.
뭐든지 자기 경험에 없으면 우선 무시하고 보는 그런 편견들 말입니다.
더 나은 방법, 더 빠른 개발, 더 좋은 가독성, 더 쉬운 유지보수. 고객의 요구사항 만족..
이런 지향점을 향해 나아가야 하는데,
C가 제일 빠르고 제일 쉬워요. 다른 언어는 쓰래기에요. 라고 주장하는 사람들이 지겨울 뿐인 거죠.
기술이 계속 발전된다라는 기본적인 마인드 조차 없는 사람들이 정말 많으니까요.
기술이 자기가 속한 영역에서만 발전하는줄 아는 사람들 말입니다. 다른 영역에서 발전된 기술은 무시하고 보는 사람들 말입니다.
-- C가 제일 빠르고
-- C가 제일 빠르고 제일 쉬워요. 다른 언어는 쓰래기에요. 라고 주장하는 사람들이 지겨울 뿐인 거죠.
물론 그런 개발자는 반성해야죠. 근데 혹시 '자바가 C 보다 더 빠르고(혹은 더 느리지 않고) 더 쉽다' 라는 믿음을 굳혀가는 사람들은 안지겨우신가요
-- 기술이 계속 발전된다라는 기본적인 마인드 조차 없는 사람들이 정말 많으니까요.
-- 기술이 자기가 속한 영역에서만 발전하는줄 아는 사람들 말입니다.
-- 다른 영역에서 발전된 기술은 무시하고 보는 사람들 말입니다.
지당하신 말씀입니다만 이곳도 거시기한게
-- C로 된 원래 퀘이크 2가 245프레임인데, 자바로 된 jake 2는 260프레임 나옵니다.
-- 코드이외의 게임 데이터는 모두 동일하고요.
-- 제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
자바 VM 이 260 프레임정도로 최적화 기술을 발전시켜 온 동안 C 의 최적화 기술은 가만히 있었겠읍니까.
그런 시각으로 저 벤치마킹 자료를 바라보셨어요.
그러면서 '다른 영역에서 발전된 기술은 무시하고 보는 사람' 을 비난하신다면 제 얼굴에 뭐 뱉기 아닐까요.
자바가 이렇게 발전할 때 C/C++ 진영은 도데체 뭘 하고 있었을까요.
자바의 성장을 눈치 못채고 있었을 까요. 아마 그럴 것 같습니다.
이제는 명백해졋읍니다. java 진영에 워낙 우수한 인재들이 몰려 있어
이제는 C 쪽에서 날고 기어 봤댔자 개발속도, 실행속도 등 거의 모든 면에서 java 를 못 쫒아 가네요.
승리한 자바에(아니면 조만간 승리할 자바에)축하를 보내면서
하루 속히 Java 로 Windows 를 만들어서 우리가 빌게이츠의 손에서 벗아나게 해주시면 좋겠읍니다.
그 선봉에 narusas 님의 활약 기대해 봅니다.
그런 소리 할바에는
그런 소리 할바에는
quake 소스 컴파일해서
성능비교를 해보고 결과를 올리겠습니다.
이전에 자바 프로그래머는 말만 잘한다는 글이 있던데
지금 결과를 보여주진 못하고 계속 이렇궁저렇궁 말만하는데가 어딘거 같으세요???
내일 quake2를 최신 컴파일러로 컴파일한 결과 기대하겠습니다.
혹시라도 Quake2 소스
혹시라도 Quake2 소스 못찾으실까봐 올려드립니다.
Quake2 source : ftp://ftp.idsoftware.com/idstuff/source/quake2.zip
데이타 화일은 알아서 구하실수 있겠죠??
내일 저녁까지 결과 보고 부탁합니다.
-- 그런 소리
-- 그런 소리 할바에는 quake 소스 컴파일해서 성능비교를 해보고 결과를 올리겠습니다.
그래서 좋은 소리가 나오면 좋으련만...
-- 이전에 자바 프로그래머는 말만 잘한다는 글이 있던데
-- 지금 결과를 보여주진 못하고 계속 이렇궁저렇궁 말만하는데가 어딘거 같으세요???
모르겠는데요. 근데 '자바 프로그래머는 말만 잘한다' 는 것은 확인하기 어려워도
'자바 프로그래머는 우선 말을 잘한다' 면 맞는 것 같습니다.
저 자바 프로그래 아닙니다만 ^^
자바는 할줄 알지만, 자바로 밥먹고 사는 사람은 아닌데요 ^^
밥먹고 사는건 VC입니다.
다만, 회사 여건상 이 언어 저 언어 다 건드려야 하는 입장이라서요. (사람이 없습니다 -_-;;)
그러다 보니 "어 이 언어가 언제 이렇게 까지 발전했지?" 라는 경험을 많이 한 편일 뿐이죠.
C/C++ 진영이 발전 하지 않았다는 소리는 않했습니다?
괜히 다른 언어들, JVM이니 파이썬 인터프리터니 하는 것들이 C/C++로 만들어 졌겠습니까?
C/C++은 너무 강력해져서 오히려 문제가 되는 언어인셈이죠.
정말 강력한데 그 강력함을 사용하는 코드를 만들거나, 그렇게 만들어진 (남이 만든) 코드를 읽기가 어렵다는게 문제죠.
스마트 포인터도 참 좋은데, 신입이 흉내내며 만든 스마트 포인터에서 발생한 오류때문에 2달 고생한다던지 할때면, (아 스마트 포인터 구나 그럼 여긴 문제없겠지 하고 넘어간 코드였죠)
자바나 C# 생각이 정말 간절해 집니다.
제 생각은 간단합니다.
3개월 교육받은 신입도 유사하게 만들수 있느냐? 그럼 쉬운 거고, 아니면 어려운 겁니다.
여태까지 몇 번 시험한 결과, 파이썬으로 교육 받은 신입이 가장 빨리 배우더군요.
파이썬으로 교육한 신입들이 나중에 업무가 C/C++로 넘어가도 잘하고요.
C로 교육한 신입의 성과는 보통 형편없었습니다. 어느정도 자리잡는데 1년 이상 걸리더군요.
자바는 딱 중간정도? 한 5개월정도면 어느정도 쓸만한 코드를 생산해 냅니다.
뭐 제가 교육한 신입이 그렇게 많은 것은 아니였으니 신빙성이야 떨어지겠습니다만, 제 경험으로는 그랬습니다.
이런 경험에서 "최적화는 C/C++이 최고로 할수 있지만, 그것을 제대로 수행할수 있는 사람은 정말 드물고, 키우기도 어렵다. " 라는 나름대로의 결론을 얻었지요.
그래서 평균적인 프로그래머들로 구성된 대부분의 회사에서 최적화 보다는 요구사항 만족을 최우선시 하는게 당연하고, 요구사항을 최대한 빨리 만족시킬수 있는 언어를 사용하자라는게 회사의 방침이죠. 그런 것때문에 언어를 이것 저것 만지게 되었고요.
그래도 천성이 프로그래머 인지라 성능과 좋은 디자인에 대한 욕심은 끊임없이 발생하죠. 그래서 언어간 성능 비교같은걸 꾸준하게 해오다 보니 "얼래 자바가 그렇게 느리지 않네"라는 생각을 가지게 된거죠.
그래서 스스로 여러 벤치마크나, 동일한 요구사항을 여러 언어로 구현해 보기도 하면서 현재의 자바는 C에 비해 대략 10~20% 정도 느리구나 라는 결과치를 가지게 되었죠.
물론 자바가 C에 비해 엄청 느린 부분도 있긴 하죠. 반면에 콜스택 최적화 같은 런타임 최적화로 자바가 C보다 빨라지는 영역도 있고 해서 대략 10~20% 정도라고 생각합니다.
(아 물론, QoS를 보장하는 저가형 라우터를 위한 프로그램을 자바로 짜지는 않죠 ^^)
>>"3개월 교육받은
>>"3개월 교육받은 신입도 유사하게 만들수 있느냐? 그럼 쉬운 거고, 아니면 어려운 겁니다.
C로 교육한 신입의 성과는 보통 형편없었습니다. 어느정도 자리잡는데 1년 이상 걸리더군요"
일단 어느정도 일리는 있습니다. 그러나 이것하나 생각해보시죠. C가 자바처럼 만들어도 안돌겠어요?
됩니다. 그렇게만드는데는 C도 3개월만 교육하면 됩니다. 하지만 좀더 효율적인 코드를 만들려한다거나..할때 좀더 기간이 필요하죠"
그런데 그기간이 지난 1년뒤의 모습은 어떠할까요? 자바는 전혀발전없이 1년전이나 지금이나 똑같은제자리 걸음이지만..
C는 기간이 지나면지날수록 내공이 깊어집니다. 한 5년이상되는 사람은 과연 어떤것이 쉽게 보일까요?
언어자체를 익히는데는 더걸렸다해도 이미 익힌후 써먹는데는 훨씬 유리하다는겁니다. 개발도 자바보다 C가 더쉽고요..
머 3개월된 초짜들만데리고 개발할꺼면 자바가 유리할수도? 있겠죠..(이부분도 위에말했듯이 C도 그냥 자바처럼개발하면됩니다.)
그러나 객관적으로 생각해보시죠.. 어느것이 더쉬운가..
그리고 자바는
그리고 자바는 환경적인것 공부하는데 어려움 버젼이라던가 이런거 다맞추어야되고.. 골때림...
자꾸 반복하게 되는데요..
C는 언어차원에서 무언가 만드는데 요구하는 LoC가 크다보니 뭐하나 변경하는데 고쳐야 하는 부분도 엄청 많죠.,
그 강력함이 오히려 약점으로 작용하게 된단 말입니다.
C가 메인 언어인 사람들의 특징이, low level, high performance 여기에 너무 신경쓰는 경향이 생긴다는 거죠.
물론 embedded 하는 사람들에게는 나쁜 경향이 아닙니다.
하지만 enterprise 하는 사람들에게는 나쁜 경향이라는 겁니다.
한 사람이 big picture를 완전히 파악하기도 어려운 큰 프로젝트에서 자잘한건 몽땅 언어가 알아서 해줘도 모라잘 판인데,
C 프로그래머들은 그 big picture를 잘 못보고 detail에만 집착하는 프로그램을 만들어내는 경향이 있단 말입니다. 그놈의 성능때문에.
xml, web service, distribute object access 이런거 C로 하면 LoC 자체가 엄청 커집니다. 물론 완전히 끝냈을때 성능이야 좋겠죠. 그런데 그 사이에 개발에 걸린 시간은?
그리고 요구사항이 계속 바꿀때는?
자바 프로그래머가 전혀 발전이 없다고 생각하시는가 본데, 큰 착각이십니다.
큰 SI 프로젝트에서는 C 프로그래머가 오히려 OOP를 이해 못하고, 객체지향적인 사고방식을 못가져서 프로젝트가 망한경우가 더 많아요
C 프로그래머들은 보통 2만 LoC까지는 잘 따라오다가 그 이상되면 맨날 디버깅에, 요구사항 하나 바뀌면 맨날 밤샘하면서 뜯어 고치고... 프로그래머마다 누군 포인터쓰고 누군 레퍼런스 써서 통합 에러 맨날 나고.. 코드 커지면 컴파일만 몇시간씩 걸리고.. 그러면서 자기가 맞다고 우기는건 정말 잘하죠. "왜 성능을 무시합니까!"라면서요
C로 자바처럼 개발하면된다?
실행시간 중에 네트워크에서 플러그인을 다운 받아서 프로그램 중단 없이 기능이 확장되는거 Posix C로 LoC 얼마나 나와요?
자바로는 기본 라이브러리로 짧게는 A4용지 한장 분량이면 Prototype 만들수 있는데요?
C로 멀티쓰래드 Echo 서버 만드는데 LoC 얼마나 나와요? 자바는 A4용지 한장분량이면 대부분의 구현이 나오는데요?
C로 멀티인코딩을 사용하는 여러 텍스트 파일을 읽어들여 데이터 관리해야 할때, posix 라이브러리로 해결되요?
low level 내공과 high level 내공은 서로 다르거든요? C로 할때는 low level 내공은 쌓아지지만 High level 내공을 제대로 쌓는 사람 거의 못봤습니다.
C 프로그래머들이 보통 서비스 관점을 전혀 이해 못해요.
C++했던 사람은 그나마 좀 나은 편입니다. OOP를 하다보면ㅕ, 메시징이라는 관점과 그에 따른 서비스라는 관점을 어느정도 이해하거든요.
그런데 엔터프라이즈 영역에서 서비스 관점을 이해 못하면, 진짜 C 코드밖에 못짠다고 구박받는 코드를 양산해내는 사람이 되는 거죠. 맨날 하는 이야기가 "그게 확장/변경 될일 있겠어?". 그런데 변하죠. 그리고는 밤샘 수정.
OOP가 단순히 프로그래밍 기법이라고만 생각하는 C 프로그래머도 참 많죠. 그래서 "그거 C로도 다 되!"라고 억지 주장하죠.
C로 고수가 되는데는 3년이면 되지만, OOP에서 고수가 되려면 5~6년 정도 걸리는 깊은 내공이 필요합니다.
그리고 C 고수가 OOP고수가 되는것은 거의 불가능하다고 보지만, 자바 고수가 OOP고수가 되는데 필요한 시간은 5년정도죠.
C 프로그래머는 "성능"과 "디테일 한 관리"라는 관점을 도저히 못버리더군요.
다익스트라 교수가 베이직을 배운 사람을 자기 제자로 절대뽑지 않았습니다. "베이직을 배운 사람은 프로그래머로써 팔다리가 잘린것과 다름없다"라면서요.
비슷하게 "C를 오래한 사람은, 엔터프라이즈 영역에 들어오게 하지마라."라는 격언도 있지요. 아 물론 속도를 요구하는 모듈 같은거야 시킬수 있죠. 하지만 C프로그래머들은 big picture를 이해하려고 들지를 않죠. 아니 이해를 못하죠. 자기가 가진 패러다임과 원체 다르니까.
>>C는 언어차원에서
>>C는 언어차원에서 무언가 만드는데 요구하는 LoC가 크다보니 뭐하나 변경하는데 고쳐야 하는 부분도 엄청 많죠.,
>>
>>그 강력함이 오히려 약점으로 작용하게 된단 말입니다.
착각이십니다. 약점으로 작용안하거든요? 강점이거든요.. 장점을 단점으로 억지로 끌어내리려하니 대화가되겠어요?
>>
>>C가 메인 언어인 사람들의 특징이, low level, high performance 여기에 너무 신경쓰는 경향이 생긴다는 거죠.
>>
너무 신경안쓰거든요? 아무생각없이해도 자바보다 났다는뜻이거든요? 자바랑 거의 비슷한코드도 단순언어의 선택여하에 자바보다 성능이 더잘나오거든요..
>>물론 embedded 하는 사람들에게는 나쁜 경향이 아닙니다.
>>
>>하지만 enterprise 하는 사람들에게는 나쁜 경향이라는 겁니다.
>>한 사람이 big picture를 완전히 파악하기도 어려운 큰 프로젝트에서 자잘한건 몽땅 언어가 알아서 해줘도 모라잘 판인데,
>>C 프로그래머들은 그 big picture를 잘 못보고 detail에만 집착하는 프로그램을 만들어내는 경향이 있단 말입니다. 그놈의 성능때문에.
천만에말씀.
>>xml, web service, distribute object access 이런거 C로 하면 LoC 자체가 엄청 커집니다. 물론 완전히 끝냈을때 성능이야 좋겠죠. 그런데 그 사이에 개발에 걸린 시간은?
>>
>>그리고 요구사항이 계속 바꿀때는?
자바보다 훨씬 쉽게 바뀌거든요...
>>자바 프로그래머가 전혀 발전이 없다고 생각하시는가 본데, 큰 착각이십니다.
>>
>>큰 SI 프로젝트에서는 C 프로그래머가 오히려 OOP를 이해 못하고, 객체지향적인 사고방식을 못가져서 프로젝트가 망한경우가 더 많아요
OOP 개념의 자바보다 C에먼저있었다는건 아시나요? C ->C++->자바 에게 전수해줬다해도 과언이 아니죠..
실무에서 대부분 자바하시는분이 개념을 못잡던데요..
>>C 프로그래머들은 보통 2만 LoC까지는 잘 따라오다가 그 이상되면 맨날 디버깅에, 요구사항 하나 바뀌면 맨날 밤샘하면서 뜯어 고치고... 프로그래머마다 누군 포인터쓰고 누군 레퍼런스 써서 통합 에러 맨날 나고.. 코드 커지면 컴파일만 몇시간씩 걸리고.. 그러면서 자기가 맞다고 우기는건 정말 잘하죠. "왜 성능을 무시합니까!"라면서요
보통 짜는데 C가 자바보다 더빨리짜고 디버깅이라해봐야 전체다해도 보통 하루도 안걸리거든요..
요구사항바뀌면 간단히 수정만 하면끝이거든요.. 자바하시는분들 밤샘하는거 무지많이봤어요..
>>C로 자바처럼 개발하면된다?
>>
>>실행시간 중에 네트워크에서 플러그인을 다운 받아서 프로그램 중단 없이 기능이 확장되는거 Posix C로 LoC 얼마나 나와요?
>>자바로는 기본 라이브러리로 짧게는 A4용지 한장 분량이면 Prototype 만들수 있는데요?
C로는 상용라이브러리로 한장도 안되거든요..
>>C로 멀티쓰래드 Echo 서버 만드는데 LoC 얼마나 나와요? 자바는 A4용지 한장분량이면 대부분의 구현이 나오는데요?
한장도 안되요.
>>C로 멀티인코딩을 사용하는 여러 텍스트 파일을 읽어들여 데이터 관리해야 할때, posix 라이브러리로 해결되요?
라이브러리 사용하면되요..
>>low level 내공과 high level 내공은 서로 다르거든요? C로 할때는 low level 내공은 쌓아지지만 High level 내공을 제대로 쌓는 사람 거의 못봤습니다.
둘다 더많이 쌓이거든요? 지식은 상호보완적이라고 Low 를알면 High 도 더빨리 파악되거든요?
우물안개구리처럼 하나만알고 둘을 모르는사람하고 다르죠..
>>
>>C 프로그래머들이 보통 서비스 관점을 전혀 이해 못해요.
천만에요..
>>C++했던 사람은 그나마 좀 나은 편입니다. OOP를 하다보면ㅕ, 메시징이라는 관점과 그에 따른 서비스라는 관점을 어느정도 이해하거든요.
>>
>>그런데 엔터프라이즈 영역에서 서비스 관점을 이해 못하면, 진짜 C 코드밖에 못짠다고 구박받는 코드를 양산해내는 사람이 되는 거죠. 맨날 하는 이야기가 "그게 확장/변경 될일 있겠어?". 그런데 변하죠. 그리고는 밤샘 수정.
>>
>>OOP가 단순히 프로그래밍 기법이라고만 생각하는 C 프로그래머도 참 많죠. 그래서 "그거 C로도 다 되!"라고 억지 주장하죠.
님이 몰라서 지금 어거지쓰시는거에요..
.
>>C로 고수가 되는데는 3년이면 되지만, OOP에서 고수가 되려면 5~6년 정도 걸리는 깊은 내공이 필요합니다.
이것도 어거지시고..
>>그리고 C 고수가 OOP고수가 되는것은 거의 불가능하다고 보지만, 자바 고수가 OOP고수가 되는데 필요한 시간은 5년정도죠.
자바하시는분.기본을 모르니 많이 걸리죠..
>>
>>C 프로그래머는 "성능"과 "디테일 한 관리"라는 관점을 도저히 못버리더군요.
>>다익스트라 교수가 베이직을 배운 사람을 자기 제자로 절대뽑지 않았습니다. "베이직을 배운 사람은 프로그래머로써 팔다리가 잘린것과 다름없다"라면서요.
>>비슷하게 "C를 오래한 사람은, 엔터프라이즈 영역에 들어오게 하지마라."라는 격언도 있지요. 아 물론 속도를 요구하는 모듈 같은거야 시킬수 있죠. 하지만 C프로그래머들은 big picture를 이해하려고 들지를 않죠. 아니 이해를 못하죠. 자기가 가진 패러다임과 원체 다르니까.
아마도 "까마귀노는곳에 백로야 가지마라" 겠죠...
참고로 불과 몇년전만하더라도 사람들은 "자바도프로그램이냐" 라고 했죠.. 한마디로 프로그램축에도 안껴줬어요..
그만큼 개념도 없고 프로그램같지도 않았단소립니다.
자바하시는분들
자바하시는분들 기본개념파악을 못한체 High레벨 개념만 익히려하다보니..
기본도 안되는데 파악못하는건당연하고 용어 암기수준에 불과한지식을가지고 주로 말로해요..
그러나 기본을알면 응용도문제없고 처음듣는것도 조금만 들어보면 무슨말인지 더잘알게되죠..
누가 C를 기본이라고 하던가요?
C는 로우레벨이지 기본이 아니에요.
프로그래밍을 파이썬으로 처음 배워서 자기 원하는 프로그램을 착착 만들어 내는 pythoner라던가 Smalltalker들을 못보신 모양이군요.
C에서 말하는 하드웨어나 메모리, 포인터 이런건 기본이 아니라 디테일이고요.
기본은 사람의 논리력과 표현력이죠.
자기가 무엇을 하고자 하는가를 정리해내는 논리력과
그것을 어떻게 표현하면 되는지를 잘 유추해 내는 표현력.
그래서 수학과 국어를 잘하는 사람이 프로그래밍도 잘한다는 말이 나오는 겁니다.
좋은 표현에는 불필요한 문장이 없어야 하며, 좋은 논리에는 불필요한 논리가 없어야 하죠.
그런데 C는 불필요한 문장도, 불필요한 논리도 너무 많아요. 자바도 불필요한 문장과 논리가, C/C++보다는 훨씬 적지만 불편하지 않을 정도로 적은게 아닙니다.
요즘 보고 있는 IO(http://iolanguage.com/about/ )언어나 J(http://www.jsoftware.com)언어,
또는 문법을 포스트잇 한장에 정리할수 있다는 스퀵이나,
코드가 마치 psedo code처럼 보인다는 파이썬.
이런 언어들의 깔끔한 표현력이나 논리 전개력은, 사람으로 하여금 좋은 논리와 좋은 표현을 빨리 배울수 있게 해줍니다.
그리고 좋은 논리력과 표현력을 익힌 사람에게 언어는 선택 사항일 뿐이게 됩니다.
프로그래밍 언어는 문제를 해결하기 위해 발전하는 거지, 문제를 늘리기 위해 발전하는게 아닙니다.
소프트웨어 엔지니어링은 복잡성을 관리하기 위한것이지, 복잡성을 늘리기 위해 존재 하는 게 아닙니다.
그래서
그래서 뭘만들어냈나요?
올으신 말씀입니다.
말씀이 맞는듯합니다. 아래의 답변글들이 증명하는군요. 숲을 볼생각을 안하네요.
정말로 c개발자 데리고 대형프로젝트 뛰면 큰일날듯~ 개념이 없네요.
자바가
자바가 말로떼우는데는 다 이유가 있습니다...
여우가 호랑이와 싸우는자체가 이미 명성을 얻기때문이죠..
호랑이가 넘나드는 큰산맥은 볼줄모르고 자신이 사는 조그만뒷산이 세상의 전부인양 떠들죠..
프로젝트를
프로젝트를 자바로따면 큰일날듯.. 일은안하고..입만놀리는 사람들들어와서..
서로 잘났다 입씨름하느라 프로젝트 망할듯..
망하지는 않죠,
망하지는 않죠, 여우끼리는 잘 싸우진 않으니까요.
좀 그러네요.
윗분이 10~20% 느리다고 했는데도 그러시네요.
아랫분 너무 극단적으로 말씀하시네요.
수백~수천%의 성능저하에 대해서 반론하셨는데, 딱 답글만 보고 비판하시는거 같아서 좀 그렇습니다.
경의로울 뿐입니다.
경의로울 뿐입니다. 처음 자바나왔을때 이게 뭐꼬였는데
일부에서나마 c를 앞지르고 전반적으로 10%~20%정도의 차이가 있다면
게임으로 이정도 수준이면 java gui에 응답성은 swing자체의 구조적문제점일 가능성도 있네요.
맞습니다. 그래서 SWT가 나온거죠.
물론 최근의 Swing은 많은 발전을 해서 예전과 비교할수 없을정도의 반응성을 보여줌니다.
하지만, High level 추상화를 선택한 대부분의 UI Toolkit이 그렇듯이 반응성 향상에 한계가 있죠.
그래서 빠른 반응성을 낼수 있는 low level UI Toolkit 을 지향하면서 SWT가 나왔죠.(SWT는 운영체체의 Component를 사용하여서 빠른 속도를 낼수 있게 만들어 졌죠)
그리고 SWT를 high level 추상화한 클래스로 래핑한 JFace가 나온거고요.
그래도 최근 비교로는 JDK 1.6 Swing과 SWT의 속도차이는 거의 나지 않습니다.
Swing이 내부적으로 Java2d를 드로잉에 사용하는데, java2d가 OpenGL pipeline을 기본 지원하면서 렌더링 속도가 대폭 향상되면서, 반응성도 엄청 올라갔거든요. (대충 JDK 1.5 스윙과 비교할때 30%정도 빨라졌다는게 일반적인 평가입니다)
다만 swt에 비해 스윙은 메모리를 많이 먹기때문에 ^^ SWT는 eSWT라고 임베디드 시스템에서 사용할수 있을정도로 작게 만들어지고 있으니까요.
원래 벤치마크
원래 벤치마크 의도를 제대로 읽지 않고 저것만 보고 아 그렇구나 하면 속는 부분이 많습니다.
C 코드는 약10년전 코드를 그대로 쓴것이고 Java 쪽은 SSE 등 각종 CPU 플래그 및 최신 3D 알고리즘에 기반에 "재작성" 된 것입니다.
원문도 잘 읽어보시면 아시겠지만 60% 정도의 성능이지 절대 10,20% 부족 수준이 아닙니다.
자세히 원문을 읽어보십시오.
Neogeo - Future is Now.
애초에 이분도
애초에 이분도 원문을 제대로 읽어보시지 않고 쓰셨군요
근거드신 벤치마크의 내용을 보시면
"The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java."
그리고 위의 quake2 게임은 예로 드시기가 무리인게
C 코드는 십년가까이 전에 나온것으로 3D 게임쪽 알고리즘이 그다지 발달하지 않았을 시기이고 CPU 의 각종 SSE 등의 옵션을 고려한 math lib 을 근간으로 구성하지도 않았던 코드입니다.
지금 나오는 Jake 코드는 최신 이론을 기반으로 다시 알고리즘을 편성한 게임입니다. ( 즉 아예 다른 방식으로 짠겁니다. )
(Some simple optimizations (vector arrays, optimized memory handling in loops etc.) show remarkable effect on performance and there surely is still room for further improvements. ) - 게다가 앞으로 더 개선할 사항도 있다고 합니다.
게임업계에서 일하는 사람으로썬 Java 는 정말 쓰고 싶어도 쓸수가 없는 상황입니다.
다른 제 리플글을 읽어보시면 이유를 아실 수 있습니다.
Neogeo - Future is Now.
옳으신
옳으신 말씀입니다....
이처럼 자바하시는분들.. 원리도 파악안해보고.. 말로만자꾸 떼우려하니 정말참 뭐라 할말이 없습니다.
제 글 어디도 자바
제 글 어디도 자바 하시는 분이 원리 파악도 안하고 말로 때운다고 한적은 없습니다.
다만 Jake2 예를 드신분이 원문을 제대로 읽지 않고 Java 가 게임에서 성능이 더 나오는 경우도 있다는 식으로 예를 드신게
부정확해서 정정해서 알리려는 의도로 글을 썼습니다.
저도 자바를 잠깐 만져본 수준입니다만 자바 하시는 분들중에 말로 때우는 분들은 한분도 못 봤습니다.
오히려 하이레벨한 개념에서 더욱더 이론적으로 멋지게 개발을 이끌어 나가시는 분도 있습니다.
로우레벨을 꼭 몰라도 되는 분야가 엄청 많다는 사실을 저는 주장하고 싶습니다.
더군다나 프로그래머들이 그토록 찾는 성배는 코드 재사용과 추상화 아니었습니까?
추상화가 비록 구멍을 만들더라도 추상화를 하이레벨영역에서 더 추구하는게 결코 잘못은 아니라고 생각합니다.
오히려 추상화의 구멍을 이해하는 사람은 극소수여도 상관없습니다.
추상화를 바탕으로 더욱 멋진 어플을 만드는데 신경써야할 프로그래머가 90% 이상 될 겁니다.
누구도 집을 지을 때 벽돌 굽는법부터 시작하진 않습니다.
벽돌 쌓는법 부터 시작하지요...
Neogeo - Future is Now.
옳으신 말씀입니다.
옳으신 말씀입니다.
"말로 때우는 분들은 한분도 못 봤습니다." 에만 동의 못하고 나머진 동의 합니다.
과거에 60%였고..
과거에 at least 60%였고, 0.9.2 에서 fastjogl을 이용해서 85% 수준까지 올릴수 있다고 나오죠. (Jake2 0.9.2 can achieve up to 85% of the framerate of the C version)
그후 차례대로 0.9.3, 0.9.4 에서 괄목할 만한 성능 향상을 거두었고, 여전히 빠르게 할 여지가 남아 있다고 나옵니다
제가 제시한 성능은 0.9.4에서의 성능이죠. 원문을 제대로 다시 ""읽어"" 보세요.. 에휴..
quake 2 소스는 현재의 sse등에 최적화 된 libc나 libmath를 이용해 컴파일해도 컴파일시킬수 있는 코드고, 그렇게 했을때의 결과들이죠.
그리고 jake2는 id의 quake 2엔진의 자바 포팅입니다. 새로짠게 맞긴하지만, 기본 구조나 알고리즘은 quake2와 동일합니다.
quake 2가 오래된 소스라는 건 맞는 이야기 입니다. 최신 게임들에 비교하면 많이 떨어지겠죠.
하지만 동일한 BSP나 OpenGL 코드를 기반으로 동일한 알고리즘을 가지는 jake2를 아예 다른 알고리즘을 사용하고 있다.. 뭐 부분부분 달라 졌겠죠.
하지만 제가 0.9.3 시절에 분석해본 BSP 구조등은 quake 2와 거의 유사했습니다. 아예 다른 방식으로 짠게 아닙니다. 그렇게 짰다면 기존의 quake 2 데이터들을 못사용하죠.
>> 게임업계에서 일하는 사람으로썬 Java 는 정말 쓰고 싶어도 쓸수가 없는 상황입니다.
물론 자바로 하드웨어의 성능을 극한까지 뽑아내는 게임은 만들기 어려울 겁니다. 하지만 핸드폰에서 돌아가는 수많은 자바 게임들이나,한세대 정도 전의 게임정도는 충분히 가능하다고 봅니다.http://lwjgl.org/shop.php 같은 곳을 보면 말이죠. 결국엔 자바로 게임을 만들어 본 사람이 없기 때문에 방법도 축적이 잘 않된다는 악순환적인 문제가 있지요.
물론 자바로 게임제작을 허가하는 기업이 없으니까 문제긴 하죠. 그러니 쓰고 싶어도 못쓰죠.
과거가 아니라 현재
"The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java."
과거가 아니라 현재 60% 정도 수준이고(FPS Game Java app 가 C 에 비해서 ) (어디에도 과거란 말 없습니다. 과거 시제 동사도 하나 찾아 볼 수 없는 문장에서 어떻게 과거란 논리를 끌어 들이시는지 이해가 잘 가지 않아서 일단 의문을 남깁니다. )
Jake2 에 한해서 ( 자바가 아니라 이 게임 코드에 한해서 ) 85% 란 겁니다.
누가 제대로 안읽는지 .. "에휴"는 뭔지 의문이군요... ( 남을 기분나쁘게 하지 않는 어법을 좀 더 배우셨으면 합니다. )
그리고 애초에 저 예를 든게 Jake2 같이 Java 가 C 보다 더 성능이 나오는 Case 로써 예를 드신것인데
그부분의 오류를 저는 지적하고 싶었던 것입니다. ( 벤치마커 조차 이 특정 app. 에 한해 85% 성능까지.. 라고 표현하는데 어떻게 뛰어 넘는다는건지 .. )
그리고 math lib 은 아쉽게도 직접 제작한 것을 씁니다.
아무리 C lib 이 sse2 등을 지원해도 q2 math 에서 직접 쓴 인라인 어셈 부분등에서 최적화될 여지가 굉장히 많습니다. 자세히 C 쪽 소스를 살펴보라고 권해드리고 싶군요.
BSP 알고리즘 역시 굉장히 많은 변화를 가져왔습니다. Jake2 쪽을 아는 분이 보셨는데 BSP 쪽은 더 최적화를 한 것으로 알 고 있습니다.
카멕도 당시 시절에 BSP 를 balanced tree 로 하지 못해 애를 먹었다는 이야기는 이미 흔한 가십이었죠..
( 요즘은 여러가지 기법으로 BSP 를 balanced tree 로 쉽게 구축합니다. )
한세대 전 게임을 지금 새로 제작하는 경우는 극히 드물겠지요..
핸드폰 게임 쪽에선 Java 가 C vm 기반보다 우세하다고 들었습니다.
그러나 제가 든 예는 DirectX 를 쓰는 게임을 만드는 곳에 대한 이야기 였습니다...
Neogeo - Future is Now.
핸드폰게임도 자바가
핸드폰게임도 자바가 결코 성능이 좋다거나해서가 아닙니다.
Sun 이 모바일시장에 자바기술 확산을 위해 전략적 기술제휴를 하는등 의노력으로 그쪽에 많이퍼진것입니다..
그나마 틈세를 노린거죠..
자바하시는분들 이것도 아나라고 우길지도 모르죠..
음..
글쓰는 투가 맘에 않드셨다니 죄송합니다. 다만 다시 한번 읽어 보시기 바랍니다.
The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java. In comparison with object oriented C++ Code Java would look even better
FPS가 C와 자바의 절대정 성능비교는 아니지만, C의 """최소한""" 60%의 성능을 낼수 있다. C++과 비교하면 더 좋을수 있다.
The 0.9.2 release shows a big improvent due to the new “fastjogl” OpenGL renderer.
0.9.2는 fasljogl Opengl render를 이용하여 큰 진전이 있었다.
Jake2 0.9.2 can achieve up to 85% of the framerate of the C version.
0.9.2는 C버전의 85%까지 FPS를 올릴수 있었다.
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop.
0.9.3은 주로 게임 루프에서 메모리 할당의 회수를 줄여서 갭을 더 줄여서 C버전과 성능차를 거의 줄였다.
The new release 0.9.4 brings yet another incredible performance boost.
0.9.4는 또다른 엄청난 성능 향상을 얻을수 있었다.
C 대비 각버전별 성능(제일 느린 결과/빠른결과)
0.9.1 : 53% / 70% (평균 60%정도)
0.9.2 : 80% / 86%
0.9.3 : 82% / 98%
0.9.4 : 91% / 106%
jake2는 오래전 부터 제가 트래킹해오던 사이트고, 홈페이지 관리가 잘 되지 않기 때문에 밑부분에 조금씩 추가만 되는 형태로 홈페이지가 유지되오는 사이트입니다.
60%가 처음 제시된게 0.9.1시절이였던거죠. 게다가 현재 0,9.5로 업데이트 되었는데도 불구하고 홈페이지가 아직 갱신되지 않은 상태이고요.
제가 읽어 보라고 말씀드린건, 읽고 직접 계산해보고 판단해 보시라는 것이였습니다. 문장에 %가 나온게 85까지이지만, 그 이후의 결과를 직접 계산해 보시면 알거라고 생각했는데 제가 조금 짧게 글을 쓴거 같군요.
제가 제시한 내용은 "스타크래프트를 자바로 만들면 10배는 느려질꺼다"라는 주장에 대한 반론이였습니다. 스타크래프트는 자바로 만들어 진게 없으니, 동일한 게임이 java와 C로 존재하는 quake 2와 jake2를 들었던 겁니다. 다른 벤치마크를 못믿으시니 실제 비교 가능한한 동일한 어플리케이션을 예로 들수밖에 없었던 거죠. quake 2 엔진이 오래되긴 했어도 아직 현역으로 사용되는 엔진이니까요.
제 글은 "일반론으로 자바로 게임을 만들면 10배 느릴것이다"라고 하는 주장에 대한 실제 반증을 들었던 겁니다.
"자바로 게임을 만들어도 그렇게 느리지 않다"라고 말이죠.
ps. 저야 두세대 이상 전에 게임을 만들었던( 진짜로 퀘이크 2 나오던 시절에 말이죠 ) 사람이라 그당시에 카멕이 공개한 코드 가지고 분석하던 오래된 기억으로 jake 2를 봤으니 아마 최근에 보셨다는 neogeo님의 아시는 분 말씀이 맞겠지요.
(소스들여다 보고, 유즈넷에서 검색하고 해서 어찌어찌 BSP 개념을 알아내고 좋아하던 시절이였는데요..^^ 이제는 GPG같은 책까지 번역되어서 참 접하기 쉬워졌죠. 게임 프로그래밍을 않한지 몇년 되니 다 까먹었네요.^^ 제가 게임 프로그래밍 배울때 바이블은 스트리트파이트 소스였습니다. ^^ )
ps.2 앞으로는 수사학적인 표현은 쓰지 말아야 겠네요. 은유나 비유를 쓰면 어김없이 오해를 불러 일으키는 군요..
저역시 오해가 좀 있었군요..
일단 자바가 10배 느릴것이다 라는 것에 대한 반론이라고는 생각못했습니다..
글 내용이
"제가 이걸로 자바는 전체적으로 C보다 훨씬 빠르다 라고 주장하시면 뭐라고 하실겁니까? ^^
물론 전체적으로 본다면 C코드가 빠릅니다. 벤치마크에서 자바가 앞선것도 한 시스템에서만이고 다른 시스템에서는 10~20%정도 느리죠. "
라고 되어있어서 이 예제가 C 보다 빠른 게임의 예제 라고 생각했습니다.
GPG 는 국내에서 하도 안팔려서 절판분위기에 최근 나온 6 권은 아예 번역 시도 조차 출판사에서 포기했습니다.
원서보면 되지만 번역서가 안나온다는건 상징적으로 국내에서 게임 개발서가 얼마나 안팔리는지 보여주는 예라 안타깝습니다.
각설하고 원문에 보시면 60% 가 0.9.1 시절이었다는 이야기는 어디에도 없고
저는 원문을 이렇게 해석하고 있습니다.
"현재 '적어도' 60% 정도 수준이고 특정 버젼에서 '최대 ( up to ) 85 %' 까지 나온다 "
정도로 전체글을 파악하고 있습니다.
"Jake2 0.9.2 can achieve up to 85% of the framerate of the C version. It depends on the relative performance of the CPU and GPU. "
보시면 아시겠지만 85% 가 최대로써 그 마저도 특정 cpu , gpu 상황에 한해서 그렇다는 이야깁니다.
0.9.3 은 게임의 mem alloc 을 줄여서 했다고 했는데 원래 C 의 게임 알고리즘을 개선했다는 의미인것 같습니다.
따라서 전체적으로 아직은 최저 60% 수준이 된다는게 글의 요지 인것 같습니다.
0.9.1 과거에 60% 였다는게 아니라 0.9.2 의 일부 상황에 최대 85%가 나온다는 것이고 앞으로 빨라질 여지가 있다는 것이지
전체적으로는 최저 60% 라고 먼저 위에 요약된 내용을 쓰고 앞으로 좋아질 수 있는것과 현재 더 나았던 부분을 쓴 글로 보여집니다.
0.9.2 가 fastogl 을 사용 해서 큰 향상이 있었다는 문장앞에 어떤 문장 연결 내용이 없는 걸로 보아 앞의 내용을 반박하거나 하지 않고 있습니다.
즉 자연스럽게 다음 문단도 부연 설명이 된다는 것을 알 수 있습니다.
그래서 저는 과거에 가 아니라 현재에 최저 60% 성능이라는 것이라고 말하고 싶습니다.
0.9.2 의 56 : 31 fps 만 보아도 60% 성능에 가까운 정도라는 벤치가 보이지 않습니까? ( 60% 아래 군요.. )
원래 의도대로 절대 10배 느리지 않다는건 저도 공감합니다만
아직 Java 는 퍼포먼스가 아주 중요한 이슈가 되는 게임 분야에서 쓰기는 많이 꺼려지는게 제 개인적인 생각입니다.
더구나 fastogl 이 무엇인지는 모르겠지만 opengl 버젼 역시 같은 상태에서 비교를 해야 정확한 상황이라고 생각합니다.
( native interface call 을 줄였다는데 원래 q2 에서 쓰던 opengl 과 다른 버젼인지 명시가 되어있지 않아서
아마 전체적인 성능을 놓고 평가할때 0.9.2 이상은 빼놓고 생각한 것일 수도 있습니다. )
0.9.1 은 최저 60% 도 절대 되지 못하는 성능을 보여줍니다. ( 원문이 at least 라는 표현을 쓴것에 주목하여 )
0.9.1 이 그렇다는 이야기는 논리적으로 전혀 맞지 않음을 보여줍니다. ( 절대 평균적으로 60% 라는 이야기는 없습니다. )
245 : 172 -> 70%
262 : 141 -> 53%
56 : 21 -> 37.5%
(245+262+56) : (172 + 141 + 21 ) = 563 : 334 -> 이래야 평균 60% 군요 ( at least 라는 표현과는 거리가 멉니다. 평균이라는 표현이 없었다는데 일단 주목하고 싶습니다. )
일단 원문에서 at least 라는 것이 평균적으로 적어도 60% 를 보여준다 라고 쓴 것이라면 ( 그런 뜻은 없지만 그렇게 해석을 한다면 )
왜 글쓴이가 그런 표현을 썼는지 다시 생각해 볼 필요가 있습니다.
저는 아마도 글쓴이가 fastjogl 을 쓰는 것은 퍼포먼스를 절대적으로 비교할 때 정당치 못하여 그런 표현을 한 것일수도 있습니다.
저 글이 밑에 달리는 식이라면 적어도 앞의 표현에 0.9.1 이 그렇다는 이야기가 한 마디라도 있어야 합니다.
원 저자의 의도를 물어보아야 알겠지만 아무리 저 글을 읽고 저글만으로 판단하였을땐
과거가 아니라 현재 at least 60% 라는게 저 벤치마크의 의도라고 생각합니다.
그래서 애초에 답글을 단 것입니다
Neogeo - Future is Now.
애초에..
The fps values are not an absolute performance comparison Java vs C. But they show that at least 60% of C performance are achievable with Java. In comparison with object oriented C++ Code Java would look even better
FPS가 C와 자바의 절대정 성능비교는 아니지만, C의 """최소한""" 60%의 성능을 낼수 있다. C++과 비교하면 더 좋을수 있다.
라고 시작하고 있습니다. 즉 FPS(Frame per second)를 벤치마크의 지표로 삼겠다는 이야기죠.
그다음도 지속적으로 FPS에 대한 이야기를 하고 있습니다.
The 0.9.2 release shows a big improvent due to the new “fastjogl” OpenGL renderer.
0.9.2는 fasljogl Opengl render를 이용하여 큰 진전이 있었다.
Jake2 0.9.2 can achieve up to 85% of the framerate of the C version.
0.9.2는 C버전의 85%까지 FPS를 올릴수 있었다.
0.9.2 의 성능은 벤치마크 대상이 된 시스템에서 최저 80% / 최고 86%의 성능을 내게 되었습니다.
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop.
0.9.3은 주로 게임 루프에서 메모리 할당의 회수를 줄여서 갭을 더 줄여서 C버전과 성능차를 거의 줄였다.
0.9.3의 성능은 최저 82% / 최고 98% 였습니다.
The new release 0.9.4 brings yet another incredible performance boost.
0.9.4는 또다른 엄청난 성능 향상을 얻을수 있었다.
0.9.4의 성능은 최저 91% / 최고106% 였습니다.
제가 제시한 성능은 0.9.4의 성능이라고 분명히 말씀드렸습니다.
그리고 어떻게 읽으셨는지 모르겠습나다만, at least는 최소한 이라는 의미입니다.
실제의 quake 2 소스도 동일한 CPU에 동일한 그래픽 칩셋을 사용하더라도 그래픽 카드 벤더등에 따라 성능차가 많이 있었습니다. 거기에서 at least 30 fps가 나온다.. 라고 하면 quake 2 엔진의 성능은 30 fps인가요?
저는 최소를
저는 최소를 무시한적은 없습니다 ( 적어도나 최소나 같은 의미지요 )
문제는 0.9.2 를 언급하기 전에 전체적으로 at least 60% 라는 문장을 현재형으로 썼다는데 주목하자는 겁니다.
즉 벤치마커 역시 아직 최소 60% 수준으로 보고 있는 거지요.
0.9.2 는 맨 아래 란에서 60% 아래의 성능을 분명 보였습니다. ( 최저 82% 가 아닙니다 )
원저자의 의도를 무시하고 무조건 0.9.4 로 제시를 한다는것 자체가 오류라는 겁니다.
그리고 up to 역시 최대한 이란 의미 입니다.
그리고 0.9.4 나 0.9.3 을 먼저 제시하지 않고 적어도 60% 라고 언급한것은 분명 그것이 C 와 java 를 비교하는데 적절한 대상이었기에 먼저 언급한 것이라고 봅니다.
애초에 언급하신 예인 java 가 C 의 성능에 필적한다는 논점과는 벤치마커의 의도 조차 전혀 다르다는게 제 요지였습니다.
즉 벤치마커 역시 60% 수준 이상을 보인다라고 말하는 ( 전체 논지가 분명 그렇습니다 ) 글을 가지고 증거로 삼기에
잘못된 논리라고 이야기를 한 것이지요. ( 절대 감정적인게 아니라 내용 자체가 그렇습니다. )
왜 제가 자꾸 이렇게 이야기 하냐면 저역시 저 사이트를 2004년 인가 부터 계속 봐왔습니다.
저 사이트에서 Jake2 버젼은 계속 변했지만 60% 정도의 수준이라는건 계속 그 문장 그대로 내용이 있어왔습니다.
절대로 저 벤치마크는 내용을 뒤에 추가한것이 아니라 새로운 벤치결과가 있을 때마다 내용을 다시 쓴 것입니다.
따라서 벤치마커 역시 그 문장의 의도를 그대로 전달하고 싶다는게 제 글의 요지입니다.
즉 벤치마커 조차 적어도 60%로 생각하는 C vs Java on FPS app 벤치마크를 narusas 님의 의도로 가져다 쓰는게 애초에 논리가 맞지 않는다 라는 의미입니다. ( 10~20% 부족은 아무리 많아도 20% 부족 수준이 되어야 그 수준이라고 할 수 있습니다. )
사이트 히스토리 증거는 다음과 같습니다.
제가 보기 시작한 시점이 이쯤 된것 같습니다.
http://web.archive.org/web/20041010091706/http://www.bytonic.de/html/benchmarks.html
이 벤치마크의 히스토리는 다음과 같습니다.
http://web.archive.org/web/*/http://bytonic.de/html/benchmarks.html
아무리 봐도 제가보기에 벤치마커의 의도는 fastjogl 은 C 와의 성능비교에 불합리하다는 것을 인지하는 것 같습니다.
Neogeo - Future is Now.
0.9.1 시절..에 60%라고
0.9.1 시절..에 60%라고 나옵니다..
http://web.archive.org/web/20040603004425/http://www.bytonic.de/html/benchmarks.html
0.9.4 현재입니다..
http://web.archive.org/web/20060526220020/http://www.bytonic.de/html/benchmarks.html
보시면 아시겠지만, 위쪽 3문단은
The following table shows the framerates of jake2-0.9.1. 에서 The following table shows the framerates of our Jake2 releases. 로 바뀐것과 , We have not done profiling and optimization yet.라는 문장이 빠진것 이외에는 동일합니다.
0.9.2를 볼까요?
http://web.archive.org/web/20040907190117/http://www.bytonic.de/html/benchmarks.html
Our new release shows a big improvent due to the new ?fastjogl? OpenGL renderer. The new renderer reduces the number of native interface calls. JNI calls produce a considerable overhead and were the main bottleneck in our application. Jake2 0.9.2 can achieve up to 85% of the framerate of the C version. It depends on the relative performance of the CPU and GPU
라는 문장이 추가 됩니다.
0.9.3에서는
http://web.archive.org/web/20050115033146/http://www.bytonic.de/html/benchmarks.html
With version 0.9.3 we almost closed the gap, mainly by reducing the number of memory allocations inside the game loop. But as you see the Java support for fullscreen modes is still not where it should be.
라는 문장이 추가됩니다.
0.9.4 에서는
http://web.archive.org/web/20050724012630/http://www.bytonic.de/html/benchmarks.html
The new release 0.9.4 brings yet another incredible performance boost. Some simple optimizations (vector arrays, optimized memory handling in loops etc.) show remarkable effect on performance and there surely is still room for further improvements.
라는 문장이 추가 되죠.
이렇게 보면 0.9.2 이후로는 처음 3문단은 몇년간 전혀 수정하지 않고 있는 겁니다. 고쳐지는게 아니죠. 저는 이것을 일반적인 프로그래머/엔지니어들의 특성인 문서 쓰기 귀찮아함의 결과라고 봅니다.
원 저자의 의도가 뭘까요? 전체 논지가 뭘까요? jake2가 이만큼 발전했습니다 일까요? 아니면 아직도 60%밖에 않되요 일까요?
저는 전자라고 보고 있습니다.
ps. 그리고 FPS는 최고 수치를 기반으로 벤치마킹하는게 일반적이죠.
둠3돌리면서 "제컴에서 60 FPS가 나와요~"라고 말하지, "제컴에서 제일 느릴때는 10fps에요"라고 말하는 건 자학할때나 쓰이는 방법이죠 ^^
그리고 실제로 제 컴에서 둠3돌리면 10프레임도 않나옵니다 -_-;; 그래서 아직도 카스는 그냥 카스 하지 카스 소스는 꿈도 못꾸고 있습니다.
문장이 추가가
문장이 추가가 아니라 계속 수정 상태입니다. ( 분명히 글을 조금씩 고치고 있습니다 )
그래서 60% 라는 논지를 계속 유지 하고 있습니다.
그 예로 20% 에서 60% 로 늘렸을때 분명히 수정했습니다. ( 처음 부분을 보시면 알 것입니다 .)
아무리 귀찮아도 성능에 관한 벤치글이 자신의 논지를 처음에 60%라고 쓴것을 안고칠리가 없지요.
제 생각은 여하튼 벤치마커도 여전히 60% 로 보고 있다 입니다. ( 물론 at least 입니다. )
그리고 최대/최소 프레임은 의미가 없는게 저 상황에선 하드웨어를 바꿔가면서 잰것입니다 ( 저기에 적혀있는 fps 자체가 그 머신에서 최대 혹은 평균값일것입니다. )
어느 상황에도 언어를 비교할때 같은 상황에서 비교하지 한 언어가 유리한 상황을 상정해서 비교하지 않아야 합니다.
즉 제 컴에서 제일 느릴때 이런것은 게임에서 비교할때나 쓰는 말이지 여기서는 적절하지 않습니다.
( 애초에 벤치마크 의도가 하드웨어 능력차이가 아니였으므로 .. )
여전히 벤치마커의 의도는 at least 60% 라는게 전체적인 글의 요지라고 생각합니다.
Neogeo - Future is Now.
과거에 60%였고..
과거에 at least 60%였고, 0.9.2 에서 fastjogl을 이용해서 85% 수준까지 올릴수 있다고 나오죠. (Jake2 0.9.2 can achieve up to 85% of the framerate of the C version)
그후 차례대로 0.9.3, 0.9.4 에서 괄목할 만한 성능 향상을 거두었고, 여전히 빠르게 할 여지가 남아 있다고 나옵니다
제가 제시한 성능은 0.9.4에서의 성능이죠. 원문을 제대로 다시 ""읽어"" 보세요.. 에휴..
quake 2 소스는 현재의 sse등에 최적화 된 libc나 libmath를 이용해 컴파일해도 컴파일시킬수 있는 코드고, 그렇게 했을때의 결과들이죠.
그리고 jake2는 id의 quake 2엔진의 자바 포팅입니다. 새로짠게 맞긴하지만, 기본 구조나 알고리즘은 quake2와 동일합니다.
quake 2가 오래된 소스라는 건 맞는 이야기 입니다. 최신 게임들에 비교하면 많이 떨어지겠죠.
하지만 동일한 BSP나 OpenGL 코드를 기반으로 동일한 알고리즘을 가지는 jake2를 아예 다른 알고리즘을 사용하고 있다.. 뭐 부분부분 달라 졌겠죠.
하지만 제가 0.9.3 시절에 분석해본 BSP 구조등은 quake 2와 거의 유사했습니다. 아예 다른 방식으로 짠게 아닙니다. 그렇게 짰다면 기존의 quake 2 데이터들을 못사용하죠.
>> 게임업계에서 일하는 사람으로썬 Java 는 정말 쓰고 싶어도 쓸수가 없는 상황입니다.
물론 자바로 하드웨어의 성능을 극한까지 뽑아내는 게임은 만들기 어려울 겁니다. 하지만 핸드폰에서 돌아가는 수많은 자바 게임들이나,한세대 정도 전의 게임정도는 충분히 가능하다고 봅니다.http://lwjgl.org/shop.php 같은 곳을 보면 말이죠. 결국엔 자바로 게임을 만들어 본 사람이 없기 때문에 방법도 축적이 잘 않된다는 악순환적인 문제가 있지요.
물론 자바로 게임제작을 허가하는 기업이 없으니까 문제긴 하죠. 그러니 쓰고 싶어도 못쓰죠.
점점 감정싸움 양상으로 가는듯한..
흐음, 글쎄요, 만약 JAVA가 그렇게 잘못되었다면 JAVA는 쓰이지 않았어야 하는 것이 아닐까요?
어쨌든 Vc >> Vj 인 것은 인정합니다.
흠... 필요할때
흠... 필요할때 필요한 언어를 쓰는게 제일 좋은것이라고 생각합니다.
체감상. C가 좀더 빠른것 같다고 느낍니다만, 그렇다고해서 자바가 못써먹을정도로 느리진 않다고도 생각합니다.
개발하는 사람들이 좀더 손에 익고 더 편하다고 느끼는 언어를 선택하면 되는게 아닐까요.. 절대적인 속도보다는 그런면이 유지관리같은 면에서 이익이라서 더 좋을것 같다고 생각합니다..
못써먹을정도로
못써먹을정도로 느리진않죠.. 거의 한 적게는 1~2배에서 많게는 수십배로 느려.. 사용은할수 있죠..
어차피 C를 10배 느린시스템에설치해도 사용할수 있는거나 마찬가지니까요..
그리고 유지관리가 쉽다는것도 감언이설에 불과하죠.. 전혀 쉬울것도 없고 개발에도 자바가 더어려웠으면 어려웠지 쉽지는 않아요.
간단한것개발에 엄청난 인력이 투입되는 자바프로젝트만봐두 그렇고..
그많은사람들이 제공되는 라이브러리가 제대로 없거나 오류가 있을때는 하늘만처다보고 있는것만봐도 그렇고..
전혀 아니에요..혹시 C는 라이브러리를 손수구현해야하지 않나라고 생각하시는분들이 계신데.. 제공되는라이브러리들 엄청많거든요..
그리고 설사 손수구현해야한다하더라도.. 그건매우쉬워요..대형프로젝트에서도 100명가운데 두세명만 한2주개발하면 필요한것다만들어놔요.. 97명은 그동안에 그함수를 사용한 소스를개발하겠죠.. 보통라이브러리가 더빨리나오니 전혀문제없이 들어맞죠..
그에비해 자바는 손수개발할일있으면 프로젝트 매우힘들어지죠..
그리고 만든 라이브러리에 메모리 누수 버그가 있어서..
데모하는날 프로그램이 죽어서 프로젝트가 망하죠. ^^
회사는 위약금 물고.
c는 매우안정적으로
c는 매우안정적으로 동작하기때문에 정상작동하던프로그램이 갑짜기 죽는일은 거의 없거든요..
모르니 이런소리하죠..
그러나 자바는 시연하는날 버벅거리다 뻗어버려 욕열라먹고 위약금물고 망하는경우가 있죠..
^^ 정말 학생이였군요
정말 학생이였군요?
그럼 맨날 죽은 윈도우 어플리케이션은 뭐지?
자바로 시연하는날 버벅거리다 뻗어 버린 케이스 소개좀 해줘봐요?
난 C로 된거 뻗어서 망친경우, 빌게이츠꺼 부터 보여줄거 많거든요?
큰 개발을 못해보시분이군요?
아, 이제보니 학생이시구나?
뭐 아직 잘 모르니 어쩔수 없겠네..
C로 100명짜리 프로젝트? 푸훗..
개념이
개념이 없으신분이시군요..
기본개념이 없으시니 어쩌겠어요..
말조차도 못알아먹을텐데..
왜 키보드워리어의 반응에 그리 민감한지 모르겠네요.
말도 안되는 키보드워리어의 찌질거림에
뭘 그리 진지하게 대응들을 하면서, 이런 의미없는 쓰레드를 이어가는지 모르겠네요.
논리를 비논리로 반박해버리는 저 센스를 누가 감당하겠습니다.
아무리 논리적인 얘기를 해도 이 한마디만 다 끝네요.
"그건 어거지구요."
쩝~
[Re:][Re:]그러니까 유니코드로 코드를 보여주세요.
앞쪽에 댓글을 달려고 하다가 너무 긴거 같아서 뒤쪽에 달아놓습니다.
유니코드 지원 c코드입니다.
컴파일이 안되면 libiconv를 gnu에서 찾아서 링크거세요
위 프로그램을 실행시키면 unicode.html문서가 생깁니다.
utf-8로 인코딩된 html파일입니다.
저는 기본인코딩을 utf-8로 했습니다.
자바에서는 utf-16이던가요?
멋지십니다!!
진지하게 토론 하려는 사람이 거의 없는 가운데,
이렇게 진지하게 코드 까지 제시해 주시는 harisoo님 참 멋지시네요^^ 님같은 분들이 많아야 제대로 된 토론이 될텐데요
아무튼, 자바 플랫폼 스펙에서 char은 utf-16 code unit 입니다.
다만, 이것을 지원하기 위한 자바 플랫폼의 내부적 인코딩은 UTF-16일수도 있고 그때그때 다르다가 정답으로 알고 있습니다. 내부적으로 UTF-8과 UTF-32 등 현존 하는 유니코드를 지원하기 위한 코드들이 존재했고, 혼합해서 관리하기 때문에 예전 JDK에서는 문자열 처리 성능이 많이 떨어졌었습니다.
제가 자바 내부에 대해서 말씀 드린 것은 JDK 1.3 기준이였는데, JDK 1.4인가 1.5에서 문자열 처리 루틴의 성능을 대폭 향상시켰다고 하는데, 저는 아직 검증해 본적이 없기 때문에 뭐라 말씀드리기 어렵네요. (제 업무 환경이 JDK1.3이라서요 ^^ 정확하게는 J2ME CDC 환경이었죠. )
자바에서 멀티인코딩을 다루는 방법
모든 문자열 Raw data는 결국 byte 배열로 표현이 됩니다.
파일이나 네트워크에서 InputStream등을 이용하여 byte 배열을 읽어 들이겠죠.
그리고 읽어들인 raw data를 이용해 String 객체를 만듭니다. 이때 인코딩을 명시해야되죠. (명시 않하면 시스템 인코딩을 사용합니다)
이때 내부적으로 인코딩 전환이 일어날겁니다. (겁니다라고 말하는 것은 JVM마다 처리하는 방식이 다를수 있기때문입니다)
그래서 그 다음 부터는 문자열을 java.lang.String으로 다루던가 char의 배열 또는 CharSequence 로 처리할수 있게 됩니다.
그리고 다시 raw data를 얻어 내는 것도 유사하게 됩니다. 단, 생산해낼 raw data의 인코딩이 필요하죠.
이런 변환과정이 번거롭기 때문에 Input/OutputStream 대신 Reader/Writer라는 문자열 전문 처리 클래스를 입출력에 사용하죠.
자바에서 java.lang.String 문자열은 변하지 않는 Value Object입니다.
문자열 연산을 수행하면, 새로운 문자열이 만들어 집니다.
이것은 Side effect를 제거하기때문에 오류를 줄이는데 큰 도움을 주지만, 그만큼 메모리를 더 사용한다라는 단점도 있지요.
그래서 썬에서 문자열에서 사용하는 메모리를 줄이기 위해, 각각의 문자열을 Flightweight pattern을 사용하여 캐싱합니다.
이러한 과정은 어디까지나 JVM 내부에서 동작하기 때문에, 일반적인 자바 프로그래머는 저 사실을 고려할 필요가 없지요.
이처럼 자바의 문자열 지원은 장단점이 뚜렷합니다.
많은 일을 알아서 해주기때문에 프로그래머는 좀더 비지니스 로직에만 신경쓸수 있게 됩니다. 반면에 그만큼의 메모리와 비용을 소비하게 되는 거죠.
재밋네..
우리모두 닷넷플렛폼 쓰면 더이상 언어에 대한 속도 논쟁은 없을듯.
저는 주 종목이 자바입니다. 그래서 자바가 가장 빠른 언어라고 생각합니다.
내친구는 주 종목이 c++입니다. 그래서 c++이 가장 빠르다고 생각한다고 합니다.
왜냐하면 어느게 더 빠르냐는 의미를 어느게 좋은 언어냐라고 생각하는 편견이 개발자들 머리 한구석에 자리잡고 있기때문입니다.
자바든 C/C++ 이든 evgangelist는 똑같군요.
처음 논점과는 다르게 무익한 논쟁으로 번지는 것 같아서 그냥 재미로 보고만 있었습니다만 좀 어이가 없군요.
자바는 인터프리터 언어가 아닙니다. JIT 컴파일러는 실행전 혹은 실행중에 자주사용되는 바이트코드를 기계어 레벨로
컴파일해서 캐싱하는 방법으로 수행되는데다 바이트코드 자체가 기계어 레벨의 기능을 수행하도록 설계되어 있기 때문에
일반적인 스크립트 언어처럼 파싱에 들어가는 비용이 크지않습니다. 그래서 Just-In-Time 컴파일러인 것이죠.
하다못해 스크립트 언어도 컴파일 언어와 비교했을 때 수십배 정도의 성능차이를 보입니다. 그런데 기계어 레벨로 컴파일
되어서 수행되는 언어가 수백~수천배나 느리다니요? 상식적으로 말이 안되지 않습니까.
게다가 개발자는 누구나 자신이 사용하는 도구의 장단점을 알고 있습니다. 황금 망치가 없다는 건 누구나 아는 사실입니다.
C/C++을 만지면서 메모리 관리에 신경을 쓰듯 어느정도 자바를 알고있다고 자부하는 사람들은 당연히 최적화에 신경을 씁니다.
디자인 설계부터 캐싱, 비동기화, 부분적인 JNI로 교체, 코드레벨에서의 간소화, GC를 고려한 타이밍 분배를 통해서죠.
이런 과정을 통해서 네이티브 언어와 비슷하거나 더 빠른 자바 어플리케이션이 만들어지는 겁니다. 아, 물론 이런 최적화 역시
C/C++ 프로그래머도 할 수 있습니다. 하지만 그렇다면,
'숙련된 자바 프로그래머라도 해도 숙련된 C/C++ 프로그래머가 만든 동일한 어플리케이션에 비하면 수백~수천배나 느려!'
라고 생각한단 말입니까? 분명히 말해서, 그건 상대방을 낮춰보는 '오만'입니다.
그리고 무엇보다 우스운 건, C/C++의 발전이 C/C++로 만들어진 JVM에 적용된다는 생각은 왜 못하십니까. 잘 생각해보면 JVM은
고도의 추상화 덩어리에 불과합니다. 하다못해 C/C++로 만든 스크립트 언어도 그 정도 성능차이가 나지않는데 C/C++로 만든
컴파일용 범용언어가 수백배나 성능이 느리다고요? 그게 개발자로서 납득이 가십니까? 제가 C/C++ 프로그래머 입장이라면
'그거 누가 만들었어? 바보아냐? 뭔가 잘못 만들었겠지?'라고 말해줄 것 같습니다만.
팔은 안으로 굽는다고, 편견일 수도 있습니다만 위에서 자바가 빠르다고 말씀하시는 분들 중에 '어느모로 봐도 자바가 빠르다'라고 말한 분은
없었습니다. 대개 '일반적인 관념과는 다르다'라고 주장했을 따름이죠. 일반적으로 아무런 생각없이 '자바는 느려'라고 생각하니까 '알면
그냥 생각했던 것과는 다르다'라고 말하는거지 '말도 안되는 소리마, 내 언어가 최고야'라고 말한적이 없습니다. 그런데 C/C++ 언어를 옹호
하시는 분들(최소한 그렇게 보이는)이 도대체 왜 그렇게 과장해서까지 상대를 깎아내리는 건지 모르겠습니다. 정말 진심으로 자바가 수십배~
수천배나 느리다고 생각하신다면 '인터프리터 방식인 스크립트 언어보다 못한 수준인 컴파일 방식언어' 자바의 열등함을 자료로 제시하는게
나을 것 입니다.
에휴, 아닙니다. 지금 언어의 우월함을 논쟁하자는 말이 아닙니다.
설령 언어의 우월함이라는게 있어서 어느게 최고냐고 싸우는게 할만한 일이 라고해도 그건 자신을 높여서 증명할 일이지 상대방을 깎아내려서
증명할게 못됩니다. 손에 들고 있는 도구가 맘에 들지만, 다른 도구를 들고있는 것만으로도 상대방과 싸워야한다면 그 도구를 버리는게
'프로그래머'로서는 안될 일일지 모르지만 '인간'으로는 할 법한 행동아닙니까?
자바든 C든 C#이든, 동적언어든 정적언어든, 인터프리터 방식이든 컴파일 방식이든 중요한 것은 '좋아하되 헤어나지 못할 정도가 되지않는 것'
입니다. 우리 모두 상대방 먼저 바라봅시다. 자신 먼저 바라보는건 항상 하는 일이 아닙니까?
위에글중 누구도
위에글중 누구도 자바가 수백~수천배 느리다고 한사람은 없습니다..
그저 자바가 C보다 일반적으로 느리다고 말했을뿐인데 자바하시는분들중에는 그사실을 부정하고 싶었던분들도 있었겠죠..
분명히 비슷한수준은 아닙니다 아직도 상당한 차이가 있습니다. 아직도 자바하시는분들 그걸모르고 계시죠..
자바에서는 그것을 극복하기위해서는 결국은 C/C++처럼변해야됩니다. 이름만바뀐 C/C++가 새로생기는거죠..
그러나 그건누구도 원치 않을겁니다..
그런데도 상업화때문인지 자꾸만 본질이 변해가는 자바를보면좀 안타깝습니다.
이 글타래에서..
자바가 일반적으로 C보다 느리다라는 거 부정하신분이야 말로 없습니다. 다만, 많이 빨라졌고 일부 영역에서는 오히려 빠른 결과가 나오기도 한다라고 말하고 계신거죠.
오히려 C하시는 분중에 "자바보다 100배 빨라요"라고 주장하신 분은 계십니다.
자바 플랫폼 프로그래머와 자바 프로그래머는 엄연히 구분되어야 합니다.
자바에서 성능차의 극복은 주로 JVM에게 맡겨져 있습니다. 일반적인 자바프로그래머는 유지보수하기 좋은 코드를 만들어 내고, 실제 수행 성능은 JVM에게 맡기게 되는 겁니다.
이런식으로 JVM이 발전함에 따라, 과거에 만든 프로그램이 저절로 몇십%의 성능향상을 보인다던지 하게 되는 겁니다.
언어의 발전과 플랫폼의 발전을 구분해서 보셔야 하고,
자바 언어는 주로 "편리하고 자동으로 처리할수 있게 하는" 방향으로 발전하고,
자바 플랫폼은 더 빠른 실행을 가져 올수 있는 방향으로 발전하죠.
그리고 자바의 본질은 오히려 더더욱 강력해 지고 있습니다만..
자바의 본질은 인터넷 환경에서 다양한 기기에서 한번 만든 프로그램을 제로 또는 작은 포팅과정만을 거쳐 실행할수 있는 프로그램의 제작이죠.
j2me의 엄청난 보급으로 이런 본질성은 더더욱 강력해 지고 있다고 봅니다만..
아니오. 익명으로 누군가 그렇게 써놨더군요.
일단 자바가 느립니다.
위에서 많이 안느리다고는 하나 실제로 짜여진건 밴치마크의 셈플처럼 전부 저런코드만 있는게 아닙니다.
대부분 스트링처리나 네트웍 db 그래픽 관련 인데 그런곳에서는 매우큰차이가 있습니다.
윗쪽에 스트링처리하나만하더라도 자바는 범용함수를 사용하여구현해야하는반면 c 는 그자체엔진에 적합한 맞춤형함수를
사용할수 있기때문에 성능차이는 매우큽니다. 함수하나에서만해도 수백%이상 성능차이가 나죠..
어쨋거나 전체적으로 따져보면 꽤성능차이가 납니다. 10~20% 정도가 아니고 보통 수백% ~수천% 정도 성능차가 납니다.
못믿으시겠지만 사실입니다..
단적인 예로 자바로 스타크레프트 만든다면 어찌될지...아마도 최소한 10배는 느릴겁니다.
그렇다고 자바가 전혀 쓸모 없는것이란 말은 아닙니다. 누구나 공감하듯 개똥도 약에쓸일이있다고 그리 속도가 중요하지 않은곳에 쓰입니다.
하지만 분명한건 자바하시는분들은 왜그리 속도도 빠르다고 우기시는지..그건 아니라고 봅니다.
아마도 sun 의 자신들의 자바를 홍보하기위해 내놓은 그런 말만믿고 사실믿고 싶겠죠.. 그걸그대로 말하는경향이 있습니다.
이런 말들은 과거에는 없었는데 자바가 나오면서 이런현상이 나타나는것같습니다..
역시 자바때문에 말들이 많네요...
--------------------------------------------------------------------------------------------------------------------
라고, 글타래 중에 하나가 있습니다. 보시다시피 '수백~수천%' 정도 성능차이가 나고 '개똥도 약에 쓸일이 있다'는 식으로 말하므로 '오만'
이라고 한 겁니다. 하긴, 정말로 그렇게 생각하는 사람이라면 익명으로 남길 일도 없을텐데 그냥 지나가는 소리에 어이가 없어서 좀 흥분
했군요. 죄송합니다.
제 개인적인 생각으로는 최적으로 튜닝된 자바 프로그램이 C/C++에 비해 그다지 떨어지지 않는다고 생각합니다. 여기서 떨어지지 않는다는
의미는 수치상의 문제가 아니라 '사용상에 있어서 문제가 되지않을 정도'라는 의미입니다. 물론 0.01초를 다투는 타임 크리티컬한 부문은
요구사항 자체가 시간을 포함하기 때문에 사용상의 문제가 되므로 제외하고 말이죠.
분명 자바 어플리케이션은 태생적인 한계로 네이티브 어플리케이션보다 느립니다. 문제는 '얼마나 느린가'라는 것 입니다.
많은 분들이 '상당히 느리다'라고 하시는데, 그렇다면 숙련된 자바 프로그래머와 숙련된 C/C++ 프로그래머가 있다고 가정하고, 동일한 스펙을
구현했을 때 자바 프로그램와 네이티브 프로그램의 성능차를 얼마로 보십니까? 프로파일링을 통해서 병목부분을 제거하고 멀티쓰레드로 성능을
높이고 캐싱기법 등을 통해 최종적인 튜닝을 거친 동일한 스펙의 자바 프로그램과 네이티브 프로그램의 성능차이를 어느정도로 보는지 묻고
싶습니다. C/C++로 만든 프로그램이 10초 정도일 때 자바로 만든 동일한 스펙의 프로그램이 20초 정도 걸릴까요? JIT의 특성상 시작시간이
오래걸리는 건 어쩔 수 없는 사실입니다. 그렇다면 런타임 도중에는 어떻게 보십니까?
솔직히 '자바하시는 분들 그걸 모르고 계시죠'라거나 '사실을 부정하고 싶겠지'라는 부분은 기분이 나쁩니다. 왜냐하면 그건 누구나 알고 있는
사실인데 '넌 그것도 모르지?'라는 식으로 들리기 때문입니다. 분명히 말하건대, 자바를 사용하면서 장점만 알고 단점을 모르는 사람이라면
그건 자바 프로그래머가 아닙니다. 특정 도구를 선택한다는 것은 그 단점마저도 같이 선택하는 것이기 때문입니다. 단언컨대, 자바 프로그램이
느리다는 건 모든 자바 프로그래머가 압니다. 그렇기 때문에 자바 개발자는 퍼포먼스 튜닝에 심혈을 기울입니다. 다시 말씀드리지만 C/C++
개발자가 메모리 누수에 민감하듯이, 자바 개발자는 퍼포먼스 저하에 대해 민감합니다. '그걸 모르고 계시죠'라는 말은 모든 자바 개발자를
'그렇지 않다던데? 벤치마킹도 비슷하던데, 그냥해도 되겠지'라고 생각하는 기본도 모르는 코더로 본다는 뜻으로 들려서 기분이 나쁜 겁니다.
여하튼 요지는 이렇습니다. 설계, 분석부터 튜닝에 이르기까지 모두 실무에 숙련된 자바 프로그래머와 마찬가지의 C/C++ 프로그래머가 동일한
스펙의 요구사항을 받아 프로그램을 만들 때, 그게 정말 '상당한'이라고 불릴 정도의 차이가 날 것인가? 라는 점입니다.
아 그리고 상업화에 관해서 안타깝다는 의견은 개인적으로 이해가 잘 안갑니다. 자바 플랫폼은 이미 J2EE가 오픈소스화 되어있고, J2SE가
오픈소스가 결정되었으며 J2ME도 오픈소스화 될 계획입니다. IDE는 이클립스와 넷빈즈가 있어서 사실상 언어, 개발환경부터 라이브러리,
소스코드에 이르기까지 오픈되어 있는데 상업화...라는 건 어떤 부분을 말씀하시는 것...인지? 잘 모르겠군요.
PS : 아... 수백 수천배가 아니라 수백~수천%였군요. 워낙 수치가 커서 '수십, 수백배'라고 느껴버린 모양입니다.
일반적으로
일반적으로 수백~수천% 느린거 맞습니다.
아무런 증거 없이 주장하긴 쉽겠지요?
뭐 그렇게 믿고 싶은 마음을 잘 알겠습니다만..
하다못해 제대로 된 벤치마크 자료와 이론적 근거를 들면서 느리다고 주장해주세요..
그런거 하나도 없이 주장만 하시면, 여태까지 다른 익명들과 다를 게 없으신 분으로 보겠습니다.
위에 나온글들 잘좀
위에 나온글들 잘좀 읽어보시죠..
벤치마크는 자바쪽에서 제시한것들조차 알고보니 수십~ 수백% 이상차이나는군요..
컴파일좀 제대로 하시고..벤치마킹하시길..
이런 자바성능이 그나마 잘나온 특이한 프로그램조차도 이정도니 일반프로그램들은 말해야뭣하겠어요..
눈에 뻔히 보이는것도 끝까지 아니라고 우기시네요..
자바 퍼포먼스 튜닝의 주요 관심사항은...
자바 퍼포먼스 튜닝의 기본은 파일, 네트워크, DB 액세스와 관련된 I/O 접근의 최소화 및 최적화입니다.
더 정확히 말하면 병목지점을 없애는 것이지만 상당부분이 I/O 에서 일어나므로 일반적으로 I/O를 어떻게 다루느냐가 관건이라고
봐도 무방합니다. 사실 이건 언어를 막론하고 모든 튜닝의 기본입니다.
그 다음부터는 GC에 따른 오버헤드와 같은 메모리나 비효율적인 코드의 문제로 넘어갑니다.
그런데 이런 튜닝은 I/O 만큼 눈에 띄는 성과는 없는데다가, 수많은 벤치마킹이 보여주는 '상업적인(?) 샘플코드'에서도 보듯이 루프나
메서드 호출과 같은 기본적인 사항에 있어서 C/C++과 자바의 성능차이는 없다고 봐도 무방합니다. 이건 당장 테스트 코드 몇개만 돌려봐도
간단하게 증명될 수 있는 내용입니다.
그렇다면 I/O 부분에서 수백~수천% 정도나 차이가 나느냐하면, 그럴리가 없지요. JVM의 I/O는 기본적으로 C/C++로 작성된 것인데요. -_-;;
JVM에서 네이티브 함수를 호출하는데 들어가는 오버헤드 때문에 그런 차이가 난다는 건 상식적으로 말이 안됩니다. 오버헤드가 있긴 하지만
그게 몇 배나 느리게 만든다고 말하기에는 무리가 있습니다. 90년대 후반의 초기 JVM의 성능문제도 다른 것이 아니라 인터프리팅 부분에
있었으니까요. 그래서 JIT 컴파일러가 나온다음에 상당부분 해소된 것이죠.
요약하면 다음과 같습니다.
첫째, 메모리 영역에서의 연산능력의 차이는 코드가 증명하듯이 사실상 없습니다.
둘째, 물리적 혹은 비물리적 I/O에 관계된 오버헤드가 존재하는 것은 분명하지만 그것이 몇 배나 차이를 불러오지는 않습니다. 게다가 I/O의
상당부분은 캐시나 풀링과 같은 기본적인 튜닝 기법만으로도 성능저하를 막을 수 있습니다.
하지만 그럼에도 불구하고 다음과 같은 이유로 자바 어플리케이션이 몇 배나 느리게 '보일 수도 있습니다'.
첫째, 스윙과 같은 GUI 툴킷은 플랫폼 독립성을 유지한다는 이유로 고도의 추상화를 사용하고 있습니다. 즉, 거치는 과정이 많다는 것이죠.
게다가 OS의 지원도 상대적으로 적게받기 때문에 영점 몇 초 정도의 성능차이가 발생할 수 있습니다. 하지만 그 정도라면 충분히 사용자의
눈에 띄고도 남는 시간이죠. 수치상으로는 적을지도 모르지만 사용하는 입장에서는 몇 배나 느리게 '보입니다'.
해결이 가능하지만 신경쓰이는 문제입니다. 귀찮다면 SWT와 같은 가벼운 GUI 툴킷을 사용하면 그만입니다.
둘째, 제대로 자바 언어에 대한 이해없이 동기화를 남용하거나 지나친 객체 설계로 인한 GC의 오버헤드 발생, 애시당초 성능은 고려하지도 않고
만들면서 무조건 '이건 내가 잘못한게 아니라 이게 원래 느려서 그래!'라는 변명 등... 오로지 학습만이 해결할 수 있습니다. -_-;;
셋째, JIT 컴파일러의 준비시간 및 제한된 자원에서의 JVM 구동 등은 어플리케이션의 성능과는 관련없는 소요시간이지만 사용자 입장에서는
충분히 '이거 왜 이렇게 늦게시작해! 느려터졌구만!'이라고 말할 수 있겠죠.
다시금 다른 분이 말씀하셨던 부분을 강조해야겠군요.
'자바 가상머신(JVM)의 발전으로 그다지 느리지않거나 일부 영역에서는 자바가 빠른 경우도 있다'
라고 말이죠. 하지만 그럼에도 불구하고 JVM이 C/C++로 작성되어 운영체제 위에 몇개의 추상레이어를 덧붙여 돌아가는만큼 발전에 따라
한없이 동일한 성능에 가까워질 뿐이지 기계어로 컴파일된 프로그램과 완전히 동일한 속도를 낼 수는 없습니다. 그래서 자바는 느립니다.
그리고 자바 프로그래머는 누구나 알고있습니다. JVM의 한계를 말이죠 (JVM이 몽땅 어셈으로 작성되었으면 좋겠습니다)
자바 느리다는 사실은 누구도 부정하지 않습니다. 대부분 자바가 빠르다라고 말하는 사람들은 자바가 C/C++ 보다 빠르다거나 동일한 성능을
낸다고 말하고 싶은게 아닙니다. 실제로 성능은 어떤지도 모르고 무조건 '몇 배나 느리게 보이니까' 곧이곧대로 '당연하지 이건 원래 느려'라고
생각하는 사람들의 '고.정.관.념'입니다.
페이지를 완전히 로딩하기전에 미리 보여주는 걸로 웹 브라우져가 빠르다고 생각하십니까?
만약 미리보기 없이 페이지를 완전히 로딩하고 나서야 화면에 출력해주는 웹 브라우져가 있다면 그게 일반적인 웹 브라우져보다 약간 더 빠릅니다
하지만 수치상으로는 빠를지 몰라도 당장 눈 앞에 결과가 없으니 '느리다'고 생각할 겁니다.
자바가 몇 배나 느리다는 말은 '내가 경험한 바로는 8배 느려'가 아니라 '8배나 느린 것 같아'가 정확합니다.
수치로 재보기 전에는 누구도 얼마나 느린지 판단할 수 없고 인간의 시간 감각은 아주 쉽게 속.아.넘.어.갑.니.다.
저는 자바를 좋아하지만, 다른 사람이 자바가 느리다고 말해도 좋습니다. 사람을 사귈때 외모만을 보지않듯이 언어의 성능만을 보면서 사귀지는
않습니다. 하지만 제발 그렇게 말하기 이전에 고정관념부터 버리십시오. 느리다고 말해도 좋지만 '이건 원래 2배나 느려'라는 건 바람직못한
태도입니다. '원래 그런 것은 아무것도 없기' 때문입니다. 다음부터 제게 말하실 때는 '재보니까 이건 2배나 시간이 들더라'라고 말해주십시오.
그러면 저는 거기서 '어떤 부분이 최적화가 덜 되었는지' 공부할 수 있을테니 감사히 듣겠습니다.
ㅋㅋㅋㅋㅋ
C하는 애들.
맨날 매모리 잡고 좃질하시라.
Java하는 애들은.
이미 SOA잡고 좃질하리니.
실망 이네요.. 결국
실망 이네요..
결국 이런식이군요..
ㅋㅋㅋㅋㅋ
인자는 프로그램을 만들때...
그것도 '쓸만한' 프로그램을 만들때...
역시 결론은...
Ruby가 왕이야!
자바 진영의 논리를
자바 진영의 논리를 들어보면..이런생각이 드네요..
자바보다 개발에 편리한 문법이나 어떤것에대해서 : 그런것없어도 충분해
자바에만 있는것들 : 이것이 있기때문에 우리가 월등해..
자바보다 느린 언어에대해서 : 저언어는 느려서 못쓰지..
자바보다 빠른언어에 대해서 : 빨라봐야 소용없어 이정도면되..
매우 자기합리화이며 자기 변호적인 이라고 생각지 않으신지..
냉정하게 객관적인 판단을 하려하지 않는다.
일단 속도에관해서 벤치마크라해서 일부특수한경우를 테스트한부분,
그것도 대부분 잘못된테스트 컴파일옵션을 제대로 안주었거나
소스가 동일한 동작을 하는것이 아니거나.. 하드웨어의 지원이 한쪽은 되고 한쪽은 안되는
혹은 신기술을 한쪽만포함하는 테스트를하고 그것을 믿고 싶어하한다.
또한 그것으로 오직 자신들의 방패막이로 사용하진 않으셨는지..
그리고 개발이나 유지보수가 좋다는 막연한 감언이설을 스스로 받아들여 믿고 있다.
따져보면 과연무엇이 유리한지도 알수 없는지경이며 실제론 더불리하다는걸 알수있음에도 그를 부인한다.
혹은 자바에만 라이브러리가 있으며 다른언어에는 그런것이 있으리란 생각조차 하기 싫어하진 않으셨는지...
또한 침소봉대하는경향이 있다.
아주작은장점이 있을수 있으나 매우크게 침소봉대하지 않으셨는지...
일단 성능개선이란면에서도 볼때 작은효과 오히려 때에따라 역작용이 발생할소지도있는 그러한걸 절대적이라믿으며
그것으로 모든것이 해결된양 생각하며 또한 그렇게 말한다.
실제 성능을 비교해보면 매우 미약함을 알수있다.
C광신도들의 논리
C광신도 진영의 논리를 들어보면..이런생각이 드네요..
C보다 개발에 편리한 문법이나 어떤것에대해서 : 그런것없어도 충분해
C로만 되는것들 : 이것이 있기때문에 우리가 월등해..
C보다 느린 언어에대해서 : 저언어는 느려서 못쓰지..
C보다 빠른언어에 대해서 : C보다 생산성이 떨어져..(어셈블리)
매우 자기합리화이며 자기 변호적인 이라고 생각지 않으신지..
냉정하게 객관적인 판단을 하려하지 않는다.
일단 속도에관해서 벤치마크... 일부특수한경우라고 믿는다.
그것도 대부분 잘못된테스트 컴파일옵션을 제대로 안주었거나
소스가 동일한 동작을 하는것이 아니거나.. 하드웨어의 지원이 한쪽은 되고 한쪽은 안되는
혹은 신기술을 한쪽만포함하는 테스트를하고있다고 하고 그것을 믿고 싶어하한다.
또한 그것으로 오직 자신들의 방패막이로 사용하진 않으셨는지..
그리고 C역시 개발이나 유지보수가 좋을수 있다는 막연한 생각을 스스로 받아들여 믿고 있다.
따져보면 과연무엇이 유리한지도 알수 없는지경이며 실제론 더불리하다는걸 알수있음에도 그를 부인한다.
혹은 C로만 가능한 것이 있으며, 다른언어에는 그런것이 있으리란 생각조차 하기 싫어하진 않으셨는지...
또한 침소봉대하는경향이 있다.
아주작은장점이 있을수 있으나 매우크게 침소봉대하지 않으셨는지...
일단 성능개선이란면에서도 볼때 작은효과 오히려 때에따라 역작용이 발생할소지도있는 그러한걸 절대적이라믿으며
그것으로 모든것이 해결된양 생각하며 또한 그렇게 말한다.
실제 성능을 비교해보면 매우 미약함을 알수있다.
논리가 아닌 비난은 아무것도 해결하지 못합니다.
일부를 보고 모두가 그렇다고 생각하시는 건 아닌지요. 그리고 무엇보다 이런 상대방을 공격하는 듯한 글은 아무것도 얻을 수 없습니다.
그리고 무엇보다 그런 점에 대해서는 반박할 수 있습니다.
자바보다 개발에 편리한 문법이나 어떤것에대해서 :
그루비(Groovy)가 있습니다. 루비와 같은 동적언어에서 제공해주는 매력적인 기능들을 정적 언어인 자바에서 사용하기 위해서 만들어진
스크립트 방식의 언어입니다. 클로져, 프로퍼티, 동적 타입검사 등의 주요 기능들은 자바보다는 차라리 타 언어에서 가져온 것들이 더 많습니다.
물론 문법상으로는 비슷하지만 이것들은 자바보다 개발에 편리한 문법이나 어떤 것을 자바에서도 쓸 수 있기를 바라며 만들어진 언어입니다.
물론, 오픈소스 프로젝트이므로 기여하고 싶다면 얼마든지 참가할 수 있습니다.
자바에만 있는것들 :
자바의 이념은 말그대로 '모든 플랫폼에서의 코드 재사용'이라는 프로그래머의 이상에서 출발했습니다. 너무 이상적으로 들릴지도 모르겠지만,
그 이상을 포기하지 않음을 자랑하는게 뭐가 이상합니까? 자바 프로그래머의 이상은 '언어'에 얽매여있는게 아니라 궁극적으로는
'Write Once, Run Anywhere'로 표현됩니다. 개발자라면 모든 언어, 환경을 막론하고 모든 환경에서의 코드 재사용에 대한 열망을 비난할
수는 없을 겁니다. 차라리 '그건 불가능해. 그런 걸 시도하다니'라고 비웃으면 몰라도 말이죠.
자바보다 느린 언어에 대해서 :
Java6 부터는 JVM에서 스크립팅 언어 엔진을 포함할 수 있습니다. 기본적으로 자바스크립트 엔진이 내장되어 있습니다. 만약 느린 언어라서
못쓴다고 생각했다면, 굳이 자바플랫폼에 스크립팅 환경을 넣을 필요가 있었을까요. 애시당초 자바가 느리다고 평가받는 상황에서 자바보다
느린 언어에 대해서 '못쓴다'라고 평가하는 경솔한 자바 개발자는 없습니다. 애시당초 자바가 그렇게 취급받고 있잖습니까.
자바보다 빠른언어에 대해서 :
우리나라에서는 관심이 부족합니다만, 자바의 퍼포먼스 튜닝에 관한 열망은 여타 언어보다 더 강합니다. 태생적으로 속도의 한계를 느끼니까요.
외국의 퍼포먼스 튜닝에 관한 원서나 사이트를 찾아보시죠. 애시당초 '이 정도로 충분해'라고 생각하는 개발자는 언어를 막론하고 기본이 잘못된
겁니다. 프로그램은 진화합니다. 충분하다는 것은 말 그대로 개발자로서의 정체를 뜻하는거죠.
그리고 '침소봉대'라거나 '실제 성능을 비교해보면'이라는 부분에서 아무런 근거가 없는 것은 글전체를 무조건적인 비난으로 만들고 있습니다.
'감언이설을 스스로 받아들여 믿고있다'는 것은 상대방이 '아무런 생각이 없다'는 뜻과 동일합니다. 이런 글은 아무런 이득도 없을 뿐더러
보는 이의 기분을 상하게하고 스스로의 품격을 떨어뜨리는 것 입니다. 왜 비판이 아니라 비난을 자처해 스스로의 품격을 떨어뜨리십니까?
아, 그리고 하나 더하자면... 정체된 믿음과 절대적인 신용은 신념을 퇴락시킵니다. 특정 종교에 대해 '무조건'이라고 말하면서 다른 종교는
무시하는 분들이 대표적인 예죠. 하지만 끝없이 다른 의견을 받아들여 자신의 신념을 시험하며 지켜나간다면 그것은 인간을 강하게 만듭니다.
모든 선각자들이 예외없이 '미쳤다'는 소리를 들었습니다. 광신자라고 해도 좋고 미쳤다고 해도 좋습니다. Write Once, Run Anywhere로
표현되는 코드 재사용을 통해서 코드를 예술의 경지로 끌어올릴수만 있다면 미친들 어떻습니까. 개발자로서 완벽한 프로그램을 만드는 것보다
중요한 건 없습니다. 제게 자바는 그런 의미에서의 도구입니다.
말들이 많아
말들이 많아 매우간단한 프로그램 자바와 C 를 직접테스트 해보았습니다.
사실 테스트하기전까지 동일한단순연산이라 이정도까지는 거의 차이나지 않을것이라 생각했습니다.
그러나 놀랍게도 예상외로 상당한 차이가 있었습니다.
아래를 직접보세요..
자바코드
C코드
결과는 아래처럼나왔습니다.
Test 환경이 어떻게 되나요?
JVM 6.0 vs. VC++ in VS 2003 (WINXP)
Java
2 Elapsed time : 1187
C
time 3
-------------------------------------------
JVM 1.4.2 vs GCC 2.95.3 (Solaris)
Java
2 Elapsed time : 4706
C
time 15
java의 경우 System.currentTimeMillis() 메소드가 ms 단위의 시간을 반환하고,
C의 time()은 s 단위의 시간을 반환하므로,
윈도우즈의 경우엔 약 300%, 솔라리스의 경우에도 약 400% 정도 Java가 빠르군요..
컴파일옵션 재대로
컴파일옵션 재대로 주시고 다시돌려보세요..
유사테스트
간단한 벤치마크
익명사용자 (미확인) 씀 (일, 2007/01/07 - 6:10pm)
실행환경
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
Java Code
결과 :
VC : 31초
Java : 32453 miliseconds
2. Call function
C Code
Java Code
결과 :
VC : 62초
Java : 36172 miliseconds
결과 종합
혹시나 싶어서 n을 한 자리수 줄여서 call 방식을 다시 측정해 보았다.
결과 :
VC : 6초
Java : 4초(3938 miliseconds)
이 경우에도 마찬 가지로 자바쪽이 우세했다.
또 혹시나 싶어서 한자리수 줄인 n을 절반으로 또 줄여서 call 방식을 다시 측정해 보았다.
결과 :
VC : 3초
Java : 2초(1734 miliseconds)
결론 : 비교문이 Inline되었을때는 C가 근소하게 빨랐다.
하지만, 비교문을 함수/메소드 호출로 바꾸고 나서 C는 함수 호출 비용 그대로 비례해서 느려진 반면, 자바는 실행시간 최적화를 통해 훨씬 빠르게 동작함을 확인할수 있다.
ps. 처음에 쓰신분 JDK 1.6을 설치하시고 프로그램 실행시키실때 -server 라는 옵션을 주고 다시한번 테스트 해주시겠습니까?
java -server HelloWorld 같은 식으로 말입니다.
Path에 JDK가 않잡히고 JRE가 잡히신 분이라면 -server 옵션이 않먹을수가 있는데요, 그럴때는 JDK\bin\java 로 JDK가 설치된 디렉토리의 java.exe를 사용하시면 됩니다.
자바에서는 사용환경에 따른 최적화 방식이 다른 Hotspot 엔진이 있습니다. 보통 client/server 두개의 엔진으로 구분되며 성능적으로는 server가 더 우월한 엔진입니다. cc로 컴파일 하실때 -O3로 최적화 옵션을 주신 것처럼, 자바에서 더빠른 실행을 원할때는 server hotspot 엔진을 사용하죠.
ps2. 가급적이면 테스트 환경도 같이 기술해주시면 다른 분들에게도 참고가 될것입니다 ^^
님도
님도 컴파일옵션주시고 재대로 돌려보세요..
그리고 표준도 재대로 지원안하고 나온지도 10년이다되가는 vc6.0++ 같은데서 하지마시고..
^^ 제가 가진 컴파일러가 VC6 밖이라서요.
Release Mode에서 테스트 했습니다.
C와 자바를 같은 환경에서 돌려 볼수 있어야 하는데,
제가 가진 윈도우 C 컴파일러가 VC6 밖에 없네요.
혹시 추천해주실만한 무료로 쓸수 있는 다른 윈도우 C/C++ 컴파일러가 있나요?
지난번에 MS에서 공개한 건 VC6(패치 다한 버전) 꺼와 다를게 없다고 알고 있는데요.
볼랜드꺼는 몇차래 시도 해봤는데 매번 다운이 않되더군요...
cygwin에서 수행해본
cygwin에서 gcc 3.4.4로 수행해본 결과..
Case 1에서
자바 32초, C 33초 나왔습니다.
Case 2에서
자바 36초, C 33초 나왔습니다.
(테스트는 각 10회씩 실시했으며, 평균값을 사용하였습니다)
C : case 1과 case 2의 결과가 동일한 33초가 나온결과로 보았을때, gcc 3.4.4 의 -O3 옵션은 calc의 내용을 inline 시켜서 컴파일을 수행을 시킨다고 보입니다.
따라서 결과는 성능을 C를 100%로 보았을때
Case 1일때 자바 103%, Case 2일때 자바 92%정도의 성능을 보여주는 것으로 나오네요.
따라서 CASE 1은 자바가 빠르고 CASE 2는 C가 빠른 결과를 보여 주었습니다.
저는 리눅스에서 gcc
저는 리눅스에서
gcc -O3 화일 이름
java -server 화일 이름
으로 했습니다.
C: 0초 java : 1326 나왔습니다.
그런데 C 는 루프 안돌고 결과를 내보냅니다.
자바는 루프 돌고 결과를 내보내고요
(디버거로 확인..)
실수.. kaffe JVM 으로
실수..
kaffe JVM 으로 했을 경우
1326 이고
jdk1.5.0_01 로 했을 경우
64 입니다.
옵션은
java -server 클래스 이름..
테스트 해보았습니다.
테스트 결과가 그대로 납득하기 어려울 정도로 차이가 나서 코드를 복사하여 실행해보았습니다.
테스트환경 --------------------------------------------------------------------------------
CPU : 인텔 셀러론 2.0A (2.2로 오버클럭)
RAM : 512MB PC2100
OS : Windows XP, SP2적용
Java Environment : Eclipse / JDK 1.6.0 b105
C++ Environment : Dev-C 4.9.9.2 / GCC 3.4.2
테스트 결과 ---------------------------------------------------------------------------------
Java - 2663 ms (10회 측정치 중 최대값. 평균 2.4초)
C++ - 3 s (10회 측정치 모두 초단위로 3초. 그 이하의 단위의 값은 출력되지 않아 평균을 구할 수 없음)
---------------------------------------------------------------------------------------------
참고로 최초 JVM 구동시 가상머신 자체의 오버헤드가 발생할 수 있습니다. (JVM 자체의 작업을 위해 쓰레드를 사용하므로
실행시 메인쓰레드의 실행이 지연된다는 뜻입니다) 하지만 의도하신게 '순간 느리다'는 것은 아닐테니 오버헤드로 인한 지연은
제외시켰습니다. 즉, 위 코드를 10회 테스트하여 평균값을 냈습니다. 똑같은 코드인데 GCC로 컴파일한 제 PC에서 3초가 걸린 작업이
8초가 걸리는걸 보니 테스트 환경이 좀 좋지못한 것 같군요. 테스트 환경을 좀 밝혀주셨으면 합니다. 그래야 공정하겠지요?
하지만, 설사 스크립트 언어라고 해도 소요되는 시간은 대부분 파싱에서 오지 연산에서 오지 않습니다. 요즘의 CPU나 램, 메모리의
속도는 반복문과 같은 단순 연산에서 엄청난 오버헤드가 있지않는 이상 그게 어떤 언어라도 차이를 무시할 정도로 빠릅니다.
그리고 제가 위에서 언급했듯이 프로그램의 성능저하는 메모리 영역에서 일어나지 않습니다. 이런 코드의 성능은 어떤 언어라도 큰
차이를 보일 수 없습니다. CPU와 메모리의 속도가 너무 빠르기 때문이죠. 설령 스크립트 언어라도 '파싱'에 소요되는 시간을 제외하면
C와 차이가 안 날 겁니다. 이런 테스트는 실질적으로 자바가 빠르다거나 느리다는 것 중 아무것도 증명할 수 없습니다.
컴파일옵션주시고
컴파일옵션주시고 재대로 해보세요..
모두 디폴트 값인데요.
자바나 GCC 모두 디폴트로 포함되는 옵션 이외에는 아무것도 붙이지 않았습니다. 그게 일반적이라고 생각되서 말이죠.
하긴, 컴파일 옵션에 따라 결과가 달라진다면 그것도 흥미로운 얘기죠. 구체적으로 어떤 환경에서 어떤 옵션으로 테스트하셨습니까?
테스트를 재현하기 위한 정보가 부족하군요.
아, 그리고 가능하면 로그인을 좀 해주시면 안될까요? 익명이면 누구하고 얘기를 하고있는지, 누가 누구를 사칭해서 말하는건지 전혀
알 수 없습니다.그리고 답변을 간단하게 하시는건 괜찮지만 필요한 정보 정도는 좀 알려주셨으면 합니다. 테스트 환경이나 컴파일러, 기타
옵션 등이 없으면 정확하게 테스트를 재현할 수가 없고 결과에 차이가 있어도 왜 차이가 났는지 추측할 수가 없습니다.
저는 여기서 자바가 낫냐, C/C++이 낫냐는 케케묵은 유치한 논쟁을 하자는게 아닙니다. 가능하면 객관적인 방법으로, 자바가 느리다는 것이
편견인지 아니면 사실인지, 사실이라면 어떻게 그걸 알아낼 수 있을 것인지, 사실이 아니라면 어느정도가 사실이고 어느정도가 사실이 아닌지
가벼운 마음으로 '가지고 놀아보자'는 얘기입니다. 논쟁보다는 그 편이 더욱 흥미롭지 않습니까? 저는 그게 더 흥미롭군요.
여기서 안된다면 따로 C/C++에 자신있는 사람을 구해서라도 실험해봐야겠군요. 음... 재밌을 것 같군요.
컴파일옵션 주는게
컴파일옵션 주는게 일반적인겁니다.
디버그 돌려볼 목적이 아니라면 넣어 줘야지요..
일단 -O3 옵션을 추가한 결과...
C++ 실행시간이 평균 3초에서 1초로 단축되었습니다.
그렇다면 님 PC에서의 C++ 8초, 자바 17초의 결과도 이상한 일이 아니군요.
하지만 좀 맘에 걸리는 부분은... 저는 제 컴퓨팅 환경이 그다지 좋다고 생각하지 않습니다. (셀 2.0 -> 2.2 오버, 512MB PC2100)
433Mhz에서 셀2.0으로 업그레이드를 한지 한 5년정도 되었습니다. 즉, 5년전 컴퓨터를 아직도 사용하고 있는데... 제 컴퓨터에서 1초면
끝나는 작업이 님의 테스트 환경에서는 8초나 걸리는군요.
1초와 2.6초의 차이는 1.6초입니다. 그 정도의 차이는 사용자에게도 용인될 수 있는 정도입니다. (루프를 10억번이나 돈 걸 감안하면...)
하지만 8초와 17초의 차이는 무려 9초. 이건 사용자가 기다리다가 컴퓨터를 던져버릴 정도의 차이입니다. 이런 환경에서는 자바 어플리케이션
못 씁니다. CPU 사양이 낮은 걸로 보이는데 그렇다면 램도 넉넉치 못할테고, JVM 같이 기본적으로 메모리를 많이잡고 들어가는 프로그램은
스왑의 원인이 될 수도 있으므로 이런 환경에서 자바를 사용한다면 도구를 잘못선택한 겁니다.
뭐, 굳이 '수치상으로는 어차피 2배 아니냐'라고 말하신다면 더 이상 할 말은 없습니다.
지금의 컴퓨팅 환경이 과거와는 비할 수 없을 정도로 발전되었다고 해도 아직 셀러론 2.0 이하의 컴퓨터를 쓰시는 분들도 있으니까요.
하지만 저 2배라는 수치가 듀얼코어가 보편화되고 512MB는 기본인 요즘 컴퓨팅 환경에서도 그렇게 빛나는 수치인지는 의문입니다.
똑같은 2배라도 1초와 2초의 차이는 용납되지만 5초와 10초의 차이는 사용자 입장에서 용납할 수 없기 때문입니다.
실제적으로는 테스트 코드처럼 극단적인 반복문을 돌 필요가 없으니만큼 이것이 실제적인 자바 어플리케이션에 있어서 '몇 배나 느리다'라고
말할만한 근거로는 불충분하다고 생각합니다. 하지만 C/C++의 최적화 옵션을 고려하면 예상보다 차이가 벌어진다는 것은 잘 알겠습니다.
음, 그런데 실례가 될지 모르겠습니다만... 자바로 만든 프로그램을 돌리기에 저 테스트 환경은 (상대적으로 추측컨대) 너무 열악한게 아닌가
싶습니다. 저런 환경에서는 제 아무리 최적화를 잘해도 실제로 쓸만한 자바 어플리케이션이 나올 수가 없겠군요. 1990년 후반에 자바가 처음
나왔을 때 엄청난 비판을 받았습니다. 당시의 컴퓨팅 환경은 지금와서 보면 최악, 네트워크 속도도 최악... 자바의 추상화는 시스템에서 감당할
수 없을 정도의 복잡함이었죠. 지금 굳이 그 당시의 환경까지 고려해서 프로그래밍을 할 필요가 있을런지요?
위에 테스트 코드
위에 테스트 코드 3개를 모두 해봤습니다. 환경은
CPU Intel P4 3.0GHz
memory 1.5GB
Windows XP, SP2
Java SE 1.6과 VC++ 2005을 사용하였습니다.
C++ 코드는 elapsed time을 msec 단위로 출력하도록 하고
계산 결과도 같이 출력하도록 하였습니다.
Speed1에서 C++이 0을 출력한 것은 아예 컴파일 타임에 계산결과가 나오도록 최적화가 된 것 같아서 제외하기로 하고
나머지 경우는 java가 3배 이상의 시간이 걸렸습니다.
Server Hotspot을 사용해 보시겠습니까?
java -server Speed2 이런식으로 실행 시켜 봐주시겠습니까?
Path에 JDK가 않잡히고 JRE가 잡히신 분이라면 -server 옵션이 않먹을수가 있는데요, 그럴때는 JDK\bin\java 로 JDK가 설치된 디렉토리의 java.exe를 사용하시면 됩니다.
c에서 컴파일 옵션 주듯이, 자바에서 성능 위주의 실행을 원할때는 Server Hotspot Engine을 사용하거든요.
1% 정도 빨라지는데..
1% 정도 빨라지는데.. 큰차이는 안나네요..
하지만 그러면 실질적인 측정이 되지않을 것 같습니다.
물론 서버 핫스팟을 사용하면, C의 컴파일 옵션처럼 구동시간이 길어지는 대신에 런타임 실행시간은 줄어들겠지요.
하지만 최종사용자에게 JRE 보다 용량이 큰 JDK를 설치하도록 강요할 생각도 없을 뿐더러, 특별한 경우를 제외하고 성능을 빠르게 해주자고
프로그램의 안정성을 떨어뜨려서 줄 수는 없습니다.
아직까지 첫번째 질문의 요지가 논점에서 살아있는지는 잘 모르겠습니다만, 대부분 자바 프로그램이 느리다고 지적받는 부분은 서버가
아니라 클라이언트 쪽입니다. 초기 자바의 '무조건 느리다'는 편견이 팽배한 것도 실제적으로는 잘 쓰이지않고 있는 클라이언트 쪽이구요.
서버가 아닌 클라이언트에서 대부분의 일반적인 자바 어플리케이션은 서버 핫스팟을 사용하지 않습니다. 그러니 일반적인 사용자가
'자바는 느리다'라고 느낄 때의 환경, JRE의 클라이언트 핫스팟에서의 디폴트 옵션으로 테스트를 해야한다고 생각합니다.
'C는 최적화 옵션을 붙이고, 자바는 안 붙이고 실행하면 그건 불공평하지 않느냐'라고 생각될지 모르지만, 실제로 사용자들이 사용하고
있는 환경이 그렇다면 그렇게 비교를 해야 현실적인 비교가 됩니다. C 컴파일러가 최적화 옵션을 붙여서 컴파일 했을 때 핫스팟과 마찬가지로
약간 불안정하다고 알고있습니다만, 일반적으로 그렇게해서 배포한다면 그게 기준이 되어야겠지요. 자바 어플리케이션은 C 어플리케이션에
비해 배포의 불편함이라던가 실행시 옵션을 더한다던가 JVM 자체의 안정성을 떨어뜨린다던가 하는 문제 때문에 일반적으로는 서버 핫스팟을
고려하지 않습니다. 그렇다면 그걸 기준으로 해야하지 않겠습니까.
벤치마킹은 지금까지 많이도 나왔습니다. 가능하면 '실제 배포하고 사용자가 사용했을 때' 어떤 차이를 보이는지 알아보는게 낫지않을까요?
최종 배포시에 '순수한 언어의 성능'은 중요하지 않습니다. 오로지 사용자의 눈에 보여질 성능만이 중요하죠.
맞는 말씀입니다만..
윈도우용 JRE에는 Server hotspot이 포함되어 있지 않지만, 솔라이스용이나 리눅스 용에는 포함되어 있늘 것으로 알고 있습니다.
다만, 자바의 client hot spot은 Swing 어플리케이션등 실행패스의 변화가 빈번하게 일어나는 코드에 적합한 엔진입니다. 다이나믹한 환경에 최적화 되어 있는 거죠.
server hot spot은 동일한 실행패스를 자주 실행시키는 서버 어플리케이션에 최적화 되어 있고요.
유저 입장에서의 성능이 중요하다라는 것은 동의 합니다.
그렇다면, 사용자는 어떤 것을 보게될까요? 실질적으로 보았을때 자바로된 GUI 어플리케이션 보다는 웹어플리케이션을 더 많이 보고 있을겁니다. 웹어플리케이션 서버는 무조건 server hotspot이니까 Server hotspot을 더 많이 보고 있을 겁니다. 그렇다면 server hotpot을 이용하는게 더 현실적 아닐까요?
어떤 익명분은 C 소스를 컴파일 할때 옵션을 주는 건 당연하다고 하셨습니다. 왜 C는 최적화 옵션을 주는게 당연하고,자바는 아닐까요? 마찬가지로 자바에서 어플리케이션의 용도에 따라 hotspot 엔진을 선택하는 것 역시 당연한 겁니다.
각각의 언어/기술은 나름대도 장점과 단점이 있습니다.
그리고 각각의 언어/기술은 자신들의 장점을 강화하고 단점을 보완하기 위해 많은 노력들을 기울여 왔죠.
벤치마크란 쉽게 이야기 하면 그런 노력들을 객관적으로 평가해보기 위한 주관적인 노력입니다.
youbit님이 말씀하신대로라면 "눈에 보이는 성능"만이 중요하다면, 최신의 하드웨어의 성능을 극한으로 뽑아내는 게임들을 만드는 언어가 제일일껍니다. youbit님의 보시는 유저는 PC에서 직접 돌아가는 프로그램을 사용하는 유저이니까요.
하지만, C/C++을 기상청의 핵심 연산 프로그램을 위한 언어로 사용하지는 않습니다. 무조건 포트란이죠. 연산속도가 8~16배정도 차이 나는데 당연한 거죠. 그럼 기상청의 해당 프로그램을 사용하는 유저도 "눈에 보이는 것"을 기반으로 성능을 생각해야 할까요?
각각의 언어/기술이 서로 환경이 다른데 가급적 동일한 환경을 구성하려는 노력은 필요하겠지만 완전히 동일한 환경은 만들수가 없습니다.
그러니 현재의 이슈, 주어진 코드를 기반으로 각 언어에서 어느정도의 성능이 나올까? 이런 테스트에서 고려/무시해야 되는 것은 무엇일까? 또 다른 코드를 테스트할때는 어떨까? 이런 논의가 될수 밖에 없는 겁니다.
제가 말씀드리는 것은 일반적인 '편견'에 속하는 영역의 것 입니다.
어플리케이션의 용도에 따라서 핫스팟 엔진을 선택하는 것은 물론 맞는 말씀입니다. 상황에 따라 맞는 옵션을 주는 것이 당연하지요.
제가 의도하는 바는 일반적으로 '어느정도 느리다'는 것도 아닌 무조건 '느려서 못써먹어'라고 평가받는 부분이 서버가 아니라 클라이언트
부분이기 때문에 애시당초 '순수하게 어느게 더 빠르냐'라는 유희적인 논쟁이 목적이 아닌 이상, 그렇게 평가받는 부분의 환경을 고려해서
테스트를 해야한다는 것입니다.
아쉽게도 솔리리스나 리눅스는 아직까지 데스크탑에서 주류가 아닙니다. 실제적으로 사용자들이 체감하는 것의 대부분은 윈도우에서의 성능을
말하는 것입니다. 그런 이상 아무리 '리눅스나 솔라리스에서는 다르다'라고 말해도 '그거? 느리지않나?'라는 생각 자체는 변하지 않을 것
같습니다. 웹 애플리케이션의 성능 역시 클라이언트의 성능보다 더 중요하지만 문제는 그걸 사용자들이 인식할 수 없지 않습니까?
제가 지적하는 것은 '자바는 느리다'라는 일반적인 인식에 객관성이 결여되어 있음에도 불구하고 사람들이 무조건 '자바? 그거 느리지'라고
납득한다는 것 입니다(이전에도 말했지만 얼마나 느린지는 아예 빠져있죠). 그리고 그런 인식을 전환하기 위해서는 사람들이 실제적으로
보여지는 영역에서의 성능을 객관적으로 비교할 필요가 있다는 것 입니다. 애시당초 인식 자체가 '이거 척 보기에도 몇 배는 느리잖아?
몇 배는 느린게 맞아'라는 거니까요. 저는 실제적인 성능보다 '느리다'라는 일반적인 인식 자체가 더 방해가 된다고 생각하기 때문에 얼마나
빠르냐보다는 '일반적인 인식이 얼마나 객관적이지 않느냐'에 관심이 있습니다. 애시당초 '자바가 C(or C++?) 보다 8배 느리다?'라는 질문도
그런 일반적인 인식을 근거로 묻는 것이 아니겠습니까?
그리고 화려하고 복잡해서 극한의 속도 없이는 끊겨버리는 화려한 게임이야 물론 자바로 짜면 안됩니다. 가능한지를 떠나서 그런 비효율성을
감수할 이유가 없지요. 하지만 그런 고성능 위주의 게임이 아니라면 자바로도 충분히 구현할 수 있습니다. 문제는 '자바는 느려서 안되지'라는
인식이죠.
Jake와 같은 예는 '자바가 C/C++의 몇% 따라잡았다'가 아니라 '일반적인 인식과 다르게 자바로도 충분히 이런 게임을 만들 수 있다'는 데에
의미가 있다고 봅니다. 사용자 입장에서야 80프레임이건 50프레임이건 끊기지만 않으면 문제가 없으니까요. 결국 '성능' 문제가 아니라 '인식'
문제라는 것입니다. narusas님이 말씀하시고 싶으신 것도 '자바가 C/C++ 못지않게 빠르다'라는게 아니라 결국은 '무조건 자바가 느리다'는
편견이 문제라는 것이 아닌가요? 저는 그렇게 느꼈습니다만...
언제인지는 기억이 정확히 안납니다만, 사내에서 사용되는 관리툴을 자바로 만들어서 아는 사람에게 준 적이 있습니다. 원래는 웹으로 만들어진
툴이었기 때문에 소스코드를 보고, 필요한 정보만 HTTP로 보내주면 되는 간단한 툴이었습니다. 솔직히 성능에 특별한 관심없이 대충만든 것이라
'느리다'고 불평할까봐 걱정했습니다만 문제없냐고 물어보니까 아무런 문제없다며 다른 기능을 추가할 수 있는지 물어보더군요. SWT도 아닌
스윙을 사용해 운영체제의 룩앤필을 흉내낸 것이었는데, 실제적으로 아무것도 모르는 사용자 입장에서는 기타 C/C++로 작성된 프로그램과 구분
하지 못했습니다. 겉보기가 똑같고 성능도 초단위의 눈에 띄는 차이가 아니라면 사용자 입장에서는 그게 자바냐, C냐는 구분할 필요조차도
느끼지 못한다는 말입니다.
'자바가 몇 배는 느리다'라는 말 속에는 단순히 성능의 문제가 아니라 '느려서 못 써먹어'라는 생각이 숨어있습니다. 사용자 입장에서는
'느려서 못쓴다고들 하잖아? 다들 그러니까 그게 맞겠지'라는 무비판적인 생각이. C/C++ 프로그래머 입장에서는 '역시 C/C++이 최고야'라는
우월주의가 말이죠. 그래서 '순수한 언어의 성능'의 문제가 아니라 '실제적인 사용에서의 성능'을 고려해야 벤치마킹이 의미가 있지않을까...
생각합니다.
추가 ------------------------------------------------------------------------------------------------------------
HotSpot Server Optimization 중에 'Loop unrolling'이 있었군요. 벤치마킹에 있어서 -server 옵션을 통해서 동일한 정도의 최적화를
거치는 것이 공정성에 문제가 없다는 것에 동의합니다.
제가 말하는 것은 벤치마킹을 떠나서 실제로 대부분의 C 어플리케이션이 최적화된 옵션으로 컴파일되어 배포되고, 자바 어플리케이션이 최적화
되지 않은 상태에서 실행된다면 그 상태를 고려해서 성능을 평가해야한다는 것이었습니다. 벤치마킹에 있어서는 어느 한쪽은 비효율적인 방식을
사용한다면 그건 공정한 비교가 안되겠죠.
C에서 정밀한 시간 측정..
한쪽은 초이고, 한쪽은 ms이니 비교가 어려워서 C에서 정밀한 시간측정이 가능한 코드를 올려드립니다.
이 테스트는 무의미
이 테스트는 무의미 합니다. 좋은 c 컴파일러의 경우 컴파일 타임에
다 계산해 넣을 정도로 내용이 단순합니다. 좋은 컴파일러는 아니지만
gcc 의 경우 단순히 루프만 다 풀어해쳐서 -O3 -funroll-loops 아니
-O1 -funroll-loops 만 넣어도 타임 0~1 초 나옵니다.
결론, 컴파일러 최적화 들어가면 어떻게 나올지 알 수 없다.
그래서^^
그래서 중간에 실행 패스가 변경되는 코드로 테스트한게 제가 포스팅한 테스트입니다.
님께서 제시한 컴파일 옵션을 넣고 제 테스트 코드를 다시 구동 시켜 보았습니다.
Case 1 : C 33초 자바 32초
Case 2 : C 33초 자바 36초
이렇게 해도 여전히 Case 1은 자바가 빠르고, Case 2에서는 C가 빠른 결과가 나옵니다.
제가 드린 말은
제가 드린 말은 내용이 정적이고 컴파일러, 최적화 옵션에 따라
결과가 다르기 때문에 의미가 없다는 말이었습니다.
예를 들어 최적화를 잘해주는 컴파일러가 있다면 Case1의 경우
에도 아예 계산해서 넣을 수도 있다는 것이었습니다.
물론 테스트 목적이겠지만, 실제로 저렇게 눈에 보이는 코드면
손으로도 최적화해서 넣을 수 있습니다. c++, java 상관 없이
디자인 최적화에 들어가겠죠. 실제로 약간 손봐서 10초 정도
줄어듭니다. 기술이 발전한다면 컴파일러가 이런 최적화도 가능
하게되리라 생각됩니다.
결론은 최적화는 컴파일러 수준에서 해주는게 마땅합니다.
페이지
댓글 달기