Interesting article but it gave me a bit of a panic attack. Benchmarking (with TPC or otherwise) is NOT the way to determine the correct approach here; that is strictly only to be used for databases (typically RDBMS) effectively “owning” the complete hardware they are running on. An embedded database might be used in that manner if it’s operating as the backend for a pure crud application that performs ~zero server side rendering, parsing, validation, etc and is essentially just an async http-to-SQLite interface. But more likely than not, an embedded db will be used and deployed on machines (not necessarily even servers) serving many a purpose, and need to perform best both within the confines of the resources available to the machine and in relative terms, necessarily making tradeoffs that might sacrifice performance for “value” in terms of CPU or memory usage.
This isn’t just with regards to benchmarking, it’s an essential consideration *any* time you are taking ownership of the cache away from the kernel, which is the only piece in the stack that has viability into the global state and can be trusted to give back memory under pressure to ensure everything plays nice together. It’s not limited to just databases or even just memory, for example FreeBSD has had greater than its fair share of issues that trace back to the ZFS having a separate cache from the kernel (despite the much tighter integration between the two and presence of various mechanisms to address pathological cases). You can also refer to any comparison or benchmark between the use of spinlocks vs mutexes: spin locks consistently perform better in/on (micro)benchmarks but are almost always actually the worse choice in the grand scheme of things because the benchmarks falsely assume complete and uncontended ownership over system resources.
This isn’t even io_uring specific and I’m hardly the first to bring this up in the context of O_DIRECT.
You’ve misunderstood what they’re saying. Not that the benchmark is invalid, but that it’s an incomplete picture if your use case is a mixed set of applications where DB performance is not the only important thing. Hence the comment about memory - O_DIRECT is optimal in terms of DB performance but then the caches are owned by the application and the kernel isn’t free to discard those caches whenever it wants like it can with the page cache. I’m not actually sold on this argument though - I have an embedded DB that with a very tiny block cache goes very very fast, and uses far less RAM than using the page cache because it knows when read ahead is called for vs when it’s not
What would be the correct way to do benchmarking/profiling here? I ask as I've started to run some for Vinyl cache to see what performance issues I can find, and I've quickly learned just how hard it is to get good, repeatable benchmarks that isolate the right thing.
No easy answer! You’d have to have a myriad of different test suites that as closely resemble your real world usage as possible. Or ship it behind a gate and let your users give you real world feedback if you’re at SQLite (not turso) scale - they’ve done that with a lot of ambiguous optimizations.
I think that’s only true on paper; in practice it’ll be true only when you have competing reads (at a thousand-foot view) and it might be possible to algorithmically bundle a portion thereof. It originally let SCSI controllers attached to spinning rust HDDs optimize physical manipulation of the disk heads to optimized queued reads of data in a “traveling salesman” sort of way, but modern nand flash can only internally read a full page at a time (which may be much greater than even the apparent physical sector size) anyway and with a strictly constant cost regardless of the “physical location” of the data on the non-existent platter. Old drives had optimization constraints like higher sequential read speeds at the outside of the platter (more bytes per physical rotation) and extremely pathological cases for data written to the innermost tracks of the platter. Individual requests were much finer-grained and the latency was much more varied, so a request from app/thread X for as little as 512 bytes from one location could be cheaply piggy-backed on an existing request from app/thread Y to read multiple megabytes from a physically proximate source that would otherwise have seriously delayed or starved the queued waiting read while the outstanding request was serviced.
In fact, one consistently sees higher bulk IO numbers when using physical media that has been formatted with a large sector size compared to the old 512 byte fixed emulated size. You’d routinely see lower latency and higher IOPs with 4kn (HDDs or SSDs) than you would with 512e disks, even with SCSI or AHCI controllers that featured similar pipelining support to today’s NVME controllers (or even if you place a spinning rust HDD behind NVMe today!).
Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests because the I/O queue isn’t infinite. So both the Linux kernel and the SSD microcontroller still benefit from merging contiguous requests on their end. However, if you issue it correctly at the application level that’s still going to be better in that you’re never going to encounter a situation where you accidentally don’t get the desired coalescing.
> Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests
FYI/fwiw Fish shell autocompletes branches sorted by last commit date when writing out git commands. It also provides completions for commitish objects grouped by class, giving precedence to the usual targets first, with each group sorted by its own sort key. Handy!
Not to knock on RISC-V, which I’ve been following from the embedded side of things for many years now, but I feel I must question the value of a license-free ISA in this specific market segment at this time.
Surely between the squeeze on RAM and storage pricing and the exorbitant costs of training or mass-inference scale GPUs (if you’re going into AI), the nominal cost of the CPU licensing is really not going to make or brake anything or unlock some new business viability?
Even RISC-V aside, we are essentially in a position that would have been impossible to even dream of ten or twenty years ago when Intel was the only player in the game.
Wouldn’t buying off-lease hardware (not even in bulk) give you better performance per dollar, better compatibility, and more options?
Not to say any of this will always be the case; even if RAM pricing doesn’t come down, storage will, and RISC-V processors will (maybe) eventually actually be competitive when it comes to SOTA performance, but today in 2026?
The promise of RISC-V is probably not that it cuts pennies of a $1 embedded ARM core (or dollars off a $100 core).
Instead, it’s that Moore’s law keeps on trucking along, so now we have lots of dark silicon (you cannot turn the whole core on at once, or it will turn into a puddle of glass) and specialized silicon.
RISC-V removes all the gatekeepers (except TSMC and the other fabs) that historically blocked new specialized silicon.
I could get an ARM license, but suspect that, at best, that means dealing with sales folks and also building out a legal division just to manage the license.
I could be wrong, but it’s easier to go with the open core, in the same way that I suspect I cannot afford to figure out how much I would have to pay in order to license windows for my servers.
The point with RISC-V is that you can first pick the architecture and then have many potential providers and you are sure to never be stuck with one provider.
Its not the cost that is the major change, its the business model.
Granted ARM potentially gives you part of that, but its still tricky.
And of course this theory only works out if you have enough competitive providers. But that's always questionable.
I think in the server space the story is more about Chinese autonomy from US regulation/control. As long as they're dependent on closed western IP there is risk of being rug pulled, that having their own RISC-V IP eliminates.
In the embedded / microcontroller space it's a different story. License cost there must be absolutely key, and I think less vulnerable on a per unit basis to the RAM etc storage factors you mention. I don't actually know the numbers but I'd expect that as a percent of total BoM cost the ARM license must be higher for microcontrollers than bigger machines? Maybe someone more qualified knows the answer to this.
The article doesn't put much emphasis on it, but like it says this is still a development system. It's not intending itself to be competitive with ARM and x86 servers for the typical server buyer in 2026.
Yeah it seems to be aimed at people wanting to do Risc-V CI for future stuff, not as a "Real" product thats competitive. They need software to work on Risc-V to sell stuff in future.
0% APR for 12 months (24 for iPhones only?) from Apple Financial Services for a device that can approach or even exceed what we were paying for new cars just a few years ago. Apple is definitely making bank off these financing offers, and with very little risk as unlike a car these Mac Studios don’t lose 20% of their value when you drive them off the lot.
Are you sayin 0% is bad? What is better then? If you have the means, pay outright, no? It used to be a lot worse, paying $16K+ for a 128MB Quadra something based RIP in mid nineties . Do you mean that these things are overpriced from the get go?
I am merely pointing out additional revenue streams for Apple here. They make money off the hardware and again off the financing. Car manufacturers and have much lower margins and finance via their financial arms with much less predatory terms than your average credit card. The zero percent APR is very attractive, and easy to convince yourself to go with something above what you can afford. Times are good for Apple.
Good for them. Things cost what they do. I hear you that one can fall into the 0% interest trap, but that’s on us.
Not that I want it to happen, but I wouldn’t be surprised if Apple could get away with even higher prices today. Like 50% more retail on everything. They are holding the line, but I wonder for how long and why. They can pretty much charge what they want.
My friend, the same way everyone else does. It goes from 0% to 28% interest when you miss a payment. Those are rates normal lenders fall asleep dreaming of.
Neither is the right alternative to compare to. You aren’t going to hit 100% utilization (if you are, ignore me, this doesn’t some to you, and write a blogpost for me to read and share).
The comparison should be against renting in the cloud for the duration of your task for training and research or using pay-per-api-call providers for general inference instead of buying your own hardware (and paying the electricity and cooling bills on top), because let’s face it, the models you want to use are probably the same ones available on inference providers (but, yes, some are more trustworthy than others).
Speaking as someone that does ML/AI research, you are essentially paying a huge premium for being able to just run your Python script at any time without setting up a deployment script and harness to run the job remotely, while your hardware sits essentially idle the rest of the time.
The only way to make the math work is if you rent your hardware in the background for inference while you’re not using it in anger, but despite all the startups and promises that has never become as streamlined as mining bitcoins or shitcoins used to be and they don’t pay out as much as they say they would. Renting your hardware for training is another option but doing that is a lot more involved, options are fewer and farther in between, you won’t get as much utilization out of it, and doesn’t let you feasibly abort running tasks at a moment’s notice.
My card (RTX Pro 6000) is always doing something all the time from my queue; like some synthetic dataset generation up next. I still actively use runpods and openrouter for scaled stuff, I was spending a bit and then did the maths, and invested in it.
The maths to me was basically equivalent to prepaying for 242 days of runpod pricing for the same GPU; and I reckon I'd be able to get 6+ years of use out of this card with 96GB.
Plus there's the resell value -- it's actually appreciated by ~50% since I bought it.
Plus I do really enjoy that it's 100% local. I wouldn't feel comfortable giving my agents this much information if inference wasn't 100% local.
I wouldn't get another one, I wouldn't have as much value, but one is definitely paying off for me on the financial side.
I'm a fan of JpegXL and happy to see support finally begin to coalesce around it on the browser scene, but I was wondering if anyone knew what goes into the decision of whether or not to consider adding encode support, e.g. via offscreenCanvas.convertToBlob() or whatever. How did browsers (minus Safari, of course) end up deciding to add support for WebP encode in addition to JPEG and PNG?
It often comes down to compat, and developer requests. Personally I find in-browser encoding for images inadequate, because it doesn't expose enough options. When we built https://squoosh.app/, we exposed the browser encoders for completeness, but they're pretty bad compared to the wasm codecs.
I love your editor/comparison tool. Would you be open to adding browser WebP?
Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.
Yeah it's the latter. I'm going to look into adding transcoding, but Squoosh is currently set up to pass a bitmap to the encoder rather than the original image, because the original image can be processed first.
I can totally see how this feature would upend most architectures. Great work, I am adding a todo list action item up see if the performance can’t work out in favor of using this in place of the browser APIs we currently run to maybe adopt it. Love what you’ve done with the package and the site (this isn’t the first time it’s come on my radar, but you’ve spurred me to actually do something about it this time).
