Most pages will take less than a second to execute. Caching, where possible, will also be used to further decrease the time. Opcode Caches can also be used to keep PHP from compiling the page with each request further decreasing the time it takes. Taken all together most professional web sites wouldn’t benefit from JIT compilation. Given the delay from converting to machine code, it might actually take longer on the first run.

Would it be quicker to write a C extension for PHP than building a JIT compiler for the Zend Engine? Yes. In the discussion with Frameworks, the solution is to write the slow PHP code in C and write a function to be called in PHP, if available. My argument has always been that I shouldn’t have to. If it is just as fast using JIT compilation than I shouldn’t have to touch C code unless I’m binding some library in C or C++ to be used in PHP.

Yeah, 2x time decrease (Roadsend compiler statistics) doesn’t sound like much, but I would like to run algorithms that normally take 15 to 30 seconds in half the time. That to me is a huge deal. Now, these algorithms won’t run in front end pages, of course, but I would like to maintain the code in PHP. The possibility of the algorithm being poor is there, and so is that it would be better writing the code in C/C++.

Well, what I’m trying to get at, is that with edge cases JIT compilation would make a lot of sense. For those with normal pages, then I concede that you are correct.

Possibly Related Posts:

• English IV: Untitled Satire
• Userland Multitasking: Introduction
• PHP Opcode Series
• Quest For Magic: Vincent Draft 1
• How to Start Spirit Keeper

Win/Win.

I’m going to try even harder now that enough people are saying that I’m not right (which is nicer than saying I’m wrong) on Just-in-Time compilation benefits for PHP. I really do think the extra seconds saved will great impact what PHP can be used for in the future. Judging from a working PHP 4 compiler, it cuts the time in half. Let us say for a moment that you have to process 100 datasets that takes .15 seconds each iteration. That is 15 seconds. If you compile it and it only takes .075 seconds, then well, it would only take 7.5 seconds. It is a poor example, but the point I’m trying to make is if you cut the time, even by a fraction, it can save a lot within a loop.

Yeah, sure it isn’t going to be a huge deal for front end sites because they won’t have anything that within a loop that takes that long. Even if they had a loop, they would use caching so that users wouldn’t notice the speed decrease. If you are doing gaming, math intensive, or heavy processing, it can get ugly very fast and limit you quickly on what you can afford to do time and processing on shared hosts.

The only way to know for sure whether or not JIT will benefit users, is to have a working and optimized solution for which testing can occur. My ultimate goal and I hope by next year I’ll have a working version that can be tested. Along the way, I have other side quests I need to complete before I can get from point ‘A’, which is not having JIT implementation, to point ‘B’, where I have a working implementation.

Not that I care whether or not it speeds PHP up, it would be nice. By this time next year I would know a lot more about Python than I do now and PHP JIT would be less important. My motivation is more compiler theory and always wanting to do something like this. The wealth of knowledge within the Zend and PHP engines is massive and anyone would learn a great deal tweaking and lurking around within them.

So, something next year, I want to either prove I’m right (hopefully that will be the case) or I’ll just prove what everyone else is saying and slowly bow my head momentarily in shame.

Possibly Related Posts:

• Easier APIs for WordPress
• Libraries Should Use Liberal Licenses
• Why Writing Documentation Wasn’t a Waste of Time
• Contradiction of Good Object-Oriented Design
• WTF Are People Still Writing PHP Template Engines

At my current level of skill and understanding, this feature would be impossible for me to implement on my own. It is just an introductory look at what the other sections will visually look like when they are also finished. I will not be implementing this feature.

Introduction

Multi-threading should not be allowed at the user level, but allow for sandbox threading. The PHP Engine should keep track of the creation of threads, protect against deadlocking, and control synchronization. This will abstract away the complexity and have PHP do all of the heavy lifting as well as protect the developers from themselves and harming the process the thread is in.

There are some architectures, both CPU and OS, that do not allow threading. There should be a fall back implemented in the virtual machine that still enables an environment functionally similar to threading. The fall back can be implemented like the ticks in the current PHP Engine or it could use a stack approach similar to operating systems.

The Engine could also track how efficient the system is and how well it would perform if it was single threaded. There should be a mix of allowing the developers to test and optimize on their own and tracking internally to help protect against slow scripts caused by wrong usage of this feature.

There should be internal reflection for threading to allow for tracking, overriding, and debugging. The reflection will track the time a thread takes, which threads and variables it is synchronized with, and how many times faults occurred. There should be functions for overriding whether or not the thread is still multi-threaded or if it creates an interprocess, or if it is instead acts like a single thread, when processed.

The multi-threading feature wouldn’t be useful, if the process shutdown and destroyed everything at execution. The feature would only be enabled for PHP environments that are already multi-tasked to keep the script from taking longer than it should.

Virtual Machine: Timing the Best Method

During runtime, the virtual machine can keep track of the time the script takes and switch between single threaded and multiple threads to get statistics on which would be the best method overall. After it figures which is the best method for the user, it can either log what it finds, allow for reflection to get the number, and then decide which is the best method to take. It would still work like the user expects, but allow for the virtual machine to decide which is the best method for the user.

