Hacker News new | past | comments | ask | show | jobs | submit | ainsej's comments login

Improbable | Software Engineer | San Francisco, London | http://www.improbable.io

I'm an infrastructure engineer at Improbable. We're building SpatialOS, a distributed operating system that facilitates simulation on an unprecedented scale.

We recently raised a huge round lead by SoftBank which is allowing to push the boundaries of virtual world creation, which you can read more about on Wired (http://www.wired.co.uk/article/improbable-quest-to-build-the...)

I'm particularly interested in finding people who want to join our new engineering effectiveness team to build tools and define development practices for a rapidly growing organisation. If you're passionate about developer productivity, build systems and designing great APIs for internal usage, reach out to me.

A full list of roles is available at https://improbable.io/careers/opportunities If you're interested and want to chat more about Improbable feel free to contact me directly at ainsley@improbable.io


Improbable | Software Engineer | San Francisco, London | http://www.improbable.io

I'm an infrastructure engineer at Improbable. We're building SpatialOS, a distributed operating system that facilitates simulation on an unprecedented scale, allowing us to ask huge, "what if" questions of the real world.

Improbable is backed by A16Z and we recently announced our partnership with Google (https://techcrunch.com/2016/12/13/improbable-teams-with-goog...) so anyone can test out SpatialOS for free on Google Cloud.

In addition to a wide range of engineering roles in our rapidly growing London office, we just opened a new office in San Francisco in which we're looking to hire founding software engineers, community managers and product managers.

A full list of roles is available at https://improbable.io/careers/opportunities

If you're interested and want to chat more about Improbable feel free to contact me directly at ainsley@improbable.io


woosh


Nope, anybody who is legally allowed to work in the UK (so EU member states included)


KLEE is pretty cool. To compensate for the atrocious build instructions there's a docker image which contains KLEE built and ready to use (https://registry.hub.docker.com/u/kleeweb/klee/).

There's also a web interface to just play around with KLEE without having to download and install anything that a few other people and I worked on available at http://klee.doc.ic.ac.uk:55080/, which we open-sourced https://github.com/klee-web/klee-web.


Author here, and good point! I was struggling a bit with the terminology to use, didn't think of decorator factory, it definitely would have been a bit clearer.


I feel like when you remove a large portion of the dynamic features of PHP (references + global variables) you're now comparing different implementations of different languages, not different implementations of the same language.

HHVM is impressive largely because of the strides in performance despite PHP being an obnoxiously dynamic language, in the same way that V8 is impressive in the optimisations they're able to do on Javascript.

It's certainly a cool side project, but I don't think anyone is under the illusion that HHVM (or the official PHP interpreter) wouldn't be orders of magnitude faster if they didn't have to support the idiosyncrasies of PHP.


To get the best performance out of HHVM, you have to let it "warm up" (JIT the functions you're using), and compile the bytecode ahead of time. Otherwise it assumes you could include new files it hasn't seen before, and has to skip out on some optimizations to accommodate that. So he can't claim he's faster when he's running it like this: @exec('hhvm ' . __FILE__ . " $test");

It's also worth noting that Facebook is actually pursuing this same approach with Hack (making the language more optimizable). And they've tried the AOT approach, and it turned out to be a huge pain for several reasons.


Please look at the test script again. It does indeed warm up the JIT.

The timing results come from within HHVM. Basically, the test is dispatched within HHVM, isolating just the function call itself. It's then executed 5 times (timed independently) and then the bottom 2 executions are thrown away. See: https://gist.github.com/ircmaxell/8859d7f1bbee7b2f6e16#file-...

So the warm-up period happens. It's not just "benchmark `hhvm file.php`". The benchmark happens inside of HHVM.

So yes, JIT warmup is accounted for 100%. In fact, PHP, HHVM and Recki-CT all execute with the exact same pre-compile steps (parsing and any pre-compiling are ignored in the benchmark).

And their AOT approach that they tried was all-or-nothing. Meaning the entire code base had to be converted. This is a "compile what you want, and run the rest normally". In fact, this is 100% compatible with Hack and HHVM...


Caching is definitely a must have, both an external cache (Memcache, Redis) and tuning MySQL's own caches in the configuration, using InnoDB and MySQL means you can configure a large buffer in the MySQL config to speed things up considerably

Disk speed could also be a huge issue, especially on a VPS where resources are shared between many virtual machines, consider migrating your database off to a dedicated server (Preferably one with an SSD), depending on where you are in the world OVH might be a good choice.


Yii is an amazing Framework all-round, well documented and has a fairly active community.

I just finished my first Yii extension which can come in handy when mixing Yii URL creation and Javascript: https://github.com/Ainsleh/Yii-JSUrlManager


I wouldn't recommend sinking any money on AdWords just yet, not atleast until you have a site that's going to retain visitors. Focus on the product first


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: