←back to thread

Interview with Zig language creator Andrew Kelley [video]

(www.youtube.com)
200 points jorangreef | 10 comments | 27 Aug 20 11:10 UTC | HN request time: 0.563s | source | bottom
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 #
1. petr_tik ◴[27 Aug 20 13:19 UTC] No.24293382[source]▶
how often does it happen that your interns work on the hot path of your trading systems, which is where I assume you care the most about avoid syscalls like malloc?
replies(3): >>24293588 #>>24293861 #>>24293926 #
2. cycloptic ◴[27 Aug 20 13:43 UTC] No.24293588[source]▶
Nit pick: On modern systems malloc isn't a syscall, it's implemented in userspace. (Sorry, I couldn't help it)

That's not to say you're safe to call other syscalls, many of them either require memory allocations in-kernel (see ENOMEM) or can block indefinitely.

replies(1): >>24293828 #
3. fanf2 ◴[27 Aug 20 14:06 UTC] No.24293828[source]▶
Never mind modern systems, malloc() was never a syscall :-) One of the great things about K&R is that it shows you how to implement parts of the C library, including a simple malloc(), demonstrating that the library does not need to be magical.
replies(1): >>24294936 #
4. logicchains ◴[27 Aug 20 14:10 UTC] No.24293861[source]▶
Literal interns are not very likely to work on it, but juniors might, and the junior's probably not going to know much more than an intern.
5. dcolkitt ◴[27 Aug 20 14:17 UTC] No.24293926[source]▶
To be honest, I'd be a lot more worried about physics PhDs then I would interns. I've seen plenty of 20 year-old engineering students write solid low-latency code. I can't say the same thing about string theorists.

It'd be pretty unusual for junior or non-technical people to write code in "core" components of the system. Things like datafeed parsers, order handlers, inventory management, safety checks, networking libraries, exchange connections, etc.

But even with all these layers in place, you still need an actual strategy to run at the end of the day. Everything in the quoter can be optimized to hell, but if the strategy module is spinning for 1000+ microseconds because it's running some bloated ML model, then none of that really matters.

Usually the system engineers and the strategists are different people. Not always. Especially in the case of more straight-forward mechanical strategies. But anything reasonably complex usually requires dedicated quants with different skillsets than profiling C code.

replies(2): >>24294998 #>>24300368 #
6. petr_tik ◴[27 Aug 20 15:57 UTC] No.24294936{3}[source]▶
Thanks you and your parent for pointing this out! I should be more precise, sbrk is the underlying system call that might be invoked inside malloc
replies(2): >>24295137 #>>24295169 #
7. petr_tik ◴[27 Aug 20 16:02 UTC] No.24294998[source]▶
> But even with all these layers in place, you still need an actual strategy to run at the end of the day. Everything in the quoter can be optimized to hell, but if the strategy module is spinning for 1000+ microseconds because it's running some bloated ML model, then none of that really matters.

From what I have heard, Optiver have a performance lab, which replicate real conditions with an exchange replayer and they can measure wire-to-wire latency for every release.

Hiring people for their maths chops as quants, you probably don't expect them to know about HW-level optimisations at the beginning of their finance careers, which, I guess, is the reason for such a performance lab. Build tools that help people bring their best skills to the table and catch regressions.

8. voldacar ◴[27 Aug 20 16:13 UTC] No.24295137{4}[source]▶
mmap usually these days
9. fanf2 ◴[27 Aug 20 16:16 UTC] No.24295169{4}[source]▶
Yes, and often mmap() for large allocations and other parts of the heap.

There has been an interesting discussion about memory management in Ritchie’s PDP11 C compiler on the TUHS list this month https://minnie.tuhs.org/pipermail/tuhs/2020-August/thread.ht... from the era when large programs could not necessarily afford the overhead of malloc() so sometimes used sbrk() directly.

10. rhodysurf ◴[28 Aug 20 00:57 UTC] No.24300368[source]▶
This is exactly my experience working on CFD software with hydrodynamics phds haha they don’t care about the “little” things and will allocate and copy shit everywhere