Re: Compiling C++ modules

Matt Keenan
2006-04-25T09:06:06Z

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.