3 ms·
You can also write it in C and use lthread. It will be faster than what Go has to offer. https://github.com/halayli/lthread https://github.com/halayli/lthread
by halayli 13y ago
You can also write it in C and use lthread. It will be faster than what Go has to offer.
https://github.com/halayli/lthread https://github.com/halayli/lthread
- tptacek 13y agoIt will probably not be significantly faster than Golang for this workload.
- halayli 13y agoIt can be. You have total control of memory layout. You can gain a lot of performance by considering locality of reference, slab allocators, and parsing DNS packets in general will most probably be much faster.
- tptacek 13y agoGolang also allows control over memory layout.
- halayli 13y agoof course it does, but it does it in a way that aims to provide an overall good performance for all apps. But it doesn't mean that's the best performance you can get.
- tptacek 13y agoWhat "way" would that be? Golang's approach to data layout is very similar to C's.
- halayli 13y agoC doesn't control memory. brk() does. There are various malloc libraries out there to improve the way malloc manages memory. But ideally you don't want to allocate memory at all. You want to have memory preallocated and preferably accessing a page that's still in cache. You can control memory pages in C because it doesn't manage that for you.
- tonyplee 13y ago+1
- acdha 13y ago> It will be faster than what Go has to offer. You meant “could theoretically be” – you're gambling that you'll have development resources and expertise to make optimizations which aren't possible in Go, that those optimizations will actually matter to the critical path, and that you're more likely to reach the point of being able to make those optimizations than the Go team will be able to optimize further. In the absence of something showing a strong, unavoidable disadvantage for Go, that's a lot to take on faith.