Javascript V8 속도를 얻기 위해 Ruby, Python을 차단하는 것은 무엇입니까?

Javascript V8 속도를 얻기 위해 Ruby, Python을 차단하는 것은 무엇입니까?

닫혔어. 이 질문은 좀 더 자세히 설명해야 합니다.초점을 맞춥니다.현재 답변을 받고 있지 않습니다.

닫힘7년 전.

잠겼습니다. 이 질문과 답변은이 질문은 부적절하지만 역사적 의미가 있기 때문에 잠겨 있습니다.현재 새로운 답변이나 상호작용을 받아들이지 않고 있습니다.

V8 엔진의 최적화 구현(인라인 캐싱 등)을 방해하는 Ruby/Python 기능이 있습니까?

Python은 구글에 의해 공동 개발되었으므로 소프트웨어 특허에 의해 차단되어서는 안 된다.

아니면 Google이 V8 프로젝트에 투입한 자원의 문제일 수도 있습니다.

Javascript V8 속도를 얻기 위해 Ruby, Python을 차단하는 것은 무엇입니까?

아무 것도 없어요.

음, 좋아요. 돈. (그리고 시간, 인력, 자원. 하지만 돈이 있다면, 그것들을 살 수 있어요.)

V8에는 수십 년 동안 역동적인 OOO 언어를 위한 고성능 실행 엔진을 만들어 온 경험이 있는 뛰어난 전문 기술자(따라서 고액 연봉)들로 구성된 팀이 있습니다.이들은 기본적으로 Sun HotSpot JVM(다른 많은 사람들 중)을 만든 사람들입니다.

수석 개발자인 Lars Bak은 말 그대로 25년 동안 VM에 대해 연구해 왔습니다(그리고 이러한 VM은 모두 V8까지 이어졌습니다). 이는 기본적으로 그의 (프로페셔널한) 삶 전체입니다.루비 VM을 쓰는 사람들 중 일부는 25세도 되지 않았다.

V8 엔진의 최적화 구현(인라인 캐싱 등)을 방해하는 Ruby/Python 기능이 있습니까?

적어도 IronRuby, JRuby, MagLev, MacRuby 및 Rubinius는 단형(IronRuby) 또는 다형 인라인캐싱 중 하나를 가지고 있기 때문에 대답은 명백히 "아니오"입니다.

최신 Ruby 구현은 이미 많은 최적화를 수행하고 있습니다.예를 들어, 특정 작업의 경우, 루비니우스의Hash클래스가 YARV보다 빠릅니다.루비니우스의 말이 듣기 전까지는 별로 신나 보이지 않겠지만Hash클래스는 100% 순수 루비로 구현되며, YARV는 100% 수작업으로 최적화된 C로 구현됩니다.

따라서 적어도 경우에 따라서는 Rubinius가 GCC보다 더 좋은 코드를 생성할 수 있습니다.

아니면 Google이 V8 프로젝트에 투입한 자원의 문제일 수도 있습니다.

네, 구글뿐만이 아닙니다.V8의 소스코드의 계보는 이제 25년이 되었다.V8에 종사하는 사람들은 Self VM(현재까지 만들어진 것 중 가장 빠른 동적 OO 언어 실행 엔진 중 하나), Animorphic Smalltalk VM(현재까지 만들어진 것 중 가장 빠른 Smalltalk 실행 엔진 중 하나), HotSpot JVM(지금까지 만들어진 JVM 중 가장 빠른 속도, 아마도 VM 기간 중 가장 빠른 속도) 및 OOVM MOSone(MOSone)도 만들었습니다.지금까지 작성된 효율적인 Smalltalk VM).

실제로 V8의 수석 개발자인 Lars Bak은 이러한 모든 작업을 수행했으며, 그 외에도 몇 가지 작업을 수행했습니다.

JavaScript 인터프리터를 고도로 최적화하기 위한 추진력이 훨씬 더 높기 때문에 Mozilla, Google 및 Microsoft 간에 많은 리소스가 투입되고 있습니다.JavaScript는 (보통 성급한) 사람이 기다리는 동안 실시간으로 다운로드, 구문 분석, 컴파일 및 실행되어야 하며, 사람이 대화하는 동안 실행되어야 하며, 이를 컴퓨터, 전화기 또는 토스터와 같은 제어되지 않은 클라이언트 엔드 환경에서 수행해야 합니다.이러한 조건에서 효과적으로 작동하려면 효율이 뛰어나야 합니다.

Python과 Ruby는 개발자/디플로이더가 제어하는 환경에서 실행됩니다.일반적으로 실행 시간이 아닌 메모리나 디스크 I/O 등의 제한이 있는 서버 또는 데스크톱 시스템입니다.또는 캐싱과 같은 비엔진 최적화를 사용할 수 있는 장소도 있습니다.이러한 언어에서는 속도 최적화보다 언어 및 라이브러리 기능 세트에 초점을 맞추는 것이 더 합리적일 수 있습니다.

