mochomocha

Every physical model has its strengths and weaknesses. In this case you're correct that no emphasis has been put on the human-instrument coupling, but they've worked harder than usual on the air/instrument coupling which makes sense givwn their goal of helping violin makers. However there are plenty of research work on physical modeling between human and instrument (Serafin, Woodhouse, Chaigne etc from 1-2 decades ago) esp for violin. For string plucking & striking specifically, the coupling is modeled in a few commercial products (Pianoteq is a popular one) [disclaimer: I used to sell a guitar software doing this as well and met some of these acoustics experts a long time ago - these were fun times going down the rabbit hole of physical modeling]

It makes me think of this parallel: often in combinatorial optimization ,estimating if it is hard to find a solution to a problem costs you as much as solving it.

With a small bounded compute budget, you're going to sometimes make mistakes with your router/thinking switch. Same with speculative decoding, branch predictors etc.

> I suspect they just push what they want you to watch, like their own content.

Having worked close to the recsys folks at Netflix, I can tell you that this statement couldn't be further from the truth.

I know nothing about photography, but I'll just comment on this point:

> (I'm guessing this is a CM4/CM5) is a disaster for a camera board. Nobody wants a 20s boot every time you want to take a picture, cameras need to be near instantaneous.

You can boot an RPI in a couple hundred milliseconds.

The article started really well, and I was looking forward to the empirical argument.

Truly mind-boggling times where "here is the empirical proof" means "here is what chatGPT says" to some people.

On the other hand, Groq seems pretty successful.

Ha! I have spent the last 2 years on this idea as a pet research project and have recently found a way of learning the wiring in a scalable fashion (arbitrary number of input bits, arbitray number of output bits). Would love to chat with someone also obsessed with this idea.

What is so bad about free trade?

Isn't competition in free markets something Republicans believe in anymore? Because forcing Americans to buy inferior locally-made products at a premium through artificial restrictions surely isn't that.

Free trade and globalization are also a pacifying force, by creating mutual dependencies between countries.

Protectionism doesn't work.

Nothing substantive to add to the discussion, but to praise Min's blog posts which I have found very well written and instructive.

11. notice that there's a unicode rendering error ("'" for apostrophe) on kernel_initializer and bias_initializer default arguments in the documentation, and wonder why on earth for such a high-level API one would want to expose lora_rank as a first class construct. Also, 3 out of the 5 links in the "Used in the guide" links point to TF1 to TF2 migration articles - TF2 was released 5 years ago.

Yep in Netflix case they pack bare-metal instances with a very large amount of containers and oversubscribe them (similar to what Borg reports: hundreds of containers per VM is common), so there are always more runnable threads than CPUs and your runqueues fill up.

Yep. In Netflix case each Titus host can run hundreds of containers per bare-metal instance at any given time. One advantage of running a multi-tenant platform like this is that you get better observability on multi-tenancy issues since you're doing the scheduling yourself and know who is collocated with who. It's much harder to debug noisy-neighbor issues when it's happening on the cloud provider side and your caches get thrashed by random other AWS customers.

One thing I was pitching internally when advocating for this platform is that when you have the scale to run it for the economics to make sense, you can reclaim some of AWS margins instead of having your cold tiny VMs subsidize other AWS customers higher perf. If you run the multi-tenant platform yourself, you can oversubscribe every app in a way that makes sense for your business and trade latency or throughput of software for $ on a per-container basis, so you can make much more granular and optimal decisions globally. VS having each team individually right-size their own app deployed on VMs and sharing CPU caches with randos.

I remember once at Netflix we investigated a weird latency issue on a random load balancer instance and got AWS involved: it turned out to be a noisy-neighbor on the underlying VM that gets chopped up into multiple customer-facing LB instances.

> Government is controlled by the highest bidder.

While this might be true for the governments you have personally experienced, this is far from being an aphorism.

According to [1] Fargate is actually not using Firecracker, but probably something closer to a single container running in a single-tenant ec2 VM. If true, this makes VM boot-time optimizations and warm pooling even more important for such product.

[1]: https://justingarrison.com/blog/2024-02-08-fargate-is-not-fi...

(I'm the author of the blog post)

Beyond "kernel programming is hard", there are a few other reasons why it made sense for us:

- observability & maintenance: much easier to implement and ship this type of changes in userspace than rolling out a kernel fork. We also built custom AB infra to be able to evaluate these optimizations.

- the kernel is really good at making reasonable decisions at high-frequency based on a limited amount of data and heuristics. But these decisions are far from optimal in all scenarios. In contrast in user-space we can make better decisions based on more data (or ML predictions), but do so less frequently.

It's a MoE model, so it offers a different memory/compute latency trade-off than standard dense models. Quoting the blog post:

> DBRX uses only 36 billion parameters at any given time. But the model itself is 132 billion parameters, letting you have your cake and eat it too in terms of speed (tokens/second) vs performance (quality).

> Do list the names of famous bureaucrats that got famous because they fined rich companies.

Thierry Breton is another name that comes to mind.

The technical report (linked in the 2nd paragraph of the blog post) mentions it, and compares against it: https://storage.googleapis.com/deepmind-media/gemma/gemma-re...

Yes, that's part of the AV1 specs actually. See https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf

Andrey (who works for Netflix) drove the effort. Chatted with him about it.

Where can I find benchmarks of EEVDF vs CFS that were 1) not run by Zijlstra and 2) not synthetic? ie AB tested on a large fleet of computers running heterogeneous processes.

