Messages in this thread | | | Date | Thu, 12 Jun 2014 16:17:10 -0400 | From | Theodore Ts'o <> | Subject | Re: random: Benchamrking fast_mix2 |
| |
One of the reasons for the timing instability is because of the usleep() calls. This allows some other process to schedule, and thus disrupts the I-cache and uop caches. With the usleep() calls:
i7-4900MQ# schedtool -R -p 1 -e /tmp/fast_mix2_49 fast_mix: 213 fast_mix2: 280 fast_mix: 336 fast_mix2: 356 fast_mix: 174 fast_mix2: 392 fast_mix: 202 fast_mix2: 403 fast_mix: 152 fast_mix2: 280 fast_mix: 212 fast_mix2: 403 fast_mix: 213 fast_mix2: 403 fast_mix: 213 fast_mix2: 392 fast_mix: 202 fast_mix2: 403 fast_mix: 191 fast_mix2: 392
... and without the usleep calls:
i7-4900MQ# schedtool -R -p 1 -e /tmp/fast_mix2_49 fast_mix: 146 fast_mix2: 347 fast_mix: 157 fast_mix2: 90 fast_mix: 78 fast_mix2: 90 fast_mix: 78 fast_mix2: 89 fast_mix: 78 fast_mix2: 90 fast_mix: 78 fast_mix2: 90 fast_mix: 90 fast_mix2: 90 fast_mix: 79 fast_mix2: 90 fast_mix: 90 fast_mix2: 89 fast_mix: 79 fast_mix2: 90
I had originally added the usleep calls() in my test infrastructure to more accurately disable the uop cache effects, since we are going to be called from an interrupt handler, not in a loop. But anyway, this is one of the reasons for the differences that you were seeing with your benchmarking framework and mine, and why micro-benchmarking can be so hard to get right. :-)
(BTW, this is your original mixer; I haven't tried playing with your modified Skein-like core round yet.)
- Ted
| |