Unless I am missing something, the stuff you guys achieved have absolutely nothing to do with "self-hosting".
I am curious - how does this compare to pypy, performance wise? Is there a big win with this approach over pypy?
Unless I am missing something, the stuff you guys achieved have absolutely nothing to do with "self-hosting".
I am curious - how does this compare to pypy, performance wise? Is there a big win with this approach over pypy?
It basically means "able to host its own development". This means something different in different contexts, e.g. JS JITs "self-host" when some part of their builtin code is written in JS. We share that property with JS JITs, but in this particular case it means we can host our own build/test infrastructure. So we're using pyston to develop pyston. ergo, "self-hosting (qualified)."
---
We're definitely slower than pypy at present - we're only a small fraction faster than cpython after all on our benchmarks, and pypy is scary fast :)
I think we're still in the part of our work where the answer to the "big win with this approach" question is "we don't know." We're confident that we can/will be much faster than we are now, but we have different constraints than pypy, so it will always be something of an apples/oranges comparison.
On a related note, I have to say that I still don't understand the point of this project. Were you guys unhappy with pypy's performance or development?
I understand that in theory, the approach you guys are taking is incompatible with pypy's, but I can't help but wonder how thing would play out if you Dropbox put their weight behind PyPy. Maybe it could've been the start of every Python programmer's wet dream: Python 2.8.
To me it was totally misleading.
Check speed.pypy.org and speed.pyston.org