Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++
via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 14 04:01:12 PDT 2015
On Tuesday, 14 July 2015 at 10:32:35 UTC, Walter Bright wrote:
> Omitted from your comments are any mention of D's language
> support for purity and transitive const/immutability and
> @safe/@trusted/@system. These are critical for writing robust,
> encapsulated code. I know of no C++ sanitizers that attempt to
> address these.
Yes, if your codebase benefits from transitive const/immutability
then that can simplify reasoning about the program.
I usually don't write code that way in C-like programming and
prefer more fine-grained const to prevent myself from making
encapsulation-related mistakes more than multi-threading issues
etc.
In the ideal world I would want both. In the real world
complexity is already higher by having const in the first
place... so I understand the trade-off.
> And lastly, writing code in C++ does not get you performance.
> Performance comes from careful balancing of algorithms, data
> structures, memory layout, cache issues, threading, and having
> intimate knowledge of how your particular compiler generates
> code, and then using a profiler.
Indeed. But you would not have written DMD in C++ if you did not
need performance? That was more my point. C++ is not an
attractive language if you can afford slower execution.
Languages like D and Go can stay interesting alternatives even
when you can accept slower execution, but want strict typing and
GC.
So for people who only want one language D has an advantage over
C++, right there. (I don't really care, since I already deal with
many languages every month.)
> Have you used a profiler for your performance critical C++
> code? You don't have to answer, but very, very few C++
> programmers do. And I can guarantee you that those that don't
> use a profiler are not writing performant code (though they
> certainly may believe they are).
I basically don't care about raw throughput, but latency and
meeting real time deadlines. Instrumentation can be useful… but I
consider that "debugging".
My C/C++ bottlenecks are in tight loops with real time
constraints on a single thread. Meaning, if it is too slow I will
get dropped audio/video frames. So I write the code as fast as I
conveniently can, taking heights for the possibility that I might
have to go even lower level... (and hoping I don't have to). So I
don't write optimal code from the get go. I try to write
maintainable code first using "CPU independent simd" and decent
cache-friendly layout.
Of course, a compiler is different since there are no latency
issues, but throughput issues. Then you need to look at the whole
call-tree using perf-counters etc.
But I think many situations where you need C/C++/D/Rust/Go are
situations dominated by responsiveness/latency.
More information about the Digitalmars-d
mailing list