Hacker News Reader

Comment by cwyers | Hacker News Reader

Is... is the author judging the change in storage versus compute by comparing the size of disk drives to the... Ghz of processors involved?

> My IBM PS/2 Model 55SX desktop in 1990 had a 16Mhz CPU, 2MB of RAM and a 30MB hard drive. That’s roughly one Hz of processor power for every 1.87 bytes of hard drive space.

Yes, yes he is. I just... that seems like such an absurd comparison to be making.

View on HN

You know, the Big O notation is all about relating number of operations to input size. Ghz is, roughly, proportional to number of operations in a fixed time frame (let's not worry about memory bandwidth for a second), HDD size is proportional to input size, so this comparison makes sense.

See it this way: for an O(n) algorithm to continue being usable, GhZ/GB ratio needs to stay constant over time.

Except CPUs hit 3ghz back in 2002 and have, in terms of what most of us use, stayed there. The grown in CPU clock cycles has not kept pace with the improvements in CPU speed that have come from superscalar CPU designs and specialized instruction sets. On the timeframes being discussed, it's a comparison that will underrate how much CPUs have changed since then, even on a per-core basis.

We've started doubling, doubling and doubling again the cores and memory bandwidth though, so our dataset size to cpu*ghz would be still comparable. The only thing this doesn't take into account is IPC.

> Fast forward almost 30 years to 2019. A typical commercial cloud VM “core” is a hyperthread of a 2.5Ghz to 3.5Ghz (turbo) physical processor core with 2GB-14GB RAM per core and effectively infinite storage via cloud storage, though local disk might be limited to 64TB or less. Using the same CPU-to-disk ratio as 1990, that 3.5Ghz turbo hyperthread would be paired to 6.6GB of disk (actually, 3.3GB of disk, taking into account the fact that a hyperthread is really only half of a physical core).

The author "controls" for the increase in cores, though.

This really is a pretty simple point. A modern x86-64 CPU is not just a 386SX running at a higher clock speed. You cannot compare CPUs across decades only on clock speeds. Nothing works like that.

>Nothing works like that.

Sure. Thrown in another order of magnitude in to account for that. Heck, throw in two! Why not say that a single 4GhZ CPU core today has a processing power of 100 4GhZ CPU's of yore.

You're still orders of magnitude behind the growth of disk space.

And that only makes sense for very simple and fast algorithms. Anything super-linear is still very hard with the amounts of data we are able to collect. Which is the author's point.

Independent of the usage within the article, I make this kind comparison pretty often when thinking about how to "saturate" a device; if I am building a specialized system to perform a task, I want the capability of the system in terms of Hz per byte of storage to roughly match that of the problem being performed. (This is typically measured against storage bandwidth, not storage total, since you usually have the assumption that you're bringing data in from a larger storage pool that is essentially "infinite" in comparison (cache <---> main memory, or main memory <---> disk, or disk <----> distant server))

If your Hz/byte ratio is too high. you're wasting compute capability. If too low, you're wasting memory/memory bandwidth.

That actually is a very useful ratio to look at. Essentially says “in a compute-bound data processing algorithm, how long would it take to process all the data you can store?”

Reply on news.ycombinator.com