Being fair about memory safety and performance
thecodedmessage.com
Being fair about memory safety and performance
1–10 of 75 posts
Re: Being fair about memory safety and performance
#2Really good article that covers some poor arguments about C++.
Re: Being fair about memory safety and performance
#3Since this is about array indexing, if you do slice.iter.for_each() instead of for-in, while-let or manual indexing then it already uses unchecked access under the hood today because internal iteration can use a counted loop and knows it doesn't need those bounds checks.
Re: Being fair about memory safety and performance
#4As for array index checking, Julia gets it right. It uses a pair of macros (@boundscheck and @inbounds), which empowers the user elide bounds checking. Moreover, it is extensible to beyond just arrays. I’ve used these macros in my own hand-rolled implementation of a ring buffer.
Re: Being fair about memory safety and performance
#5Totally agree with this article, as a fellow HFT coder.
The problem in c++ is the surface where you might cause a memory problem is huge. Once it's there, it's a lot of work to test the hypotheses about where it is hiding. On top of that, these kinds of issues can escape your instrumentation in a way that other bugs tend not to. Add some debug lines, things get accessed differently -> Heisenbug. Mega pain in the ass to figure out, lots of time taking everything apart, sprinkling debug lines, running long tests to catch that one time it goes wrong in a million, and so on.
He's also right that the array access thing is not a huge thing, it can't possibly be what your decision turns on, and that most of the code doesn't have a tradeoff in performance, because it's in the config stage rather than the hot path.
Personally I've had a great time with Rust, it's far more productive than other typed languages I've used. On a business level, the issue with the type of bug mentioned above is it destroys your schedule. I've spent entire weeks looking at that kind of thing, when I was expecting to be moving on with other parts of my project. With my current Rust stuff, I'm doing what I expect to be doing: addressing some issue that will soon be fixed like adjusting some component to fit a new spec.
Re: Being fair about memory safety and performance
#6There's a presumption here that checked access would cost some nr of nanoseconds per access, but this often isn't the case since predicted, not-taken branches tend to have 0 cycle latency in recent CPUs.
Re: Being fair about memory safety and performance
#7Great article, I'm bookmarking it so I can point to it if and when required ;p
Re: Being fair about memory safety and performance
#8There's a presumption here that checked access would cost some nr of nanoseconds per access, but this often isn't the case since predicted, not-taken branches tend to have 0 cycle latency in recent CPUs.
Depends, if the function is vectorizable then the cpu can do more elements at a time if it doesn't do the branch prediction work. It is true for non-vectorizable work.
Re: Being fair about memory safety and performance
#9Since this is about array indexing, if you do slice.iter.for_each() instead of for-in, while-let or manual indexing then it already uses unchecked access under the hood today because internal iteration can use a counted loop and knows it doesn't need those bounds checks.
That’s discussed in the slices section of the article
Re: Being fair about memory safety and performance
#10Read only top half of the article.
Would like to add that at least in plain C, doing var[index] doesn't invoke any checked() or unchecked() access function call. It's rather compiled into assembly instructions to calculate the address where the data is expected and load it into memory in one or two lines.