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.