5 ms·

I always worry that hardware "locks in" software. SSDs showed up after everyone wrote their databases to be optimal on spinning rust, so SSDs were built to loo

I always worry that hardware "locks in" software. SSDs showed up after everyone wrote their databases to be optimal on spinning rust, so SSDs were built to look at the flow of requests, assume that the application was written for spinning rust, and optimize the data layout accordingly. Whether or not this is as good as brand-new software that managed the layout itself is debatable, and nobody will write that software anyway because they won't have users that have SSDs that let the database manage the disk in full. So the software has to tune it for one manufacturer's reorganization algorithm and hope for the best. The path to a "global maximum" remains unclear because of this. CPUs are similar. People started writing programs in C, so CPUs started optimizing for the outputs of C compilers. If someone were to invent CPUs and compilers today, the list of optimizations would probably be different, and the performance characteristics of real-world software would probably be different. (It's not just C; people wanted virtual address spaces, and that was slow in software, so now there is a TLB, etc.) Actually, it goes even deeper. Half the startups I see on HN related to software operations have a quickstart like "don't worry, you don't have to rewrite your code, we'll magically do everything for you". Why not just refactor the code? It would take about an hour, and then you don't need a crazy Rube Goldberg machine to achieve your desired results. (If you want specifics, think service meshes, and how they now detect what language your app is written in so they can rewrite your HTTP handling functions to pass around a trace ID. Back in the day, you just set outgoing.Headers["x-trace-id"] to incoming.Headers["x-trace-id"]. Now we have layers and layers of OS-level machinery that still don't do as good a job as spending half a day adjusting your codebase. Billions of dollars invested in saving half a developer day! Wow!)

JoeAltmaier 3y ago
Deeper than that! Such fundamentals as 'the stack is accessible by code' goes back to Fortran. C doesn't need that. The call stack and the 'display' stack could be different things and no C programmer need care. This is the root of attacks that rewrite the return address of a kernel call. If the return address were managed/protected outside normal data operation this would not exist.
- pklausler 3y ago
  Could you explain this in more detail, please? Fortran standards didn't support recursion until Fortran '90 and it wasn't easy to get stack allocation in F'77 compilers from vendors until the mid-80's or so, both long after Algol-like languages had them.
  - rtomanek 3y ago
    Wondering if they meant Forth rather than Fortran.
    - int_19h 3y ago
      It's even less true for Forth, given that it has separate data and return address stacks, and neither is addressable. There is some dedicated Forth hardware that relies on this fact to separate the stacks physically in hardware and e.g. use SRAM for them.
  - JoeAltmaier 3y ago
    Fortran programmers abused the stack in astonishing ways. They used to calculate offsets on the stack to variables in the previous frame you already returned from. The details of stack layout were coded into important applications. Intel designers tried to do better, but the Fortran people pushed back, hard.
paulmd 3y ago
Probably the biggest ground-up rethink of SSDs that I've seen is the Samsung SSDs with a key-value store mode. Like, think about it, a filesystem is really a database, right? Copy-on-write even makes the "transactionality" explicit. And a lot of high-performance databases will go farther and skip the filesystem and treat the device as block storage... which it is. The filesystem is a leaky abstraction with filesystem blocks and flash pages and flash block erasure, etc. Well, what if the SSD was just an object store? In that model you slice away a bunch of layers of abstraction and just let the SSD worry about all that. SSD says it's committed? Alright then, guess it is. Obviously you are very much at the mercy of the SSD to implement ACID correctly however...
- r1ch 3y ago
  Optane was also a contender for the biggest fundamental shift - byte addressable persistent memory with insane endurance is simply in a different class to every other SSD technology out there. No need for a FTL. No need for a DRAM / SLC cache. Unfortunately no software really took advantage of it, OSes still provisioned it as 512/4096 byte sectors, etc. so in standard benchmarks it never really looked that compelling over a regular NVME drive. But if the access patterns align, nothing can come close. Truly a technology ahead of its time.
  - MichaelZuo 3y ago
    It always made me surprised that Intel didn't market it better, such as forking linux and writing some custom additions that could allow the Optane drives to demonstrate real world 10x improvements.
    - paulmd 3y ago
      Intel already has Clear Linux actually. I don't think there's really a ton you can do at an OS level. ZFS L2ARC, system swap, etc, but a lot of the benefits would come from tuning DB configs/etc to suit the new hardware. If it's a fast SSD... ok are you the DBA? Similarly, PDIMM is really best utilized by a ground-up rethink of applications operating in a persistent context (think of like, javacard multicore 1TB or whatever). If you treat it as slow RAM it's gonna be slow RAM. The point would be building systems and applications that exploit the "writing the memory is now writing the disk" idiom. The ideal ecosytem for PDIMM isn't Linux at all, it's JVM, or LISP/Haskell. Or android I suppose lol.
wtallis 3y ago
Typical SSDs all assume your IO will be in 4kB-aligned chunks even though the storage is denominated in 512-byte sectors for compatibility reasons. So we have managed to move past the legacy of early hard drives to some degree, and are now being held back by assumptions that derive more from x86 page sizes.
throwawaylinux 3y ago
> I always worry that hardware "locks in" software. SSDs showed up after everyone wrote their databases to be optimal on spinning rust, so SSDs were built to look at the flow of requests, assume that the application was written for spinning rust, and optimize the data layout accordingly. It's not really that so much as contiguous or nearby access is faster on NAND, just like it's faster on hard disks, so software optimized layout and access patterns can look similar for both. > CPUs are similar. People started writing programs in C, so CPUs started optimizing for the outputs of C compilers. This didn't start at a one-way street. Actually CPUs were around first, so the first C compiler optimized for the CPU it generated code for. And from that point onward, C compilers optimize for the CPU. > If someone were to invent CPUs and compilers today, the list of optimizations would probably be different, and the performance characteristics of real-world software would probably be different. (It's not just C; people wanted virtual address spaces, and that was slow in software, so now there is a TLB, etc.) Unlikely. At the periphery yes, but there are fundamentally difficult things for CPUs and compilers to do which shape the solutions. Before somebody says "those fundamental difficulties might be different if we invented things differently" - the story of CPUs and of compiler optimization is about inventing ways to make those fundamental difficulties less difficult. There wasn't one day somebody invented the CPU and that was that, millions of people around the world have worked countless hours inventing and improving parts of CPUs and compilers for the past 70 years or so. There is inertia, but new ideas that are good enough can catch on even if it means entirely new models and ecosystems have to be invented. That's how we got multiprocessors, clusters, SIMD, GPUs.
- jrockway 3y ago
  > It's not really that so much as contiguous or nearby access is faster on NAND, just like it's faster on hard disks, so software optimized layout and access patterns can look similar for both. I worry about the pathological cases. Imagine you have an append-only log, and you write and fsync() one byte at a time. Each time you write a byte, the entire flash block (are they still 4KB these days?) has to be erased. So you end up chewing through 4000 durability cycles on your SSD, whereas if you had waited to write an exact 4KB block, then you'd use only 1. A hard drive is fine with this access pattern, though you'd probably be doing a lot of seeking to update fs metadata and it would be so slow that you'd come up with some other way. So maybe this pathology only exists in my mind.
