pjdesno

The whole point of lock-free data structures and algorithms is that sometimes you can do better by using these atomic operations inside your own code, rather than using a one-size-fits-all mutex based on those same atomic operations.

(Note that I say "sometimes". Too many people believe that lock-free structures are always faster; as always, your mileage may vary. In this case it's a huge win, to the point where I would bet it almost always moves the bottleneck to the code actually using the ring buffer.)

Most scientific research represents about the same amount of improvement over the state of the art as the shitty web app or whatever that you're working on right now. It's not zero, but very few are going to be groundbreaking. And since the rules are that we all have to publish papers[*], the scientific literature (at least in my field, CS) looks less like a carefully curated library of works by geniuses, and more like an Amazon or Etsy marketplace of ideas, where most are crappy.

[* just like software engineers have to write code, even if the product ends up being shitty or ultimately gets canceled]

Neither of us are going to be changing how the system works, so my advice is to deal with it.

I'll add that the reaction of most of academia will be "It's in a management journal - of course it's nonsense."

But what about availability? If you ask most of our users whether they’d prefer 4 9s of availability or 10% more money to spend on CPUs, they choose the CPUs. We asked them.

There are a lot of availability-insensitive workloads in the commercial world, as well, like AI training. What matters in those cases is how much computing you get done by the end of the month, and for a fixed budget a UPS reduces this number.

It was cool to see them grow into a real competitor for the big distributors.

  https://traditional.leidenranking.com/ranking/2025/list

My Chinese colleagues have heard of it, but never considered it a top-ranked school, and a quick inspection of their CS faculty pages shows a distinct lack of PhDs from top-ranked Chinese or US schools. It's possible their math faculty is amazing, but I think it's more likely that something underhanded is going on...

If you're providing a service that needs to keep running, you need a strategy for handling unexpected errors. It can be as simple as "fail the request" or "reboot the system", or more complicated. But you need to consider system requirements and the recovery strategy for meeting them when you're writing your code.

Long, long ago I worked with some engineers who thought it was just fine that our big piece of (prototype) telecom equipment took half an hour to boot because of poor choices on their part. Target availability for the device was 5 9s, which is 5 minutes of downtime per year. They didn't seem to realize the contradiction.

I've boycotted reviewing for Elsevier for years, but it's easy for me - I'm in CS, where ACM, USENIX and IEEE offer higher-status publication venues and Elsevier journals are decidedly second-tier.

I fear that progress in this field might be handicapped by the fact that the folks who know a lot of type theory have little idea of how hardware works, and rarely care, and most of the folks who know how hardware works don't know a lot about types beyond possible bad experiences with VHDL. Luckily there's a non-zero set of people in the overlap, though.

I disagreed strongly - I think X-per-second should be decimal, to correspond to Hertz. But for quantity, binary seems better. (modern CS papers tend to use MiB, GiB etc. as abbreviations for the binary units)

Fun fact - for a long time consumer SSDs had roughly 7.37% over-provisioning, because that's what you get when you put X GB (binary) of raw flash into a box, and advertise it as X GB (decimal) of usable storage. (probably a bit less, as a few blocks of the X binary GB of flash would probably be DOA) With TLC, QLC, and SLC-mode caching in modern drives the numbers aren't as simple anymore, though.

That's basically what the administration was trying to do here, under a legal system which (unlike Venezuela in the 70s) is very keen on protecting corporate investment. It seems like a classic "takings" case.

If it's a traditional 1-car driveway that's about $70K worth of land, although in the end it's zero-sum because it takes away an on-street spot. Parking garages for larger developments probably cost as much or more per parking space - they use less land, but they're expensive to build.

It's insane, and they're trying to fix it, and approving special permits left and right to omit the spots.

That leaves non-violence, which is perhaps a misnomer - there's often plenty of violence, but it's used by the government, not its opponents. When non-violence works, it's typically because those working for the government start refusing to kill their fellow countrymen - they defect, in non-violence scholar-speak.

There's an authoritarian playbook for countering this - you recruit your forces from ethnic minorities, often rural, who already hate the people who are protesting. Thus you see ICE recruits from the Deep South and National Guard troops from Texas being sent into Northern cities.

Developers may understand that "XYZ is better", but if management provides enough incentives for "not XYZ", they're going to get "not XYZ".

That's one of the things that publication is for.

The paper is a well-supported (if not well-proofread) position paper, synthesizing the author's thoughts and others' prior work but not reporting any new experimental results or artifacts. The author isn't an academic, but someone at Amazon who has written nearly 20 articles like this, many reporting on the intersection of academic theory and the real world, all published in Software Engineering Notes.

As an academic (in systems, not software engineering) who spent 15 years in industry before grad school, I think this perspective is valuable. In addition academics don't get much credit for this sort of article, so there are a lot fewer of them than there ought to be.

  $ time ./wc-avx2 < bible-100.txt
  82113300
  
  real    0m0.395s
  user    0m0.196s
  sys     0m0.117s

    $ time ./optimized < bible-100.txt > /dev/null

    real    0m1.525s
    user    0m1.477s
    sys     0m0.048s

In the optimized case:

  real    0m0.395s
  user    0m0.196s
  sys     0m0.117s

In other words: yes, the author managed to beat the speed of the disk subsystem. With two caveats:

1. not by much - similar attention to tweaking of I/O parameters might improve I/O performance quite a bit.

2. the I/O path is CPU-bound. Those 117ms (38% of all CPU cycles) are all spent in the disk I/O and file system kernel code; if both the disk and your user code were infinitely fast, the command would still take 117ms. (but those I/O tweaks might reduce that number)

Note that the slow code numbers are with a warm cache, showing 48ms of system time - in this case only the ext4 code has to run in the kernel, as data is already cached in memory. In the cold cache case it has to run the disk driver code, as well, for a total of 117ms.

1) "interop with C" is part of the fundamental requirements specification for any code running in the Linux kernel. If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job.

