emmericp

6 ms·

1.
by emmericp 1y ago
(Native German speaker here), it's a very rare use of the word "free" and usually only used in fixed terms like "Freibier", it wouldn't even work for other drinks, e.g., you can't say "Freisaft"
2.
by emmericp 1y ago
I'm surprised that the recent advances in applying typography to engineering problems [1, 2] are not published at SIGBOVIK but are apparently going to a more serious journal. [1] https://www.researchgate.net/publication
3.
by emmericp 2y ago
The time-travelling UB interpretation was popularized by this blog post about 10 years ago [1]. I'm not enough of a specification lawyer to say that this is definitely true, but the reasoning and example given there seems sound to me.
4.
by emmericp 2y ago
uIP (TCP/IP stack for tiny microcontrollers) is a another fun real-world example for these types of coroutines: https://github.com/adamdunkels/uip/blob/master/uip/lc-switch...
5.
by emmericp 3y ago
66% was drivers in 2019.
6.
by emmericp 4y ago
My aunt donated my grandpa‘s old slide rule there some time ago [0]. Crazy how far we came in just two generations. Fun to see this site show up on HN :) [0] https://sliderulemuseum.com/Circular/Curtis_L-M_FrequencyRes.
7.
by emmericp 5y ago
Yes, you should publish it. Don't bother cleaning it up if you don't feel like it. No one will judge you for the code quality. Published terrible code is far better than unpublished code.
8.
by emmericp 5y ago
We wrote some experimental network drivers in high-level languages a few years ago and Java performed better than expected. Yeah, that's a very special and somewhat odd use case, but it was fun :) We've got some graphs [0] compari
9.
by emmericp 5y ago
Most "new tech" is engineering, not science. If you want empiricism try academic papers instead of mailing lists ;) Some numbers: most critical bugs in the Linux kernel are due to memory safety: 40 out of 65 bugs allowing for code
10.
by emmericp 5y ago
The real root cause for all that flow director mess and core balancing is that there's a huge disconnect between how the hardware works and what the socket API offers by default. The scaling model of the hardware is rather simple: hash
11.
by emmericp 5y ago
Lesson 1: Never ever reboot multiple Ceph nodes without checking if Ceph is happy between reboots. This failure happened early during boot and this could have been handled with no downtime if they checked the rebooted nodes before rebooting
12.
by emmericp 6y ago
The NIC can hash on IPs and UDP ports just fine, nothing to worry about here. Sure, there's the rare case of a connection moving to a different L3/4 flow identifier causing a cache miss, but that's not something that happens
13.
by emmericp 6y ago
The hardware selection and test setup is questionable, yeah. But downclocking the CPU is pretty standard for many benchmarks like that. Would have been better to evaluate the effects of CPU frequency changes separately. But there's not
14.
by emmericp 6y ago
Isn't a large part of the performance gain from TSO offloading on transmit due to avoiding working with way too many skb's in the kernel? Shouldn't GSO for UDP with proper NIC support give you most of the performance gain? I&
15.
by emmericp 6y ago
> But enabling tcp timestamps in general case brings little benefit and wastes 12 bytes of each packet for basically no gain. I disagree; TCP timestamps are awesome. Linux enables these by defaults. Quick search gives me some measurement
16.
by emmericp 7y ago
There's only one level of TLBs in the IOMMU. And that's 64 entries. Yeah, I think the dTLB is only 64 entries on Intel CPUs as well, but there's a second larger layer behind that, and an even larger third layer. IIRC it'
17.
by emmericp 7y ago
Interesting, did you use huge pages? I think ~100k to 200k TSO "packets" per second should be doable with the IOMMU. But I guess it depends where the data is coming from. Could be one of the odd cases where copying data is faster
18.
by emmericp 7y ago
A problem on the hardware side is that Intel's IOMMU TLB is tiny (64 entries), so using huge pages for all DMA-accessible memory is absolutely required to get a good performance out of it. We've done some benchmarks here: https:&
19.
by emmericp 7y ago
Related: I ran some benchmarks for all GCs in OpenJDK 12 some time ago: https://github.com/ixy-languages/ixy-languages/blob/master/J... Epsilon tied on speed but lost to Shenandoah on latency because nev
20.
by emmericp 7y ago
Not a game developer, but I used to write UI addons for World of Warcraft. WoW allows you to customize your UI heavily with these Lua plugins ("addons") and Lua is garbage collected. It's a reasonable incremental GC so it sho
21.
by emmericp 7y ago
The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo
22.
by emmericp 7y ago
Yes, we do if we want to have an idiomatic interface for the application on top of the driver. Pull requests proving otherwise are welcome
23.
by emmericp 7y ago
Yes, we could write most of the critical part in C and it would probably be faster. But then it wouldn't be a Swift driver.
24.
by emmericp 7y ago
Java reaches 52% of C speed in the benchmark game ("fastest measurement at the largest workload" data set, geometric mean), we reach 38%. Seems like our implementation is within a reasonable range for something that's usually
25.
by emmericp 7y ago
PCIe bandwidth also decreases with increasing packet size as there's a lot of overhead per packet. Memory isn't used, it's all handled in cache, hitting main memory is super slow.
26.
by emmericp 7y ago
The OCaml version is probably our most optimized implementation, it was scrutinized (and improved) by lots of people at the MirageOS retreat earlier this year.
27.
by emmericp 7y ago
Swift spends 76% of the time incrementing/decrementing reference counts; ARC is just very bad at pushing tens of millions of objects through it every second. There's some more evlauation for Swift here: https://github.c
28.
by emmericp 7y ago
Real NIC drivers spend most of their time fiddling with bit fields. It's mostly about translating a hardware-agnostic version of a packet descriptor (mbuf, sk_buffs, ...) into a hardware-specific DMA descriptor. If your driver copies m
29.
by emmericp 7y ago
Neither C# nor Java have C in the hot path; C# uses unsafe mode, Java sun.misc.Unsafe. JNI/C# native calls are either in the initialization or for an alternate implementation to compare them.
30.
by emmericp 7y ago
2-10% for an already fast user space driver is nothing. State of the art for a lot of these use cases is still the kernel driver which is ~7 times slower. Sure, all that stuff is moving to XDP/eBPF/AF_XDP, but that is still ~20-30

More ›