I’m more familiar with RISC-V than I am with ARM though it’s my understanding they’re quite similar.

• ARM/RISC-V are load-store architectures, meaning they divide instructions between loading/storing and doing computation. x86 on the other hand is a register-memory architecture, having instructions that do both computation as well as loading/storing.

• ARM/RISC-V also have weaker guarantees as to memory ordering allowing for less synchronization between cores, however RISC-V has an extension to enforce the same guarantees as x86 and Apple’s M-series CPU have a similar extension for ARM. If you want to emulate x86 applications on ARM/RISC-V these kinds of extensions are essential for performance.

• ARM/RISC-V instructions are variable width but only in a limited sense. They have “compressed instructions” - 2 bytes instead of 4 - to increase instruction density in order to compete with x86’s true variable width instructions. They’re fairly close in instruction density, though compressed instructions are annoying for compilers to handle due to instruction alignment. 4 byte instructions must be aligned to 4 bytes, so if you have 3 instructions A, B and C but only B has a compressed version then you can’t actually use it because there must be 4 bytes between instructions A and C.

• ARM/RISC-V also makes backwards compatibility entirely optional, Apple’s M-series don’t implement 32-bit mode for instance, whereas x86-64 still has “real mode” for running 16 bit operating systems.

There’s also a number of other differences, like the number of registers, page table formats, operating modes, etc, but those are the more fundamental ones I can think of.

Up until your post I had thought it exactly was the size of the instruction set with x86 having lots of very specific multi-step-in-a-single instruction as well as crufty instruction for backwards compatibility (like MPSADBW).

The MPSADBW thing likely comes from the hackaday article on why “x86 needs to die”. The kinda funny thing about that is MPSADBW is actually a really important instruction for (apparently) video decoding; ARM even has a similar instruction called SABD.

x86 does have a large number of instructions (even more so if you want to count the variants of each), but ARM does not have a small number of instructions and a lot of that instruction complexity stops at the decoder. There’s a whole lot more to a CPU than the decoder.

compressed instruction set /= variable-width […]

Oh for sure, but before the days of super-scalars I don’t think the people pushing RISC would have agreed with you. Non-fixed instruction width is prototypically CISC.

For simpler cores it very much does matter, and “simpler core” here can also could mean barely superscalar, but with insane vector width, like one of 1024 GPU cores consisting mostly of APUs, no fancy branch prediction silicon, supporting enough hardware threads to hide latency and keep those APUs saturated. (Yes the RISC-V vector extension has opcodes for gather/scatter in case you’re wondering).

If you can simplify the instruction decoding that’s always a benefit - moreso the more cores you have.

Then, last but not least: RISC-V absolutely deserves the name it has because the whole thing started out at Berkeley.

You’ll get no disagreement from me on that. Maybe you misunderstood what I meant by “CISC-V would be just as exciting”? I meant that if there was a popular, well designed, open source CISC architecture that was looking to be the eventual future of computing instead of RISC-V then that would be just as exciting as RISC-V is now.

The original debate from the 80s that defined what RISC and CISC mean has already been settled and neither of those categories really apply anymore. Today all high performance CPUs are superscalar, use microcode, reorder instructions, have variable width instructions, vector instructions, etc. These are exactly the bits of complexity RISC was supposed to avoid in order to achieve higher clock speeds and therefore better performance. The microcode used in modern CPUs is very RISC like, and the instruction sets of ARM64/RISC-V and their extensions would have likely been called CISC in the 80s. All that to say the whole RISC vs CISC thing doesn’t really apply anymore and neither does it explain any differences between x86 and ARM. There are differences and they do matter, but by an large it’s not due to RISC vs CISC.

As for an example: if we compare the M1 and the 7840u (similar CPUs on a similar process node, one arm64 the other AMD64), the 7840u beats the M1 in performance per watt and outright performance. See https://www.cpu-monkey.com/en/compare_cpu-amd_ryzen_7_7840u-vs-apple_m1. Though the M1 has substantially better battery life than any 7840u laptop, which very clearly has nothing to do with performance per watt but rather design elements adjacent to the CPU.

In conclusion the major benefit of ARM and RISC-V really has very little to do with the ISA itself, but their more open nature allows manufacturers to build products that AMD and Intel can’t or don’t. CISC-V would be just as exciting.

