Messages in this thread | | | Date | Mon, 16 Oct 2000 00:19:32 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: [Criticism] On the discussion about C++ modules |
| |
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.
:-)
Jeff
Eray Ozkural wrote: > > "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: erayo@cs.bilkent.edu.tr > 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |