Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Parent Full thread

Cross-language comparisons are always interesting to look at; if I had the time, I'd really like to write one in Asm and see how it compares.

I've written NIC drivers for some older chipsets, and IMHO it's not something that's particularly "algorithmic" in computation or could necessarily show off/exercise a programming language well; what's really measured here is probably an approximation to how fast these languages can copy memory, because that's ultimately what a NIC driver mostly does (besides waiting.) To send, you put the data in a buffer and tell the NIC to send it. To receive, the NIC tells you when it has received something, and you copy the data out. Nonetheless, the astonishingly bad performance of the Python version is surprising.

Although I haven't looked at the source in any detail, I know that newer NICs do a lot more of the processing (e.g. checksums) that would've been done in the host software, so that would be another way in which the performance of the host software wouldn't be evident.

One other thing I'd like to see is a chart of the binary sizes too (with and without all the runtime dependencies).

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 memory you are doing something wrong.

> Nonetheless, the astonishingly bad performance of the Python version is surprising.

In the paper, they point out that the Python version is the only one they didn't bother to optimize.

However, my takeaway is that practically everybody can handle north of 1 Gigabits per second (2 Million packets per second x 64 bytes per packet) even on a 1.6GHz core. I find THAT quite a bit more astonishing actually.

I don't see why it's that surprising. We've been stuck on 1Gbps for the better part of 20 years. What's surprising to me is that wired networking was sorta left behind the tech wave, sure 10Gbps exists but it's still not that affordable or widespread.

I wouldn't say it was exactly left behind, because the average consumer will not really benefit from anything over 1Gbit. 1Gbit is already enough to saturate most consumer harddrives.

I run 10gbit inside my home and it didn't even cost me that much (if you go with 10Gbit fiber instead of copper) with the sole reasons of getting quicker transfers between my PC and NAS. My NAS has 4 SFP+ ports and functions as a switch. I bought second hand PCIe SFP+ NICs for $40 each and matching transceivers for $15 each. 10M of fiber costs less than $10.

There's no point in going higher, because 10Gbit is already way past the sequential writing speed of the drive array in my NAS, and it's pretty much saturating the NVMe cache drive in the NAS or the NVMe storage in my PC.

That's not to say you can't go faster, because 100, 200 and 400Gbit are very much possible and in use in datacenters and the like.

> I wouldn't say it was exactly left behind, because the average consumer will not really benefit from anything over 1Gbit. 1Gbit is already enough to saturate most consumer harddrives.

That hasn't been true for a long time. Even one single spinning rust hard drive made in the last decade can do sequential reads at ~120-150MiB/sec, which is easily enough to saturate a 1 Gbit/s link.

SSDs have way, way higher throughput for sequential read and write. Good SSDs will also beat that number handily for random read/writes.

And of course, any machine with more than 1 hard drive can easily saturate a 1Gbit/s network.

I also find it surprising that wired networking has been 'stuck' on 1Gbit/s for decades.

> What's surprising to me is that wired networking was sorta left behind the tech wave

Lack of necessity.

Since the telcos are a gigantic bottleneck to everything in the cloud, and now that everything is in the cloud, there is no need for >1Gbps home networking.

Because >1Gbps on 1.6GHz means <1.6 cycles per transmitted/received bit, or <8 cycles/byte if you prefer to count bytes.

That's not shabby for a language like python.

Yeah, for real life applications as well, I shy away from Python for anything where performance might one day be an issue. Most languages can at least get within an order of magnitude of state of the art (at which point ergonomic considerations can matter more), but Python is just incredibly slow in practice.

>I shy away from Python for anything where performance might one day be an issue if there are only a few bottlenecks that have a significant impact on the performance you could rewrite only those parts to C/Rust. This might be a good aproach especially in a situation where performance is not an issue right now but might be in future. When it actually becomes an issue only the part that actually affects the performance could then be rewritten to C. Of course this approach doesn't always make much sense, but quite often there is a small part of the code that impacts the performance the most and only that part would need to be rewritten, while the rest of the code could still enjoy a language more productive to write in. Similarly a microservice(ish) architecture comes handy with this

In a language as slow as Python where even basic memory copying is slow, you don't really just have a few bottlenecks. You can optimize the most important 10% of the code and the rest of the code will still be slowing everything down. It's also a lot of work to have to rewrite parts in C/Rust and interface with Python code.

Reply on news.ycombinator.com