이 외에도 Node.js와 같은 모든 종류의 애플리케이션을 위해 용도 변경할 수 있는 고성능 오픈 소스 JavaScript 엔진이 2개 있습니다.

그것의 상당 부분은 지역사회와 관련이 있다.Python과 Ruby는 대부분 기업 지원이 없습니다.아무도 Python과 Ruby에서 풀타임으로 일하는데 돈을 받지 않는다(특히 그들은 CPython이나 MRI에서 일하는데 항상 돈을 받는 것은 아니다).한편, V8은 세계 최강의 IT기업의 지원을 받고 있습니다.

게다가 V8의 종업원에게 있어서 중요한 것은 통역뿐이기 때문에, V8의 속도가 빨라질 수 있습니다.즉, V8은 작업할 표준 라이브러리가 없고, 언어 설계에 대한 염려도 없습니다.그들은 통역사를 쓸 뿐이다.바로 그겁니다.

그것은 지적재산권법과는 아무런 관련이 없다.또한 Python은 Google guys에 의해 공동 개발되지 않았다(그 크리에이터는 몇몇 다른 커밋들과 함께 그곳에서 일하지만 Python에서 일하는데 돈을 받지 못한다).

Python 속도의 또 다른 장애물은 Python 3이다.언어 개발자의 주된 관심사는 언어 개발자인 것 같습니다.다른 구현이 따라잡을 때까지 새로운 언어 기능의 개발을 동결할 정도입니다.

기술적인 세부 사항에 대해서는 잘 모르지만, Python은 최적화를 사용할 수 있는 장소가 많이 있다(그리고 Google 프로젝트인 Unlading Swallow는 이를 구현하기 시작했다).다음은 그들이 계획한 최적화의 일부입니다.앞으로 Python에 JIT a la PyPy를 구현하면 Python의 V8 속도가 빨라지는 것을 볼 수 있지만, 향후 몇 년 동안은 그렇게 될 것 같지 않다(현재의 초점은 JIT가 아닌 Python 3 채택이다).

또한 많은 사람들은 Ruby와 Python이 각각의 글로벌 인터프리터 잠금을 제거함으로써 막대한 이익을 얻을 수 있다고 생각한다.

Python과 Ruby는 모두 JS보다 훨씬 무거운 언어라는 것을 이해해야 합니다.이것들은 표준 라이브러리, 언어 기능, 구조 면에서 훨씬 더 많은 것을 이해해야 합니다.객체 지향의 계급 체계만으로도 (좋은 방향으로) 상당한 무게가 더해진다.Javascript는 Lua와 같이 임베디드용으로 설계된 언어라고 생각합니다(많은 점에서 비슷합니다).Ruby와 Python은 훨씬 더 풍부한 기능을 가지고 있으며, 그 표현력은 대개 속도에 따른 대가를 치르게 된다.

핵심 Python 개발자들은 "충분히 빠른" 것으로 충분하다고 느끼며 프로그래머의 생산성을 높이는 기능이 컴퓨터의 코드 실행을 돕는 기능보다 더 중요하다고 생각하는 것으로 보인다.

Indeed, however, there was a (now abandoned) Google project, unladen-swallow, to produce a faster Python interpreter compatible with the standard interpreter. PyPy is another project that intends to produce a faster Python. There is also Psyco, the forerunner of PyPy, which can provide performance boosts to many Python scripts without changing out the whole interpreter, and Cython, which lets you write high-performance C libraries for Python using something very much like Python syntax.

Misleading question. V8 is a JIT (a just in time compiler) implementation of JavaScript and in its most popular non-browser implementation Node.js it is constructed around an event loop. CPython is not a JIT & not evented. But these exist in Python most commonly in the PyPy project - a CPython 2.7 (and soon to be 3.0+) compatible JIT. And there are loads of evented server libraries like Tornado for example. Real world tests exist between PyPy running Tornado vs Node.js and the performance differences are slight.

I just ran across this question and there is also a big technical reason for the performance difference that wasn't mentioned. Python has a very large ecosystem of powerful software extensions, but most of these extensions are written in C or other low-level languages for performance and are heavily tied to the CPython API.

There are lots of well-known techniques (JIT, modern garbage collector, etc) that could be used to speed up the CPython implementation but all would require substantial changes to the API, breaking most of the extensions in the process. CPython would be faster, but a lot of what makes Python so attractive (the extensive software stack) would be lost. Case in point, there are several faster Python implementations out there but they have little traction compared to CPython.

Because of different design priorities and use case goals I believe.

In general main purpose of scripting (a.k.a. dynamic) languages is to be a "glue" between calls of native functions. And these native functions shall a) cover most critical/frequently used areas and b) be as effective as possible.

Here is an example: jQuery sort causing iOS Safari to freeze The freeze there is caused by excessive use of get-by-selector calls. If get-by-selector would be implemented in native code and effectively it will be no such problem at all.

