For now, with SATA drives at least, the logical sector size exposed to the OS will remain 512 bytes. Several years down the road that will change, because it is simpler to have the logical and physical sector sizes be the same.
In practice, though, as long as you are writing blocks aligned on 4KB boundaries to partitions aligned on 4KB boundaries (such that the blocks being written are aligned with the underlying physical sectors), it won't make much of a difference whether the logical sector size is 512 bytes or 4KB bytes.
With contemporary filesystems and databases that will almost always be the case, provided the partition alignment is correct for 4KB writes.
Any change in sector size that doesn't affect the filesystem block size will not affect the number of KB required to store a file at all. Since virtually every filesystem already uses 4 KB block sizes by default a change to 4KB logical or physical sector sizes will not have an effect on storage requirements.
That's insane. ECC at the hardware / firmware level corrects the vast majority of bit errors transparently in a manner that is invisible to the operating system. If you took out sector level ECC, the drives would be useless in anything other than a ZFS RAID configuration, and even then performance would drop in the presence of trivially ECC correctable errors, due to the re-reads and stripe reconstructions at the filesystem level.
Drive performance would probably drop because the heads would have to stay in closer alignment without the ability of ECC to correct data read errors caused by small vibrations and electrical noise. In addition, sector relocations would probably increase because tiny flaws that do not impair the ability of a drive to write an ECC correctable sector would force the drive to remap that sector to another part of the disk.
It is a similar issue with various wire level data transmission schemes. If DSL connections did not use error correcting codes, they would suffer much higher packet loss rates than they do now, especially at distance. Most those packets would generally get retransmitted due to transport level checksum errors, but why resort to performance impairing fall back measures when the problem can be largely eliminated at a lower level?
Those are "logical" sectors, which can be different from the physical sector size. According to the Anandtech article the Western Digital hard drive model numbers that end with "EARS" use the larger, 4KB physical sector size, while presenting a 512 byte logical sector size to the operating system for compatibility reasons.
Please note, of course, that the logical sector size is a drive interface level concept distinct from the filesystem cluster or block size. Filesystem block sizes have generally been larger than the logical or physical sector size for quite some time.
That could have been true had NetBIOS commonly been run over a routable protocol and had NetBIOS name servers supported a recursive name resolution scheme. Most NetBIOS networks in the early days were far from it. If you don't have a routable protocol and a means to configure what address the name server lives on, and you don't have an inter-name server name query resolution protocol, you end up with the much more typical broadcast and election scheme on small networks and perhaps a handful of name servers on large ones.
I mean, when Microsoft wanted a recursive name resolution protocol for Active Directory, they didn't invent a way to extend NetBIOS name resolution to make it recursive, instead they added a bunch of extensions to DNS for the purpose. Not that NetBIOS name resolution couldn't have been so extended, of course. DHCP solves the NBNS (now "WINS") name server determination problem quite well too., and NetBIOS over TCP ("NBT") the routing problem.
IPX routing is severely limited compared to IP routing, of course. RIP style route distribution, 15 hop limit, etc. I suppose that could have all been fixed if IPX had taken over the world instead of TCP/IP. In some ways IPX is more like IPv6 than IPv4 is. Too bad IPX had to be weighted down with a number of chatty, broadcast heavy higher level protocols. IPX networks got the equivalent of DNS, what, ten years later?
Once upon a time, there was a standard INT 5C interface that was used by DOS programs to control the the NetBIOS functions built into some LAN adapter cards or other add on NetBIOS software. That no doubt is why the functionality was called "NetBIOS", because it was intended as a networking oriented parallel with the regular ROM BIOS.
"NetBIOS" is an awfully funny name for a network protocol, and of course originally it wasn't a network protocol at all, it was a higher level interface to lower level protocols such as NBF and NBT. Of course NetBEUI (NetBIOS Extended User Interface) wasn't originally a "protocol" either, but later became associated with the non-routable NetBIOS Frames or NBF protocol for some strange reason.
Not that this isn't a good idea for other reasons, but how exactly does this requirement flow from the Sarbanes-Oxley Act? I mean, the whole thing is about financial controls, accuracy, disclosure, and reporting. I suppose your network could impair the timeliness of some reports, but it is hard to see in general how it is going to affect their accuracy.
The premise of the article is right on target, in terms of power efficiency for the entire front end. You are right, however, that if power consumption or hardware overhead is a sufficient problem, you could probably gain a marginal amount of performance by going to C instead of C++, although far short of the reduction one could obtain by making the first step. The question is one of balance.
If your requirements make it optimal to run a language that is running behind the state of the art in interpreted languages by nearly three decades because it is easier for some people to learn, that is great. Compared to something like Applesoft BASIC, which actually started out with an intelligent, highly optimized design (byte code even!), PHP started out as a first class hack. And like most first class hacks, short sightedness in the original design tends to cripple all future versions, even when it is far past time for the system to "grow up".
And that, unfortunately, is why the future of PHP looks approximately as bright as the future of Perl. The duct tape of the Internet. Not that there isn't a sizeable niche for that sort of thing.
Are there any languages other than C and assembly language that suffer from string buffer overflow problems? C++ certainly doesn't, not if you use any kind of C++ string library, and one would of course be insane to write non-trivial C++ code without one. That is why no one does.
One of the things that shocks me is that parsing to bytecode is considered a major performance optimization in the PHP world. Every BASIC interpreter in the world did that thirty years ago, on machines with less than 16K of RAM. Otherwise useful programs wouldn't fit in memory, to say nothing of running at a non-glacial speed. Can't throw cycles away when dealing with a 1 Mhz CPU.
If you then rewrote the same program in C++, to do exactly the same things
If one rewrote a large C++ program so that it didn't use any non-scalar value types, never used arrays of structures, never placed anything other than scalars and pointers on the stack, and relied exclusively on garbage collection for memory management, even for temporary variables, then it would probably run as slow as a Java program compiled ahead of time too, if not as bad as a Java program that has to be JITed before it comes up to speed.
That is not to say that Java can't be very effective in a server environment for a large class of applications. And certainly a good Java programmer has to be aware of what is going on at a relatively low level with regard to dynamic allocation, garbage collection, etc.
Absolutely. But if the case can be made for using C/C++ for a web application front end anywhere, it is with a high volume low revenue per visitor site like Facebook. I am not sure exactly what Google is using for it these days, but I wouldn't dream of using anything other than C/C++ for search page result generation. Talk about pouring money down the drain.
If I were Amazon, on the other hand, I don't think C++ would be my first choice for the front end. Amazon can afford the overhead of Java/C# or whatever much better than a free site like Facebook can.
With modern techniques, just about any language can be sufficiently compiled to run within 1/2 the speed of C
If only this were true. In the real world, Java is dead on the client side precisely because a large Java application cannot be compiled (let alone JITed) to come within half the speed of an equivalent application written in C/C++. Dynamic languages are worse in the sense that they tend to compile to native code much more poorly than a statically typed language like Java, although this is indeed changing.
When you can run a word processor written in Javascript on a thousand page document with 1/2 the speed of a word processor written in C/C++, and not wait forever for it to start up, we will know that dynamic language compilers have arrived. I would be impressed if someone could do that with Java, especially without resorting to expedients like SWT, to say nothing of library after library of C support routines - stuff Java simply (currently) cannot do with any reasonable speed, no matter how good the compiler is.
And it need not be said that no one is going to write a word processor in Perl, Python, or PHP anytime soon, although once the appropriate JITs are out there it would be interesting to see someone try.
All you have demonstrated there is that statically compiled implementation A of a regular expression library is more efficient than statically compiled implemenation B of a regular expression library. This is a contest that PHP cannot win. The implementation PHP uses is not written in PHP, but rather something like C.
That said, programmers who have better alternatives do not rely on regular expression parsers for casual processing in performance critical code. Regular expression engieer tend to be much slower than the alternatives in any compiled language. Of course hand coding the equivalent code takes longer.
You will never find a competitive compiler that uses dynamically parsed regular expressions to do language parsing for precisely this reason. It would slow the parsing phase down by a factor of ten or more due to two problems - first the regular expressions themselves have to be parsed, and then the resulting state machine has to be interpreted. In other words regular expression libraries are a microcosm of the situation with PHP itself - provided the patterns are known ahead of time, hand written native code to do the same thing is much faster.
High traffic sites are not interpreted on the fly over and over again
Substitute "parsed" for "interpreted" and I agree 100%. There are plenty of high traffic sites that don't JIT every last bit of code, however, and are most definitely interpreted for everything that is not compiled to native code. Sites that use JVMs are typical.
However, I am shocked that special effort is required for PHP to cache intermediate code at all. Certainly mod_perl, mod_python, and the various CFML engines don't require any special effort to cache intermediate code for each page. That is to say nothing of JIT, although there appears to be some progress being made there with regard to PHP.
Ergo, it is going to reduce the processing necessary on the server to do any given job
Any given job, yes. But if there are a lot more "jobs" (i.e. more requests that require server side processing), the efficiency of the language used on the server side tends to become more critical, not less, especially if the per request overhead is significant, something that happens to be one of Facebook's primary complaints about PHP.
I am not saying that everyone should go out and write large web applications in C++. I am saying rather that dynamic languages have serious problems that need to be addressed before they become ideal for such development. The best way I know to to address it is with static analysis tools, which seem to be hard to come by for dynamic languages.
If a type system creates more problems than it is worth, you can certainly use a crash and burn development methodology with a dynamically typed language. Mostly though, the trend in dynamic languages is to add type annotations, not take them away.
Sufficiently large systems (Google: "programming in the large") are rarely developed in unannotated dynamic languages because they are simply too fragile - too many errors cannot be caught before deployment. If it was a net loss, nobody would write programs in statically typed languages, ever.
Developers that are diligent enough to make only 1 memory-related bug/year can certainly spell variable names correctly
If they are stuck using a language that doesn't check anything until runtime, sure.
If you have dynamic, you rely on unit tests
But how exactly do you go about doing unit tests of the front end of a web application? The short answer is, you can't, not without unusually sophisticated tools. This is a serious problem even if you write the web application in C++, due to all the javascript stuff that lives on the browser these days.
There are a lot of things than *can* be checked ahead of time with a dynamic language, it is just that no one does, because the languages do not require that it be done. That is something that ought to be fixed. Surely someone out there has written a static analysis tool for Python or PHP that finds a large class of programming errors prior to runtime. Or even better, a static analysis tool that analyzes a dynamic language web app, client side javascript, an SQL database and the interactions between them? Anyone?
The exception proves the rule. FORTRAN (like COBOL) is certainly more computationally efficient than the vast majority of languages today, so if you are in a performance / overhead sensitive environment, there can be a lot to be said for such languages. It is just not the sort of thing people normally do without such constraints, because there are other, more modern languages that tend to be more suitable to the task.
No one is going to write an operating system kernel in FORTRAN, for example, although I have no doubt that it is actually possible.
1. If you are getting more than one memory corruption problem per programmer year in C++, something is seriously wrong with the competence of your developers.
2. The edit test cycle is fine the first time you develop a page or whatever. Then you need to make a change to an internal interface used by thousands of pages. Testing all of them is not fun. A statically typed interface can be checked by a compiler in a fraction of the time.
Cacheing pages or page components is great if the cache hit rate is sufficiently high. For many applications (and Facebook is among them), the cache hit rate is far too low to make cacheing *pages* worthwhile. Of course Facebook caches a large amount of non-page data (apart from the caching done in the database), and couldn't operate without it. All that cached data is assembled dynamically for virtually every page request, however. The original article referred to is rather informative on the subject.
10:1 is a conservative estimate of the *efficiency* of page generation in PHP vs. C++. If you are not CPU bound on the page generation servers, an increase in page generation efficiency won't make a perceptible difference.
However, if you have a large number of servers that do nothing other than page generation because the page generation process is CPU bound, how efficient that process is makes a big difference in terms of how many servers you require. So small sites shouldn't care, and very large sites should care *a lot*.
FORTRAN is designed to do numeric processing. FORTRAN compilers are very good at optimizing such code. FORTRAN is not at all optimal for doing much of anything else.
Similarly, with the right framework, someone might write a general purpose web application in C++, because you can make string processing code a relatively painless exercise with the right class libraries. Plain old C, on the other hand, is much worse - essentially a language designed not to do string handling very well or very reliably.
Even with C++, there is an enormous interoperability and efficiency problem with strings of different flavors, and I would put rank that problem as #1 on a list of why few people do general purpose business programming in C++. I have *never* seen a standard C++ library compatible C++ string implementation that was worth using in both compile time and run time efficiency terms. Certainly the implementation that comes with GCC doesn't qualify...
In general code written in a dynamically typed language like PHP is harder to test than code written in a statically typed language like C++. The reason why is that statically typed language compilers catch hundreds of problems at compile time that dynamic languages typically cannot catch until run time, and with complete code coverage at that. Misspelled variables and other minor typos anyone?
In a sufficiently large project, all the time one might save not going through an extended compile cycle quickly gets eaten up by the extra testing overhead, testing which for user interface intensive applications is rather difficult to automate.
Of course the developers have to know what they are doing. If you run into more than one dangling point or array overflow problem per ten thousand lines of code, someone is either ignorant or careless. C++ programming is not for code monkeys.
Slashdot Mirror
For now, with SATA drives at least, the logical sector size exposed to the OS will remain 512 bytes. Several years down the road that will change, because it is simpler to have the logical and physical sector sizes be the same.
In practice, though, as long as you are writing blocks aligned on 4KB boundaries to partitions aligned on 4KB boundaries (such that the blocks being written are aligned with the underlying physical sectors), it won't make much of a difference whether the logical sector size is 512 bytes or 4KB bytes.
With contemporary filesystems and databases that will almost always be the case, provided the partition alignment is correct for 4KB writes.
Any change in sector size that doesn't affect the filesystem block size will not affect the number of KB required to store a file at all. Since virtually every filesystem already uses 4 KB block sizes by default a change to 4KB logical or physical sector sizes will not have an effect on storage requirements.
That's insane. ECC at the hardware / firmware level corrects the vast majority of bit errors transparently in a manner that is invisible to the operating system. If you took out sector level ECC, the drives would be useless in anything other than a ZFS RAID configuration, and even then performance would drop in the presence of trivially ECC correctable errors, due to the re-reads and stripe reconstructions at the filesystem level.
Drive performance would probably drop because the heads would have to stay in closer alignment without the ability of ECC to correct data read errors caused by small vibrations and electrical noise. In addition, sector relocations would probably increase because tiny flaws that do not impair the ability of a drive to write an ECC correctable sector would force the drive to remap that sector to another part of the disk.
It is a similar issue with various wire level data transmission schemes. If DSL connections did not use error correcting codes, they would suffer much higher packet loss rates than they do now, especially at distance. Most those packets would generally get retransmitted due to transport level checksum errors, but why resort to performance impairing fall back measures when the problem can be largely eliminated at a lower level?
Those are "logical" sectors, which can be different from the physical sector size. According to the Anandtech article the Western Digital hard drive model numbers that end with "EARS" use the larger, 4KB physical sector size, while presenting a 512 byte logical sector size to the operating system for compatibility reasons.
Please note, of course, that the logical sector size is a drive interface level concept distinct from the filesystem cluster or block size. Filesystem block sizes have generally been larger than the logical or physical sector size for quite some time.
That could have been true had NetBIOS commonly been run over a routable protocol and had NetBIOS name servers supported a recursive name resolution scheme. Most NetBIOS networks in the early days were far from it. If you don't have a routable protocol and a means to configure what address the name server lives on, and you don't have an inter-name server name query resolution protocol, you end up with the much more typical broadcast and election scheme on small networks and perhaps a handful of name servers on large ones.
I mean, when Microsoft wanted a recursive name resolution protocol for Active Directory, they didn't invent a way to extend NetBIOS name resolution to make it recursive, instead they added a bunch of extensions to DNS for the purpose. Not that NetBIOS name resolution couldn't have been so extended, of course. DHCP solves the NBNS (now "WINS") name server determination problem quite well too., and NetBIOS over TCP ("NBT") the routing problem.
IPX routing is severely limited compared to IP routing, of course. RIP style route distribution, 15 hop limit, etc. I suppose that could have all been fixed if IPX had taken over the world instead of TCP/IP. In some ways IPX is more like IPv6 than IPv4 is. Too bad IPX had to be weighted down with a number of chatty, broadcast heavy higher level protocols. IPX networks got the equivalent of DNS, what, ten years later?
NetBIOS is NOT an "API"
Once upon a time, there was a standard INT 5C interface that was used by DOS programs to control the the NetBIOS functions built into some LAN adapter cards or other add on NetBIOS software. That no doubt is why the functionality was called "NetBIOS", because it was intended as a networking oriented parallel with the regular ROM BIOS.
"NetBIOS" is an awfully funny name for a network protocol, and of course originally it wasn't a network protocol at all, it was a higher level interface to lower level protocols such as NBF and NBT. Of course NetBEUI (NetBIOS Extended User Interface) wasn't originally a "protocol" either, but later became associated with the non-routable NetBIOS Frames or NBF protocol for some strange reason.
Not that this isn't a good idea for other reasons, but how exactly does this requirement flow from the Sarbanes-Oxley Act? I mean, the whole thing is about financial controls, accuracy, disclosure, and reporting. I suppose your network could impair the timeliness of some reports, but it is hard to see in general how it is going to affect their accuracy.
The premise of the article is right on target, in terms of power efficiency for the entire front end. You are right, however, that if power consumption or hardware overhead is a sufficient problem, you could probably gain a marginal amount of performance by going to C instead of C++, although far short of the reduction one could obtain by making the first step. The question is one of balance.
If your requirements make it optimal to run a language that is running behind the state of the art in interpreted languages by nearly three decades because it is easier for some people to learn, that is great. Compared to something like Applesoft BASIC, which actually started out with an intelligent, highly optimized design (byte code even!), PHP started out as a first class hack. And like most first class hacks, short sightedness in the original design tends to cripple all future versions, even when it is far past time for the system to "grow up".
And that, unfortunately, is why the future of PHP looks approximately as bright as the future of Perl. The duct tape of the Internet. Not that there isn't a sizeable niche for that sort of thing.
Are there any languages other than C and assembly language that suffer from string buffer overflow problems? C++ certainly doesn't, not if you use any kind of C++ string library, and one would of course be insane to write non-trivial C++ code without one. That is why no one does.
One of the things that shocks me is that parsing to bytecode is considered a major performance optimization in the PHP world. Every BASIC interpreter in the world did that thirty years ago, on machines with less than 16K of RAM. Otherwise useful programs wouldn't fit in memory, to say nothing of running at a non-glacial speed. Can't throw cycles away when dealing with a 1 Mhz CPU.
If you then rewrote the same program in C++, to do exactly the same things
If one rewrote a large C++ program so that it didn't use any non-scalar value types, never used arrays of structures, never placed anything other than scalars and pointers on the stack, and relied exclusively on garbage collection for memory management, even for temporary variables, then it would probably run as slow as a Java program compiled ahead of time too, if not as bad as a Java program that has to be JITed before it comes up to speed.
That is not to say that Java can't be very effective in a server environment for a large class of applications. And certainly a good Java programmer has to be aware of what is going on at a relatively low level with regard to dynamic allocation, garbage collection, etc.
Absolutely. But if the case can be made for using C/C++ for a web application front end anywhere, it is with a high volume low revenue per visitor site like Facebook. I am not sure exactly what Google is using for it these days, but I wouldn't dream of using anything other than C/C++ for search page result generation. Talk about pouring money down the drain.
If I were Amazon, on the other hand, I don't think C++ would be my first choice for the front end. Amazon can afford the overhead of Java/C# or whatever much better than a free site like Facebook can.
With modern techniques, just about any language can be sufficiently compiled to run within 1/2 the speed of C
If only this were true. In the real world, Java is dead on the client side precisely because a large Java application cannot be compiled (let alone JITed) to come within half the speed of an equivalent application written in C/C++. Dynamic languages are worse in the sense that they tend to compile to native code much more poorly than a statically typed language like Java, although this is indeed changing.
When you can run a word processor written in Javascript on a thousand page document with 1/2 the speed of a word processor written in C/C++, and not wait forever for it to start up, we will know that dynamic language compilers have arrived. I would be impressed if someone could do that with Java, especially without resorting to expedients like SWT, to say nothing of library after library of C support routines - stuff Java simply (currently) cannot do with any reasonable speed, no matter how good the compiler is.
And it need not be said that no one is going to write a word processor in Perl, Python, or PHP anytime soon, although once the appropriate JITs are out there it would be interesting to see someone try.
All you have demonstrated there is that statically compiled implementation A of a regular expression library is more efficient than statically compiled implemenation B of a regular expression library. This is a contest that PHP cannot win. The implementation PHP uses is not written in PHP, but rather something like C.
That said, programmers who have better alternatives do not rely on regular expression parsers for casual processing in performance critical code. Regular expression engieer tend to be much slower than the alternatives in any compiled language. Of course hand coding the equivalent code takes longer.
You will never find a competitive compiler that uses dynamically parsed regular expressions to do language parsing for precisely this reason. It would slow the parsing phase down by a factor of ten or more due to two problems - first the regular expressions themselves have to be parsed, and then the resulting state machine has to be interpreted. In other words regular expression libraries are a microcosm of the situation with PHP itself - provided the patterns are known ahead of time, hand written native code to do the same thing is much faster.
High traffic sites are not interpreted on the fly over and over again
Substitute "parsed" for "interpreted" and I agree 100%. There are plenty of high traffic sites that don't JIT every last bit of code, however, and are most definitely interpreted for everything that is not compiled to native code. Sites that use JVMs are typical.
However, I am shocked that special effort is required for PHP to cache intermediate code at all. Certainly mod_perl, mod_python, and the various CFML engines don't require any special effort to cache intermediate code for each page. That is to say nothing of JIT, although there appears to be some progress being made there with regard to PHP.
Ergo, it is going to reduce the processing necessary on the server to do any given job
Any given job, yes. But if there are a lot more "jobs" (i.e. more requests that require server side processing), the efficiency of the language used on the server side tends to become more critical, not less, especially if the per request overhead is significant, something that happens to be one of Facebook's primary complaints about PHP.
I am not saying that everyone should go out and write large web applications in C++. I am saying rather that dynamic languages have serious problems that need to be addressed before they become ideal for such development. The best way I know to to address it is with static analysis tools, which seem to be hard to come by for dynamic languages.
If a type system creates more problems than it is worth, you can certainly use a crash and burn development methodology with a dynamically typed language. Mostly though, the trend in dynamic languages is to add type annotations, not take them away.
Sufficiently large systems (Google: "programming in the large") are rarely developed in unannotated dynamic languages because they are simply too fragile - too many errors cannot be caught before deployment. If it was a net loss, nobody would write programs in statically typed languages, ever.
Developers that are diligent enough to make only 1 memory-related bug/year can certainly spell variable names correctly
If they are stuck using a language that doesn't check anything until runtime, sure.
If you have dynamic, you rely on unit tests
But how exactly do you go about doing unit tests of the front end of a web application? The short answer is, you can't, not without unusually sophisticated tools. This is a serious problem even if you write the web application in C++, due to all the javascript stuff that lives on the browser these days.
There are a lot of things than *can* be checked ahead of time with a dynamic language, it is just that no one does, because the languages do not require that it be done. That is something that ought to be fixed. Surely someone out there has written a static analysis tool for Python or PHP that finds a large class of programming errors prior to runtime. Or even better, a static analysis tool that analyzes a dynamic language web app, client side javascript, an SQL database and the interactions between them? Anyone?
The exception proves the rule. FORTRAN (like COBOL) is certainly more computationally efficient than the vast majority of languages today, so if you are in a performance / overhead sensitive environment, there can be a lot to be said for such languages. It is just not the sort of thing people normally do without such constraints, because there are other, more modern languages that tend to be more suitable to the task.
No one is going to write an operating system kernel in FORTRAN, for example, although I have no doubt that it is actually possible.
1. If you are getting more than one memory corruption problem per programmer year in C++, something is seriously wrong with the competence of your developers.
2. The edit test cycle is fine the first time you develop a page or whatever. Then you need to make a change to an internal interface used by thousands of pages. Testing all of them is not fun. A statically typed interface can be checked by a compiler in a fraction of the time.
Cacheing pages or page components is great if the cache hit rate is sufficiently high. For many applications (and Facebook is among them), the cache hit rate is far too low to make cacheing *pages* worthwhile. Of course Facebook caches a large amount of non-page data (apart from the caching done in the database), and couldn't operate without it. All that cached data is assembled dynamically for virtually every page request, however. The original article referred to is rather informative on the subject.
10:1 is a conservative estimate of the *efficiency* of page generation in PHP vs. C++. If you are not CPU bound on the page generation servers, an increase in page generation efficiency won't make a perceptible difference.
However, if you have a large number of servers that do nothing other than page generation because the page generation process is CPU bound, how efficient that process is makes a big difference in terms of how many servers you require. So small sites shouldn't care, and very large sites should care *a lot*.
FORTRAN is designed to do numeric processing. FORTRAN compilers are very good at optimizing such code. FORTRAN is not at all optimal for doing much of anything else.
Similarly, with the right framework, someone might write a general purpose web application in C++, because you can make string processing code a relatively painless exercise with the right class libraries. Plain old C, on the other hand, is much worse - essentially a language designed not to do string handling very well or very reliably.
Even with C++, there is an enormous interoperability and efficiency problem with strings of different flavors, and I would put rank that problem as #1 on a list of why few people do general purpose business programming in C++. I have *never* seen a standard C++ library compatible C++ string implementation that was worth using in both compile time and run time efficiency terms. Certainly the implementation that comes with GCC doesn't qualify...
In general code written in a dynamically typed language like PHP is harder to test than code written in a statically typed language like C++. The reason why is that statically typed language compilers catch hundreds of problems at compile time that dynamic languages typically cannot catch until run time, and with complete code coverage at that. Misspelled variables and other minor typos anyone?
In a sufficiently large project, all the time one might save not going through an extended compile cycle quickly gets eaten up by the extra testing overhead, testing which for user interface intensive applications is rather difficult to automate.
Of course the developers have to know what they are doing. If you run into more than one dangling point or array overflow problem per ten thousand lines of code, someone is either ignorant or careless. C++ programming is not for code monkeys.