In my lifetime the conversation has shifted from mineral farming with chemical fertilizers to managing microbes to microbes doing the managing.
There is a case to be made for many species of plants effectively being a previously unidentified manner of lichen. Created on mineral soil much the same way lichen grew on rocks.
They don't seem to give a single iota of a fuck about that when a private regular person has their money stolen or their car totaled by hit and run driver. Finding some innocent person to arrest would indicate they are at least pretending to give a fuck, yet they seem to only be bothered to even keep up appearances when it is the bank being robbed.
By far my favorite feature of lodash is the sortby function, in which instead of providing a custom comparator as most std libraries’ sort() function offers, provides a way to substitute a simpler object for the comparator to chew on. If your comparator needs to go beyond a couple nested conditionals, to actual data transform or grabbing locks, then that nasty little logn term in the runtime can take your sort from using 20% of the time budget for an expensive operation to taking 120%. Especially when you consider the memory bandwidth sloshing around L3 or the main memory bus to do the full table scan logn times.
I think the world would be better off if this wasn’t in a third part library in a single programming language. Iirc Ruby is the only language I know with it as a built-in.
Rust's slice of T [T] provides [T]::sort_by_cached_key which is a stable IPN sort which lets you provide a key transform callable f, which it will call at most once for each item to be sorted, sorting by comparing the (cached) results from that callable.
However ..._by_cached_key is not provided for Rust's unstable sort because the unstable sort doesn't require an allocator and necessarily a cache does need an allocator.
Yeah this is a function called sort_by but I don’t think it’s doing the same thing.
let (initial_values, stream) = (initial_values, stream)
.filter(filter)
.sort_by(new_sorter_lexicographic(vec![
// Sort by latest event's kind.
Box::new(new_sorter_latest_event()),
// Sort rooms by their recency.
Box::new(new_sorter_recency()),
// Finally, sort by name.
Box::new(new_sorter_name()),
]))
.dynamic_head_with_initial_value(page_size, limit_stream);
That’s an api that would make an OG Java developer get tingles.
sortBy should be locking each object once and I’m reasonably sure this is happening at least three times. Author ends up approximating _.sortBy() at the bottom by introducing a struct.
> Legend says it only happens in obscure, low-level systems, but I'm here to refute the legend.
In a somewhat self-deprecating, but also an “anyone can do this if they have the will” fashion, I tend to say my real skill in performance tuning is stubbornness. Orphaned gains can be easily responsible for 1/2 of the runtime of your average operation, sometimes as high as 2/3. The first 20% is fairly straightforward, the rest is just hard work. There’s always four smartasses willing to misquote a Knuth aphorism they never understood, but the fact is if your customers hate how slow the product is, and more to the point, if your marketing people are talking about it, it’s time to get off your asses and do the hard work, because your shit is broken.
Yes there’s specialized knowledge but is it really any harder than understanding how databases work? Probably not. But if what is described I’m the quote above is a “legend”, then either things have got a lot worse while I wasn’t looking, or I’m underplaying the value of those skills in the overall mix, or both.
The biggest memory pressure problem I ever fixed, I deduped running the same DB query twice and intersecting two filters of that data. I was expecting about a 2x improvement, but instead I got 10x. In retrospect I should have hoped for maybe as high as 4x due to the extra short circuiting on the data set, but not 10x. That was all better data locality.
The irony of that situation is that I had been pulled in as a fixer and asked if I could figure out how to get a request taking thirty seconds down to three. This was supposed to be my opening salvo in a several week drill down and a series of improvements going from 15 to 10 to 8 to 7 seconds etc and prepping to apologize when I was only able to get it down to five, maybe six seconds. And instead I was done in like two days. But it did serve my larger thesis that we were using caching wrong. Data passed on the call stack doesn’t have to be looked up a second time. Or a third, or a fifth.
It feels like my era of education 2012-2020 (couple of degrees over that time) really deemphasized perf tuning, even heard it was practically useless in current day a few times.
I had a computer organization course that came close but mostly just described microarchitecture and its historical development, not so much the practical ways to exploit it.
Actually taking the time to sit down and poke around with techniques was mind blowing. I grew up during the golden age of CPU and OS advancements 90s-00s and the rush from seeing ‘instructions per cycle’ > 1 captured a bit of that magic that CRUD app dev and wrangling k8s just doesn’t have.
I went to a top ten school. I had one semester of circuit design, one one of EE, and a couple of computer architecture that went over the MIPs and writing assembly.
I think there was some sort of transition of curriculum going on with the introductory classes though because the difficulty from one homework assignment to the next that first year of CS 1XX classes was pretty choppy. A friend and I made a game of one-upsmanship of adding our own constraints to the easier assignments to make them more interesting. Like taking larger inputs than the requirements and counting execution time.
When I left school my first job the application was glacially slow, and I learned half of what I know about optimization in a short stint there through trial and error. It was a couple jobs in before I ever got pushback and had to learn the human factors element. But it (the optimization balanced against readability, robustness, extensibility) was a way I have always made pedestrian work more interesting. There are whole classes of code smells that also contain performance penalties, and at the peak of my restlessness I needed those to keep my sanity without irritating coworkers. I’m just cleaning up this messy code, nothing to see here.
Reading release notes for other tools bragging on their improvements. Dev tools and frameworks are more forthcoming about how and what than consumer apps, but there are standouts from time to time. I read a ton of SIGPLAN proceedings during that era. Fortune favors the prepared mind and you look a lot smarter when you’re confronting a problem or opportunity with a primed pump rather than coming in cold (being friendly with other disciplines in your company also helps there).
It's not worth optimising if you don't have a problem. Focus your effort.
If this code runs once per week at midnight, needs to finish by 5am, and currently it takes 18 minutes, the fact it could take 40 seconds isn't actually important and so spending meaningful engineering effort to go from 18 minutes to 40 seconds is a waste.
On the other hand, if the code runs on every toaster when it's started and ideally would finish before the toast pops up, but currently takes 4 minutes, then even getting it down to 2.5 minutes will make more customers happy [also, why the fuck are we running software in the toaster? But that's beside the point] and might well be worth doing.
The classic UX examples given are much closer to the latter category. When I type fast the symbols ought to appear immediately for example, if you can't do that then you have a performance problem and optimisation is appropriate. But so much of what software engineers do all day isn't in that space and doesn't need to prioritise performance so optimisation shouldn't be a priority.
>so much of what software engineers do all day isn't in that space
Seems to me that critical infra that supports a lot of modern computing is in that space though.
If you want to develop that depth of knowledge you need to go into HPC/scientific, trading or accelerator hardware. I didn’t get into this sometimes crazy industry to NOT learn stuff and push the limits of my computer.
I’m glad I know about those applications now, but I wonder how much of a disservice we did to the industry by just focusing on frameworks and abstraction especially now that you can just sling a lot of that out with a prompt…
In the era of kubernetes and edge servers and everything running on battery power, that distinction between need and want becomes much fuzzier because of course we can bin pack the more efficient one better or preserve another five minutes of standby time even if the wall clock behavior is moot.
And I’d also argue that if you wait to use a skill only until the need is dire then you will be both 1) shit at doing it and fail to achieve your goal well and 2) won’t have spent enough time on the cost/benefit analysis to know when things have changed over from want to need. Like the blind people I allude to in my top level.
I'm just not sure if the relationship between the holes, the ridgeline, and prevailing winds (rain) line up for this being a water harvesting solution. But it's clear that in several sections they've done this on all of the terrain that's walkable on some of those hills, and I know walking ridgetops is often a solution to get through rocky or desert areas.
I always like seeing the desert reclamation stuff, but I always kind of think that the before pictures are taken in the dry season and after pictures are taken in the rainy season
Well the Macbook Air pricing in USD was always around $1000 right?
2013 MBA pricing in USD was $1100
2013 MBA pricing in JPY was 110k JPY
2026 Macbook Neo pricing in JPY is ~100k JPY
2026 Macbook Neo pricing in USD is $600
2026 Macbook Air pricing in JPY is ~140k JPY
2026 Macbook Air pricing in USD is ..~$1100
So depending on the currency either the Neo is a massively cheaper thing or filling a gap in a product line that inflation created.
I wonder how much of Apple's costs are USD-denominated. The fact that the MBA hasn't changed pricing at all makes me guess that not that much, but I don't know how manufacturing contracts work
I dunno, I find it interesting, but JPY inflation is a recent phenomenon
Apple has a different relationship with the Paradox of Choice than most companies. The price stability makes it a bad idea generally to buy the old model right when the new one comes out. And not chasing inflation numbers I think is also part of that.
They also have some of the highest margins on consumer electronics in the business. Higher IIRC than Nokia had, before smartphones killed them. So absorbing a 3% bump in the dollar isn't that big a deal for them.
There is a case to be made for many species of plants effectively being a previously unidentified manner of lichen. Created on mineral soil much the same way lichen grew on rocks.
reply