This would add additional memory and processing overhead, so it could be disabled by those who already think that their script is optimized enough already. This adds another level of complexity to the feature and could introduce difficult to find and fix bugs. It should also be allowed to be overwritten by the user for those who know for a fact that the system doesn’t work that well for their script. The system won’t be able to work perfectly 100% of the time for every script.

This additional feature would be extremely useful for JIT or opcode cached environments where the script is stored in memory for extended periods of time. Keeping track of timing of various environments would allow for the system to rewrite itself to optimize the speed for the user. The abstraction would be such that the user wouldn’t be able to tell, except when the system fully realizes and optimizes itself and the script.

Keywords

The following sections will introduce additional keywords and syntax that will require that the flex and bison skeletons be updated to allow for this feature. This section will not be updated and will not be found here.

Different Methods for Creating Threads

The following parts will detail the various parts of this feature and will be split up to allow for better understanding on what the feature will involve.

1. Anonymous
   • Does not allow for returning to main thread or calling from the main thread.
   • Runs along side the main thread.
2. Named
   • Does not run unless called from the main process.
   • Can return data to the calling thread.
3. Shell
   • Allows for shell commands to be processed in another thread or process.
   • Allows for returning to the calling thread.
   • Allows for both anonymous and named shells.
   • It would replace functionality, most of the shell extensions, when implemented.
4. Interprocess
   • Replaces the current method of the Process Control extension with an easier to setup and create method.
   • Also will allow for connecting to other processes for passing data.

Possibly Related Posts:

• English IV: Untitled Satire
• In Response to JIT Compilation
• PHP Opcode Series
• Quest For Magic: Vincent Draft 1
• How to Start Spirit Keeper

The PHP Opcode series will take a look at the theory and implementation of working with the Zend Engine in the specific areas of adding opcodes and enabling language features. The specific areas will be how it would look in the PHP language, how it would look as PHP opcodes, and how it would look as Assembler for looking at enabling JIT compiling later.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

(Honestly, I’m spending more time on these posts than I do on my school research papers… which is to still say that I am doing more than previous posts.)

Purpose

I want to add JIT compiling to the current Zend Engine and before I can do that I will have to learn how the Zend Engine works. The best way would be to read a book or learn from the minds that created it. There is a current lack of printed material on extending the Zend Engine and I’ll rather not bother the Zend Engine masters with my countless n00bish questions. I’ll wait to ask those questions for whenever I hit a road block or can’t find the answer myself.

I’m going to try to implement some of the easier features of the “Opcode Theory” part to learn how different areas of the Zend Engine work. I’ll also intentionally break the Engine and learn from there. Such questions as, “I wonder what would happen if I add this?” or “What if I change this to my own code.”

I’m tempted to rewrite the entire thing to my achieve my own goals, but that would negate the point of these exercises.

Not that I will implement all of the theory, but to think about how it would be possible. To learn how PHP uses Opcodes and how it can be improved and optimized by using more. By writing theory and how the current Zend Engine works, I can remember better and try to implement my ideas to see if they are possible.

Areas of Focus

There will be areas of focus with titles for keeping order of which post is for what.

• Opcode Theory
• Opcode Implementation
• Opcode Documentation

Opcode Theory

These posts will abstract out the problem and how it could look once implemented. From above, the sections will be PHP userland code, PHP Opcode, and finally how it would look as Assembler for JIT. The Assembler isn’t much use for the JIT, but it will help to think about solutions once JIT is finally implemented. The JIT and Assembler will achieve the same functionality of converting opcodes to machine code.

It would be nice to see it in action outside of PHP, using Assembler, before implementing the feature using the JIT library. Getting Assembler code to work against the Zend Engine and PHP will also be part of the Implementation, which is outside the scope of the Theory. It is just to say that the Theory part will have puesdo-Assembler code for how it might look.

I will not be implementing all of these theory posts and I will be lucky if I even implement one. My main purpose is learning enough of the Opcode parts of the Zend Engine to hook into and write a Zend Engine extension that enables JIT compilation. These side projects should help to learn enough to accomplish that much.

Opcode Implementation

Will document how well I’m doing implementing some of the theory and eventually the JIT feature for the Zend Engine. In the event that I do implement one of the features in the theory part, I will post what it finally looks like and how it works. These posts will also include the road and difficulties in implementing the features in the theory posts and eventually how it was done.

Opcode Documentation

I expect that I’ll learn a lot by the above mangling of the Zend Engine and picking at the minds and team behind the Zend Engine. Some things I will have to learn myself and I’ll post them in this heading to make sure that I’ll remember them when I come back after an extended break or two to work on other projects.

“Hmm, how did I do that one thing again? Oh yeah, I wrote about that!” and also to store help I will eventually (hopefully) receive from the PHP lists.

Possibly Related Posts:

• English IV: Untitled Satire
• In Response to JIT Compilation
• Userland Multitasking: Introduction
• Quest For Magic: Vincent Draft 1
• How to Start Spirit Keeper