Java 가 C++ 보다 빠르다..?
글쓴이: 신승한 / 작성시간: 수, 2004/06/16 - 4:52오후
다들 자주 가시는 /. 에 서 방금 본기사 입니다..
당연히, 다양한상황에서 다양한 결과가 나오고..
아직까지는 확실하게 검증 할수 있는 방법이 공인 된것이 없다지만..
흥미 있는 내용이네요..
벤치마킹을 각 알고리즘 별로 해서, 로그까지 남겨 놓았네요..
http://www.kano.net/javabench/
/. 에 올라온 글은..
http://developers.slashdot.org/developers/04/06/15/217239.shtml?tid=108&tid=126&tid=156
입니다..
한번씩들 보시고, 그런가 보다 하세요..
붙어서 싸우지들 마시고요.. :D
Forums:
javalobby.org에도 비슷한 류의 기사가 있습니다...정확
javalobby.org에도 비슷한 류의 기사가 있습니다...
정확히 같은 기사인지는 알 수 없습니다만, Javalobby에 있는 기사는 C와 비교, C++과 비교를 하고 있습니다...
http://javalobby.org/thread.jspa?forumID=61&threadID=12937
이곳에 가면 볼 수 있습니다...
osnews.com에서도 위 기사를 확인해 볼 수 있습니다... 댓글이 osnew에 더 많군요... -____-
http://osnews.com/story.php?news_id=7372
이곳입니다...
뭐... 항상 있는 논쟁에 또 하나 추가된 거네요...
위 기사에서 다루고 있는 것은 앞으로 나올 JDK 1.5에 관한 것입니다... 20%의 Performance 향상이 있다고 하네요...
그냥 참고만 하세요... 증명하기 힘든 Performance 논쟁이 또 이는 것은 바람직 하지 않겠죠...
가만보니 사기네요..ㅎㅎㅎ첫번째 소스하나 열어봤습니다.[c
가만보니 사기네요..ㅎㅎㅎ
첫번째 소스하나 열어봤습니다.
public class fibo { public static void main(String args[]) { int N = Integer.parseInt(args[0]); System.out.println(fib(N)); } public static int fib(int n) { if (n < 2) return(1); return( fib(n-2) + fib(n-1) ); } }#include <iostream> #include <stdlib.h> using namespace std; unsigned long fib(unsigned long n) { if (n < 2) return(1); else return(fib(n-2) + fib(n-1)); } int main(int argc, char *argv[]) { int n = ((argc == 2) ? atoi(argv[1]) : 1); cout << fib(n) << endl; return(0); }자바와 C++이 메인에서 인자 받아서 처리하는 일도 조금다르고.. C++더많죠
fib 함수내부에서도..자바에서는 if 로 만쓰고 C++에서는 if else 로 했군요.
그리고 자바에서는 int 형이고 C++에서는 long 형이군요..
더구나 이런코드에서는 자바에서도 크게 떨어질 이유가 없는코드들만 해놨군요.. 완전모략이네요..
----------------------------------------------------------------------------
[quote="ㅡ,.ㅡ;;"]가만보니 사기네요..ㅎㅎㅎ[/quote]
그러네요 ;;; 소스가 공개되어있길래 당연히 사기는 아니겠지 하면서...
그냥 넘어갔는데 --;;
근데 아무리 자바가 빠르다 어쩌다 그래도 같은 logic으로 같은 일을 하는 프로그램을 만들면 C++보다 빠를 수가 있나요? vm을 거치는데...
그냥 자바가 적당히 빠르고 C++, C보다 느릴순 있지만 "편하니까" 좋다라고 주장하는건 이해가 가지만 왜 C++, C보다 빠르다라고까지 주장하면서 flame을 일으키는지 모르겠습니다.
흠... 잘은 모르겠지만어떠한 알고리즘은 JAVA가 더 빠른 경우가
흠... 잘은 모르겠지만
어떠한 알고리즘은 JAVA가 더 빠른 경우가 있습니다.
(위와 같은 사기성 코드가 아닌 것으로 알고 있습니다)
_____________________________
언제나 맑고픈 샘이가...
http://purewell.biz
위의 소스를 보니 신빙성이 없어 보이네요. 벤치 마크의 의도도 그렇고요.
위의 소스를 보니 신빙성이 없어 보이네요. 벤치 마크의 의도도 그렇고요...
좀 더 공신력 있는 자료를 보여주는 곳이 있어 주소를 붙여 놓습니다. C++, Java, C#을 함께 비교해 놓았네요. 메모리 귀신 자바의 진면목을 확인할 수도~
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
대체로 성능 실험의 결과는, 자바가 C++보다 빠르지는 않을지언정 그렇게 느리지도 않다...인 것 같습니다.
게다가
http://java.sun.com/developer/technicalArticles/javaopensource/biojava/
와 같이 굉장히 성능 크리티컬한 분야에서도 자바가 널리 사용되고 있는 추세인 것 같고요.
그리고
자바가 C++보다 빠를 수도 있다는 얘기가 전적으로 플레임은 아닌 것 같습니다. 자바가 더 빠를 수도 있으니까요. 자바 바이트 코드가 실행시에 머신 코드로 변환될 수 있고, 자주 호출되는 코드 부분에 대해서는 최적화까지 수행할 수 있다는 얘기를 종종 듣곤 하거든요. 그렇담 C++보다 충분히 빠를 수 있지요.
(제가 붙여 놓은 벤치마크에서도 hashmaps의 경우 자바가 훨씬 빠르네요...)
[quote="thedee"][quote]근데 아무리 자바가 빠르다 어쩌
물론 자바로 짠 코드가 더 빠를 수도 있다는 것은 인정합니다. 머신코드로 변환해 수행하고, 최적화 잘 하면 더 빠를 수도 있겠죠. 그치만 이건 C++도 최적화 잘 하면 된다는 것과 같은말 아닌가요? C++도 표준 라이브러리를 얼마나 최적화했냐에 따라 다를 수 있는 것이고요. 함수콜 얼마나 복잡하게 하냐에 따라 다를 수 있고요. 아마도 hashmap이 이런 부분이 아닐까 싶네요.
그치만 그런 사항 하나하나 비교한다는 것이 무슨 의미가 있나요. 아무리 C, 어셈으로 만들어도 최적화를 제대로 하지 않거나 구현을 좀더 제네릭하고 복잡하게 만들면 자바보다 느릴 수 있고, 그 반대의 경우 자바가 빠를 수 있는 것입니다. 그치만 자바의 기본 특성상 (보통의 경우) C, C++보다 느린 것은 당연하잖습니까.
전 자바의 장점이 비교적 사용하기 편한 OO언어, 그리고 방대한 기본 라이브러리에 있다고 봅니다. 속도면보다 이것을 선택한 사람은 자바를 사용하겠죠. 그리고 그 선택 안에서 최대한의 속도를 내기 위해서 이런저런 최적화를 수행하겠죠.
이런 점에서 볼때, "자바도 이런저런 최적화를 수행했더니 꽤 좋은 속도가 나오고 심지어 C++을 능가하기도 한다" 이런 말은 정말 와닿습니다.
그치만 자바를 쓰는사람들이 마치 속도에 컴플랙스를 잔뜩 가진 양 저렇게 "자바는 C++보다 빠르고 C++는 sucks하다"고 주장하면 곤란하다는 것입니다.
너무 민감하신 것 같네요... 자바가 빠른들 어떻고 C++가 빠른들 어떻
너무 민감하신 것 같네요... 자바가 빠른들 어떻고 C++가 빠른들 어떻습니까?
같은 말이 아닙니다. 자바는 실행시간에 자신의 코드를 계속 감시하고 있다가 호출이 잦은 부분을 찾아내 최적화하는 기능을 제공하는 것으로 알고 있습니다. C++에서 그런 기능 얘기를 들어 본적이 없습니다.
당연한가요? 꼭 그렇지는 않다고 말씀드린 것 같은데요... 자바 바이트 코드가 실행시에 머신 코드로 변환되고, 실시간으로 성능 최적화 기능을 제공하고, 수치 관련 메소드는 직접 하드웨어에 접속하여 연산을 수행한다면 자바가 기본 특성상 C\C++ 보다 성능이 떨어질 까닭이 없지 않나요?
오히려 콘솔에서 java -jar XXX를 치고나서는 자바 너무 느리다, GUI 반응성이 너무 떨어진다... 라는 느낌만 가지고 자바는 느린 것이야... 하고 결론을 내리는 것이 더 피상적인 것은 아닐까요?
자바의 성능은 C++에 필적하는 수준이 되었습니다. 이게 현실이라 보고요. 벤치 마크 소스를 속여가며 자바가 C++보다 빠르다고 강변하는 것이나, 자바가 원리상 어떻게 C++보다 빠를 수 있느냐고 맞서는 것이나 다 생산적이지 않을 것 같네요.
[quote="thedee"]너무 민감하신 것 같네요... 자바가 빠른들
(그렇게 하는 것이 C++에서 코드 전체를 잘 최적화해서 컴파일해 돌리는 compiler 기술보다 빠르리라고 생각하지는 않지만 제 개인적인 생각입니다.)
그렇게 해서 자바와 C++이 비슷한 속도를 가질 수 있다고 합시다.
제가 그래서 "기본 특성" "보통의 경우"라고 강조하고 강조했잖습니까.
java -jar XXX 해서 느린건 자바가 느린게 아니고 GUI 반응성이 떨어지는건 자바가 반응성이 떨어지는 것이 아닌가요? 어떻게 실행시 머신 코드 변환하고 실시간 성능 최적화 하는 것이 자바의 기본 특성인가요? 그건 자바 프로그램을 좀 더 빨리 돌리기 위해 제공하는 최적화 솔루션일 뿐입니다. 또, 자바로 만드는 모든 프로그램이 그 최적화 솔루션을 모두 거칠 수 있는 것도 아닙니다.
컴파일러 (인터프리터, or VM) 수준에서 봐도 reference implementation이라고 보는 sun's jdk, 좀더 최적화를 잘 해서 빠르다 생각이 되는 ibm's jdk 등 jdk마다 제공하는 최적화 정도도 다릅니다. 마치 범용적으로 쓰이는 gcc와 x86에서 훨씬 빠르다는 icc가 존재하는 것처럼요.
산업계 현장에서 여러 최적화 솔루션을 잘 도입해 "이제 C++과 별 차이 없거나 더 빠르다"라고 하는 전문가가 있는가 하면, data structure, os 숙제를 자바로 하면서 "졸라 느리네" 하는 학생도 있습니다.
또 시작이다.
mp3 에 이어 다음 타자가
타석에 들어섰군요.
수십번 수백번 반복되면서
소모적인 논쟁에 아무 성과도 없이
서로 감정싸움까지 일으키는
대표적인 주제 중의 하나지요.
담배 이야기
mp3
Windog 랑 리눅스 비교
Java 랑 .Net 이나 C++ 과의 비교
선거철 정치 이야기
또 뭐가 있더라?
개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?
[quote](그렇게 하는 것이 C++에서 코드 전체를 잘 최적화해서 컴
자바가 한참 느릴 때도 자바의 핫스팟이나 jit 때문에 자바가 기본 특성상 C++보다 빠를 수 있다고 얘기하는 사람들이 있었습니다.
그러니까 그 보통의 경우가 어떤 경우냐가 문제인 거지요. 일반 데스크탑 어플의 경우가 그 보통의 경우라면, 자바는 님 말씀대로 성능상의 여러 난점으로 데스크탑쪽에서 널리 쓰이고 있지 못합니다. 그러나 그 분야가 자바가 이용되는 보통의 경우인지 어쩐지는 사람마다 의견이 다르겠죠.
그러니 이렇게 말하는 것이 더 정확하지 않을까요, 자바는 스윙의 성능과 기능의 제약으로 클라이언트측에는 크게 어필하지 못하고 있다고...
자바는 원리상 C++보다 느릴 수 밖에 없고, 자바는 개발 효율상의 잇점을 얻기 위해 선택되는 언어다...라는 주장하고는 좀 느낌이 다르지 않나요?
자바가 C++에 필적하는 성능이 나오고 있다는 것이 그 최적화 솔루션 때문이 아니라는 것을 누누히 말씀드렸는데요...-.-
그리고 간단한 데이터구조 숙제를 >java XXX하고 나서 "졸라 느리네"하는 학생들 분명히 많습니다. 그 졸라 느림에는 가상 머신의 로딩 시간이 있는 거구요. 이런 식의 (죄송합니다만) "피상적인 경험"을 가지고 자바의 성능에 관해 논하지는 말자는 얘기입니다.
저의 생각을 정리하자면, 현재 C++이 전반적으로 자바보다 성능상의 우위를 갖고 있다고 생각하지만, 자바가 C++보다 뛰어난 성능을 보인다고 해도 전혀 놀랄 바가 아니라는 얘기죠. 자바가 뛰어날 수도 있는 거죠.
마치 사람이 하늘을 날 수 있듯이, 혹은 달나라에 인간이 착륙할 수 있듯이 말입니다...
위의 벤치 마크의 신빙성은 별 문제로 하고, 스윙으로된 GUI를 제외하면
위의 벤치 마크의 신빙성은 별 문제로 하고, 스윙으로된 GUI를 제외하면 특히 반복적으로 실행되는 연산의 경우 JIT의 사용으로 인해 자바가 C/C++ 등에 비해 유리한 면이 있습니다.
자바 VM이 최적화 하는 것 만큼 C/C++도 프로그래머가 최적화 시키면 되는게 아닌가 하고 반문할 수 있지만, JIT의 핵심은 그런 최적화를 실제 실행 시간에 실행되는 환경에 맞춰서 할 수 있다는 점이고, 이런 종류의 최적화는 컴파일 타임에 할 수 없습니다. 그럼 JIT를 C/C++로 구현하면 되는게 아니냐 할 수 있지만 JIT나 VM기술이 그렇게 단순한게 아닙니다. 그렇게 따지면 모든 프로젝트는 어셈블리로 짜야겠지요...
자바 VM이 C/C++로 되어 있다고 C/C++보다 빠를 수 없다면, 위의 osnews에 올라온 그럴 듯한 비유를 들어 보자면 설사 베이직 프로그램도 만일 그 프로그램이 최적화된 어셈블리 코드를 생성해서 이를 실행하는 역할을 한다면 동일한 역할을 하는 C/C++보다 빠를 수 있다는 점을 말씀 드리고 싶습니다.
현재 자바의 문제는 라이센스, 배포방법이지 속도가 아닙니다. 스윙 GUI의 경우 최근 많은 향상에도 불구하고 여전히 무겁지만 SWT 등을 사용하면 네이티브 GUI를 얼마든지 만들 수 있습니다.
보통 자바가 느리다고 생각하는 건 주로 사람들이 스윙으로된 GUI를 사용하거나 예전 버전에서 코드의 실행 시간이 아닌 JVM 시작 시간이 지나치게 길었기 때문입니다. 최근에는 이 부분에도 많은 향상이 있었지만 어쨌든 자바가 주로 사용되는 서버 환경에서는 설사 시작 시간이 10초라고 해도 사실상 의미가 없는 값이기 때문입니다.
마지막으로 저런 식의 벤치마크는 흥미 거리 이외에 크게 중요하지 않습니다. 자바든 C/C++이든 메이저 급 언어들은 거의 대부분의 영역에서 '충분히' 빠릅니다. 중요한 건 특정 수학 식을 백만번 돌리는데 1초가 늦느니 빠르니 하는게 아니라 실제 특정 비즈니스 영역에서 특정 문제를 풀기 위해 해당 사용자층이 만족할 수 있는 수준의 성능을 기대할 수 있는가 입니다. 최소한 서버 측에서, 그리고 최근 클라이언트에서 SWT를 통해 자바는 이런 점에서 충분히 성공했고 그래서 지금 가장 많이 쓰이는 언어 중 하나가 된 것입니다.
JIT, VM을 사용하는 언어의 벤치마크나 성능은 그렇게 간단한 문제가 아님에도 너무 많은 사람들이 단편적 지식이나 잘못된 상식으로 단정적으로 말하는 경향이 있는 것 같습니다. 기술적으로 위의 벤치마크에 흥미가 있으시다면 슬래쉬닷의 몇몇 커멘트만 읽어봐도 상당한 도움이 될 것 같군요,,,
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote]자바 VM이 C/C++로 되어 있다고 C/C++보다 빠를 수
아무리 그래도 인정할것은 인정해야죠..
위의말은
고 말하는거나 같습니다. 이말이 무슨의미가 있나요..
빠를수야. 있지요.. 하지만 이게 빠른게달릴수있는물체를 아는데 무슨도움이 되나요. 이말하는자체는 사람을현혹하려하는의도일뿐입니다.
----------------------------------------------------------------------------
[quote="thedee"]자바가 C++에 필적하는 성능이 나오
어쨋거나 사용자입장에서 느린거 아닌가요?
사용자 입장에서 어떤작업을 수행하기위해 컴퓨터를 켜서 작업하고 검퓨터를 끄기까지..실제 느리게된다면 느린것 아닌가요?
----------------------------------------------------------------------------
[quote="ㅡ,.ㅡ;;"][quote="thedee"]자바가
가상 머신의 로딩 시간 때문에 느린 것이 '언어 본연의 느림'이라면 C++도 컴파일이 너무 느려요.. 하지만 그 뒤엔 충분히 빠르지 않습니까? 아무래도 이쪽이 C++의 본연의 속도죠? 자바의 로딩 시간이 자바의 속도인가요, 아니면 그 다음부터가 자바라는 언어의 선천적인 속도인가요?
----------------------------
May the F/OSS be with you..
[quote="ㅡ,.ㅡ;;"][quote]자바 VM이 C/C++로 되어
왜 그게 같은 비유가 되나요? 자바 VM은 실재로 런타임에 최적화된 네이티브 바이너리 코드를 생성하고 실행합니다.
실무에서 쓰이는 자바 언어 대부분이 서버 측에서 동작하는 것을 생각해보면 그 '사용자 입장'이라는게 JVM의 로딩 시간에는 전혀 관심도 없습니다.
ㅡ,.ㅡ;;님께서는 일년에 몇번 껐다킬 서버를 구입할 때 부팅이 1-2초 빠르다고 런타임 속도 느리고 관리도 불편한 제품을 구매하시겠습니까?
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote="hey"]가상 머신의 로딩 시간 때문에 느린 것이
컴파일은 만드는데시간이죠? 수행시간이 아니죠..
사용자가 컴파일하지는 않습니다.
----------------------------------------------------------------------------
[quote="fender"]왜 그게 같은 비유가 되나요? 자바
현제 자바로짠것은 C로짠거보다 대부분 느리다는건 인정하시나요?
(사람도 출발직후 한발짝정도는 빨리 나갈수 있습니다.)
자바는 런타임에 최적화한다면 C는 컴파일때 최적화합니다.
(머신마다 환경이 다르다고요? 자바가 그렇다해도 C보다 빠른경우는 잘못봤거든요..설사 그것이 크게 작용한다면 머신마다 다르게수행하도록자면되죠..)
JVM 로딩에 관심이 없다고요? 몇몇사람들은 자바까는자체로 윈도우가 느려졌다고 불평이던데요
또한 부팅이 1~2초 차이나지 않죠 더나죠.. 그리고 런타임속도가 자바가 빠르다고 판단될만큼 빠른경우 거의못봅니다. 아니 아예 빠른경우를 거의 찾아보기 힘듭니다. 물론 특수한경우 빠른경우도 있겠죠.. 하지만 그런경우를두고 자바가 C보다 빠르다고 할수는 없겠죠 대부분의 경우를 생각해봐야 하지 않나요..
둘다 최적화하여 짠다고 생각해봅시다.
자바가 굉장히 최적화하고 자바의 특성과도 아주 부합하는 작업을 한다고 칩시다.
C가 자바와흡사한 수행을하게 짜는게 안될까요? 최악의경우 자바와 거의 흡사한수행을 하게 짤수도 있습니다.
대부분은 불필요한 요소는 제거할수 있고 더최적화할수 있겠죠..
----------------------------------------------------------------------------
C++은 static optimization만 가능하지만,Java는
C++은 static optimization만 가능하지만,
Java는 dynamic optimization이 가능합니다.
( 위에서 둘다 똑같이 optimize가능한데 왜그러냐 ? 하셔서 -_-a )
그래서 빠를 수 있는 가능성이 있다는 얘기가 나오는 것이고요.
( C보다 빠른 경우는 그다지 없지만, )
( STL을 쓰는 C++에 비해 빠른 경우는 종종 있다더군요. )
물론 대부분은 서버 애플리케이션에 한정되는 경우입니다만.
어쨌든 이제 속도때문에 C++를 써야하는 경우는,
GUI가 들어가는 소프트웨어나 게임들에 국한되어가는 것 같습니다.
뭐 다른 이유가 있는 경우엔 할 수 없겠지만요.
( C++로 작성된 라이브러리들을 사용해야한다던가 하는 .. )
C++만큼 빠르다, 까지는 아니어도 이제 충분히 빠르다, 라고는
할 수 있을 수준에 이르렀으니까요.
[quote="ㅡ,.ㅡ;;"][quote="fender"]왜 그게 같은
자바가 런타임에 최적화 한다는 건 단순히 C/C++와 동일한 최적화를 시점만 다르게 한다는 것이 아닙니다. JIT의 진정한 의미는 런타임에만 알 수 있는 프로파일링 정보 - 예를들어 사용자 PC의 정확한 CPU 타입 - 를 이용해서 최적화 한다는 뜻입니다.
이런 특성이 가장 크게 드러나는 부분이 단순 연산을 여러차례 반복하는 종류의 벤치 마크이고 이미 그런 부분에서 자바가 C/C++보다 우수한 성능을 보일 수 있다는 벤치 마크 결과가 많이 나와 있습니다. 물론 그게 실무에서 어떤 의미를 가지는 지는 생각해볼 문제입니다.
아무래도 ㅡ,.ㅡ;;님의 경험은 대부분 윈도우즈 데스크탑에서 자바 애플릿이나 스윙 어플리케이션들을 구동해보신 것 같군요. 저는 자바 스윙이 데스크탑 어플리케이션에서 최적의 성능을 낸다고 생각하지 않습니다. 하지만 서버에서는 최적의 성능을 낼 수 있고 실제로 실무에서 쓰이는 대부분의 자바 언어는 서버측 개발입니다.
즉, 자바 언어가 사용되는 '대부분의 경우'라는게 님의 말씀 처럼 윈도우즈에 JRE깔았다고 느려진다고 착각하는 사람들이 쓰는 프로그램이 아니라 대부분 서버에서 미션 크리티컬한 어플리케이션을 돌리는 경우라는 뜻입니다.
다른 이야기지만 최신버전 JVM 로딩이 2초 이상 걸린다면 업그레이드를 생각해보실 때가 된 것 같습니다. 제 회사 PC 펜티엄 800/377 RAM에서 HelloWorld가 JVM 부팅까지 0.4초 걸립니다만...
가능 합니다... C/C++로 JVM도 만들고 JIT도 만든 다음에 실제 어플리케이션도 구현하면 되겠지요 -ㅅ-;;
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
딴일하는 사이에 쓰레드가 이렇게 길어졌네요 ;;;지금 자바는 서버
딴일하는 사이에 쓰레드가 이렇게 길어졌네요 ;;;
지금 자바는 서버쪽 분야에서는 위에서 말한 최적화로 인해 C++과 비슷한 성능에 와서 많이 쓰이고 있습니다. 저도 많이 쓰이는거 아는데, 자바는 그게 다가 아니라는 겁니다. 제 생각에 자바가 진정 C++보다 빠르면 데스크탑쪽까지 다 먹었을 거라고 생각합니다.
서버쪽도 자바가 성능이 좋아서 많이 쓰이는 것이 아니라, 비교적 쉬운 OO언어인데다가 (C++보다 확실히 쉽죠;; ) 방대한 기본라이브러리로 무장해서 많이 쓰이게 된거라고 생각하거든요. C++이 자바보다 쉽고 편하면 자바 쓸 이유가 없었겠죠. (자바가 막 나왔을때를 생각해보자면요.. 그때는 machine independent라는 이상한 말도 안되는 꾀에 속아넘어간 면도 있죠.)
그 다음에 좀 더 쉬운 언어를 잘 돌아가게 하려고 머리 열심히 써서 서버쪽에서는 C++ 또는 C 수준까지 올라간 것입니다. 데스크탑쪽은 아직 최적화를 해도 C++또는 C의 속도를 쫓아갈수가 없으니 안쓰이고 있는 것 뿐입니다. 원래 자바가 서버쪽에 쓰이는 언어인 것이 아니라요.
그렇기 때문에 전 "보통의 경우, 원래 정의에서의" 자바가 C/C++보다 느린 언어라고 말하는 것입니다. 지금 자바에 적용되고 있는 온갖 최적화를 무시하는 것이 아니고요. 원래 인터프리터 언어가 컴파일러 언어보다 느리다는것은 기본 상식 아닌가요? 물론 그 인터프리터에 열라 최적화를 했더니 서버의 경우엔 컴파일러보다 좋을 수도 있는거죠. 그리고 서버의 경우엔 인터프리터 뜨고 죽고 하는 시간을 무시해도 좋다는 아주 좋은 조건도 있죠.
그치만 콘솔 어플리케이션을 짰을때, GUI 프로그래밍을 할 때, 게임을 만들때, 웹브라우저에서 애플릿이 뜰 때 아직 많은 부분에서 자바가 C++, C보다 느린건 사실이지 않습니까. (서버쪽도 누가 빠르다 판명난건 아니죠. 아니, 판명나기가 힘들다고 봅니다. 같은 CPU로 계산만 열라 하는데 누가 확실히 빠를리가 있겠습니까, 각 경우에 일장 일단이 있겠죠)
(전 C++ 옹호자가 아닙니다. 저 C++ 공부 많이 하긴 했지만 할수록 꼬여드는 어려운 문법, 표준이 구현하기 어렵고 이상해서 고의든 아니든 제대로 지원하는 컴파일러가 없다는것. 등 여려가지 이유로 C++ 별로 안좋아합니다. C는 매우 좋아하지만, 자바의 상대로서 좋아하는게 아니고 그냥 제 시작이 C라서 정이 있는 것이고...)
제가 하고 싶은 말을 어느정도 이해했으리라고 생각합니다. 하여튼 결론은 자바 속도 컴플렉스 걸린것처럼 자바가 C/C++보다 이제 빠르니까 C/C++은 발붙일 자리가 없을 것이고.... 하는 주장은 아직 할 수도 없고 (자바가 느린 영역이 많으니까) 할 필요도 없다는 것입니다 (자바의 주무기는 속도가 아니고 쉬운 언어 + 방대한 라이브러리니까)
이런 인터프리터도 열라게 최적화하니까 서버 영역에서는 이정도 빠르고 쓸만하더라. 이런 얘기가 좋다는 겁니다.
제가 쓴 글을 이해하지 못하여 올리는 질문을 받는 걸 제외하고는 여기서 마치도록 하겠습니다.
ps) 제가 한참 C, C++, 자바 사이에서 고민할때 생각했던건, 왜 자바정도로 쉽고 (또는 그 외 perl, python자체처럼은 못가더라도, 어느정도 쉽고) C/C++처럼 컴파일되는 언어가 안나올까 하는 것이었습니다. 그래서 요즘 D 언어를 접하고 한참 쳐다보고 있죠 --;;
ps2) 이 아래부분은 지금 주제와 별 관계없는 생각이니 트집잡지 말아주세요. 이 아래 생각때문에 위의 결론이 달라지는 건 아닙니다. 지금 자바의 런타임 최적화가 어떻게 이루어지고 하는 말이 많지만 아무리 그래도 기계, OS에 독립적인 코드로 짠 걸 인터프리터가 열라 쳐다보고 최적화하는것보다는 처음부터 각 기계, OS에 맞게 잘 짜고 컴파일한 것이 빠를거 같다는 생각입니다. 물론 그렇게 하면서 자바만큼 쉬우면 훨 좋겠죠.
[quote="eungkyu"]ps) 제가 한참 C, C++, 자바
GCJ
싸울걸 뻔히 알면서 이 쓰레드를 올린 분의 심리가 좀 이해가 안가네요.
싸울걸 뻔히 알면서 이 쓰레드를 올린 분의 심리가 좀 이해가 안가네요. -_-;
생각해보니 이해는 가는군요. 그런데 올리시지 않는게 나았을 것 같습니다. ^^
다시 말씀드리지만 저런 식의 벤치 마크 결과는 별 의미가 없습니다. 그리
다시 말씀드리지만 저런 식의 벤치 마크 결과는 별 의미가 없습니다. 그리고 "자바는 인터프리트 방식이라 무조건 C/C++보다 느리다"라는게 말이 안되는 것 처럼 "자바는 JIT 방식이라 C/C++보다 무조건 빠르다"도 말이 안되는 건 마찬가지 입니다.
실무에서 성능 병목이 CPU에 걸리는 경우는 생각보다 많지 않습니다. 자바든 C/C++이건 각자 적합한 부분이 있고 그 특성을 제대로 이해하고 잘 쓰면 그만인 것이지요.
다만 데스크탑 어플리케이션 영역에서의 자바도 충분히 가능성이 있고 특히 최근 그런 움직임이 보이고 있다는 점은 지적하고 싶습니다.
개인적으로 SWT + RCP + GCJ + Eclipse VEP 정도가 데스크탑 자바의 미래라고 생각합니다. 지금도 Azureus이나 Sancho등이 충분히 가능성을 보이고 있으니까요.
스윙이 느린게 자바로 만들어서 그런 것도 아니고, 스윙만이 클라이언트 자바의 전부가 아닙니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote="TooCooL34"]싸울걸 뻔히 알면서 이 쓰레드를 올린
동의합니다. 이건 어떻게 해도 플레임성 게시물밖에 안될 것 같습니다.
[quote="TooCooL34"]싸울걸 뻔히 알면서 이 쓰레드를 올린
헙... :shock: ..OTL...
소햏을 즈려 밟아 주세욯..T,.T
[quote="sangu"][quote="eungkyu"]ps) 제가
gcj도 열심히 쳐다보긴 했었는데, 수많은 클래스 라이브러리 포팅하다가 시간 다가는걸 보고 의욕을 잃었다죠. ;;; 역시 그런걸 한번에 해낼려면 거대 벤더가 붙지 않으면 안될거 같더군요. 오픈소스에서 할 일은 이미 있는걸 잘 조합하는 것이지 거대 벤더가 열라 만들어놓은거 바닥부터 따라만드는건 아닌거 같다는 마음이 들면서 안보게 되었습니다.
D는 상당히 괜찮아보이긴 하는데, 이미 거대 벤더가 주도하는 개발환경 싸움에 틈새가 날지... 그래도 C 라이브러리를 그대로 사용가능하니 취미생활로 건들기에 딱인거 같습니다. 벌써 조그만 프로그램 짜는데 한몫 하고 있습니다 :)
[quote="eungkyu"]gcj도 열심히 쳐다보긴 했었는데, 수
Red Hat에서 밀고 있습니다. Fedora Core 2에 GCJ로 컴파일한 ant, tomcat등이 있어요. 원래는 GCJ로 컴파일한 eclipse 2.X도 포함될 예정이었는데 현재는 eclipse 3.x를 가지고 열심히 컴파일하고 있습니다.
요즘은 모노 vs GCJ로 인해서 더욱 열혈 모드로 GCJ 해커들이 작업하는 것 같네요.
[quote="eungkyu"]ps) 제가 한참 C, C++, 자바 사이
자바 정도로 쉽고 C/C++처럼 컴파일되는 언어 있습니다.
Object Pascal 써보세요. ( Delphi / Kylix )
Pascal은 C보다 더 오래된 역사를 가지고 있고,
자바는 사실 C/C++보다는 Object Pascal에 가깝습니다.
RAD Tool을 원하지 않으시면 Free Pascal도 있습니다.
http://www.freepascal.org/
그리고 자바 VM은 인터프리터라고만 할 수는 없습니다.
인터프리터와 Native code의 중간 정도라고 봐야죠.
( 한번 interpreting된 부분은 이후 실행될 때 native code로 동작합니다. )
또 최적화는 실제로 run-time 최적화가 더 효율적입니다.
그래서 각 프로세서들도 실제로 실행 중에 하드웨어적인 최적화를 수행합니다.
( 대학원 수준에서 보는 Computer Architecture 책을 보시면 압니다. )
Compiler는 실제로 실행되는 상황을 알 수가 없기 때문에,
static한 optimize밖에 수행할 수가 없습니다.
그러나 VM 혹은 하드웨어의 경우는 실제 실행되는 trace를 알기 때문에,
dynamic하게 optimize할 수 있죠.
( 예를 들어 어떤 if문이 있는데 거의 대부분은 else로 간다고 합시다. )
( Compile 단계에서는 이런 사실은 거의 알 수 없습니다. )
( 하지만 VM이나 하드웨어는 실행중에 이 사실을 알고 최적화할 수 있죠. )
[quote="ㅡ,.ㅡ;;"]가만보니 사기네요..ㅎㅎㅎ첫번째 소스
코드르 보니 꼭 사기 같지는 않습니다...
일단, i386에서 실험을 한 듯 한데요, i386에서 long과 int 둘 다 32-bit integer 입니다. 그리고, parsing 하는 쪽이 다르다고 말씀하셨는데요, 어차피 parsing 하는 부분의 수행시간은 수 마이크로초 단위일 것입니다. 기껏해야 수백개의 instruction만 실행하면 끝날 루틴인데.
if문 후에 else 없는 것은, 어차피 compiler optimization 거치고 나면 똑같아지는 것이겠고요. 어셈으로 짜보시면 아시겠지만 두개를 else 있는 경우와 없는 경우를 다르게 짜는 것도 만만치 않을 것입니다... -_-;;
제 생각에, 이 benchmark에서 java가 이기는 것은 아마 딱 한가지일 것입니다. branch prediction. java는 수행중에 코드의 흐름을 프로파일링해서 어느 쪽 branch가 많이 가는지 예측을 할 수 있을 것이고, 많이 가는 쪽의 code가 더 빠르게 수행될 수 있게 하면 성능 향상이 어느정도 더 나겠죠. 이는 어떤 instruction을 선택해서 컴파일 할 것이냐는 것 뿐만 아니라, 실행할 instruction의 순서를 정하는 것... 즉 scheduling이라는 면에서도 아마 작용할 것입니다. 문제는 c++의 입장에서는 어느게 더 많이 실행되는지 compile-time에 짐작하기 힘들다는 것이죠. 그런 면에서, 이런 경우에는 java가 성능이 더 좋은 것이 무리는 아니라고 봅니다.
단, 현실적인 경우에, 이런 코드가 엄청나게 많은 수행시간을 잡아먹으면서 실행할 일이 있는지가 문제겠죠. 제 생각에 java가 불리할 만한 경우(가령 작은 블록의 memory allocation을 무쟈게 많이 하는 경우라던지)가 현실적으로 더 많을 것이라 생각합니다.
아무리 그래도 VM load하는 시간을 제외한다면, 그놈이 그놈이 아닐까 하는 생각이 듭니다. 차라리 코드 몇줄을 더 깔끔하게 짜는 것이 현실적으로 더 좋을 것이라 봅니다...
ps : 실제로 native 기계어에서 저 짓을... 그러니까 runtime에 최적화를 해 주는 것에 대한 연구도 여러 차례 있었습니다... 제가 지금 기억나는 것으로는 HP에서 한 dynamo라는 것입니다. PA-RISC 기계어를 runtime에 다시 PA-RISC 기계어로 컴파일을 하는... 뭔가 얄딱꾸리-_-한 목표를 갖고 있었는데요... 결국 수행시간이라는 면에서는 상당한 성능향상을 보였다고 합니다. 물론 재컴파일하는 데에 걸리는 시간을 고려해야할테니 매우 자주 실행되는 코드에만 적용시킬 수 있다면 좋겠죠.
dynamo에 대하여 ars technica에서 쓴 기사입니다. http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
또 ps : gcc에도 runtime의 information을 추출해서 최적화를 하는 방법이 있습니다. 한번 그냥 컴파일을 하되, 실행시 실행되는 방향에 관한 정보를 추출하고, 그다음에 그 정보를 이용해서 재컴파일을 해서 바이너리를 생성해 내는 방법이죠. 뭐 runtime에 정보를 추출해서 즉시 재컴파일을 하는 경우가 좀 더 낫긴 하겠지만(어떤 입력을 갖고 실행되느냐에 따라 최적화되어야 할 방향이 다를 수 있으므로) 그래도 꽤 성능향상이 있었던 것으로 기억합니다.
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
플레임이라고만 여겼는데, 아예 언어적인 차이보다 runtime optii
플레임이라고만 여겼는데, 아예 언어적인 차이보다 runtime optiimization 과 compile-time optimization 에 대한 얘기로 전환하는 것도 나쁘진 않겠네요. =)
:twisted: 빠른들 어떠하리 느린들 어떠하리가상머
:twisted:
빠른들 어떠하리 느린들 어떠하리
가상머신 OOLong이 헬로 찍은들 무엇하리
아무거나 튜닝툴 잡고 병목이나 잡아보세.
ㅋㅋㅋ.
You may say I'm a dreamer.
But I'm not the only one.
cvm 나와야 겠군요..
cvm 나와야 겠군요..
----------------------------------------------------------------------------
[quote="wildkuz"]:twisted: 빠른들 어
종장의 첫구는 세 음절이어야 한다더군요. :roll:
--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!
[quote="차리서"][quote="wildkuz"]:twisted:
그.. 그럼 '암거나'로 =3
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
Java가 처음 나왔을 때, VM은 하나의 명령을 한번에 하나씩 순차적으
Java가 처음 나왔을 때, VM은 하나의 명령을 한번에 하나씩 순차적으로 처리하는 byte code interpeter였습니다. 느릴 수 밖에 없는 구조라 이것을 개선하고자 소개가 된 것이 JDK 1.1에서부터 시작된 JIT compilation입니다.
1.1과 1.2에서는 각각의 클래스는 최초 실행전에 JIT에 의해 machine code로 compile이 되었습니다. 그렇지만, 여전히 느릴 수 밖에 없었는데 이유는 byte code 형태로 된 개개의 클래스를 machine code로 compile 할 때 한 번에 하나씩 밖에 할 수 없었기 때문입니다. 또한, 여전히 수행 속도를 향상 시키는데 문제로 남는 것들이 runtime에 array access나 type casting에 대한 check가 이루어진다는 것들이었습니다. Object가 stack에 들어갈 수 없고 heap에 위치되어야 한다는 점도 문제고요.
Java 언어 자체를 array bound나 type cast check를 않도록 한 것외에, 위의 compile문제를 해결하고자 한 것이 1.3에서부터 등장하는 Hotspot VM 입니다. compile 된 machine code를 클래스들이 변경에 되는 경우 runtime에 다시 compile을 하는 거죠. 왜 이게 속도의 향상에 도움을 주는가 하는 것은 어플리케이션이 수행되는 시점에 분석이 되고 이를 반영하는 결과에 의해 최적화가 이루어지기 때문입니다. 그리고 machine code로의 compile이 VM이 충분히 어플리케이션의 동작이 어떻게 이루어지고 있다는 것에 대한 정보를 가진 후에 이루어지므로 한번에 몽땅 compile을 아무 정보없이 한 경우보다 훨씬 정확히 최적화를 할 수가 있게 되는거죠. 그럼, 어떻게 최적화가 이루어지냐 하는 것은, 하드웨어에 따라 즉, 예를 들어 수행되는 기계가 pentium2 냐, pentium3냐, 다른 pipeline을 쓰는 것 등을 감지하여 profiling이 이루어 집니다.(어느 기계에서 수행되는지 모르고 compile하고 수행시키는 것보다 최적화가 더 잘 되겠죠.) -- 사족 1, 이 부분이 위에 다른 분들이 java가 c++보다 경우에 따라서는 더 빠를 수도 있다고 claim하는 근거의 요체입니다. -- 사족 2, java -X 옵션해서 살펴보면 여기에 적힌 것을 대충 짐작하실 수 있는 옵션들을 보실 겁니다. mixed 모드가 기본 설정이 되었으니, 그냥 java 해서 시작하면 위에 이야기한 것이 동작을 하는 겁니다. -- 사족 3, 최적화의 정도는 제공되는 JDK에 따라 다릅니다. Sun VM과 IBM VM에서의 최적화가 다릅니다. -- 사족 4, 더 빨라질 여지가 있습니다. 1.3 에서 1.4로 20%, 1.4에서 1.5로 또 20% 속도 개선이 1년 또는 2년 내에 이루어지고 있으니 예전에 느리더라 하는 것은 옛날 이야기 입니다.
이밖에 Java Static Compiler에 의한 수행 속도 향상을 꾀하는 경우도 있는데 이것에 대한 언급은 생략합니다.
이렇게 performance를 향상시키는 개선이 이루어진 결과 Java도 이제는 C/C++정도로 빠르지 않느냐 하고 말하는 겁니다.
무슨 언어가 빠르더라 하는 것처럼 부질없는 것이 없다는 생각을 하고 있지만, 상대방의 주장에 기술적인 근거가 되는 지식의 보유 여부를 떠나, 알려고 또는 이해하려고 하는 노력(또는 예의)조차 안하려는 듯한 글들이 보이기에 적어 놓습니다.
----
I paint objects as I think them, not as I see them.
atie's minipage
VM 기술이 현재 어떻게 진행되고 있는 지 궁금하네요...사실,
VM 기술이 현재 어떻게 진행되고 있는 지 궁금하네요...
사실, VM의 Loading 시간이 Desktop Java에게 가장 큰 걸림돌이라는 것은 아마 모두들 숙지하고 있는 사실일 겁니다...
가장 근본적인 해결책은 System이 부팅되면 그 때 같이 VM을 Loading하고 그 VM을 모든 Java Application이 공유하다가 System이 종료될 때, VM도 같이 종료되는 거지요...
이렇게 된다면야 VM Loading으로 인한 불만은 다 없어지리라고 봅니다... 나아가서는 Java의 느림에 대한 불만도 많이 없어지겠죠...
그렇지만, Application들이 VM을 공유하는 것이 현재는 지원되지 않는다고 하더군요... 그래서 Java Application을 2개 띄우면 2개의 VM이 돈다고 하던데...
JDK 1.5에서 지원된다는 말이 잠깐 있었는데, 어떻게 되어 가고 있는 지 궁금하네요...
아! 공식적인 명칭이 있죠... Shared VM...
http://java.sun.com/j2se/1.5.0/docs/guid
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
shared vm 은 1.6에 가서야 완성된다는 소문이..
그러나 CDS 만으로도 어느정도 start up time 은 극복가능하지 않을까
생각합니다만..
J2SE 1.5 에서 지원되는데 몇가지 제약사항이 있습니다.아래 링크
J2SE 1.5 에서 지원되는데 몇가지 제약사항이 있습니다.
아래 링크를 참조하세요.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
Java shared classes
developerworks에 뜬 Java shared classes에 대한 최근 글입니다.
http://www-106.ibm.com/developerworks/java/library/j-shared/
IBM, Apple 그리고 Sun이 각기 다른 implementation을 자사의 OS를 위해 하는 것을 맛보기로 알려주는 군요.
----
I paint objects as I think them, not as I see them.
atie's minipage
언어라는게 목적에 맞으면 좋은 언어 아닌가요.?데몬을 시작하거나
언어라는게 목적에 맞으면 좋은 언어 아닌가요.?
데몬을 시작하거나 정지 시키는 부분까지도 전에는 C로 작성을 했었습니다.
지금 생각하면 조금 어리 석지 않았나 싶네요.
어쩌면 쉘 스크립트에 자신이 없었기 때문일지도...
윈도우 용 어플리케이션을 작성하면서 MFC안쓰는 분 있나요.?
아.. 공부 차원을 이야기 하는 것이 아님니다. 실무에서 말이죠.
'이 툴아니면 안되'라고 못이 박히지 않은 경우라면 자신의 손에 익은 걸 쓰면 되고, 자신 있는 툴이 여럿이라면, 생산성을 고려하는게 당연한 거 아닌가 생각합니다.
위에 어느 분이 쓰셨는데, 자바가 빠르면 얼마나 빠르고 느리면 얼마나 느릴까요.
제 생각에도, 자신의 플로우는 개선의 여지가 없고 오로지 언어의 성능만이 개선의 대상이 되신 분들이 얼마나 될지 궁금하군요.
Do you think that's the air you are breathing now?
흐음
네!
MFC싫어해서 안쓰는 프로들도 많고요, 대안도 많이 있습니다.
[quote="운형"]윈도우 용 어플리케이션을 작성하면서 MFC안쓰는
MFC 안써도 됩니다..
비쥬얼베이직을 사용해도 되고..
WinAPI를 사용해서.. 시작부터 노가다 해도 됩니다 -_-;;
또한
볼랜드 C++빌더를 사용해도 되고..
볼랜드 델파이를 사용해도 되며..
java swing 으로도 가능하며..
더해야 할까요..? 흐흐흐
cygwin.dll 을 이용하면.. gcc로도 가능하겠군요 :D
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
:wink: 이글 처음에 올라왔을때 이런 결과를 예상햇지만..오
:wink: 이글 처음에 올라왔을때 이런 결과를 예상햇지만..
오랜만에와서 보니 역시나군요.. 상당한 리플들 보는라 눈이다
빡빡합니다.. 그래도 내용만은 어느정도 걸러내면 참 유익하게 읽었습니다. :)
저도 자바 와 C++ 쓰지만 언어는 선택적 도구인것 같습니다..
여기가 무협세계였다면 저토론의 얘기는 검이 낫다 칼이 낫다 라고
하는것같았습니다 물론 몇몇글이 그랬고요 나머지글들은
유익했는데.. 앞글들의 여세를 타고 강하게 비판적글이 올라온것같습니다..
토론글로 가야할듯한 게시물이 되었군요 :)
자바, C++ 와 둘다 충분히 매력적이고 선택적으로 쓰고 나름대로
업무환경( 엄청다양 ) 또는 사정 또는 취향에 따라 쓰실텐데..
자바가 조금 빨랐다 라는 문구만으로 흥분할 필요는 없을것 같습니다..
'그냥 공동의 프로그래머로써 기뻐해야할 문제 아니었을까요?'
' 형식이 내용을 규정한다. '
Re: 흐음
흠... 그렇군요. 진정한 프로들은 안쓰는 분들도 있는가 보군요...
생산성에 대한 고려를 얼마나 할지 궁금하네요.
그리고 정태영님은... 윈도우 어플리케이션 꼭 win32 api와 cygwin 환경에서"만" 작성하시기 바랍니다.
생산성에 관한 글이 었는데, 반박을 위한 반박만 일삼는 군요.
Do you think that's the air you are breathing now?
[OT] Re: 흐음
제가 보기엔 운형님이야 말로 태클을 위한 태클을 일삼는 군요.
내가 MFC를 쓴다고 다 MFC를 쓸거라고 단정적으로 먼저 말씀하신 건 운형님이고...
MFC가 아닌 대안도 많이 있다는 두분의 댓글이었는데...
제삼자인 제가 봐도 기분 나쁜 비아냥거림이군요.
이쓰레드는 이 정도에서 정리해야 되지 않을런지...
더이상 주제에 집중이 안되는 거 같은데...
----
the smile has left your eyes...
Re: 흐음
이게 전형적인 인신공격성 글이죠.
이거만 없었다면 님 글도 이 스레드에 맞는 비판글이 되겠지요.
그리고 저두 mfc 별루입니다.
Written By the Black Knight of Destruction
번지수를 잘못 찾아오신 것일지도... 이 포럼 이름의 두번째 문자 L이
번지수를 잘못 찾아오신 것일지도... 이 포럼 이름의 두번째 문자 L이 무엇의 약자인지 아셨다면, 이곳의 대략적인 정서를 알 법도 한데... 물론 친 MFC 개발자가 전체 개발자 중에서는 더 많은 비율을 차지하겠지만, 모든 곳이 다 그러리라고 가정할 수는 없겠죠. 제가 쓰는 윈도 프로그램 중에도 MFC를 사용한 것은 몇 개 안되는 것 같네요. 모질라, xchat, gvim, gaim, 빵집 등 자주 쓰는 것들 대부분이 MFC가 아닌 것들.
----
http://nohmad.tumblr.com/
기냥 궁금.
근데, 혹시
빵집이 mady by 델파이 인가요? 궁금..
[quote="neosuper"]근데, 혹시빵집이 mady by
네.. 델파이라고 들었습니다.
아.. 델파이라고 하니 kmplayer도 추가해야겠군요.
----
http://nohmad.tumblr.com/
Re: 또 시작이다.
c 와 C++ 이야기
짜장면과 짬뽕.
남자와 여자
기타등등..
Re: 또 시작이다.
여러번 강조했지만 주제가 감정 싸움을 일으키는 것이 아니라 일부 성숙된 토론 자세가 부족한 사람들이 게시판을 어지럽히는 것입니다.
이번 주제도 정말 '아무런 성과 없이 감정싸움을 일으키는' 것으로 단정하기 전에 2 페이지에 걸친 논의 내용을 보시기 바랍니다. 최소한 VM이나 JIT의 동작 원리, 컴파일타임 최적화와 런타임 최적화의 차이 등 얼마든지 흥미롭게 이야기 할 수 있는 주제가 있었지 않았나요?
정치이야기나 종교이야기도 아니고 컴퓨터 관련 주제까지 이런 주제는 괜찮고 저런 주제는 안된다는 식이라면 아예 게시판에서 이야기하면 안되는 금지된 주제 목록이라도 정할 수밖에 없을 것 같습니다만...
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
Re: 또 시작이다.
맞습니다. 저에게는 많은 도움이 되었습니다. 쓰레드 닫지 말기를 바라는 마음에서... :oops:
----
블로그 / 위키 / 리눅스 스크린샷 갤러리
Re: 기냥 궁금.
주제와 전혀 상관 없는 생뚱맞은 질문을 드리는 점에 대해 먼저 진심으로 양해를 구합니다. 갑자기 너무 궁금해진 부분이 있습니다.
'프로그래밍 언어'에만 국한해서 이야기할 때, 어떤 구현물이 어떤 언어로 작성되었다는 것을 write 동사 대신 make 동사로 쓰려면 전치사로 by를 쓰는게 맞습니까? (정말 몰라서 묻는 것입니다.) 지금까지는 제대로 확인해보지도 않고 그냥 막연하게 'written in'으로만 쓰곤 했었는데, 막상 write 대신 make를 만나고 보니 'made in'은 역시 좀 이상하고 (왠지 in의 목적어로 지역이 나와야할 듯한 느낌) 'made out of'도 절대 아닐 것 같군요. 설마 with? with는 왠지 컴파일러를 목적어로 받는게 어울릴 듯한데요. 'made by'도 대략 맞을 것 같기는 하지만 뭔가 약간 익숙치 않은 느낌이 들어서 여쭙니다.
그리고 지금까지 습관적으로 막 쓰던 'written in'은… 설마 맞겠죠? 여기 저기서 여러 문서들을 통해 읽었던 표현 같은데 말입니다. 만약 아니라면, 지금까지 영어로 쓸 때마다 무식을 광고하고 다녔다는 얘기가……. :cry:
마지막으로 초 무식 질문: write 동사에 대해서 에디터의 전치사는 by입니까 with입니까? 'by pecil'이 막연히 입에 붙어있는 것으로 보아 필기도구는 분명히 by를 쓰는 것 같은데 말입니다. 'edit with vim'도 입에 붙어있긴 한데 'write with vim'은 뭔가 이상해요. 역시 by인가요? :roll:
--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!
Re: 기냥 궁금.
from 을 써야하지 않을까요? 소스와 컴파일된 소스는 성격이 전혀 다르니까요.
:)
Bbangzip is made using Delphi.by 는 붙
Bbangzip is made using Delphi.
by 는 붙이지 않는 것이 맞는것 같습니다.
왜냐하면 어색하거든요.
제 생각엔 프로그램에 made를 갖다 붙이는게 웬지 어색한 것 같고요,
제 생각엔 프로그램에 made를 갖다 붙이는게 웬지 어색한 것 같고요, 굳이 쓴다면 made with Delphi 또는 made using Delphi가 적당할 듯 합니다. 아무래도 프로그램은 written in, written with, created with나 created using으로 쓰는게...
write와 에디터에 대해서는, 제 경우는 시점에 따라 write on이나 wrote with로 쓰는데... 근거는 없습니다. 그냥 그렇게 쓰는 거죠. 물론, write with나 write using으로 쓸 때도 있고요.
----
I paint objects as I think them, not as I see them.
atie's minipage
단지 재미로....
단지 재미로 하는 토론은 좋습니다. 개인적으로 그 이상의 큰 의미는
찾기 어렵습니다.
자바와 C 중 어느 것이 빠른지가 그 얼마나 중요하겠습니까?
개발에 있어 자료구조와 알고리즘, 설계가 그 차이를 없애고도 남습니다.
무엇보다 하려는 일과 자신에게 맞는 언어가 어떤 것인지를 발견하는 것이
중요하다고 생각합니다.
--
Minimalist Programmer
Re: 단지 재미로....
이런 코멘트야말로 토론의 질을 떨어뜨리고 토론에서 김을 빠지게 합니다. 토론이 주제에 따라 열전을 벌일 수도 있지만, 참여자들이 충분히 주의를 하면 감정 싸움과 자존심 싸움 없이 새로운 정보를 공유하면서 발전적인 토론을 해나갈 수 있습니다. 그런 면에서 저는 이번 토론이 그렇게 나빴다고 생각지 않습니다. 님께서는 다 아는 얘기라 별 의미가 없었다고 말씀하실지 모르겠지만 다른 분들께는 좋은 정보 소스가 되었을 수도 있습니다.
님의 말씀대로 언어 자체의 성능보다는 자료구조, 알고리즘이 더 중요할 수 있습니다. 그리고 자신의 작업에 적합한 언어를 선택하는 것이 무엇보다 중요하겠지요. 그러면 어떤 정보를 가지고 그 적합한 언어를 선택할까요? Java와 C/C++ 혹은 .NET의 비교가 매번 열전을 불러 일으키는 이유는 그 둘이 서로 라이벌 관계에 있기 때문이죠. 님께서는 혹 위의 토론이 경쟁 관계에 있는 도구 중 하나를 선택하는데 나름 유용한 정보를 제공하고 있다고는 생각지 않으시는지요?
끝으로 토론다운 토론을 원하신다면(그렇기 때문에 위의 포스트를 올리신 거겠지요?) 토론에 대해 토론할 것이 아니라 주제에 대해 토론하셨으면 합니다. 적어도 제가 토론에서 읽고 싶은 것은 주제에 맞는 새로운 정보나 아이디어이지 토론에 대한 도덕적이고 교과서적인 총평이 아닙니다. (어떤 언어가 더 우수하냐가 중요한 것이 아니라 어떤 언어가 나의 작업에 더 적합하느냐가 더 중요하다는 사실을 모르는 사람 있습니까? 이런 말로 100 페이지를 도배한들, 그러한 토론에서 유용한 정보를 얻을 수 있는 사람은 없을 것입니다.)
앞에 많은 얘기 잘 보았습니다. GUI application의 perfo
앞에 많은 얘기 잘 보았습니다. GUI application의 performance에 몇 몇 궁금증이 생겨서 글을 써봅니다.
저도 거의 Java로 구현하지만, GUI application들은 아직 쫌 심하게 느리다는 생각이 들더군요. Eclipse는 상당히 빠른 느낌을 주긴 하지만 말이죠. (SWT가 native로 되어 있다고 앞에서 어떤 분이 언급하신 것 같은데 한번 porting해봐야 겠군요. 전 아직 Swing을 써서^^)
근데 궁금한 것은 MS Windows에서 MFC같은 것 썼을때 graphic card의 하드웨어 가속 지원을 받는 건가요? 요즘 카드들은 2D 가속들은 기본적으로 되는 것 같던데 말이죠. 그렇다면, Java GUI같은 경우 Java 3D나 기타 등등 graphic관련된 것들은 하드웨어 지원을 받지 못하는 이상 윈도우 프로그램의 성능은 보이기 힘들텐데 말이죠. Java awt도 어디에선 가는 native code가 있을테니 걱정할 필요가 없는것 같기도 하고. Java3D는 확실히 지원의 문제가 걸리긴 할 것 같고 graphic card들이 Java code에도 영향을 미치는 지 모르겠군요.
그리고, GUI 제외한 performance에 대한 의견도 보았는데 runtime optimization쪽의 이점을 빼고라도, 미래를 생각해 보면 static optimization도 Java쪽이 더 발전할 가망성이 많아 보입니다. 우선 최적화를 위한 프로그램 분석 및 적용이 상대적으로 Java쪽이 훨씬 쉬울 것 같아 보이기 때문입니다.
쫌 심하게 쓰면 이후에 동시에 적용할 수 있는 분석 기술이 개발되어도 아마 c/c++의 엄!청!나!게! 다양한 모든 형태를 고려하면서 지원하기는 쉽지 않아 보입니다. (pointer arithmetic만 있어도 쓸수 없는 방법들이 수도 없을 것이기 때문에 말이죠.)
또한, 순전히 감입니다만 thread관련 constructor들이 원래 존재하는 java언어가 성능 개선의 여지가 훨씬 많아 보입니다. 아무래도 C/C++는 thread가native constructor가 아니기 때문에 아무리 표준화된 library를 쓴다고 해도 분석을 통한 성능향상에는 한계가 있어 보입니다.
말하다 보니 그냥 Java 성능 개선의 미래가 더 밝아 보인다 정도로 정리되겠군요.
계속 꿈꾸던 건데, JVM같은 역할을 해주는 addon card가 나왔으면 좋겠습니다. 있는지 모르겠지만.. graphic card랑도 TV card처럼 바로 interaction하고, 하드웨어로 조금만 받쳐주면 날라다닐것 같은데 말이죠 :-)
참. C# 써서 .net framework에서 GUI 돌려보면 별루 느린지 모르겠던데. 쩝.. 이게 SWT와 같이 native code형태로 구현된거겠죠? 그리고, SWT가 swing과 달리 awt기반으로 구현된 것이 아니라면 awt와 연동하는데 별로 어려움이 없나요??
[quote="recypace"]그리고, GUI 제외한 perform
GUI에 대한 답변은 아니고요,
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-D
여기의 마지막 result에 보면 Excelsior JET로 컴파일해서 벤치마크한 비교가 나오는데 현재로서는 JIT와 우열을 가리기는 어려울 것 같습니다. 다음은 Excelsior homepage에서 따온 글입니다.
What is Excelsior JET?
Excelsior JET is a comprehensive solution for Java client- and server-side application performance, scalability, and code protection. It transforms your Java code into a conventional Windows executable (EXE, DLL, or NT Service) that runs directly on hardware, as if it was written in C++, FORTRAN, or COBOL. This feature is called Ahead-Of-Time (AOT) compilation, as opposed to Just-In-Time (JIT) compilation implemented in most contemporary J2SE VMs.
Excelsior JET, Professional Edition comes with a Caching JIT compiler, aimed at handling dynamically loaded classes, so it is fully compatible with Java 2.
AOT compilation occurs on a developer's system and thus may employ resource-consuming optimizations, resulting in better code. It also eliminates or minimizes the overheads associated with dynamic compilation during execution of your application.
----
I paint objects as I think them, not as I see them.
atie's minipage
[quote="recypace"]계속 꿈꾸던 건데, JVM같은 역할을
글쎄요... 그렇게 Hardware로 받쳐주는 식으로 발전을 해도 좋겠지만, 역시 Java의 로망은 Software VM 기술 아니겠습니까??? Software VM의 성능이 많이 발전해야 만이 'Write Once, Run Anywhere'의 목표에 좀 더 가까이 가는 것이라고 생각합니다... Hardware 지원으로 속도가 빨라진다면, 그 Hardware를 지원하지 못하는 다른 Platform에서는 느리지 않겠습니까??? 그렇다면, 진정한 Java의 모습은 아니겠죠...
물론, Hardware의 지원은 몇몇 Major Platform에서는 매우 중요하겠죠... 하지만 그것도 'Hardware에서의 Java지원'이라는 형태가 아니라 'VM에서 그 Hardware를 이용'하는 형태라야 겠지요... 그런 식으로 발전해야 진정한 Java라고 할 수 있을 거 같습니다...
그리고 .NET에서 사용하는 CLR은 Java의 VM과는 조금 다르다고 들었습니다...
Java의 경우 ByteCode를 매번 Interpret하지만, .NET의 경우 일단, 한번 Interpret하여 Native로 만들어지면, 다음 실행부터는 Interpret단계없이 바로 Native 실행이 되는 것으로 알고 있습니다...
즉, .NET은 첫번째 실행이후에는 Native Application과 같다고 하더군요...
뭐... 100% 확실하다고는 말씀드릴 수 없겠습니다... 저도 예전에 .NET을 잠깐보면서 알게된 내용이라서요... 요즘 .NET도 그런 지는 모르겠습니다...
[quote="sDH8988L"]그리고 .NET에서 사용하는 CLR은 J
바로 위의 답글들을 읽어보시기 바랍니다. 자바던 .NET이건 JIT를 사용해서 실행 중 네이티브로 컴파일 한 이후는 바이트 코드를 인터프리트 하지 않고 컴파일 된 네이티브 코드를 실행합니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote=recypace]근데 궁금한 것은 MS Windows에서 M
하드웨어 가속을 지원 받는 것은 GDI 관련 API 함수들이 하드웨어 가속을 받을 수 있을 듯 하구요. 정확히는 찾아 봐야 알겠네여 ^^;
MFC는 하드웨어 가속과는 전혀 관련이 없는 걸로 알고 있습니다.
그리고, 자바의 VM 얘기는 참 재미있네요. 그럼 실행 시간에 바이트 코드를 최적화 시켜준다면 실행 횟수가 많아 질수록 바이트 코드가 더욱 최적화 되는 건가요?
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
[quote="fender"][quote="sDH8988L"]그리고 .N
글쎄요... 제가 이해하고 있는 것과는 좀 다른 이야기인 거 같습니다...
물론, JIT이후에는 당연히 Interpret가 아니고 Compile된 Code를 이용하겠죠...
제가 이야기 하는 것은 실행 도중이 아닙니다...
한 번 프로그램을 실행했다가 완전 종료가 된 후에 다음에 또 실행할 때는 아주 Native로 시작한다는 거죠... JIT가 개입되는 것이 아니구요...
그래서 한 번 Interpret 된 후에는 다음 실행에서는 Native라는 말을 쓴 겁니다...
Java도 물론, 실행 중에 JIT가 돌고 그로 인해 동일 실행 중에 그 Code를 다시 수행한다면, JIT로 Compile된 Code가 돌겠죠... 그렇지만, 프로그램이 완전 종료되어 메모리에서 사라진 후 다시 실행될 때는 어떻습니까??? 다시 JIT가 돌지 않습니까???
제가 잘못알고 있는 건가요???
흠... 저도 다시 한 번 찾아봐야 겠네요...
뭐 어짜피 각 로직이나 함수에 따라 속도에 장단이 있지 않을지..
뭐 어짜피 각 로직이나 함수에 따라 속도에 장단이 있지 않을지..
노가다라 할지라도 남들보다 빨리 끝낼 수 있으면 어셈 최적화가 더 좋을 때도 있는거죠..ㅡ_ㅡ;; 실제 세계에선 그럴 가능성은 물론 거의 없겠지만,,,,
그나저나, Bbangzip is developed with Delphi 가 가장 보편적으로 쓰입니다.
developed by 는 아닌 것이, Delphi 가 만든게 아니라 Delphi 로 만든 거니까.. developed by me 하면 맞겠죠.
made 는 흠... 사실 "뭔가를 만든다" 고 할 때는 make 를 안 씁니다. 뭘 되도록 만들다~ 고 할 때에 주로 쓰이죠. 햄버거 집에서 Errrr.... make it two~! 라고 할 때 아니면, I made it~!!!!! 이라고 할 때 또는, make it right turn 이라고 할 때에 주로 쓰입니다.
L-System
:D Java 가 C++ 봐 빠를수는 없습니다. 자바 특성상 b
:D
Java 가 C++ 봐 빠를수는 없습니다. 자바 특성상 byte code 로 되어 있어 VM 이없다면 실행이 안되죠.. VM 역시 가상의 CPU program 이구요 byte Code 를 실행 시켜주는..
그런데 빠르게 하고 싶다면, Byte code Accelerator 를 하드웨어 적으로 만들어 주면 됩니다. 이때 Hardware 는 많이 커지겠죠..
그 예을 들어보면...
Smart card Application 에서는 Java 가 많은 역활을 하고 있습니다. 스마트 카드 특성상.. 많은 제품들이 있고, 여기에 들어가는 COS(card operating system)를 사용 용도에 따라 바꿔 줘야 하는데 이때 Smart card내에 들어 있는 MCU 가 다르게 됩니다. 이때 소스를 다시 MCU 에 맞게 포팅하는게 아니라. VM 만 포팅 되어 있으면, 어떤 COS 라도 올릴 수 있습니다.
Smart card 특성상 빠른 처리가 필요치 않기 때문에 소프트웨어로 VM 를 만들어 사용하기도 하지만, 요즘 추세는 Java Byte code Accelerator를 하드웨어 적으로 설계하여 지원하기도 합니다.
저에게 Java 의 장점은 프로그램의 편리성보다도 Java 로 만든 프로그램은 CPU 를 가리지 않고..(당연히 VM 은 CPU 를 가리겠지만,) 어떤 CPU 에서든 사용할수 있는것입니다.
한가지 장점이 있다면 다른 하나의 단점이 있겠죠...~~
회사에서 시뮬레이션 돌리다 너무 늦게 돌아서 몇자 적었습니다.~~
참고로 저는 HDL 를 사용하는데 무지 느려요~~~ ^^;;
System C 사용하면 좋아 질려나..? 혹시 System C 사용하시는 분 있으시면 사용하시는 이야기 좀 해주세여~~~
[quote="errorfree"]:D Java 가 C++ 봐 빠를
이미 앞에서 Java의 특성에 관한 이야기가 많이 다루어져 있습니다...
그 글들을 읽어보면, 'VM을 이용한 Java가 꼭 C++보다 항상 느릴 수 밖에 없다'라고는 말 할 수 없다는 것을 알 수 있습니다...
Language의 Design에 따라 어느 정도의 Optimization이 가능한가가 달라지기 때문이죠...
Java와 C++은 그런 Language의 Optimization 부분에서 많이 다릅니다...
그렇기 때문에 Java가 항상 C++보다 느리다는 말은 할 수 없는 거죠...
참고로 C++은 그 복잡성으로 인해서 아직 '완벽하게 동작하는' Parser 조차 없습니다...
다들 아시는 사실이겠지만, GCC 최신 버전에서는 C++ Parser가 예전의 자동화된 부분을 전부 Hand made 부분으로 바꾸었죠... Language의 Parser마저 손으로 Coding합니다... 그만큼 Optimization이 쉽지 않다는 거죠...
'Java에서 할 수 있는 Optimization은 무조건 C++에서도 가능하다.' 이건 사실이 아니죠...
[quote="sDH8988L"][quote="fender"][quote
알고 계신게 거의 맞습니다. 프로그램 구동때가 아니라 프로그램 설치시에 native code를 GAC에 설치할수 있습니다. (WinForm 계열들은 거의 기본으로 하라고 권장되어 있지요.) 참 재미있습니다. (마치 python의 컴파일 옵션입니다.)
MS에서도 이 기능을 client application으로 국한하고 있습니다. ASP.NET의 경우 작동 불가능한 기능이라고 명시하고 있네요.(불필요 하겠지요. Java같이) 더불어, Java 와 달리 JIT단위가 class가 아니라 Function이라서, 필요 함수 단위 컴파일 되어 시작시간(start-up time)을 아주 조금이나마 한 몫합니다.
장점 측면에서 보면, 아직 시작 시간외에 얻는 큰 이점은 없다고 밝히고 있습니다. 아마, native가 되어도 .NET vm의 구동은 있어야 하는 것 같은데, 구체적인 것은 잘 모르겠네요.
Java의 돈을 버는 주무대가 Server인 것을 감안한다면, vm 캐싱의 근본을 바꾸어야 하는 요구사항 이라 도입 안하는것 같습니다. 그러나 Java 1.5의 메이저 업그레이드를 관찰하면서, DeskTop을 표방한다면 왜 이 개념을 적극 도입안하는지 이해가 가지 않습니다. 그리고 J2EE가 아닌 J2ME라면, 굉장히 유용한 기능일텐데요. (모바일의 성능상 문제로 WIPI가 ATOC를 하고 있죠.)
ps.
오랫만의 학교에 가봤는데, PC들이 대부분 3 Ghz 단위로 업그레이드 되어 있더군요. 메모장 처럼 뜨는 VisualStudio .NET에 일반 어플리케이션 처럼 뜨는 Eclipse라.. 격세 지감입니다.
ref
Java And .NET
Performance Optimization in Visual Basic .NET의 Other Optimization
Native Image Generator (Ngen.exe)
dynamic optimization 역시 공짜는 아니지 않습니까? 진정
dynamic optimization 역시 공짜는 아니지 않습니까? 진정한 성능 비교를 하고 싶다면, 역효과가 날 수 있는 부분과 C++에 비해 성능이 크게 낮아지는 부분과 JVM이 사용하는 메모리도 고려해야겠지요. 메모리 부족해서 page swap 한번 더 일어나면...-_-
대부분의 어플리케이션은 성능에 그다지 연연하지 않지만(하드웨어 발전 속도가 성능 요구 속도를 앞지른 것도 한몫하고), 정작 리얼타임의 특성을 띠는 분야에서는 자바의 침투도가 그다지 높지 않다는 점에서 성능에 관한 전반적인 결론은 내려졌다고 봐야 하지 않습니까?
Java보다 C++이 Real-time에 주로 쓰이는건Performa
Java보다 C++이 Real-time에 주로 쓰이는건
Performance가 높아서라기보다는
Deterministic하기 때문이라고 봐야죠.
Java는 Garbage Collecting 때문에
Non-deterministic한 면이 좀더 있다고 봐야 하니까요.
( Garbage Collecting 때문에 Deadline을 못지킬수도 있으니. )
그리고 Real-time에서 실제 이슈들도 사실
Performance보다는 Scheduling이죠.
빠른게 다가 아닙니다.
최근 프로젝트중 front-end가 비주얼 베이식6.0으로 진행되고 있는
최근 프로젝트중 front-end가 비주얼 베이식6.0으로 진행되고 있는데,
비주얼 베이식으로 코딩하면서,
요즘 함수내 분기할 시점을 판단할 때,
스택으로 인한 오버해드가 어떨까 이 변수는 전역이 나을까
파포인터로 읽는 것이 부하가 될까
2~3회 참조하니깐 로컬로 카피해서 읽으면 더 빠를까...
고민하는 내모습을 종종 볼때 마다 우습더라구요.
전~혀 포퍼먼스하고는 담쌓은 프로젝트인데도 말이죠...
요즘 비주얼 베이식을 보고 있으면,
다같은 변수인데, 어떤 것은 포인터이고 어떤 것은 실제 변수인지
알겠더군요..
그리고 연산자들도 오버라이딩(?)되는 것도 보이구요...
우연히 오랜 만에 이글을 읽게 되서,
요즘의 저의 행태가 우습다는 생각도 해보았습니다.
There is no spoon. Neo from the Matrix 1999.
글쎄요 이주제는 좀 이렇게 바뀌어야 의미가 정확 한게 아닌가 생각하네요.
글쎄요 이주제는 좀 이렇게 바뀌어야 의미가 정확 한게 아닌가 생각하네요.
"JAVA가 C++ 보다 빠르다"
->
"(실시간 최적화가 되는) 새로운 실행 플랫폼이 기존 실행 플랫폼보다 빠르다"
새로운 실행 플랫폼이라는게 JVM, .NET 이런걸 테고요.
無心