←back to thread

Interview with Zig language creator Andrew Kelley [video]

(www.youtube.com)
200 points jorangreef | 2 comments | 27 Aug 20 11:10 UTC | HN request time: 0s | source
Show context
logicchains ◴[27 Aug 20 12:40 UTC] No.24293046[source]▶
I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice.

This is a huge advantage over C++ and Rust, because it makes it much harder for e.g. the intern to write code that repeatedly creates a vector or dynamically allocated string in a loop. Or to use something like std::unordered_map or std::deque that allocates wantonly.

replies(8): >>24293328 #>>24293382 #>>24293469 #>>24293919 #>>24293952 #>>24294403 #>>24294507 #>>24298257 #
voldacar ◴[27 Aug 20 13:30 UTC] No.24293469[source]▶
Yeah when I heard about this I instantly thought of game engines, but it makes total sense for HFT too. "Modern C++", with all its constant little mallocs and frees is so awful for anything that requires ultra low latency
replies(3): >>24293652 #>>24299417 #>>24300117 #
nyanpasu64 ◴[27 Aug 20 22:29 UTC] No.24299417[source]▶
std::span is a modern C++ class designed to act like an array or vector, by viewing the memory of an existing array/vector without allocating anything. In my experience writing audio code, C++'s implicit copy constructors are what makes it too easy to accidentally allocate memory.
replies(1): >>24304570 #
qppo ◴[28 Aug 20 13:29 UTC] No.24304570[source]▶
I'm not saying C++ is the best language out there but that smells like inexperience writing real-time safe code. The problem isn't implicit copy constructors but implicit copies in your code.
replies(1): >>24308234 #
nyanpasu64 ◴[28 Aug 20 18:16 UTC] No.24308234[source]▶
> The problem isn't implicit copy constructors but implicit copies in your code.

I don't understand what's the difference.

I'm not an expert in writing real-time safe code, but I've spent close to a year working on allocation-free programming. Implicit copies of structs (value types) are as fast as implicit copies of integers, but implicit copies of types with owned heap memory invoke the copy constructor, which calls into the allocator. Or did I misunderstand your comment or get anything wrong?

replies(1): >>24308972 #
qppo ◴[28 Aug 20 19:26 UTC] No.24308972[source]▶
Sorry I worded that poorly, what I meant is that you shouldn't be writing code where the fact an implicit copy constructor allocates is a concern at all, because C++ has very clear copy semantics.

With a handful of exceptions you essentially will never need to worry about this if you restrict assignment and argument passing of non-POD types to references within the critical code blocks. And in the case that you do need to worry about it, the copy constructor should be explicitly deleted anyway.

It's a footgun to be sure, but it's not a serious one with a bit of discipline. If you're used to doing real-time safe programming, you'll get paranoid about code that could invoke an allocator (or write your own).

replies(1): >>24309210 #
1. nyanpasu64 ◴[28 Aug 20 19:52 UTC] No.24309210[source]▶
> if you restrict assignment and argument passing of non-POD types to references within the critical code blocks.

It's a working strategy, but if you forget the `&` in `auto & x = document.foo; auto & y = x.field;` a single time, it might silently invoke the allocator. What actually happened to me was that it crashed because I returned a reference to a stack variable copied by mistake, when I meant to type a `&`. Pointers are probably less prone to accidental copying, but they have uglier dereference syntax and are nullable (excluding custom types).

Ever since that incident, I've been paranoid that I accidentally forgot the reference in another spot in the code. A few days ago, I debugged the code and set a breakpoint on malloc in the audio thread (LLDB crashes when listing threads, Visual Studio works) and found out my current codebase doesn't allocate on the audio thread. I hope I don't introduce any allocations.

To avoid this footgun, objects could be only copyable through an explicit `clone()` method like in Rust (which breaks std::vector<explicit_clone>), or by marking copy constructors as explicit (which you can't do to a std::vector).

replies(1): >>24309905 #
2. qppo ◴[28 Aug 20 21:02 UTC] No.24309905[source]▶
Most of this is solved by code review, unit testing, custom allocators, and if you really want rust-like guarantees, type traits. In this case std::is_trivially_copyable and std::is_trivially_destructible. Like you don't need an explicit .clone() method, you static_assert that all real-time-safe code only touches structs that are trivially copyable/destructible and write a custom allocator with optional checks to see if it's invoked in a real time context, and write a unit test to stress it. There are some places where this doesn't work, but they're obvious and pretty straightforward to handle. Ideally you'd have a slab allocator with constant time alloc/free while locked in the real time context that cleans itself up for real on resetting the system.

Really though, you shouldn't have an owned STL instance like std::vector near your real time code to begin with. You're seeing one of the reasons people writing performant code don't use the STL at all, even if it has gotten up to par with handrolled solutions in certain benchmarks.