"Ulrich Drepper [the gnu libc project leader] recently approached us [LWN] asking if we would be interested in publishing a lengthy document he had written on how memory and software interact. Memory usage is often the determining factor in how software performs, but good information on how to avoid memory bottlenecks is hard to find. This article is the first in a serie of articles (the original has over 100 pages) that will get published on LWN weekly. Once the entire series is out, Ulrich will be releasing the full text."
To read all comments associated with this story, please click here.
Member since:2006-01-19
Definitely a great read!
I would like to mention, that assembler-coding makes you think about memory latencies and throughputs and processor cycles quite a lot.
I did not have much time assemblying lately, but learning it once provided me some insight about the difference between code performance and algorithm performance. As a rule of thumb: Try to get the best algorithm in c or f90 working before even considering reprogramming the time-critical subroutines in assembler.
Member since:2006-10-08
"As a rule of thumb: Try to get the best algorithm in c or f90 working before even considering reprogramming the time-critical subroutines in assembler."
Seems, thatt this rule is not very well known, because we have too much ressources these days: too fast CPUs, too much RAM, too big hard disks... who cares about efficient programming anyway? :-)
I really enjoyed the article. Very interesting content, presented in a educational valuable way. Worth having a printed copy on the system shelf.
Member since:2006-01-02
Or you could separate the serious .NET programmer and the hobbyist one. Using Java or .NET doesn't mean that you have no control over the underlying system. Memory still is accessed in the cached manner with the same latencies as in native code. If you know how to structure your data (prefer contiguous allocation over spread data, try to keep data that's used together close in memory), you get the same benefits of this knowledge in a managed language as in an unmanaged one.
A GCed language has one major advantage though: if you're using a mark-and-sweep collector like in the CLR, the runtime will automatically compact small items together upon collection, so you get better cache locality between items automatically without writing your own custom allocator in C or C++.
Snarky comments against managed runtimes do not demonstrate that you are elite. Just like with any language system, there are skilled tweakers who spend time squeezing performance out of .NET and there are people who just want to solve a one-off problem or play around on the weekends.
Member since:
2006-01-25
I can't wait for the rest of the paper to be published. This was a very interesting read. Memory management is essential to any good programmer, it's what seperates the hard-core coder from the weekend enthusiasts who slap stuff together in .NET and call themselves a "programmer".