The other major issue is backwards compatibility. Ruby and Python have large API surfaces on both the C API and scripting language sides, with many libraries making use of obscure language features. If any single one of those features doesn't work, the library won't. Witness how tough the Python3 migration has been.
I talked with the Unladen Swallow guys sometime after the project was canceled. They said that the main issue was not getting Python to run fast on LLVM, where they said they had some really encouraging results. Instead, it was:
1. Bugs in LLVM which they had to spend a lot of engineering effort working around. This is probably much less of an issue now, with Clang, XCode, Julia, and Rust all being used in production with a good deal of success.
2. Compatibility with the C API. This was considered a "non-negotiable" for Unladen Swallow's design, and one major reason they started by forking CPython rather than building from scratch on LLVM. The problem is, the C API makes a lot of assumptions about how objects are laid out in memory, how they are memory-managed, how they are accessed, etc. If you must support defining & calling methods from C, there's a lot less freedom to, say, stick a trampoline in the method preamble or a PIC at the call site or switch to using a tagged representation of pointers and ints. That means that the VM has to fall back on the interpreter (and possibly waste cycles converting & marshalling data) for a lot of things that are supposed to be fast, which kills many of the real-world performance gains.
V8 had the luxury of defining its own C interface. I've often wondered whether a Python that gives up C extension compatibility could get similar speed gains - I even ran the idea by a former Python core team member who worked on my team at Google, and he said there was no theoretical reason why not. But then, Python without C extension compatibility would be Python without Numpy, Scipy, scikit-learn, PIL/Pillow, JSON, StringIO, and many other critical packages. At that point you might as well start over with a new language.
Speaking of C APIs, JRuby+Truffle is going all-out:
> Our new solution in JRuby+Truffle is pretty radical - we're going to interpret the C source code of your extension. We use the same high performance language implementation framework, Truffle, and dynamic compiler Graal, to implement C in the same way as we have implemented Ruby.
And it seems that even though their C implementation is not as fast as compiled code from, say, GCC would be, the mix of Ruby and C can run faster than using compiled C extensions from another Ruby implementation! This is due to cross-boundary optmization opportunities. Cool stuff!
I wonder if a Python JIT could do the same thing... Has anyone thought about this? It seems that since Dropbox's Pyston uses LLVM, it would be a perfect fit.
That would be pypy largely. From what I've seen it's got the biggest backing of the community and tends to be really fast computer to other interpreters.
A number of projects (e.g. this bcrypt package -- https://pypi.python.org/pypi/bcrypt) have switched from using CPython's API for C extensions, and switched to the cffi package (https://pypi.python.org/pypi/cffi), giving them what seems to be a much cleaner (and less CPython-specific) break between the C-level and the Python-level code.
I say "seems to be" because I'm not too familiar with the internals to know for sure :) What cffi did give them is that bcrypt (with it's C component) can be used by both CPython and PyPy -- even though PyPy doesn't support any of CPython's native C API.
Meaning that PyPy just has to support cffi, and is otherwise freed from any fixed C interface itself. I think the reason cffi gives it this freedom is that cffi provides Python-side metadata about the C datastructures being worked with through cffi, allowing the PyPy JIT to efficiently integrate that information into it's compilation process.
My guess is that this would still be a bottleneck in practice. LuaJit has a similar feature, and Mike Pall has said several times that if you care about performance, you're almost certainly better off using 100% Lua, because calling into C is slow.
Though, it seems much easier to work around for the implementation than the existing Python C API.
With LuaJIT calling C from the ffi is fast (from jitted code), just the traditional Lua C interface is slow. Lua code can be faster as it can optimise through the boundary of course.
>An afternoon to write, and then a year or more to work out all the bugs & corner-cases, write the documentation, and convince everyone to switch.
For a JSON parser? I think you overestimate the difficulty in implementing one. If anything, a parser for such a format is one of the easiest things to know you got correct -- there are extensive test suites.
As for switching to it, Python users already use several JSON libs anyway, so it's not like adopting another would be any great deal.
For the other libs, like numpy etc, yes, it would be more effort, but nothing unsurmountable. And speed is a far greater hook to get users to adopt that version of Python than "we now got unicode all over and fixed a couple more annoyances".
Judging by how slowly projects (especially ones that depend on the C API) have moved from Python2 to Python3, I think you're underestimating the effort required.
Maybe money and promises of better performance would solve that problem, too.
The code backing things like Numpy and Scipy is not small, has been well optimised over many years, and would be extremely difficult to reimplement at speed even with a faster Python. The freedom high level languages give tends to prevent many low level optimisations that are really useful for big maths and data routines.
For the language I work on we were able to write macros and functions to allow our C libraries to continue to work when we changed our VM, but we've spent considerable effort optimising things so the C has to reach back into objects as little as possible, and we could only do this because recompilation and refactoring was okay.
"The code backing things like Numpy and Scipy is not small, has been well optimised over many years, and would be extremely difficult to reimplement at speed even with a faster Python."
I assume you're unaware of the numpypy project then, which is doing exactly that, with reasonable results.
I also think you overestimate the performance of numpy/scipy when compared to, for instance, C++ template-based libraries which are able to make large performance gains from compiling specializations for the specific array shapes being used. JITs can potentially go further, being able to compile specializations in places where array shapes are not known at compile-time.
They are rewriting BLAS in Python? Seriously? Links please.
You may not be aware that NumPy does it's heavy lifting by offloading the work to C and FORTRAN, and that's where the speed comes from. You set up your data in Python, use the nice high level language to parse files, etc, then you pass chunks of memory containing matrices off to the FORTRAN to crunch, then use Python again to say write it back to a file.
Yes to the basic point, but note that (specifically) if you use BLAS in Fortran, you're typically losing a factor of several in speed, I'm sorry to say. Competitive serial numerical kernels typically still end up needing assembler (e.g. OpenBLAS, FFTW, ELPA).
I'm not sure why Fortran wouldn't be considered a high level language, if that's the implication (and it hasn't been SHOUTED since the 70s).
Somebody has to actually write the new functionality, and then many more people have to learn the new functionality.
Anyway, this thought experiment has basically been done. "Ditch the backwards compatibility, start with a new language, make it fast by design, and rewrite all the packages that make it super popular." It's called Julia. And it's popular among some people, but for a lot of others, the maturity of the Python ecosystem still makes it a lot more attractive despite the performance & multi-language issues.
I believe that Julia still uses a lot of C/FORTRAN packages that numpy relies on, like BLAS, so they're not really re-written in Julia (at least yet?).
I think he meant re-do the bindings. A lot of Julia is written in itself, but not things like that. Large libraries benefit from Julia's extremely simple C calling mechanisms.
Julia is incredible, but I worry about its future because, unlike some other promising-but-not-quite-mature languages like Go or Rust, Julia doesn't have any kind of corporate or organizational patron promoting it and investing big money in it.
AFAIK, it doesn't have any kind of official institutional backing from MIT. Some of the creators are MIT faculty, but I don't think that makes it "An MIT Project" in the way that Go is a Google Project.
That might be true, but I think they're also targeting some of the R / NumPy market. Those are both pretty mature, and it could be hard to make inroads.
Definitely. My (indirect) point was that scientific computing is a much less competitive area than Go and Rust are targeting. And I can imagine a world where NumPy, R, and Julia are all strong projects.
Arguably, lack of commercial support is a bigger problem for mature projects than young projects. Whether or not Julia pulls away users from R probably has more to do with how much R adapts to new directions in statistics than with anything Julia does (assuming that julia passes a minimum threshold of credibility, which it probably doesn't yet for most statisticians.) A lot of my interest in julia comes from a specific simulation that I need to run to prototype a new estimator that would be infeasible in straight R. If R were faster, I wouldn't bother.... (To preempt the obvious reply, I could always write the slow part in C. But if I need to introduce a different language anyway, why not look at other options?)
Re-implementing matrix math, image processing, signal processing, statistics, scientific mathematics and a much much more is a daunting task. Not impossible, but a lot of work.
> Ironically, Python w/o c extensions is what you get to use on Google App Engine and it works quite nicely for many purposes.
That is not quite correct. While you can't add your own C-extensions, some popular extensions that aren't pure Python are included in the provided platform (including, particularly, numpy.)
Can this logic be applied to another environment that has had a ton of money poured into it? Specifically, .NET. Can you replace Ruby/Python in the question with C# and if so, why doesn't the latter benefit from money and experienced developers?
You can spend money on performance or on features.
Google has historically been good at high performance computing, and chose to spend enough money to get and fund a team of experts on building high performance VMs.
Microsoft has historically been good at adding backwards compatible feature sets, and chose to spend enough money to get and fund a team of experts on tasteful design and evolution of programming languages.
The Python 3 migration hasn't been tough, it was just subjected to a political campaign. That kind of risk can only be controlled by never changing anything.
Put on hold as too broad by rene, davidism, vaultah, Sam, iCodez 2 hours ago
There are either too many possible answers, or good answers
would be too long for this format. Please add details to
narrow the answer set or to isolate an issue that can be
answered in a few paragraphs.
If this question can be reworded to fit the rules in the
help center, please edit the question or leave a comment.
Meta: It's interesting that 5 users thought that it would benefit the SO community to put this question on hold, while 100+ thought it was an interesting question. In one way, SO does keep the noise down pretty well, but this doesn't feel to me like noise. Does avoiding questions like these actually make SO a better place? Is there a reworded version of this question that would actually elicit better responses? Or is this just the joy of playing the enforcer?
I'm not a moderator, but I agree that the question is not really constructive in the scope of what stack overflow is supposed to do: answer questions to specific problems. The question itself is interesting as are the answers, and the whole discussion around it is great, but it doesn't belong on that site.
Why is python not as fast as JavaScript is a completely different question than "An internal error occurred during updating maven project". The later seeks a solution to a problem while the former only encourages discussion but is impossible to solve (because it's not a solvable question).
So, I feel this question was appropriately tagged, or perhaps even not aggressively enough.
I asked this question because I was a little bit frustrated with one page in my app which rendered in 800ms. 100ms was db time, the rest it was Ruby.
Sure, the answers won't help to solve my _specific_ problem. However in general I like to known how things work. It is not enough for me to read ordinary info about Ruby symbols. I have to read Ruby source code to understand them better (1) Thanks to this I understand Ruby symbols gc issue, a new feature of Ruby 2.2
Even more important is _intuition_ one can build reading the answers. Intuition about languages in general. I really like duck typing languages. Sometimes I need raw performance. So should I plan migration to statically typed languages (Java, Scala)? Or is it better to invest my time into learning Dart? Does Dart have _potential_ to solve my specific requirements?
As a software architect I have to predict a future a bit. And I must say that nostrademons answer helped me to learn something new today.
If you're going to move to a static language, I'd recommend Go over Java or Scala. Especially if you like duck typing (it has a static flavor of duck typing). I haven't used it for anything nontrivial (you can pry C from my cold, dead hands), but it looks like it solves the problems in its domain exceedingly well.
Regarding Dart: It looks nice. At work I'm forced to work in JS sometimes (I work at a game company that does contracting, and lately clients have started needing/wanting HTML5), and my opinion is that Dart looks better than it in every meaningful way. I've also begun to get the impression that Google has moved most of the V8 engineers over to Dart, but I don't have any hard evidence for this.
Honestly without knowing your problem, it's impossible to say whether or not either of these would solve it. My guess is that either of them could, as they're both languages that are orders of magnitude faster than Ruby and both seem to have large, fully featured standard libraries.
> the scope of what stack overflow is supposed to do: answer questions to specific problems
Honestly people should read the manual then. That will give you the specific answer to your question. Stackoverflow wanted to replace other message/discussion boards in regards to programming. It's veered away from that purpose and IMHO has become cumbersome to use. If you have to worry more about how you word your question than the question itself is it worth asking there?
The way I've always thought about and used StackOverflow is as a replacement for manuals, tutorials, and bug fixes—not at all a replacement for message boards or forums.
I think SO is starting the get the same problem that Wikipedia has been wrestling with - editor/moderator cliques. It may be a classic bureaucracy issue - on one hand they raise the quality bar by providing a higher level of consistency. On the other hand, they may drift from what might be considered reasonable from the point of view of more and more people outside the circle...
The theory of universal deletionism states that sites with extensive volunteer moderators will invariably tend towards bureaucracy and deletionism regardless of what regular users want as mods get bored and want to feel important
You should see how excited the moderators get when they decide there's a new rule against some new kind of question
SO was supposed to mitigate this effect by making people earn their mod rights. So you only get to call other people's questions off-topic if you have a track record of contributing to the site content yourself.
I would say it's the latter. A majority of questions that I've found on SO that helped me solve a problem or answer a question have been marked as non-constructive. I don't know why people would do that from a logical perspective, but I can see how having the ability to moderate discussion would make one overzealous with this sort of thing.
It's not 5 v 100, you have to be at a certain threshold of points to vote to close a question.
I don't agree with closing questions like this either, but there are rules, those rules work most of the time and the question is broad. SO is not a Quora, it's not a discussion site, even though it would be nice to use the brain trust of SO in that way.
I think that comes from the sheer number of developers who don't understand, and haven't taken the time to actually read up on, or learn JS, using jQuery to hack together a usually working solution and then asking on SO when they hit a wall.
It speaks more to the popularity of jQuery and the use of JS by those inexperienced with it than a specific signal/noise issue.
The public domain CMUCL/SBCL line of compilers (as well as most commercial common lisps) are notorious for being the fastest dynamic/interactive systems since the 1990's. Most dynamic languages are still nowhere near the speed of the assembly code produced by most common lisp compilers while still retaining the impressive dynamic & incremental aspect of the language (although every year they are closing in). In the end, it comes down to how much effort was put into these compilers, rather than the language itself. For years DARPA spent loads of money on a highly trained team of compiler experts to work on CMUCL (later SBCL) led by Scott Fahlman. I doubt Ruby and Python will be able to attain JS speed until more effort goes into on these systems, which so far are still defined by a canonical, byte-code interpreted implementation.
Isn't finding what function to call at a particular function call much easier in Lisp (or Julia) than it is in Python/Ruby/JS? The vast numbers of CL and Scheme compilers are relatively easy to write, exactly because the languages leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.
Definitely not. It's almost hard to think of what Lisp doesn't let you change at runtime, since the compiler is always there. Common Lisp is in fact much more dynamic at run time than python/ruby/smalltalk. I would say that Python and Ruby are the more limited ones. You can recompile functions whenever in CL, you can even compile functions that call undefined functions at runtime. Lisp is known for its extreme late binding and reflection, with almost everything redefine-able on the fly (except functions declared inline, you need to recompile to callers afterwards. but only if you declare them inline). Even in defining classes, Common Lisp will redefine a class and update all the _old_ instances of the class as well. As far as I know, Ruby and Python do not automatically update old instances. Ruby, like Common Lisp, does allow you to add new methods at runtime without redefining the entire class, and as far as I know python does not.
> The vast numbers of CL and Scheme compilers are relatively easy to write, exactly because the languages leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.
I would say it's a mistake to conflate Scheme and Common Lisp. Scheme isn't even defined well enough to say something implementation independently about whether the environments should decide things at runtime or not. But Common Lisp as a language has special/dynamically scoped variables and runtime definable macros which make it much more difficult to write a compiler for it. I would say that Common Lisp has way more things to decide at runtime than python or ruby. Maybe they're about the same in terms of difficulty of writing a compiler for, if only because lisp has no parsing/lexing pass. Again, in the end, it's mostly not a language issue. It's how much money and how many compiler experts work on your implementation.
SBCL targets x86, alpha, ARM, x86-64, and PPC in fact. Python doesn't actually target C, it targets a bytecode VM that's interpreted by C. which obviously is much easier to do. (there are many CL implmentations that use this approach as well eg ECL CLISP...) It just doesn't seem like Ruby or Python has the sophistication/resources yet to move their main implementations to native code, aggressively optimized compilers (yet). Which is unfortunate considering CL, Dylan and small talk got there first 30 years ago.
If the difference in speed comes down to money, as the first two answers suggest, then why is LuaJIT even faster than V8? I'm pretty sure PyPy has had far more money invested in it than LuaJIT has.
Lua itself is much faster then Python or Ruby. Both languages look, as if the author did read 'A little Smalltalk' by Timothy Budd, though that its easy to design a new language, and repeated all errors(simplifications) out of the book.
I dont know the main problem of Ruby, but I would point to the garbage collector for Python, as a ref counting GC is required for finalization, and ref counting is slow as hell. Python after 2.0 therefore required two slow GCs. The old ref counting GC, that slows down every object access, and in addition a simple stop the world GC to clean up cyclic references.
My understanding is that LuaJIT isn't really under active development anymore.
It does seem like it would be hard to add the 5.3 features to LuaJIT without compromising on efficiency, but given how clever Mike Pall is, I'd suspect it can be done.
It is under active development. There is the start of an arm64 port recently for example. Mike did take a break to do other stuff for a bit it seems, but its not stopped.
When Ruby or Python is too slow you can switch to something else. When JavaScript is too slow you have to either pay someone to make your code faster or pay someone to make the browser faster.
It mostly did before V8 was created. A few people ran JS outside the browser using Mozilla's Rhino, but it wasn't very common. Nodejs probably was the first widely adopted platform for non-browser JS, and it was built on V8 after V8 already existed. So I believe historically server-side JS did not drive JS performance.
It should be mentioned that Microsoft has had server side Javascript (well, Jscript) running on IIS since 1997. I used to write data driven websites in it.
1) Python & Ruby have lots of dependencies on the C FFI — PyPy is great, but not replacing CPython because of this.
2) A huge amount of effort is going into v8. Perhaps that level of effort will catch up to the effort put into the JVM.
3) Using esoteric, hard to optimize features in Python and Ruby is apparently a sign of cleverness. And those features are used in the major frameworks like RoR.
4) Incompatibility between other engines. Right now though you have to be backwards compatible with the web, it is acceptable to implement a small subset of the new features. People wouldn't be happy with several versions of Java / Python / Ruby all implementing some of the new features but not all of them.
But really, besides a highly optimized regex engine, v8 is still kind of slow. Just happens to be the fastest of the slow.
For context: this question was asked in '11. PyPy is really really fast now. I'm not sure exactly how it stacks up against v8, but it definitely holds its own. It's roughly 7 times faster than cpython.
True, but you could say the same thing about almost any JIT compiler/interpreter for a garbage collected language. It's not like java is known for it's memory efficiency. I'm not too knowledgeable about the memory efficiency of v8, I imagine they pay attention since it's in a browser, but I'm going to guess compared to a simple interpreter it's probably not great.
That is of course true, but pypy does have an unusually large memory burden (and the developers do know about it - it's just not top priority at the moment).
Also, JavaScript has a much smaller API surface area. In addition to optimizing core code execution, a decent amount of work goes into optimizing the core libraries and built-in types: RegExps, string operations, collections, hashes, etc.
In JavaScript, that set of stuff is pretty small. In Ruby and Python, it's enormous.
What is V8 speed? Without actually quantifying anything this is all just bull shitting. For all I know V8 is slower and they are asking why python and ruby aren't as slow as V8.
Secondly, if we assume the question is saying that V8 is faster, is it faster than vectorized numpy functions? Without specifics in mind, this question is just to start a language war.
Its more deep grained that "the VM is slow" The default python interpreter is really quite fast, but biggest performance problem with python is that everything is an object.
From the accepted answer: "Given that at least IronRuby, JRuby, MagLev, MacRuby and Rubinius have either monomorphic (IronRuby) or polymorphic inline caching, the answer is obviously no."
A lot of those guys know enough to write several books. Unfortunately, most of them don't seem to enjoy writing things for humans to read as much as they enjoy hacking on VMs. :(
Would the dart VM be the place to start? It's the newest and I saw a presentation somewhere where it looked like part of what motivated them to create it was having to deal with so many edge cases in JavaScript. I imagine the source of V8 is probably not going to be that easy to pick up.
Why do we need so many different VMs anyway? Is it it just history and politics? Are, e.g. Python and Ruby so different that, if implementing from scratch today it would make sense for each of them to have its own VM? What about the CLR vs the JVM: are their respective functions so different that it would make sense for both of them to exist if not for the need for Oracle and Microsoft to maintain mutual incompatibility?
I would pay three times as much for a book by Mike Pall. With all due respect to Lars Bak (and I have utmost respect), Mike Pall has done a lot more with about 1% of the resources.
We sponsor Matz, Nobu, and Koichi. Of them Koichi works pretty much full time on speed. He implemented partial generational GC in Ruby 2.1 and incremental GC in 2.2. He also implemented faster keyword arguments https://bugs.ruby-lang.org/issues/10440.
There's actually been a bunch of great performance increases in the past few years in addition to the GC. Optimized method cache invalidation by the late James Golick, frozen string pool for hash keys by tmm1, using vfork instead of fork, etc, copy on write GC. There's also new features, like Ruby's ability to GC symbols that let developers use symbols in more places and spend less time converting back and forth between strings.
So yes, money is a factor. Having employees work on it full time helps. Despite only having 3 full time employees Ruby has made some pretty impressive improvements recently.
But basic knowledge of fast VMs would also help. Maybe get an engineer from a good school?
E.g. a decent GC would help ruby a lot, i.e. Cheney Copying Collector with thread support. Ruby is used on devices with lots of RAM and big cache lines.
Or optimized data structures (nan-tagging, better tagging) and slimmed down ops.
I need 32bit per op plus 2 args. Check out how much more ops fit into your cache line then.
The ruby hash table implementation also sucks. Write a good one. Study the literature. It's basic engineering, you don't need to be a genius, really.
And embrace types, either optional or inferenced. Optimize on type information.
I'm not so sure it's all about money. Ruby and Python are significantly more complex languages than Javascript. By contrast, LuaJIT can absolutely wreck V8 performance-wise, but Lua is a substantially less complex language.
v8 doesn't really do multithreading, for example, so it's able to take a lot of shortcuts that save a lot of time. v8 doesn't have built-in Bignum support, and doesn't support non-UTF-16 character encodings, so there is a lot of work that it doesn't have to do, where more full-featured languages have to make sanity checks and do conversions under the hood frequently. Ruby's metaprogramming constructs are extremely powerful, but their rulesets are fairly complex, so the VM has a lot of bookkeeping to do to ensure that everything works well. I don't know Python's internals that well, but I do know that Ruby spends a lot of time making sure that all those things play nicely together without the programmer having to exert much effort, and that does incur a performance penalty.
v8 is an absolutely excellent piece of engineering, but it's a tool that occupies a slightly different problem space than the Ruby and Python VMs do. That's not to say that Ruby and Python don't have gains they can and should make, but that it's not as simple as pouring money in one end and watching performance come out.
If you can provide modern numbers, I'd appreciate it!
Maybe my information is out of date, but I just now picked a random benchmark (the fasta one from the language shootout) and ran it against v8-3.14.5.10 and luajit-2.0.3 (Fedora 21, latest available via yum), and luajit came out quite a bit ahead. I grant that it's a really naive benchmark setup and shouldn't be taken seriously, but my investment here is pretty minimal :)
$ time luajit-2.0.3 fasta.lua 25000000 > /dev/null
luajit-2.0.3 fasta.lua 25000000 > /dev/null 8.60s user 0.01s system 100% cpu 8.613 total
$ time d8 --nodebugger fasta.js > /dev/null -- 25000000
d8 --nodebugger fasta.js -- 25000000 > /dev/null 12.80s user 0.51s system 100% cpu 13.209 total
Heck, even with these data 12.80s vs 8.60s is not "wreck".
Those are in the same order of magnitude even! Not even 2x the speed. Hardly makes a difference in picking one or the other, all other things being the same.
Now, compare V8 or LuaJit with Python or Ruby -- that would be "wrecking it".
You've missed my point; LuaJIT can be quite a bit faster than v8, despite the amount of money being invested in it being a tiny fraction of what's put into v8. Therefore, we can conclude that v8's speed is not simply a function of money, but that there may be other variables involved, such as "complexity of language".
I'm not attacking v8 here. I'm simply pointing out that there are VMs for interpreted languages which run faster than v8, which isn't to say "v8 is bad", but rather "different languages inherently have different performance profiles".
That "another microbenchmark" seems to have some unnecessary overhead vs the Lua one? I don't like it. The Language shootout is better: let anybody implement the task anyway he likes, so long the results are the same, and compare that.
It supports it as a language construct, even though the GIL gets in the way of actual parallelism. As far as I'm aware, EMCAScript doesn't provide any concept of threading within the language itself. You can get it by spinning up multiple separate VMs in separate threads and passing messages back and forth (which is what web workers are), but that's a function of how the VM is presented in the context of a larger application, not a feature of the language itself. Jython and JRuby don't have GILs and are able to achieve full parallelism using the same language constructs that CPython and MRI use.
I don't think you can even achieve that kind of concurrency (multiple seperate VMs in seperate threads running in parallel) with Python, though. As I understand it the GIL really is global - it's shared across every single VM in every thread within the current process, at least in the CPython 2.x series, and that's not easy to fix because it's protecting global shared state.
If they're running separate VMs then your threads aren't really threaded in any meaningful sense; you could equally well run those VMs in separate processes (shared-memory communication between distinct processes is not completely trivial but it's very much doable).
Last I looked, you are correct, but Python isn't designed as an embeddable language, either. Multiple VMs usually isn't something you'd have any desire to do specifically because you can achieve multithreading from within the language itself.
If you need multiple, separate VMs (ie, to drive multiple isolated scripting engines in a game), then v8 isolates or Lua contexts will do you just fine, but that's a different use case than most places where you'd want to use concurrent Python.
Python totally is designed as an embeddable language; that's why there's a giant section called "Embedding Python in Another Application" in the reference manual:
It's just that at the time Python was created, multithreading was not something you generally did in a C program. The POSIX thread standard didn't come out until 1996. Python was started in 1989, first released in 1991, and reached 1.0 in 1994. Common rules of thumb for dealing with multithreaded programs (eg. "Avoid global or static data") didn't really become popularized until the 2000s, and many programmers in less well-informed circles still don't know them.
It does seem strange to me that so few people are paid to work full time on ruby etc (core tech) when you consider the massive total benefit from making ruby a few % faster or better. Why is the funding not there?
I think there are a few issues. The first is funding. If you are an engineering manager and trying to ship product, you don't want a 25% faster Ruby VM in 10 years, you want someone to benchmark and optimize existing code in existing products 25% today. I agree that it's a good pay off, cost versus benefit...however the benefit is spread around hundreds and thousands of companies. Google gains marketshare for chrome when V8 gets faster, there's very few companies that get significant advantage explicitly from making Ruby faster for everyone. If you're paying to make Ruby faster, it's also getting faster for your competitors too (if they use Ruby).
There are a bunch of core contributors that are very active. Several of their companies allow them to spend time contributing (most of them are from Japan). Another example is Aaron, he is on Ruby core and his company allows him some time to contribute to open source, so this is sponsorship in a way. I while a company stands to benefit from sponsoring a full time developer, they benefit just as much if someone else sponsors a full time developer. Right now there's not enough companies with either a business incentive, altruism, or interest. Perhaps there are companies out there interested in sponsoring full time devs who just don't know how (and to your point cannot find them) but I think that would be the minority case.
Oracle seems to spend some money on java and JRuby which is pretty fast and will get even faster the coming years. Not sure how much if any they are directly funding JRuby but they are funding the JVM which is used by JRuby.
I'm guessing that people like Lars Bak are hard to come by. I remember reading somewhere that Google opened the Aarhus office mostly because he didn't want to move to Mountain View (I might be misremembering so don't quote me on that).
It would be very cool to start a crowdfund-esque campaign that also encourages corporate sponsors to build a fund to hire fulltime developers and create an agenda devoted to performance.
It is a pity that V8 is so entangled with the language Javascript.
In my opinion, V8 would have been much more powerful if it was fully parameterizable in all the types that it supports, etc. In that case Python could simply be translated into V8 intermediate code (or javascript).
The .Net DLR is like that, although I was disappointed when they dropped Dynamic JScript... more so when they effectively dropped continued DLR support altogether, it was a nice runtime. Maybe with Rosilyn some open support for dynamic languages will come back.
Personally I've been working with JavaScript since the mid 90's, and node.js since very early on. I like JS more than most as it's my favorite language, for all its' warts. I do feel that for most work loads a modular dynamic language implementation for a given task is a better idea than building a compiled version. If you need more performance from something, or it's something relatively obvious (A/V processing comes to mind) it's similar to a premature optimization to go compiled first these days.
Kind of more than you are/were looking for.. but you may want to look into IronRuby/IronPython ... it's a pretty nice way of working with the languages.
I'm not sure what "full fat" means, but compared with current gfortran in my experience, ifort is incorrect by default, surprisingly unreliable, and typically generates similar speed code at the 10% level. My all-free software build of a quantum chemistry program was reported to run faster than an all-Intel libraries one on a cluster which has faster processors but is otherwise very similar to ours.
If you just write in Fortran, you don't have to have to debug two versions.
Thanks. Brython looks more like what I was looking for. Everyone's porting code into Javascript but I think a better browser can be built with more language support.
Crazy thing is, Ruby is already so much more powerful than Javascript. Javascript is fast, easy to implement and relatively easy to learn - but it is so limited.
As a programming language, Ruby really pushes the limits of what we are used to.
The thing is though, if you have a super performance-critical bit that you can't make fast in Ruby, you can still drop down to C if you really have much to gain. For a lot of what it gets used for, though (system scripting, web apps, automation), it's fast enough that the language niceties trump raw speed.
Ah the hot spot fallacy. I don't mean that Ruby / Python don't have their place, I'm using a lot of Python myself. However, the notion that you could always just reimplement a few places here and there in C is mostly false IMO. In these cases where the interpreter itself is the bottleneck (as opposed to I/O), you'll often find that the performance is spread out over dozens or hundreds of sections in your code - for non trivial projects. When that happens and you really need an order of magnitude or more speedup, you basically have to reimplement.
What I want to say is: In many cases starting with a scripting language makes sense, just to get a working prototype quickly, but when you know beforehand that performance is critical, don't overestimate the ability to just patch it up later. The whole 'premature optimization' viewpoint should (if at all) only be applied up to a certain experience level, after which it's rather damaging than doing any good.
It would only be a "fallacy" if it were literally not possible to optimize using C extensions. It has been done, many times, for many real jobs. There is no fallacy.
Did I write that it's impossible? Of course you can always reimplement code with C extensions. The fallacy I was talking about is the assumption that it will be limited to a few hotspots. For non-trivial work it's either not true or if it's true it can hardly be shown before starting the implementation with high certainty - meaning that you don't know whether the faster time to get a working prototype won't be offset by a longer period of optimization (and possibly less maintainable code, because you now have two layers interacting with each other, with the interface being boundaries between performant and non-performant code, instead of logical ones). All I'm saying is that one should think a bit further ahead when choosing the implementation language / frameworks / persistency layer - how important is performance (e.g. how many requests per seconds do you want to serve per node)? How important is it to have a working prototype quickly? How important is fault tolerance? How much computation are you doing anyway, rather than doing I/O bound ops? Depending on these answers, the solution could be python/ruby, or Erlang, but it could also be java/scala or even C/Fortran. Always going the dynamic language route first might hold up in 95% of cases, but the remaining 5% could hurt a lot (or be a big missed opportunity of doing something with high impact, because these 5% of cases are often not touched by most programmers).
That's nice but somewhat irrelevant. The discussion is about how to make Python or Ruby fast, your solution is basically "just rewrite it in C, lol". It's a workaround but ideally you should not have to do that.
There are always touchy Lisp and Smalltalk fans who must vent their spleens at the earliest opportunity, but barely a sliver of active developers today have used a Smalltalk system and only marginally more, even with Clojure, have used a Lisp in anger. So, when you are not actively trying to read the literal worst into something, you will see that Ruby does in fact do quite a lot that "we," in the general case, are not terribly used to. That's a major reason I use it, for example, where performance isn't a big deal.
Ruby is popular because it's powerful and expressive in a way that many other environments are not. 'Power' isn't everything - ability to easily use it is equally important. Hell, it's a direct spiritual descendent of Smalltalk to a greater degree than any other popular language!
The performance of Ruby caused by the extensiveness of its dynamism had definitely been one of the downsides of the language, and the fact that newer languages place more emphasis on that while learning from Ruby is great - it's how the field evolves!
It has always been this way. Two decades ago ASM was fast but limited; BASIC was expressive but slow. Today, JavaScript is fast but limited; Ruby is expressive but slow. What a wonderful transition; it means our fast language du jour is growing more and more expressive. Another two decades of compiler and optimization research and we may yet have fast languages that are so expressive they negate the need for anything more powerful.
have you guys actually tried anything else than serving web requests with node...because for any other backend procedure node is not faster....and definitely the code is not cleaner!
Check also atom vs sublime text as desktop applications...
I talked with the Unladen Swallow guys sometime after the project was canceled. They said that the main issue was not getting Python to run fast on LLVM, where they said they had some really encouraging results. Instead, it was:
1. Bugs in LLVM which they had to spend a lot of engineering effort working around. This is probably much less of an issue now, with Clang, XCode, Julia, and Rust all being used in production with a good deal of success.
2. Compatibility with the C API. This was considered a "non-negotiable" for Unladen Swallow's design, and one major reason they started by forking CPython rather than building from scratch on LLVM. The problem is, the C API makes a lot of assumptions about how objects are laid out in memory, how they are memory-managed, how they are accessed, etc. If you must support defining & calling methods from C, there's a lot less freedom to, say, stick a trampoline in the method preamble or a PIC at the call site or switch to using a tagged representation of pointers and ints. That means that the VM has to fall back on the interpreter (and possibly waste cycles converting & marshalling data) for a lot of things that are supposed to be fast, which kills many of the real-world performance gains.
V8 had the luxury of defining its own C interface. I've often wondered whether a Python that gives up C extension compatibility could get similar speed gains - I even ran the idea by a former Python core team member who worked on my team at Google, and he said there was no theoretical reason why not. But then, Python without C extension compatibility would be Python without Numpy, Scipy, scikit-learn, PIL/Pillow, JSON, StringIO, and many other critical packages. At that point you might as well start over with a new language.