자바 스크립트 엔진 장점

Question

지금 자바 스크립트 엔진에 대해 혼란스러워합니다. V8은 자바 스크립트를 기본 코드로 컴파일했기 때문에 큰 문제였습니다.

그런 다음 약 Mozilla SpiderMonkey에 대해 읽었습니다.이 내용은 C에서 작성되었으며 JavaScript를 컴파일 할 수 있습니다. 그렇다면 이것이 V8과 어떻게 다른가? 그리고 이것이 사실이라면 왜 Firefox가 이것을하지 않습니까?

마지막으로 Rhino은 자바 스크립트를 자바 바이트 코드로 컴파일하여 Java의 모든 속도 이점을 얻을 수 있습니까? 그렇지 않다면 왜 데스크톱에서 스크립트를 작성할 때 사람들이 V8을 실행하지 않습니까?

Answer 1

V8이 모든 JS를 컴퓨터 코드로 컴파일하기 때문에 가장 빠릅니다.

SpiderMonkey (FF가 사용하는 것)도 빠르지 만 기계어 코드가 아닌 중간 바이트 코드로 컴파일됩니다. V8과의 주요 차이점입니다. 편집 - 최신 파이어 폭스 릴리스에는 SpideMonkey의 새로운 변종이 포함되어 있습니다. TraceMonkey. TraceMonkey는 중요한 부분을 JIT 컴파일하고 다른 스마트 최적화를 수행합니다.

Rhino는 Javascript를 Java 클래스로 컴파일하므로 기본적으로 Javascript로 "Java"응용 프로그램을 작성할 수 있습니다. Rhino는 JS를 백엔드에서 해석하고 조작하고 반사와 같은 코드를 완전히 이해할 수있는 방법으로도 사용됩니다. 이것은 예를 들어 YUI Compressor에서 사용됩니다.

V8 대신에 Rhino가 사용되는 이유는 V8이 비교적 새롭기 때문일 수 있습니다. 따라서 많은 프로젝트가 이미 Yahoo 엔진과 같이 JS 엔진으로 Rhino/Spidermonkey를 사용하고 있습니다. (나는 당신이 "데스크탑의 스크립트"라고 말한 것으로 생각합니다.)

편집 이 링크는 SpiderMonkey가 널리 채택 된 이유에 대한 통찰력을 줄 수도 있습니다. Which Javascript engine would you embed in your application?

Answer 2

는

네이티브 코드가 빠르다 ... 질문, 바이트 코드를 대 왜 네이티브 코드를 응답하고 구글의 전략적 선택 그들은 적어도 크롬입니다 그들 JS 하나 계획을 가지고 있기 때문이다.

이 질문에 대한 좋은 비디오는 다양한 자바 스크립트 엔진을 쌓아 브라우저에서, 사파리를 설치하는 방법을 보려면 V8 뒤에있는 사람이 here

Answer 3

을 찾을 수 있습니다 라스 박과의 인터뷰와는 Channel9에 게시 4 (네 지금은 너무 윈도우에서 실행!) (당신이 창에있는 경우) 및 벤치 마크 실행, 크롬 V8, 파이어 폭스 3.5, 그리고 IE 8 : 나는 믿고

http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

을 뾰족한 위, 상기로 새로운 Firefox 3.5는 TraceMonkey를 사용하여 일부 f를 사용하여 즉석에서 코드를 중간에 컴파일합니다. JIT의 orm. 따라서 V8과 다소 유리하게 비교되어야합니다. 적어도 Firefox 3 SpiderMonkey (JIT없이)처럼 V8보다 10 배 느려지지 않을 것입니다.

나를 위해 ... 사파리 4.0.3은 Win XP에서 Firefox 3.5.3의 Tracemonky보다 2.5 배 빠릅니다. IE8은 훨씬 느렸다. 현재 Chrome을 설치하지 않았습니다.

Rhino에서 java 바이트 코드로 컴파일하는 것에 대해 모르십니까? 런타임에 객체 인스턴스에 속성을 추가 할 수있는 것과 같이 자바의 동적 기능을 해석하는 경우 (예 : obj.someNewAttribute = "someValue"는 자바 스크립트에서 허용됨) ...나는 그것이 바이트 코드에 전적으로 "컴파일"되어 있는지 확신하지 못한다. 자바 스크립트가 실행될 때마다 자바 스크립트 소스 코드 텍스트에서 컴파일 할 필요가없는 것보다 나은 성능을 얻지 못할 수도있다. Javascript는 eval ("x = 10; y = 20; z = x * y")와 같이 매우 동적 인 구문을 허용한다는 것을 기억하십시오. 즉 런타임에 컴파일되는 코드 문자열을 작성할 수 있습니다. 그래서 JVM 바이트 코드로 컴파일했다하더라도 Rhino가 혼합 모드 해석/컴파일 될 것이라고 생각합니다.

