lauriewired

1. not that I can think of, due to the core split. It really has to be independent cores racing independent loads. anything clever you could do with kernel modules, page-table-land, or dynamically reacting via PMU counters would likely cost microseconds...far larger than the 10s-100s of nanoseconds you gain.

what I wished I had during this project is a hypothetical hedged_load ISA instruction. Issue two requests to two memory controllers and drop the loser. That would let the strategy work on a single thread! Or, even better, integrating the behavior into the memory controller itself, which would be transparent to all software without recompilation. But, you’d have to convince Intel/AMD/someone else :)

2. It’s called a “smokeninja”. Fairly popular in product photography circles, it’s quite fun!

Nope, there isn’t a tradeoff; median latency isn’t affected. I don’t think you understand the code. The p50 is identical between a single read and the hedged strategy.

The clflush is there because the technique targets data that will miss the cache anyway. If your working set fits in L1, you don’t need this.

Also, AWS Graviton instances absolutely do not expose per-channel memory controller counter PMUs. That’s why you have to use timing-based channel discovery.

The IBM z-system is neat! But my technique will work on commodity hardware in userspace, and you can easily only sacrifice half the space if you accept 2-way instead of 8+ way hedging. It’s entirely up to you how many channel copies you want to use.

Your reply was quite rude, but I hope this is informative.

This is correct. The majority of cases I have to rely on my own expertise.

It's useful for the automation of small repetitive tasks here and there. I was never expecting it to gain the traction that it did; anyone saying they expect it to replace reverse engineers (it won't) is wildly misunderstanding the original intent.

Quite trivial to create binaries that massively confuse LLMs!

> If you can't make CPUs and you can't keep the internet up, where are you going to get the equipment for enough "private peering or Sat links" for the privileged?

Storage. You only need a few hundred working systems to keep a backbone alive. Electron migration doesn’t kill transistors if they are off and in a closet.

> You need CPUs to build optical media drives! If you can't build CPUs you're not using optical media in 30 years.

You don’t need to make new drives; there are already millions of DVD/Bluray devices available. The small microcontrollers on optical drives are on wide node sizes, which also make them more resilient to degradation.

> they're definitely f-ing going to have been able to repeat all the R&D to build a 68k CPU in 30 years (and that's assuming you've destroy all the literature and mind-wiped everyone with any knowledge of semiconductor manufacturing).

If you read the post, the scenario clearly states “no further silicon designs ever get manufactured”. It’s a thought experiment, nothing more.

It takes a bit of curation, but I find substack's algorithm to be quite good at recommending other bloggers I'd be interested in.

It's also pretty trivial to find what writers other bloggers enjoy based on the "reads" list tab. My algorithm is:

-> Find blogger you like -> Check their substack "reads" for other writers -> Repeat

The three “flaws” that this post lists are exactly what the industry has been moving away from for the last decade.

Arm’s SVE, and RISC-V’s vector extension are all vector-length-agnostic. RISC-V’s implementation is particularly nice, you only have to compile for one code path (unlike avx with the need for fat-binary else/if trees).

I touch on this briefly in the video, beside Claude Desktop, 5ire is a fairly model-agnostic local MCP client, I'm sure there are others.

sama also recently mentioned ChatGPT Desktop is getting MCP client functionality "soon".

As for remote clients, Cloudflare has some really useful tooling, look at their "AI Playground".

That's just my natural speaking voice. I'm a small person, and everyone sounds different.

I'd be happy to focus on the tool, or the content of the channel, rather than how I sound.

Ghidra is very feature-rich for code decompilation, however it doesn't handle dropping in an entire application bundle; only single executables.

Apple application files are special, bundling up resources and (potentially multiple) executables into the same package.

Many of these resource files are important for analysis, but have custom encodings by Apple. Malimite "digests" this information into a logical way.

It’s more like LLM-optional.

Malimite is first and foremost intended to be a tool to help Reverse Engineer iOS/Mac binaries, much like JADX for Android.

As it turns out, LLMs are quite good at “converting” C-Pseudocode into an approximation of the original Swift or Objective-C code. Therefore, you can optionally use the LLM extension to help analysis.

Of course, it’s not 100% accurate, but significantly easier to read, and I find it to save hours of manual research.

It might be better to think of Malimite as "JADX but for iOS/Mac".

(JADX is a very popular Android decompiler)

Ghidra is quite limiting, and the workflow makes iOS reverse engineering quite cumbersome.

Malimite is intended to have a swappable back-end, so theoretically compilers other than Ghidra can be used in the future.

Does no one realize this is a thinly-veiled ad? The URL is bizarre

P550 cores don't have vector extensions. It's actually quite an old design, from 2021. What you'd want is SiFive P670 cores, which are RVA22 compliant with the vector 1.0 spec.