back
2 comments
Maybe he'll find some other language to make an order of magnitude faster.
Hoping he picks python :)
I think he has written about why Lua was so good for JIT compilation and in doing so talked about python. I don't remember specifically what he said, but he had analyzed other languages and there were hurdles that kept them from being able to achieve the same speed as LuaJIT.
Facebook have said in the past that PHPs weirdness made getting HHVM off the ground a lot of hard work, and Javascript JITs have struggled for generations to get bang-for-the-buck in the browser
Are there any available writeups or talks which discuss these challenges for HHVM? This sounds like it would be very interesting.
Yes. Lua is a very small and orthogonal language, so even tiny improvements in one part of it help most programs.

For example, if you've figured out a small increase in reading a value from a table, you have sped up all other data structures, OO code, etc., because the table is used for everything.

You can start from here http://lambda-the-ultimate.org/node/3851#comment-57805 or read the whole thread.
I'd like to see cPython without a GIL first. It would be really nice to take advantage of multi core CPUs without having to use subprocesses.
What's the disadvantage of subprocesses?
There are plenty, but here's an easy example: sockets. File descriptors are shared across process forks. So let's take a typical web application that does:

1. Boot, setting up system wide resources like DB/memcached connections

2. Start doing work

Then any process forked after step #1 is sharing those sockets and can accidentally corrupt the work that the parent process is doing. With threads, you can share the connections through a pool that can be simply mediated within the process.

Yeah, you can design around it. But with threads, you don't have to.

Here's another: serialisation. If you want to parallelise any processing that builds up any complex data structures, you have to serialise them between your parent/child processes which can make it hard to keep the "richness" of the objects like interdependencies between processing runs. In addition, now your processing bottleneck becomes how fast your single-threaded parent process can deserialise the responses (which in Python in particular can really be quite slow).

And not everything can be serialised. It's not trivial to share sockets with other processes that have already been started. You can't easily accept a connection in one process and pass it to another to do the work and send the response (it's possible, just not as easy as passing an integer around like you can do between threads).

You might find PyParallel interesting: http://pyparallel.org.
Are you talking about Python limitations? Because for 1) if you can put your sockets 'close on exec' no? For 2) how about using shared memory?
They cant share data as efficiently as threads because they don't share the same address space.
I got that working with PyParallel: http://pyparallel.org.
nah, ruby you folks have numpy and scipy already.
Whatever it is, I guess that he leaves the role because the compensation for it was in long term not appropriate for him.
Maybe, but after 10 years, maybe he just wants to spend his time doing something else.