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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:08 EST