Ruby, Python에서 Javascript V8 속도를 얻는 데 필요한 블록은 무엇입니까?




python vs javascript (8)

V8 엔진에 최적화 (예 : 인라인 캐싱 ) 구현을 차단하는 루비 / 파이썬 기능이 있습니까?

파이썬은 Google 사람들이 공동 개발 한 소프트웨어 특허에 의해 차단되어서는 안됩니다.

또는 이것은 Google이 V8 프로젝트에 투입 한 자원의 문제입니다.


Ruby, Python에서 Javascript V8 속도를 얻는 데 필요한 블록은 무엇입니까?

아무것도.

음, 알았어. 돈. (그리고 시간, 사람, 자원,하지만 돈이 있다면 그 돈을 살 수 있습니다.)

V8은 고성능 실행을 위해 수십 년의 경험이 있습니다. (저는 개별적으로 말하고 있습니다 - 집합 적으로 수세기와 비슷합니다) 뛰어난, 뛰어난 전문성을 갖춘 고도로 숙련 된 엔지니어들로 구성된 팀이 있습니다. 동적 OO 언어 용 엔진. 그들은 기본적으로 Sun HotSpot JVM을 만든 사람들과 동일합니다.

리드 개발자 인 Lars Bak은 글자 그대로 VM에서 25 년 동안 일해 왔으며 (모든 VM이 V8까지 이어짐), 이는 기본적으로 그의 전체 (프로) 삶입니다. Ruby VM을 작성하는 사람들 중 일부는 25 세가되지 않습니다.

V8 엔진에 최적화 (예 : 인라인 캐싱) 구현을 차단하는 루비 / 파이썬 기능이 있습니까?

최소한 IronRuby, JRuby, MagLev, MacRuby 및 Rubinius에는 단일 양식 (IronRuby) 또는 다형 인라인 캐싱이 있으므로 감안할 때 분명히 대답은 아닙니다.

현대 Ruby 구현은 이미 많은 최적화를 수행합니다. 예를 들어 특정 작업의 경우 Rubinius의 Hash 클래스는 YARV보다 빠릅니다. 이제 Rubinius의 Hash 클래스가 100 % 순수 루비로 구현되고 YARV는 100 % 손으로 최적화 된 C로 구현된다는 것을 알기 전까지는이 사실이 그리 흥미로운 것은 아닙니다.

그래서 적어도 Rubinius는 GCC보다 더 나은 코드를 생성 할 수 있습니다!

또는 이것은 Google이 V8 프로젝트에 투입 한 자원의 문제입니다.

예. Google뿐 아니라 V8 소스 코드의 혈통은 현재 25 살입니다. V8을 연구하는 사람들은 Self VM (오늘날까지 생성 된 가장 빠른 동적 OO 언어 실행 엔진 중 하나), Animorphic Smalltalk VM (현재까지 작성된 가장 빠른 Smalltalk 실행 엔진 중 하나), HotSpot JVM (가장 빠른 JVM, 아마도 가장 빠른 VM 기간) 및 OOVM (지금까지 생성 된 가장 효율적인 Smalltalk VM 중 하나)

사실, V8의 수석 개발자 인 Lars Bak은 그 중 하나 하나 와 다른 몇 가지 작업을 수행했습니다.


그 진술은 정확하게 사실이 아니다.

V8이 JS의 구현물 일뿐 아니라 CPython은 Python의 한 구현물이다. Pypy는 V8과 일치하는 퍼포먼스를 가지고 있습니다.

또한 V8은 기본적으로 비 차단이기 때문에 웹 대기열은 IO 대기 시간을 절약하기 때문에 더 많은 실적이있는 프로젝트로 연결됩니다. 그리고 V8은 주로 IO가 핵심 인 개발 웹에 사용되므로 유사한 프로젝트와 비교합니다. 하지만 파이썬은 웹 개발자가 아닌 다른 많은 분야에서 사용할 수 있습니다. 또한 과학적 계산이나 암호화와 같은 많은 작업에 C 확장을 사용할 수 있으며 탁월한 성능으로 데이터를 처리 할 수도 있습니다.

그러나 웹에서 가장 인기있는 Python과 Ruby 프로젝트가 차단되고 있습니다. 파이썬은 특히 동기식 WSGI 표준의 유산을 가지고 있으며 유명한 장고와 같은 프레임 워크가이를 기반으로합니다.

비동기 Python (Twisted, Tornado, gevent 또는 asyncio) 또는 Ruby를 작성할 수 있습니다. 그러나 그것은 자주 행해지지는 않습니다. 가장 좋은 도구는 여전히 차단됩니다.

