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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]