JVM은 여전히 ​​JIT를 지원하는 아주 좋은 도구이지만 인터프리터입니다. 그래서 Rhino-on-JVM을 2 개의 인터프리터 레이어 (인터프리터 통역사) 또는 2 개의 인터프리터라고 생각합니다. 다른 Javascript 엔진의 대부분은 C로 작성되었으므로 더 많은 인터프리터^1을 수행해야합니다. 각 인터프리터 레이어는 C 또는 C++ (예 : Perl 또는 Python 또는 Ruby를 참조)와 비교하여 5-10x 성능 저하를 추가 할 수 있지만 JIT를 사용하면 성능이 2 ~ 4 배 정도 낮아질 수 있습니다. 그리고 JVM은 가장 강력한 & 성숙한 JIT 엔진 중 하나입니다.

따라서 귀하의 마일리지는 분명히 다를 것이며 자신의 하드웨어 & OS에서 의도 한 응용 프로그램에 대한 실제 답변을 원한다면 몇 가지 심각한 벤치 마크를 통해 이익을 얻을 수 있습니다.

많은 사람들이 사용하고 있기 때문에 Rhino를 너무 느리게 할 수는 없습니다. 주요 매력은 속도가 아니라 자바 라이브러리에 훅 (hook)이있는 코드/라이트 웨이트/임베디드/인터프리터이며, 소프트웨어 프로젝트의 스크립팅/설정/확장성에 완벽하다는 사실입니다. UltraEdit과 같은 일부 텍스트 편집기는 Javascript를 대체 매크로 스크립팅 엔진으로 임베드합니다. 모든 프로그래머는 자바 스크립트를 통해 쉽게 발견 할 수있는 것처럼 보이기 때문에 쉽게 픽업 할 수 있습니다.

Rhino의 장점 중 하나는 JVM이 실행되는 곳이면 어디서든 실행된다는 것입니다. 내 경험상 독립 실행 형 TraceMonkey 또는 SpiderMonkey를 명령 행에서 실행하여 &으로 만들려고하면 Windows와 같은 시스템에서 약간 어려울 수 있습니다. 또한 자신의 응용 프로그램에 포함하는 것이 훨씬 더 많은 시간을 소비 할 수 있습니다. 그러나 임베디드 언어를 사용하는 것에 대한 투자는 큰 프로젝트의 경우 가치가있을 것입니다. 자신 만의 미니 스크립팅 솔루션을 필요로하는 경우 "롤"해야하는 것과 비교하면됩니다.

자바와 rhino jar를 가지고 있다면 Rhino로 스크립팅하는 것이 매우 쉽습니다. 자바 스크립트를 작성하고 명령 줄에서 실행하면 Rhino로 스크립팅하는 것이 정말 쉽습니다. 나는 간단한 작업을 위해 항상 그것을 사용한다.

Answer 4

JIT를 수행 할 때조차도 JavaScript 실행에는 다양한 방법이 있습니다. V8과 Nitro (이전 SquirrelFish Extreme으로 알려짐)는 전체 메서드 JIT를 선택합니다. 즉, 스크립트를 만날 때 모든 JavaScript 코드를 기본 지침으로 컴파일 한 다음 컴파일 된 C 코드처럼 간단히 실행합니다. SpiderMonkey는 먼저 "추적"JIT를 사용합니다.이 JIT는 스크립트를 먼저 바이트 코드로 컴파일하고 해석하지만 실행을 모니터링하여 루프와 같은 "핫 스폿"을 찾습니다. 그 중 하나를 발견하면, 바로 그 뜨거운 경로를 기계어 코드로 컴파일하고 나중에 실행합니다.

두 가지 방법 모두 장단점이 있습니다. Whole-method JIT는 실행되는 모든 JavaScript가 컴파일되고 기계 코드로 실행되며 해석되지 않도록합니다. 일반적으로 더 빠릅니다. 그러나 구현에 따라 엔진이 실행되지 않을 코드를 컴파일하는 데 시간을 소비하거나 성능상 중요한 것은 아닙니다. 또한 컴파일 된 코드는 메모리에 저장해야하므로 메모리 사용량이 높아질 수 있습니다.

SpiderMonkey에서 구현 된 추적 JIT는 코드를 이미 실행했기 때문에 전체 메서드 JIT와 비교하여 매우 특수화 된 코드를 생성 할 수 있으며 for 루프에서 index 변수를 처리하는 것과 같이 변수 유형을 추측 할 수 있습니다 전체 메서드 JIT는 JavaScript가 유형 지정되지 않고 유형이 변경 될 수 있기 때문에 변수를 객체로 처리해야합니다 (SpiderMonkey는 가정이 실패하면 SpiderMonkey 추적을 단순히 "해제"하고 바이트 코드 해석으로 돌아갑니다) . 그러나 SpiderMonkey의 추적 JIT는 현재 여러 분기가있는 코드에서 효율적으로 작동하지 않습니다. 추적은 단일 경로의 실행에 맞게 최적화되어 있기 때문입니다. 또한 추적을 컴파일하고 해당 추적으로 실행을 전환하기 전에 실행 모니터링에 관련된 약간의 오버 헤드가 있습니다. 또한 추적자가 나중에 위반되는 가정 (예 : 변수 변경 유형)을 사용하면 추적에서 제외되고 해석으로 다시 전환하는 비용이 전체 방법 JIT보다 높습니다.