그러나 Ruby와 Python의 기본 구현이 V8만큼 빠르지 않은 데는 이유가 있습니다.

경험

Jörg W Mittag가 지적했듯이, V8에서 일하는 사람들은 VM 천재입니다. 파이썬은 많은 열정을 가진 열렬한 사람들에 의해 개발되었지만 VM 튜닝을 전문으로하지는 않습니다.

자원

파이썬 소프트웨어 재단은 거의 돈이 없습니다. 파이썬에 투자하는 데 1 년에 40,000 개 미만 입니다. Google, Facebook, Apple과 같은 대형 업체가 모두 Python을 사용한다고 생각할 때 이것은 다소 미친 짓입니다.하지만 대부분의 작업은 무료입니다. 유튜브에 힘을주고 자바가 자원 봉사자들에 의해 손으로 만들어지기 전에 존재했던 언어.

그들은 영리하고 헌신적 인 자원 봉사자이지만 현장에서 더 많은 주스가 필요하다고 판단되면 300k에게이 전문 지식 분야의 최고 전문가를 고용하도록 요청할 수 없습니다. 그들은 무료로 누군가를 둘러 봐야합니다.

이 방법이 효과가있는 동안 우선 순위에 대해 신중해야합니다. 그러므로 이제 우리는 다음을 살펴볼 필요가 있습니다.

목표

최신 모던 기능이 있더라도 Javascript를 작성하는 것은 끔찍한 일입니다. 범위 지정 문제, 매우 적은 수의 콜렉션, 끔찍한 문자열 및 배열 조작, 날짜, 수학 및 정규 표현식을 제외하고는 거의 stdlist가 없으며 매우 일반적인 작업에도 구문론 적 설탕이 없습니다.

그러나 V8에서는 속도가 빨라졌습니다.

이는 Chrome에서 페이지 렌더링의 병목 현상이 발생했기 때문에 속도가 Google의 주요 목표 였기 때문입니다.

파이썬에서는 유용성이 주요 목표입니다. 거의 프로젝트의 병목 현상이 아니기 때문입니다. 부족한 리소스는 개발자의 시간입니다. 개발자를 위해 최적화되어 있습니다.


JavaScript 구현은 바인딩의 하위 호환성에 신경을 쓸 필요가 없기 때문입니다.

최근까지 자바 스크립트 구현의 유일한 사용자는 웹 브라우저였습니다. 보안 요구 사항으로 인해 웹 브라우저 공급 업체 만 런타임에 바인딩을 작성하여 기능을 확장 할 수있는 권한이있었습니다. 따라서 바인딩의 C API를 이전 버전과 호환되도록 유지할 필요가 없었으며 자바 스크립트 런타임이 발전함에 따라 웹 브라우저 개발자가 소스 코드를 업데이트하도록 요청할 수있었습니다. 그들은 어쨌든 함께 일하고있었습니다. 게임의 후발주 였고 매우 숙련 된 개발자가 이끄는 V8조차도 API가 바뀌면서 API가 변경되었습니다.

OTOH Ruby는 (주로) 서버 측에서 사용됩니다. 많은 인기있는 루비 확장은 C 바인딩으로 작성됩니다 (RDBMS 드라이버를 고려하십시오). 즉, Ruby는 호환성을 유지하지 않으면 성공하지 못했을 것입니다.

오늘날 차이는 여전히 어느 정도 존재합니다. node.js를 사용하는 개발자는 V8이 API를 시간이 지남에 따라 변경 (즉, node.js가 분기 된 이유 중 하나이기 때문에)하여 네이티브 확장을 이전 버전과의 호환성을 유지하기가 어렵다고 불평하고 있습니다. IIRC 루비는이 점에서 여전히 훨씬 보수적 인 접근 방식을 취하고 있습니다.


V8은 JIT, 크랭크 샤프트, 유형 추론 기 및 데이터 최적화 코드로 인해 빠릅니다. 태그가 붙은 포인터, NaN - double 형의 태깅. 그리고 물론 중간에 일반적인 컴파일러 최적화를 수행합니다.

평범한 루비, 파이썬 및 펄 엔진은 그 중 일부를 수행하지 않으며 단지 기본 최적화 만 수행합니다.

클로저가되는 주요한 vm은 타입 유추, 상수 폴딩, NaN 태그 지정 또는 정수조차하지 않지만 나쁜 언어처럼 뚱뚱하지 않은 유사한 작은 코드 및 데이터 구조를 사용하는 루아 츠 (luajit)뿐입니다. 제 프로토 타입 동적 언어 인 potion과 p2는 루아 젯과 비슷한 기능을 가지고 있으며 v8을 능가합니다. 옵션 유형 시스템 인 "점진적 타이핑"을 사용하면 크랭크 샤프트를 우회 할 수 있으므로 v8보다 쉽게 ​​성능을 향상시킬 수 있습니다. 다트보기.

