[PATCH] D46735: [Test-Suite] Added Box Blur And Sobel Edge Detection

[Pankaj via Phabricator via llvm-commits]

proton added a comment.

In https://reviews.llvm.org/D46735#1095482, @MatzeB wrote:

> Are you writing these from scratch? If so, I'd like to make some suggestions:
>
> - Please aim for a runtime for 0.5-1 second on typical hardware. Shorter benchmarks tend to be hard to time correctly, running longer doesn't increase precision in our experience.


But the fraction of noise will be more for shorter runtimes. A longer runtime will help us when we to see the performance improvement after applying optimization.

> - I'd go for "MultiSource" benchmarks, even if they end up being a single source file; Producing multiple executables out of a single directory of source files is more complicated than it seems.
> - Did you check the amount of time spent on initializing and printing the image compared to the main operation of the benchmark?

No, Do we need to submit the time values also when we add a new benchmark/kernel?
About 8% of total time that program takes was spent in the sobel_edge_detection function.

In https://reviews.llvm.org/D46735#1096128, @jdoerfert wrote:

> In https://reviews.llvm.org/D46735#1096084, @Meinersbur wrote:
>
> > Some context: Pankaj is a GSoC student on a project to add more Polly-optimizable benchmarks. Currently, only SingleSource/Benchmarks/Polybench is really optimizable, most other benchmarks contain some kind of pre-optimization that makes it difficult for Polly to preserve semantics, even if the algorithm itself is 100% optimizable.
>
>
> First, let me keep the record straight:
>
> - Only SingleSource/Benchmarks/Polybench profits from the (mostly tiling) transformations applied by Polly.
> - There are various reasons why other benchmarks are "not optimizable" by Polly but only a fraction is caused by manual "pre-optimizations" (except the input language choice obviously).
> - Adding simple "Polly-optimizable" benchmarks is all good and well (as it makes for nicer evaluation sections in future papers...), but I would argue it is much more interesting to investigate if the existing benchmarks could be optimized and why they currently are not.
>
>   Regarding these (and other new) benchmarks:
> - Please describe why/how the codes differ from existing ones we have (e.g., Halide/blur). Polybench already contains various kernels including many almost identical ones.


This blur is similar to the blur in Halide/blur. I didn't know that there was blur already in test-suite. I will be careful next time.

> - Please describe why/how the magic constants (aka sizes) are chosen. "#define windows 10" is not necessarily helpful.

I chose the window size randomly. I wanted more computations so that program runs for more than 2 secs as small runtime have more fraction of noise in time values (due to scheduler/CPU physical condition) than a larger one. A smaller window (3 is generally taken) will also work.

> - I fail to see how Polly is going to optimize this code (in a way that is general enough for real codes). So my question is: Did you choose a linked data structure on purpose or do you actually want to have a multi-dimensional array?

I wanted a matrix to store Image so I used a 2D array here.

> Finally, regarding the actual code, I would run clang format and remove these blocks of empty lines.

I will make sure that I use clang-format from now before uploading any code here.


Repository:
  rT test-suite

https://reviews.llvm.org/D46735