c - Cache memories and memory addresses -

i have 1 class´s exercise have subroutines , check cache misses, atachment:

i have create 2 subroutines s1 capacity of l1 cache 32kb , b1 line witdh 64 bytes.

subroutine a: increment bytes of memory buffer containing 2*s1 bytes  in order of increasing memory addresses;  subroutine b: increment each b1-th byte of memory buffer containing 2*s1  bytes in order of increasing memory addresses; 

for subroutine think have do:

char buffer[2*s1];   printf... buffer++; printf... 

both printf show:

buffer[0]= 0x7fff36769fe0 buffer[1]= 0x7fff36769fe1  buffer[0]= 0x7fff36769fe1 buffer[1]= 0x7fff36769fe2 

all bytes increassed,so, think correct,and subroutine b, have no idea...so, have subroutine b.

it nice if can me.

thank you!

these exercises makes sense lesson in optimisation. unfortunately, they're not quite hitting figurative head of nail.

programmers waste enormous amounts of time thinking about, or worrying about, speed of noncritical parts of programs, , these attempts @ efficiency have strong negative impact when debugging , maintenance considered. should forget small efficiencies, 97% of time: premature optimization root of evil. yet should not pass our opportunities in critical 3%.

that's famous quote, along-side context, perhaps reputable teacher can agree upon in field: donald knuth. following on exercise, professor introduce profilers walking through profiling unoptimised code.

what can hope improve if apply manual optimisations though compiler performs none, , later enable compilers automatic optimisations? perhaps compiler might automatically perform same optimisations (or better optimisations) manually perform, in miniscule fraction of time.

there's marketing/planning strategy consider behind figures in quote. in commercial world or hobbyist, have spent 97% of time front developing and testing program solves actual problem. notice emphasis on actual problem. won't writing , testing programs purpose of observing cache behaviours. you'll writing , testing programs solve real life problems.

once you've written , tested entire program thoroughly you'll know whether or not feels fast enough (e.g. you'll told clients/employers optimise it). if feels fast enough, won't optimise it, if there cache misses everywhere; won't know there cache misses. if feels slow, however, you'll want use profiler on fully optimised code determine significant bottleneck is, , spend 3% of time on bottleneck...

it possible program optimistically, that's not exercise in observation these exercises; it's exercise in planning , factoring. 1 guideline avoid repeating yourself, i've done code below. determining common behaviours between 2 exercises (e.g. both loop low indexes high indexes, incrementing each element 1) i've reduced 2 loops one, , avoided repeating myself @ same time. factor programs avoid repetition possible , code smaller, resulting in less testing, maintenance , of course less repeated keystrokes. most of optimisation optimisation of our time, not of computers time! happens optimising computer time making our code smaller.

void increment_every(char *buffer, size_t multiple, size_t maximum) {     while (maximum > multiple) {         buffer[0]++;         buffer  += multiple;         maximum -= multiple;     } } 

you should able solve both of these problems in terms of function. example:

#define s1 32768 /* 32kb */ #define b1 64    /* 64 b */  int main(void) {     char buffer[2 * s1] = { 0 };      increment_every(buffer, 1, sizeof buffer);  // subroutine      if (b1 < s1) {                              // subroutine b         increment_every(buffer + b1, b1, sizeof buffer - b1);     } } 

this assuming s1 , b1 fixed values don't come file or interactive device. such assumption causes compiler quite aggressive optimisation. in fact, program optimised int main(void) { } because there's no observable behaviour; there's no input or output files or interactive devices anywhere in program! hopefully, now, you'll see few true lessons behind next lesson:

• write code optimally rather write optimal code. e.g. avoid repeating yourself.
• profile code when feels slow. e.g. optimise after you've written , tested entire program.