To model any input signal you need an infinite series of sine waves of different frequencies. Some input signals are better approximated by the first n terms in the series. Some signals (like the square wave) are difficult and you need more terms.
What if your input signal IS a sine wave? Then you only need 1.
First the preprocessor stripped out all the white space, newlines, superfluous stuff like page numbers and comments, and all the #ifdef stuff that defined obsolete, no-longer-supported architectures.
Then on the compilers first pass, it compiled everything that was left, which wasn't much, to tell you the truth.
Then came the optimizing pass. Out came the redundant loops, the busy-wait code, the code that was unreachable (aka "dead code"); By invoking the "--with-best-result option" most conditionals (if/else, switch) could be optimized out and only the one true path taken. Duplicate code was removed.
The whole compile time took 40 days and 40 nights - most of it was the optimizer.
Finally, I ran the resulting binary -./da_rulez
Out came one line.
"Hello, world! Treat others as you would have them treat you."
Turns out that beyond that core concept, everything else is either contradiction, commentary, corruption, or crap.
Merry Christmas, Happy Holidays, whatever floats your boat.
Fact - the Catholic Church has paid out over ONE BILLION DOLLARS to settle child molestation suits by 2002, and the number grows and grows and grows.
But what do you expect from an organization that teaches that sex is bad except with their seal of approval, that gays and lesbians are going to hell even though same-sex activity of all kinds is normal in the animal kingdom, and also normal in humans, that you should be stoned to death for shopping on Sunday, and that cannibalism brings you closer to god ("take, eat, this is my body").
I wouldn't be surprised if there's a priest somewhere right now sewing an "alter boy meat suit" a la Hannibal Lecter. Or reading the alt.recipes.baby newsgroup.
That just makes god into a shitty parent and a shitty example to follow.
"Someone has to pay for this!" Why? "Because those are MY rules!" Well, your rules suck. That's not forgiveness. That's "eye-for-an-eye."
"I love you all so much I killed my kid for you!" Well, we never asked for that, so you should accept responsibility for your infanticide. "I did it for YOU!" Why? "Because you're going to hell otherwise!" Why? "Because you disobeyed my laws!" In other words, you don't know the meaning of forgiveness. Fuck you.
Any parent that would torture and kill their own kid is not an example to follow. Any god that would ask one of their followers to do the same (and god did ask this of Abraham) is fucked up. Anyone who follows such a god deserves to go to hell.
It would be the height of irony if god existed and in her judgment only atheists qualify for heaven, because the good we do is done without the guilt of sin or fear of punishment by god.
All Catholics and Anglicans believe in Christ (the son of God) hence the are Christians.
The bible says that satan himself believes that jesus was the son of god.
By your argument, the devil is a christian.
After all, the bible can't be wrong, right?
It also explains why so many christians act like they're in a real hurry to go to hell.
Now let's extend it. This means that only atheists go to heaven.
After all, you're either going to hell or heaven,; you can believe that jesus was gods son, like satan did, and he's supposed to be in hell, so since unbelievers can't be in the same place as believers, and since unbelievers have to go "somewhere", and the only other option is heaven, atheists go to heaven. And since believers can't go the same place as unbelievers, they ALL go to hell.
Or there is no god, there is no jesus, there is no devil, there is no original sin, and there is no such thing as a pope - just another nazi dictator.
Also, your #10 is wrong. Atheists KNOW there is no such thing as god. Agnostics say you can't know for sure one way or the other, so agnostics can't include atheists.
Atheists regard agnostics as wishy-washy fence-sitters trying to hedge their bets.
Which is a different thing altogether, and fundamentally wrong. One cannot be Catholic without being Christian.
Sure you can. "Catholic" means "universal" - and we all know that those "Universal" churches are all just cults (but then again, so are all religions).
Besides, the pope can't claim trademark OR copyright, since both predated trademark and copyright law, and the church never registered them within the delays provided by law, they're still in the public domain. You can't "un-public-domain" something. So much for "papal infallibility".
Looks like the pope is showing his jackboot nazi roots by trying to declare he is above the law.
Repeat after me - bytecode needs an interpreter at runtime. It is not "compiled" in any true sense of the word, any more than the output of the c preprocessor could be called "compiled".
Bytecode is an intermediate representation of your program that is further interpreted at runtime, not compiled code that can be run on a real-world cpu. Your script is translated to bytecode as part of the process, whether it's done in the web server when the script is loaded and run, or via APC. You can see this because certain errors cause the program to not parse during the conversion to bytecode; contrast with logic errors, which will cause it to fail partway through execution.
This will be slower than c because you're still interpreting at runtime - you've just skipped the "strip out the comments and extraneous whitespace and represent it as bytecodes and references to data" portion.
I have never seen a non-trivial program in THIS universe that uses the stl and doesn't encapsulate it in a class, and then derive from that class. So your code is going to have some vtables, and its going to be slower than straight c, and it's going to be WAY slower than php. What universe do YOU live in where people use the stl but not objects?
No - allocated a 64k buffer and read into it 64k at a time
If you can go faster by doing syscalls in assembly than using posix read(), your libc implementation sucks
And just where would one go to get a non-sucky-libc-posix-read() 2 decades ago? And some non-sucky-hardware to go with it? And a non-sucky-posix-compliant-optimizing-c-compiler?
I know, I'll just whip out Mr. Time Machine and... no, if I could do that, I'd corner the stock market, start a cult that would make L. Ron Hubbard look like a poseur, and alter the time line so we didn't abandon the moon (hence the cult:-). And I'd make sure that the Motorola 68k series of chips won the war, not the Intel x86. And maybe have Apple buy Microsoft, for the lulz.
The problem is always one of access rights - chunk of code a says "I want the next item in the list", gets suspended, chunk of code b says "delete the last item", chunk of code a resumes and gets back a pointer to non-valid data. The traditional way to solve this is to lock on $SOMETHING. Other work-arounds are for the runtime environment to guarantee to the programmer that certain statements will get executed atomically, so you can guarantee setting/clearing a flag, or changing a function pointer (but what happens when two processes BOTH try to set two flags and each one only sets one... so you end up with having to either put in code to detect a deadlock, or you end up with a 3rd flag that guards the first two, which wrecks code that isn't aware of the 3rd flag, so you end up with a real mess anyways and say "what the heck, let's just remove the first two flags and check only the third" so you're not so fine-grained. Done often enough, you end up back at the "one big lock" level).
In the end it depends on the application you're writing, and whether data that's slightly "dirty" is okay.
Any program that uses the stl is going to be a c++ program by definition. It will have classes that use the stl (how often do you see a c++ program with no classes?), and since most people don't write one-off classes, and you have to guard access to the stl with locking primitives anyway (STL_LOCK, STL_UNLOCK) which the programmer usually stuffs into a class and then derives their objects so that they don't have to worry about locking, it's pretty much inevitable that you'll end up with vtables in your runtime when you use the stl.
Hey, I didn't write that code - I just nuked it wherever possible because it is fugly; Besides, the STL doesn't really belong in an OOP environment - even Stephanov agrees that the STL is not OOP., so no wonder it looks ugly.
Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
But back "sort of" on topic - how often have you seen a non-trivial c++ program that used the stl that didn't also use inheritance?
And use of that particular aspect of the class is incompatible with the rest of the class functionality. For example, no prepared statements - which is the only really compelling reason to use mysqli, despite its' higher overhead at runtime. 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 - try it and you'll see quickly enough. Plus, you're still paying the speed penalty for interpreted code, which is what the article is all about.
If the bottleneck were the database, you couldn't make your app 10x (or even 2x) faster by switching to c. The bottleneck is the interpreter, not the db.
The people who claim the bottleneck is the db haven't tried to benchmark the difference in speed between using php and using c to access the db, or they'd know that it's like night and day.
It depends on what type of data you're trying to generate. Terrain maps that actually "make sense" are a bit more complex than completely random data like $RANDOM_LAST_NAME + "," + $RANDOM_FIRST_NAME, for example, so once you generate a grid, you've got to make it sane, and it's got to have a pattern that looks realistic to a human. You can't for example, have a river that just goes in a circle.
How would you do this in a web environment? Each request comes in independently so how do you deal with all these different instances of queries needing to be serviced? And if you are waiting until you have 1000 different queries, you're going to introduce delays as request #1 has to wait for request #1000 and unless you have a fairly constant, high volume of traffic, you're not going to be able to anticipate the volume of queries. I suppose you could execute the batch every 500ms or 1000 queries, whichever comes first, though that doesn't guarantee the snappiest response for the user.
Say you have 400 front-facing server threads that are executing... your back-end process grabs any that have data ready, prepares one large multi-statement query, runs it, iterates through the results, and gives each back it's proper response. Alternatively, you might want to load specific modules into your back-end process that can respond to specific front-end requests that need to generate and process, say, 100 queries - better to do that in one shot than to have php try to do it.
At any rate, now you have me curious... one of these days I'll have to try batching up queries vs. batching up stored procedures vs. executing independently and letting the server figure it out, then compare the relative performance of each.
Curiosity is a *GOOD THING* - it's both how we advance the state of the art and how we solve our everyday problems. It's certainly a lot better than most responses, which try to claim stupidity like "running compiled byte-code" - which plainly shows they don't know that "byte-code" is not machine code, and needs further interpretation at runtime. Or like the people who claim that they can solve it with Smarty templates because they're "compiled." Total bullshit. The "rendering time" that Smarty claims is a lie. If you look through the output code, and trace back through to the underlying libraries, you'll see that the timer that calculates page generation time is only started AFTER the supposedly "compiled" code is parsed out by the interpreter, all objects instantiated, and all variables initialized. And the timer ends before the work is done to release all the objects and close the run. In other words, it leaves out the load time (either from disk or an object cache), the construction of the parse tree, all the initialization and ending time, etc.
As soon as anyone says "compiled templates" I know they don't know what they're talking about. I ask them if they've ever opened up one of their "compiled php templates" in a text editor. They don't think it's possible. Idiots or fools, because they're simply NOT CURIOUS!
No, I'm not forgetting any of that. The bytecode still has to be interpreted at runtime (same as all those "templating engines" don't really compile code - look at their output - it's not machine code). Ram caching of scripts (or even using an object cache) doesn't help that much either - you STILL are running an interpreter. Until the optimizer outputs machne code (not "byte-code", which is not capable of being run directly by the cpu), it will always be slower than c.
BTW - The Catholic church has already paid out more than a Billion dollars in settlements for priests who are child molesters.
"Former SD lawmaker convicted of raping foster daughters claims copyright of name.
PIERRE, S.D. (AP) -- A former South Dakota lawmaker convicted of raping his two foster daughters has sent news organizations what he claims is a copyright notice that seeks to prevent the use of his name without his consent.
A letter and an accompanying document labeled "Common Law Copyright Notice" said former state Rep. Ted Alvin Klaudt is reserving a common-law copyright of a trade name or trademark for his name. It said no one can use his name without his consent, and anyone who does would owe him $500,000.
Klaudt was convicted in 2007 on four counts of second-degree rape for touching his teenage foster daughters' breasts and genitals in phony examinations he said could help them sell their eggs to infertile couples. He was sentenced to 44 years in prison for rape and 10 more years after pleading guilty to two counts of witness tampering.
The notice, received by The Associated Press and several other news organizations Monday, carried a return address that matched that of the state prison in Springfield, where Klaudt is being held
:
1. For this discussion, I think optimal == fewer resources needed (time, ram, etc).
2. The locking primitives in the STL aren't fine-grained. Fine-grained locking gives more chance for your thread to use up its complete timeslice rather than have to wait because another thread is holding onto the "Big F****** Lock" for some shared resource. Additionally, you take a performance hit using the STL because stl classes have virtual method lookup tables. C code doesn't have virtual method lookup tables so it runs quicker.
3. As for the benchmarks, I benchmarked it personally to prove to all the windows weenies that the STL had no place in what we were trying to do, which was a server running on bsd unix - my c99 code was a MINIMUM of 4 times faster than the same code using the stl and c++.
The stl is not part of the c standard and never will be. I bought a hardcover copy of TR1 to see if it would finally give me reason to adopt the stl - it didn't, but at least I no longer wonder if I should bother with it. Maybe one day I'll find something that begs for it to be used, in which case sure, then I'll just use it... but until then, it doesn't offer me anything special and to be honest I find it aesthetically ugly. If it weren't so ugly-looking, I'd probably be less inclined to throw rocks at it - which means I probably wouldn't have written the benchmarks and just assumed that it was "almost as fast."
Please don't get me wrong - I like c++ as much as c. Classes can be a beautiful thing. But not all the time. The biggest mistake of Java was to try to make everything a class (the second-biggest was not to have a macro processor, but that's okay... there are ways around both limitations:-)
If you're using php, you're still going to be much slower than using the c api and multi-statements. Your queries don't have to be all related to one request - you can process 100 different requests for 100 different users requesting 500 different data sets, as ONE multi-statement. It's not just fast - it's like greased lightning in comparison to php, but it's fastest when you go to the trouble of serving diverse requests. If you use multi-statements one per page request (say for example to get the user info, name, their bio, whatever, as 4 queries) you're missing out on the real power. Set a 2 meg input buffer for the server, concatenate 1,000 different queries, and spool out the response.
The query optimizer will try to fix things so that there's the least disk thrashing possible, no duplicate reads, etc. It's not the easiest thing in the world, but when it works, you'll just be amazed at how fast things can be.
It's like the time I got a bit curious as to what the ultimate performance of my hard disk was. I wrote a routine in assembler, and it actually was able to read twice as much data a second as with c - which was only able to hit the disks' official limit. So even c has room for improvement, but the performance gains aren't nearly as much as the switch from, say, php to c.
Yes, it is harsh, but anyone who has not programmed in c and assembler, and then spouts off nonsense about how php can't possibly be 10x slower, doesn't have the programmer mind-set.
That mindset includes understanding the runtime environment - which means knowing the limitations of your tool - in this case php. That means you'll not "have" to do something in php because "when all you know is php, everything looks like it needs a script" rather than a different tool.
Case in point - generating test data. Say you want half a billion examples stuffed into a db. You can run a script, which will take forever, or you can write it in c. Real-life example - a "world" measuring 8k x 8k cells, with each cell also measuring something like (iirc) 100 x 80. You can write a script to generate all that, and it will take a week to run (actually, it would have taken 220 hours). Or you can take an hour to write a similar program in c, let it run during lunch (a longish lunch - an hour and a half), and get back to work in the afternoon.
That's why I'm a bit harsh on the "script it!" crowd. They're not very imaginative or curious, or they would learn c - it's not THAT hard.
You're still initializing your interpreter for EACH result set.
What do you mean by "initializing an interpreter"? It's already running, doesn't initialize even with each page in a well-designed system.
The hell you don't. You have to re-initialize all the variable store. You can't leave around values and variables left by the previous invocation.
Plus, php deliberately doesn't let you execute multiple statements with one call
I'm not defending PHP specifically here, because that kind of stupidity doesn't seem like it's implied by an interpreter. Again, you are talking about a limitation in the current MySQL bindings, not in the language itself, and certainly not in the general design of an interpreted language.
It IS deliberate. It's to help prevent sql injections.
For example, if you KNOW that you'll never get a response from the end user that's longer than 2k, as soon as you exceed that limit, stop reading from the socket,
And if you forget to do that, but you've only allocated the 2k, that's a buffer overflow -- a kind of security vulnerability which you cannot create in PHP. I'd rather have a DoS than a real security flaw any day.
Simple rule: learn how to count. If you can't keep track of your buffer stores, you shouldn't be writing any code that uses malloc. Which means you shouldn't be writing in c.
Then test it to make sure you didn't screw up. Always use the same entry point for code that manipulates the buffers, so that you NEVER "forget" to do sanity checks.
If you can't do this consistently, c simply isn't a language for you to use. It's not that hard. The reason programs contain lots of buffer overflows is because people are either lazy, under time pressure to cut corners or "just fix it | ad a feature to it", or simply can't do zero-based math (which is why so many overflows are 1-byte errors).
And you're wrong about PHP being free of buffer overruns - seek and ye shall find.
Actually no. PHP is, like all interpreted languages, slower. Also, it doesn't matter if you keep a pool of processes active - a fastcgi script is still running as an interpreter, so it's always going to be slower than a chunk of c code loaded directly into the server.
Also you're comparing Apache to a custom written, purpose-built web server. You could probably write said web server in PHP and it would be faster than the Apache/PHP combo.
You might want to rithink that. Why would anyone want to write a web server in a slow interpreter like PHP when they can get the performance benefits and flexibility of c?
Slashdot Mirror
I vote for Satan Clause!
What if your input signal IS a sine wave? Then you only need 1.
I ran the source through an optimizing compiler with the command gcc (gods commands compiler)
gcc religious_texts.src -oda_rulez --with-best-result --cpu=human --arch all --check_out-of-bounds --licence gpl2.0 -nohell -nopurgatory -saveall -Dheaven 1 -Dhell NULL -Dchurch NULL -Dreligion "RELIGION_ANY | RELIGION_NONE"
First the preprocessor stripped out all the white space, newlines, superfluous stuff like page numbers and comments, and all the #ifdef stuff that defined obsolete, no-longer-supported architectures.
Then on the compilers first pass, it compiled everything that was left, which wasn't much, to tell you the truth.
Then came the optimizing pass. Out came the redundant loops, the busy-wait code, the code that was unreachable (aka "dead code"); By invoking the "--with-best-result option" most conditionals (if/else, switch) could be optimized out and only the one true path taken. Duplicate code was removed.
The whole compile time took 40 days and 40 nights - most of it was the optimizer.
Finally, I ran the resulting binary - ./da_rulez
Out came one line.
"Hello, world! Treat others as you would have them treat you."
Turns out that beyond that core concept, everything else is either contradiction, commentary, corruption, or crap.
Merry Christmas, Happy Holidays, whatever floats your boat.
May I suggest you check in the alt.recipes.babies news group.
True, he's so fallible that when I looked up "FAIL" it had his picture.
Then again, he's just a politician who got voted in by a small group, same as the president of the usa was voted in by the electoral college.
Fact - the Catholic Church has paid out over ONE BILLION DOLLARS to settle child molestation suits by 2002, and the number grows and grows and grows.
But what do you expect from an organization that teaches that sex is bad except with their seal of approval, that gays and lesbians are going to hell even though same-sex activity of all kinds is normal in the animal kingdom, and also normal in humans, that you should be stoned to death for shopping on Sunday, and that cannibalism brings you closer to god ("take, eat, this is my body").
I wouldn't be surprised if there's a priest somewhere right now sewing an "alter boy meat suit" a la Hannibal Lecter. Or reading the alt.recipes.baby newsgroup.
That just makes god into a shitty parent and a shitty example to follow.
"Someone has to pay for this!" Why? "Because those are MY rules!" Well, your rules suck. That's not forgiveness. That's "eye-for-an-eye."
"I love you all so much I killed my kid for you!" Well, we never asked for that, so you should accept responsibility for your infanticide. "I did it for YOU!" Why? "Because you're going to hell otherwise!" Why? "Because you disobeyed my laws!" In other words, you don't know the meaning of forgiveness. Fuck you.
Any parent that would torture and kill their own kid is not an example to follow. Any god that would ask one of their followers to do the same (and god did ask this of Abraham) is fucked up. Anyone who follows such a god deserves to go to hell.
It would be the height of irony if god existed and in her judgment only atheists qualify for heaven, because the good we do is done without the guilt of sin or fear of punishment by god.
The bible says that satan himself believes that jesus was the son of god.
By your argument, the devil is a christian.
After all, the bible can't be wrong, right?
It also explains why so many christians act like they're in a real hurry to go to hell.
Now let's extend it. This means that only atheists go to heaven.
After all, you're either going to hell or heaven,; you can believe that jesus was gods son, like satan did, and he's supposed to be in hell, so since unbelievers can't be in the same place as believers, and since unbelievers have to go "somewhere", and the only other option is heaven, atheists go to heaven. And since believers can't go the same place as unbelievers, they ALL go to hell.
Or there is no god, there is no jesus, there is no devil, there is no original sin, and there is no such thing as a pope - just another nazi dictator.
Also, your #10 is wrong. Atheists KNOW there is no such thing as god. Agnostics say you can't know for sure one way or the other, so agnostics can't include atheists.
Atheists regard agnostics as wishy-washy fence-sitters trying to hedge their bets.
Sure you can. "Catholic" means "universal" - and we all know that those "Universal" churches are all just cults (but then again, so are all religions).
Besides, the pope can't claim trademark OR copyright, since both predated trademark and copyright law, and the church never registered them within the delays provided by law, they're still in the public domain. You can't "un-public-domain" something. So much for "papal infallibility".
Looks like the pope is showing his jackboot nazi roots by trying to declare he is above the law.
Repeat after me - bytecode needs an interpreter at runtime. It is not "compiled" in any true sense of the word, any more than the output of the c preprocessor could be called "compiled".
Bytecode is an intermediate representation of your program that is further interpreted at runtime, not compiled code that can be run on a real-world cpu. Your script is translated to bytecode as part of the process, whether it's done in the web server when the script is loaded and run, or via APC. You can see this because certain errors cause the program to not parse during the conversion to bytecode; contrast with logic errors, which will cause it to fail partway through execution.
This will be slower than c because you're still interpreting at runtime - you've just skipped the "strip out the comments and extraneous whitespace and represent it as bytecodes and references to data" portion.
I have never seen a non-trivial program in THIS universe that uses the stl and doesn't encapsulate it in a class, and then derive from that class. So your code is going to have some vtables, and its going to be slower than straight c, and it's going to be WAY slower than php. What universe do YOU live in where people use the stl but not objects?
No - allocated a 64k buffer and read into it 64k at a time
And just where would one go to get a non-sucky-libc-posix-read() 2 decades ago? And some non-sucky-hardware to go with it? And a non-sucky-posix-compliant-optimizing-c-compiler?
I know, I'll just whip out Mr. Time Machine and ... no, if I could do that, I'd corner the stock market, start a cult that would make L. Ron Hubbard look like a poseur, and alter the time line so we didn't abandon the moon (hence the cult :-). And I'd make sure that the Motorola 68k series of chips won the war, not the Intel x86. And maybe have Apple buy Microsoft, for the lulz.
The problem is always one of access rights - chunk of code a says "I want the next item in the list", gets suspended, chunk of code b says "delete the last item", chunk of code a resumes and gets back a pointer to non-valid data. The traditional way to solve this is to lock on $SOMETHING. Other work-arounds are for the runtime environment to guarantee to the programmer that certain statements will get executed atomically, so you can guarantee setting/clearing a flag, or changing a function pointer (but what happens when two processes BOTH try to set two flags and each one only sets one ... so you end up with having to either put in code to detect a deadlock, or you end up with a 3rd flag that guards the first two, which wrecks code that isn't aware of the 3rd flag, so you end up with a real mess anyways and say "what the heck, let's just remove the first two flags and check only the third" so you're not so fine-grained. Done often enough, you end up back at the "one big lock" level).
In the end it depends on the application you're writing, and whether data that's slightly "dirty" is okay.
Any program that uses the stl is going to be a c++ program by definition. It will have classes that use the stl (how often do you see a c++ program with no classes?), and since most people don't write one-off classes, and you have to guard access to the stl with locking primitives anyway (STL_LOCK, STL_UNLOCK) which the programmer usually stuffs into a class and then derives their objects so that they don't have to worry about locking, it's pretty much inevitable that you'll end up with vtables in your runtime when you use the stl.
Hey, I didn't write that code - I just nuked it wherever possible because it is fugly; Besides, the STL doesn't really belong in an OOP environment - even Stephanov agrees that the STL is not OOP., so no wonder it looks ugly.
But back "sort of" on topic - how often have you seen a non-trivial c++ program that used the stl that didn't also use inheritance?
And use of that particular aspect of the class is incompatible with the rest of the class functionality. For example, no prepared statements - which is the only really compelling reason to use mysqli, despite its' higher overhead at runtime. 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 - try it and you'll see quickly enough. Plus, you're still paying the speed penalty for interpreted code, which is what the article is all about.
If the bottleneck were the database, you couldn't make your app 10x (or even 2x) faster by switching to c. The bottleneck is the interpreter, not the db.
The people who claim the bottleneck is the db haven't tried to benchmark the difference in speed between using php and using c to access the db, or they'd know that it's like night and day.
It depends on what type of data you're trying to generate. Terrain maps that actually "make sense" are a bit more complex than completely random data like $RANDOM_LAST_NAME + "," + $RANDOM_FIRST_NAME, for example, so once you generate a grid, you've got to make it sane, and it's got to have a pattern that looks realistic to a human. You can't for example, have a river that just goes in a circle.
Say you have 400 front-facing server threads that are executing ... your back-end process grabs any that have data ready, prepares one large multi-statement query, runs it, iterates through the results, and gives each back it's proper response. Alternatively, you might want to load specific modules into your back-end process that can respond to specific front-end requests that need to generate and process, say, 100 queries - better to do that in one shot than to have php try to do it.
Curiosity is a *GOOD THING* - it's both how we advance the state of the art and how we solve our everyday problems. It's certainly a lot better than most responses, which try to claim stupidity like "running compiled byte-code" - which plainly shows they don't know that "byte-code" is not machine code, and needs further interpretation at runtime. Or like the people who claim that they can solve it with Smarty templates because they're "compiled." Total bullshit. The "rendering time" that Smarty claims is a lie. If you look through the output code, and trace back through to the underlying libraries, you'll see that the timer that calculates page generation time is only started AFTER the supposedly "compiled" code is parsed out by the interpreter, all objects instantiated, and all variables initialized. And the timer ends before the work is done to release all the objects and close the run. In other words, it leaves out the load time (either from disk or an object cache), the construction of the parse tree, all the initialization and ending time, etc.
As soon as anyone says "compiled templates" I know they don't know what they're talking about. I ask them if they've ever opened up one of their "compiled php templates" in a text editor. They don't think it's possible. Idiots or fools, because they're simply NOT CURIOUS!
No, I'm not forgetting any of that. The bytecode still has to be interpreted at runtime (same as all those "templating engines" don't really compile code - look at their output - it's not machine code). Ram caching of scripts (or even using an object cache) doesn't help that much either - you STILL are running an interpreter. Until the optimizer outputs machne code (not "byte-code", which is not capable of being run directly by the cpu), it will always be slower than c.
http://www.baltimoresun.com/business/sns-ap-us-inmate-name-copyright,0,6423024.story
BTW - The Catholic church has already paid out more than a Billion dollars in settlements for priests who are child molesters.
"Former SD lawmaker convicted of raping foster daughters claims copyright of name.
PIERRE, S.D. (AP) -- A former South Dakota lawmaker convicted of raping his two foster daughters has sent news organizations what he claims is a copyright notice that seeks to prevent the use of his name without his consent.
A letter and an accompanying document labeled "Common Law Copyright Notice" said former state Rep. Ted Alvin Klaudt is reserving a common-law copyright of a trade name or trademark for his name. It said no one can use his name without his consent, and anyone who does would owe him $500,000.
Klaudt was convicted in 2007 on four counts of second-degree rape for touching his teenage foster daughters' breasts and genitals in phony examinations he said could help them sell their eggs to infertile couples. He was sentenced to 44 years in prison for rape and 10 more years after pleading guilty to two counts of witness tampering.
The notice, received by The Associated Press and several other news organizations Monday, carried a return address that matched that of the state prison in Springfield, where Klaudt is being held :
1. For this discussion, I think optimal == fewer resources needed (time, ram, etc).
2. The locking primitives in the STL aren't fine-grained. Fine-grained locking gives more chance for your thread to use up its complete timeslice rather than have to wait because another thread is holding onto the "Big F****** Lock" for some shared resource. Additionally, you take a performance hit using the STL because stl classes have virtual method lookup tables. C code doesn't have virtual method lookup tables so it runs quicker.
3. As for the benchmarks, I benchmarked it personally to prove to all the windows weenies that the STL had no place in what we were trying to do, which was a server running on bsd unix - my c99 code was a MINIMUM of 4 times faster than the same code using the stl and c++.
The stl is not part of the c standard and never will be. I bought a hardcover copy of TR1 to see if it would finally give me reason to adopt the stl - it didn't, but at least I no longer wonder if I should bother with it. Maybe one day I'll find something that begs for it to be used, in which case sure, then I'll just use it ... but until then, it doesn't offer me anything special and to be honest I find it aesthetically ugly. If it weren't so ugly-looking, I'd probably be less inclined to throw rocks at it - which means I probably wouldn't have written the benchmarks and just assumed that it was "almost as fast."
Please don't get me wrong - I like c++ as much as c. Classes can be a beautiful thing. But not all the time. The biggest mistake of Java was to try to make everything a class (the second-biggest was not to have a macro processor, but that's okay ... there are ways around both limitations :-)
The query optimizer will try to fix things so that there's the least disk thrashing possible, no duplicate reads, etc. It's not the easiest thing in the world, but when it works, you'll just be amazed at how fast things can be.
It's like the time I got a bit curious as to what the ultimate performance of my hard disk was. I wrote a routine in assembler, and it actually was able to read twice as much data a second as with c - which was only able to hit the disks' official limit. So even c has room for improvement, but the performance gains aren't nearly as much as the switch from, say, php to c.
Besides, we need more holy brace wars :-)
Yes, it is harsh, but anyone who has not programmed in c and assembler, and then spouts off nonsense about how php can't possibly be 10x slower, doesn't have the programmer mind-set.
That mindset includes understanding the runtime environment - which means knowing the limitations of your tool - in this case php. That means you'll not "have" to do something in php because "when all you know is php, everything looks like it needs a script" rather than a different tool.
Case in point - generating test data. Say you want half a billion examples stuffed into a db. You can run a script, which will take forever, or you can write it in c. Real-life example - a "world" measuring 8k x 8k cells, with each cell also measuring something like (iirc) 100 x 80. You can write a script to generate all that, and it will take a week to run (actually, it would have taken 220 hours). Or you can take an hour to write a similar program in c, let it run during lunch (a longish lunch - an hour and a half), and get back to work in the afternoon.
That's why I'm a bit harsh on the "script it!" crowd. They're not very imaginative or curious, or they would learn c - it's not THAT hard.
The hell you don't. You have to re-initialize all the variable store. You can't leave around values and variables left by the previous invocation.
It IS deliberate. It's to help prevent sql injections.
Simple rule: learn how to count. If you can't keep track of your buffer stores, you shouldn't be writing any code that uses malloc. Which means you shouldn't be writing in c.
Then test it to make sure you didn't screw up. Always use the same entry point for code that manipulates the buffers, so that you NEVER "forget" to do sanity checks.
If you can't do this consistently, c simply isn't a language for you to use. It's not that hard. The reason programs contain lots of buffer overflows is because people are either lazy, under time pressure to cut corners or "just fix it | ad a feature to it", or simply can't do zero-based math (which is why so many overflows are 1-byte errors).
And you're wrong about PHP being free of buffer overruns - seek and ye shall find.
Actually no. PHP is, like all interpreted languages, slower. Also, it doesn't matter if you keep a pool of processes active - a fastcgi script is still running as an interpreter, so it's always going to be slower than a chunk of c code loaded directly into the server.
You might want to rithink that. Why would anyone want to write a web server in a slow interpreter like PHP when they can get the performance benefits and flexibility of c?