On Thu, Sep 18, 2014 at 2:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
" and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. "
nope , you are close but you got it the other way around. As a smalltalker you see it from purist way of view. For you Python is that language that got caught up on too reliance on C/C++ libraries.
Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements.
What you see as side effect is actually the central goal of python. The central goal of python was and still is to a great extend today to serve as scripting language for C and C++ code. This what made python so successful that a C/C++ coder could use on top of its app embedded inside its app. This why so many people use it even today.
Nope. What you claim as a central goal of Python is merely a supine acceptance of massive failure to innovate. Bourne shell has been doing this for years and years. It's not a new thing. And GVR seems to have conceived it as a better shell. Well, that's not innovative; useful, yes, innovative no. But seriously, look at something innovative written in Python such as BitTorrent et al. How much of that is system calls, C or Python? t is basically Python an socket calls. C doesn't play a significant part in the architecture. The important thing is a dynamic OOPL being able to express a novel architecture. I'd wager that torrent clients are amongst the most popular Python apps. You also again wrong to assume that its a late thing that new VMs are
developed for Python , PyPy which is very well known inside the python community has been around more than 12 years. Its a very performant JIT VM 2-10 faster than cpython. Why cpython has not ported to it ? because of not so good support for C/C++ , zero support for cpython libraries and of course because as they say it would complicate the development of cpython quite a lot . Its that situation that only a couple of people can decypher the magic of the VM and the rest of developer only hope for the best.
By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages. And PyPy is not the only JIT VM for python , there is also Jython that runs
of JVM and ironpython that runs on .NET and Mono. What those 3 have in common ?that are used by a tiny crowd compared to people using cpython.
That could be because foreign VMs don't provide the support that users of a VM designed for a language expect, could it not? IMO this is a really important issue, especially for Smalltalk where we expect instance migration, contexts, etc, all of which one has to say goodbye to when hosted on a foreign VM. And this is a major reason for putting effort into one's own infrastructure. The truth is pure python libraries are a rarity . Why you think the most
popular , by far, implementation of python is called cpython ? I will give you a hint, 50% of its source code is written in C. No thats not just the VM its libraries and cpython comes with a lot of libraries included.
And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine. Frankly I dont believe that any VM ever however fast will ever beat smooth
integration of C/C++ code unless you have a huge company to back you up with an insane amount of libraries. Java had Sun , .NET has still Microsoft.
Seriously, what do you mean "beat"? The world is infinitely varied. COBOL is still important and yet you seem to portray the entire programming field as reducing to some kind of horse race. What's the content here? Also what's the intent behind pissing contests? Seems rather teenage. Whereas being positive, doing good engineering and innovating can invent the future. Seem much more fun than doling out endless negativity.
For people that speed is a serious matter even if a VM is a mere 30% slower than optimised C code, they will take the C code any day.
You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason). Speed is pretty meaningless unless you qualify it. In applications where performance can really matter theres always assembler (e.g. video decoders) or DSPs or... and often optimized C just doesn't hack it. But so what? There is another context where using Scheme to automatically generate Java VMs is critical to performance. And one can cite example after example where high performance does /not/ equal C/C++ plus an insane number of libraries. Computing is a broad church. There are plenty of contexts where time to market is the dominant factor and that can force one to reject performant and difficult to configure solutions (such as Jython, or Smalltalk + C), but equally there are contexts where time to market is the dominant factor and that can "force" one to use pure dynamic OOPLs because the world changes too fast to do anything else (e.g. finance). Anyway, keep those "nope"s coming. I love them. Time to patent your new way of proving a negative I think. -- best, Eliot