Yeah I know. I said it was probably a driver issue, get off your high horse. My point was that just because some guy says his PC is stable doesn't mean that Win7 is a magical stability machine that can negate the main cause of crashes in any OS, namely drivers.
That was my point, 3rd party drivers are more likely to cause crashes. The fact that most Linux drivers are maintained in-tree is useful here.
I was simply pointing out that Windows isn't magically super stable any more than it has been for ages (not including Win 9x, they were truly awful), and that some guy's anecdote that his Windows machine doesn't crash doesn't mean that Windows is stable, in my case it's not, and it's not hardware, Ubuntu has been running fine on this box for years.
Anyway I wasn't attacking Windows as everyone here seems to be assuming, I was saying that I probably had a driver issue, but that because MS don't maintain 3rd party drivers (and I understand that too, it's not an attack just a statement) then you're more likely to have driver problems. The MS certs system is a big improvement but not a full solution.
Except that it seems no-one has read TFA. I know I know...
This isn't some compensation package for the **AA, it's about the cost of implementing an anti-piracy law for persistent repeat downloaders. I don't really agree with the law myself but this is far from what it's being portrayed as here.
Hey now you've stopped wailing on PHP we can be friends;)
Completely agree that PHP is slower, of course it is, it's written in C so there's no way it can be faster than C!
I still think the original point of the article is BS though. If we were talking about some sort of simulation cluster I'd leap to agree, but really most of the time PHP is pretty unlikely to be doing anything very processor intensive. If it is then I'd suggest that in most cases there's a logic problem rather than a language problem.
Something that may be of interest btw, I wrote a front controller to wrap our CMS in this:
Which is basically a true FCGI-style app server for PHP (currently it's using SCGI, but same gig and FCGI is on the way. It's all very alpha atm though). So instead of PHP's default FCGI behaviour (maintain the same PHP interpreters but still rebuild the app itself on each request) it behaves as SCGI/FCGI should, the application keeps running and services requests. With 10 worker threads (running on the PHP CLI binary and listening on sockets) the performance of the app more than doubled over mod_php+APC in one go, and that's over APC's already very significant improvement over vanilla PHP. That's with everything cached though, so PHP was doing very little apart from instantiating the app then telling it to do it's stuff, which mostly consisted of fetching the cache, so it's not that surprising that the setup overhead was the majority in this case.
And yes I agree about XML too, we use XML for object metadata which it's pretty handy for, but cache it into PHP arrays on disk as soon as humanly possible.
Sure, and they all (even VB.Net!) have their places. PHP happens to work pretty damn well for most web applications, where CPU usage for the app usually isn't that intensive but the ability to rapidly change and develop your functionality is often vital.:)
My point was that you're talking about PHP vs C/C++, and I'm saying that most l33t C/C++ coders use libraries too. As it happens the same libraries that PHP uses.
I can have it both ways. I was referring to the examples you gave, all but one of which don't apply in most production environments (which almost exclusively use a bytecode cache). Yes I agree that PHP code runs slower, no it's not because of most of the points you made, and no in most environments the speed the code runs isn't the limiting factor, it's I/O and DB, as several other people have pointed out in this thread.
We saw an 90% reduction in load between APC disabled and enabled. So yes 10x isn't out of the ballpark you're describing. With a small script you won't see much difference, with larger apps there's a big overhead in re-parsing for every request, even after selective inclusion and caching strategies.
What? The point is that they should be dealing with relatively static data, therefore they go to their cache layer first (in this order usually: memory, memcached or similar, DB query cache, DB query)
Of course the less you have to hit the DB the better, but even moreso the less you have to re-calculate things that don't change the better.
"Also, mysqli is not a core part of the language - it's an extension. php itself simply doesn't natively support multiple-statement mysql queries"
The standard MySQL functions are a module too, so by your logic PHP itself doesn't support MySQL. In fact the vast majority of PHP's functionality is modules.
By the way, in your sample app were you parsing that XML with actual PHP code or the XML functions built into the language or available as modules? If it was the former then your benchmarks are worthless as you clearly don't have a clue about how to use PHP.
He chose a bad example though because Facebook do do their own custom C/C++ development where they see a need for it while keeping presentation code in PHP where it belongs because of the increased flexibility.
Regarding the glue code, do you honestly think the tiny amount of code required to dump the string into the XML parser is going to make a noticeable difference when compared to the amount of processing required to parse an XML document?
You write custom XML parsers every time you parse a different doc schema? Wow.. How many C/C++ apps do this? Let's take Debian as a sample and just look at the libxml2 package, provided by Gnome but used by many. Here are the packages dependent on it:
> Contrast to php, where every script has to be > loaded, interpreted, then flushed out of the > system so it leaves a clean memory footprint for > the next script, and where tons of variables that > your script may never call have to be initialized > each run. Obviously only compiling what you need > and loading it once is more efficient:-)
5 actual items here in the case of PHP, one of which you didn't mention:
It's pretty simple to profile an app and see it's spending most of its time waiting for the DB. I've done this with our CMS, which renders pages on first request and then caches various cacheable parts of the page until they're invalidated by some action. The DB is the bottleneck, it's easy to see, just see how much time the app spends waiting on the database query function.
A well written web-app really shouldn't be doing much processing for each page view, typically they're extremely cache and DB intensive if they're written right. We're usually not talking about apps that have to do heavy maths or anything like that, they're mostly pretty front ends for previously entered data. Database read to write ratio tends to be in the region of 10:1
I'd agree with that but the point is that with the vast majority of web apps the bottleneck is the database. There are usually far more gains to be had in optimising your DB and DB caching (including row to object transforms if you use OO with a relational back-end) than there is in switching your programming language.
Slashdot Mirror
I didn't blame Windows, I explicitly blamed drivers, how's your reading comprehension?
Pretty much exclusively my driver problems with Linux have been 3rd party binary blobs.
> You can't really blame the OS developper for 3rd
> parties releasing bad drivers for the system.
I don't, it's just how it is with the way drivers are developed for Windows.
> The difference between yours and mine? Probably
> that you've either got less than par hardware
> (that'll screw over Linux as well)
Nope, works fine in Ubuntu, has done for years, also worked fine with XP.
> or you've got shitty drivers (which will also
> screw over a Linux system)
Which is exactly what I said. The shitty drivers in this case are the latest ones from nVidia.
Yeah I know. I said it was probably a driver issue, get off your high horse. My point was that just because some guy says his PC is stable doesn't mean that Win7 is a magical stability machine that can negate the main cause of crashes in any OS, namely drivers.
Clearly not its development model if you're having Flash video crashes, that's not OSS remember.
Anyway I'm not saying OSS is a better development model, but it's excellent for drivers.
That was my point, 3rd party drivers are more likely to cause crashes. The fact that most Linux drivers are maintained in-tree is useful here.
I was simply pointing out that Windows isn't magically super stable any more than it has been for ages (not including Win 9x, they were truly awful), and that some guy's anecdote that his Windows machine doesn't crash doesn't mean that Windows is stable, in my case it's not, and it's not hardware, Ubuntu has been running fine on this box for years.
Anyway I wasn't attacking Windows as everyone here seems to be assuming, I was saying that I probably had a driver issue, but that because MS don't maintain 3rd party drivers (and I understand that too, it's not an attack just a statement) then you're more likely to have driver problems. The MS certs system is a big improvement but not a full solution.
Except that it seems no-one has read TFA. I know I know...
This isn't some compensation package for the **AA, it's about the cost of implementing an anti-piracy law for persistent repeat downloaders. I don't really agree with the law myself but this is far from what it's being portrayed as here.
My Windows 7 install crashes every day or two.
Yes it's probably drivers but that was always the case with Windows and is due to its development model.
"phprocks.com"
Heheh, I wouldn't go that far, but it's perfectly serviceable ;)
Like the contest idea but don't really want any new domains just now :)
Hey now you've stopped wailing on PHP we can be friends ;)
Completely agree that PHP is slower, of course it is, it's written in C so there's no way it can be faster than C!
I still think the original point of the article is BS though. If we were talking about some sort of simulation cluster I'd leap to agree, but really most of the time PHP is pretty unlikely to be doing anything very processor intensive. If it is then I'd suggest that in most cases there's a logic problem rather than a language problem.
Something that may be of interest btw, I wrote a front controller to wrap our CMS in this:
http://github.com/indeyets/appserver-in-php/
Which is basically a true FCGI-style app server for PHP (currently it's using SCGI, but same gig and FCGI is on the way. It's all very alpha atm though). So instead of PHP's default FCGI behaviour (maintain the same PHP interpreters but still rebuild the app itself on each request) it behaves as SCGI/FCGI should, the application keeps running and services requests. With 10 worker threads (running on the PHP CLI binary and listening on sockets) the performance of the app more than doubled over mod_php+APC in one go, and that's over APC's already very significant improvement over vanilla PHP. That's with everything cached though, so PHP was doing very little apart from instantiating the app then telling it to do it's stuff, which mostly consisted of fetching the cache, so it's not that surprising that the setup overhead was the majority in this case.
And yes I agree about XML too, we use XML for object metadata which it's pretty handy for, but cache it into PHP arrays on disk as soon as humanly possible.
Sure, and they all (even VB.Net!) have their places. PHP happens to work pretty damn well for most web applications, where CPU usage for the app usually isn't that intensive but the ability to rapidly change and develop your functionality is often vital. :)
I thought you were referring to your PHP vs C benchmarks sorry.
My point was that you're talking about PHP vs C/C++, and I'm saying that most l33t C/C++ coders use libraries too. As it happens the same libraries that PHP uses.
I can have it both ways. I was referring to the examples you gave, all but one of which don't apply in most production environments (which almost exclusively use a bytecode cache). Yes I agree that PHP code runs slower, no it's not because of most of the points you made, and no in most environments the speed the code runs isn't the limiting factor, it's I/O and DB, as several other people have pointed out in this thread.
We saw an 90% reduction in load between APC disabled and enabled. So yes 10x isn't out of the ballpark you're describing. With a small script you won't see much difference, with larger apps there's a big overhead in re-parsing for every request, even after selective inclusion and caching strategies.
What? The point is that they should be dealing with relatively static data, therefore they go to their cache layer first (in this order usually: memory, memcached or similar, DB query cache, DB query)
Of course the less you have to hit the DB the better, but even moreso the less you have to re-calculate things that don't change the better.
Actually my friend wrote the original PHP in 24 hours and he's a rabid layer separation proponent! :)
His later book "PHP Object Patterns and Practice" is much more interesting though.
Never had a magic quotes bug no. Standard practice is to disable it and has been for a long time.
You could list some of your other favourite PHP hacks and we can see from there eh...
"Also, mysqli is not a core part of the language - it's an extension. php itself simply doesn't natively support multiple-statement mysql queries"
The standard MySQL functions are a module too, so by your logic PHP itself doesn't support MySQL. In fact the vast majority of PHP's functionality is modules.
"For apps running like facebook, it's probably cost-effective to slowly switch pieces from php to c that are going to be more-or-less static."
Which Facebook already do when there's a need, so what's your point?
By the way, in your sample app were you parsing that XML with actual PHP code or the XML functions built into the language or available as modules? If it was the former then your benchmarks are worthless as you clearly don't have a clue about how to use PHP.
He chose a bad example though because Facebook do do their own custom C/C++ development where they see a need for it while keeping presentation code in PHP where it belongs because of the increased flexibility.
Regarding the glue code, do you honestly think the tiny amount of code required to dump the string into the XML parser is going to make a noticeable difference when compared to the amount of processing required to parse an XML document?
You write custom XML parsers every time you parse a different doc schema? Wow.. How many C/C++ apps do this? Let's take Debian as a sample and just look at the libxml2 package, provided by Gnome but used by many. Here are the packages dependent on it:
php5-xsl,libxml2 2.6.27
php5-xmlrpc,libxml2 2.6.27
php5-cli,libxml2 2.6.27
php5-cgi,libxml2 2.6.27
libapache2-mod-php5,libxml2 2.6.27
libapache-mod-php5,libxml2 2.6.27
php4-domxml,libxml2 2.6.27
php4-imagick,libxml2 2.6.27
xmlroff,libxml2 2.6.27
xfce4-mixer,libxml2 2.6.27
virtualbox-ose,libxml2 2.6.27
virt-viewer,libxml2 2.6.27
ure,libxml2 2.6.27
umbrello,libxml2 2.6.27
sobby,libxml2 2.6.27
scribus,libxml2 2.6.27
quanta,libxml2 2.6.27
postgresql-contrib-8.3,libxml2 2.6.27
postgresql-8.3,libxml2 2.6.27
perlmagick,libxml2 2.6.27
osm2pgsql,libxml2 2.6.27
openoffice.org-writer,libxml2 2.6.27
openoffice.org-core,libxml2 2.6.27
openbox,libxml2 2.6.27
obconf,libxml2 2.6.27
network-manager-vpnc-gnome,libxml2 2.6.27
mysql-query-browser,libxml2 2.6.27
mysql-admin,libxml2 2.6.27
lighttpd-mod-webdav,libxml2 2.6.27
libwine,libxml2 2.6.27
libvirt0,libxml2 2.6.27
libvirt-bin,libxml2 2.6.27
libpurple0,libxml2 2.6.27
libobrender16,libxml2 2.6.27
libobparser16,libxml2 2.6.27
libmapnik0.5,libxml2 2.6.27
libmagick10,libxml2 2.6.27
liblablgtksourceview-ocaml,libxml2 2.6.27
liblablgtk2-ocaml,libxml2 2.6.27
liblablgtk2-gnome-ocaml,libxml2 2.6.27
kxsldbg,libxml2 2.6.27
kopete,libxml2 2.6.27
klinkstatus,libxml2 2.6.27
kdelibs4c2a,libxml2 2.6.27
juk,libxml2 2.6.27
icecast2,libxml2 2.6.27
heartbeat,libxml2 2.6.27
gtkpod,libxml2 2.6.27
gpomme,libxml2 2.6.27
gobby,libxml2 2.6.27
gnucash,libxml2 2.6.27
gnash-common,libxml2 2.6.27
finch,libxml2 2.6.27
ekiga-gtkonly,libxml2 2.6.27
ekiga,libxml2 2.6.27
compiz-plugins,libxml2 2.6.27
compiz-gnome,libxml2 2.6.27
compiz-core,libxml2 2.6.27
collectd,libxml2 2.6.27
autogen,libxml2 2.6.27
apt-dater,libxml2 2.6.27
vlc-nox,libxml2 2.6.27
python-libxml2,libxml2 2.6.27
postgresql-contrib-8.1,libxml2 2.6.27
postgresql-contrib-7.4,libxml2 2.6.27
php5-xsl,libxml2 2.6.27
php5-xmlrpc,libxml2 2.6.27
php5-cli,libxml2 2.6.27
php5-cgi,libxml2 2.6.27
perlmagick,libxml2 2.6.27
openoffice.org-core,libxml2 2.6.27
network-manager-gnome,libxml2 2.6.27
libxml2-utils,libxml2 2.5.7-1
libxml2-utils,libxml2 2.5.7-1
libxml2-utils,libxml2 2.6.27
libxml2-dev,libxml2 2.6.6-1
libxml2-dev,libxml2 2.6.6-1
libxml2-dev,libxml2 2.6.27.dfsg-6+etch1
libxml2-db
You said:
> Contrast to php, where every script has to be :-)
> loaded, interpreted, then flushed out of the
> system so it leaves a clean memory footprint for
> the next script, and where tons of variables that
> your script may never call have to be initialized
> each run. Obviously only compiling what you need
> and loading it once is more efficient
5 actual items here in the case of PHP, one of which you didn't mention:
1. Read
2. Parse
3. Interpret bytecode
4. Variable re-interpretation
5. Flush from memory
APC removes 1,2,5 and to a large extent 4.
In the case of 5, yes the execution environment is still cleared, but the bytecode remains in memory in APC.
I'm not saying it's as fast as hand written C just pointing out that a large part of what you wrote is rubbish in the typical production environment.
It's pretty simple to profile an app and see it's spending most of its time waiting for the DB. I've done this with our CMS, which renders pages on first request and then caches various cacheable parts of the page until they're invalidated by some action. The DB is the bottleneck, it's easy to see, just see how much time the app spends waiting on the database query function.
A well written web-app really shouldn't be doing much processing for each page view, typically they're extremely cache and DB intensive if they're written right. We're usually not talking about apps that have to do heavy maths or anything like that, they're mostly pretty front ends for previously entered data. Database read to write ratio tends to be in the region of 10:1
I'd agree with that but the point is that with the vast majority of web apps the bottleneck is the database. There are usually far more gains to be had in optimising your DB and DB caching (including row to object transforms if you use OO with a relational back-end) than there is in switching your programming language.
Parsing XML would be handled by a PHP extension, which would be... written in C!