4 ms·

> I think the biggest reason Python is still slow is that there weren't such kind of investments comparable to those for JS jits (or dot Net). I think this is

> I think the biggest reason Python is still slow is that there weren't such kind of investments comparable to those for JS jits (or dot Net). I think this is spot on. Python, Ruby, and the JVM all originated in the 1990-95 timeframe, and all started out with while-loop/switch statement bytecode interpreters. Java had the commercial backing of Sun, who viewed it as a way to compete with Microsoft Windows and invested a lot of money into making Java faster. (HotSpot, etc.) As far as I know, lacking that kind of investment, the main Python and Ruby implementations are still interpreting bytecode 25 years later. .Net was a little bit different because by the time it came around, JIT was widely understood to be a useful thing, and Microsoft built the CLR with JIT as one of the founding principles. I also tend to believe that Emacs suffers the same sorts of problem. At it's core, Emacs is a Lisp implementation, and high-performance concurrent language implementations are expensive to build.

acqq 9y ago
Yes, some maybe forget, others were too young, but Firefox JavaScript implementation was actually unbelievably, awfully slow for any longer calculations before Google financed and published V8 (2008), e.g. in this benchmark from 2007: https://www.fourmilab.ch/fourmilog/archives/2007-09/000896.html https://www.fourmilab.ch/fourmilog/archives/2007-09/000896.h... The attitude before the public V8 outside of Google was "it's good enough as it is and it would be too hard to do anything about it." That JS was even slower than Ruby, which was some 30 times slower than C, at that time. Now the jitted JavaScript can run at least at about the speed of the non-optimized C, when doing calculations. Python is not so slow as that particular JS was then, but I see no technical reason that the speeds comparable to the current JS jits couldn't be reached.
- mschaef 9y ago
  Microsoft's original JavaScript implementation also had some interesting characteristics. Bear with me a moment as I describe why. Back in 1987, Bill Gates wrote an article for a Byte Magazine special edition in which he described a kind of system-wide scriptability as a next step beyond the simple macro languages common at that time. The general idea is that there would be a single 'macro language' that would have the ability to reach into and automate multiple different applications at the time. Maybe the easiest way to describe his vision from the article is to point to mid-90's VBA. Whatever else you can say about VBA, it represented the culmination of a strategy that Gates had been pushing for 10 years or more. I've always looked to that as an example of the value of long-term thinking in terms of technical strategy. (Even if I do rather dislike the result.) From the point of view of JavaScript, it's the technology that underpinned VBA's cross-application capabilities that's the most interesting. Sitting at the heart of OLE 2.0/ActiveX was the COM object model, and its late binding support in the form of IDispatch. Without going too far into the details, VBA was able to manipulate COM objects directly. But to do so meant it had to play by COM's rules - reference counting, specific supported data types, etc. Where JavaScript in the browser comes into the picture is that Microsoft's first JavaScript implementation was just another COM-compatible scripting language, and the IE 6 DOM was exposed as a set of COM objects. This meant that in addition to whatever slowness you had from the JavaScript interpreter, you also had to cope with the COM overhead involved in method calls to DOM objects, as well as the fact that DOM objects in IE6 were reference counted and not traditionally garbage collected. (I was involved in at least one mid-2000's-era project where we spent a bunch of time breaking cycles in DOM/COM object graphs to prevent memory leaks.) The 'upside' to this approach? Because the DOM was exposed via COM, you could also script your web pages in VBScript.... which was very much in keeping with Microsoft's vision and history, but almost nothing else. --- One other sidenote, while I'm wandering down memory lane. While OLE _2.0_ was the version that stuck, there was also an OLE _1.0_ that was totally different in implementation. Unlike OLE 2.0, which was based on an actual object model, OLE 1.0 was based on DDE (and shipped in Windows 3.1). DDE was the original MS Windows mechanism for dynamically sharing data across applications, and was heavily based on sending windowing messages from application to application (in the single shared address space common of the time.) IIRC, DDE 1.0 also had the ability to invoke macro commands in other applications, but it was not nearly as developed. (One of the initial challenges OLE 2.0 faced was that due to the fact it was branded so similarly to the radically inferior OLE 1.0, many people initially missed the value in COM.)

acqq 9y ago

Yes, some maybe forget, others were too young, but Firefox JavaScript implementation was actually unbelievably, awfully slow for any longer calculations before Google financed and published V8 (2008), e.g. in this benchmark from 2007: https://www.fourmilab.ch/fourmilog/archives/2007-09/000896.html https://www.fourmilab.ch/fourmilog/archives/2007-09/000896.h... The attitude before the public V8 outside of Google was "it's good enough as it is and it would be too hard to do anything about it." That JS was even slower than Ruby, which was some 30 times slower than C, at that time. Now the jitted JavaScript can run at least at about the speed of the non-optimized C, when doing calculations. Python is not so slow as that particular JS was then, but I see no technical reason that the speeds comparable to the current JS jits couldn't be reached.

mschaef 9y ago
Microsoft's original JavaScript implementation also had some interesting characteristics. Bear with me a moment as I describe why. Back in 1987, Bill Gates wrote an article for a Byte Magazine special edition in which he described a kind of system-wide scriptability as a next step beyond the simple macro languages common at that time. The general idea is that there would be a single 'macro language' that would have the ability to reach into and automate multiple different applications at the time. Maybe the easiest way to describe his vision from the article is to point to mid-90's VBA. Whatever else you can say about VBA, it represented the culmination of a strategy that Gates had been pushing for 10 years or more. I've always looked to that as an example of the value of long-term thinking in terms of technical strategy. (Even if I do rather dislike the result.) From the point of view of JavaScript, it's the technology that underpinned VBA's cross-application capabilities that's the most interesting. Sitting at the heart of OLE 2.0/ActiveX was the COM object model, and its late binding support in the form of IDispatch. Without going too far into the details, VBA was able to manipulate COM objects directly. But to do so meant it had to play by COM's rules - reference counting, specific supported data types, etc. Where JavaScript in the browser comes into the picture is that Microsoft's first JavaScript implementation was just another COM-compatible scripting language, and the IE 6 DOM was exposed as a set of COM objects. This meant that in addition to whatever slowness you had from the JavaScript interpreter, you also had to cope with the COM overhead involved in method calls to DOM objects, as well as the fact that DOM objects in IE6 were reference counted and not traditionally garbage collected. (I was involved in at least one mid-2000's-era project where we spent a bunch of time breaking cycles in DOM/COM object graphs to prevent memory leaks.) The 'upside' to this approach? Because the DOM was exposed via COM, you could also script your web pages in VBScript.... which was very much in keeping with Microsoft's vision and history, but almost nothing else. --- One other sidenote, while I'm wandering down memory lane. While OLE _2.0_ was the version that stuck, there was also an OLE _1.0_ that was totally different in implementation. Unlike OLE 2.0, which was based on an actual object model, OLE 1.0 was based on DDE (and shipped in Windows 3.1). DDE was the original MS Windows mechanism for dynamically sharing data across applications, and was heavily based on sending windowing messages from application to application (in the single shared address space common of the time.) IIRC, DDE 1.0 also had the ability to invoke macro commands in other applications, but it was not nearly as developed. (One of the initial challenges OLE 2.0 faced was that due to the fact it was branded so similarly to the radically inferior OLE 1.0, many people initially missed the value in COM.)