llvm dev - Sep 2016 - Benchmarks for LLVM-generated Binaries

> On Sep 14, 2016, at 12:50 AM, Dean Michael Berris via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> I'm working on this now, and I had a few more questions below for
Renato and the list in general. Please see inline below.
> 
>> On 2 Sep 2016, at 11:27, Dean Michael Berris <dean.berris at
gmail.com> wrote:
>> 
>>> On 2 Sep 2016, at 11:19, Renato Golin <renato.golin at
linaro.org> wrote:
>>> 
>>> On 2 September 2016 at 02:13, Dean Michael Berris <dean.berris
at gmail.com> wrote:
>>>> I think it should be possible to have a snapshot of it
included. I don't know what the licensing implications are (I'm not a
lawyer, but I know someone who is -- paging Danny Berlin).
>>> 
>>> The test-suite has a very large number of licenses (compared to
LLVM),
>>> so licensing should be less of a problem there. Though Dan can help
>>> more than I can. :)
>>> 
>> 
>> Cool, let's wait for what Danny thinks on the patch I'll be
preparing. :)
>> 
>>> 
>>>> I'm not as concerned about falling behind on versions there
though mostly because it should be trivial to update it if we need it. Though
like you, I agree this isn't the best way of doing it. :)
>>> 
>>> If we start using it more (maybe we should, at least for the
>>> benchmarks, I've been long wanting to do something decent
there), then
>>> we'd need to add a proper update procedure.
>>> 
>>> I'm fine with some checkout if it's a stable release, not
trunk, as it
>>> would make things a lot easier to update later (patch releases, new
>>> releases, etc).
>>> 
>> 
>> SGTM.
>> 
> 
> Is there a preference on where to place the library? I had a look at
{SingleSource/MultiSource}/Benchmarks/ and I didn't find a common location
for libraries used. I'm tempted to create a top-level "libs"
directory that will host common libraries but I'm also fine with just having
the benchmark library living alongside the XRay benchmarks.
> 
> So two options here:
> 
> 1) libs/googlebenchmark/
> 2) MultiSource/Benchmarks/XRay/googlebench/
This is something that may be used (or is intended) to be used by others in the
future, the first option makes it easier (or encouraging at least).

—
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160914/02cd0908/attachment.html>

On 14 September 2016 at 16:23, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> This is something that may be used (or is intended) to be used by others in
> the future, the first option makes it easier (or encouraging at least).
I agree.

cheers,
--renato

On Wed, Sep 14, 2016 at 8:23 AM Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> On Sep 14, 2016, at 12:50 AM, Dean Michael Berris via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I'm working on this now, and I had a few more questions below for
Renato
> and the list in general. Please see inline below.
>
> On 2 Sep 2016, at 11:27, Dean Michael Berris <dean.berris at
gmail.com>
> wrote:
>
> On 2 Sep 2016, at 11:19, Renato Golin <renato.golin at linaro.org>
wrote:
>
> On 2 September 2016 at 02:13, Dean Michael Berris <dean.berris at
gmail.com>
> wrote:
>
> I think it should be possible to have a snapshot of it included. I
don't
> know what the licensing implications are (I'm not a lawyer, but I know
> someone who is -- paging Danny Berlin).
>
>
> The test-suite has a very large number of licenses (compared to LLVM),
> so licensing should be less of a problem there. Though Dan can help
> more than I can. :)
>
>
> Cool, let's wait for what Danny thinks on the patch I'll be
preparing. :)
>
>
> I'm not as concerned about falling behind on versions there though
mostly
> because it should be trivial to update it if we need it. Though like you, I
> agree this isn't the best way of doing it. :)
>
>
> If we start using it more (maybe we should, at least for the
> benchmarks, I've been long wanting to do something decent there), then
> we'd need to add a proper update procedure.
>
> I'm fine with some checkout if it's a stable release, not trunk, as
it
> would make things a lot easier to update later (patch releases, new
> releases, etc).
>
>
> SGTM.
>
>
> Is there a preference on where to place the library? I had a look at
> {SingleSource/MultiSource}/Benchmarks/ and I didn't find a common
location
> for libraries used. I'm tempted to create a top-level "libs"
directory that
> will host common libraries but I'm also fine with just having the
benchmark
> library living alongside the XRay benchmarks.
>
> So two options here:
>
> 1) libs/googlebenchmark/
> 2) MultiSource/Benchmarks/XRay/googlebench/
>
>
> This is something that may be used (or is intended) to be used by others
> in the future, the first option makes it easier (or encouraging at least).
>
>
+1 to this.

Looks like there is reasonably active development going on right now
(primarily by EricWF who is also contributing to llvm), so we'll probably
want to coordinate how and how often we sync with top of tree. (Probably
more often than google unittests :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160914/9ac1f9b6/attachment.html>

Have you seen the prototype for googlebenchmark integration I did in the past:

https://reviews.llvm.org/D18428 <https://reviews.llvm.org/D18428> (though
probably out of date for todays test-suite)

+1 for copying the googlebechmark into the test-suite.

However I do not think this should simply go into MultiSource: We currently have
a number of additional plugins in the lit test runner such as measuring the
runtime of the benchmark executable, determining code size, we still plan to add
a mode to run benchmarks multiple times, we run the bechmark under perf (or iOS
specific tools) to collect performance counters… Many of those are questionable
measurements for a googlebenchmark executable which has varying runtime because
it runs the test more/less often.
We really should introduce a new benchmarking mode for this.

- Matthias
> On Sep 14, 2016, at 8:29 AM, Eric Christopher via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> On Wed, Sep 14, 2016 at 8:23 AM Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> On Sep 14, 2016, at 12:50 AM, Dean Michael Berris via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>> 
>> I'm working on this now, and I had a few more questions below for
Renato and the list in general. Please see inline below.
>> 
>>> On 2 Sep 2016, at 11:27, Dean Michael Berris <dean.berris at
gmail.com <mailto:dean.berris at gmail.com>> wrote:
>>> 
>>>> On 2 Sep 2016, at 11:19, Renato Golin <renato.golin at
linaro.org <mailto:renato.golin at linaro.org>> wrote:
>>>> 
>>>> On 2 September 2016 at 02:13, Dean Michael Berris
<dean.berris at gmail.com <mailto:dean.berris at gmail.com>> wrote:
>>>>> I think it should be possible to have a snapshot of it
included. I don't know what the licensing implications are (I'm not a
lawyer, but I know someone who is -- paging Danny Berlin).
>>>> 
>>>> The test-suite has a very large number of licenses (compared to
LLVM),
>>>> so licensing should be less of a problem there. Though Dan can
help
>>>> more than I can. :)
>>>> 
>>> 
>>> Cool, let's wait for what Danny thinks on the patch I'll be
preparing. :)
>>> 
>>>> 
>>>>> I'm not as concerned about falling behind on versions
there though mostly because it should be trivial to update it if we need it.
Though like you, I agree this isn't the best way of doing it. :)
>>>> 
>>>> If we start using it more (maybe we should, at least for the
>>>> benchmarks, I've been long wanting to do something decent
there), then
>>>> we'd need to add a proper update procedure.
>>>> 
>>>> I'm fine with some checkout if it's a stable release,
not trunk, as it
>>>> would make things a lot easier to update later (patch releases,
new
>>>> releases, etc).
>>>> 
>>> 
>>> SGTM.
>>> 
>> 
>> Is there a preference on where to place the library? I had a look at
{SingleSource/MultiSource}/Benchmarks/ and I didn't find a common location
for libraries used. I'm tempted to create a top-level "libs"
directory that will host common libraries but I'm also fine with just having
the benchmark library living alongside the XRay benchmarks.
>> 
>> So two options here:
>> 
>> 1) libs/googlebenchmark/
>> 2) MultiSource/Benchmarks/XRay/googlebench/
> 
> This is something that may be used (or is intended) to be used by others in
the future, the first option makes it easier (or encouraging at least).
> 
> 
> +1 to this.
> 
> Looks like there is reasonably active development going on right now
(primarily by EricWF who is also contributing to llvm), so we'll probably
want to coordinate how and how often we sync with top of tree. (Probably more
often than google unittests :)
> 
> -eric 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160914/1d55b8d0/attachment.html>