Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40097
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.236 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:references;
        b=DzPLByO1qmzyuryBrTD1I5ILzkx267+zk4oZ4m8RaQicnexpieP0hrMwNhIq6bPXB2
         VjNCXIqUY2IddR9PDA/x8BbW/9t8mzR3BFB+5NBWsVzRpmUS9XSSuQqFn8k5C2ghBxmI
         OAZsT49VGZupkJ3G3MS6atRSPnM0GeUW/wGLU=
Message-ID: <7dd2dc0b0808261319q36a40f76iee74477858d6679b@mail.gmail.com>
Date: Tue, 26 Aug 2008 14:19:10 -0600
To: "Jonathan Bond-Caron" <jbondc@openmv.com>
Cc: steve <iamstever@gmail.com>, "Sebastian Bergmann" <sb@sebastian-bergmann.de>, 
	internals@lists.php.net
In-Reply-To: <002d01c9077b$4e0a9ce0$ea1fd6a0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_8472_26259769.1219781950825"
References: <57792e850808251040y6672e1f1ha0036f0778b7a011@mail.gmail.com>
	 <g8urfr$7s6$1@ger.gmane.org>
	 <57792e850808251528u3ede0077rd6828ff066f5e4dd@mail.gmail.com>
	 <002d01c9077b$4e0a9ce0$ea1fd6a0$@com>
Subject: Re: [PHP-DEV] TracingPHP
From: quickshiftin@gmail.com ("Nathan Nobbe")

------=_Part_8472_26259769.1219781950825
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tue, Aug 26, 2008 at 6:57 AM, Jonathan Bond-Caron <jbondc@openmv.com>wrote:

> On Mon Aug 25 06:28 PM, steve wrote:
> > Has anyone had success compiling PHP with LLVM?
> >
>
> I haven't tried it, here is a good summary:
> http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf
>
> In short, it is 'slower' but that seems to be without any caching of the
> "bytecode"
>
> Bytecode is not opcode:
> http://www.santosj.name/general/computers/byte-code-vs-op-code/
>
> Right now, the most effective strategy to optimize php is executing opcodes
> using an "opcode" cache such as APC (facebook & others use this).
>
> That's from my research, maybe someone can correct me here.
> Isn't using something like Zend Guard (converts code into opcode) then
> caching the opcodes essentially JIT?
>
> Even if opcode is not binary, it's still a fast intermediate form that gets
> translated into machine binary, isn't that JIT?


i think that depends on what happens inside of php..  since i dont know the
inner workings im guessing executing opcodes is pretty much the same thing
every time, that is a certain opcode correlates to some precompiled code
which is feed some variables at runtime.  whereas in JIT, w/ java anyway, it
actually takes bytecode (precompiled by the users [in .class files]) and
compiles down to binary as certain pieces of bytecode are compiled.  that
compiled bytecode is then availble to the jvm through the remainder of that
instances lifetime.

so although php executes opcodes on an, as needed basis, i think the
difference is that opcode correlate to precomipled binary, whereas w/ JIT,
compilation (from opcode to binary) is actually occurring at runtime.

http://schmidt.devlib.org/java/jit-compilers.html

-nathan

------=_Part_8472_26259769.1219781950825--