>그런데도 한국에서는 문제없이 사용되는 이유는 한국은 아직까지 극한의 기술을 사용하지 않는 그저그런 웹사이트 처리뿐이고
>SW 의 기술보다 HW 에 우위를 두는 이상한 현상때문이죠. 설계감사에서 보다보면 도저히 성능이 안나올거 같아서 물어보면
>대답은 한결같더군요. HW 를 더 고사양으로 올리죠. 이거 미국에서였으면 boss 한테 짐싸라는 소리 나옵니다.
하드왜어 업그래이드로 커버가 되는 문제들을 굳이 소프트왜어로 해결하려고 하지 않는 회사들 많이 봐왔습니다만...
사실 C/C++/Java간의 속도 차이에 대해서는 별다른 관심은 없습니다만 벤치마킹 결과가 궁금해서 돌려봤습니다.
그런데 C++ 코드 쪽을 보니 메모리 할당만 있고 해제가 없더군요. 이런 경우를 정상적인 C++ 코드라고 보긴 힘들지요. :) 정상적인 C++ 코드로 만들려면 해제 코드도 넣어주는 (a) 방법이 있고 별도의 컨테이너를 쓰는 (b) 방법이 있을 텐데, (b) 쪽에 대해서는 std::vector<bool> (b1) 과 std::deque<bool> (b2) 두 종류의 컨테이너를 사용해 돌려봤습니다. 결과는 아래 그림에 나와있습니다만, 요약하자면 해당 C++ 코드는 Java 코드에 비해
(a), (b2): 속도가 거의 같습니다.
(b1): 큰 N에 대해 속도가 대략 4배쯤 빠릅니다.
측정한 시스템의 구성은 아래와 같습니다.
Pentium M 1.7GHz, 2GB RAM
Gentoo Linux 2006.1
gcc-4.1.1-r1
sun-jdk-1.5.0.09 (blackdown-jdk-1.4.2 도 써 봤습니다만 양쪽 다 결과는 거의 같습니다.)
알고 있습니다. :) vector 와 deque 두 개의 컨테이너를 다 테스트한 이유 중 하나가 그것입니다. (미리 적어둘 걸 그랬나보군요.) 그리고 이 경우에는 Effective STL 을 고려하더라도 굳이 vector를 비교에서 제외할 이유는 별로 없는 것 같습니다.
====
기억에 의존해서만 적기엔 좀 뭐해서 집에 돌아와 ESTL을 다시 뒤져보고 추가로 적습니다. ESTL #18에서는
Scott Meyers wrote:
vector<bool> 보기를 돌같이 하자
라는 항목 밑에 대략 다음과 같이 그 이유를 적고 있습니다.
1. vector<bool>에는 실제로 bool이 들어 있지 않다.
2. vector<bool>은 STL 컨테이너가 아니다. STL 컨테이너의 요구사항을 만족시키지 않는다.
하지만 위 두 가지 이유는 모두 이 경우에는 적용되지 않습니다. 이 경우에는 vector<bool>에 실제로 bool이 들어 있든 안 들어 있든 상관할 필요가 없죠. 오로지 bit를 넣고 뺄 필요가 있을 뿐입니다. 또한 iterator, reference, pointer라든가 STL 알고리듬 등을 따로 이용하지 않는다면 요구사항을 만족시키든 못 만족시키든 상관 없이 잘 동작할 수도 있습니다.
Scott Meyers 본인도 ESTL의 머리말에서 말하고 있듯이
Scott Meyers wrote:
이것들은 그냥 "가이드라인"일 뿐입니다. 경우에 따라선 지키지 않는 것이 나을 때도 있습니다.
이 경우는 그냥 단순한 벤치마크이므로 지키지 않는 것이 낫다고까지는 할 수 없겠습니다만, 이런 사정이라면 당연히 양쪽 다 테스트하는 게 맞겠지요.
Agile Software Development, Principles, Patterns, and Practices
Agile Principles, Patterns and Practices in C#
Extreme Programming in Practice
UML for Java Programmers
Designing Object-Oriented C++ Applications using the Booch Method
등 아주 훌륭한 책도 많이 낸분이고 제가 제일 좋아하는 개발자인데 낚시질이라 하시니 OTL
"premature optimization is the root of all evil (성급한 최적화가 만악의 근원이다)."라는 말을 많은 대가들이 언급했었습니다.
성급한 최적화가 시작되는 곳이 바로 여기(언어간 속도 논쟁)가 아닌가 합니다.
성공적으로 시장에 진입한 언어들 중에 속도가 느려서 못쓸만큼 느린 언어는 없는것같습니다만, 왜 매번 이런 플레임성 글이 올라오는지 참 의아합니다.
JVM에 의한 메모리 관리가 그 주 이유 입니다. 아시다 시피 많은 OS에서 system call은 인터럽트로 구현되어 있습니다. 프로세서 아키텍쳐를 조금만 공부해보신 분은 다 아실테지만,
인터럽트의 처리 과정은, 다른 어떤 처리과정 보다도 복잡하고, 많은 작업을 요합니다. 또한 인터럽트 서비스 루틴에서의 처리를 위해서 시스템 영역과 유저영역 사이의 데이터 트랜스퍼 역시 많은 오버헤드가 걸리는 작업이지요.
C/C++에서의 malloc/free와 같이 system call을 수반하는 명령이 호출될때마다 이러한 엄청난 작업이 일어나지요.
Java에서는 VM에서 어느정도 똑똑하게 user 영역에서 메모리 관리를 해줍니다. 따라서 상대적으로 system call로 인한 오버헤드가 적지요.. 물론 이러한 GC에 따른 오버헤드 역시 상당했었습니다.. 예전엔.. 그러나 최신의 JVM에서는 정말 많이 개선이 되었지요.
잊을만 하면 나오는 flame이군요. 일부 잘못된 오해를 바탕으로 한 황당한 주장도 있고..
무슨 근거로 Java를 그렇게 무시하는지는 모르겠지만
비즈니스 프로젝트에는 C프로젝트보다 Java프로젝트가 더 많습니다.
삼성, LG, SK, 은행, 보험 등 SI의 주요 큰손 프로젝트의 상당수는 Java입니다.
잡코리아 같은데서 SI파견업체 구직을보면 Java 모집이 가장 많습니다.
여러 하고픈말이 많지만 속도문제로 한정짓자면,
Java도 하부구조인 JVM의 진화, 캐싱, GC기술의 발전, JIT기술의 발전으로 이젠 느리지 않으며
어플리케이션 레벨에서도 멀티쓰레딩, 쓰레드풀, NewIO 등의 도움으로 효율적으로 시스템 자원을 활용합니다.
JVM의 초기 구동이나 바이트코드를 JIT가 컴파일하는데는 delay가 있지만 JIT를 통과해 기계어로 컴파일되면 C로 작성한 네이티브 코드만큼의 최적화는 기본입니다. 같은 루틴이 여러번 호출될수록 C와의 차이는 점점 줄어들게 되는것이지요. 비슷한 정도의 최적화를 거쳤다는 가정 하에 많은 Java 서버 어플리케이션은 C와 거의 비슷한 속도를 낼 수 있습니다.
그리고 JVM이 개선됨으로 속도가 향상되는건 C 컴파일러가 개선되면서 코드가 최적화되는것과 같은 원리입니다. 실제로 Sun에서 최신 cc를 발표하면서 옵티마이저를 개선해 이전 버전에 비해 수십% 향상시켰다는 보도자료도 있었습니다. 컴파일러를 변경함으로 인해 바이너리가 개선된다는건 컴파일러를 판매하는 벤더들의 공통된 주장입니다. cc가 개선되는 것처럼 JVM의 개선은 비난할게 못됩니다.
하지만 속도는 뭐니뭐니해도 메모리 증설하고 디스크를 스토리지로 바꾸고 DB를 튜닝하고 네트웍을 증설하는게 가장 저렴하게 해결할 수 있습니다. 대부분의 경우 C건 Java건 돌아가는 프로그램에 손대는건 버그만 추가할 뿐이지 들인 시간(시간은 곧 돈!)에 비해 결과가 별로 좋지 않습니다.
자바에서 할수 있는거 C/C++로 다 할수 있다는 거 맞습니다.
자바 JVM 자체가 C/C++로 만들어 졌으니까요.
그런데 자바 JVM에서 해주는 수많은 "자동" 최적화를 C/C++로 "수동"으로 직접 짜실 겁니까? ^^
프로그램 만들때 매번 실시간 분기예측, 유저레벨쓰래드, 유저레벨 메모리 관리, 실시간 최적화... 등등 다 해주시나요?
뭐 JVM에서 제공되고 있는 온갖 종류의 최적화를 일일히 다 해주신다면야 당연히 C/C++이 무조건 더 빠르겠죠.
ps. 실시간 분기예측을 통한 최적화같은건 정말 구현하기 어려운 거죠.
if (a==1) {
//..do 1
}
else if (a == 2) }
// do 2
}
else if (a == 3 && b ==1) {
// do 3
}
이런 복잡한 조건문이 있어도 실행시에 분기 예측에 의해 아예 조건문의 실행 없이
// do 3
만 호출해 버리는 거죠. 실행시간에만 가능한 최적화방법중에 하나죠.
이런걸 C/C++로 만들수는 있지만, 그걸 직접 매번 자신의 프로그램에 넣으실분 계세요?
이런것 말고도, 어플리케이션이 해당 CPU(AMD, 인텔등)에 최적화된 코드를 사용하게 한다던가, 대단히 많은 실행시간 최적화를 제공하고 있죠.
물론 모두 C/C++로 만들어진 JVM이 제공하는 기능이니 C/C++에서 불가능 하다는게 아닙니다.
그런 최적화를 프로그래머가 제공하느냐, 아니면, 환경에서 제공하느냐 하는 차이인 것입니다.
ps2.
>> Java 의 경우, 얼마나 최적화가 되어있지 않으면, 10~20% 정도 성능향상을 시킬만한 여지가 있는건지...
>> VM 바꾸는 것으로 10~20% 성능향상을 가져올 수 있다는 것은, 그만큼 VM이 엉터리로 짜여져서 최적화가 되어있지 않다는 얘기와 동일한 것 아닌가요 ???
방식을 바꿔서 엄청난 진전을 가져와본적이 없으신가보군요 ^^
예를 들자면, 2D를 그리는데, 도트단위로 직접 그리는 것을 죽어라 최적화 하는 것 보다, HW 가속기능을 사용하게끔 변경한다던지하는 거 말입니다. JVM은 그런식으로 조금씩 계속 진보되고 그 진전을 JVM에 쌓아 가고 있습니다.
>> C/C++ 은 몇십년 동안 축적된 저런 성격이 없나요???
>> 혹시, 그 사실 아십니까.. ??
>> C/C++ 이 포트란 보다 신뢰성과 안정성 그리고 관계자의 익숙성에서 더 뛰어나다는 사실을...
이말을 자바에 대해서도 말할수 있습니다.
Java 는 몇십년 동안 축적된 저런 성격이 없나요???
혹시, 그 사실 아십니까.. ??
Java가 C/C++ 보다 신뢰성과 안정성 그리고 관계자의 익숙성에서 더 뛰어나다는 사실을...
FSM(유한상태기계)는 상태가 변경될때만 비용이 발생합니다.
반면에 조건문은 조건문이 실행될때마다 비용이 발생합니다.
if 문과 관련된 상태를 기반으로 FSM를 구성하여 최적화 하기 때문에 상태가 바뀌지 않는한 비용이 발생하지 않습니다.
이것도 기초적인 분기예측이고요, 더 복잡하고 정교하면서 저비용의 분기예측 기법은 많습니다.
그리고 모든 부분에서 분기예측이 아닌 성능에 직접적으로 큰 영향을 미치는 부분, 바로 Hot-spot 부분에 대해서 좀더 강력한 최적화를 수행하는 거죠. 그래서 Hot spot VM인겁니다.
그리고 불필요한 분기문이 아니라, 특정시간과 상태에서만 불필요한 분기문인거죠. "실행시간"이라는 것을 잘 생각해 보세요.
게임이라고 생각해보면
while(isGameGoing) {
switch(gameState) {
case OPENING:
showOpening();
break;
case MAIN_MENU:
showMainMenu();
break;
case PLAYING:
play();
break;
case SUB_MENU:
showSubMenu();
break;
case CLOSING:
close();
isGameGoing = false;
break;
}
}
이런 코드에서 불필요한 분기문이 있나요?
하지만 대부분의 시간을 case PLAYING 상태에서 play()를 호출하겠죠.
물론 이걸 직접 FSM으로 만들수도 있습니다. ^^
FSM은 비용이 들지 않습니다. 그냥 호출입니다. ^^
상태가 변경될때에만 비용이 발생하고 각각의 상태를 호출하는데 있어서는 비용이 발생하지 않습니다.
다시말해 상태를 판단하지 않습니다.
상태기계가 매실행 루프에서 항상 비용이 든다는 것은 처음듣는 이론입니다만...
억지로 그렇게 만들수는 있지만, 누가 그렇게 할려나요?
제가 예로 제시한 것은 상용게임에서 사용하는 전형적인 코드이고 다음의 코드역시 상용게임에서 FSM으로 구현된 것을 간단히 옮긴 것입니다만...(상태패턴이 아닌 전략 패턴으로 구성되기도 합니다)
interface State { void execute(); }
class OpeningState implements State { void execute() { showOpening();}}
class MainMenuState implements State { void execute() { showMainMenu();}}
class PlayingState implements State { void execute() { playing();}}
class CloseState implements State { void execute() { close(); }}
...
State state;
...
while(GameState.isRunning()) {
state.execute();
}
class OpeningState implements State { void execute() { showOpening();}}
class MainMenuState implements State { void execute() { showMainMenu();}}
class PlayingState implements State { void execute() { playing();}}
class CloseState implements State { void execute() { close(); }}
...
State state;
...
while(GameState.isRunning()) {
state.execute();
}
이렇게 코드를 실제로 짰더라고 실행시간의 대부분에 해당하는게 Playing 상태겠죠.
이부분이 Hot-spot으로 인식되면 실행시간 분기예측 최적화에 의해 내부적으로 다음과 같은 코드처럼 네이티브 코드로 동작하게 되는 겁니다.
while(GameState.isRunning()) {
playing();
}
이런식으로 호출 스택마저도 옵티마이즈가 가능하다는 겁니다. 매번 상태판단을 하는 것도 아니기 때문에 이렇게 되면 최소한 이부분은 동일한 C++코드보다 빠르게 동작하는 부분이 되는 거죠. FSM에 의해 상태가 바뀌면 다시 원래 코드로 동작하고요.
FSM을 OOP의 메시징 기법을 이용해서 구현하면 상태 판단이 필요없다는 얘기는 처음 듣습니다.
FSM을 어떤 언어로 구현하느냐에 따라 근본적인 차이가 있을 거라고 생각하십니까?
> FSM에서는 상태의 변화, 즉 이벤트가 발생할때만 상태변경에 대한 판단이 필요하고 그때만 비용이 발생합니다.
그러면 이벤트를 발생시킬 것인지는 어떻게 결정합니까? 계속 감시하는 것 말고 다른 방법 있나요?
FSM, 분기예측, GC 등 Java가 내세우는 것을은 모두 같은 특징을 갖고 있습니다.
사용자가 그에 대한 비용을 지불할 의사가 없는 경우에도 그 비용을 강요하는 것입니다.
지금까지 이 글타래를 읽어보니 Java가 desktop application에서 빛을 못 보고 있는 이유를 알 것도 같습니다.
그런 건 성능에 별로 영향 없다. / 체감할 정도의 성능 차이는 없다.
--> 사용자가 분명 느리다고 느끼고 있는데도 이렇게 얘기하는 것은 우기기밖에 안 됩니다.
저도 분명 느꼈으니까요. 전에 Java로 만든 프로그램을 실행시켰더니 정말 느렸습니다.
윈도우즈의 설치 프로그램이었는데 복잡하게 레지스트리를 건드리는 것도 아니고 그냥 파일 복사하는 정도인데도 JVM 설치부터 시작해서 한 20분 걸렸던 것 같습니다.
압축 파일이나 install shield를 썼다면 아무리 길게 잡아도 5분 이내에 끝날 일이었습니다.
게다가 JVM은 설치 이후에는 쓰지도 않을 것이었습니다.
성능에 문제가 있으면 하드웨어를 좋은 걸 쓰면 된다.
--> 일반 사용자들한테 이런 요구를 할 수 있나요?
게임 매니아 같이 하드웨어에 상당한 투자를 하는 사람들을 제외하면 말입니다.
(C코딩을 한지 오래되서 정확하지는 않을껍니다. 그냥 psedo 코드로 생각해 주세요. )
이런식으로 함수 포인터을 이용하면 모니터링 할 필요가 사라집니다. 이것 말고도 여러 방법이 있으나 다 소개 하지는 않겠습니다.
>> FSM, 분기예측, GC 등 Java가 내세우는 것을은 모두 같은 특징을 갖고 있습니다.
>> 사용자가 그에 대한 비용을 지불할 의사가 없는 경우에도 그 비용을 강요하는 것입니다.
맞습니다. 그리고 그 비용을 꾸준이 줄여 왔고, 그 결과로 여러 영역에서 C/C++과 유사또는 대등 이상의 성능을 내게 되었다는 것 역시도 사실입니다.
음.. 자꾸 오해가 있으셔서 말씀 드립니다만, 저는 자바가 무조건 C/C++보다 빠르다고 주장하는 게 아닙니다.
C/C++이 무조건 자바보다 빠르다는 주장이 틀렸다고 말씀드리는 것 뿐입니다.
그리고 자바가 그런 상태에 오기까지 쌓아 올린 여러 기술적 노하우중 제가 아는 몇가지를 말씀 드린 것이고요.
>>필요없다고 말씀드린적은 없습니다만. 다만 switch문(등의 비교문)의 실행이 변경이 일어나거나 이벤트가 발생할때만 상태판단비용이 필요할뿐, 매 루프마다 요구되지 않게 된다고 말씀드렸습니다.
매우당황스럽군요..당연히 이벤트발생할때만 해야지 그럼 이벤트도 발생하지 않는데 혼자 루프도는걸누가 만듭니까?
C는무슨 이밴트도 없는데 무한루프 돌고 있을줄압니까?
그리고 님코드 이밴트발생할때마다 루프돕니다. 당연한말이구요..
따라서 매루프마다 상태판단하게되있습니다.
또한 코드를보니 어처구니 없이 비효율적입니다.
저런식이라면 저루틴에서만 C보다 수천%이상 지연현상일어납니다.
그리고 그밑에 두코드는..
일단 코드(하는기능,역할)이 틀립니다. 밑에는 0,1 외에는 오류가 발생하지만 위코드는 그렇지 않습니다.
동일한 기능수행을두고 비교를따져야지 수행자체가틀린것을 따지셨군요..
또한 위코드를보면 첫번째는 비교후 함수를 다이렉트로수행하지만.
두번째는 포인터함수배열에 저장되어진 포인터로뛰어가는 중간철차를거치게됩니다.
즉,위코드도 저런단순비교는 switch case 로해야지요 그럴경우는 아래코드보다 오히려 더효율적입니다.
그리고, 아래코드가 무슨 자바 vm 에서만 수행되는것으로 아시는데.
아래코드는 C에서 함수포인터의 대표적활용이라할수 있습니다.
또한 수행중에 일반코드를 저런식으로 수행해야겠다고 판단하고 코드를 바꾸어 수행한다는자체가 얼마나 비효율적입니까.
그건 비용이 훨씬많이 들지요.
제가 말씀 드리는 내용은 모두 분기예측 최적화에 대한 내용입니다.
물론 이 과정은 HOT-SPOT이라고 부르는 퍼포먼스를 많이 소모하는 부분에 대해서 수행됩니다.
(이 HOT-SPOT을 추적하는 것 자체는 추가 적인 비용이 듭니다만, 많은 최적화를 통해서 대단히 미비한 비용입니다.)
HOT-SPOT에 해당하는 영역에 대해 JIT를 통해 native컴파일된 코드를 사용하는데 이 과정에서 분기예측을 수행하고 FSM에 기반한 최적화를 수행합니다.(여기까지는 분명히 비용이 발생합니다.) 물론 분기 예측 최적화 이외에서 다양한 실시간 최적화 기법이 있습니다만, 여기에서는 이것만 떼어 놓고 이야기 하는 중이죠.
님께서는 이렇게 했을때 성능향상이 있다는 것을 믿기 어렵다는 입장이신 것이고요.
게임 로직을 하나 들겠습니다.
void run(){
while(isGameGoing) {
if (isGameShowing) {
switch (gameMode) {
case INITIALIZING: init();break;
case OPENING: showOpening(); break;
case MAIN_MENU: showMainMenu(); break;
case PAYING: play(); break;
case PAUSEL pause(); break;
}
}
}
closing();
}
매우 일반적인 코드이며, OOP형태의 FSM을 직접 바꿀수도 있습니다만, 지금은 그냥 저 코드로 나가죠.
처음에는 위의 코드가 인터프리트형태로 그냥 실행 됩니다.
어느정도 수행이 되다보면 JIT에 의해서 동일한 의미를 가지는 네이티브 코드로 컴파일 되어 수행 됩니다. (물론 컴파일 자체에는 비용이 수반됩니다만, 그 이후에 얻어지는 성능 향상으로 대부분 상쇄된다고 볼수 있습니다)
위의 코드는 메인 루프이기 때문에 매우 빈번하게 실행되며 따라서 HOT-SPOT으로 탐지되게 됩니다(물론 이 과정도 미비하게 나마 비용이 들어 갑니다)
내부적으로 분기 예측을 수행하여 위의 코드를 FSM으로 분해 합니다.
FSM의 상태는
SHOWING_XXXX,
NOT_SHOWING_XXX
두가지 군으로 나누어 질 겁니다.
그래서 FSM형태로 구분한 각각의 STATE을 수행시킵니다.
하지만 대부분의 시간은 SHOWING_PLAYING을 수행 할 겁니다. HOT_SPOT은 이 것을 알아내면(물론 여기도 비용이 들어갑니다)
추가적인 프로시져를 동적으로 만들어 냅니다.
void run() {
play();
}
물론 이 프로시져는 의미를 보이기 위해 소스 코드 형태일뿐 실제로는 네이티브 컴파일된 기계어입니다.
HOST Spot은 상태가 변경될때 까지 이 코드를 호출하게 됩니다.
물론 상태가 바뀌면 기존의 JIT로 네이티브 컴파일된 FSM의 코드를 호출하는 것이지요.
이런 것이 C언어로 구현된게 아닌, 어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다. 단순히 함수 포인터가 아니고요. 의미상으로는 C의 함수 포인터와 같습니다만, 실제로는 CPU 아케텍쳐마다 어셈을 이용하여 최적화된 실행 제어를 수행하고 있습니다.
이렇게 되었을때 SHOWING_PLAY가 지속되는 시간이 길어 질수록 부가 비용이 상쇄되고 어느 시점에 이르면 원래 코드의 네이티브 버전 보다 빠르게 동작합니다.
몰룬 여기에서 중요한것은 HOT_SPOT을 판단하는 휴리스틱과, JIT가 만들어 내는 네이티브코드의 효율성, 그리고 부가 비용의 최소화입니만, 자바는 이미 충분할 정도로 진화해 왔고 앞으로도 진화해 나갈것입니다.
제가 설명 드린 것은 어디까지나 아이디어 입니다. 실제 구현이 매우 복잡하기 때문에 어디 한부분만 딱 떼다가 설명드리기 어렵습니다. 어셈이 많이 사용되었기도 하고 내용이 상당히 방대하기 때문입니다.. 그래서 제가 할수 있는 것은 "이러 이러한 아이디어에 기반한 구현을 가지고 있다"라고 설명드릴수 뿐이 없습니다.
제가 함수 포인터가 C/C++의 일반적인 장점이자 자주 사용되는 기법인줄 모르겠습니까?
포인터배열이 비용을 더 소비한다는 것을 모르겠습니까?
아이디어로 제시된 내용을 "실제 구현인양" 곡해하시면 대화가 않됩니다. ^^
(실제 구현을 보고 싶으시면 http://www.sun.com/software/opensource/java/ 에서 JVM을 다운 받아 보시면 됩니다.C/C++/어셈 이니 C하는 분들은 재미있게 보실수 있을 겁니다. )
FSM을 기반으로 하여 실행경로를 조각내고, HOT-SPOT인 특정 실행 경로만을 수행하는 네이티브 코드를 만들어 실해하게 하는것이 분기예측 최적화의 기본 아이디어 입니다.
FSM의 상태 변화는 값에 의해 수행 할수 있다는 것을 간단하게 보여 드렸고요.(이것도 아이디어로 제시한 것일뿐입니다. 실제로는 어셈으로 구현된 부분에 있다고 추정하고 있습니다. 제가 여태까지 JVM 소스을 본 바로는요)
대화가 비슷한내용에 계속 맴도는데요..
위에서도 님께서 비용이수반됨을 인정하신부분이 있습니다.
"이런 것이 C언어로 구현된게 아닌, 어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다. 단순히 함수 포인터가 아니고요. 의미상으로는 C의 함수 포인터와 같습니다만, 실제로는 CPU 아케텍쳐마다 어셈을 이용하여 최적화된 실행 제어를 수행하고 있습니다."
답답하십니다.. 이말도 매우 의미 없는 소리입니다..
"이렇게 되었을때 SHOWING_PLAY가 지속되는 시간이 길어 질수록 부가 비용이 상쇄되고 어느 시점에 이르면 원래 코드의 네이티브 버전 보다 빠르게 동작합니다. "
이건 java 상에서의 비교이겠죠.. 다른언어(예를들어C라던가) 보다 더 빠르게 동작했다면 실 예를 좀보여주시죠..
결론은 이것하나만 말씀드리고 싶습니다. 어떤사건이발생하기전에 그사건에서 예측할수 있는것이 있다면 그예측을 미리 대비해두는것 이외의 것은 사건이 발생한후에 예측하는것에는 언제나 다시 예측비용이 수반됩니다.
비용을 들이지 않아도 되는것과 자신의 의지와 무관하게 비용이들어가는것과 차이입니다.
일단 대화가 비슷한내용에서 맴도는거 같으니 실례나 어떤 검증된근거가 있다면 보여주시고..
아니면 대충여기서 저는 마무리 하겠습니다.
"오히려 제쪽에서 이렇게 했을때 진짜로 빨라지지 않는다는 주장의 근거를 보고 싶습니다."
님의 주장은 참 너무 황당합니다.
시로운시도나 주장은 하시는쪽에서 어떤 근거자료를 내놓아야합니다.
어떤사람이 내가 이새로운기계를 만들었는데 이것은 매우뛰어나다..뛰어난이유나 자료가 있습니까? 란질문에..
그럼 안뛰어나다는 증거를 대봐라고한다면 너무 어처구니 없다고 생각지 않나요?
그래서 C/C++과의 성능차를 극복하기 위해 다양한 아이디어가 나왔고
그중에 가장 근본적인 아이디어는 "추가 비용 10을 사용하여 전체 성능을 20이상 끌어 올릴수 있다면 추가비용을 지불해서라도 전체 성능을 끌어 올리자"라는 것입니다.
그래서 나온것이 JIT였고 HOT-SPOT 엔진입니다.
이것들로 인한 성능 향상은 대단했고 C/C++과의 성능차를 엄청나게 매꿀수 있었습니다. 심지어 일부 영역에서는 C/C++보다 빠르기도 하게 되었습니다. 물론 전체 영역을 살펴 본다면 여전히 격차가 있습니다만, 이제는 그 격차때문에 자바를 포기하지 않아도 될 정도까지는 발전해왔습니다.
여기까지가 사실(Fact)입니다.
그런데 님께서는 "추가 비용이 있는데 어떻게 더 빨라 지냐?"라는 머리속의 생각때문에 사실을 무시하고 주장만 하고 계신거죠.
"자바는 인터프리터인데 어떻게 컴파일 된 코드보다 빨라지냐"라던가 "레이어가 하나 더 있는데 어떻게 더 빨라지는데?"라는 것과 유사한 오류를 범하고 계신거죠.
그래서 제가 처음에 "접근 방식을 바꾸어 상당한 성능향상을 이루어 낼수 있는 것을 부정하느냐?"라는 취지의 질문을 했던 겁니다.
사실(Fact)을 보세요. 저는 그 사실이 어떻게 해서 얻어질수 있었나를 설명하는데 님께서는 "그 사실은 내 생각에 거짓말이야"라고 주장하고 계신것일 뿐입니다.
이미 다른 분이 자바가 C보다 일부 영역에서 빠르다라는 벤치마크를 올려 주셨습니다.
그럼 님께서는 자바는 어떤 경우에도 C/C++보다 빠를수 없다는 주장을 뒷받침해 줄 근거와 벤치마크를 보여주셔야 자신의 주장을 말할수 있는 거겠죠.
님은 막연히 당연히자신들의것을 호도하기위해 광고성주장을 펼치는그들의 주장을 무비판적으로 받아들이고 이미 그것을 너무 믿어버린나머지 다른이의 비판을 받아들이기 싫은겁니다.
님이야말로 사실을 보셔야합니다.
님이 링크건 벤치마크 소스를 살펴보니 템플린라이브러리함수를 호출합니다.즉 저런소스보다 결과적으론 그라이브러리 함수의 성능비교가된것입니다.
저기올려진소스는 이미 무의미하다는소리죠..
라이브러리가 구체적으로 동일한 작동을할지 안할지는 내부소스를 열어봐야 알겠지만.
일단 벤치마크라고 올린 소스가 실제 동일한조건인지 알수도 없는소스를 올려두고 벤치마크라하는것이 참...
정상적인 벤치마크가 되기위해선 완전히 동일한 동작을하는 함수를 콜했다는 조건이있던지..
아니면 직접구현한함수를 호출해야할것입니다.
저런식의 테스트는 눈속임에 불과할수도 있습니다.
'이런 저런 기술을 통해 자바가 C/C++보다 빠른 경우도 있다'라는 온건한 주장에 대해선 온갖 링크와 증거를 요구하면서 '자바는 절대 C/C++보다 빠를 수 없다'라거나 '자바는 너무 느려서 실무에서 절대 못쓴다', 혹은 '자바가 빠르다는 벤치마크는 모두 부정확하거나 마케팅적 의도로 조작했을 것이다'라는 훨씬 과격한 주장들은 아무런 근거 없이 믿어야 하는 건가요?
좋습니다. 님의 충고대로 '자바가 비즈니스 어플을 만드는 데 많이 쓰일 만큼 빠르고 또 경우에 따라선 C/C++보다 빠를 수 있다'라는 주장을 '비판적'으로 '냉정히' 받아들이도록 노력해 보겠습니다.
그럼 님께서는 '자바는 절대로 C/C++보다 빠를 수 없고 이에 어긋나는 벤치마크는 모두 부정확하거나 의도적으로 왜곡된 것이다, 또 실무에서는 느려서 절대로 쓸 수 없다'라는 주장을 '비판적'이고 '냉정하게' 생각해보실 의향이 있는지요? (실무에 쓸 수 없다는 부분에 대해선 님께서도 다른 익명 분들 의견에 동의하시는 지 모르겠습니다)
그런 연후에도 주장을 굽히지 않으실 것이라면 한 번 시간 나실 때 인터넷 상에 그런 생각을 잘 정리해서 올려 보시기를 권해드립니다. /. 같은데 올려서 지금도 진실을 깨닫지 못하고 '썬의 농간에 놀아나고 있는' 수많은 전문 자바 개발자들이나 아키텍트들을 계몽하실 수 있다면 아마 전세계적으로 이름을 날릴 수 있을 것 같습니다.
그런 입장이시라면 제 생각과 사실상 차이가 없습니다. right tool for the right job이겠지요. 익명 글도 넘쳐나고, 위에서 자바가 C보다 8배, 50배 느리다거나 미션크리티컬한 곳에 쓸 수 없다거나 하는 등의 이야기가 워낙 많이 나와서 논점이 섞여버렸군요. HotSpot/JIT에 대한 부분을 제외한다면, 윗 글의 내용에는 저도 역시 동의합니다.
"해당 벤치마크에서 리스트, 해쉬테이블등의 라이브러리는 어셈으로 최적화된 코드가 아니고
순수 자바코드로 만들어진 코드입니다. 어셈으로 된 코드를 call해서 빨라지는게 아닙니다. "
저윗쪽글에 "어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다." 라고 하셨기에 말씀드린겁니다.
모든게 어셈으로 구현되었다는말이아니구요.
"처음부터 말씀드렸습니다만, JVM 자체가 C/C++, 어셈으로 되어 있기 때문에 C/C++이 JVM에서 수행하고 있는 온갖종류의 최적화를 다하고 그외의 최적화를 한다먄 당연히 C/C++이 빠를 겁니다.
그걸 매번 다 하실겁니까? "
처음부터 말씀드렸습니다. JVM에서 수행하고 일부 행동들... 그렇게 안해도 더빠르며 그렇게 안하는게 더빠르다입니다.
즉, C에서 최적화 하지 않은것은 안하는것이 더유리하기 때문이며 수행중일어나는 최적화는 부가적인 비용이들어가기때문에 그로인한부가비용이 들어간다입니다.
같은 질문을 계속하시네요..
자기 생각만 주장하지 마시고 이런 벤치마크에서 자바가 우위를 차지 했던 영역에 대해 C++이 더 빠르게 나온 최근 벤치마크 자료라도 좀 들고 나와 보세요. 그리고 논리적인 근거나 아이디어도 좀 제시해 보시고요. 저도 그런 자료를 좀 보고 싶습니다. 저도 좀더 정확하게 내용을 파악해야 하지 않겠습니까?
플랫폼은 어플리케이션이 동작하기 위한 기반이며, 플랫폼이 주는 장점과 더불어 단점을 "그냥 수용할수 밖에 없는" 것입니다.
만약 C로 어플리케이션을 만드신다면,
CPU+OS+API+Compiler 가 플랫폼이 됩니다.
자바로 어플리케이션을 만든다면
CPU+OS+JVM+API+compiler가 플랫폼이지요.
플랫폼이 주는 장단점은 그냥 받아들여야 하는 겁니다.
8086으로 프로그램을 만들면 무슨 수를 쓰던지간에 부동소수점연산은 에뮬레이션이 됩니다. CPU에 바로 부동소수점연산을 맡길수가 없습니다.
윈도우즈기반의 어플리케이션을 만들면 OSX나 리눅스에서 돌아가지 않습니다.
GCC로 최적화옵션을 아무리 주어도 Intel C Compiler에 비해 평균적으로 상당히 느리게 돌아가는 실행파일을 얻을수 밖에 없습니다.
이게 플랫폼의 특성입니다.
그렇기 때문에 C로 프로그램을 만든다고 해도 단순히 C 프로그램이 아닙니다. x586기반의 리눅스에서 gcc 3.0으로 컴파일한 c 프로그램인 겁니다.
플랫폼의 내부에 대해서는 불평은 할수 있을 지언정(오픈소스 OS라면 직접 고치는 방법도 있겠지요) 바꿀수는 없습니다.
따라서 java vs C++ 벤치마크란 실제로는 동일한 CPU, 동일한 OS을 기반으로 하는, C 플랫폼과 자바 플랫폼의 벤치마크가 되는 겁니다.
그렇게 각 플랫폼 별로 유사/동일 알고리즘을 가지는 어플리케이션의 벤치마크 결과가 나왔는데 결과가 맘에 않든다고 플랫폼의 내부때문이라고, C는 절대 않느리다고 말하는 것은 참으로 어불성설입니다.
그렇게 주장하는 것은 "이 코드가 느린건 윈도우즈 때문이야. 윈도우즈 내부의 코드를 비교해 봐야 정확한 걸 알수 있어"라고 주장하는 것과 마찬가지입니다. 유사하게 "이 코드가 느린건 CPU때문이야. CPU가 레지스터를 어떻게 처리하는지 회로를 봐야 정확한 걸 알수 있어".
플랫폼은 제약입니다. 받아 들이세요.
웹서버의 성능을 측정하는데, 웹서버의 구현 코드를 들여다 볼 필요가 있나요? 아닙니다.
성능 벤치마크란 블랙박스 테스트 일수록 정확한 겁니다.
블랙 박스에 대고 다양한 테스트를 진행하여 최고/최저/평균 성능을 얻어내는게 중요한겁니다.
그 내부에서 어떻게 돌아가던지 말입니다.
테스트 자체에 대해서는 왈가왈부 할수 있겠지요. 하지만 블랙 박스 내부에 대해서 왈가왈부 하면 큰 실수를 하는 겁니다.
>> 그래봐야 더빠르긴 힘들며
그러니까 JIT+HOT Spot engine의 그 수많은 최적화 에도 불구하고 더 빠르기 힘들다는 이론적 근거와 자료를 제시해 주세요.
더 빠를수 있다/빠르다라는 근거와 자료는 이미 많이 제시 하였습니다. 그밖에도 HOT Spot 휴리스틱과 JIT Adoptation 에 대해 매년 많은 수의 논문이 발표 되고 있다는 것도 사실이니까요.
>> 일단 비관적입니다.
>> 예를들어 불필요한 분기문이 있었다칩시다.. 그걸예측판단 하는데는 비용이 들지 않았을까요?
>> 또한 프로그래머 입장에선 그것을 예측해서 코딩했어야하지 않았을까요?
여기에 대해 저는 불피료한 분기문이 아니였다고 답변 드렸습니다.
>> 상태머신은 항상 상태판단 비용이들지만.
>> 그냥하면 그런비용은 없습니다.
그냥한다는게 무엇인지 실제코드로 보이신적은 없습니다만, 상태머신이 "항상" 상태판단비용이 든다는 것이 아니라는 것은 나중에 님도 동의 하신 부분입니다.
>> 매우당황스럽군요..당연히 이벤트발생할때만 해야지 그럼 이벤트도 발생하지 않는데 혼자 루프도는걸누가 만듭니까?
>> C는무슨 이밴트도 없는데 무한루프 돌고 있을줄압니까?
>> 그리고 님코드 이밴트발생할때마다 루프돕니다. 당연한말이구요..
>> 따라서 매루프마다 상태판단하게되있습니다.
이것에 대한것도 실제 코드로 상태가 가끔 변경되지만 매 실행루프마다 상태 판단하지 않는 코드를 예시로 들어 드렸습니다.
>> 이건 java 상에서의 비교이겠죠.. 다른언어(예를들어C라던가) 보다 더 빠르게 동작했다면 실 예를 좀보여주시죠..
>> 위에서 말한 실례라는것은 실제 벤치마그된예..벤치마그 링크걸어달라는겁니다.
>> 여러차례 테스트되었다면 많을것 아닙니까? 웬만하면 한글페이지 링크걸어주시고.
이것 때문에 플랫폼을 이해하지 못하고 계시다는 말씀을 드린 겁니다. 자바에서 코사인 계산하는데 java.lang.Math.cos 말고 뭘 호출할까요?
>> 일단 벤치마크라고 올린 소스가 실제 동일한조건인지 알수도 없는소스를 올려두고 벤치마크라하는것이 참...
>> 정상적인 벤치마크가 되기위해선 완전히 동일한 동작을하는 함수를 콜했다는 조건이있던지..
>> 아니면 직접구현한함수를 호출해야할것입니다.
>> 저런식의 테스트는 눈속임에 불과할수도 있습니다.
제시된 벤치마크는 플랫폼간 벤치마크이기때문에 완전히 동일한 환경일수가 없습니다. 그런 것은 알고리즘 벤치마크때나 가능한 이야기 입니다. 이런 차이점도 인식하지 못하고 완전히 동일하지 않다라는 이유떄문에 눈속임에 불과하다라고 말하고 계신거죠.
>> 또한 구글링해서 많이도 나오겠죠.. 하지만 저많은것들을 일일이 다까발려 알려드리고 싶어도.. 그럴시간이 없는게 안타깝군요..
여기에 글쓰시는 시간의 아주 일부만 사용하셔서 구글링해도 님의 주장을 옹호할수 있는 벤치마크 자료 하나는 찾았을 겁니다.
>> 또한 웃긴게 일부 모듈을 어셈으로작성된 코드를 call 해서 빨라졌다면 그게 자바인가요?
>> 그렇게 콜한다면 c나 스크립트조차도 콜할수 있습니다. 그렇다면 누가더빠른가요?
>> 그걸두고 자바가 빨라졌다? 말할수 있는겁니까?
이것역시 플랫폼을 이해하지 못했기 때문에 나온 말씀이죠. 내가 짠 코드가 실행시간에 자바플랫폼에 의해 과거보다 더 빨리 동작하면 "자바가 빨라졌다"라고 말하는 겁니다.
>> 처음부터 말씀드렸습니다. JVM에서 수행하고 일부 행동들... 그렇게 안해도 더빠르며 그렇게 안하는게 더빠르다입니다.
>> 즉, C에서 최적화 하지 않은것은 안하는것이 더유리하기 때문이며 수행중일어나는 최적화는 부가적인 비용이들어가기때문에 그로인한부가비용이 들어간다입니다.
부가비용이 발생하는 것을 부정한적은 단 한번도 없습니다. 그리고 제가 주장하고 여러 자료로 제시한 것은 부가비용을 투자해서, 원래보다 더 빠른 성능을 얻을수 있는 방법이 존재한다. 라는 겁니다. 이걸 부정하시나요?
>> 제가 하나하나 잘못되었음을 여테 다짚어드렸습니다.
여태까지 지적하셨다고 하는 부분을 모두 요약해 보았습니다만, 제대로 짚었다고 할만한 곳이 없습니다. 게다가 어디에도 근거는 없습니다. 모두 님의 개인적인 생각에 기반한 독자적인 주장이실 뿐입니다.
부디 "부가 비용을 투자하면 절대로 원래보다 빨라질수 없다" 라는 님의 주장을 뒷받침할수 있는 이론과 자료를 제시해 주시기 바랍니다.
>> 거의 실제적인것보다 말로떼우죠
님은 말로 떼우고 계시는 군요.
>> 직접해보라면 되는것하나도 없고.
아이디어도 설명해 드렸고, 벤치마크도 보여드렸고, 소스코드도 보여드렸고, JVM Source도 알려 드렸습니다.
그리고 실제 적용 사례와 경험담도 제시해 드렸습니다.
오히려 제쪽에서 직접 해보시라고 권하는데 나오는 근거나 자료는 하나도 없는 상태군요.
>> 어쨋거나 님은 재대로된예를 하나도 보이지 못하셨습니다. 다른예도 다마찬가지겠죠..
제 실력이 부족해서 JVM source의 정확한 위치를 딱 짚어 말씀드리지 못하는 것은 죄송합니다만,
벤치마크의 예가 제대로 된 예가 아니라고 생각하십니까? 아니면 중간에 넣어드린 논문도요?
>> 실제도 안되고 이론도 밀리면 멀로 먹겠습니까 그점은 이해합니다.
저야말로 님을 잘 이해하고 있습니다.
ps. 제가 왜 님과 이런 고전적이고 이미 한물간,결론까지 이미 한참전에 난 플레임을 계속하는지 아십니까?
근데....여기 토론 하시는 분들은 c,c++ 그리고 java 는 둘다 능숙하게들 써보셨나요
근데
여기 토론 하시는 분들은 c,c++ 그리고 java 는 둘다 능숙하게들 다루시나요?
그리고 아까부터 쟁점이 됐던....극한(?)의 상태를 두 언어로 처리해본 경험이 있으신가요?
그냥 궁금해서.....................
미국에서 일하는데요...
>그런데도 한국에서는 문제없이 사용되는 이유는 한국은 아직까지 극한의 기술을 사용하지 않는 그저그런 웹사이트 처리뿐이고
>SW 의 기술보다 HW 에 우위를 두는 이상한 현상때문이죠. 설계감사에서 보다보면 도저히 성능이 안나올거 같아서 물어보면
>대답은 한결같더군요. HW 를 더 고사양으로 올리죠. 이거 미국에서였으면 boss 한테 짐싸라는 소리 나옵니다.
하드왜어 업그래이드로 커버가 되는 문제들을 굳이 소프트왜어로 해결하려고 하지 않는 회사들 많이 봐왔습니다만...
그냥 경험상 무책임하게 수치화 하자면
하나의 일을 숫행하는 시간이
ASM의 속도가 100이라 하면
C는 100~300 정도,
C++은 100~1000 정도의 속도
JAVA는 200~5000 정도의 속도를 내는 것 같습니다.
이정도면 꽤 차이 나는것 같기도 하지만
같은 언어를 사용하더라도 사용자에 따라
잘 짜면 속도가 300정도 나오는 것을
엉터리로 짜서 9999999999999(또는 이보다 길게)
니오는 경우가 허다 합니다.
장비에 의한 차이도 언어의 선택보다 몇배 중요 하구요.
게임 만드는것 (그것도 그래픽이 꽤나 현란한 것)만 아니면
차이 없다고 봐도 무방합니다. 그리고 네트워크는 속도가 비슷하면서 자바쪽이 세련됙 쉽구요.
...
자바가 C(or C++?) 보다 8배 느리다?
맞다.
단 개발기간은
자바가 C보다 8만배 빠르다.
근거가
근거가 있는가요?
개발기간이 짧다고 어떻게 비교된건가요..?
제가볼땐 자바소스가 좀더 길게 작성하는경향이 있는거 같던데..
물론 소스길이가 개발기간의 기간과 비례하는건 아니지만..
일단 코딩량은 더많아 보이더군요..
더구나 포인터라는 도구도 없어 더욱불편할것같고..
무슨근거인가요? 뭔가 비교된자료가 있으시면 부탁..
----------------------------------------------------------------------------
개발기간
객관적으로나 제 주관적인 경험을 통해서나, Java가 개발시간을 현저히 빠르게 해주는건 사실이 아닐까싶네요.
뭐 여러가지 이유가 있겠지만 우선 가장 중요한건 기본적으로 제공되는 툴 클래스들이 워낙 많고, 왠만큼 보편적인 상황을 위한 클래스들을 왭에서 쉽게 찾을수 있다는거겠죠.
또 Java의 강점중엔 "하나의 Compile 환경"도 있겠죠.
전 세계의 개발자들이 많든 여러 다른 jar들을 아주 손쉽게 이용할수 있다는거... 이거 아주 매력적이에요.
C나 C++에서는 컴파일 환경을 구축하는데만 몇일을 소비하는 경우도 종종 생기고, 꼭 써야되는 라이브러리에서 STL을 금지해서 내가 쓰지 못하는 경우도 생기고... 다시 말해 "예기치 못한 상황"들이 Java보단 C/C++에서 훨씬 더 많이 발생하는것 같아요.
> 일단 코딩량은 더많아 보이더군요..
아마 getter/setter의 남용이나 operator 오버로딩을 대체하는 method들등 Java만의 문제점들을 많이 보신것 같은데요..., 이런건 Eclipse나 IntelliJ 같은 IDE들이 매크로로 생성해주는 경우가 많으니까 눈감아줄수 있지않을까요? (몇년전에 Emacs에 Java 매크로들 설치하려다 결국 포기해버린 기억이 나네요. ^^)
> 더구나 포인터라는 도구도 없어 더욱불편할것같고..
물론 상황에 따라 포인터가 참 편리하게 쓰이기도 하지만, 어쩔땐 내가 불장난을 하고 있단 생각이 들기도하지요.
포인터 없이 Reference만으로도 충분히 훌륭한 프로그램 동일한 시간에 개발 가능합니다. Reference에 익숙해 지시면 C/C++에서도 은근히 포인터를 외면하게 되기도 하지요. (포인터 연산이 아예 필요하지 않게 말이에요.)
물론 개발자로서의 "쾌락"은 C/C++을 만질때 훨씬 더 크긴하지요. ^_^
여담이지만
C++ 쓰면서 불필요하게 포인터 연산 안쓰고도 잘 개발했습니다만은...?
꼭써야 하는 경우에는 바이너리 파일을 직접 읽어서 어케 조작할때나 쓰일거 같은데
멍청하게 포인터조작을 하지 않고 , 꼭 써야하는데 쓴다면 포인터는 배이면 백 득이지 손해는 아닙니다
포인터를 기본적으로 못쓰는게 더 불편할뿐이죠
흠...
1부터 2^31-1 까지 유효한 소수를 에라스토테네스의 체 방법으로 푸는데 걸리는
시간을 같은 알고리즘을 사용해서 푸는 시간을 비교해보면 대충 알 수 있겠네요 -.-;;
(너무 단편적인가요?)
흠
글 삭제는 어떻게 하는지 모르겠네요.
이를태면...
글쌔요. 전 어느쪽의 언어든 하진 못하지만(C의 경우는 손 놓은지 10여년, 지금은 IT쪽 근무도 아님)
하지만 이런 것 아닐까요.
하나는 출퇴근을 하건 출장을 가건 이사가서 옆집에 떡을 돌라주건 기사를 불러 운전을 시키고,
하나는 그 모든 경우에 직접 운전해갑니다. 물론 길을 모르면 낭폐입니다.
단지, 빠르다 느리다의 문제라면 아무래도 컴파일 언어가 더 빠르지 않을까요.
문제는 만들고자 하는 것(업무)를 이해하고 기간내에 적용 완성시키는 것은 별개의 문제라고 봅니다.
인천의 나사 풀린 산호...
인천의 나사 풀린 산호...
유지 / 보수를 생각한다면
저라면 자바에 한표
임베디드같은 극한의 상황이 아니고서야 자바도 제법 빨라진 덕에
성능차이가 심각한 수준은 절대 아닙니다.
그래도 자바가 C보다는 '대체적으로' 느립니다.
흠 논제가...
Java 가 C 보다 느리다...
인지...
Java 가 C 보다 8배 느리다...
인지 모르겠습니다...
여기에는 몇 가지 가정이 더 들어가야 명확한 토론이 될 것 같습니다...
[ 어떤 경우에 ] Java가 C보다 느리다... 정도로 하는게.. 더 알맞는 논제이지 않을까요?
밥아저씨는 어떻게 이야기했나?
아래와 같은 코드를 작성하면 자바와 c++은 성능 차이가 거의 없습니다. 직접 돌려보세요~
자세한 내용은 아래에~ 제가 제일 존경하는 밥아저씨의 말씀.
http://butunclebob.com/ArticleS.UncleBob.SpeedOfJavaCppRuby
Ruby require 'benchmark' def sievePerformance(n) r = Benchmark.realtime() do sieve = Array.new(n,true) sieve[0..1] = [false,false] 2.upto(Integer(Math.sqrt(n)) do |i| if sieve[i] (2*i).step(n,i) do |j| sieve[j] = false end end end end r end Java public class GeneratePrimes { public static double generate(int max) { long start = System.currentTimeMillis(); boolean sieve[] = new boolean[max]; Arrays.fill(sieve, true); sieve[0] = false; sieve[1] = false; for (int i = 2; i < Math.sqrt(max); i++) { if (sieve[i]) { for (int j = 2*i; j < sieve.length; j+=i) { sieve[j]= false; } } } return (System.currentTimeMillis() - start)/1000.0; } C++ #include <iostream>> #include <math.h> #include <sys/time.h> using namespace std; double generate(int max) { struct timeval start; struct timezone tz; gettimeofday(&start, &tz); bool *sieve = new bool[max]; for (int i=0; i<max; i++) sieve[i] = true; sieve[0] = false; sieve[1] = false; for (int n=2; n<sqrt(max); n++) { if (sieve[n]) { for (int j=2*n; j<max; j+=n) sieve[j] = false; } } struct timeval end; gettimeofday(&end, &tz); double startSecond = start.tv_usec/1000000.0; double endSecond = (end.tv_sec - start.tv_sec) + end.tv_usec/1000000.0; return endSecond - startSecond; } int main(int ac, char** av) { for (int i=100000; i<=5000000; i+=100000) { double time = generate(i); cout << time << endl; } }사실 C/C++/Java간의
사실 C/C++/Java간의 속도 차이에 대해서는 별다른 관심은 없습니다만 벤치마킹 결과가 궁금해서 돌려봤습니다.
그런데 C++ 코드 쪽을 보니 메모리 할당만 있고 해제가 없더군요. 이런 경우를 정상적인 C++ 코드라고 보긴 힘들지요. :) 정상적인 C++ 코드로 만들려면 해제 코드도 넣어주는 (a) 방법이 있고 별도의 컨테이너를 쓰는 (b) 방법이 있을 텐데, (b) 쪽에 대해서는
std::vector<bool>(b1) 과std::deque<bool>(b2) 두 종류의 컨테이너를 사용해 돌려봤습니다. 결과는 아래 그림에 나와있습니다만, 요약하자면 해당 C++ 코드는 Java 코드에 비해(a), (b2): 속도가 거의 같습니다.
(b1): 큰 N에 대해 속도가 대략 4배쯤 빠릅니다.
측정한 시스템의 구성은 아래와 같습니다.
Pentium M 1.7GHz, 2GB RAM
Gentoo Linux 2006.1
gcc-4.1.1-r1
sun-jdk-1.5.0.09 (blackdown-jdk-1.4.2 도 써 봤습니다만 양쪽 다 결과는 거의 같습니다.)
std::vector<bool> 은
std::vector<bool> 은 쓰시면 곤란합니다. (Effective STL #18)
그럼 비교할 만한건 짙은 파란색[a]이군요.
알고 있습니다. :)
알고 있습니다. :) vector 와 deque 두 개의 컨테이너를 다 테스트한 이유 중 하나가 그것입니다. (미리 적어둘 걸 그랬나보군요.) 그리고 이 경우에는 Effective STL 을 고려하더라도 굳이 vector를 비교에서 제외할 이유는 별로 없는 것 같습니다.
====
기억에 의존해서만 적기엔 좀 뭐해서 집에 돌아와 ESTL을 다시 뒤져보고 추가로 적습니다. ESTL #18에서는
1.
vector<bool>에는 실제로bool이 들어 있지 않다.2.
vector<bool>은 STL 컨테이너가 아니다. STL 컨테이너의 요구사항을 만족시키지 않는다.하지만 위 두 가지 이유는 모두 이 경우에는 적용되지 않습니다. 이 경우에는
vector<bool>에 실제로bool이 들어 있든 안 들어 있든 상관할 필요가 없죠. 오로지 bit를 넣고 뺄 필요가 있을 뿐입니다. 또한 iterator, reference, pointer라든가 STL 알고리듬 등을 따로 이용하지 않는다면 요구사항을 만족시키든 못 만족시키든 상관 없이 잘 동작할 수도 있습니다.Scott Meyers 본인도 ESTL의 머리말에서 말하고 있듯이
결과를 보면 java나
결과를 보면 java나 C++이나 차이가 없으니 java가 느리다는 속설은 허구네요.
그런데 코드를 비교해봐도 별로 다를 것이 없군요.
그렇다면 java의 개발 기간이 빠르다는 것도 허구?
속도는 경우에 따라
속도는 경우에 따라 자바가 느릴 수도 빠를 수도 있고, 또 그 차이가 해당 프로젝트에서 문제가 될 수도 안될 수도 있습니다.
생산성은 얼마나 코드를 짧게 쓸 수 있느냐에 따라 좌우되진 않습니다. 또 간단한 벤치마크 알고리즘에서 차이가 나진 않겠죠...
제 말이 그
제 말이 그 말입니다.
저딴 걸 벤치마킹이라면서 떡하니 올려놓고 낚시질하는 밥아저씨라는 사람이 웃겨서요.
저런 마이크로
저런 마이크로 벤치마크도 의미가 있습니다. 단 성능을 이야기할 때는 한정된 조건을 두고 말해야 한다는 것일뿐이죠. 저런 벤치가 문제가 아니라 저런 벤치나 어디서 전해들을 이야기로 덮어놓고 'A가 B보다 몇 배 빠르다더라'하는 일반론을 말하는 게 문제라고 봅니다.
해당 알고리즘이 그리 허접한건 아닌디...
물론 단순히 알고리즘 하나 가지고 많은 걸 볼수는 없지만 셈플 코드 전까지 막연하게 a,b를 논하는 것보다는 생산적인거 같습니다.
http://kangcom.com/common/author/default.asp?author_id=13044
Agile Software Development, Principles, Patterns, and Practices
Agile Principles, Patterns and Practices in C#
Extreme Programming in Practice
UML for Java Programmers
Designing Object-Oriented C++ Applications using the Booch Method
등 아주 훌륭한 책도 많이 낸분이고 제가 제일 좋아하는 개발자인데 낚시질이라 하시니 OTL
자바가 어디에 어떤 형태로 주로 쓰이는지 모르시면
자바가 어디에 어떤 형태로 주로 쓰이는지 모르시면
인터넷이라도 좀 찾아보시죠.
훗.
깔려면 좀 알아보고 까든가.
주제와는 상관없지만...
위의 성능측정에서 그래프는 어떻게 작성하셨나요? 그래프 그리는 프로그램이 있나요? 궁금해서 물어봅니다
gnuplot이나 그
gnuplot이나 그 비슷한류의 프로그램일 것이라 추측합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
gnuplot 맞습니다.
gnuplot 맞습니다.
"premature optimization is
"premature optimization is the root of all evil (성급한 최적화가 만악의 근원이다)."라는 말을 많은 대가들이 언급했었습니다. 성급한 최적화가 시작되는 곳이 바로 여기(언어간 속도 논쟁)가 아닌가 합니다. 성공적으로 시장에 진입한 언어들 중에 속도가 느려서 못쓸만큼 느린 언어는 없는것같습니다만, 왜 매번 이런 플레임성 글이 올라오는지 참 의아합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
JAVA가 C/C++ 보다 빠를수도 있습니다.
JVM에 의한 메모리 관리가 그 주 이유 입니다. 아시다 시피 많은 OS에서 system call은 인터럽트로 구현되어 있습니다. 프로세서 아키텍쳐를 조금만 공부해보신 분은 다 아실테지만,
인터럽트의 처리 과정은, 다른 어떤 처리과정 보다도 복잡하고, 많은 작업을 요합니다. 또한 인터럽트 서비스 루틴에서의 처리를 위해서 시스템 영역과 유저영역 사이의 데이터 트랜스퍼 역시 많은 오버헤드가 걸리는 작업이지요.
C/C++에서의 malloc/free와 같이 system call을 수반하는 명령이 호출될때마다 이러한 엄청난 작업이 일어나지요.
Java에서는 VM에서 어느정도 똑똑하게 user 영역에서 메모리 관리를 해줍니다. 따라서 상대적으로 system call로 인한 오버헤드가 적지요.. 물론 이러한 GC에 따른 오버헤드 역시 상당했었습니다.. 예전엔.. 그러나 최신의 JVM에서는 정말 많이 개선이 되었지요.
자세한 내용은 다음 link를 참고바랍니다.
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
그래도 느린걸 어떻합니까..
JVM 이 빨라지고, 자바가 발전해서 좋아졌다고..학교나 논문에선 외치지만.
필드에서 개발하는 입장에선 아직도 터무니 없이 느립니다.
원래 목표대로 플랫폼 공유목적으로 쓰기는 좋지만.
mission ciritical / real-time 어플리케이션으로는 부적합합니다.
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
RT 용으로는
C/C++도 그다지 매력적이지 않지 않나요?
필드에서 얼마나 Java를 많이 써보셨는지 모르겠지만
Java는 이미 Mission Critical한 애플리케이션 용으로 아주 많이 쓰이고 있습니다.
http://download.microsoft.com
http://download.microsoft.com/download/7/6/c/76ca8514-aea5-4114-8820-7ab3d8bd45fb/Gartnermissioncrit.pdf
썬이 아닌 MS의 마케팅 자료에 링크된 가트너 보고서입니다. 2004년 기준으로 미국내 직원 1000명 이상 기업을 대상으로 'mission-critical application'에 사용되는 플랫폼을 조사한 내용입니다.
결론적으로 자바가 40%, 닷넷이 41% 정도 쯤이라고 합니다.
저런 조사의 수치가 100% 맞다는 이야기가 아니라 '자바는 느려서 필드에선 미션 크리티컬한 쪽에서 안쓴다'라는 건 전혀 현실과 맞지 않는다는 뜻입니다. 40%든 30%든 자바나 닷넷이 해당 분야에서 대세라는 건 사실이니까요.
[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
대세는
대세는 아무리그래봐도 자바가 느리다는것도 사실이죠...
대세를 잘
대세를 잘 모르시는군요.
님이 착각
님이 착각 하시는군요.
물론 hard real time용으로는 아직 무리죠.
hard real time은 사실 C++도 무리입니다. C나 어셈을 사용하죠.
하지만 soft real time용으로는 이미 자바가 많이 쓰입니다.
대표적인게 IPTV, 이거 기반이 자바입니다.
노키아 차세대 핸드폰 플랫폼 기반이 자바입니다.
모토롤라도 차세대 핸드폰 플랫폼이 자바입니다.
잊을만 하면 나오는
잊을만 하면 나오는 flame이군요. 일부 잘못된 오해를 바탕으로 한 황당한 주장도 있고..
무슨 근거로 Java를 그렇게 무시하는지는 모르겠지만
비즈니스 프로젝트에는 C프로젝트보다 Java프로젝트가 더 많습니다.
삼성, LG, SK, 은행, 보험 등 SI의 주요 큰손 프로젝트의 상당수는 Java입니다.
잡코리아 같은데서 SI파견업체 구직을보면 Java 모집이 가장 많습니다.
고객들이 멍청해서 느려터진 Java를 선호하는게 아닙니다.
언어간 속도비교는 무의미하다고 생각합니다. 애플릿, 스윙만이 Java의 전부가 아닙니다.
여러 하고픈말이 많지만 속도문제로 한정짓자면,
Java도 하부구조인 JVM의 진화, 캐싱, GC기술의 발전, JIT기술의 발전으로 이젠 느리지 않으며
어플리케이션 레벨에서도 멀티쓰레딩, 쓰레드풀, NewIO 등의 도움으로 효율적으로 시스템 자원을 활용합니다.
JVM의 초기 구동이나 바이트코드를 JIT가 컴파일하는데는 delay가 있지만 JIT를 통과해 기계어로 컴파일되면 C로 작성한 네이티브 코드만큼의 최적화는 기본입니다. 같은 루틴이 여러번 호출될수록 C와의 차이는 점점 줄어들게 되는것이지요. 비슷한 정도의 최적화를 거쳤다는 가정 하에 많은 Java 서버 어플리케이션은 C와 거의 비슷한 속도를 낼 수 있습니다.
그리고 JVM이 개선됨으로 속도가 향상되는건 C 컴파일러가 개선되면서 코드가 최적화되는것과 같은 원리입니다. 실제로 Sun에서 최신 cc를 발표하면서 옵티마이저를 개선해 이전 버전에 비해 수십% 향상시켰다는 보도자료도 있었습니다. 컴파일러를 변경함으로 인해 바이너리가 개선된다는건 컴파일러를 판매하는 벤더들의 공통된 주장입니다. cc가 개선되는 것처럼 JVM의 개선은 비난할게 못됩니다.
하지만 속도는 뭐니뭐니해도 메모리 증설하고 디스크를 스토리지로 바꾸고 DB를 튜닝하고 네트웍을 증설하는게 가장 저렴하게 해결할 수 있습니다. 대부분의 경우 C건 Java건 돌아가는 프로그램에 손대는건 버그만 추가할 뿐이지 들인 시간(시간은 곧 돈!)에 비해 결과가 별로 좋지 않습니다.
동적 "자동" 최적화와 정적 "수동" 최적화..
자바에서 할수 있는거 C/C++로 다 할수 있다는 거 맞습니다.
자바 JVM 자체가 C/C++로 만들어 졌으니까요.
그런데 자바 JVM에서 해주는 수많은 "자동" 최적화를 C/C++로 "수동"으로 직접 짜실 겁니까? ^^
프로그램 만들때 매번 실시간 분기예측, 유저레벨쓰래드, 유저레벨 메모리 관리, 실시간 최적화... 등등 다 해주시나요?
뭐 JVM에서 제공되고 있는 온갖 종류의 최적화를 일일히 다 해주신다면야 당연히 C/C++이 무조건 더 빠르겠죠.
ps. 실시간 분기예측을 통한 최적화같은건 정말 구현하기 어려운 거죠.
if (a==1) {
//..do 1
}
else if (a == 2) }
// do 2
}
else if (a == 3 && b ==1) {
// do 3
}
이런 복잡한 조건문이 있어도 실행시에 분기 예측에 의해 아예 조건문의 실행 없이
// do 3
만 호출해 버리는 거죠. 실행시간에만 가능한 최적화방법중에 하나죠.
이런걸 C/C++로 만들수는 있지만, 그걸 직접 매번 자신의 프로그램에 넣으실분 계세요?
이런것 말고도, 어플리케이션이 해당 CPU(AMD, 인텔등)에 최적화된 코드를 사용하게 한다던가, 대단히 많은 실행시간 최적화를 제공하고 있죠.
물론 모두 C/C++로 만들어진 JVM이 제공하는 기능이니 C/C++에서 불가능 하다는게 아닙니다.
그런 최적화를 프로그래머가 제공하느냐, 아니면, 환경에서 제공하느냐 하는 차이인 것입니다.
ps2.
>> Java 의 경우, 얼마나 최적화가 되어있지 않으면, 10~20% 정도 성능향상을 시킬만한 여지가 있는건지...
>> VM 바꾸는 것으로 10~20% 성능향상을 가져올 수 있다는 것은, 그만큼 VM이 엉터리로 짜여져서 최적화가 되어있지 않다는 얘기와 동일한 것 아닌가요 ???
방식을 바꿔서 엄청난 진전을 가져와본적이 없으신가보군요 ^^
예를 들자면, 2D를 그리는데, 도트단위로 직접 그리는 것을 죽어라 최적화 하는 것 보다, HW 가속기능을 사용하게끔 변경한다던지하는 거 말입니다. JVM은 그런식으로 조금씩 계속 진보되고 그 진전을 JVM에 쌓아 가고 있습니다.
>> C/C++ 은 몇십년 동안 축적된 저런 성격이 없나요???
>> 혹시, 그 사실 아십니까.. ??
>> C/C++ 이 포트란 보다 신뢰성과 안정성 그리고 관계자의 익숙성에서 더 뛰어나다는 사실을...
이말을 자바에 대해서도 말할수 있습니다.
Java 는 몇십년 동안 축적된 저런 성격이 없나요???
혹시, 그 사실 아십니까.. ??
Java가 C/C++ 보다 신뢰성과 안정성 그리고 관계자의 익숙성에서 더 뛰어나다는 사실을...
실행시간에만
실시간분기예측을통해 얼마나 시간단축이 일어났다는 데이터가 있나요? C/C++와 비교해서요..
일단 비관적입니다.
예를들어 불필요한 분기문이 있었다칩시다.. 그걸예측판단 하는데는 비용이 들지 않았을까요?
또한 프로그래머 입장에선 그것을 예측해서 코딩했어야하지 않았을까요?
말하자면 프로그래머가 엉뚱하게 짜지 않고 어느정도 잘구현했음에도 vm의 실시간분기예측에드는 비용이 C/C++의 실행을 능가하는경우가
구체적으로 어떤경우냐는겁니다.
FSM이 비용이 드나요?
FSM(유한상태기계)는 상태가 변경될때만 비용이 발생합니다.
반면에 조건문은 조건문이 실행될때마다 비용이 발생합니다.
if 문과 관련된 상태를 기반으로 FSM를 구성하여 최적화 하기 때문에 상태가 바뀌지 않는한 비용이 발생하지 않습니다.
이것도 기초적인 분기예측이고요, 더 복잡하고 정교하면서 저비용의 분기예측 기법은 많습니다.
그리고 모든 부분에서 분기예측이 아닌 성능에 직접적으로 큰 영향을 미치는 부분, 바로 Hot-spot 부분에 대해서 좀더 강력한 최적화를 수행하는 거죠. 그래서 Hot spot VM인겁니다.
그리고 불필요한 분기문이 아니라, 특정시간과 상태에서만 불필요한 분기문인거죠. "실행시간"이라는 것을 잘 생각해 보세요.
게임이라고 생각해보면
while(isGameGoing) {
switch(gameState) {
case OPENING:
showOpening();
break;
case MAIN_MENU:
showMainMenu();
break;
case PLAYING:
play();
break;
case SUB_MENU:
showSubMenu();
break;
case CLOSING:
close();
isGameGoing = false;
break;
}
}
이런 코드에서 불필요한 분기문이 있나요?
하지만 대부분의 시간을 case PLAYING 상태에서 play()를 호출하겠죠.
물론 이걸 직접 FSM으로 만들수도 있습니다. ^^
FSM이 비용이
그럼 안드나요? 상태를 판단해야죠.
상태머신은 항상 상태판단 비용이들지만.
그냥하면 그런비용은 없습니다.
더구나 비교판단문자체만하더라도 대입보다 부하를 더먹을수 있습니다.
더구나 그러한 어떤상황에따른 처리를 사용자의 선택에 맞겨야지
무조건 상태판단을한다는것자체가 이미 부하를 가중시키는일입니다.
그리고 님이 예를 드신코드는 유한상태기계의 적절한 예가 아닙니다.
FSM을 잘 모르시는 군요..
FSM은 비용이 들지 않습니다. 그냥 호출입니다. ^^
상태가 변경될때에만 비용이 발생하고 각각의 상태를 호출하는데 있어서는 비용이 발생하지 않습니다.
다시말해 상태를 판단하지 않습니다.
상태기계가 매실행 루프에서 항상 비용이 든다는 것은 처음듣는 이론입니다만...
억지로 그렇게 만들수는 있지만, 누가 그렇게 할려나요?
제가 예로 제시한 것은 상용게임에서 사용하는 전형적인 코드이고 다음의 코드역시 상용게임에서 FSM으로 구현된 것을 간단히 옮긴 것입니다만...(상태패턴이 아닌 전략 패턴으로 구성되기도 합니다)
interface State { void execute(); }
class OpeningState implements State { void execute() { showOpening();}}
class MainMenuState implements State { void execute() { showMainMenu();}}
class PlayingState implements State { void execute() { playing();}}
class CloseState implements State { void execute() { close(); }}
...
State state;
...
while(GameState.isRunning()) {
state.execute();
}
http://www.objectmentor.com/resources/downloads.html 에서 SMC Finite State Machine Compiler 를 다운 받아(Java/C++ 두가지 버전이 있습니다) 테스트 해보시기 바랍니다.
추가적으로 분기예측 최적화는 ...
interface State { void execute(); }
class OpeningState implements State { void execute() { showOpening();}}
class MainMenuState implements State { void execute() { showMainMenu();}}
class PlayingState implements State { void execute() { playing();}}
class CloseState implements State { void execute() { close(); }}
...
State state;
...
while(GameState.isRunning()) {
state.execute();
}
이렇게 코드를 실제로 짰더라고 실행시간의 대부분에 해당하는게 Playing 상태겠죠.
이부분이 Hot-spot으로 인식되면 실행시간 분기예측 최적화에 의해 내부적으로 다음과 같은 코드처럼 네이티브 코드로 동작하게 되는 겁니다.
while(GameState.isRunning()) {
playing();
}
이런식으로 호출 스택마저도 옵티마이즈가 가능하다는 겁니다. 매번 상태판단을 하는 것도 아니기 때문에 이렇게 되면 최소한 이부분은 동일한 C++코드보다 빠르게 동작하는 부분이 되는 거죠. FSM에 의해 상태가 바뀌면 다시 원래 코드로 동작하고요.
비용이 들지
비용이 들지 않는다니요..
아니 상태를 판단하지 않았는데 무슨 상태를 안다는말입니까.
좀 어이가 없습니다.
님말에 "상태가 변경될때만 비용이 발생하고..." 상태가 변경된걸 어떻게 알죠? 누가 공짜로 알려줍니까?
모든것에는 비용이듭니다. 아무리 사소해도 말이죠..
또한 님의 코드가 상태기계를 표현한건 아닙니다 핵심을 빠트렸죠 겉보기는 비슷한데
어떤식으로 상태가 변경될때만 실행하고 상태가 변경되지 않았을때는 실행되지 않는다란..
그핵심적인 내용이 빠졌는데 상태기계 예로서는 적절하지 않다는겁니다.
물론 하위레벨함수에 구현되었을수 있죠 그러나 예를저렇게 보이면안되죠.
정말로 OO기반의 FSM을 모르시는 군요.
FSM에서는 상태의 변화, 즉 이벤트가 발생할때만 상태변경에 대한 판단이 필요하고 그때만 비용이 발생합니다.
상태변화 이벤트가 발생하지 않는다면 비용이 들지 않습니다.
아마 C에서 switch로 구현된 FSM에 익숙하셔서 그런것 같습니다. C에서 FSM을 만들때는 말씀하신대로 매번 상태판단이 필요하거든요. (매 루프마다 비용이 필요하죠)
하지만 객체지향 언어에서는 메시징을 이용하기 때문에, 상태가 변경되면 실행될 State객체를 변경 시켜 주는 것으로 비용은 끝입니다. 이걸 이해 못하시면 저로써는 님께서 OOP를 이해하지 못하신 분이라고 밖에 생각할수 없습니다.
그럼 이벤트는 어디서 오느냐? 보통은 다른 쓰래드에서 옵거나(External Event) 또는 내부적으로 상태객체 내부에서 발생하기도 하죠(Internal Event)
>> 아니 상태를 판단하지 않았는데 무슨 상태를 안다는말입니까.
상태를 판단하지 않는게 아니라, FSM의 전환이 상태의 변경이 일어날때만 수행된다는 겁니다.
FSM의 내부 State가 전환된 이후에는 비용이 더이상 발생하지 않는 것이고요.
>>어떤식으로 상태가 변경될때만 실행하고 상태가 변경되지 않았을때는 실행되지 않는다란..
>> 그핵심적인 내용이 빠졌는데 상태기계 예로서는 적절하지 않다는겁니다.
if (a ==1) {
doA();
}
else if (a==2) {
doB();
}
라는 코드가 있을때 JVM이
StateA { doA() }
StateB { doB() }
같은 네이티브 컴파일된 상태머신을 실행시간에 만들어내어 a가 변경되는 것에 따라 각각의 FSM의 상태를 변경시커, 해당 State를 실행 시킨다는 겁니다.
이런 이유때문에 Interpreter + native compiled code 를 사용하는 환경이 Only native compiled code 보다 빠를 가능성이 있다라는 겁니다. 그리고 실제로 여러 부분에서 빠르게 동작하고요.
답답하십니다.. 이해
답답하십니다..
이해못하고 계신건 님입니다.
하위레벨의 실행을 이해못하기때문에 님께서 이런소리하시는겁니다.
좀더 하위레벨쪽으로 공부해보시라 추천드리고싶습니다.
vm이 어떻게 작동하며
vm이 어떻게 작동하며 인트럽트는 어떻게 발생하고 어떻게 프로세스,쓰레드가 받아내는지 알고 계십니까?
FSM을 OOP의 메시징
FSM을 OOP의 메시징 기법을 이용해서 구현하면 상태 판단이 필요없다는 얘기는 처음 듣습니다.
FSM을 어떤 언어로 구현하느냐에 따라 근본적인 차이가 있을 거라고 생각하십니까?
> FSM에서는 상태의 변화, 즉 이벤트가 발생할때만 상태변경에 대한 판단이 필요하고 그때만 비용이 발생합니다.
그러면 이벤트를 발생시킬 것인지는 어떻게 결정합니까? 계속 감시하는 것 말고 다른 방법 있나요?
FSM, 분기예측, GC 등 Java가 내세우는 것을은 모두 같은 특징을 갖고 있습니다.
사용자가 그에 대한 비용을 지불할 의사가 없는 경우에도 그 비용을 강요하는 것입니다.
지금까지 이 글타래를 읽어보니 Java가 desktop application에서 빛을 못 보고 있는 이유를 알 것도 같습니다.
그런 건 성능에 별로 영향 없다. / 체감할 정도의 성능 차이는 없다.
--> 사용자가 분명 느리다고 느끼고 있는데도 이렇게 얘기하는 것은 우기기밖에 안 됩니다.
저도 분명 느꼈으니까요. 전에 Java로 만든 프로그램을 실행시켰더니 정말 느렸습니다.
윈도우즈의 설치 프로그램이었는데 복잡하게 레지스트리를 건드리는 것도 아니고 그냥 파일 복사하는 정도인데도 JVM 설치부터 시작해서 한 20분 걸렸던 것 같습니다.
압축 파일이나 install shield를 썼다면 아무리 길게 잡아도 5분 이내에 끝날 일이었습니다.
게다가 JVM은 설치 이후에는 쓰지도 않을 것이었습니다.
성능에 문제가 있으면 하드웨어를 좋은 걸 쓰면 된다.
--> 일반 사용자들한테 이런 요구를 할 수 있나요?
게임 매니아 같이 하드웨어에 상당한 투자를 하는 사람들을 제외하면 말입니다.
필요없다고 말씀드린적은 없습니다만
>> FSM을 OOP의 메시징 기법을 이용해서 구현하면 상태 판단이 필요없다는 얘기는 처음 듣습니다.
필요없다고 말씀드린적은 없습니다만. 다만 switch문(등의 비교문)의 실행이 변경이 일어나거나 이벤트가 발생할때만 상태판단비용이 필요할뿐, 매 루프마다 요구되지 않게 된다고 말씀드렸습니다.
while(isAlive) { int buttonState = getMouseButtonState(); switch(buttonState) { case BUTTON_1_PRESSED: play(); break; case BUTTON_2_PRESSED: pause(); break; } }이 코드와
Mouse.addListener(new MouseListener() { void button1pressed() { FMS.toPlayState();} void button2pressed() { FMS.toPauseState();} } ); FMS { State currentState; static State PlayingState = new PlayingState(); static State PauseState = new PauseState(); void toPlayState() { currentState = PlayingState; } void toPlayState() { currentState = Pausetate; } void run() { currentState.execute(); } } PlayingState implements State { void execute(){ play();} } PauseState implements State { void execute(){ pause();} } ... while(isAlive) { FSM.run(); }이 아래쪽 코드가 매 루프마다 상태 판단을 요구하는 가요?
>> 이벤트를 발생시킬 것인지는 어떻게 결정합니까? 계속 감시하는 것 말고 다른 방법 있나요?
if (a==1) { doA(); } else if (a==3) { doB(); }같은 코드가 있을때
enum { ONE=0, THREE=1 } function doA() { ... } function doB() { ... } void (*Func)(void)[2] = { &doA, &doB} ; ... Func[ enumValue(a)]();(C코딩을 한지 오래되서 정확하지는 않을껍니다. 그냥 psedo 코드로 생각해 주세요. )
이런식으로 함수 포인터을 이용하면 모니터링 할 필요가 사라집니다. 이것 말고도 여러 방법이 있으나 다 소개 하지는 않겠습니다.
>> FSM, 분기예측, GC 등 Java가 내세우는 것을은 모두 같은 특징을 갖고 있습니다.
>> 사용자가 그에 대한 비용을 지불할 의사가 없는 경우에도 그 비용을 강요하는 것입니다.
맞습니다. 그리고 그 비용을 꾸준이 줄여 왔고, 그 결과로 여러 영역에서 C/C++과 유사또는 대등 이상의 성능을 내게 되었다는 것 역시도 사실입니다.
음.. 자꾸 오해가 있으셔서 말씀 드립니다만, 저는 자바가 무조건 C/C++보다 빠르다고 주장하는 게 아닙니다.
C/C++이 무조건 자바보다 빠르다는 주장이 틀렸다고 말씀드리는 것 뿐입니다.
그리고 자바가 그런 상태에 오기까지 쌓아 올린 여러 기술적 노하우중 제가 아는 몇가지를 말씀 드린 것이고요.
>>필요없다고
>>필요없다고 말씀드린적은 없습니다만. 다만 switch문(등의 비교문)의 실행이 변경이 일어나거나 이벤트가 발생할때만 상태판단비용이 필요할뿐, 매 루프마다 요구되지 않게 된다고 말씀드렸습니다.
매우당황스럽군요..당연히 이벤트발생할때만 해야지 그럼 이벤트도 발생하지 않는데 혼자 루프도는걸누가 만듭니까?
C는무슨 이밴트도 없는데 무한루프 돌고 있을줄압니까?
그리고 님코드 이밴트발생할때마다 루프돕니다. 당연한말이구요..
따라서 매루프마다 상태판단하게되있습니다.
또한 코드를보니 어처구니 없이 비효율적입니다.
저런식이라면 저루틴에서만 C보다 수천%이상 지연현상일어납니다.
그리고 그밑에 두코드는..
일단 코드(하는기능,역할)이 틀립니다. 밑에는 0,1 외에는 오류가 발생하지만 위코드는 그렇지 않습니다.
동일한 기능수행을두고 비교를따져야지 수행자체가틀린것을 따지셨군요..
또한 위코드를보면 첫번째는 비교후 함수를 다이렉트로수행하지만.
두번째는 포인터함수배열에 저장되어진 포인터로뛰어가는 중간철차를거치게됩니다.
즉,위코드도 저런단순비교는 switch case 로해야지요 그럴경우는 아래코드보다 오히려 더효율적입니다.
그리고, 아래코드가 무슨 자바 vm 에서만 수행되는것으로 아시는데.
아래코드는 C에서 함수포인터의 대표적활용이라할수 있습니다.
또한 수행중에 일반코드를 저런식으로 수행해야겠다고 판단하고 코드를 바꾸어 수행한다는자체가 얼마나 비효율적입니까.
그건 비용이 훨씬많이 들지요.
처음 이야기로
처음 이야기로 돌아가볼까요? ^^
제가 말씀 드리는 내용은 모두 분기예측 최적화에 대한 내용입니다.
물론 이 과정은 HOT-SPOT이라고 부르는 퍼포먼스를 많이 소모하는 부분에 대해서 수행됩니다.
(이 HOT-SPOT을 추적하는 것 자체는 추가 적인 비용이 듭니다만, 많은 최적화를 통해서 대단히 미비한 비용입니다.)
HOT-SPOT에 해당하는 영역에 대해 JIT를 통해 native컴파일된 코드를 사용하는데 이 과정에서 분기예측을 수행하고 FSM에 기반한 최적화를 수행합니다.(여기까지는 분명히 비용이 발생합니다.) 물론 분기 예측 최적화 이외에서 다양한 실시간 최적화 기법이 있습니다만, 여기에서는 이것만 떼어 놓고 이야기 하는 중이죠.
님께서는 이렇게 했을때 성능향상이 있다는 것을 믿기 어렵다는 입장이신 것이고요.
게임 로직을 하나 들겠습니다.
void run(){ while(isGameGoing) { if (isGameShowing) { switch (gameMode) { case INITIALIZING: init();break; case OPENING: showOpening(); break; case MAIN_MENU: showMainMenu(); break; case PAYING: play(); break; case PAUSEL pause(); break; } } } closing(); }매우 일반적인 코드이며, OOP형태의 FSM을 직접 바꿀수도 있습니다만, 지금은 그냥 저 코드로 나가죠.
처음에는 위의 코드가 인터프리트형태로 그냥 실행 됩니다.
어느정도 수행이 되다보면 JIT에 의해서 동일한 의미를 가지는 네이티브 코드로 컴파일 되어 수행 됩니다. (물론 컴파일 자체에는 비용이 수반됩니다만, 그 이후에 얻어지는 성능 향상으로 대부분 상쇄된다고 볼수 있습니다)
위의 코드는 메인 루프이기 때문에 매우 빈번하게 실행되며 따라서 HOT-SPOT으로 탐지되게 됩니다(물론 이 과정도 미비하게 나마 비용이 들어 갑니다)
내부적으로 분기 예측을 수행하여 위의 코드를 FSM으로 분해 합니다.
FSM의 상태는
SHOWING_XXXX,
NOT_SHOWING_XXX
두가지 군으로 나누어 질 겁니다.
그래서 FSM형태로 구분한 각각의 STATE을 수행시킵니다.
하지만 대부분의 시간은 SHOWING_PLAYING을 수행 할 겁니다. HOT_SPOT은 이 것을 알아내면(물론 여기도 비용이 들어갑니다)
추가적인 프로시져를 동적으로 만들어 냅니다.
void run() { play(); }물론 이 프로시져는 의미를 보이기 위해 소스 코드 형태일뿐 실제로는 네이티브 컴파일된 기계어입니다.
HOST Spot은 상태가 변경될때 까지 이 코드를 호출하게 됩니다.
물론 상태가 바뀌면 기존의 JIT로 네이티브 컴파일된 FSM의 코드를 호출하는 것이지요.
이런 것이 C언어로 구현된게 아닌, 어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다. 단순히 함수 포인터가 아니고요. 의미상으로는 C의 함수 포인터와 같습니다만, 실제로는 CPU 아케텍쳐마다 어셈을 이용하여 최적화된 실행 제어를 수행하고 있습니다.
이렇게 되었을때 SHOWING_PLAY가 지속되는 시간이 길어 질수록 부가 비용이 상쇄되고 어느 시점에 이르면 원래 코드의 네이티브 버전 보다 빠르게 동작합니다.
몰룬 여기에서 중요한것은 HOT_SPOT을 판단하는 휴리스틱과, JIT가 만들어 내는 네이티브코드의 효율성, 그리고 부가 비용의 최소화입니만, 자바는 이미 충분할 정도로 진화해 왔고 앞으로도 진화해 나갈것입니다.
제가 설명 드린 것은 어디까지나 아이디어 입니다. 실제 구현이 매우 복잡하기 때문에 어디 한부분만 딱 떼다가 설명드리기 어렵습니다. 어셈이 많이 사용되었기도 하고 내용이 상당히 방대하기 때문입니다.. 그래서 제가 할수 있는 것은 "이러 이러한 아이디어에 기반한 구현을 가지고 있다"라고 설명드릴수 뿐이 없습니다.
제가 함수 포인터가 C/C++의 일반적인 장점이자 자주 사용되는 기법인줄 모르겠습니까?
포인터배열이 비용을 더 소비한다는 것을 모르겠습니까?
아이디어로 제시된 내용을 "실제 구현인양" 곡해하시면 대화가 않됩니다. ^^
(실제 구현을 보고 싶으시면 http://www.sun.com/software/opensource/java/ 에서 JVM을 다운 받아 보시면 됩니다.C/C++/어셈 이니 C하는 분들은 재미있게 보실수 있을 겁니다. )
FSM을 기반으로 하여 실행경로를 조각내고, HOT-SPOT인 특정 실행 경로만을 수행하는 네이티브 코드를 만들어 실해하게 하는것이 분기예측 최적화의 기본 아이디어 입니다.
FSM의 상태 변화는 값에 의해 수행 할수 있다는 것을 간단하게 보여 드렸고요.(이것도 아이디어로 제시한 것일뿐입니다. 실제로는 어셈으로 구현된 부분에 있다고 추정하고 있습니다. 제가 여태까지 JVM 소스을 본 바로는요)
ps. 이렇게 풀어 썼는데도 이해 못하시면 정말 곤란합니다. -_-
대화가 비슷한내용에
대화가 비슷한내용에 계속 맴도는데요..
위에서도 님께서 비용이수반됨을 인정하신부분이 있습니다.
"이런 것이 C언어로 구현된게 아닌, 어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다. 단순히 함수 포인터가 아니고요. 의미상으로는 C의 함수 포인터와 같습니다만, 실제로는 CPU 아케텍쳐마다 어셈을 이용하여 최적화된 실행 제어를 수행하고 있습니다."
답답하십니다.. 이말도 매우 의미 없는 소리입니다..
"이렇게 되었을때 SHOWING_PLAY가 지속되는 시간이 길어 질수록 부가 비용이 상쇄되고 어느 시점에 이르면 원래 코드의 네이티브 버전 보다 빠르게 동작합니다. "
이건 java 상에서의 비교이겠죠.. 다른언어(예를들어C라던가) 보다 더 빠르게 동작했다면 실 예를 좀보여주시죠..
결론은 이것하나만 말씀드리고 싶습니다. 어떤사건이발생하기전에 그사건에서 예측할수 있는것이 있다면 그예측을 미리 대비해두는것 이외의 것은 사건이 발생한후에 예측하는것에는 언제나 다시 예측비용이 수반됩니다.
비용을 들이지 않아도 되는것과 자신의 의지와 무관하게 비용이들어가는것과 차이입니다.
일단 대화가 비슷한내용에서 맴도는거 같으니 실례나 어떤 검증된근거가 있다면 보여주시고..
아니면 대충여기서 저는 마무리 하겠습니다.
실예는 이미 보여 드렸습니다.
님의 생각대로라면 어떤 벤치마크에서도 자바가 C보다 빨리 나와서는 않됩니다.
하지만 엄격히 수행되었든, 허술하게 수행되었든, 여러 벤치마크에서 여러 영역에서 자바가 C/C++ 보다 빠르다는 벤치마크가 나왔습니다. 물론 다른 여러 영역에서 느리다고 나왔고요.
사실을 무시하시면서 머리속의 생각만 주장하시는 것은 대화에 도움이 되지 않습니다.
저는 여러 아이디어를 제시하면서 이렇게 하면 빨라질수 있다라고 했습니다만, 님께서는 "그래서는 빨라질수 없다"라는 주장만 하고 계신 거죠.
오히려 제쪽에서 이렇게 했을때 진짜로 빨라지지 않는다는 주장의 근거를 보고 싶습니다.
위에서 말한
위에서 말한 실례라는것은 실제 벤치마그된예..벤치마그 링크걸어달라는겁니다.
여러차례 테스트되었다면 많을것 아닙니까? 웬만하면 한글페이지 링크걸어주시고.
M$윈도우도 엉뚱하게도 느린것도 빠르다고 많이들 광고하죠..
사실을무시하긴요.. 님이제시한 아이디어에 헛점을 지적했을뿐입니다.
님은 그헛점에대해 더이상의 적당한방법이나 대안을 제시하지못했구요.. 같은말을 되풀이 하시고계십니다..
"오히려 제쪽에서 이렇게 했을때 진짜로 빨라지지 않는다는 주장의 근거를 보고 싶습니다."
님의 주장은 참 너무 황당합니다.
시로운시도나 주장은 하시는쪽에서 어떤 근거자료를 내놓아야합니다.
어떤사람이 내가 이새로운기계를 만들었는데 이것은 매우뛰어나다..뛰어난이유나 자료가 있습니까? 란질문에..
그럼 안뛰어나다는 증거를 대봐라고한다면 너무 어처구니 없다고 생각지 않나요?
다른 분 글을 제대로 않보셨군요.
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html 에 보시면
벤치마크 결과 입니다.
http://www.tommti-systems.de/main-Dateien/reviews/languages/perf3.gif
자바는 느렸습니다.
과거에 자바는 느렸습니다. 상당히요.
그래서 C/C++과의 성능차를 극복하기 위해 다양한 아이디어가 나왔고
그중에 가장 근본적인 아이디어는 "추가 비용 10을 사용하여 전체 성능을 20이상 끌어 올릴수 있다면 추가비용을 지불해서라도 전체 성능을 끌어 올리자"라는 것입니다.
그래서 나온것이 JIT였고 HOT-SPOT 엔진입니다.
이것들로 인한 성능 향상은 대단했고 C/C++과의 성능차를 엄청나게 매꿀수 있었습니다. 심지어 일부 영역에서는 C/C++보다 빠르기도 하게 되었습니다. 물론 전체 영역을 살펴 본다면 여전히 격차가 있습니다만, 이제는 그 격차때문에 자바를 포기하지 않아도 될 정도까지는 발전해왔습니다.
여기까지가 사실(Fact)입니다.
그런데 님께서는 "추가 비용이 있는데 어떻게 더 빨라 지냐?"라는 머리속의 생각때문에 사실을 무시하고 주장만 하고 계신거죠.
"자바는 인터프리터인데 어떻게 컴파일 된 코드보다 빨라지냐"라던가 "레이어가 하나 더 있는데 어떻게 더 빨라지는데?"라는 것과 유사한 오류를 범하고 계신거죠.
그래서 제가 처음에 "접근 방식을 바꾸어 상당한 성능향상을 이루어 낼수 있는 것을 부정하느냐?"라는 취지의 질문을 했던 겁니다.
사실(Fact)을 보세요. 저는 그 사실이 어떻게 해서 얻어질수 있었나를 설명하는데 님께서는 "그 사실은 내 생각에 거짓말이야"라고 주장하고 계신것일 뿐입니다.
이미 다른 분이 자바가 C보다 일부 영역에서 빠르다라는 벤치마크를 올려 주셨습니다.
그럼 님께서는 자바는 어떤 경우에도 C/C++보다 빠를수 없다는 주장을 뒷받침해 줄 근거와 벤치마크를 보여주셔야 자신의 주장을 말할수 있는 거겠죠.
제가 님에게
제가 님에게 링크걸어달라는건 님에게 구체적으로 지적해드리기위해서입니다.
소스는 보셨는지요..
님은 막연히 당연히자신들의것을 호도하기위해 광고성주장을 펼치는그들의 주장을 무비판적으로 받아들이고 이미 그것을 너무 믿어버린나머지 다른이의 비판을 받아들이기 싫은겁니다.
님이야말로 사실을 보셔야합니다.
님이 링크건 벤치마크 소스를 살펴보니 템플린라이브러리함수를 호출합니다.즉 저런소스보다 결과적으론 그라이브러리 함수의 성능비교가된것입니다.
저기올려진소스는 이미 무의미하다는소리죠..
라이브러리가 구체적으로 동일한 작동을할지 안할지는 내부소스를 열어봐야 알겠지만.
일단 벤치마크라고 올린 소스가 실제 동일한조건인지 알수도 없는소스를 올려두고 벤치마크라하는것이 참...
정상적인 벤치마크가 되기위해선 완전히 동일한 동작을하는 함수를 콜했다는 조건이있던지..
아니면 직접구현한함수를 호출해야할것입니다.
저런식의 테스트는 눈속임에 불과할수도 있습니다.
http://www.google.com/search?
http://www.google.com/search?q=java%20faster%20C%20benchmark
구글링만 해도 많이 나옵니다.
'이런 저런 기술을 통해 자바가 C/C++보다 빠른 경우도 있다'라는 온건한 주장에 대해선 온갖 링크와 증거를 요구하면서 '자바는 절대 C/C++보다 빠를 수 없다'라거나 '자바는 너무 느려서 실무에서 절대 못쓴다', 혹은 '자바가 빠르다는 벤치마크는 모두 부정확하거나 마케팅적 의도로 조작했을 것이다'라는 훨씬 과격한 주장들은 아무런 근거 없이 믿어야 하는 건가요?
아무런 근거 없이
아무런 근거 없이 믿으라고 안했습니다.
님이 링크거신 벤치마크엔 문제가 있음을 알려드린겁니다.
또한 구글링해서 많이도 나오겠죠.. 하지만 저많은것들을 일일이 다까발려 알려드리고 싶어도.. 그럴시간이 없는게 안타깝군요..
무비판적으로 받아들이시기전에 아주냉정히 살펴보시기 바랍니다.
좋습니다. 님의
좋습니다. 님의 충고대로 '자바가 비즈니스 어플을 만드는 데 많이 쓰일 만큼 빠르고 또 경우에 따라선 C/C++보다 빠를 수 있다'라는 주장을 '비판적'으로 '냉정히' 받아들이도록 노력해 보겠습니다.
그럼 님께서는 '자바는 절대로 C/C++보다 빠를 수 없고 이에 어긋나는 벤치마크는 모두 부정확하거나 의도적으로 왜곡된 것이다, 또 실무에서는 느려서 절대로 쓸 수 없다'라는 주장을 '비판적'이고 '냉정하게' 생각해보실 의향이 있는지요? (실무에 쓸 수 없다는 부분에 대해선 님께서도 다른 익명 분들 의견에 동의하시는 지 모르겠습니다)
그런 연후에도 주장을 굽히지 않으실 것이라면 한 번 시간 나실 때 인터넷 상에 그런 생각을 잘 정리해서 올려 보시기를 권해드립니다. /. 같은데 올려서 지금도 진실을 깨닫지 못하고 '썬의 농간에 놀아나고 있는' 수많은 전문 자바 개발자들이나 아키텍트들을 계몽하실 수 있다면 아마 전세계적으로 이름을 날릴 수 있을 것 같습니다.
제목은 'HotSpot은
제목은 'HotSpot은 허구였다!'라던가 'JIT 기술에 숨겨진 썬의 음모와 진실' 정도가 적당할 것 같습니다.
이미 냉정히, 비판적으로 생각해 보았고, 보고있고, 볼예정입니다.
저는 예전 프로젝트에서, 4가지 언어를 혼합해서 만들어진 임베디드 시스템을 개발했습니다.
각각의 언어는 각 용도에 최적화된 언어를 선택하였습니다.
각각 C, 자바, 쉘스크립트, 파이썬(정확히는 자이썬)이였습니다.
이 프로젝트 결과물은 성공적으로 제품화 되어 좋은 평가를 받으며 잘 팔려나가고 있는 제품입니다.
여기에서 자바는 접착제 언어이면서, 핵심 어플리케이션을 구성하는 역활을 수행하였습니다.
IPTV는 MHEG등의 자바 기반의 표준을 가지고 있고, 잘팔려 나가고 있습니다.
모토롤라와, 노키아같은 철저한 플랫폼기반의 회사가 차기(이미 제품이 나오고 있습니다만) 자사 플랫폼을 자바로 선정하고 제품을 만들고 있습니다.
자바를 실무에 쓸수 없다고 생각하십니까?
이 질문에 단순히 예/아니요 라고 답하는 것 만큼 어리석은 짓도 없습니다.
실무가 무엇이냐에 따라 달라질겁니다.
TV Ray-gun controller같은 하드리얼타임 어플리케이션에 자바나 C++를 쓰는 미친 짓은 않할겁니다.
마찬가지로 엔터프라이즈 웹 어플리케이션을 만드는데 C를 쓰는 미친짓도 않할겁니다.
다만 저는 두가지 영역(임베디드 영역, 엔터프라이즈 영역) 두 군데서 각기 수년씩의 경험을 쌓은 결과로 우리가 일반적으로 만드는 대부분의 어플리케이션이라면 이제는 자바를 써도 상관없다라는 생각은 가지고 있습니다.
그런 의미에서라면 자바를 실무에서 쓸수 있다고 생각합니다.
물론 이것은 현재형으로써, 추후 개발 비용 및 난이도를 낮추줄수 있는 것으로 생각되는 언어나 기술이 등장한다면 충분히 비교,검토하여 수용할 의사도 있습니다.
이정도면 제 입장을 아시겠습니까?
그런 입장이시라면
그런 입장이시라면 제 생각과 사실상 차이가 없습니다. right tool for the right job이겠지요. 익명 글도 넘쳐나고, 위에서 자바가 C보다 8배, 50배 느리다거나 미션크리티컬한 곳에 쓸 수 없다거나 하는 등의 이야기가 워낙 많이 나와서 논점이 섞여버렸군요. HotSpot/JIT에 대한 부분을 제외한다면, 윗 글의 내용에는 저도 역시 동의합니다.
또한 웃긴게 일부
또한 웃긴게 일부 모듈을 어셈으로작성된 코드를 call 해서 빨라졌다면 그게 자바인가요?
그렇게 콜한다면 c나 스크립트조차도 콜할수 있습니다. 그렇다면 누가더빠른가요?
그걸두고 자바가 빨라졌다? 말할수 있는겁니까?
남자둘이서 누가더싸움을 잘하는지 가려보자고 링위에 올라선두사람중한사람이 친구불러서 상대를 제압한후에
거봐 내가더쎄지.라는것과 무슨차인가요?
정당한대결이라면 둘다친구 부르던가..아니면 둘다 없이 해야지요.
그런식으로 어거지성으로 외부코드를 포함해서 빠르다주장한다면 세상에 느린언어가 어딨으며 느리고빠름의 비교가 무슨의미가 있나요?
어찌됬건 그렇게 해서 빠르면되지 않는가?에대해서는.
어찌됬건 그렇게해봐도 C보다 느리다는겁니다. C는 그렇게 안해도 빠르지만 마찬가지로 콜할수있기때문에..
결국 부가적인 코드에서 자바는느리게되고. 결국 추월할수가 없다는게되겠지요.
그래서 많이 나아졌다? 라는주장에대해서도..
옛날보다 나아졌는지는모르겠지만 아직도 많이 느리다입니다.
자바가 빠르다는
자바가 빠르다는 벤치마크 대부분 어셈 코드하고 상관 없는대요? 런타임 최적화의 의미가 뭔지 아시는 건지... 하긴 뭐 JVM도 C/C++이니까 무효다!라고 우기실 거라면 그냥 'you win!'입니다만...;
자바 콜렉션 프레임워크는 순수 자바코드로 된 라이브러리입니다.
>> 또한 웃긴게 일부 모듈을 어셈으로작성된 코드를 call 해서 빨라졌다면 그게 자바인가요?
벤치마크 결과를 보셨으니 다시 말씀드립니다.
해당 벤치마크에서 리스트, 해쉬테이블등의 라이브러리는 어셈으로 최적화된 코드가 아니고
순수 자바코드로 만들어진 코드입니다. 어셈으로 된 코드를 call해서 빨라지는게 아닙니다.
이것이 JVM의 실행시간 최적화를 통해 동인한 C++ 템플릿 코드 보다 빠르게 구동하는 결과가 벤치마크에 나와 있습니다.
이런 사실도 무시하시렵니까?
이게 어거지일까요?
>> 어찌됬건 그렇게 해서 빠르면되지 않는가?에대해서는.
>> 어찌됬건 그렇게해봐도 C보다 느리다는겁니다. C는 그렇게 안해도 빠르지만 마찬가지로 콜할수있기때문에..
>> 결국 부가적인 코드에서 자바는느리게되고. 결국 추월할수가 없다는게되겠지요.
처음부터 말씀드렸습니다만, JVM 자체가 C/C++, 어셈으로 되어 있기 때문에 C/C++이 JVM에서 수행하고 있는 온갖종류의 최적화를 다하고 그외의 최적화를 한다먄 당연히 C/C++이 빠를 겁니다.
그걸 매번 다 하실겁니까? 하지만 그래도 과학연산은 포트란 보다 느립니다만?
제가 처음부터 말씀 드린 것은 요구사항에 맞춰 언어를 선택해야 한다는 겁니다.
그리고 여러 사람이 자바가 8배 느리니, 50배 느리기 하시기에,
예전에는 그랬을지 모르지만 이제는 아니다. 충분히 빨라졌고 어떤 부분에서는 오히려 빠르기도 하다.
그렇게 되기 까지 여러 노력이 있었고, 그 노력중에 제가 조금이나마 알고 있는 부분을 설명드렸습니다.
ps. 자바를 아직도 오해 하고 계시는 군요. 이 오해가 참 오래 가네요..
자바는 자바언어와 자바 플랫폼으로 구성됩니다. 둘다 JCP의 표준화 과정을 거쳐 표준화되고, 표준이 나온후에 각 벤더에서 구현체를 발표하게 되어 있습니다
일반적으로 JVM이라고 이야기 하는 구현체가 바로 자바 플랫폼입니다.
자바 언어와 플랫폼의 가교가 바로 바이트코드이자 .class 파일들이죠.
자바 플랫폼은 C/C++로 구현되는 경우가 많지만, 다양한 언어로 구현되어있습니다. (심지어는 자바언어로 만들어진 자바플랫폼도 있습니다)
대표적인 자바VM은 썬에서 만들어진 JRE이지만, IBM의 J9역시 많이 사용됩니다.
자바 플랫폼에 대한 표준은 JIT 및 HOT-SPOT에 대한 표준도 포함하고 있으며, 각 벤더별로 추가적인 최적화를 추가 하기도 합니다.
자바플랫폼이 빨라졌으면 자바가 빨라졌다고 이야기 해야 겠지요. 뭐라고 이야기 할까요?
"해당 벤치마크에서
"해당 벤치마크에서 리스트, 해쉬테이블등의 라이브러리는 어셈으로 최적화된 코드가 아니고
순수 자바코드로 만들어진 코드입니다. 어셈으로 된 코드를 call해서 빨라지는게 아닙니다. "
저윗쪽글에 "어셈으로 작성된 네이티브 코드 ,기계어 레벨에서 수행됩니다." 라고 하셨기에 말씀드린겁니다.
모든게 어셈으로 구현되었다는말이아니구요.
"처음부터 말씀드렸습니다만, JVM 자체가 C/C++, 어셈으로 되어 있기 때문에 C/C++이 JVM에서 수행하고 있는 온갖종류의 최적화를 다하고 그외의 최적화를 한다먄 당연히 C/C++이 빠를 겁니다.
그걸 매번 다 하실겁니까? "
처음부터 말씀드렸습니다. JVM에서 수행하고 일부 행동들... 그렇게 안해도 더빠르며 그렇게 안하는게 더빠르다입니다.
즉, C에서 최적화 하지 않은것은 안하는것이 더유리하기 때문이며 수행중일어나는 최적화는 부가적인 비용이들어가기때문에 그로인한부가비용이 들어간다입니다.
같은 질문을 계속하시네요..
부가비용..
부가비용 10을 들여서 20이상(부가비용으로 소비된 10+그 10으로 할수 있었던 다른 일)의 성능 향상을 얻어 낼수 있기 때문에 실행시간 최적화가 더 빠를수 있다라는 게 제 주장이고, 이미 여러 논문과, 구현체과 벤치마크에서 입증된 사실입니다.
제가 요청 드리고 있는 것은
>> 그렇게 안해도 더빠르며 그렇게 안하는게 더빠르다입니다.
에 대한 이론적 근거 입니다.
님께서는 지금 그냥 "주장"만 하고 계신겁니다. 저는 그 주장을 뒷받침해줄 자료를 제시해 달라고 하는 겁니다.
참고로 자바 언어와 자바 플랫폼을 착각하시는 분들을 위해..
자바 플랫폼에서 동작하는 언어 목록입니다.
http://www.robert-tolksdorf.de/vmlanguages.html
간단히 보기에도 100여개의 언어 구현체가 자바 플랫폼상에서 동작하는 군요.
다시 말씀 드리면, 자바의 성능이란 자바 플랫폼의 성능이고
이 성능은 다양한 언어들(주력은 물론 자바 언어입니다만)이 같이 공유할수 있다는 겁니다.
아직도 많이 느리다..
라는 최근 벤치마크를 좀 보여 주실수 있겠습니까?
물론 "많이"라는게 정확히 어떤 의미인지 제시되어 있는 벤치마크말입니다.
여태까지 저만 자로와 근거를 제시했지 님께서는 근거를 제시한 적이 없습니다.
전형적인 케이스입니다만..
결과를 보여달라 ->벤치마크를 어떻게 믿냐, 다 눈속임이다.
전형적인 케이스입니다만, 한번 글을 달아보죠.
http://kldp.org/node/73324#comment-359861
여기에 제시된 결과도 못 믿으시겠나요? 소스 코드도 다 있습니다만.
이런것 까지 설명해야하나 싶습니다만, 자바의 성능이란 자바 플랫폼의 성능입니다.
자바 플랫폼이 빨라졌다만, 자바가 빨라진겁니다.
일단 결과가 자바가
일단 결과가 자바가 잘나온건 아니죠?
그건둘째치고 소스를보시고 말씀하세요.. 같은가..
일부러 느리게 만들려고 애쓴거같군요..
또한 가장중요한핵심적인 요소는 역시나 라이브러리함수를 콜했군요..
저러면 저함수내부에서 서로 같게작동할지 다르게작동할지는 내부소스까지 봐야합니다.
벤치마크하려면 재대로 해야지 저런식으로하니까 문제지요.
그리고 자바가 일부코드에서는 비슷한성능을 낼수없다는것이 아닙니다..
하다못해 스크립트조차도 일부코드에선 매우빠르게 동작할겁니다.
그래봐야 더빠르긴 힘들며 전체적으론 많이 느리다 입니다.
근거와 자료는 결국 없으시군요.
>> 그래봐야 더빠르긴 힘들며
단순히 "그건 다 거짓말이야"라고 말하기는 쉽습니다.
그런데 그게 거짓말이라는 것을 입증하는 것은 어렵지요.
저는 몇가지 아이디어에 기반해서 더 빠를수 있다고, 그리고 실제로 다 빠르게 나오기도 한다고 말씀드렸고,
관련된 자료를 제시했습니다.
추가적으로
http://www.irisa.fr/caps/people/pokam/pokam_lcpc2004.ppt
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
http://kano.net/javabench/
http://www.osnews.com/img/5602/results.jpg
http://www.w3sys.com/pages.meta/benchmarks.html
도 읽어 보시면 참고가 되겠군요,
자기 생각만 주장하지 마시고 이런 벤치마크에서 자바가 우위를 차지 했던 영역에 대해 C++이 더 빠르게 나온 최근 벤치마크 자료라도 좀 들고 나와 보세요. 그리고 논리적인 근거나 아이디어도 좀 제시해 보시고요. 저도 그런 자료를 좀 보고 싶습니다. 저도 좀더 정확하게 내용을 파악해야 하지 않겠습니까?
http://dada.perl.it/shootout/
http://dada.perl.it/shootout/java.html
아무 테스트 항목이나 찍어보세요.
메모리 사용량까지 보면 캐안습.
제말이 맞군요.
일부 벤치마크 영역에서 자바가 C++보다 빠른 영역이 존재합니다.
메모리 사용량도 마찬가지입니다. 일부 영역에서 자바가 C++보다 적게 사용하는 테스트가 있습니다.
올려주신 자료 역시 제 주장을 뒷받침해주는 자료입니다만..
참고로, 올려주신 벤치마크 자료 역시 님께서 다 속임수라고 주장하시는 마이크로벤치들뿐입니다만.
ps. 님의 주장의 이론적 근거를 뒷받침해줄 논문은 없을까요? "부가 비용을 지불하면 원래보다 더 빨라질수 없다"라는 논문말입니다. 아니면 PPT 자료도 좋습니다.
저는 저 결과를 별로
저는 저 결과를 별로 믿지 않지만 님이 반박 자료를 보기 원하시니까 이런 것도 있다고 올린 겁니다.
그런데 이것까지 님의 주장을 뒷받침한다고 하시면 좀 무리하시는 게 아닌가 싶네요.
제 주장은 간단합니다.
자바가 C/C++을 일부 영역에서 성능적으로 앞지르는 케이스가 있다.
그리고 님께서 올려 주신 벤치마크 역시 그걸 입증하고 있고요. 자바가 일부영역에서 더 빠르다고 벤치마크 결과가 나와 있네요. 결과를 자세히 비교해 보세요.
님의 주장은 "무슨수를 쓰던지간에 부가비용을 지불하는 이상 원래보다 더 빨라질수 없다"이고요.
저는 거기에 대한 이론적 근거와, 실제 벤치마크 결과(최근꺼야겠죠)를 보여 달라고 하는 겁니다.
실행시간 최적화 관련..
http://kldp.org/node/73324#comment-361727
어느 분이 글을 올려 주셨네요. 굉장히 심플한 코드인데, 차이는 딱 하나네요. 메소드를 호출하느냐 인라인시키느냐.
이제보니..
플랫폼의 개념이 아직 않잡히셨군요..
플랫폼은 어플리케이션이 동작하기 위한 기반이며, 플랫폼이 주는 장점과 더불어 단점을 "그냥 수용할수 밖에 없는" 것입니다.
만약 C로 어플리케이션을 만드신다면,
CPU+OS+API+Compiler 가 플랫폼이 됩니다.
자바로 어플리케이션을 만든다면
CPU+OS+JVM+API+compiler가 플랫폼이지요.
플랫폼이 주는 장단점은 그냥 받아들여야 하는 겁니다.
8086으로 프로그램을 만들면 무슨 수를 쓰던지간에 부동소수점연산은 에뮬레이션이 됩니다. CPU에 바로 부동소수점연산을 맡길수가 없습니다.
윈도우즈기반의 어플리케이션을 만들면 OSX나 리눅스에서 돌아가지 않습니다.
GCC로 최적화옵션을 아무리 주어도 Intel C Compiler에 비해 평균적으로 상당히 느리게 돌아가는 실행파일을 얻을수 밖에 없습니다.
이게 플랫폼의 특성입니다.
그렇기 때문에 C로 프로그램을 만든다고 해도 단순히 C 프로그램이 아닙니다. x586기반의 리눅스에서 gcc 3.0으로 컴파일한 c 프로그램인 겁니다.
플랫폼의 내부에 대해서는 불평은 할수 있을 지언정(오픈소스 OS라면 직접 고치는 방법도 있겠지요) 바꿀수는 없습니다.
따라서 java vs C++ 벤치마크란 실제로는 동일한 CPU, 동일한 OS을 기반으로 하는, C 플랫폼과 자바 플랫폼의 벤치마크가 되는 겁니다.
그렇게 각 플랫폼 별로 유사/동일 알고리즘을 가지는 어플리케이션의 벤치마크 결과가 나왔는데 결과가 맘에 않든다고 플랫폼의 내부때문이라고, C는 절대 않느리다고 말하는 것은 참으로 어불성설입니다.
그렇게 주장하는 것은 "이 코드가 느린건 윈도우즈 때문이야. 윈도우즈 내부의 코드를 비교해 봐야 정확한 걸 알수 있어"라고 주장하는 것과 마찬가지입니다. 유사하게 "이 코드가 느린건 CPU때문이야. CPU가 레지스터를 어떻게 처리하는지 회로를 봐야 정확한 걸 알수 있어".
플랫폼은 제약입니다. 받아 들이세요.
웹서버의 성능을 측정하는데, 웹서버의 구현 코드를 들여다 볼 필요가 있나요? 아닙니다.
성능 벤치마크란 블랙박스 테스트 일수록 정확한 겁니다.
블랙 박스에 대고 다양한 테스트를 진행하여 최고/최저/평균 성능을 얻어내는게 중요한겁니다.
그 내부에서 어떻게 돌아가던지 말입니다.
테스트 자체에 대해서는 왈가왈부 할수 있겠지요. 하지만 블랙 박스 내부에 대해서 왈가왈부 하면 큰 실수를 하는 겁니다.
>> 그래봐야 더빠르긴 힘들며
그러니까 JIT+HOT Spot engine의 그 수많은 최적화 에도 불구하고 더 빠르기 힘들다는 이론적 근거와 자료를 제시해 주세요.
더 빠를수 있다/빠르다라는 근거와 자료는 이미 많이 제시 하였습니다. 그밖에도 HOT Spot 휴리스틱과 JIT Adoptation 에 대해 매년 많은 수의 논문이 발표 되고 있다는 것도 사실이니까요.
님이 예로들거나
님이 예로들거나 근거라고 제시한것중에 하나라도 제대로된게 있던가요?
제가 하나하나 잘못되었음을 여테 다짚어드렸습니다.
자꾸 뭘아느냐 혹은 뭘모르신다 라는것으로 상대를 이기려드시는데 그런식으로 한다해서 어디 되겠습니까?
특히나 자바진영이 그런식으로논리를펼칩니다. 거의 실제적인것보다 말로떼우죠..^^
직접해보라면 되는것하나도 없고.
"플랫폼의 개념이 아직 않잡히셨군요.. "요런말요..
님이 말씀하신거 제가 설명드리면 님이 사과라도할껀가요? 그럴꺼도 아니면서 저런말하는건 상대를 어거지로 누르려는거지요..
제가 님은 대화의개념도 없군요..이렇게 말하면 님도 아마 기분나쁘죠? 님은대화회피의 한방편으로 저런말을쓰는것으로판단됩니다.
더이상 대화하지말자 요런말을 기분나쁘게 지레떨어져나가라는의도죠..
어쨋거나 님은 재대로된예를 하나도 보이지 못하셨습니다. 다른예도 다마찬가지겠죠..
뭐 누가 무슨논문을썼느니.. M$ 에서도 자기네들 방식이 빠르고 좋다고 특허까지 냈거든요?
M$ 좋아하는사람들은 철석같이 믿더군요.. 머어쩌겠습니까. 말로 못이기죠..그런분들은.워낙에 이론적으로 잘갖추니까..
그래야 살아남죠. 실제도 안되고 이론도 밀리면 멀로 먹겠습니까 그점은 이해합니다.
결국은 근거 없는 주장이셨습니까?
결국 논점을 흐리시는 군요.
>> 일단 비관적입니다.
>> 예를들어 불필요한 분기문이 있었다칩시다.. 그걸예측판단 하는데는 비용이 들지 않았을까요?
>> 또한 프로그래머 입장에선 그것을 예측해서 코딩했어야하지 않았을까요?
여기에 대해 저는 불피료한 분기문이 아니였다고 답변 드렸습니다.
>> 상태머신은 항상 상태판단 비용이들지만.
>> 그냥하면 그런비용은 없습니다.
그냥한다는게 무엇인지 실제코드로 보이신적은 없습니다만, 상태머신이 "항상" 상태판단비용이 든다는 것이 아니라는 것은 나중에 님도 동의 하신 부분입니다.
>> 매우당황스럽군요..당연히 이벤트발생할때만 해야지 그럼 이벤트도 발생하지 않는데 혼자 루프도는걸누가 만듭니까?
>> C는무슨 이밴트도 없는데 무한루프 돌고 있을줄압니까?
>> 그리고 님코드 이밴트발생할때마다 루프돕니다. 당연한말이구요..
>> 따라서 매루프마다 상태판단하게되있습니다.
이것에 대한것도 실제 코드로 상태가 가끔 변경되지만 매 실행루프마다 상태 판단하지 않는 코드를 예시로 들어 드렸습니다.
>> 이건 java 상에서의 비교이겠죠.. 다른언어(예를들어C라던가) 보다 더 빠르게 동작했다면 실 예를 좀보여주시죠..
>> 위에서 말한 실례라는것은 실제 벤치마그된예..벤치마그 링크걸어달라는겁니다.
>> 여러차례 테스트되었다면 많을것 아닙니까? 웬만하면 한글페이지 링크걸어주시고.
그래서 벤치마크 자료를 보여 드렸습니다.
>> 제가 님에게 링크걸어달라는건 님에게 구체적으로 지적해드리기위해서입니다.
구체적으로 지적하신 것이 없습니다만..
>> 님이 링크건 벤치마크 소스를 살펴보니 템플린라이브러리함수를 호출합니다.즉 저런소스보다 결과적으론 그라이브러리 함수의 성능비교가된것입니다.
이것 때문에 플랫폼을 이해하지 못하고 계시다는 말씀을 드린 겁니다. 자바에서 코사인 계산하는데 java.lang.Math.cos 말고 뭘 호출할까요?
>> 일단 벤치마크라고 올린 소스가 실제 동일한조건인지 알수도 없는소스를 올려두고 벤치마크라하는것이 참...
>> 정상적인 벤치마크가 되기위해선 완전히 동일한 동작을하는 함수를 콜했다는 조건이있던지..
>> 아니면 직접구현한함수를 호출해야할것입니다.
>> 저런식의 테스트는 눈속임에 불과할수도 있습니다.
제시된 벤치마크는 플랫폼간 벤치마크이기때문에 완전히 동일한 환경일수가 없습니다. 그런 것은 알고리즘 벤치마크때나 가능한 이야기 입니다. 이런 차이점도 인식하지 못하고 완전히 동일하지 않다라는 이유떄문에 눈속임에 불과하다라고 말하고 계신거죠.
>> 또한 구글링해서 많이도 나오겠죠.. 하지만 저많은것들을 일일이 다까발려 알려드리고 싶어도.. 그럴시간이 없는게 안타깝군요..
여기에 글쓰시는 시간의 아주 일부만 사용하셔서 구글링해도 님의 주장을 옹호할수 있는 벤치마크 자료 하나는 찾았을 겁니다.
>> 또한 웃긴게 일부 모듈을 어셈으로작성된 코드를 call 해서 빨라졌다면 그게 자바인가요?
>> 그렇게 콜한다면 c나 스크립트조차도 콜할수 있습니다. 그렇다면 누가더빠른가요?
>> 그걸두고 자바가 빨라졌다? 말할수 있는겁니까?
이것역시 플랫폼을 이해하지 못했기 때문에 나온 말씀이죠. 내가 짠 코드가 실행시간에 자바플랫폼에 의해 과거보다 더 빨리 동작하면 "자바가 빨라졌다"라고 말하는 겁니다.
>> 처음부터 말씀드렸습니다. JVM에서 수행하고 일부 행동들... 그렇게 안해도 더빠르며 그렇게 안하는게 더빠르다입니다.
>> 즉, C에서 최적화 하지 않은것은 안하는것이 더유리하기 때문이며 수행중일어나는 최적화는 부가적인 비용이들어가기때문에 그로인한부가비용이 들어간다입니다.
부가비용이 발생하는 것을 부정한적은 단 한번도 없습니다. 그리고 제가 주장하고 여러 자료로 제시한 것은 부가비용을 투자해서, 원래보다 더 빠른 성능을 얻을수 있는 방법이 존재한다. 라는 겁니다. 이걸 부정하시나요?
>> 제가 하나하나 잘못되었음을 여테 다짚어드렸습니다.
여태까지 지적하셨다고 하는 부분을 모두 요약해 보았습니다만, 제대로 짚었다고 할만한 곳이 없습니다. 게다가 어디에도 근거는 없습니다. 모두 님의 개인적인 생각에 기반한 독자적인 주장이실 뿐입니다.
부디 "부가 비용을 투자하면 절대로 원래보다 빨라질수 없다" 라는 님의 주장을 뒷받침할수 있는 이론과 자료를 제시해 주시기 바랍니다.
>> 거의 실제적인것보다 말로떼우죠
님은 말로 떼우고 계시는 군요.
>> 직접해보라면 되는것하나도 없고.
아이디어도 설명해 드렸고, 벤치마크도 보여드렸고, 소스코드도 보여드렸고, JVM Source도 알려 드렸습니다.
그리고 실제 적용 사례와 경험담도 제시해 드렸습니다.
오히려 제쪽에서 직접 해보시라고 권하는데 나오는 근거나 자료는 하나도 없는 상태군요.
>> 어쨋거나 님은 재대로된예를 하나도 보이지 못하셨습니다. 다른예도 다마찬가지겠죠..
제 실력이 부족해서 JVM source의 정확한 위치를 딱 짚어 말씀드리지 못하는 것은 죄송합니다만,
벤치마크의 예가 제대로 된 예가 아니라고 생각하십니까? 아니면 중간에 넣어드린 논문도요?
>> 실제도 안되고 이론도 밀리면 멀로 먹겠습니까 그점은 이해합니다.
저야말로 님을 잘 이해하고 있습니다.
ps. 제가 왜 님과 이런 고전적이고 이미 한물간,결론까지 이미 한참전에 난 플레임을 계속하는지 아십니까?
자바가 C++보다 느린
자바가 C++보다 느린 이유는 런타임 최적화에도 불구하고 플랫폼 차이를 극복하지 못하기 때문이지 런타임 최적화 자체가 비효율적이기 때문은 아닙니다. 만약 런타임 최적화가 불필요한 비용만 발생시킬 뿐이라면 자바끼리 비교했을 때도 퍼포먼스가 떨어지겠죠.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
맞습니다.
자바 플랫폼은 전반적인 성능이라는 측면에서 C/C++ 플랫폼을 아직 넘어서지 못했습니다.
하지만 그 차이는 현격하게 줄어 들었고
일부분에서는 오히려 (일반적인 GCC,MS C, Intel C) C/C++ 플랫폼 보다 빠른 부분도 나오고 있습니다.
저는 이 이야기를 하고 있을뿐인데, "절대로 C/C++을 넘어설수 없다"라고 주장"만" 하시는 분들이 많아서 논쟁이 길어 지네요.
그건 아니죠.. 왜
그건 아니죠..
왜 아닌지 자바하는사람들은 이해할수 없을겁니다..
C나 어셈을 공부해보면 왜 그런지 알수 있습니다.
물리학에 불확정성의 원리 라는게 있습니다.
무슨원리인지 아십니까? 어떠한 정보에 정확히 접근하려하면할수록 정보를 더욱정확히 알수없어지고 멀어진다는원리입니다.
이것은 단편적이거나 그런게아니라 모든물리 법칙입니다. 이해가 안가실수도 있지만..
그한계를 안다면 그이상을 추월할순없다는걸 알게됩니다.즉, 최대한 빠른방법은무엇인지 이론적으로 고찰해보세요.
저는 자바만 하는 사람이 아닙니다만.
>> C나 어셈을 공부해보면 왜 그런지 알수 있습니다.
저는 4년간 임베디드시스템에서 C와 어셈으로 프로그래밍했습니다. 그리고나서 내린 결론입니다만.
>> 물리학에 불확정성의 원리 라는게 있습니다.
>> 무슨원리인지 아십니까? 어떠한 정보에 정확히 접근하려하면할수록 정보를 더욱정확히 알수없어지고 멀어진다는원리입니다.
>> 이것은 단편적이거나 그런게아니라 모든물리 법칙입니다. 이해가 안가실수도 있지만..
http://ko.wikipedia.org/wiki/%EB%B6%88%ED%99%95%EC%A0%95%EC%84%B1_%EC%9B%90%EB%A6%AC 을 먼저 보고 와 주세요.
모든 과학은 현상에 대한 해설이지 근본 원리가 아닙니다. 당장이라도 1초후에 모든 법칙이 무너질수도 있는 겁니다.
마치 불확정성의 원리가 만고불변의 진리인양 생각하시는 것은 큰 오산입니다.
>> 그한계를 안다면 그이상을 추월할순없다는걸 알게됩니다.즉, 최대한 빠른방법은무엇인지 이론적으로 고찰해보세요.
불확정성의 원리는 오히려, 기본의 방법이외에는 더 나은 방법이 없다라는 결정론적 사고 방식을 타파하는 데 이용되는 건데 오히려 한계를 벗어 날수 없다라고 주장하시는데 쓰이는 것은 참 오랫만에 보는 군요.
간단히 하나 이야기하자면, 우연에 의해 속도와 방향이 모두 정확하게 관측될수도 있다라는 것 역시 불확정성의 원리에 내포된 결론입니다. 좀 더 생각해 보실만한 꺼리일겁니다.
우리 우주에서 빛보다 빠를수 없다는 한계이지만, 우리 우주가 아닌곳에서는 빛보다 빠른 것이 존재할수 있습니다.
2차원에 사는 생물에게 "높이"는 한계이지만, 3차원에 사는 생물에게는 "높이"는 한계가 아닙니다. "시간"이 한계이지요.
제가 지지하는 입장은 한차원 높은 어프로치를 취할수 있을 경우, 기존의 한계는 의미가 없어진다입니다. 물론 여전히 또다른 한계는 있겠지요.
이것은 괴델의 불완전성의 원리에서 도출되는 결론입니다.
또한 "어떤 방법을 취하던지 간에, 더 나은/나쁜 결과를 가져올수 있는 또다른 방법이 있다.따라서 최고/최저의 방법은 그때까지 알려진 것중에서만 말할수 있는 것" 이라고도 믿습니다.
이것은 불확정성 원리에서 도출되는 결론이죠,
괴델의 불완전성의 원리와 하이젠베르그의 불확정성의 원리는 비슷해 보이지만, 상당히 다른 원리이고 둘다 현재까지는 현대 사회에서 참인 것으로 받아들이고 있는 원리들입니다.
단순히 관측에는 한계가 있다라는 소견에서 결과는 불확정되어 있다라는 근본적인 아이디어를 배우실수 있기를..
참고로..
제가 믿는 가장 빠른 코드는 실행되지 않는 코드이며(비용소모가 0인)
가장 느린 코드는 끝나지 않는 코드입니다. (비용소모가 무한대인)
하지만 차원을 한단계 나아가면
이미 결과가 나와있는 코드가 더 빠를 것이고(입력하거나 실행의 시도조차 필요없으니까요)
다른 곳의 시간까지 잡아 먹는 코드가 더 느린 코드가 됩니다.
님이 어느정도
님이 어느정도 스스로 답하셨네요...
특히 두번째..
위에서 왜그런지에대한결과가될겁니다.
물론 님은 더이상생각을진행하지 않을지도 모르죠..
논리력을 좀더 키우시길..
간단히 반박하자면, 비용을 투자해서, 실행되지 않는 코드를 늘리는 방법도 있지요.
간단히, http://kldp.org/node/73324#comment-361727 를 님의 논리로 설명해 보세요.
어느분이 올리셨는지 모르지만, 자바의 실시간 최적화로 C 보다 빠른 케이스를 올려 주셨네요.
코드도 짤막하니 분석하기 좋을 겁니다. 뭐 그렇게 주장하셨던 "라이브러리를 호출하는 것이기 때문에 내부를 봐야 안다"라는 코드도 아니니까요.
이론도 증거도 없이 자기 생각만 우기기만 하시는 것은 이 글을 보는 다른사람들에게도 보기에 않좋습니다.
뭐, 불확정성의 원리의 기초가 되었던 동시관측불가를 가지고 "더 빠른 방법은 없다"라고 주장하시는게 이론이라고 들고 나오신 거라면, 좀더 공부하시기를 추천해 드립니다.
지속적으로 차원을 높여나가며 기존의 한계를 부셔 나가는 것이 항상 나오게 되어 있습니다. 기존의 틀에 사로잡혀서 사실을 왜곡하고 사실을 못받아들이지는 마시기 바랍니다.
공부좀더하시길.. >>"
공부좀더하시길..
>>"지속적으로 차원을 높여가며 기존의 한계를 부셔 나가는 것이 항상 나오게 되어 있습니다" ㅋㅋ
너무 어이 없습니다.. 아직도 어린애들처럼 4차원세계 꿈꾸시나요.. 이상한나라 폴과 함께 여행가실라고요? ㅎㅎ
뭐, 적절한 이론이나 근거를 못발견하시니 당연한 반응이겠습니다만..
제 공부가 부족하다는 것은 저 스스로 잘 알고 있습니다. 앞으로도 지속적으로 공부해 나갈 예정입니다.
차원이라는 단어를 잘 이해 못하시겠다면, 메타 레벨이나, 메타 솔루션이라는 단어는 더더욱 이해 못하시겠군요.
이 단어들은 IT하고는 별로 상관 없는 현대 수학의 이론적 근거가 되고 있는 것들인데요.
왜 현대 수학이라고 하느냐면은 괴델의 불완전성의 정리때문입니다.
님께 권하는 것은 "괴델,에셔,바흐 황금의 가지"라는 책을 한번 읽어 보시길 권합니다.
아니면, "괴델, 불완전성의 정리"도 좋을듯 싶고요. 이 정리때문에 수학체계가 한번 완전히 무너졌었을 정도로 현대사회에 큰 영향을 미친 정리입니다.
선인들의 수많은 경험과 연구를 집대성해서 학생들이 단기간에 섭취할 수 있도록 풀어써 놓은 좋은 교과서들이 있습니다. 저는 기본개념을 하나씩 설명하면서 절정고수들이 쓴 교과서에 기가막히게 해설해 놓은 이야길 왜 내가 짧은 글빨로 재탕을 해야 하나 환멸을 느낍니다.
자바진영이 좀
자바진영이 좀 이렇듯 별것도 아닌것을 대단한양 떠벌리는경향이 있습니다.
상술적인 그런것이 좀있어보이죠.
자바진영이 그런
자바진영이 그런 별것도 아닌것혹은 설사 자체적으론 개선효과가 있다하나 다른언어에비해 효과는 떨어지는것을
대단한양 크게 떠벌리는 경향이 있습니다.
상술적이라 보이는그런..
페이지
댓글 달기