c++ vs PHP/mySQL

[crockett]

I'm not a programmer but can anyone explain why server side scripts written in c++ tend to be better than those written in PHP/mySQL? my understanding is the c++ is faster and uses less resources..

I'm talking to some guys about having a custom script programed for a service I want to offer. They are trying to convince me to go with PHP/mySQL, I'm not sure that will be the best option for what I'm wanting to do.

I'm just looking for some basic information on why c++ is better for some things and PHP/mySQL is better in other areas

[Spudstr]

well for one.. c++ is precompiled application thats written. where as php is a scripting language that is thrown through an interpretor(spelling) and then spits out the results.

lots of bench marks against the two.. simple..
compile a program once.. give stuff to spit out.. or..

compile give/ get results.. over and over and over again.

php is just easier to use. but if you want speed and so forth c++ and mysql++ (the c++ library for mysql) is a way to go.

what are you looking to do? hit me up on icq.

[badmrfrosty]

Because PHP Is a scripting language that was written in C and C is the actual language.

Anytime you stack something on top of something else it becomes less efficent.

You should have all of your scripts written in Assembly

BMF

[onlyreal]

Originally posted by Spudstr
well for one.. c++ is precompiled application thats written. where as php is a scripting language that is thrown through an interpretor(spelling) and then spits out the results.

lots of bench marks against the two.. simple..
compile a program once.. give stuff to spit out.. or..

compile give/ get results.. over and over and over again.

php is just easier to use. but if you want speed and so forth c++ and mysql++ (the c++ library for mysql) is a way to go.

what are you looking to do? hit me up on icq.

[Scherfi]

if you use caches and compiled php code it gets a whole lot faster. not many people really need the speed of c++ my

[Spudstr]

Originally posted by Scherfi
if you use caches and compiled php code it gets a whole lot faster. not many people really need the speed of c++ my

you can't compile php, make a shell script or a script out of it yes but can't make it an app. php caching is fast but beware.. cache.. some forums i know use caching and sometimes due to a cached page things don't update like they should/display correctly due to dynamic content.

[crockett]

ok, that's the basic Idea I had.. I didn't know the specifics of each language as I'm not a programmer, but I kinda figured with the traffic adult can push c++ would probally be a better option.

[PowerCum]

Nah, C and php are lame, better go on pure assembly or plain binary. Why not just a hardware device? FPGAs are cheap

Just joking.

The main difference is that php+mysql is very easy to be scaled and is completely painless. C in exchange is not. If you start from there you can make a better decision than speed of C and php.If you use zend or turck encoded php it will be the same fast as C (don't forget that C loads lots of system libraryes on each run). It's not A is faster than B, it's more like program design A is faster than program design B (whatever it is written on). You can have slow program running C. Windows is a perfect example

[V_RocKs]

Originally posted by badmrfrosty
Because PHP Is a scripting language that was written in C and C is the actual language.

Anytime you stack something on top of something else it becomes less efficent.

You should have all of your scripts written in Assembly

BMF

Do you have a hello world program for me in ASM?

[raymor]

C or C++ can do many things that PHP can't
(for example, PHP is written in C), and C or C++ apps will
generally run a shitload faster using the same algorithm,
this is true. However, I think that's a tiny percentage
of the reason most C apps are a shitload better than most PHP apps.

PHP was designed to make easy things easy - very, very easy.
Building a program with PHP is as easy as building a
toy with Legos. Well, at least it's a good comparison
to say that Legos are to welding what PHP is to C.
Highly skilled professionals don't often use Legos, children do.
Same thing with PHP - being super easy to use makes
it attractive to middle school geeks, but means that
"hard" concepts like "integer variables" are leeft out
of the language. These "hard concepts" are what the pros
consider to be the basic tools of their trade.
Also, PHP, like Lego, make it really easy to build crap,
shit that doesn't hold together, and very, very difficult to
build a quality product.
Specifically, after 7 years in this business I'm still looking
for a PHP script that doesn't have a serious security issue.
I'm sure I'll find one someday.

The guys who code C tend to be the same guys whose
bathroom books include 800 page tomes on such computer
science topics as relational calculus (like me).

So I'd say while there are inherent differences in
the languages, it's the programmers that they attract which
makes a much bigger difference.
Perl and VB are both in the middle, and spread thinly.
With the "strict" pragma in force and using good OO design
principles Perl (and VB) can be professional languages
that a software engineer can be comfortable with.
On the other hand both can also be used sloppily.

[Adultlexicon]

<?

echo "Hello World!";

?>

first php program without security holes

[Nathan]

I hate to TOTALLY disagree to all of this, but I sadly have to

C++ vs PHP/mySQL is first of all a bad comparision.

1) We need to compare C/C++ vs PHP.. the database type will be the same, makes no sense otherwise.

