Rosetta 2 is software, but there are design decisions made for the M-series chips that are specifically made to improve the ability of Rosetta to work in a performant way. The main one I'm aware of is the x86-TSO memory-ordering mode - most ARM chips don't support this, but the M-series have it so that Rosetta can toggle it on for x86 emulation.
I'm not sure what the total cost of these are, but it's not zero.
> There are only a handful of different instructions that account for 90% of all operations executed, and, near the top of that list are addition and subtraction. On ARM these can optionally set the four-bit NZCV register, whereas on x86 these always set six flag bits: CF, ZF, SF and OF (which correspond well-enough to NZCV), as well as PF (the parity flag) and AF (the adjust flag).
> Emulating the last two in software is possible (and seems to be supported by Rosetta 2 for Linux), but can be rather expensive. Most software won’t notice if you get these wrong, but some software will. The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
There's another big one, 4K page support. The MMU can be told to set up a virtual address space with smaller, x86-compatible 4096-byte memory pages instead of the default 16384-byte pages.
The dishwasher does automate a large part of doing the dishes, but not the whole of it. A Jetsons-style robot maid would also be able to clear the dishes from the table, restock the cabinets, and set the table before dinner - in addition to doing the cooking, cleaning, lawncare, etc.
It maybe wasn't the least-automated part of the chores, but if anything, doesn't that strengthen their point? We as people were happy to automate our dishwashers, and would probably spend more money on other chore-automations as well (see: Roomba, robotic lawn mowers, etc).
You gotta do both. Ideally, the bottom-up price (the price you want to charge) is less than the the top-down price (what people will pay). If it's not, you gotta go back to the drawing board.
It depends a bit on your crop mix, yield, and of course, family size.
You'd be surprised how much some crops can yield in small areas. (Oh god, I used to actually like pickles before I realized how many cucumbers we were churning out last year.)
Where it gets space-intensive tend to be grain crops, which we don't currently grow because the ROI is so low, but have space to if life forced it on us. Protein can also be a little tricky depending on what your expectations are, but if you're okay with mostly beans and eggs, you'll be alright on well less than an acre for a small family.
"local" can also be a network fileshare. It could also be in a directory that is treated differently than your other checkouts - whether that's something like deployment, sharing over the web, running CI, etc.
"network fileshare" is not local. By the same logic, I can mount S3 bucket over fuse and call it "local". Sure, it will work, but in the context it is just nonsense.
/shrug It's more local than github is. Whether it's a server running in your basement, or the filesystem served by the next rack over in your on-prem datacenter, it doesn't seem unreasonable to refer to it as 'local' in certain contexts, to contrast with remotes that are further away.
Leaving out types in public API's makes type errors hard to understand. Types should be declared in the API and bidirectional type inference used in the implementation.
Eh. This causes some problems for rust. Right now you can have a function return impl Trait instead of a concrete type. Very handy - and essentially required by async functions.
But the language also requires that types have names in lots of places. For example, you can't store an 'impl Trait' in a struct. You can't make a type alias of an impl Trait. And so on. As a result, async rust can only interact with a butchered subset of the language. (You can work around this with Box<dyn Future<...>> but performance suffers.)
There's a proposal[1] to fix this. But the proposal has been under discussion for (checks watch) 7 years now. Until this lands, async remains a second class citizen in rust.
This entire problem stems from rust's early decision to requiring concrete types at interface boundaries.
reply