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!
This is my own channel, but I made a 10+ part series on modern ARM assembly you may find interesting. I used CPUlator for the demonstrations, which is a nice way to inspect the memory as well as the individual registers as you are running a program.
> 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.
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).
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.
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.
Work + Personal research. The main industry usecase for RE is malware analysis.
The flow is essentially:
1. Break down a sample to determine behavior; this is usually a mixture of static (decompilation) and dynamic (running the sample in a safe env /w a debugger) analysis.
2. Write a signature / detection based on unique identifiers you discover inside the payload. This is where the real skill comes in; being extremely clever with Regex is helpful here.
It's a tricky game to keep up with malware developers. Write a signature too specific, and all they have to do is recompile with a few string changes to defeat you. Conversely, if a detection is too broad, you run the risk of detecting benign software (aka a False Positive or FP).
Check out Jellyfin (open-source project) + it's associated clients. Pretty simple to spin up in a docker container, and if your machine is fast enough; it can auto-transcode for device and bandwidth limitations.
For example, your iPhone probably won't be able to stream an uncompressed blu-ray over 4G, Jellyfin can transcode the original file at a lower bitrate before sending to your device.
Any chance you'd consider making a version of this as a browser extension for paid subscribers?
What I really want is this functionality on unsupported websites/documentation. It would be killer to "ask" kagi a fact about the article or docs I'm already reading, even if it only traverses/parses the single page.
Personally, I find the 'knowledge half-life' problem to be easily solved with spaced repetition. I've used SuperMemo for a few years now, and have found it invaluable for retaining and revisiting old concepts, especially when switching between different tech stacks. The priority queue system of supermemo fixes the issues Anki and others have when collections grow to larger than 10K+ cards, where the daily load can often become unmanageable.
I find 30 minutes a day of supermemo, supplemented by an hour of purposefully randomized review on weekends keeps even very old topics near the forefront of my mind. It's like having a well-maintained toolbox I can throw at different problems at any time. The slight daily effort is more than compensated by the retention gains I've noticed over time.
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!