Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up PHP with the HipHop VM

facebook.com

Post reply on HN
Print view View original

101–110 of 122 posts

Re: Speeding up PHP with the HipHop VM

#101

Post by pbiggar »

dparoski wrote: post #85
pbiggar wrote: post #37

Earlier quoted context omitted.

One more thing - the use of a stack-based bytecode is also curious. PHP itself (the Zend engine) uses a register-based bytecode (well, it uses a horror-show of an in-memory bytecode-like-thing, which could best be described as a register-based bytecode). The PHP engine details leak into the language a lot, so the difficulties they describe aren't unexpected. Not only that, but bleeding-edge JITs typically use registe…

As noted elsewhere in this thread, a stack-based design typically produces more compact bytecode. Compactness was a concern for us because of the size of FB's PHP code base. Also, generally speaking a stack-based design tends to be easier to deal with when working to get a prototype VM up and running quickly. Many of the advantages of register-based designs (ability to optimize by rewriting the program at the bytecod…

Makes total sense, thanks!

Would using a register-based bytecode not have been useful for the x64 JIT?

Re: Speeding up PHP with the HipHop VM

#102

Post by igouy »

pbiggar wrote: post #54
byroot wrote: post #49

Earlier quoted context omitted.

Did you looked at the source ? For example for the pidigits bench: The PHP version use the GM extension http://shootout.alioth.debian.org/u64q/program.php?test=pidi... And Ruby do it in pure Ruby http://shootout.alioth.debian.org/u64q/program.php?test=pidi... So basically it's a C vs Ruby benchmark. Many peoples complained on the forum, take a look. The Debian shootout is interesting, but don't take it as an absolute…

The Debian shootout has made some very questionable decisions, and the author has defended them by saying that you cant rely on the results. Which is definitely true.

>> the author has defended them by saying that Please show where I said that, or admit that you are putting words into my mouth.

Re: Speeding up PHP with the HipHop VM

#103

Post by igouy »

byroot wrote: post #49
notJim wrote: post #45

Earlier quoted context omitted.

Uhh, to the extent that it makes sense to compare speeds of programming languages, PHP is faster and uses less memory than both ruby and python in many or most cases: Python: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Ruby: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Did you looked at the source ? For example for the pidigits bench: The PHP version use the GM extension http://shootout.alioth.debian.org/u64q/program.php?test=pidi... And Ruby do it in pure Ruby http://shootout.alioth.debian.org/u64q/program.php?test=pidi... So basically it's a C vs Ruby benchmark. Many peoples complained on the forum, take a look. The Debian shootout is interesting, but don't take it as an absolute…

The benchmarks game is not "The Debian ..." anything -- just one of 960 hosted projects.

The pi-digits page also shows a PHP program which does not use the GMP extension.

Why do you think no one has contributed a Ruby program that uses GMP? Is that too hard to do using Ruby?

The benchmarks game is the absolute truth about the reported measurements.

Re: Speeding up PHP with the HipHop VM

#104

Post by [deleted] »

pbiggar wrote: post #54
byroot wrote: post #49

Earlier quoted context omitted.

Did you looked at the source ? For example for the pidigits bench: The PHP version use the GM extension http://shootout.alioth.debian.org/u64q/program.php?test=pidi... And Ruby do it in pure Ruby http://shootout.alioth.debian.org/u64q/program.php?test=pidi... So basically it's a C vs Ruby benchmark. Many peoples complained on the forum, take a look. The Debian shootout is interesting, but don't take it as an absolute…

The Debian shootout has made some very questionable decisions, and the author has defended them by saying that you cant rely on the results. Which is definitely true.

[deleted]

Re: Speeding up PHP with the HipHop VM

#105

Post by pbiggar »

igouy wrote: post #102
pbiggar wrote: post #54

Earlier quoted context omitted.

The Debian shootout has made some very questionable decisions, and the author has defended them by saying that you cant rely on the results. Which is definitely true.

>> the author has defended them by saying that Please show where I said that, or admit that you are putting words into my mouth.

Do you believe that the shootout results reliably show that one language is faster than another?

Re: Speeding up PHP with the HipHop VM

#106

Post by igouy »

pbiggar wrote: post #105
igouy wrote: post #102

Earlier quoted context omitted.

>> the author has defended them by saying that Please show where I said that, or admit that you are putting words into my mouth.

Do you believe that the shootout results reliably show that one language is faster than another?

You claimed I said "that you cant rely on the results".

Please show where I said that, or admit that you are putting words into my mouth.

Re: Speeding up PHP with the HipHop VM

#107

Post by pbiggar »

igouy wrote: post #106
pbiggar wrote: post #105

Earlier quoted context omitted.

Do you believe that the shootout results reliably show that one language is faster than another?

You claimed I said "that you cant rely on the results". Please show where I said that, or admit that you are putting words into my mouth.

This is a discussion forum, not a court of law. I'm not about to trawl through 5 or 6 years of reddit and hacker news comments to find an exact quote.

If you believe the shootout results can reliably show that one language is faster than another, say so. Otherwise, de facto you are saying you cant rely on the results.

Re: Speeding up PHP with the HipHop VM

#108

Post by rynop »

rynop wrote: post #32

First off thanks for all the hard work. Do you have a list of the php extensions you support? I’m wondering if things like cURL, memcache, pdo MySQL etc are supported. I found https://github.com/facebook/hiphop-php/wiki/Extensions-and-m... but its a bit outdated (last mod 2yrs ago). Also wondering what APC methods you support.

Found ans here: https://github.com/facebook/hiphop-php/tree/master/src/runti...

Re: Speeding up PHP with the HipHop VM

#109

Post by igouy »

pbiggar wrote: post #107
igouy wrote: post #106

Earlier quoted context omitted.

You claimed I said "that you cant rely on the results". Please show where I said that, or admit that you are putting words into my mouth.

This is a discussion forum, not a court of law. I'm not about to trawl through 5 or 6 years of reddit and hacker news comments to find an exact quote. If you believe the shootout results can reliably show that one language is faster than another, say so. Otherwise, de facto you are saying you cant rely on the results.

People here are smart enough to understand that you want to claim "you cant rely on the results" and to make your claim seem stronger you put your words in my mouth.

Re: Speeding up PHP with the HipHop VM

#110

Post by kmavm »

masklinn wrote: post #76
kmavm wrote: post #38

Earlier quoted context omitted.

It isn't tracing. Don't be fooled by the name "tracelet". Unlike trace trees, tracelets contain no control flow. It is just a type-specialized basic block. This means that the jit output does not combinatorially explode when we encounter polymorphism. In many ways, our approach is the opposite of tracing; we jit the first time we hit any code at all. And we look terrible on loopy microbench code, but run FB's multi m…

So it's closer to V8's "basic" JIT?

Our approach is different from other dynamic language JITs that I'm aware of. While there is lots of diversity out there, most other dynamic language JITs can be roughly categorized as either having a method-at-a-time strategy, or a tracing strategy. Our system is neither tracing jit nor method-at-a-time, but basic-block-at-a-time.

The systems that it has the most in common with are actually binary translators; e.g., VMware's software x86 hypervisor, or the Dynamo system. Those systems run basic block at a time to solve a number of problems; e.g., disambiguation of code and data. We're basic-block-at-a-time for a different reason: closure under type inference.

Post reply on HN