Daniel, Nadav, Hal, So, after some painstakingly boring re-formatting, I've split the 24 kernels into 24 files (and left a horrible header file with code in it, which I'll clean up later). Since we're taking times in the benchmark tool, and we're trying to assert the quality of the FP approximation by the vectorization, I'll try to come up with a reasonable watermark for each test. Maybe adding the values of all elements in the result vector, or something, and printing that value, using FP_TOLERANCE to detect errors in the vectorized code. Does this seem sensible? cheers, --renato
Seems fairly reasonable to me. I don't know what size of arrays you are dealing with, if they are reasonably small it is probably also fine to just output each element in the result. It's fine to start by just setting FP_TOLERANCE to a small value and if it breaks in the future because of an actual precision change we can tweak it. Thanks for the reformatting, its great to see new benchmarks getting added! - Daniel On Fri, Nov 16, 2012 at 12:28 PM, Renato Golin <rengolin at systemcall.org>wrote:> Daniel, Nadav, Hal, > > So, after some painstakingly boring re-formatting, I've split the 24 > kernels into 24 files (and left a horrible header file with code in > it, which I'll clean up later). > > Since we're taking times in the benchmark tool, and we're trying to > assert the quality of the FP approximation by the vectorization, I'll > try to come up with a reasonable watermark for each test. Maybe adding > the values of all elements in the result vector, or something, and > printing that value, using FP_TOLERANCE to detect errors in the > vectorized code. > > Does this seem sensible? > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121116/6e9bc5d9/attachment.html>
On 16 November 2012 21:24, Daniel Dunbar <daniel at zuster.org> wrote:> I don't know what size of arrays you are dealing with, if they are > reasonably small it is probably also fine to just output each element in the > result.It's from 64 to more than 1000. I'll sum the elements up and then people can change later for a better heuristics on a case by case basis. -- cheers, --renato http://systemcall.org/
Hi Renato! Thanks for working on this! It's really important to have more array-ish benchmarks. On Nov 16, 2012, at 12:28 PM, Renato Golin <rengolin at systemcall.org> wrote:> Daniel, Nadav, Hal, > > So, after some painstakingly boring re-formatting, I've split the 24 > kernels into 24 files (and left a horrible header file with code in > it, which I'll clean up later). > > Since we're taking times in the benchmark tool, and we're trying to > assert the quality of the FP approximation by the vectorization, I'll > try to come up with a reasonable watermark for each test. Maybe adding > the values of all elements in the result vector, or something, and > printing that value, using FP_TOLERANCE to detect errors in the > vectorized code. >Once Michael Ilseman commits the fast math patch we will be able to implement floating point reductions. Thanks, Nadav
On 16 November 2012 21:43, Nadav Rotem <nrotem at apple.com> wrote:> Once Michael Ilseman commits the fast math patch we will be able to implement floating point reductions.That's great news! Attached is the whole benchmark, divided into 24 kernels and running on LNT with FP comparison and timings. Unpack the file onto SingleSource/Benchmarks and change the Makefile to add LivermoreLoops to the tests. Run the LNT tests with --only-test SingleSource/Benchmarks/LivermoreLoops to see it pass. The heuristics are dumb accumulations of the array values, just to get a value that will change considerably with small FP errors, so we can easily test and adjust how much FP error is being incurred by fast-math. If no one objects, I'll commit to the test-suite. -- cheers, --renato http://systemcall.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: LivermoreLoops.tar.gz Type: application/x-gzip Size: 12160 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121116/a3f0c736/attachment.bin>