Feel the cache size: a definitive experiment
melikyan.blogspot.com
Feel the cache size: a definitive experiment
1–10 of 33 posts
Re: Feel the cache size: a definitive experiment
#2This is something that's been bothering me for the last decade (okay, more.). Every time I've articulated it in the past I've been dismissed, but it really is key to good performance.
iirc, the GNOME folks once did some benchmarking and found they could get huge speedups by trimming a few bytes here and there from the gnome libraries.
I hope more people take the time to consider the implications of code bloat. I'm not asking for hand written assembler, but just a little bit of thought here and there can produce huge improvements.
EDIT: This is also why ssd's are so exciting. Yes the're not perfect yet, but they promise to (all but) eliminate disk latency within the next few years.
Re: Feel the cache size: a definitive experiment
#3This article is not really about the memory cache hierarchy.
It's an excuse to show off the author's exciting new algorithm for computing the value of the integer "max": (func_table[max] - func_table[0]).
Re: Feel the cache size: a definitive experiment
#4This is something that's been bothering me for the last decade (okay, more.). Every time I've articulated it in the past I've been dismissed, but it really is key to good performance. iirc, the GNOME folks once did some benchmarking and found they could get huge speedups by trimming a few bytes here and there from the gnome libraries. I hope more people take the time to consider the implications of code bloat. I'm no…
Too true.
"We should forget about small efficiencies, say about 97% of the time" Donald Knuth
We often forget about the rest 3% too.
Re: Feel the cache size: a definitive experiment
#5if you want to know more on this topic
"What Every Programmer Should Know About Memory" - http://people.redhat.com/drepper/cpumemory.pdf
Re: Feel the cache size: a definitive experiment
#6if you want to know more on this topic "What Every Programmer Should Know About Memory" - http://people.redhat.com/drepper/cpumemory.pdf
Over the top, but fun:
Unix Systems for Modern Architectures
http://www.amazon.com/UNIX-Systems-Modern-Architectures-Mult...
Re: Feel the cache size: a definitive experiment
#7This is something that's been bothering me for the last decade (okay, more.). Every time I've articulated it in the past I've been dismissed, but it really is key to good performance. iirc, the GNOME folks once did some benchmarking and found they could get huge speedups by trimming a few bytes here and there from the gnome libraries. I hope more people take the time to consider the implications of code bloat. I'm no…
Too true. "We should forget about small efficiencies, say about 97% of the time" Donald Knuth We often forget about the rest 3% too.
It's a shame that profiling/performance/cache utilization analysis tools aren't nearly as common/standardized as the rest of a developer's toolbox.
Re: Feel the cache size: a definitive experiment
#8This article is not really about the memory cache hierarchy. It's an excuse to show off the author's exciting new algorithm for computing the value of the integer "max": (func_table[max] - func_table[0]).
[deleted]
Re: Feel the cache size: a definitive experiment
#9This article is not really about the memory cache hierarchy. It's an excuse to show off the author's exciting new algorithm for computing the value of the integer "max": (func_table[max] - func_table[0]).
Isn't it really calculating max * 11, since the functions pointed at by func_table[max] are 11 bytes long?
I'm not much of a C coder, is there a more idiomatic way to do this?