Re: [Criticism] On the discussion about C++ modules
Rik van Riel wrote: > If C++ really is that good for kernel modules, I'd like to > see some code that proves it can be done without too much > of a performance hit (or without a performance hit at all?). > it can be done in theory :) > Sending 500 rants to the kernel list isn't even close to > being productive. Sending 1 patch is... > i already made that point. the only proof that it can be done is the demonstration of an actual kernel module without a grave performance hit. many thanks! > regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
Marty Fouts wrote: > > I prefer Peter Salus' wording, myself: The difference between theory and > practice is always larger in practice than in theory. I didn't know this brilliant quote. About the bloat: I think C++ would give you some bloat. But that bloat is mainly in the footprint (you have to link with libc), rather than source because C++ code happens to be shorter. These are in theory as I mentioned ;) Regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Criticism] On the discussion about C++ modules
Hi, I've read a summary of a discussion about C++ module writing on this list, and I'd like to make some comments on it. [I'm not subscribed to this list, please retain a Cc: to my address] To rephrase, Stepan Kasal had started writing a C++ kernel module and while including kernel headers he found out that C++ reserved words were being used in some header files, thus resulting in errors. He proposed a patch to remedy this situation but as I see it was rejected on the grounds that C++ is not appropriate for kernel development. First off, I'd like to state that kernel being a mostly C program may not have had such considerations. The responses however surprised me greatly, although I'm aware of Linus Torvald's general skepticism of the utility of C++ for kernel development. [I don't imply that all kernel hackers are his disciples] If the conflict can be avoided outside linux source tree, it should be preferred. I have nothing to say about that. The quoted posts in the summary I've read will be subject to my humble criticism as I believe they were made without putting much thought to the subject matter but largely motivated by some need to advocate. * Jes Sorensen has claimed that kernel modules should not be written in C++ on the grounds that " Once somebody has done it, somebody else will try to use some of the brain dread C++ features such as exceptions - therefore totally preventing people from writing any bits of the kernel in C++ is a good thing." Exceptions are not a brain dead C++ feature, although I'd agree that C++ has many flaws. On the contrary [to what you say], exception handling in C++ standard has seemed to me one of the most efficient and simplistic ways to handle exceptions. Like in many languages, inappropriate ways of using a feature can result in awful side effects and overall undesirable system behavior. When writing systems software, one cannot attain the same style as though he's writing a word processor. I believe many people in this list can point out to badly written C code in some version of the linux tree. OTOH, anybody can do anything they desire with the linux source code. And anybody can write any Linux kernel module they see fit. (I like 68k assembly a lot, can't I write a module with it?) [A note on C++ exceptions: they were designed to cause no overhead when they are not used, which is something a kernel programmer would want] * Victor Khimenko has claimed that "lots of nice features of C++ need support from run-time systems and using lots of space on stack. NOT what you want in kernel where even gcc run-time was stripped out (kernel is NOT linked with libgcc and it's done deliberately)". As I said, it depends on what in C++ you use. What features need support from run-time systems or excessive stack usage? Template instantiation? Or perhaps member function calls? I don't want to go into a polemic, so let me just say that a programmer may avoid excessive run-time system usage by carefully choosing which language and library features he's applying. He has added "you have only 4-5KiB on stack to play with and where heap is bonus (kmalloc, vmalloc and other things exist but should not be used if not REALLY necessary). I'm not sure if C++ is needed even in userspace but in kernel space it's not appropriate" I can think of a C kernel module that is intended to run on systems with large memory. Allocating 30 mb of RAM for a very special device. Objections? Besides, as I've said the memory is within the control of C++ programmer. C++ isn't Java, you can exercise very precise memory management. [And there would be applications where the g++ run-time's footprint wouldn't hurt] Anyway, you can write a kernel with any language that's efficient and portable enough. If I were asked to design a lean kernel, I could go ahead with a generic RISC assembly platform rather than C. Not that one is available, but if it were it could be used instead of C. C is not the only systems programming language on earth; and obviously not the only language a hacker has to use. * Alan Cox adds the following: "C++ is just a syntax wrapper over C with some bad exception handling included. It doesn't even do a good job on object orientation compared to stuff like smalltalk. People do object oriented programming in cobol. Its a programmer feature not a language feature." Alan Cox sounds as if he hasn't followed the development of programming languages and compilers for the last 10 years. C++ used to be a syntax wrapper over C, a la the original cfront implementation. That has changed now, here is an excerpt from gcc info manual: " G++ is a *compiler*, not merely a preprocessor. G++ builds object code directly from your C++ program source. There is no intermediate C version of the program. " It occurs to me that you haven't read this part of gcc manual. Please do justice to your fellow hackers before you engage in an old-fashioned
Re: [Criticism] On the discussion about C++ modules
"Jeff V. Merkey" wrote: > > The [new] and constructor/destructor operations create hidden memory > allocations in C++ that can blow performance in kernel "fast paths". That is designed to decrease the number of syscalls, not to increase them. Besides, in a successful C++ design memory allocation would be encapsulated in allocator classes as in the C++ standard library. It lets you manage the memory the way you want it, specify in an abstract way and yet achieve this with efficiency. For example, I'd written a very simple & efficient allocator that did only a single big alloc and free for a graph partitioning program. SGI's STL Programmer's Guide has some documentation on allocators at URI http://www.sgi.com/Technology/STL/ . The thing is memory management is something beginner programmers have difficulty with in every language. [Of course, you don't have to use allocator classes. You can do it any way you'd like. It'd be better, though.] Default STL allocators are quite efficient, and may be used generally. The good part is that containers don't try to handle locks by themselves. > Writing kernel code in C++ is never a good idea because of this problem, > and the fact that with function overloading, it's possible for someone > to write code that is so difficult to follow, it's unmaintainable. As I said, I don't think it's a C++ specific problem. A lot of C programs suffer from bad memory and I/O code, too. Function/Operator overloading does give inexperienced programmers the opportunity to create semantic traps. It should be used when it is required. If the function overloading is used so that semantic similarity is preserved, it has its affordances. A similar argument goes for operator overloading. After all, an inexperienced programmer wouldn't be able to write a maintainable kernel module in C | C++. > MS > wrote a large portion of W2K in C++, which is one reason it's hard to > debug, and slow. C++ also puts in jump tables with mangled names, and > is very difficult to debug at the assembler level. Which jump tables do you refer to? Those [vtables] come into play only when you use virtual function calls, which must be used for high-level functions. You can write a kernel module without using any. C++ doesn't require you to employ polymorphism. Windows isn't bad because it's [largely] written in C++. It's bad because it's written by MS. ;) Do you think it would be better if they didn't use C++? [BTW, let's not associate C++ with proprietary software! :/ ] Best Regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
"J . A . Magallon" wrote: > I agree that C++ for kernel is not a good idea, libstdc++ should be in the > kernel, > code would be bigger, there's a complicated runtime under C++ doing things > by itself (copy constructors-operators and so on), inheritance adds some > little calling overhead. > You can profile C++ code very precisely. Avoiding copy constructors is programmer's part. C++ doesn't require you to use polymorphism, and if used carefully doesn't incur significant overhead. I can't say whether putting libstdc++ in a kernel module is a bad thing before I see one. This is a skel. code: orion:opt$ ls -al app -rwxrwxr-x1 exa exa 14275 Oct 16 04:38 app orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so -rw-r--r--1 root root 271528 Oct 10 09:54 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a -rw-r--r--1 root root 476494 Oct 10 09:54 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a It seems to me that a somewhat big module binary wouldn't hurt for many applications. Putting that into the "real" kernel isn't a good idea of course. Can't the unused code be stripped from libstdc++ for a single kernel module? :( > - args : dont break your untouchable data, and get rid of pointer mess and const functions. This is such a good thing, it allows the compiler to make great optimizations that are not possible in C. The C9x standards had (IIRC) a similar "restricted" keyword for C, but I don't know if gcc is going to implement it. You might want to demand that from gcc developers :) > Perhaps a g++-embedded mode could be the solution... For embedded applications? ;) Regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
"Jeff V. Merkey" wrote: > There are some elements that are attractive, but overall, why would a > device thread want to allocate memory from an interrupt I don't how you would do such a thing in C++. Allocators and the stuff I talked about make it more efficient and safer to manage memory. They don't throw memory calls all over the place. :P Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
"Jeff V. Merkey" wrote: > > Eray Ozkural wrote: > > > > I don't how you would do such a thing in C++. Allocators and the > > stuff I talked about make it more efficient and safer to manage > > memory. They don't throw memory calls all over the place. :P > > More routines touching more memory on more cache lines (generating more > MESI traffic between the cache controllers). Plus the poor schmuck who > has to maintain the source code will will have to debug his 10 > instruction read and write code (in C) to IO register which now does 4 > copies, and is 500 instrutions long (in C++) (copying memory is > expensive). You're assuming that g++ generates code that is much larger and slower. That's not true. An inexperienced C++ programmer can manage it perhaps. Can you give an example for this? ;> C++ programmer has the kind of control over the machine the C programmer has, and then some. [ See the comments on "const" ] > Oh, I almost forgot, the processor also will have to > generate an AGI (address generation interlock) since you will load an > address then immediately jump to it in all the jump tables that the C++ > compiler will put in for every function you call (and your multiple > instruction piplines will be reduced to one, since the processor has to > go serial to handle the AGI correctly). In flat model code, jumps to > functions within a single 4GB segment (or larger) are just done with > simple math internally in the processor -- C++ injects one or more > memory fetches in between each function call, plus they use 2-3 times as > much stack memory. Eh Sorry. These are not relevant, especially the last bit about C++ injecting one or more memory fetches between function calls. Haven't you studied any compiler courses? [ Let me guess, you're an EE guy and don't want to know what an optimizer is :> ] I don't want to repeat myself, but C++ doesn't force you to use any bad programming practice that will result in slow code: * exceptions everywhere * polymorphism everywhere * dynamic type checking everywhere * new/delete everywhere * huge non-const objects copied everywhere ... If you think that C++ proggys _have_ to contain such terrible code, then I'll have to conclude that you haven't learnt coding in C++. If any of what you said was generally true, then nobody would be able to write any efficient program in C++. In kernel or userland. Would you mind checking the blitz++ package for understanding what I mean? That library happens to be a good example of efficient use of C++. Let me look back at that graph partitioning program I did; there must have been a miracle to make it run that fast. :) -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
"Jeff V. Merkey" wrote: > > Not meant to offend, but it's obvious you are not grasping hardware > optimization issues relative to kernel development and performance. I > would recommend getting your hands on a bus analyzer, and testing out > some of your theories, and explore for yourself relative to these issues > with some hard numbers. > > :-) > In the days we coded demos in assembly, we didn't used to need bus analyzers. I saw each unit flood with current as I coded. :) Anyway, kernel code is not different from any other code. It is profiled and analyzed just the same way. Software engineers don't analyze the code that way, you just do time and space complexity analysis. For high performance applications, you can do an analysis that takes into account memory fetches, etc. Then, you perform an empirical analysis _after_ theoretical measures have been taken (ie, you have done a correct design regarding efficiency) This usually corresponds to profiling using features of compiler and your program. For realtime tasks, it's more difficult to do a right analysis. You still sound like a physicist or an EE person. :) Get a copy of "The Art of Computer Programming". :) -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
"Jeff V. Merkey" wrote: > > Tell you what. You should go look into the Chorus or TMOK projects that > are based on C++ and pester them. Fine. I don't want to waste my time with somebody else's crap though! > Next you'll be telling me that IDL > and Corba stubs in every layer of the OS are in order and won't hurt > performance. No, I won't! I don't believe in Corba. > I did this OOM mental mastrubation excercise with the USL > folks 7 years ago at Novell and sat in lots of design reviews of C++ > kernel code for Unixware and we had so many offsites on this crap, I saw > the NOvell campus about once every two weeks in between political > meetings with Art Sabsevitch and his USL buddies. Too bad for Novell coders. You know, there are other factors in these grand C++ failures. It's kind of a sociological disaster. Once C++ is in the play, I guess developers trust on it so much that they _forget_ about important design elements. In a kernel, you _have to_ think about a zillion "fast paths". That means it's not eligible to use exceptions or virtual function calls at a low-level function, and other things as well. [C++ is not sort of a magical entity that will do the thinking for you, it's just another programming language] There is a strong backup to this argument. When you're writing in C++, you can resort to a style that's very similar to C. If you write only generic procedural code, your program becomes just a generic C. Throw in a few object-based abstractions, and the cake's done. And if you _really_ want to code the whole kernel in C++, you have to be very careful because the services the kernel offers and the implementation of those services are not the same thing. At the very low level, you'll probably want to use a style that's *just like* C and assembly. (Of course, you can make use of C++'s more flexible syntax and strong type-checking) At the higher level, you can present a more abstract interface to *module* developers. Of course, you have to show them how to write a module and supply some utility routines, too. Overall, writing a clean and efficient C++ kernel is a daunting task. > We wasted two years > of time, spend 375 million dollars on the C++ modular kernel projects, > and ended up with a pile of crappy Chorus code that was unsellable and > shitty. You should go over to the Chorus group with your ideas about > C++ kernels. They will listen to you because they believe their own BS > about C++ kernel development -- you'll be right at home... Chorus group does wrong because of other things, too. There is no real disttributed OS on the planet, and you're contrasting Linux *module* development with the full-scale development of another system. It's not that I love BS, I'd written to him asking for some advice (not on C++) and he hadn't replied. :( [As I told somebody else] I am not advocating using C++ for writing base Linux kernel code. Let it remain C as you like it. I'm just telling that * you can't prevent people from writing C++ linux modules as they like * you are making unfair criticism of C++ language My purpose is not to engage in a net religion war. I only want to clarify technical aspects of a dispute concerning platform choice for kernel module development. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