Only until you have any other contributor, as you’re then no longer the sole copyright holder. If you still want to work like that you’ll need a CLA.

CRTs (apart from some exceptions) did not have a display buffer. The analog display signal is used to directly control the output of each electron gun in the CRT, without any digital processing happening in-between. The computer on the other end however does have display buffers, just like they do now; however eliminating extra buffers (like those used by modern monitors) does reduce latency.

if youre boiling water, it can be any arbitrary temperature above 100.

That’s not how boiling works. The water heats up to its boiling point where it stops and boils. While boiling the temperature does not increase, it stays exactly at the boiling point. This is called “Latent Heat”, at its boiling point water will absorb heat without increasing in temperature until it has absorbed enough for its phase to change.

There is an exception to this called superheating

100F is a fever; if you’re experiencing those regularly you should go see a doctor.

Distributed ledger data is typically spread across multiple nodes (computational devices) on a P2P network, where each replicates and saves an identical copy of the ledger data and updates itself independently of other nodes. The primary advantage of this distributed processing pattern is the lack of a central authority, which would constitute a single point of failure. When a ledger update transaction is broadcast to the P2P network, each distributed node processes a new update transaction independently, and then collectively all working nodes use a consensus algorithm to determine the correct copy of the updated ledger. Once a consensus has been determined, all the other nodes update themselves with the latest, correct copy of the updated ledger.

From your first link. This does not describe how git functions. Did you actually read the page?

The consensus problem requires agreement among a number of processes (or agents) for a single data value. Some of the processes (agents) may fail or be unreliable in other ways, so consensus protocols must be fault tolerant or resilient. The processes must somehow put forth their candidate values, communicate with one another, and agree on a single consensus value.

From your second this. Again this description does not match with git.

You’re right in that automation is not technically required; you can build a blockchain using git by having people perform the distribution and consensus algorithms themselves. Obviously that doesn’t make git itself a blockchain in the same way it doesn’t make IP a blockchain.

Key word distributed ledger. Git repositories don’t talk to each other except when told to do so by users.

I shouldn’t need to explain why an access key is not a consensus algorithm. Seriously?

Well, I’m saying Circulor is most likely lying about their “blockchain” actually being a blockchain, or that they’ve pointlessly set up extra nodes to perform redundant work in order to avoid technically lying.

Blockchain is completely pointless without 3rd parties being part of the network. It’s like me saying I run a personal social network for just myself.

Git is not a blockchain. There is no distributed ledger; no consensus algorithm.

Polestar uses contracts and audits to ethically source materials, not blockchain. It uses blockchain as a shitty append-only SQL database to (apparently) tell you where the materials came from. Let me quote from Circulor’s website:

data can be fed seamlessly to the blockchain via system integration using RESTful Web Service APIs with security and authentication protocols

So the chain is private and accessible only through a centralized, authenticated REST API. This is a traditional web application. A centralized append-only ledger is not even a blockchain.

He immediately got charged under the Espionage Act. If he didn’t leave or if he came back he’d be tried, without a jury, and get either life in prison or the death penalty.

Pouring water on lithium-ion battery fires is not only safe it’s the primary means of fighting them. It does not make them explode a second time, what it does do is cool down the battery.

Lithium battery fires though, there you’ll want a class D extinguisher. Those batteries aren’t in EVs though.

There’s a decent chance that’s still the salt lamp.

It’s an apples to oranges comparison. FPS bots are not playing the same game: they have perfect information in an imperfect information game.

It’s a natural result of their election system. First-past-the-post strongly disincentivizes third parties from running due to the “spoiler effect” - say there was a similar candidate to Biden that was pro-Palestine, any votes for this candidate take away votes from Biden thus making it easier for Trump to win. Most people don’t align with either party, but they don’t get much of a choice.

TLDs are valid in emails, as are IP V6 addresses, so checking for a . is technically not correct. For example a@b and a@[IPv6:2001:db8::1] are both valid email addresses.

The only one I’ve seen is the VW “e-up!”.

There’s vulnerabilities like the recent iMessage exploit that are executed remotely through no interaction by the user. In combination with the ability to self-spread you get mass exploits like WannaCry which spread to 300k+ computers in 7 hours. All you need is a network connection.