598 karma · joined May 5, 2020
Example: AMX predated the standard ARM matrix multiply instructions. Perhaps Apple will add the ARM versions someday and now can remove AMX without breaking compatibility. Or maybe there will be a non-additive AMXv2.
Shippers end up eating the cost of these packages, and they are making an economic tradeoff: Slower deliveries by following preferences vs. eating the cost of loss. They are choosing the latter. Maybe they haven't done the analysis right, or maybe the overall costs really are lower that way.
While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. Even your shiny new RTX 4090 runs FP64 at 1/64th rate.
2xFP32 for most basic operations can be 1/4th the rate of FP32. It is quite often the superior solution compared to using the FP64 support provided in GPU languages.
There was once a bank that looked the other way when lots of shady cash came in, allowed transfers of those amounts to to foreign banks, basically ignored KYC rules, etc. Word got around, and lots of criminals all over started using this bank for all of their money laundering purposes.
Some banking authority started noticing a lot of suspicious transactions, and was preparing to shut the whole thing down, disconnect the bank from all transfers, raid offices, arrest employees, trumpet press releases about how they're protecting the American financial system, etc... (ie, exactly what they are supposed to do).
The bank was, of course, a honeypot run by some other 3-letter agency, who was actively facilitating money laundering in order to collect enormous amounts of info about who was involved.
(basically the banking version of that 'encrypted phone' scheme).
The raids were mere hours away when someone put two and two together, and managed to get it called off.
This makes a lot more performance sense for those languages.
For example, you are selling a Widget for $20. Amazon says "we'll take $10 of that ourselves". You can sell your Widget elsewhere at lower overhead, but you can't pass those savings on to the buyer, which means the buyer has no incentive to shop elsewhere, which means there are no market forces encouraging Amazon to reduce their cut.
There are also no market forces preventing Amazon from increasing their cut. Tomorrow, they'll want $15 of that $20.
> When your device is locked with a passcode, Touch ID, or Face ID, all of your health and fitness data in the Health app — other than your Medical ID — is encrypted and inaccessible by default. Additionally, if you are using iOS 12 or later and turn on two-factor authentication, Apple will not be able to read your health and activity data synced to iCloud.
The two factor authentication is the mechanism for key distribution such that HealthKit data can be synced and migrated between your own devices, without being decryptable by apple.
You undermine your own argument. Ukraine's admission was never going to happen anyway, and everyone knows it. Putin also knows it. So that isn't why he is invading.
Arguments about NATO membership or repressed Russian speaking minorities and anything else (you get different justifications for the war depending on where you are in the world...) are fig leafs to exploit people's existing opinions of particular parties (in your case, about the US throwing its weight around).
The reality is far simpler: Putin wants the Ukraine personally. His own private reasons are irrelevant. He wants it. And he has the will and capability to take it. And so he is doing so.
I'm going to pick one one part of your statement in particular:
> US and the EU should've realized the only way to defuse this situation was to negotiate
Putin wants Ukraine. Negotiation of any kind was never going to prevent this invasion, unless the concession surrendering without a fight and having Putin install a government of its choice.
The vast majority or LA county homes are not in a WUI zone, so wildfire extent can’t be used as an argument for this.
// a is a UInt64
let a = Int.random(in: 0..<Int.max)
// causes a fatal runtime error if out of range, halts execution
let b = UInt32(a)
// returns a UInt32?, which will be nil if out of range
let c = UInt32(exactly: a)
// another approach for exact conversion:
guard let d = UInt32(exactly: a) else {
// conversion failed
// handle error and return
return
}
// 'd' is a UInt32 without any bits lost
// always succeeds, will return a UInt32, either clamped or truncated. Truncation just cuts off the high bits.
let e = UInt32(clamping: a)
let f = UInt32(truncatingIfNeeded: a)I'm curious how the problem effectively gets sliced.
The broader legislature has no interest in such a tax.
This is the bill in question: http://leginfo.legislature.ca.gov/faces/billStatusClient.xht...
Edit: also note that this article is on the WSJ opinion page, and didn’t come from the news desk.
When the planes were grounded, Boeing kept producing them assuming the issue would be resolved quickly. As of January 2020, slightly before Covid, they had 400 planes built, but not delivered to customers (and so customers haven’t paid for them). Boeing was funding these aircraft with debt.
All of a sudden, demand for air travel drops off a cliff.
All those airlines now decide “I’m just not going to take delivery of those aircraft”. Which also means “I’m not going to pay for them”.
Had the timing gone in the other order, all of those aircraft would have been delivered, and paid for, and airlines would have been holding the bag. (and the covid crisis would have limited the damages airlines could claim, and thus demand from Boeing, if they could meet their reduced schedules with other aircraft).
M1 apparently has much lower power consumption.
So something else is going on other than “Apple is willing to spend more to make cores wider”.
A12Z/DTK: HW does not support virtualization at all.
Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated).
What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not familiar if there is any usable high performance x86_64->arm translation available for linux.
Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming.
Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu?
Docker w/ full x86 image (incl. kernel): I don't think this is possible?
To have adopted any of those other languages requires dramatic changes to a huge amount of platform APIs, along with on-going challenges of divergence. Put another way, any other language would have basically forked the entire platform.
The Swift developers definitely have ambitions beyond being a compatible with Apple's existing SDKs, but that's the fundamental thing Swift does that no other language can do.
I find that paper maps are dramatically better for me than anything on a screen, simply because they can be so much bigger and higher resolution at the same time. It is far easier to get a feel for an area on a table-top sized map printed at high PPI than on my 4K 27" monitors.
As for rapidly tracking the fire perimeters: Despite what the original article says, this mapping process is already happening. You can see the very outlines updated daily, with lots of fine detail, on inciweb.
I live in a rural area, between a major population center and a major resort area, with one major highway and a few small back roads that provide alternate paths for part of the highways route. Every summer weekend the highway becomes highly congested.
Google quickly starts routing people down the back roads because of a 30 minute delay on the highway. A sudden crush of cars hits these back roads, and they end up gridlocked for 3-4 hours. Google then realizes traffic is literally stopped on these roads, and stops sending new traffic down those routes. But the people already on them are still stuck for hours.
It gets smelly when a bunch of drivers take a shit on the side of the road because they can’t go anywhere else, and leave it there.
All because Google simultaneously made an ‘individually optimal’ decision for a whole bunch of individual drivers at once.
——
Another example in the same area actually causes a backup on the highway itself. Google started suggesting one back road that required an unprotected left turn across oncoming traffic on the highway, to avoid a 10-15 minute delay further on the highway. Drivers dutifully followed directions by getting into the left turn lane.
The drain rate of the left turn rate is slow because oncoming traffic is also high. The left turn lane fills up, and one driver with directions to turn then stops in the traffic lanes to wait for room to get into the turn lane. And suddenly the highway is now encountering 2-3 hour delays that don’t clear for most of the day.
I’m also not immediately seeing a non-privacy reason to make this change either...
dlopen() will look for the dylib first (as today), and if the file doesn't exist, it'll look in the shared cache.
So the only people this actually impacts are those who stat() system-provided dylibs before calling dlopen(). They should just skip the stat(), and go straight to calling dlopen().
Certainly not worthy of the end-of-the-world vibes in the twitter thread...
For the same number of SMs, you're also paying substantial area for the tensor cores, ray tracing acceleration, independent thread scheduling, different I/O to support memory technologies, more NV link, larger caches, etc. That stuff didn't happen for free.
A simply die shrunk 1080 would have had more TFlops than what we have, but it wouldn't be as interesting of a product.
They are basically a big array of ALUs hard-wired in a grid to do a matrix multiply: The connectivity between ALUs is baked into silicon: no general purpose register file to hold the intermediate results, just wires directly from the output of one ALU into the input of the next (well, and registers for pipelining).
No overhead for register files, instruction decoding, instruction scheduling, load/store units, cache, etc. (load/store is handled by the usual SM instruction set).
This is basically the same concept you find in any "AI acceleration" hardware (Google's TPUs, various neural-thingys you find in Phones, etc).
As for using in games, this hardware is generally idle, except for a few cases (typically because Nvidia did the work to light them up):
- upscaling from lower resolution rendered products to higher resolution (Nvidia markets this under the name "Deep Learning Super Sampling"), which is basically taking a derivation Temporal Anti-aliasing and mapping it onto the tensor cores to exploit that hardware
- Doing CNN-like denoising and reconstruction of a noisy ray traced image.