pypy 나 jruby와 같은 잘 알려진 최적화 된 백엔드는 여전히 다양한 over-engineering 기술로 어려움을 겪고 있습니다.


난 그냥이 질문을 가로 질렀다 언급되지 않은 성능 차이에 대한 큰 기술적 인 이유가 있습니다. 파이썬은 강력한 소프트웨어 확장의 매우 큰 에코 시스템을 가지고 있지만 이러한 확장의 대부분은 성능을 위해 C 또는 다른 저수준 언어로 작성되었으며 CPython API와 밀접하게 관련되어 있습니다.

CPython 구현 속도를 높이기 위해 사용할 수있는 잘 알려진 기술 (JIT, 현대 가비지 컬렉터 등)이 많이 있지만 API의 상당 부분을 변경해야 프로세스의 확장 기능을 대부분 손상시킬 수 있습니다. CPython은 더 빠르지 만, Python을 너무 매력적으로 만드는 많은 것들 (광범위한 소프트웨어 스택)은 사라질 것입니다. 예를 들어, 거기에는 몇 가지 더 빠른 Python 구현이 있지만 CPython과 비교하면 거의 견인력이 없습니다.


다른 사람들이 언급했듯이, Python에는 PyPy 의 형태로 실행 가능한 JIT 컴파일러가 있습니다.

의미있는 벤치 마크를 작성하는 것은 언제나 미묘하지만 다른 언어로 작성된 K-means 의 간단한 벤치 마크가 here . here 찾을 수 here . 제약 조건 중 하나는 다양한 언어가 모두 동일한 알고리즘을 구현해야하며 단순하고 관용적이되도록 노력해야한다는 것입니다 (속도 최적화가 아닌). 모든 구현을 작성 했으므로 내가 속임수를 쓰지 않았다는 것을 알았지 만, 필자가 작성한 언어가 관용적이라고 모든 언어에 대해 주장 할 수는 없지만 (나는 그 중 일부에 대해서만 지식이있다).

결론을 내리지는 않았지만, PyPy는 Node보다 훨씬 빠른 구현 방법 중 하나였습니다. 대신 CPython은 순위에서 가장 느린쪽에있었습니다.


오해의 소지가있는 질문. V8은 JavaScript의 JIT (Just in Time Compiler) 구현이며 가장 인기있는 브라우저가 아닌 구현 인 Node.js에서 이벤트 루프를 중심으로 구성됩니다. CPython은 JIT가 아니며 이벤트가 발생하지 않습니다. 그러나 Python 프로젝트에서는 CPython 2.7 (곧 3.0 + 이상) 호환 JIT가 Python 프로젝트에서 가장 일반적으로 존재합니다. 예를 들어 Tornado와 같은 많은 이벤트 라이브러리가 있습니다. Tornado와 Node.js를 실행하는 PyPy와 현실적인 테스트가 존재하며 성능 차이는 미미합니다.


자바 스크립트 해석기를 고도로 최적화하는 데 더 많은 자극이 있습니다. 그래서 우리는 많은 자원이 모질라, 구글, 마이크로 소프트 사이에 배치되는 것을 보았습니다. JavaScript는 다운로드되고, 구문 분석되고, 컴파일되고, 실시간으로 실행되어야합니다. (보통 참을성이없는) 인간이 그것을 기다리고 있고, 사람이 그것과 상호 작용하는 동안 실행해야하며, 제어되지 않은 클라이언트 측에서는이를 수행하고 있습니다. 컴퓨터, 전화 또는 토스터가 될 수있는 환경. 이 조건 하에서 효과적으로 운영되기 위해서는 효율적이어야합니다.

Python과 Ruby는 개발자 / 배포자가 제어하는 ​​환경에서 실행됩니다. 일반적으로 메모리 또는 디스크 I / O 및 실행 시간과 같은 요소가 제한되는 서버 또는 데스크톱 시스템 또는 캐싱과 같은 비 엔진 최적화를 활용할 수있는 곳. 이러한 언어의 경우 속도 최적화보다 언어 및 라이브러리 기능에 초점을 맞추는 것이 더 바람직합니다.

이것의 부수적 인 이점은 우리가 Node.js와 같은 모든 유형의 애플리케이션에 맞게 다시 사용할 수있는 2 개의 고성능 오픈 소스 JavaScript 엔진을 가지고 있다는 것입니다.







language-design