[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.



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:
> www:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.174 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site