Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
PHP compiler for JVM (github.com/dim-s)
115 points by tjomk on March 23, 2014 | hide | past | favorite | 24 comments


This is not the first attempt. This seems to be focused on extending PHP's performance and capabilities. Personally, I'm more interested in porting PHP applications away from PHP.

Caucho Resin offers 100% php compatibility on the JVM, so that you can host your entire app in a servlet container, and port features one by one. http://www.caucho.com/resin-3.1/doc/quercus.xtp

The PHP-to-Scala migration helper uses Resin/Quercus to provide the standard library to translate PHP to Scala. The output is a Scala codebase, so that you never have to touch the legacy PHP again. https://code.google.com/p/php-to-scala-migration-helper/


Are there any unbiased comparisons of Resin and other app servers? The only source for their claims of better performance is their own benchmark of serving what seem to be static files. [0] A discussion of it pointed out that the comparison is totally moot, since Resin caches 1k files (and thus outperforms Nginx for that metric), but otherwise is pretty similar for larger files. [1]

[0] http://www.slideshare.net/billdigman/resin-outperforms-nginx [1] https://www.ruby-forum.com/topic/4404987


Used Quercus (the actual php -> java bridge) years ago. I can't recall exact numbers, but generally was about 50-80% faster than the same php based site using a well tuned xcache install (ie, both avoiding the file load/compile).

Ran it using resin, tomcat, glass fish, and jboss. No real difference by app server.

That said, the biggest issue is always site design. Page too big, too many queries, too many assets loaded, etc. will not benefit much from Quercus or any similar technology.


We use Resin as the Java Servlet container for plain Servlet and most of the Servlet-derived frameworks in our benchmarks [1]. Incidentally, benchmarking static delivery of larger files on modern hardware is a bit uninteresting since it's relatively trivial to saturate gigabit Ethernet.

[1] http://www.techempower.com/benchmarks/


Caucho deserves to be its own post. Looks very interesting, I had no idea something like that was available.


looks great!Any php "optout" solution is valuable.Or sometimes you just want to run a quick CMS for a client;)

It's not clear though which PHP version it does support.


They don't support any specific PHP version outright, rather individual features (appropriately tagged with PHP version).


How does it compare to HipHop or fb's newest offering?


IIRC:

1. Normally, PHP becomes opcodes for the PHP interpreter to run.

2. Quercus takes PHP code and generates .java source files from it, which then run in the JVM like other Java code.

3. The earlier HipHop (HPHPc) compiles PHP to C++ source

4. The more-recently-released HipHop Virtual Machine (HHVM) is an alternative to PHP's typical interpreter.


See also: http://www.php-compiler.net/

  > Phalanger – full-featured PHP runtime & compiler for .NET/Mono 
  > frameworks. Phalanger is modern open-source implementation of PHP, 
  > compatible with the vast array of existing PHP code


It's nice to see some progress on the PHP Front, with this and HHVM. Though I'm not really a fan of PHP, it needs to be done, too much PHP code has been written.

I think the PHP guys themselves should push a bit more for a new runtime though. Otherwise they'd have to write an actual spec and declase theirs as "just" the reference implementation or something.


I believe there are preliminary plans to implement a JIT compiler for PHP 6. FB has certainly helped push changes being discussed into the ecosystem given their problems scaling PHP.


Nuno Lopes attempted this first using LLVM in 2008:

http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf

I think the cost of the garbage collection involved in a JVM implementation vs LLVM significantly outweigh any immediate perceived benefits, especially when you factor in double reference counting anomalies.


How does this deal with the load-all-discard-all-per-request approach of PHP? With everything in the JVM, does it keep eating up the memory on a per-request basis?

I don't know anything about language design or compiling something for JVM.


Does this use InvokeDynamic?



How about a PHP interpreter for erlang?

https://github.com/altenwald/ephp


Thanks for see the project, I'm under hard construction phase now with the system, at the moment it's not usable for OOP, only for functions ... but I'm on it.

If you want to follow the progress of the project, you can see this page:

https://github.com/altenwald/ephp/blob/master/doc/COMPATIBIL...

A very simple example is available in this gist:

https://gist.github.com/manuel-rubio/7949523

If you have suggestions, recommendations or questions, don't hesitate to do them to me :-)


Why JVM when you have HHVM?


I see they are offering the "Ability to use java libraries in PHP". But there aren't many Java libs that meet needs unfulfilled by PHP libs, that I know of. And you would have to cross languages to modify the Java libs.


> But there aren't many Java libs that meet needs unfulfilled by PHP libs

Only a bajillion bespoke enterprise apps full of Java-implemented business logic.


Business logic most likely is application code. Not library code.


You should perhaps lookup the following excellent Java libs which you could access natively: Elasticsearch, Hadoop, Cassandra, Zookeeper, Neo4J, Cascading... etc etc


It would certainly make migrating away from PHP easier, one library at a time.




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

Search: