Bought the app, this is great. Can I make a feature request? I’d love for it to include a sequence of “levels” or existing equations to try and solve in order of increasing difficulty, and maybe a way to generate a random interesting one. Would love to use this to teach others with a mechanism for regular practice.
Plus modern interconnects like CXL are also layers on top of PCIe, and USB4 supports PCIe tunnelling. PCIe is a big collection of specifications, the physical/link/transaction layers can be mixed and matched and evolved separately.
I don't see it disappearing, at most we'll get PCIe 6/7/etc.
I’m sure this work is very impressive, but these QPS numbers don’t seem particularly high to me, at least compared to existing horizontally scalable service patterns. Why is it hard for the kube control plane to hit these numbers?
For instance, postgres can hit this sort of QPS easily, afaik. It’s not distributed, but I’m sure Vitess could do something similar. The query patterns don’t seem particularly complex either.
Not trying to be reductive - I’m sure there’s some complexity here I’m missing!
Unfortunately I don’t have any recommendations to give, my experience starts and stops at application development. Though I would love to spend some time in a datacenter!
Potentially have a look at Infiniband and Clos/fat tree networks?
My more generic recommendation would be to explore semantic scholar for impactful/cited papers, look for some meta analyses, and just dig through multiple layers of references till you hit the fundamentals (typically things published in the 80s for a lot of CS topics).
Once you're past the fundamentals, if find yourself interested in high-performance networking, I recommend looking into userspace networking and NIC device drivers. The Intel 82599ES has a freely available (and readable!) data sheet, DPDK has a great book, fd.io has published absolutely insane benchmarks, ixy [1] has a wonderful paper and repo. It's a great way to go beyond the basics of networking and CPU performance. It's even more approachable today with XDP – you don't need to write device-specific code.
Do you have any career advice for someone deeply interested in breaking into high performance GPU programming? I find resources like these, and projects like OpenAIs Triton compiler or MIMD-on-GPU so incredibly interesting.
But I have no idea who employs those skills! Beyond scientific HPC groups or ML research teams anyway - I doubt they’d accept someone without a PhD.
My current gameplan is getting through “Professional CUDA C programming” and various computer architecture textbooks, and seeing if that’s enough.
I disagree, “req/res body cookies that’s it” is not the underlying system. It’s an abstraction over the TCP/IP and HTTP stack.
What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.
They sell an API product, of which documentation is an absolutely core, user-facing part of their product. It doesn’t make sense not to own something that differentiates your products value proposition.
Having your caching set up I correctly is verrryyy easy to do. There’s lots of things you can miss, and don’t realise until a whole lot of traffic hits you
I’m using Bazel to build my rust project (Using the rules_rust rules) and it’a become quite a pain to use in concert with docker.
This is not a complaint about Bazel specifically, its fantastic, and easily my favourite build system bar none.
However it cannot cross compile Rust. This means if I’m developing on my MacBook, and I want to compile a Rust binary and put it in an Ubuntu docker container, I can’t do it on my host machine. I need to copy the source into the container and build it there, using multistage builds.
But this is -extremely slow- because it cannot take advantage of Rusts build caching. I’m talking 10-15 minutes for my small Rust project.
Has anyone run into this? How do you work around it?
I’ve considered running a Bazel remote execution server on a local Ubuntu VM, but this feels like so much extra complexity just to use Rust, Bazel and containers.
They’re not doing anything wrong, but working with generics, traits and async code is very much against the grain of the 2018/2021 editions of Rust.
The async story hasn’t finished, and is definitely the area that needs most improvement in terms of developer experience. There are a number of gated features and RFCs that propose solutions to these problems (e.g. GATs), but they haven’t been moved into the core language yet.
That doesn’t mean Rust is inherently bad or difficult, only that we’re working with an early version. Rust is young! We didn’t have futures until 2019, iirc.
Lots of core Rust concepts (lifetimes, ownership, references) need to be rethought for how they fit into asynchronous programming, and how to make everything compose well together.