sebazzz 3y ago
Didn't or do still some CPUs have instructions that can aid the JVM?
- saagarjha 3y ago
  Jazelle is generally deprecated.
  - bzzzt 3y ago
    Only since 2005 ;)
    - saagarjha 3y ago
      Sadly I’ve never gotten my hands on Jazelle hardware :(
- geraldhh 3y ago
  "aid" is very broad, so i'd say "yes" but recently there was an article on hn that talked about an arm-instruction for some js stuff.
yuhong 3y ago
[dead]
causi 3y ago
Whether or not this is as good as brand-new software that managed the layout itself is debatable, and nobody will write that software anyway because they won't have users that have SSDs that let the database manage the disk in full. Maybe it's not relevant to databases, but in my experience everything written with SSDs in mind has been horrifying. Compare two machines with nice NVMe drives running Windows 10/11 and Windows 7. Your user experience will be virtually identical. Swap the SSDs out for hard drives. The Windows 7 machine will get slower and have the many split-second delays we all remember from back in the day. The Windows 11 machine, however, will completely shit the bed. Massive multi-second delays crop up trying to do the most simple tasks. So far developers, instead of taking advantage of SSDs, are just using them as a crutch.
- dingledork69 3y ago
  Many companies refuse to test their software on low-end hardware, because effort. I've seen testers test software, get annoyed at how slow it was, and instead of letting that be a test result they just switched to a faster machine.

JoeAltmaier 3y ago

Deeper than that! Such fundamentals as 'the stack is accessible by code' goes back to Fortran. C doesn't need that. The call stack and the 'display' stack could be different things and no C programmer need care. This is the root of attacks that rewrite the return address of a kernel call. If the return address were managed/protected outside normal data operation this would not exist.

pklausler 3y ago
Could you explain this in more detail, please? Fortran standards didn't support recursion until Fortran '90 and it wasn't easy to get stack allocation in F'77 compilers from vendors until the mid-80's or so, both long after Algol-like languages had them.
- rtomanek 3y ago
  Wondering if they meant Forth rather than Fortran.
  - int_19h 3y ago
    It's even less true for Forth, given that it has separate data and return address stacks, and neither is addressable. There is some dedicated Forth hardware that relies on this fact to separate the stacks physically in hardware and e.g. use SRAM for them.
- JoeAltmaier 3y ago
  Fortran programmers abused the stack in astonishing ways. They used to calculate offsets on the stack to variables in the previous frame you already returned from. The details of stack layout were coded into important applications. Intel designers tried to do better, but the Fortran people pushed back, hard.

paulmd 3y ago

Probably the biggest ground-up rethink of SSDs that I've seen is the Samsung SSDs with a key-value store mode. Like, think about it, a filesystem is really a database, right? Copy-on-write even makes the "transactionality" explicit. And a lot of high-performance databases will go farther and skip the filesystem and treat the device as block storage... which it is. The filesystem is a leaky abstraction with filesystem blocks and flash pages and flash block erasure, etc. Well, what if the SSD was just an object store? In that model you slice away a bunch of layers of abstraction and just let the SSD worry about all that. SSD says it's committed? Alright then, guess it is. Obviously you are very much at the mercy of the SSD to implement ACID correctly however...

r1ch 3y ago
Optane was also a contender for the biggest fundamental shift - byte addressable persistent memory with insane endurance is simply in a different class to every other SSD technology out there. No need for a FTL. No need for a DRAM / SLC cache. Unfortunately no software really took advantage of it, OSes still provisioned it as 512/4096 byte sectors, etc. so in standard benchmarks it never really looked that compelling over a regular NVME drive. But if the access patterns align, nothing can come close. Truly a technology ahead of its time.
- MichaelZuo 3y ago
  It always made me surprised that Intel didn't market it better, such as forking linux and writing some custom additions that could allow the Optane drives to demonstrate real world 10x improvements.
  - paulmd 3y ago
    Intel already has Clear Linux actually. I don't think there's really a ton you can do at an OS level. ZFS L2ARC, system swap, etc, but a lot of the benefits would come from tuning DB configs/etc to suit the new hardware. If it's a fast SSD... ok are you the DBA? Similarly, PDIMM is really best utilized by a ground-up rethink of applications operating in a persistent context (think of like, javacard multicore 1TB or whatever). If you treat it as slow RAM it's gonna be slow RAM. The point would be building systems and applications that exploit the "writing the memory is now writing the disk" idiom. The ideal ecosytem for PDIMM isn't Linux at all, it's JVM, or LISP/Haskell. Or android I suppose lol.

wtallis 3y ago

Typical SSDs all assume your IO will be in 4kB-aligned chunks even though the storage is denominated in 512-byte sectors for compatibility reasons. So we have managed to move past the legacy of early hard drives to some degree, and are now being held back by assumptions that derive more from x86 page sizes.

throwawaylinux 3y ago

> I always worry that hardware "locks in" software. SSDs showed up after everyone wrote their databases to be optimal on spinning rust, so SSDs were built to look at the flow of requests, assume that the application was written for spinning rust, and optimize the data layout accordingly. It's not really that so much as contiguous or nearby access is faster on NAND, just like it's faster on hard disks, so software optimized layout and access patterns can look similar for both. > CPUs are similar. People started writing programs in C, so CPUs started optimizing for the outputs of C compilers. This didn't start at a one-way street. Actually CPUs were around first, so the first C compiler optimized for the CPU it generated code for. And from that point onward, C compilers optimize for the CPU. > If someone were to invent CPUs and compilers today, the list of optimizations would probably be different, and the performance characteristics of real-world software would probably be different. (It's not just C; people wanted virtual address spaces, and that was slow in software, so now there is a TLB, etc.) Unlikely. At the periphery yes, but there are fundamentally difficult things for CPUs and compilers to do which shape the solutions. Before somebody says "those fundamental difficulties might be different if we invented things differently" - the story of CPUs and of compiler optimization is about inventing ways to make those fundamental difficulties less difficult. There wasn't one day somebody invented the CPU and that was that, millions of people around the world have worked countless hours inventing and improving parts of CPUs and compilers for the past 70 years or so. There is inertia, but new ideas that are good enough can catch on even if it means entirely new models and ecosystems have to be invented. That's how we got multiprocessors, clusters, SIMD, GPUs.

