Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

On the Sankuru blog there's a recent post looking at the construction of a simple bytecode compiler with a virtual machine as written in PHP (for Expression Language).

In my previous blog posts, I demonstrated how we can use the builtin PCRE library, to create a lexer in Php. I also showed how to use Bison-generated LALR1 parser tables in Php. In this blog post, I will re-use these lexing and parsing facilities to compile EL programs from within Php.

He uses his lexer/parser (available for download) in an example program that outputs some values and does some simple mathematical operations. There's sections detailing the Bison grammar used, execution stacks, callbacks and the bytecode it produces.

Brandon Savage has posted a response to a recent set of benchmarks as run comparing ASP.NET and PHP's processing speeds.

But benchmarks, for all their decision-making aid, fail under the best of circumstances for one simple reason: they're not real life. Never more is this true than in Joe Stagner's blog post on whether Windows or Linux, and PHP or ASP was faster. [...] Benchmarks come loaded with all sorts of problems. It doesn't matter if it's Microsoft doing them or Apple doing them; they don't mimic real-world conditions, and any number of factors affect how the benchmarks are rendered.

Keeping these things in mind, Brandon looks at some of the issues he found with how the benchamrks were run, the largest of which was comparing the ASP.NET results (with byte code caching) to a PHP install without APC enabled.

Lukas Smith got a chance to catch up with Rasmus Lerdorf (and others in #php.pecl) and "talk shop" about topics including handling large libraries and maxclients settings.

In this first post I will provide a link and some commentary on Rasmus's points regarding Doctrine (note I left independent chatter in the log in order to not have any chance of me filtering the content, but there is very little of that so I hope the discussion is still easy enough to follow).

Lukas introduces Doctrine briefly (what it does) along with some general thoughts on ORMs and making code a bit more bye code cache friendly.

Joshua Eichorn points out an interesting project in a new post to his blog today - quercus.

I found an interesting project, quercus that compiles PHP to Java Bytecode allowing it to run ontop of the Java Resin Application Server. It has a couple neat features, one being PHP6 compatible unicode support, the other being easy integration between Java and PHP code.

He gave it a shot and notes that the performance seems decent and allows you to compensate for some of the differences in the PHP API it supports and what you're using via a Java class. According to their site:

Quercus is Caucho Technology's 100% Java implementation of PHP 5 released under the Open Source GPL license. Quercus comes with many PHP modules and extensions like PDF, PDO, MySQL, and JSON. Quercus allows for tight integration of Java services with PHP scripts, so using PHP with JMS or Grails is a quick and painless endeavor.

It includes several extensions too, including the JSON library, APC, MySQL and Oracle support, and PDF functionality. Check out their Getting Started guide, documentation, or their wiki for more information.

In a new post on his blog, Lukas Smith warns developers working with autoload and byte code caches that things may not be as speedy as they might seem.

While it seems kind of nice one must be weary of the idea that they speed up your code. If you are running a byte code cache (which anyone who cares about performance of course does) you will get quite the opposite.

He includes a quote from an IRC log with Rasmus Lerdorf as to the reason why. Mainly, it has to do with the fact that autoload is runtime dependent as opposed to the byte codes which are handled and cached when working with apc.

So, what does this mean for performance? If you really want to squeeze those few extra bits of time out of the execution of your scripts, static includes are the way to go.

Alan Knowles has posted this post about some of the thinks that came from a previous post he did concerning a tool for encrypting PHP scripts. In this new post, however, he mentions something on the other side of the equation - a "PHP recovery tool".

Someone posted a comment on a post I did a while back about a product that was supposed to provide encryption on PHP scripts. (That blog post was probably my most controversial, as the author of the application send me an email asking me to contact his lawyers....)

The post this time was about another magic cure, php recovery, a new web site claiming (or appearing to) sell a product to recover php source code after it has been encrypted. Well, considering my last post, using plain old PHP methods, this is perfectly feasible. However they also claim to restore your code if it was encrypted with ioncube and Zend's encoders, which, not having tried them, but knowing the author of both products reasonably well, I have a few doubts about.

He mentions what most of the encoders on the market do to accomplish their protection (the translation into bytecodes) and what some of the potential problems with converting the bytecodes back to PHP would be. There's on piece of software he mentions ("Derick's VLD"), but that's only really useful because it dumps back the opcodes in a readable format.

On the SitePoint PHP blog today, Harry Fuecks talks about some of the options to integrate PHP with Java - the Caucho updates specifically.

From this post on the server side it seems Caucho have added PHP support to their Resin Java App server.

There are a number ways to integrate with Java, by which I mean PHP-the C version.

What's interesting about what Caucho seem to have done is, rather than integrate with PHP-C, they've written their own parser for PHP scripts in Java, from which they generate Java byte code for execution. I say "seem" because I've only glanced at the source and found a convincing-looking PHP parser in there. He also points out a wiki entry with some more information on it...

John Lim has a new post on PHPEverywhere today with a look at a listing of a few PHP compilers that are up and coming.

The number of implementations of PHP continue to rise and rise. [...] I am excited about all these implementations. Most computationally intensive compiler benchmarks have shown a 5-10 times speedup over mod_php. Perhaps it is only a matter of time before we see a JIT compiler for PHP to Intel opcodes, built into mod_php...

Some of the ones mentioned include:

• Caucho's PHP5 to Java bytecode compiler
• Pint, a PHP to Parrot compiler
• Roadsend, a commercial PHP to binary compiler

He also speculates on the things that might be causing a slow uptake of these compiler technologies, things like: "is PHP fast enough?" and "Not all PHP extensions/libraries are available on all systems"...