2) We need to make sure what EXACTLY we are talking about:
a) C/C++ CGI App vs PHP Script
b) C/C++ FastCGI App vs PHP Script
c) C/C++ Apache Module vs PHP Script

I would say, most of you here were thinking of a), so lets look at that one:

Overhead when executing a C/C++ CGI app is rather huge. Why? Well, Apache first has to run an exec call, which basically FORKS apache and then lets the CGI app take over the process. This prosess is rather time consuming and resource hungry.
A PHP Script is simply loaded by the php module, which gets called instead of the base module. So no time is lost here, then PHP has to compile the script, obviously, not the fastest thing, but in terms of resources, its a HUGE advantage to the exec involved in the C/C++ App.

Now, for Database connection, the C/C++ CGI app has to open a new connection to the Database, whereas PHP will have it already in most cases. Although also connects are fast, its still a time saver for PHP.

Last but not least, C/C++ apps will tend to be harder to write and a lot less flexible. Load on the server will very likely also be higher when using C/C++ apps because more apps are running.

And, like many posted here, PHP can be extremely speed up by taking out the rather slow parsing step and by caching the system. This caching does not mean caching the OUTPUT, it means caching the fully compiled and optimized script in various stages in memory to run it even faster.

So, unless the person writing the app in C/C++ really has a _VERY VERY VERY VERY_ good rep of knowing how to do CGI correctly, I would ALWAYS prefer PHP over anything else.

[NastyJack]

Originally posted by V_RocKs
Do you have a hello world program for me in ASM?

[BITS 16]				;16 bit code gen
[ORG 0100H]				;start address for com file

[SECTION .text]			;code portion

START:

  mov dx, hellomsg		;load the address
  mov ah, 9				;func 9 displays to stdout
  int 21H				;call to dos

  mov ax, 04c00H			;exits prog
  int 21H				;return control to os

[SECTION .data]			;section containing data

hellomsg    db "Hello World!", 13, 10, "$"	;push the msg

id definately do it in php. its much easier that way. if you are concerned about extra overhead, use the zend optimizer (www.zend.com). that is written by the people who wrote the php/zend engine, zeev suraski and andi gutmans. it will increase the performance of your php scripts greatly. plenty of info on the zend site.

[Scherfi]

Originally posted by Spudstr
you can't compile php, make a shell script or a script out of it yes but can't make it an app. php caching is fast but beware.. cache.. some forums i know use caching and sometimes due to a cached page things don't update like they should/display correctly due to dynamic content.

you can make a standalone-app with gtk, and with compiling i mean optimizing which creates an almost compiled code for the zend engine. well, you know what i mean

caching can produce some overhead, true. it always depends what you wanna do

[AnalProbe]

I read a LOT of crap here.

At first you are mistaken C with C++, which is a HUGE difference in performance as well as program design.

C is the fastest thing there is, you can easily use it to create webapps using the cgi library.

C++ is an OO language that's a tat slower, more like JAVA.


About C (not C++) versus PHP :

PHP is SLOW when you use it as an Apache module, average as a standalone app, and reasonable to good with Zend accelerator (cache).

It's very easy to learn, mature, but still, every time you start a thread (user request) you have the 8 megs of memory use for every thread.

With C, if you start an executable that's 5 kB, you use 5kB of memory. That's a lot of threads, huh ?

You say C is slow if used with Apache ?

That's because Apache is SLOW, use THTTP with FastCGI and be very surprised. You can have 500 concurrent users with CGI with no noticable system slowdown. Now try that with Apache (40 - 60 concurrent maximum).

Here's a good link to compare some languages (benchmark) :

http://scutigena.sourceforge.net/

[aiken]

Originally posted by Nathan
Overhead when executing a C/C++ CGI app is rather huge. Why? Well, Apache first has to run an exec call, which basically FORKS apache and then lets the CGI app take over the process. This prosess is rather time consuming and resource hungry.

Hey, Nathan -- I'm going to have to respectfully disagree with you here. Hopefully nobody who goes to all of the effort to write a C/C++ app is going to run it as an Apache CGI module. If you were determined to use Apache, a custom mod_ would probably make the most sense, but why even bother with that?

In my opinion, the highest performing web app is going to be a pure C application with built-in web serving. Of course, this is massive, insane overkill for almost any application, and it means that in addition to your actual app, you effectively have to maintain a web server as well (well, you can buy web server source code off the shelf, or a few other options, but it gets crazy).

All that said, I can't imagine a web app that anyone in this industry is going to need that PHP wouldn't be able to do just fine. The development costs and complexities with C/C++ are dramaticalyl higher, so if raw performance is an issue you'd probably be better off going PHP and just throwing more hardware at it than going C.

