Re: Compiling C++ modules

[Matt Keenan]

Avi Kivity wrote:
> Alan Cox wrote:
> > On Maw, 2006-04-25 at 00:03 +0300, Avi Kivity wrote:
> >  
> > > Alan Cox wrote:
> > > I think it's easy to show that the equivalent C++ code would be 
> > > shorter, faster, and safer.
> > >     
> >
> > Mathematically the answer is "no you couldn't". You might be able to
> > argue that a fortran implementation would be faster but not a C++ one.
> >   
> Maybe not mathematically, but I can try to hand-wave my way through.
>
> By using exceptions, you free the normal return paths from having to 
> check for errors. The exception paths can be kept in a dedicated 
> section, avoiding cache pollution. The total code (and data) size 
> increases, but the non-exception paths size decreases significantly 
> and becomes faster.
>
> Using C++ objects instead of C objects allows you to avoid void 
> pointers, which are difficult for the compiler to optimize due to 
> aliasing.
Exception handling on a kernel with a 4K stack would be very 
interesting, now imagine what would happen if one exception triggered 
another? and possibly another?? And even giving up on the stack issues, 
what about cacheline / performance issues? Moving error handling even 
further from the fast path isn't going to help performance much.. How 
about an exception for every ENOENT? Have you seen how many ENOENT's 
/lib/ld-linux.so.2 generates when a large app starts? Take firefox, load 
it, let it open five tabs, then shut it down. On my system, 1377 
open()'s, 527 of which are ENOENT, 135 of those before the program has 
finished linking. Not exactly the best way to speed the system up. And 
don't say you can use the dentry cache to return an object or NULL, as 
this is just replication of what C does, but with even more syntatic 
goop. C++ is a good tool, for the right job. The kernel is not one of them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/