jrockway 3y ago
> It's not really that so much as contiguous or nearby access is faster on NAND, just like it's faster on hard disks, so software optimized layout and access patterns can look similar for both. I worry about the pathological cases. Imagine you have an append-only log, and you write and fsync() one byte at a time. Each time you write a byte, the entire flash block (are they still 4KB these days?) has to be erased. So you end up chewing through 4000 durability cycles on your SSD, whereas if you had waited to write an exact 4KB block, then you'd use only 1. A hard drive is fine with this access pattern, though you'd probably be doing a lot of seeking to update fs metadata and it would be so slow that you'd come up with some other way. So maybe this pathology only exists in my mind.

sebazzz 3y ago

Didn't or do still some CPUs have instructions that can aid the JVM?

saagarjha 3y ago
Jazelle is generally deprecated.
- bzzzt 3y ago
  Only since 2005 ;)
  - saagarjha 3y ago
    Sadly I’ve never gotten my hands on Jazelle hardware :(
geraldhh 3y ago
"aid" is very broad, so i'd say "yes" but recently there was an article on hn that talked about an arm-instruction for some js stuff.

yuhong 3y ago

[dead]

causi 3y ago

Whether or not this is as good as brand-new software that managed the layout itself is debatable, and nobody will write that software anyway because they won't have users that have SSDs that let the database manage the disk in full. Maybe it's not relevant to databases, but in my experience everything written with SSDs in mind has been horrifying. Compare two machines with nice NVMe drives running Windows 10/11 and Windows 7. Your user experience will be virtually identical. Swap the SSDs out for hard drives. The Windows 7 machine will get slower and have the many split-second delays we all remember from back in the day. The Windows 11 machine, however, will completely shit the bed. Massive multi-second delays crop up trying to do the most simple tasks. So far developers, instead of taking advantage of SSDs, are just using them as a crutch.

dingledork69 3y ago
Many companies refuse to test their software on low-end hardware, because effort. I've seen testers test software, get annoyed at how slow it was, and instead of letting that be a test result they just switched to a faster machine.