Messages in this thread | | | Subject | Re: Compiling C++ modules | From | Christer Weinigel <> | Date | 29 Apr 2006 04:50:04 +0200 |
| |
[trimming the Cc list since probably nobody is interested in yet another language flame]
"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
> On Fri, 28 Apr 2006, Avi Kivity wrote: > > Developer performance equates to runtime performance. > > Read what you wrote! It's absolutely, incredibly stupid! > > The cost in developer time is borne once. The cost of performance > is borne every time you run the application.
That last sentence is true. The rest is you misunderstanding him.
Yes, for some things it is worth hand optimizing until you're blue in the face, but most of the time the language doesn't matter at all. No matter what you do, 99% of the execution time will be spent waiting for disk or waiting for user input.
Even if the task is CPU bound, a higher level language (C++/STL, Python, Perl, vhatever) may be faster than most C implementations because the time spent in the high level language is insignificant compared to the time spent in the highly optimized libraries that come with those languages (e.g. the regexp stuff in perl).
And even if there is no optimized library it may still be better to develop in a higher level language because the algorithms used may be clearer than the same code in C because the C code needs so much manual bookkeping to work. If the algorithm is easier to understand it is usually also easier to optimize, and remember that algorithmic optimizations usually give magnitudes of better performance, while low level optimizatios just provide a few percent.
Another thing to consider is that at program that always completes successfully, although a bit slow, is usually a lot better than a program that is fast for most data sets but segfaults for some others. It is much too easy to make a simple off-by-one mistake in C or forget to free some memory and get a memory leak. A really good C programmer will not make that kind of mistakes all that often, and with good C libraries and a good program structure a C application can also be easy to understand and optimize, but lets face it, most C programmers and C programs aren't all that good.
With all that said, I personally belive that coding the kernel in C and assembly is a very good choice. The performance of the kernel affects every application on the system, so saving a few bytes of memory in a page table descriptor or a some tenths of a percent in a hot path will mean a huge gain for the system as a whole. And the kernel maintainers are a bunch of extremely talented people who do a tremendous job of keeping the kernel clean and maintainable. With almost 15 years of development spent on the kernel written in C, they are starting to understand what works and what doesn't work. If we try to implement parts of the kernel in C++, we'll have to spend another 10 years learning what works and doesn't work in C++. [1]
So for some things, such as the kernel, very resource constrained systems, libraries that everyone use, C is a good choice. But blindly choosing C, based on some naive belief that C is always more performant, that is just plain stupid.
Sorry for the rant, but this particular subject is a just a particular itch of mine.
/Christer (who prefers programming C and Python)
[1] Recommended reading: Safer C by Les Hatton.
> The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
This part of legalese is just plain silly, if you didn't want the world to read your mails, don't post to public mailing lists.
-- "Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux Christer Weinigel <christer@weinigel.se> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |