logoalt Hacker News

forrestthewoodsyesterday at 11:13 PM3 repliesview on HN

Here’s an older blog post of mine on roughly the same topic:

https://www.forrestthewoods.com/blog/memory-bandwidth-napkin...

I’m not sure I agree with the data presentation format. “time per element” doesn’t seem like the right metric.


Replies

klanktoday at 1:23 AM

What are your qualms with time per element? I liked it as a metric because it kept the total deviation of results to less than 32 across the entire result set.

Using something like the overall run length would have such large variations making only the shape of the graph particularly useful (to me) less so much the values themselves.

If I was showing a chart like this to "leadership" I'd show with the overall run length. As I'd care more about them realizing the "real world" impact rather than the per unit impact. But this is written for engineers, so I'd expect it to also be focused on per unit impacts for a blog like this.

However, having said all that, I'd love to hear what your reservations are using it as a metric.

show 1 reply
alain94040today at 1:39 AM

From your blog post:

> Random access from the cache is remarkably quick. It's comparable to sequential RAM performance

That's actually expected once you think about it, it's a natural consequence of prefetching.

show 2 replies
petermcneeleytoday at 3:23 AM

Whats most misleading is the data for the smaller sizes (1k)