2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. This is a fundamental limitation, and again is an issue when the fundamental requirement for the task is to interface to data structures implemented as doubly-linked lists.

No matter how good a language is, if it doesn't have support for floating point types, it's not a good language for implementing math libraries. For most applications, the inability to safely express doubly-linked lists and difficulty in interfacing with C aren't fundamental problems - just don't use doubly-linked lists or interface with C code. (well, you still have to call system libraries, but these are slow-moving APIs that can be wrapped by Rust experts) For this particular example, however, C interop and doubly-linked lists are fundamental parts of the problem to be solved by the code.

Not quite, and an interesting story that fits these engineering maxims better than you might think.

An analog channel with the bandwidth and SNR characteristics of a landline phone line has (IIRC) a Shannon capacity of 30-something kbit/s, which was closely approached with V.34, which used trellis coded modulation plus basically every other coding and equalization mechanism they knew of at the time to get to 33.6kb/s on a good day.

But... by the 80s or so the phone system was only analog for the "last mile" to the home - the rest of the system was digital, sending 8-bit samples (using logarithmic mu-law encoding) at a sampling rate of 8000 samples/s, and if you had a bunch of phone lines coming into a facility you could get those lines delivered over a digital T1 link.

Eventually someone realized that if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher - in theory the limit is probably 64000 bit/s, i.e. the bit rate of the digital link, although V.90 could only achieve about 56000 b/s in theory, and more like 53kb/s in practice. (in particular, the FCC limited the total signal power, which means not all 64000 combinations of bits in a second of audio would be allowable)

I worked with modem modulation folks when I was a co-op student in the mid-80s. They had spent their lives thinking about the world in terms of analog channels, and it took some serious out-of-the-box thinking on someone's part to realize that the channel was no longer analog, and that you could take advantage of that.

A few years later those same folks all ended up working on cable modems, and it was back to the purely analog world again.

The specific lines about Ellison and a lawnmower start at 38:28 in the linked video; the entire Oracle rant starts at about 34:00.

(this is at a campus Dunkies where there's no drive-through, and I have a hard deadline to start my lecture. If there's no line at the register, and I've got five minutes before class starts in a room down the hall, it shouldn't take a logistical genius to get me a regular coffee in time for class)

Actually that's a really common use - I've bought a half dozen or so Dell rack mount servers in the last 5 years or so, and work with folks who buy orders of magnitude more, and we all spec RAID0 SATA boot drives. If SATA goes away, I think you'll find low-capacity SAS drives filling that niche.

I highly doubt you'll find M.2 drives filling that niche, either. 2.5" drives can be replaced without opening the machine, too, which is a major win - every time you pull the machine out on its rails and pop the top is another opportunity for cables to come out or other things to go wrong.

#1 is all NVMe. It's dominated by laptops, and desktops (which are still 30% or so of shipments) are probably at the high end of the performance range.

#2 isn't a big market, and takes what they can get. Like #3, most of them can just plug in SAS drives instead of SATA.

#3 - there's an enterprise market for capacity drives with a lower per-device cost overhead than NVMe - it's surprisingly expensive to build a box that will hold dozens of NVMe drives - but SAS is twice as fast as SATA, and you can re-use the adapters and mechanicals that you're already using for SATA. (pretty much every non-motherboard SATA adapter is SAS/SATA already, and has been that way for a decade)

#4 - cloud uses capacity HDDs and both performance and capacity NVMe. They probably buy >50% of the HDD capacity sold today; I'm not sure what share of the SSD market they buy. The vendors produce whatever the big cloud providers want; I assume this announcement means SATA SSDs aren't on their list.

I would guess that SATA will stay on the market for a long time in two forms: - crap SSDs, for the die-hards on HN and other places :-) - HDDs, because they don't need the higher SAS transfer rate for the foreseeable future, and for the drive vendor it's probably just a different firmware load on the same silicon.

Since it was offline, the bug was obvious although a bit frustrating - you had to put in multiple waypoints to make it forget its urge to send you on the ferry to Hull when you were trying to get to parts of the South Shore.

This seems like an entirely different level of craziness, though.

I fairly frequently leave my phone in the office and take a clipboard full of lined paper and a ballpoint to a place where I can write without access to the internet - I've got a number of published CS papers and at least one funded grant where a significant amount of writing was done in longhand on paper.

Of course this would require a bit of software work and maybe a brain swap to make it into the sort of portable typewriter that I'm really looking for, but given this as a starting point it should be fairly easy.

One question I have - what is the finished weight?

With S3 you just do an http request and you’re done.

A lot of folks get hung up on the theoretical equivalence of things, and forget that their favorite solution may be flat out unworkable in practice for reasons that have nothing to do with the theoretical features they’re talking about.