Cheers
-b

[Nathan]

Originally posted by AnalProbe
I read a LOT of crap here.

At first you are mistaken C with C++, which is a HUGE difference in performance as well as program design.

C is the fastest thing there is, you can easily use it to create webapps using the cgi library.

C++ is an OO language that's a tat slower, more like JAVA.


About C (not C++) versus PHP :

PHP is SLOW when you use it as an Apache module, average as a standalone app, and reasonable to good with Zend accelerator (cache).

It's very easy to learn, mature, but still, every time you start a thread (user request) you have the 8 megs of memory use for every thread.

With C, if you start an executable that's 5 kB, you use 5kB of memory. That's a lot of threads, huh ?

You say C is slow if used with Apache ?

That's because Apache is SLOW, use THTTP with FastCGI and be very surprised. You can have 500 concurrent users with CGI with no noticable system slowdown. Now try that with Apache (40 - 60 concurrent maximum).

Here's a good link to compare some languages (benchmark) :

http://scutigena.sourceforge.net/

You are proving my point. a 5kb C app might be small, but it will use libaries and all kind of other crap, and I said CGI (which 99% of the people referring to C web apps on this board will mean) is slower than a module like php calling a pre-compiled script. And yes, great, THTTPd and FastCGI is faster, I know it is. But who here would ever use THTTPd and FastCGI? The vast majority has never heard of FastCGI, let alone THTTPd.

[crockett]

lot's of good points guys.

[Nathan]

Originally posted by aiken
Hey, Nathan -- I'm going to have to respectfully disagree with you here. Hopefully nobody who goes to all of the effort to write a C/C++ app is going to run it as an Apache CGI module. If you were determined to use Apache, a custom mod_ would probably make the most sense, but why even bother with that?

In my opinion, the highest performing web app is going to be a pure C application with built-in web serving. Of course, this is massive, insane overkill for almost any application, and it means that in addition to your actual app, you effectively have to maintain a web server as well (well, you can buy web server source code off the shelf, or a few other options, but it gets crazy).

All that said, I can't imagine a web app that anyone in this industry is going to need that PHP wouldn't be able to do just fine. The development costs and complexities with C/C++ are dramaticalyl higher, so if raw performance is an issue you'd probably be better off going PHP and just throwing more hardware at it than going C.

Cheers
-b

Yes, exactly! Look, I myself said that there are many ways to have "C" used for the web, and I only looked at the slowest possible, meaning as a CGI. Obviously anyone that REALLY needs performance, performance that PHP can not handle, would use either an apache module, or better like you said, a standalone server.

I totally agree with you there, but I did not talk about that. Why wouldn't I agree, I'd say I am the best example. You mentioned that you can not imagine a web app that anyone in this industry is going to need that PHP wouldn't be able to do just fine. I'll tell you one, counters. I mean public ones, not your own little counter for your webpage. In that kind of environment, a standalone web server is your best bet. Or else you will be a second web side story and need 50 servers to handle your traffic, or 10 like sextracker (I think its 10? not sure exactly, might be 5).

I have written statistics apps that at peak times handled over 80 million impressions a day on a single server without huge problems, and that while offering statistics others dreamed of. Thats over 1000 concurrent users at peak time btw AnalProbe

So yes, for HIGH-END performance HUNGRY systems, you will need to use C, obviously. Why would you not anyway.

But like I said before, 99% of the people here will NEVER have a system that needs more than PHP.

[AnalProbe]

Hey man,

I LOVE php, really.

I write almost all my webapps in PHP, sometimes Perl or Python.

But I write my stats app and OS like stuff in 100% C.

Nothing beats the speed of C, my stats server (seperate) counts millions of hits a day with an average serverload of 21 - 23 %.

Every hit gets stored in a SQLite DB, storing 42 fields / hit.

BTW, did you like the benchmark link ?

[Nathan]

Originally posted by AnalProbe
Hey man,

I LOVE php, really.

I write almost all my webapps in PHP, sometimes Perl or Python.

But my stats app and OS like stuff I write in 100% C.

Nothing beats the speed, my stats server (seperate) counts millions of hits a day with an average serverload of 21 - 23 %.

Every hit gets stored in a SQLite DB, storing 92 fields / hit.

BTW, did you like the benchmark link ?

Yeah, cool link, I'd love to see the speed change if you use Zend Accelerator though in terms of PHP.

And yes, like I said in my reply to aiken, very few things need C, but big stats systems definately do. We had 80 million hits a day, server load at 70% (dual system), collecting over 100 static fields and path, referrer, multi page, browser and os dynamic data. dynamic as in, they were not just count-increases, its shit that had to be sorted and so on and searched for to add up.