Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

This continues the trend we see in processors, that in a post-Moore's law environment, rather than trying to push physical limits for performance improvements, we're branching out into hardware optimized for specific purposes. Very neat to see it on the storage side, and something I don't think anyone could fathom back in the spinning disk days.

View on HN

I think it's happening somewhat in the software space, where we pursue speed improvements by penetrating through sometimes literally decades of accumulated cruft layers to build something more modern. It is ironically harder precisely because it's easier; we've got a lot more software layers because it's so much easier to add another one. Wayland is probably one big example of it, but I often have this feeling in my Go code, too, where instead of a framework on top of a framework on top of a very framework-y core language like Python, we more-or-less just get on with it, both at the level of the code I type, and in the generated assembler as well. I imagine Rust programming feels much the same way when working with Rust-native libraries, I just don't have direct experience.

It's not all Electron apps out there.

Also, when I call something "accumulated cruft", it's not just vague "bloat" concerns I'm referring to; you have the problems of several layers of leaky abstractions, and those leaky abstractions may well date from an era of radically different hardware. It's true this can cause "bloat", but it causes other problems, too.

QUIC/Http3 could be another software example of this.

There is too much cruft in the TCP/IP + HTTP stacks, so the solution is to implement a new protocol on top of the lowest abstraction that can be practically used (IP+UDP) in user space; at least until kernels implement it.

I will delegate judging if this is a good idea to more knowledgeable parties though.

Isn't QUIC/HTTP3 the opposite? It's moving up the layers of abstraction, by moving something that would previously have been managed at layer 4 up to a higher layer.

Running everything that used to be done in the network layer up to the application layer and putting everything on top of HTTPS is the opposite of what the parent is advocating for.

If we consider it relative to HTTP1 just to heighten the contrast, it takes the layers of: TCP connection management and negotiation, plain text framing protocols, protocols too limited to deal with the greatly-increased use of or need for multiple streams at once, SSL layering its own negotiation in, rather hacky stories around websockets/SSE (which are usually used as text protocols framed inside of text protocols framed inside of text protocols... not really the best setup), and probably a couple of other things. All of these things were designed for a different era at the very least, and often designed independent of each other. HTTP3 slices through the whole thing and creates nearly an entire protocol stack for its needs, using only the minimum it needs from IP to work over the internet at all.

My software engineering instincts tell me this is all a bad idea and those layers should be kept separate as they were, if indeed they weren't already intermingled more than they should be (e.g., SSL & SNI; "why should SSL have to know anything at all about how HTTP deals with host names?" say my instincts). However, I intellectually realize that my software engineering instincts are not calibrated for the size of the HTTP world, nor the amount of resources that can be thrown at this problem. It's a great example of slicing through many layers that make sense independently, but just never quite went together properly, to make something that's going to perform better without 30 years of mismatching layers stacked on top of each other.

(I'm not saying HTTP3 is perfect, only that it is a good example of someone at least trying to do what I was talking about.)

I guess it's kind of both.

It circumvents the established network and software stack and builds a new protocol on the lowest-level abstraction that can be used practically (IP + UDP) because everything else would require hardware and kernel support, which would take many years to manifest.

Nobody commercially perhaps, but I've been fathoming it for a while. I kept wondering when we would see a RAID controller with enough juice to run PostgreSQL directly. With a key-value store in existence maybe some more people will be looking into such things.

Sun Microsystems' motto was "the network is the computer" but over the last fifteen or more years there's been a steady trend in the opposite direction.

The computer is a network. I sometimes wish this would be embraced more thoroughly, not just in the way you mention, of offloading work to specialized processing units, but of building a network fabric inside the box. It's one of the things we never copied down from classical mainframe design.

>Sun Microsystems' motto was "the network is the computer"

Just a note, That trademarks now belongs to Cloudflare [1]

[1] https://blog.cloudflare.com/the-network-is-the-computer/

Well, for one of the world's largest CDN's I have to say this is pretty appropriate.

> Very neat to see it on the storage side, and something I don't think anyone could fathom back in the spinning disk days.

Seagate had a product called Kinetic that was an Ethernet-connected key-value spinning disk. We had a 1U box with a number of 4000GB drives in our lab for an evaluation.

It was interesting but we didn't find a use for it. Product is dead now as far as I know.

We're nowhere near ‘post-Moore’ in persistent storage, though. Although Dennard scaling for CPUs has faltered (if not Moore proper), storage is still getting faster and denser at the same time... it just does the speed upgrades in discrete jumps. SSDs were massively faster than HDDs, and when Optane DIMMs actually become available, those will be another huge factor faster than SSDs. (And if not Optane, then QuantX or MRAM or NRAM or ReRAM or...)

CISC is back with a vengeance!

Honestly, this is more like the revenge of the mainframes.

Having enough logic in all your storage and peripherals that the hardware itself presented a nice, directly usable API was the thing that differentiated mainframes in the era when minicomputer were cheaper and started getting faster cpus. (That and "no-one's ever gotten fired for buying IBM".)

This was my impression as well.

I've always wondered why we didn't have memory with lookup operations implemented in hardware.

I think some network chips have associative operations like this in hardware (find route matching ...), it would be interesting to have a generally available solution.

I would be surprised if caches and virtual memory TLBs weren't build based on associative memory. The thing with associative memory is that it's a simple logic in principle, but becomes a sprawling array of and gates when implemented in hardware. This takes it out of the competition for high density memory chips.

This is a sort of punctuated optimization that is natural in any technology.

When a fundamental technology is evolving rapidly, not much effort is put into optimization. It instead goes into keeping the momentum of evolving the fundamental technology.

When it hits a physical limitation, everyone scrambles to now optimize.

Until the next generation of fundamental tech shows up and evolves rapidly again.

Think about air travel and how every airline is now all about fuel efficiency.

A single new technology eg: a new battery chemistry that is say, 2x as energy dense as the best right, now comes along, electric air propulsion will become a major thing. And airlines will be scrambling to offer faster, quieter options that may not necessarily be the most efficient.

Reply on news.ycombinator.com