
PHP at the speed of C - alfonsodev
http://mgdm.net/weblog/php-at-the-speed-of-c/
======
__david__
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/](http://caldwell.github.io/mandelbrot-html/)

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

~~~
ircmaxell
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.

------
ars
> 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.

~~~
Mahn
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.

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

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

------
halayli
> "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.

~~~
pmelendez
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.

~~~
halayli
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.

~~~
pmelendez
> 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.

~~~
pekk
"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.

~~~
pmelendez
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.

