725 karma · joined May 11, 2018
Also, while I get the appeal of just storing it all in a giant JSON, I don't really feel that's the final word in simple storage formats. I'd personally just use SQLite, or some other format I could rsync.
In my experience where I didn't modulo the numbers, the compute time was dominated by the last couple of multiplications with Megabyte-sized integers.
> samples from surviving mice on day 12 were also obtained through necropsy to measure viral titers.
The Grandparent's point about that "it double-dings open source developers" is still correct and poignant even with this clarification.
Watch what other people eat in their day. How many of their calories came from meals created with only the above ingredients? 25%?
Put another way, the bag of chips at the American grocery is _designed from concept to factory_ to be unable to support living beings. Microorganisms would die from dehydration trying to eat the chips. But due to a bug in human psychology, when we eat them we just feel more hungry. There only regulating feeling we get is guilt.
Guix bootstraps (in 2023, no clue about now) from a 357-byte program. You audit the bytecode.
The comment you're replying to is talking about not pulling in dependencies at all, before compiling, if they would not be needed.
These tasks aren't that challenging but they sure are a yak shave.
I believe the implication is there's fewer than one allocation per node with the new API. You allocate contiguous memory once, and use it to store n elements.
In my defense, I had to hack around a different Python library also manipulating sys.path, which nobody likes except this one dev team in a different timezone. They somehow got a director to declare that I would fix this issue they self-created before they woke up in 8h, and I wasn't allowed to rip out the library. So, ugly sys.path manipulation in the exact way that library wants. Not proud of it, but it sounds like you were given time to engineer an actually correct solution.
There's several aspects of deployments that are in contention with each other: safety, deployment latency, and engineering overhead are how I'd break it down. Every deployment process is a tradeoff between these factors.
What I (maybe naively) think you're advocating is writing more end-to-end tests, which moves the needle towards safety at the expense of the other factors. In particular, having end to end tests that are materially better than well-written k8s health checks (which you already have, right?) is pretty hard. They might be flakey, they might depend on a lot of specifics of the application that's subject to change, and they might just not be prioritized. In my experience, the highest value end-to-end tests are based on learned experiences of what someone already saw go wrong once. Writing comprehensive testing before the feature is even out results in many low quality tests, which is an enormous drain on productivity to write them, to maintain them, and to deal with the flakey tests. It is better, I think, to have non-comprehensive end-to-end tests that provides as much value for the lowest overhead on human resources. And the safety tradeoff we make there can be mitigated by having the feature behind a flag.
My whole thesis, really, is that by using feature flags you can make better tradeoffs between these than you otherwise could.
They had three measures: A) Flops. Operations per second. B) Cost. Dollars per hour. C) Runtime. Seconds per task.
I expected the formula to be Flops/Cost, resulting in units of operations per dollar.
Instead it was computed as Flops / (Cost * Runtime), to get some units that don't make sense to me — operations * tasks per dollar seconds?