On Thu, May 24, 2012 at 2:29 AM, Bennie Kloosteman <[email protected]>wrote:
> IM not sure how a NAT kind can prevent bounds checking eg if I want 3 > chars at point n how do you know with certainty that it is not out of > bounds ? Because the bound is part of the type if a NAT kind is present. > n> I'm not convinced that what you say about the balance of C vs C++ is > true. > My sense was that any system already committed to C stayed in C, and that > > accounted for a lot of low-level code. On the other hand, a lot of newer > > work seems to get done in C++ with a back-compatible API for C clients. > > Yes there is a lot of critical old c code , that said C++ kernels are > pretty rare , many newer ones eg barrelfish are still C ( I note > Coyotos was a trend setter in requiring C++ :-) . > But the case for upgrading the C++ code is smaller than the C code. > Its the old C code that really needs to be updated. Given the Coyotos code base, I obviously don't agree. EROS used C++. It was a huge mistake, for reasons that I discussed on the eros-arch list. In brief: the minimal C++ runtime became too large to be appropriate for a deeply embedded kernel, most notably in the area of exceptions. Which is why we used C in Coyotos. > I think > fundamentally these libraries are performance critical and due to > micro benches some people don't even want the vcall overhead , memcpy > is still asm in some cases. > memcpy() is asm because it truly is performance critical and most compilers don't get it right. In particular, compilers are generally not aware of cache line boundary issues, and typically won't issue vector instructions for what appears to be an iterative scalar array copy. Whatever your source language, the asm version of memcpy() is well motivated. Modern implementations actually have the compiler pick off the easy/obvious cases and only call the ask version when the general case is needed. But there are very few examples like that in a well-written C library. As for the rest, I really don't think that the C/C++ debate is driven by microbenchmarks. I'm sure there are people who may argue about that, but the impact of microbenchmarks on macro-scale performance tends to be very hard to trace. The bigger issues in libraries, I think, are (1) the added complexity when a C++ library needs to be callable from C - it constrains types and signatures at the interface boundary, and (2) the fragile base class problem and the difficulties this creates for dynamic library versioning. The latter probably more than the former. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
