Now the reasoning isn't present in the patch but it probably is because they want step increments and -fms-extensions is a small-ish first step. Maybe -fplan9-extensions could make sense later, in a few years.
> For example, my blog search engine, which indexes on the order of 500,000+ words across 1,000+ documents, can return results in < 10ms because the indices can be queried incredibly quickly.
This is odd. Let's do a back-of-the-envelope estimation. DDR4 bandwidth is at least 12GB/s. 500k words is around 3MB. So, reading this amount takes 0.25ms, ignoring CPU caches. It sounds reasonable to assume the matching algorithm can run in-between that speed and 40 times slower for the 10ms mark.
This is one example where precomputation is probably not needed: bruteforce if N is small enough.
Applications want to receive/provide a stream (X sample-rate, Y sample format, Z channels) and have it routed to the right destination, that probably is not configured with the same parameters. Having all applications responsible for handling this conversion is not doable. Having the kernel handle this conversion is not a good idea. The routing decision-making needs to be implemented somewhere as well. Let's not ignore the complexity involved in format negotiation as well.
The scenario of a DAW (pro-audio usage) is too specific to generalise from that. That is the only kind of software that really cares about codec configuration, latencies and picking its own routing (or rather to let the user pick routing from the DAW GUI).
I have trouble understanding how people work for such big companies. Of course if the scale is 1000 employees "the company" cannot care about you; it is an institution not a bunch of people anymore. There is no upper layer to blame, the structure and scale themselves are the culprit.
I decided against that and work in a small company. Work-life balance is nice, we are friends and we all care (at least some bit) about the company itself. That is, because "the company" is us.
I see two differences: (1) the software stack on the server side and (2) I guess there is JS to be sent to the client side for HTMX support(?). Both those things make a difference.
What about plain HTML & CSS for all the websites where this approach is sufficient? Then apply HTMX or any other approach for the few websites that are and need to be dynamic.
In my MIDI controller case, the "compute state and send update" code takes about 8µs, up to a spike of 15µs. The worst case of the code in article is a sort on each frame on a 100ish array, it sounds safe to ignore. Profile before optimizing.
Another way to describe what has been done: implement a pure function and avoid storing additional state. It sounds way less dumb that way. It is not really a pure function but the spirit is here.
I've done the same during a refactoring of a side-project recently. It handles the input/output to a MIDI controller with many buttons, knobs and matching LEDs. Instead of computing what LED should change at regular interval, I am switching to recomputing the whole state each time. No more complex logic, no more mutable data. Only a pure function that outputs the desired LED state based on software internal state. Then a diff is computed and only changes lead to MIDI messages. Code is less efficient (for 100-ish LEDs) but much more straight forward.
I do not agree. Commits in my patch series have no link whatsoever with the chronology of my work. I wouldn't call it "Git history" as long as it is the branch I'm working on. It becomes history once it is merged inside a more persistent branch.
This is usually called container_of in C projects. It is compile-time safe as well, though the error won't be pretty. Linux, Qemu, musl, U-Boot, iproute2 & uclibc-ng each have a copy from the few project I've looked at. Two interesting implementations:
I've worked on a project that required a bigger swiotlb as well, I don't remember the exact details though. I guess it's not that uncommon, but indeed the default value looks good.