I've used bubblesort in a coding interview, because it was the easiest to remember and get correct on a whiteboard in short time.-

Reminds me of an interview I had a while ago. The interviewer in all seriousness asked me to code up a sorting algorithm on the whiteboard. He was more of a business person than technical so was probably thinking of insertion, selection and bubblesort.

I said sure, quicksort, mergesort or radixsort?

He just said "okay, let's skip to the next question". :)

I'd be tempted to ask under what circumstances they'd expect me to be coding a sorting routine... Seems a bit like asking an accountant to add two 10 digit numbers.

BTW. Feeding that AI boom, that is driving up the cost of hardware... while at the same time asking people to buy new computers only to run the next version of their OS.

Not a great plan.

BTW. They did the same with Maps and the PDF reader: the two apps I used the most on my Windows tablet. An "upgrade" replaced the app with a nonce. That just made me so incredibly angry.

> Efficiency: Uses a lazy-loading piece tree to avoid loading huge files into RAM

I once started writing a text editor on Linux, and first went down a similar route: a piece table over a mmap()'d file. But I abandoned using mmap, because Linux file systems typically don't have mandatory locking enabled, so you can't be sure that the file data won't be modified by another program.

(Then I got bogged down in Unicode handling... so 95% of the code became just about that, and I tired of it)

I considered using mmap to help manage the caching but what if your file is hosted on S3 or whatever? (Something I'm planning to support eventually)

So I opted for explicit management of chunks, also gives me more control and consistent cross platform behavior.

I'm wondering how the compiler optimised add_v3() and add_v4() though.

Was it through "idiom detection", i.e. by recognising those specific patterns, or did the compiler deduce the answers them through some more involved analysis?

add_v3() is the result of induction variable simplification: https://llvm.org/doxygen/IndVarSimplify_8cpp_source.html

Scalar Evolution is one way loops can be simplified

They don't. In the US, most children killed by cars had even been run over in the family's own driveway — because the SUV/truck had poor visibility.

Perhaps the headline should have been changed when the post was made here.

Or people should read beyond the headline before commenting

“Intel-manufactured Apple Silicon could return to Apple’s computers in 2027”

Dirt cheap M1's?

M1’s already dead, A18 Pro’s where it’s at for that.

The budget MacBook due next year is widely rumored to adopt the A18 Pro CPU.

> https://www.macrumors.com/2025/06/30/new-macbook-with-a18-ch...

Lots of rumors about a new Macbook with a Axx chip in the pipe.

There is a `c.mv` instruction in the compressed set, which most RISC-V processors implement.

That, and `add rd, rs, x0` could (like the zeroing idiom on x86), run entirely in the decoding and register-renaming stages of a processor.

RISC-V does actually have quite a few idioms. Some idioms are multi-instruction sequences ("macro ops") that could get folded into single micro-ops ("macro-op fusion"/"instruction fusion"): for example `lui` followed by `addi` for loading a 32-bit constant, and left shift followed by right shift for extracting a bitfield.

x86 has no architectural zero register, but a x86 CPU could have a microarchitectural zero register.

And when the instruction decoder in such a CPU with register renaming sees `xor eax, eax`, it just makes `eax` point to the zero register for instructions after it. It does not have to put any instruction into the pipeline, and it takes effectively 0 cycles. That is what makes the "zeroing idiom" so powerful.

You can't always see a person's dark side before you have spent many months with them.