Consider ray-tracer demo that is frequently used demo for V8 demonstration. In Python world it can be implemented in native code as Python provides all facilities for native extensions. But in V8 realm (client side sandbox) you have no other options rather than making VM to be [sub]effective as possible. And so the only option see ray-tracer implementation there is by using script code.

So different priorities and motivations.

In Sciter I've made a test by implementing pretty much full jQurey core natively. On practical tasks like ScIDE (IDE made of HTML/CSS/Script) I believe such solution works significantly better then any VM optimizations.

As other people have mentioned, Python has a performant JIT compiler in the form of PyPy.

Making meaningful benchmarks is always subtle, but I happen to have a simple benchmark of K-means written in different languages - you can find it here. One of the constraints was that the various languages should all implement the same algorithm and should strive to be simple and idiomatic (as opposed to optimized for speed). I have written all the implementations, so I know I have not cheated, although I cannot claim for all languages that what I have written is idiomatic (I only have a passing knowledge of some of those).

I do not claim any definitive conclusion, but PyPy was among the fastest implementations I got, far better than Node. CPython, instead, was at the slowest end of the ranking.

The statement is not exactly true

Just like V8 is just an implementation for JS, CPython is just one implementation for Python. Pypy has performances matching V8's.

Also, there the problem of perceived performance : since V8 is natively non blocking, Web dev leads to more performant projects because you save the IO wait. And V8 is mainly used for dev Web where IO is key, so they compare it to similar projects. But you can use Python in many, many other areas than web dev. And you can even use C extensions for a lot of tasks, such as scientific computations or encryption, and crunch data with blazing perfs.

But on the web, most popular Python and Ruby projects are blocking. Python, especially, has the legacy of the synchronous WSGI standard, and frameworks like the famous Django are based on it.

You can write asynchronous Python (like with Twisted, Tornado, gevent or asyncio) or Ruby. But it's not done often. The best tools are still blocking.

However, they are some reasons for why the default implementations in Ruby and Python are not as speedy as V8.

Experience

Like Jörg W Mittag pointed out, the guys working on V8 are VM geniuses. Python is dev by a bunch a passionate people, very good in a lot of domains, but are not as specialized in VM tuning.

Resources

The Python Software foundation has very little money : less than 40k in a year to invest in Python. This is kinda crazy when you think big players such as Google, Facebook or Apple are all using Python, but it's the ugly truth : most work is done for free. The language that powers Youtube and existed before Java has been handcrafted by volunteers.

They are smart and dedicated volunteers, but when they identify they need more juice in a field, they can't ask for 300k to hire a top notch specialist for this area of expertise. They have to look around for somebody who would do it for free.

While this works, it means you have to be very a careful about your priorities. Hence, now we need to look at :

Objectives

Even with the latest modern features, writing Javascript is terrible. You have scoping issues, very few collections, terrible string and array manipulation, almost no stdlist apart from date, maths and regexes, and no syntactic sugar even for very common operations.

But in V8, you've got speed.

This is because, speed was the main objective for Google, since it's a bottleneck for page rendering in Chrome.

In Python, usability is the main objective. Because it's almost never the bottleneck on the project. The scarce resource here is developer time. It's optimized for the developer.

Because JavaScript implementations need not care about backwards compatibility of their bindings.

Until recently the only users of the JavaScript implementations have been web browsers. Due to security requirements, only the web browser vendors had the privilege to extend the functionality by writing bindings to the runtimes. Thus there was no need keep the C API of the bindings backwards compatible, it was permissible to request the web browser developers update their source code as the JavaScript runtimes evolved; they were working together anyways. Even V8, which was a latecomer to the game, and also lead by a very very experienced developer, have changed the API as it became better.

OTOH Ruby is used (mainly) on the server-side. Many popular ruby extensions are written as C bindings (consider an RDBMS driver). In other words, Ruby would have never succeeded without maintaining the compatibility.

Today, the difference still exist to some extent. Developers using node.js are complaining that it is hard to keep their native extensions backwards compatible, as V8 changes the API over time (and that is one of the reasons node.js has been forked). IIRC ruby is still taking a much more conservative approach in this respect.

V8 is fast due to the JIT, Crankshaft, the type inferencer and data-optimized code. Tagged pointers, NaN-tagging of doubles. And of course it does normal compiler optimizations in the middle.

The plain ruby, python and perl engines don't do neither of the those, just minor basic optimizations.

The only major vm which comes close is luajit, which doesn't even do type inference, constant folding, NaN-tagging nor integers, but uses similar small code and data structures, not as fat as the bad languages. And my prototype dynamic languages, potion and p2 have similar features as luajit, and outperform v8. With an optional type system, "gradual typing", you could easily outperform v8, as you can bypass crankshaft. See dart.

The known optimized backends, like pypy or jruby still suffer from various over-engineering techniques.

ReferenceURL : https://stackoverflow.com/questions/5168718/what-blocks-ruby-python-to-get-javascript-v8-speed