I have nothing against the EEVDF algorithm itself (in fact I like it) and I dislike CFS very much. But I dislike the current development process of the Linux scheduler even more. Proper quantitative benchmarks of CPU schedulers are missing, which is why CFS ended in the sad state it did, where hundreds of patches were submitted to fix random edge cases over the years. What makes you confident that the initial EEVDF Linux implementation won't suffer the same fate, given that the development process hasn't changed (single kernel dev implementing it and running micro benchmarks)?

This is technically true but practically irrelevant. Case in point, I deployed at Netflix a real-time combinatorial solver specifically for CPU scheduling [1].

Most real-world combinatorial problems can be solved relatively well. This is why Gurobi is in business, Alpha Go exists, or why Amazon and United Airlines still manage to practically solve their resource allocation problems.

[1]: https://netflixtechblog.com/predictive-cpu-isolation-of-cont...

Having experimented with a lot of CFS knobs, my high-level conclusion is that every single non-default behavior is broken to various degrees, and default behavior isn't immune to pathological edge cases either.

I'd like to wager that EEVDF has been tested less methodologically than how this paper investigates CFS. The primary author of EEVDF and maintainer of the subsystem has been dismissing alternative approaches and plethora of robustly tested patches from Google and Facebook over the years, with mostly replies boiling down to "meh I don't like it".

I'd take a patch of CFS and its millions of broken knobs from Google over newly released EEVDF any day, because I trust scheduler AB testing by Google over millions of machines and every single scheduling pattern under the sun way more than whatever synthetic micro-benchmark a single kernel dev (as competent as they might be) ran.

If you're interested in quantitative analysis of schedulers & tooling around it, these 2 projects are very interesting:

https://github.com/google/schedviz

https://fuchsia.dev/fuchsia-src/concepts/kernel/fair_schedul...

If you know anything about Ilya, it's definitely not out of character.

Well, from my first account (I worked there) this is wrong. Also, there's never been stack ranking.

> Netflix pays well because they don't believe in work-life balance, at all.

I'm surprised you've made a general statement out of a company you've never actually worked for.

For engineering roles, work life balance at Netflix is mostly what you want it to be.

Was true until 2022. Unfortunately levels rolled out for both ICs and managers.

It's apt in Yoshua's case though, as he hasn't made any significant contribution himself. I'd argue his brother during his tenure at Google has had a much bigger impact.

Be the change you want to see in the world.

I refuse to interview at places that are Leetcode-heavy. Never prevented me from getting 7 figures offers at FAANG-type companies.

Similarly when I interview candidates, I don't ask them Leetcode questions either. I like to get a sense of whether or not a candidate can reason in semi-unknown territories and has good intuition, not if they can parrot a textbook.

I just wanted to express gratitude for the amazing work you're doing. As someone with no hardware background, I learnt a lot from reading your blog, and I marvel at the amount of collective human intelligence packed into all the tiny chips surrounding our daily lives.