PHP at the speed of C | Hacker News Reader

PHP at the speed of C

mgdm.net

63 pointsalfonsodev24 comments

I did a similar dive using Javascript recently. I tried plain js, asm-js and finally webgl. Perhaps unsurprisingly, I got the best speeds out of webgl, with the mandelbrot inner loop in a shader. You can see the results here [1]—it's pretty fast. Click and drag, double click or scroll wheel to zoom.

[1] http://caldwell.github.io/mandelbrot-html/

Interestingly, he didn't bother to measure the speed of a C program that does this. ;)

I kind of doubt he understands why C is generally faster.

Actually, the PECL compiler he mentions generates C, and then compiles it using GCC with -O3.

So in a way, yes it is measuring the speed of a C program. Not a hand-optimized one, but it's compiled the same.

> If you’ve got complete control over your infrastructure and don’t mind changing PHP implementations, HHVM could well be the way to go. It also has a number of other extras which may be of interest. But what if you don’t?

I don't see how Recki answer this question. If anything Recki seems to be even more disruptive over the infrastructure.

Sure, it's interesting in its own right, but I not in the context that this article placed it in.

If I understood correctly, I think his point is that unlike HHVM, which replaces the interpreter altogether, Recki and JIT-Fu can be used for a specific piece of code or algorithm while retaining the original interpreter for the rest of the application.

Speed is not so important when biggest bottlenecks are DB and network. Safety is more important.

It's like a 7 year old with a hunting knife in each hand driving an F1 car.

> "Also, PHP is a fairly thin glue layer on top of a lot of C libraries"

Your definition of thin, and glue are kinda... off.

PHP is fairly thin (as a thumb rule the code size is roughly the same than Python) and it is a glue in the sense that you can consume the libraries in PHP instead of C.

It is not the thinnest layer but I don't think his comment was off either.

I think the reason why is that PHP users always get picked on. (I up voted his comment)

Give me a sane way to remember when to add an underscore and when not to add an underscore after str:

http://php.net/ref.strings

I wonder why they don't deprecate the str_* functions and create "normal" str{funcname} functions, for better consistency.

str without underscore is for functions that exist in C. They appear with the same name in PHP.

Am I missing strpos in C[1]?

[1]: https://en.wikipedia.org/wiki/C_string_handling#Functions

And this is a reason to pick on people who use php?

But it's so hip to do!

I did not pick on him or anybody else, I mentioned something that bothers me.

Neither Python nor PHP are thin glues. They have their own GCs, and are byte code interpreted. How is that a "thin" glue on top of c? They are an environment on their own happened to be written in C.

> They have their own GCs, and are byte code interpreted

Between the thinnest alternatives I can think of (Scheme, Lua), they have GCs as well. I'm not sure why you are bringing memory manage here though. In that phrase the author is talking about the size of the language not the memory footprint.

I believe that the author uses the term "glue" in the sense that a person who doesn't want to code in C can still use C libraries through a scripting language (in this case PHP).

How else could you do it? Well you could do the same with Java using JNI. Also you could use Perl if you want but in comparison, PHP is "fairly" thin. The author is not claiming that PHP is lightweight, just that it is thin enough to be consired as a proxy between C libraries.

"Thin" implies little work is being done over the work that C would do. I can't see how the size of the source repositories would matter here.

Memory management is worth mentioning because actually it's a lot of work done automatically, and it is among the many important distinctions between code written in C and code which runs on an interpreter written in C. I doubt many people would have called Go a thin layer of glue over C even when it was implemented in C. There is, at least, the entire Go runtime to consider.

By the time we've described almost every language in wide use as a thin glue over C (and so many languages do offer some kind of interface layer or FFI to C, permitting the use of C APIs outside of C)... there is no longer any real purpose calling anything a thin glue over C.

So I have an alternative explanation: calling PHP a thin glue over C is just how PHP decided to market itself years ago, even though it's either not true or it's trivially true of almost everything else. The apparent idea was to encourage the thought that PHP is 'almost as fast as C' and to excuse very raw APIs (they have to be this raw, you see, in order to allow the high performance of staying close to C).

I guess that made some kind of sense 15 years ago, and if you like PHP then at least there is still work on things like HHVM to reduce its disadvantages, but so much has happened in languages that now you can have either much cleaner APIs with comparable speed, or just plain much better speed than PHP, and there are also arguably options which have both cleaner APIs as well as higher speed.

I'm not arguing that PHP is unusable, much less that PHP users are stupid, but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C, when PHP is not very close to C at all in any sense that everything else isn't also very close to C.

What would be an example of a thin glue? If your definition excludes all possibilities, it's no more useful than a definition that admits all possibilities.

I believe this discussion is getting long because it seems that everybody is using a different meaning for "thin". In this context (and it is a personal interpretation), a layer to interact with a C library is thin if there is not much code that separates a language to the other.

In that regard it doesn't have anything to do with performance or memory footprint. If you take the way Java interacts with a C library you would see that there is a lot of code in between, that doesn't mean it is slower but it does mean it is thick in terms of the layer size.

>but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C,

I didn't imply that PHP is faster than Perl or Java. Just that PHP is thinner than them. However, this discussion is not going to be productive unless we all agree what we mean by a thin layer.

PHP used to be thinner than it is now. PHP/FI 2.0 was a really thin layer on top of the C standard library, and you could trivially add new functions to it (though this is still true to an extent for Zend).

PHP 3 and beyond have been more abstracted, thicker layers. They are platform-independent and have things like binary-safe strings and Unicode support.

Reply on news.ycombinator.com