Apply D49339 befor this patch. as that contains some utilities functions required by this.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
MicroBenchmarks/ImageProcessing/Dither/floydDitherKernel.cpp | ||
---|---|---|
9 ↗ | (On Diff #156126) | WhiteSpace |
10–11 ↗ | (On Diff #156126) | Commented Code |
MicroBenchmarks/ImageProcessing/Dither/orderedDitherKernel.cpp | ||
17 ↗ | (On Diff #156126) | Commented Code |
52 ↗ | (On Diff #156126) | You could remove the M==2, M==3 and M==8 conditions since M is defined as 4? That or you could pass another argument to set M and have a test for each size image with each value of M. |
MicroBenchmarks/ImageProcessing/Dither/main.cpp | ||
---|---|---|
36 ↗ | (On Diff #157760) | Does this work? It dereferences the pointer returned by malloc (which should be the uninitialized first bytes of the memory allocated be malloc) and then casts it to a pointer. Id' expect this to result in a segfault. |
MicroBenchmarks/ImageProcessing/Dither/orderedDitherKernel.c | ||
13 ↗ | (On Diff #157760) | Do you need m to by a variable? It is only passed the constant 4 in this benchmark. The code would be more optimizable if the compiler knew the constant. Alternatively, you could run the kernel several times with different values of m. |
MicroBenchmarks/ImageProcessing/Dither/main.cpp | ||
---|---|---|
36 ↗ | (On Diff #157760) | Yes, It works properly because the pointer returned by malloc is casted as int (*) [][]. So to access the array we have to first dereference the pointer (use it as (*inputImage)[i][j]). |
Changes: update m along with image size when called with the benchmark library. For verification, only m=4 is used.
test-suite/trunk/MicroBenchmarks/ImageProcessing/Dither/main.cpp | ||
---|---|---|
144–154 | I just noticed an odd effect here. A benchmark run now gives us 12 results for the same function running. test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/512/3 I just had a change that was mostly improving things but happened to slightly regress this benchmark. Unfortunately this effect is now multiplied by 12 so this benchmark has a far bigger weight than others... |
test-suite/trunk/MicroBenchmarks/ImageProcessing/Dither/main.cpp | ||
---|---|---|
144–154 | Do you suggest to reduce the number of variants? |
test-suite/trunk/MicroBenchmarks/ImageProcessing/Dither/main.cpp | ||
---|---|---|
144–154 | We can reduce the number of runs here but I think instead of hardcoding it here (like it is now), we can pass it as an argument from cmake file. b->Args({i, 2}); b->Args({i, 3}); b->Args({i, 4}); b->Args({i, 8}); to b->Args({i, 2}); b->Args({i, 8}); See Line: 107 |
I just noticed an odd effect here. A benchmark run now gives us 12 results for the same function running.
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/512/3
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/512/2
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/256/3
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/256/2
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/128/2
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/128/3
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/256/4
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/512/4
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/128/4
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/512/8
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/128/8
test-suite :: MicroBenchmarks/ImageProcessing/Dither/Dither.test:BENCHMARK_ORDERED_DITHER/256/8
I just had a change that was mostly improving things but happened to slightly regress this benchmark. Unfortunately this effect is now multiplied by 12 so this benchmark has a far bigger weight than others...