네이티브 코드의 최후?
글쓴이: iolo / 작성시간: 금, 2006/06/16 - 11:15오전
http://ask.slashdot.org/askslashdot/06/06/12/2044245.shtml
요즘에는 보통 PC들도 가상머신이나 just-in-time컴파일러를 통해 실행되는 인터프리터 언어들로 만든 복잡한 소프트웨어를 실행하기에 충분한 성능을 갖고 있죠. 윈도 개발자의 입장에서, MS가 발표한 윈도 비스타의 시스템 요구사항은 미래의 윈도 박스가 현재의 인터프리터/JIT 방식 언어(예: .NET, 자바, 파이썬 등등)의 메모리/프로세서 요구사항을 비웃는 것처럼 보이네요.
네이티브 코드와 비교해도 성능 상의 별 차이가 없지만, 인터프리터 언어가 더 포팅하기 쉽고, 종종 개발 시간을 줄여주고, 네이티브 코드를 만드는 언어만큼 강력함에도 불구하고, 주요 소프트웨어 개발팀과 많은 오픈 소스 개발자들은 주요 프로젝트에서 네이티브 코드를 선호하는 것 같습니다.
KLDP를 찾는 분들은 인터프리터/JIT 언어의 현재 상태에 대해서 어떤 생각을 갖고 계신가요? 인터프리터/JIT 언어의 배로 옮겨타야할 시점일까요? 인터프리터 언어를 쓰면 시스템에 대한 - 아마도 저수준의 - 제어권을 잃어버리게 될까요?
흰 머리 늘어나는 것 말고 뭘 더 잃게 될까요?
PS. 슬닷에서 퍼서 각색을 좀 했습니다 :S
댓글
어차피
어차피 인터프리터/JIT 언어가 사용되는 분야와 네이티브 코드가 사용되는 분야가 서로 다를 것 같은데... 인터프리터/JIT로 갈아탈지 네이티브를 고집할지 고민해야 할 분야는 구체적으로 어떤 것이 있을까요?
저는 자바로 주로
저는 자바로 주로 개발하는데 멀티플랫폼을 지원하는 GUI는 아직 문제가 많은듯 합니다.
속도, 기능, 호환성 등이 네이티브로 개발한 것에 비해 많이 부족합니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
환경을 알고 싶네요.
저는 JDK 1.5, Windows XP, CPU 2.4 GHz 환경에서 쓰고 있는데 Swing이 느리다는 느낌을 받지 못했습니다.
CPU가 1.0GHz 이하일때는 느리다고 생각했지만요.
Swing이 Windows에만 최적화 된건가요? (Windows 사용자가 많긴 하니까 먼저 지원하기는 하겠지만..)
제가 쓰는 컴터들이
제가 쓰는 컴터들이 다 보급형 수준의 환경이라 그런거 같습니다.
집에는 펜3 866, 회사는 바통2500 이거든요.
게다가 제가 스윙보다는 awt를 많이 경험했구요.
속도가 느린 이유도 CPU보다는 표준 컴포넌트들의 네이티브 피어 설계나 자바의 컴포넌트 구조가 더 느리게 한다는 생각이 많이 듭니다.
물론 결정적으로 GUI어플리케이션의 코드를 얼마나 빨라보이게 작성하느냐도 한몫 하겠죠.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
대부분의
대부분의 어플리케이션과 툴 수준의 유틸리티 아닐까요?
----------------------------
May the F/OSS be with you..
그 인터프리터/JIT를
그 인터프리터/JIT를 구현하는 일이겠죠~.~
C컴파일러/런타임을 C로 만드는 것처럼... 자바 컴파일러/런타임을 자바로 만드는 것도 더이상 특별한 일에 끼지도 못하죠~
헤헤~ 농담이구요~
"이 일은 무조건 네이티브로 해야 해!"라고 할만한 근거가 점점 없어지고 있다고 생각됩니다.
본문에도 나와 있는 것처럼.. 그럼에도 불구하고 네이티브가 많이 쓰이고 있는 것은 일종의 관성에 의한 것이 아닐까요?
바꿔말하면, "이건 무조건 네이티브로 해야 해!"라고 할만한 근거도 없지만,
"이제 VM으로 바꿔야 해!"라고 할만한 근거도 없다는 거죠. 생산성이 좋고 나쁘고는 어느 정도 주관적인 측면이 있어서 결정적인 근거가 되기는 힘들 거 같구요...
----
the smile has left your eyes...
----
the smile has left your eyes...
인터프리터/JIT
인터프리터/JIT 언어라기 보다는, 그러한 기술이 적용된 언어라는 관점에서,
그게 대세면, C 내지 C++ 도 그 기술이 적용된 바이트 코드 생성기를 만들면 된다고 봅니다.
Orion Project : http://orionids.org
http://www.harbaum.org/till/n
http://www.harbaum.org/till/nanovm/
nanovm이라는 자바(?라고 하긴 뭣하지만)vm입니다.
"절대" 네이티브의 영역이라고 생각했던 8bit risc cpu(-.-)용 프로그램을 자바로 짤려고 하는 이유가 뭘까요?
저도 잘 모르겠어요=3=3=333
----
the smile has left your eyes...
----
the smile has left your eyes...
엔터프라이즈 서버
엔터프라이즈 서버 쪽은 이미 자바 .NET 등 인터프리터/JIT 기반 언어가 대세인듯 하구요.
데스크탑 어플리케이션은 아직 네이티브 코드를 생성하는 언어가 대세지만 많은 인터프리터/JIT 기반 언어들이 충분한 가능성을 보여주고 있다고 생각합니다.
윈도의 경우 앞으로 .NET 데스크탑 어플리케이션 영역 역시 커버하게 될테니 더욱 그렇구요. 리눅스에서는 요새 심심치 않게 python 으로 GUI 를 만든 프로그램들도 찾아볼 수 있지 않나요?
데스크탑 어플리케이션에서 자바는 현재 좀 문제가 있습니다. 첫번째는 너무 큰 런타임환경, 두번째는 VM startup 시간이 너무 길다는 것. 일반 사용자들에게 JRE 가 깔려있냐 없냐, 깔려 있으면 버젼은 뭐냐를 판단하게 할 수는 없으니 속편한 방법은 JRE 를 같이 배포하는 것인데... 네트워크 대역폭이 넓어지고, 하드 디스크 용량이 100G 를 넘어가는 요새는 60M 짜리 런타임이 큰 무리가 아니라는 입장도 있지만, 런타임을 제외하면 1~2 M 면 충분한 프로그램에 60M 런타임은 좀 부담스럽습니다. 그리고 VM startup 시간은 앞으로 좀 더 좋아지겠지만 splash screen 을 바라보면서 프로그램이 뜨기 기다리는 것은 갑갑한 일입니다. Look&Feel 은 스윙의 경우 문제가 있지만 SWT 는 괜찮은 것 같구요.
임베디드 쪽은 잘 모르지만 J2ME 가 아직 가능성은 있다고 봅니다. .NET 의 임베디드 지원에 대해서는 전혀 모르겠군요. 임베디드 쪽이 갈아탈지 말지를 고민해야할 분야가 아닐까요?
하드웨어를 직접 다룰 필요가 있는 OS, driver 등의 분야, 실시간 응답이 필요한 분야에는 아직 인터프리터/JIT 기반 언어가 전혀 침입하지 못하고 있는 것 같구요.
뭐 현재 상황은 이렇게 봅니다만, 저는 현재 인터프리터/JIT 기반 언어의 장점으로 꼽히는 이기종간(프로세서, OS) 바이너리 호환성과 언어간 라이브러리 호환성, 런타임/다이나믹 최적화 기술이 인터프리터/JIT 기반에서만 가능한 것들이 아니라고 봅니다.
런타임/다이나믹 최적화 기술은 현재는 인터프리터/JIT 언어기반으로 많이 발전해 있지만... 이건 네이티브 코드를 생성하는 언어에서도 가능하지 않은가요? 현재 네이티브 코드를 생성하는 주류 언어들이 컴파일타임/스태틱 최적화에 초점을 맞추고 있어서 그렇지 불가능한 것이 아니니까요.
그리고 잘 설계된 언어들은 이기종간 바이너리 호환성은 없어도 소스 코드 호환성은 있습니다. 네이티브 코드/바이트 코드를 모두 지원하는 언어도 있지요. 물론 컴파일러가 여러 플래폼을 지원해야하는 문제가 있지만 이는 어차피 플랫폼별로 인터프리터/JIT 를 따로 작성해야하는 것과 마찬가지이므로 약점이 아니라고 봅니다.
언어간 라이브러리 호환성 역시 네이티브 코드에서도 프로토콜만 잘 정의되면 별 문제 없다고 생각합니다. 어느 세월에 누가 프로토콜 표준을 정하고 또 각 언어들이 그걸 지원하느냐고 물으시면 할 말 없기는 합니다만...^^; 현재 언어간 라이브러리 공유가 wrapping 같은 삽질을 통해서 이루어지지만 (swig 같은 거의 자동화된 wrapping 툴도 존재합니다.) 아주 최소한의 노력으로 표준화된 프로토콜을 사용해서 가능하게 될 날을 기대합니다..
물론 VM 같은 표준화된 플랫폼이 이런 작업들을 훨씬 쉽게 한다는 것에는 동의합니다. 하지만 속도/저수준 하드웨어 제어같이 VM 을 도입함으로써 잃게 되는 것들이 분명히 존재합니다. 하드웨어가 발전할수록 속도 문제가 없을거라는 이야기는 옳지 않다고 봅니다. 하드웨서 속도가 높아지면 그걸 잡아먹는 새로운 기능이 등장하기 마련이므로 속도는 언제나 문제가 됩니다.
따라서 네이티브 코드 세상에서 점차 위에 언급한 기술들이 발전해서 언젠가는 (한 10년 ? 너무 먼 일인가...) 현재의 인터프리터/JIT 유행이 다시 다시 네이티브 코드로 전환되지 않을까 생각합니다.
그리고 개발자 입장에서는 인터프리터/JIT 기반인가 네이티브 코드 기반인가는 별도 중요하지 않다고 생각합니다. 보다 논리적/추상적인 개념인 "언어" 문제이지요. 새로운 언어/새로운 방법들을(그게 좋아서든, 밥 벌어먹고 살기 위해서든) 공부하고 만들어가느냐 그냥 하던거 하느냐하는 문제인거지요.
Quote: Look&Feel 은
넷빈즈에서 제공하는 라이브러리를 사용하여 스윙으로 네이티브 룩앤필을 보여줄 수 있습니다 ^^;
Windows XP, Mac OS X 에서 확실히 테스트해봤습니다.
http://blog.superwtk.com/
JRE 버전
System Properties를 통해 버전을 알 수 있습니다.
System.getProperty("java.specification.version");
System.getProperty("java.specification.vendor");
System.getProperty("java.specification.name");
System.getProperty("java.version");
System.getProperty("java.vendor");
System.getProperty("java.vendor.url");
System.getProperty("java.vm.specification.version");
System.getProperty"java.vm.specification.vendor");
System.getProperty("java.vm.specification.name");
System.getProperty("java.vm.version");
System.getProperty("java.vm.vendor");
System.getProperty("java.vm.name");
제 컴퓨터 JRE의 사양은 다음과 같습니다.
java.specification.version: 1.5
java.specification.vendor: Sun Microsystems Inc.
java.specification.name: Java Platform API Specification
java.version: 1.5.0_06
java.vendor: Sun Microsystems Inc.
java.vendor.url: http://java.sun.com/
java.vm.specification.version: 1.0
java.vm.specification.vendor: Sun Microsystems Inc.
java.vm.specification.name: Java Virtual Machine Specification
java.vm.version: 1.5.0_06-b05
java.vm.vendor: Sun Microsystems Inc.
java.vm.name: Java HotSpot(TM) Client VM
그리고 rt.jar를 필요한것만 추려낼 수 있다면 상당히 용량을 줄일 수 있을것이라 생각됩니다. 이런 사례도 있지 않을까 합니다. 그래도 한계는 있겠지요.
인터프리터 언어들이
인터프리터 언어들이 바이트 코드 외에 네이티브 코드도 뽑아내주면 참 좋을것 같은데 말이죠..
아니면 C/C++의 전처리기 역할까지만 충실히 해주는 인터프리터 언어가 있으면 좋을것 같습니다.
저수준 제어, 성능 극대화 등을 그 이후에 할 수 있게끔 말이죠..
말해놓고 보니 ㅂㅌ같은 생각입니다;;;;;
펄 6의 패럿이
펄 6의 패럿이 지향하는 바가 바로 그것인것 같습니다만~ :-)
문제는 프로그래머가 익숙한걸 쓴다는게 문제겠죠...
오픈소스 프로그래머라고 정한 영역이 있는것도 아니고
상용 프로그램을 개발하는 프로그래머가 오픈소스로 소스를 공개할수도
있는데 문제는 그걸 과연 포팅해서 내놓을까요..?
소스를 공개하는 선도 상당한 노력이나 포기하는 부분이 많을것인데
너무 많은걸 바라는거 아닌지 모르겠습니다.
툴이 더 나와봐야 알 상황인지도 모르겠습니다.
Windows는 쉘도 VM기반으로
MS에서 monad라는 프로젝트명으로 개발하던
perl과 unix쉘을 짬뽕으로 섞어놓은듯한 문법의
새로운 명령행 shell의 RC버젼을 Powershell 이란
이름으로 내놓았습니다.
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
http://blogs.msdn.com/PowerShell/
이것이 돌아갈려면 .NET 2.0 버젼이 깔려야 됩니다.
cmdlet이라는 개념으로 운영체제의 핵심부분을 object로
shell 상에 불러들여 처리합니다.
이런걸 보면 MS는 운영체제 차기버젼 Vista부터 운영체제의 핵심부분까지
모두 VM기반으로 옮겨가려고 하는듯 보입니다.
네이티브코드의 최후라고 하기는 그렇고 앞으로 VM기반의 컴퓨팅이
더욱 확대될것 같습니다.
저는 윈도우의 쉘을
저는 윈도우의 쉘을 적극적으로 이용하는 유저를 본 경우가 매우 적었습니다. MS의 의도와는 달리 Powershell 자체는 성공할 수 있을지 모르겠네요.
- CN의 낙서장 / HanIRC:#CN
- 죠커's blog / HanIRC:#CN
윈도 커맨드..
전 윈도 쓸때엔 윈도 커맨드라인에서만 작업하려고 노력합니다.
Cygwin 쓰면 유닉스 셸과 비스해서 편한맛도 있지만,
Cygwin 자체를 작업하는 컴퓨터마다 설치하는것도 큰 일이구요,
path 문제가 자꾸 걸려서 안쓰기로 했습니다..
nmake 쓸땐 호환성 문제가 일어나곤 하는데, java로 작업할땐 ant를 쓰면 되므로 큰 일은 아닙니다.
(java 쓰려면 jdk는 어차피 설치해야 하고요, ant 는 그리 크지 않으므로 큰 문제는 아닙니다)
아무래도 예전 dos 에서 작업하던 버릇이 아직도 많이 남아있나 봅니다.
간단한 C/C++ 코드 테스트할때도 그냥 VC 커맨드라인인 CL을 씁니다.
MS 컴파일러가 생각보다 C++ 표준에도 잘 부합하거든요. ^^
MS의 정책이나 독점화는 싫지만 윈도에서 작업할땐 편한점도 많은게 사실입니다.
무엇보다 커맨드라인에서 작업하다보면 은근히 속도가 빠른것이 느껴집니다.
근데 VM 이야기로 넘어가서..
느려지는건 싫지만, interoperability 라는 엄청난 잇점을 생각하면 바람직한것 같아요.
하지만, 멀티미디어 관련된 부분은 아무래도 힘들지 않을까 싶어요.
누군가 그러던데 멀티미디어가 무지 많은 양의 작업을 무지 빠른 하드웨어로 커버해야 하는거니까요.
하드웨어 사양이 높아질수록 그에 따라 최종 사용자의 취향도 고급화되기 마련이고,
그만큼 더 고사양의 하드웨어를 요구하는 알고리즘들이 나올텐데요.
이런 부분들은 VM으로 하긴 어렵지 않을까요?
MS가 한편으로 DirectX를 유지관리하는데, 이런 것을 VM으로 만들긴 어렵지 않나 해요.
가상머신이나
가상머신이나 just-in-time 컴파일러들이 코어 라이브러리는 네이티브 코드로 만들었라도 속도는 분명 느립니다. 하지만 멀티플랫폼이 큰 이점을 가집니다.
그럼에도 확대가 안되는 것은 .net이라고 해봤자 윈도우즈에서만 쓰고, java는 그나마 양쪽에서 잘쓰고 있으나 아무래도 윈도우서 많이 쓰이는 것으로 보입니다. 리눅스에서 많이 쓰는 파이선 역시도 윈도우쪽에서는 많이 쓰이지 않는 것이 문제 같습니다.
저는 자바VM 처럼 Python+GTK2+PyGTK2+qt+PyQt+PyXML 등으로 해서 한번에 깔리는 PyVM 패키지 윈도우버전 좀 나와줬으면 합니다. 그러면 학생 실습용부터 개발에 까지도 많이 쓰일거 같습니다.
정품 소프트웨어 사용 캠패인
정품 소프트웨어 사용 캠패인
좋은 생각입니다.
좋은 생각입니다. PyVM!!
----------------------------
May the F/OSS be with you..
parrot
PyVM이라... parrot 이 비슷한 플랫폼이 되지 않을까 싶네요.
Perl6가 주가 될 것이고 여기서 지원될 다른 언어란 ruby, python등이 포함된다고 하는군요.
언어의 선택은
언어의 선택은 프로젝트 상황에 따라 달라지지 않을까요?
그렇게 쓰는 것이 현명한 방법 같습니다.
CN은 바이트코드에
CN은 바이트코드에 대해서도 부정적입니다. WHATWG와 기타 단체들은 웹 브라우져가 기존 플랫폼을 대신할 만큼 기능적으로 향상 시킬 것입니다. 그렇게 된다면 바이트 코드의 중요성 역시 떨어지게 될 것입니다.
게다가 새로운 기술이 아니더라도 시장은 바뀌고 있습니다. 구글과 같은 선도적인 업체는 웹 환경에서 기존의 어플리케이션 시장을 하나 둘 잠식하여 갈 것입니다.
시간이 흘러감에 따라서 웹에서 무언 가를 하는 것이 더 체계화되어 갈 것입니다. 그리고 컴퓨터의 의미는 웹의 이용에 가깝게 되어갈 것입니다.
- CN의 낙서장 / HanIRC:#CN
- 죠커's blog / HanIRC:#CN
개인적으로 일반
개인적으로 일반 사용자들을 위한 어플리케이션 개발시 java의 가장 꺼려지는 부분은 사용자들이 이거 쓸려면 jvm이 있어야돼? 뭐가 그런게 다 있어? 불편하네.. 한다는 점입니다. 이것은 다른 인터프리팅 언어들도 마찬가진것 같구요.. 이것만 아니면 개발에 있어서는 뭔가 꺼림직한 부분은 없는것 같습니다.
----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.xo.st
http://hangulee.egloos.com/
----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com
VM이란 산은...
네이티브 코드 와 바이트 코드라...
1. 속도 : JAVA co-processor, JIT compiler...등등 속도가 몇몇 코드는 더 빠르다. 일반적으로 네이티브 코드의 70~80%까지 따라 잡았다. 그래도, 몇몇 코드는 현저하게 떨어진다. Quake 2를 해보라!
2. 메모리 : 네이티브 코드에 비해서 바이트 코드는 적게는 몇배에서 많게는 몇십배의 메모리가 필요하다. 요즘 기본이 512mb라고 하더라도...
3. 개발 : 네이티브 코드보다는 바이트 코드가 개발이 용이하다. 이 기종간의 실행환경에서도 수월하다. 단, VM은 누가 포팅해주나?
4. 라이센스 : C -> GCC , java -> JVM , GCC -> GPL, JVM -> SUN , GCC -> Open Source , JVM -> Binary , GCC -> x86, ARM, MIPS, PowerPC... , JVM -> x86, PowerPC
5. 문제점 : DMB -> DMB MPEG-2 + DAB(유레카) + Contents(JAVA), 자 이제 DMB Settop Box를 만들자. core는 물론 ARM이다. 큰일났다. VM을 포팅해야 한다. 상용을 쓰냐? 프리를 쓰냐? 프리를 쓰다 안되면 상용을 쓰자. 프리를 찾아 삼만리 포팅을 해보자. 이론 JAVA 버젼에 따른 스펙과 지원 패키지. 속도. 쥉장. 이건 다좋은데 ARM에 포팅된적이 없네. 문서나 찾아봐야겠다. 헉쓰. Google goooooooogle을 끝까지 가도 없네. 아는 동생은 ARM위에 OSGi를 올려야 하는데. JVM 때문에 x86으로 전환. ETRI Qplus 관계자분은 Qplus안에 JVM이 SUN JVM이라고 하시던데, 어떻게 ARM에 올리셨는지 모르겠던데 혹시 SUN 라이센스로 제공하나 모르겠네요. 혹시 아시는 분은 답변을 해주시면 감사하겠습니다. ^^;
Hello World.
arm에서 java vm을
arm에서 java vm을 사용할 필요가 있으면 어떻게 하나요? 프리/상용 모두 상관 없습니다. 저도 평소에 궁금했던 부분입니다.
standard라면 몰라도
standard라면 몰라도 micro edition정도는 쓸수 있습니다.
별루 할 수 있는게 없을라나?ㅋㅋ
폰들에 올라가 있으니까요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
arm에서는...
J2SE를 ARM CPU를 사용하는 임베디드 기기에 올리는 것은 좀 거시기하구요.
J2ME의 CDC, CLDC를 올리는 것은 이제 일반화된 일입니다.
이제 국내에 시판되는 모든 휴대폰에는 CLDC 스펙을 만족하는 JVM이 탑재되어 있고,
스카이라이프같은 셋탑 박스에는 CDC를 만족하는 JVM이 탑재되어 있죠.
휴대폰에 들어가는 JVM은 일반적인 경우 SUN의 KVM이나 CLDC_HI (HotSpot Impl.)을
커스터마이즈해서 탑재하고 있는데, 해외의 Esmertec, 국내의 XCE, 아로마소프트 등과
같이 자체 VM을 가지고 있는 업체들의 VM을 탑재하는 경우도 흔합니다.
(물론 SUN과는 라이센스 계약을 맺고 있는 업체들입니다.)
Sparc 머신에서
Sparc 머신에서 돌아가는 JVM 도 있습니다 :-)
썬에서 만들었으니.. 어찌보면 당연하겠지요?
http://blog.superwtk.com/
native code의 최후는 올
native code의 최후는 올 수도 있으리라 생각하지만 Java, .NET에 의해서 올 수 있을까에 대해서는 의문입니다. Java Virtual Machine의 Spec을 읽으면서 예전에 JVM을 설계해 보았는데 지나치게 이상적으로 설계한 듯한 느낌이 들었습니다. 제가 JVM을 설계하면서 느낀 것은 JVM에 있는 쓸데없는거 다 빼버리고 아주 simple하게 VM하나 만들고 싶다는 생각이 들더군요. ^^;
일단 Sun에서 Java를 내 놓으면서 했던 이야기가 JVM위에서 작동하는 프로그램은 현재는 Java로 작성해야만 하지만 앞으로는 기존의 언어로 작성된 프로그램들도 잘 작동할 것이라고 했지만 이미 Java가 등장한지 10년이 넘었지만 아직 잘 작동하지 않는 경우가 많습니다. ( Python정도가 잘 작동하는 듯 하군요. )
그리고 수시로 발생하는 Garbage Collection으로 인해 Realtime이 중요시되는 작업을 JVM위에서 하는 것이 불가능합니다. 공장의 벨브를 콘트롤 하는 프로그램을 JVM위에서 돌리려고 하면(실제로 제가 하려고 시도했었음) 뭔가 큰 일이 발생해서 얼른 벨브를 잠그려고 하는데 갑자기 Garbage Collection이 발생해서 열심히 Garbage를 Collect하는 상황이 발생해서 실제로 벨브를 잠구는데 상당시간 소요되기도 합니다. (-_-;;;)
그리고 Just In Time Compile도 좋긴 하지만 Compile하는데 시간이 너무 오래 걸립니다. 물론 startup만 되고 나면 native code에 비해 그다지 많이 느리지 않지만 JVM을 실행시키고 Compile도 하고 하다 보면 처음에 좀 지겹습니다. -_-; 그리고 그 compile된 code도 Garbage Collection을 할 때마다 정지되기 때문에 Realtime이 중요시되는 작업을 할 수가 없습니다. Java Application을 실행시키고 싶을 때 JVM을 실행하는게 아니라 미리 JVM을 실행시켜 놓는 방법도 있는데 JVM Spec상으로 하나의 Java Application이 일을 다 하고 끝마쳤을 때 JVM이 강제로 Java Application이 사용한 자원을 청소해 주는 방법이 존재하지 않습니다(요즘은 있을 지도?). JVM Process를 통째로 죽였다가 다시 실행해야 됩니다. 하지만 이것도 Process Model이 존재하지 않는 Embedded Platform에서는 Process를 죽일 수도 없으니 잘 눈속임하는 수밖에 없습니다. (몰래 초고속 reboot와 같은. ^^;;)
VM에 의해 native code가 사라질 가능성은 있지만 현재의 JVM은 여러가지로 문제가 많다는 것이 제 생각입니다. .NET도 살펴보면 JVM과 과연 뭐가 다른지 알기 힘들 정도로 유사한 느낌을 받았습니다. -_-;
Taeho Oh ( ohhara@postech.edu, ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
PLUS ( Postech Laboratory for Unix Security ) http://www.plus.or.kr
Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com
JVM은...
우선 Java 언어와 JVM은 별도로 생각해야 한다는 점을 지적하고 싶네요.
물론 JVM이 Java 언어의 특성에 맞도록 디자인되었다는 점은 이론의 여지가 없지만, 그 자체로 충분히 다른 OOP 언어의
실행 환경으로도 이용될 수 있다는 점은 많은 프로젝트를 통해 증명이 되고 있습니다. (다음의 링크 참고)
Programming Languages for the Java Virtual Machine
그리고 요즘 JVM의 Garbage Collector는 Generational Collection을 비롯한 여러 복합적인 GC 알고리즘이 적용되어
있기 때문에, 예전처럼 프로그램의 수행 중 pause 현상이 발생하는 경우는 현저하게 낮습니다.
만약 생각보다 pause 현상이 많이 일어난다면, 그것은 아마도 해당 자바 프로그램 그 자체를 비효율적으로 작성한
책임이 더 크다고 생각합니다. 많은 분들이 오해하시는 것 중 하나가 Java는 JVM에서 메모리 관리를 알아서 해주니
프로그램 작성 중에 메모리 관리에 대해서는 신경쓸 필요가 없다라는 것인데, 이는 크게 잘못된 생각입니다.
제아무리 효율적인 GC 알고리즘을 적용한 JVM이라 하더라도 메모리 할당을 비효율적으로 무지막지하게 해대는
자바 프로그램에 대해서는 대책이 없습니다. C 프로그램을 짤 때 만큼은 아니겠지만, 최소한 GC의 특성을 어느정도
이해한 후에 오브젝트 라이프 사이클에 대해서 세심하게 관리를 해준다면 Real-time 분야에서도 충분히 경쟁력이
있다라는 것이 제 생각입니다.
JIT의 경우에도 요즘의 JVM은 DAC(Dynamic Adaptive Compilation)을 기본적으로 채택하고 있기 때문에, startup 타임이
늦다던가 Compile할 때 pause 현상이 일어난다던지 하는 초기 JIT의 문제점들은 이제 거의 경험할 수 없는 현상입니다.
Compile할 때도 해당 메쏘드를 한번에 다 Compile하는 것이 아니라 다른 코드를 실행하면서 부분부분 나누어 Compile
하기 때문에 사용자는 현재 Compile 작업이 수행되고 있는지를 거의 감지할 수 없을 정도의 수준에 이르렀습니다.
ARM 사의 Jazelle(TM) 기술과 연동하면 더욱더 그렇구요.
마지막으로 요즘 JVM쪽 이슈가 바로 MVM(Multiple VM)입니다. 즉 하나의 JVM Process 상에서 여러 자바 프로그램을
동시에 돌리자는 것인데, 휴대폰쪽에서는 이미 상용화 제품들이 나오기 시작했고, J2EE 쪽에서도 거의 작업이 완료
단계에 있는 것으로 알고 있습니다. 이렇게 되면 시스템 클래스들을 여러 자바 프로그램들이 공유할 수 있게 되어
메모리 점유면이나 startup 타임 등에서 많은 이득을 볼 수 있습니다.
사실 저는 휴대폰과 같은 Embedded 환경에서만 JVM을 다뤘기 때문에 위의 이야기들이 PC 환경에서는 다소 다를 수
있음을 인정합니다. 하지만 요즘 ARM CPU의 클럭 스피드가 예전의 초창기 Pentium CPU와 별 차이가 없을 만큼 빠르고
JVM 기술도 많은 발전을 해왔기 때문에, Embedded 환경에서의 JVM이 느리다라는 시각에 대해서는 인정할 수 없는
입장입니다. Embedded 환경에서는 속도 뿐만 아니라 보안적인 측면이 상당히 중요하기 때문에 JVM을 비롯한
VM 기반의 접근 방식이 native code 방식보다는 더 득세할 것이라고 조심스럽게 예측해봅니다.
ps. 오하라군을 개인적으로 알고 있는 사이인데, 이렇게 답글을 다려니 좀 어색하군요. :-P
허어어어엇. 어쩐지
허어어어엇.
어쩐지 글 내용에서 뭔가 비범한 기운이 느껴진다 했는데. 역시 ^_^;;;;;; (부끄~~~)
자주 연락 하고 지내요~~~
Taeho Oh ( ohhara@postech.edu, ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
PLUS ( Postech Laboratory for Unix Security ) http://www.plus.or.kr
Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com
Layer.(계층이라
Layer.(계층이라 부르겠습니다) 컴퓨터를 하다보면 계층를 잘 나누어 놓은 부분을 많이 보게됩니다. 제일 먼저 생각 나는 것이 네트워크 부분이고, GCC도 preprocessor, compiler, link 등으로 나누어져 있고, 그외에도 여러 가지 많습니다. 이런 것들은 다른 부분에 영향을 주지 않고 변화를 시도하는 것이 가능하게 해줍니다. 컴퓨터도 하드웨어를 모두 직접 제어하다가 OS라는 계층을 만들었습니다. 하지만 각자의 기능 중복없이 분명 다릅니다.
제가 생각하는 건 리눅스만으로도 멀티 플랫폼이 가능하지 않을까 생각해서 입니다. 리눅스가 설치되는 플랫폼에서는 Hello, world 프로그램은 똑같이 컴파일이 됩니다. 물론 깊이 들어가면 아키텍쳐 마다 다르게 해주어야 할 부분이 있겠지요. 리눅스 소스 처럼요. 리눅스 커널은 어셈블러 때문에 그렇지만 일반 어플리케이션이라면 그 차이도 적을 겁니다. 굳이 여기에 JVM, .net같은 것은 기능이 중복으로 보이고, 그로 인한 낭비가 심해보입니다. 그리고 JVM, .net도 아키텍쳐마다 설정해줄 것이 전혀없는지도 궁금하고요.
물론 아무리 세상이 좋아져도 리눅스만 쓰이는 날은 없을 겁니다만, 네이티브 코드로도 충분히 가능한 것을 굳이 계층을 한 단계 위로 올려 할 건 없다고 봅니다.
정품 소프트웨어 사용 캠패인
정품 소프트웨어 사용 캠패인
VM을 쓰는 것은
VM을 쓰는 것은 단순히 portability를 높이기 위해서가 아닙니다.
그런 것 뿐이라면 portable한 OS나 compiler를 쓰는 것으로 충분하겠죠.
Java나 .NET 기술은 기존 library 기반의 system 개발을
platform(혹은 framework) 기반의 system 개발로 이동시키고 있습니다.
그로해서 생산성의 향상을 꾀하고 있고, 개발 속도도 많이 빨라졌죠.
Security 문제도 framework 자체에서 해결을 하려고 하고 있고,
흔히 발생하는 memory leak 같은 bug들에 대해서도 그렇습니다.
뭐 사람이 bug 없이 잘 개발하고, 빨리 개발한다면
Java나 .NET framework이 portability를 제외하고는
크게 장점이 없을 수도 있겠지만 실제론 그게 아니니까요.
( 이건 큰 system일수록 더욱 문제가 되는 것이고요. )
Hard real-time system 개발 같은 특별한 상황이 아닌 이상은
VM 기반의 framework들은 개발자들에게 환영받을만한 것들이 아닌가 싶네요.
뭐 개인적으로야 싫어할 수도 있겠지만 이미 대세가 되어가고 있지 않은지. ;;
생각해보면 이런 장점도 있죠.
JIT 컴파일러는 실행때마다 컴파일을 합니다.
수행되는 프로그램은 동일하고 CPU는 좋은 것으로 업그레이드되었다 하면...
원래 쓰던 CPU에 맞춰진 네이티브 코드로 실행되는 것이 아니라.
새로 구입한 CPU에 맞게 최적화 JIT컴파일된 실행도 기대할 수 있습니다.
즉 새 CPU의 빨라진 클럭수 이상의 이득을 기대할 수 있습니다.
1. 하위호환성이 있는 CPU라면 추가된 새로운 인스트럭션을 사용할 수 있는 이득
2. (apple이 그랬던 것처럼... PowerPC에서 x86으로 스펙이 바뀐다해도...)
기존 프로그램을 다시 빌드할 필요가 없다는 이득.
네이티브 코드가
네이티브 코드가 사라지는 경우는 없겠죠. 눈에 안보이는 경우는 생기더라도요.
일단 과학 계산이라던가 3D 그래픽스 등 순수하게 "계산"이 필요한 분야에서는 유효할 것이라고 봅니다.
인터프리터 언어나 JIT 언어들이 충분한 속도를 제공한다고 하더라도 네이티브보다 빠를 수는 없기 때문에 단순한 처리를 무지막지하게 해대야 하는 분야에서는 말이죠.
점점 임베디드 기계들이 많이 사용 되면서 그쪽 분야에서 활용되는 네이티브 언어들도 무시할 수 없죠. 저전력 소형 장비들은 앞으로 늘어날 분위기이고...이쪽은 말 그대로 "전력" 때문에라도 네이티르 언어를 써야 되겠죠. (전력 때문에 CPU 좋은거 꽂는게 부담됩니다.)
핸드폰쪽도...J2ME가 가장 잘 적용된 분야라고는 하지만, 제작년까지만 해도 Java기반 어플들이 네이티브 기반(BREW)을 절대 따라올 수 없었습니다.
WIPI초기에도(작년?) Java로 짠건 느려서 C로 짠다는 예기가 있었구요. 헨펀쪽은 뭐 워낙 H/W 발전이 빠른 분야라 어찌될지 모르긴 하군요. ^^;
적어도 embedded에선...
메모리 1M가 곧 돈이죠.
여기선 네이티브가 강세일 수 밖에 없죠.
JVM이 올라가는 놈들도 보이긴 하지만 아직은...
제 경험을 바탕으로
제 경험을 바탕으로 말하자면 모바일에서도 jvm이 느린것 보다는 폰(주로 lcd관련)이 느리거나 jvm의 기본적인 페인트 방식이나 개발자의 플랫폼에 대한 이해가 속도에 더 영향을 주는것 같았습니다.
우선 일례로 wipi 국가 과제중에 sk의 gvm기반 게임을 wipi java로 컨버팅 했는데 내부적으로 더블 버퍼링을 구현한 부분이 매우 느렸습니다. 그래서 당시 플랫폼 개발 업체와 컨택해서 플랫폼에서 제공하는 lcd메모리 복사 로직을 최적화 한 후에 매우 빨라졌습니다. 그때 플랫폼 개발 업체의 담당자 말로는 그당시 포팅된 lg폰의 lcd메모리 구조가 플랫폼 내부의 비트맵의 메모리 구조와 반대로 되어 있어서 처음에는 매우 느렸다고 하더군요. 복사 로직을 변경한 후에 빨라졌다고 했는데 자세한 내용은 저도 알 수 없었습니다.
그리고 다음엔 유럽 nokia 폰으로 일부 gvm혹은 brew기반 게임을 컨버팅 했는데 비슷한 크기의 lcd와 메모리 기반에서 오히려 brew기반 게임보다 속도가 더 빨랐습니다. 아마도 cpu, lcd의 속도가 대부분의 국내 폰 보다 빨랐을듯 합니다. jvm도 폰에 더욱 최적화가 되었을 테구요.
제가 말하고자 하는건 embedded에서 native기반의 코드가 최적화나 기본적인 속도 면에서는 당연히 유리하겠지만 jvm기반도 충분히 메리트가 있다는 것입니다. 물론 jvm이 하드웨어의 능력을 잘 발휘하도록 충분히 최적화가 되어있는 상황에서만 가능한 얘기겠지요.
이 얘기는 제가 경험한 핸드폰(midp,wipi,gvm,brew)용 게임 개발에 한해서만 해당되는 이야기입니다. 다른 분야는 아는게 없습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.