4 ms·

this article is ridiculous. He makes blanket claims based on the performance of a very specialized application. For many / most applications, memory is so cheap

this article is ridiculous. He makes blanket claims based on the performance of a very specialized application. For many / most applications, memory is so cheap that you CAN effectively ignore VM. Where some thought about the relative latency of memory is useful though is in parallel applications on NUMA hardware.

Qz 16y ago
That depends whether, when you're talking about 'most applications', you mean most by sheer number, or most by processing time used. Because yes, there are a zillion tiny applications that don't care about VM space. But the ones that do are used far more often (running nonstop on servers, etc) than that random iBoobs app on your iPhone.
- slioslat 16y ago
  Even for most applications "running non-stop on servers", VM is almost moot these days. For anything computational, swap is the kiss of death. For many applications where the working set is larger than available memory, the work is typically done inside a DBMS which usually has it's own systems for managing paging. Algos in DBMS are certainly aware of non-uniform access time: http://en.wikipedia.org/wiki/B-tree http://en.wikipedia.org/wiki/B-tree
stcredzero 16y ago
this article is great. He gives a specific example based on real-world performance, showing that you can't always rely on theory assuming a general case. For many intensive applications, memory is so precious, you CAN'T effectively ignore VM. Some thought about the relative latency of memory is useful in more than just parallel applications on NUMA hardware. (Git and Mercurial are designed with an eye towards optimizations based on disk latencies. Python is optimized with regard to CPU cache. We're back to "Abstractions Leak.")
- acqq 16y ago
  The article is really poorly written. The specific example is very specific, the claims that "nobody else gets it" are in fact unsubstantiated. All the effects he mentions are very known among right professionals. And the title text is not about "relative latency" you mention but about the cost of paging, once something gets paged out.
  - stcredzero 16y ago
    The specific example is very specific Sounds good to me. the claims that "nobody else gets it" are in fact unsubstantiated I'm pretty sure that the entire shop at my last consulting job would all claim it was news to them. Most people don't have to deal with issues like the ones discussed in the article, so it's perfectly understandable that it would be news to them. I don't have to deal with such issues on a daily basis, though I think I would have been able to do the same analysis if I had his job. And the title text is not about "relative latency" you mention but about the cost of paging I didn't know "relative" was so associated with memory and paging that you could jump to a conclusion about my specific meaning. (And actually, I meant to be quite general.) AFAIK, the cost of paging has something to do with the latency of resident memory vs. latency memory that was paged out.
    - Confusion 16y ago
      I'm pretty sure that the entire shop at my last consulting job would all claim it was news to them On the other hand, I'm pretty sure that the same doesn't hold for the actual target audience of this article.
  - mfukar 16y ago
    I'm willing to forgive his "poor" writing on account that he's right - most CS students and graduates don't have any clue about cache effects on algorithm implementations, and that's just wrong.
- _delirium 16y ago
  One problem is that the article seems to incorrectly assume that "theory" always ignores memory hierarchies. That was true in, say, 1975, but the past 20 years of algorithms theory pays a lot of attention to memory hierarchies. You can even get all sorts of off-the-shelf algorithms designed to perform well on typical modern memory configurations. I mean, he's basically arguing that CS hasn't revisited heaps since 1961, and hasn't noticed that things like caches or VM pressure might change what the optimal algorithm looks like. But that's of course not the case.

Qz 16y ago

That depends whether, when you're talking about 'most applications', you mean most by sheer number, or most by processing time used. Because yes, there are a zillion tiny applications that don't care about VM space. But the ones that do are used far more often (running nonstop on servers, etc) than that random iBoobs app on your iPhone.

slioslat 16y ago
Even for most applications "running non-stop on servers", VM is almost moot these days. For anything computational, swap is the kiss of death. For many applications where the working set is larger than available memory, the work is typically done inside a DBMS which usually has it's own systems for managing paging. Algos in DBMS are certainly aware of non-uniform access time: http://en.wikipedia.org/wiki/B-tree http://en.wikipedia.org/wiki/B-tree

stcredzero 16y ago

this article is great. He gives a specific example based on real-world performance, showing that you can't always rely on theory assuming a general case. For many intensive applications, memory is so precious, you CAN'T effectively ignore VM. Some thought about the relative latency of memory is useful in more than just parallel applications on NUMA hardware. (Git and Mercurial are designed with an eye towards optimizations based on disk latencies. Python is optimized with regard to CPU cache. We're back to "Abstractions Leak.")

acqq 16y ago
The article is really poorly written. The specific example is very specific, the claims that "nobody else gets it" are in fact unsubstantiated. All the effects he mentions are very known among right professionals. And the title text is not about "relative latency" you mention but about the cost of paging, once something gets paged out.
- stcredzero 16y ago
  The specific example is very specific Sounds good to me. the claims that "nobody else gets it" are in fact unsubstantiated I'm pretty sure that the entire shop at my last consulting job would all claim it was news to them. Most people don't have to deal with issues like the ones discussed in the article, so it's perfectly understandable that it would be news to them. I don't have to deal with such issues on a daily basis, though I think I would have been able to do the same analysis if I had his job. And the title text is not about "relative latency" you mention but about the cost of paging I didn't know "relative" was so associated with memory and paging that you could jump to a conclusion about my specific meaning. (And actually, I meant to be quite general.) AFAIK, the cost of paging has something to do with the latency of resident memory vs. latency memory that was paged out.
  - Confusion 16y ago
    I'm pretty sure that the entire shop at my last consulting job would all claim it was news to them On the other hand, I'm pretty sure that the same doesn't hold for the actual target audience of this article.
- mfukar 16y ago
  I'm willing to forgive his "poor" writing on account that he's right - most CS students and graduates don't have any clue about cache effects on algorithm implementations, and that's just wrong.
_delirium 16y ago
One problem is that the article seems to incorrectly assume that "theory" always ignores memory hierarchies. That was true in, say, 1975, but the past 20 years of algorithms theory pays a lot of attention to memory hierarchies. You can even get all sorts of off-the-shelf algorithms designed to perform well on typical modern memory configurations. I mean, he's basically arguing that CS hasn't revisited heaps since 1961, and hasn't noticed that things like caches or VM pressure might change what the optimal algorithm looks like. But that's of course not the case.