Geode Native Benchmarking

2018-05-07 Thread Jacob Barrett 
I got sucked into Google Benchmark [1], a C++ benchmark framework, and
decided to put together a POC benchmark project for Geode Native based on
it. You can find it in apache/geode-native PR 293 [2]. There are two new
projects, cpp-benchmark and cpp-integration-benchmark.

The cpp-benchmark is for unit or micro benchmarks that do not require a
Geode server to test, like a unit test.

The cpp-itegration-benchmark is then obviously for integration style
benchmarks that require a Geode server. It shares the new single process
integration framework classes as the new integration tests. The integration
tests, benchmarks and framework, have been refactored and moved to make
this relationship clear.

Please consider giving this some review and your blessing if you think
there is benefit in integrating it into the trunk.

Skip this part if you aren't interested in some benchmark results from each
platform.

As warned, here are some quick benchmarks from the sample included in this
PR that tests the time spent taking a Java String compatible hash code of a
C++ std::string in UTF-8 vs. a std::u16string in UTF-16. Since the Java
String hash code is computed on the individual UTF-16 code units
encapsulate din Java String, we must convert from UTF-8 to UTF-16 to hash
the std::string UTF-8. We have not optimized this to calculate the hash
inline with this conversion but rather take a brute force convert to UTF-16
then hash the UTF-16. This benchmark shows us that optimizing this method
could give us significant hash performance somewhere between the UTF-8 and
UTF-16 benchmark values. The benchmark name is formatted as
[fixture]/[test]/[variant], for example GeodeHashBM/std_string/8 is the
GeodeHashBM fixture (think test fixture), std_string test, with
8 characters. This is achieved by defining the test like this:

BENCHMARK_DEFINE_F(GeodeHashBM, std_string)(benchmark::State& state) {
  std::string x(state.range(0), 'x');
  for (auto _ : state) {
int hashcode;
benchmark::DoNotOptimize(hashcode = geode_hash{}(x));
  }
}
BENCHMARK_REGISTER_F(GeodeHashBM, std_string)->Range(8, 8 << 10);

Please read the details of Google Benchmark to understand how it does what
it it does or accept that it does some magic to warm up the code and then
runs the bit of code inside the for-range loop in groups of many iterations
(seen in the results below) to calculate a mean time for each individual
execution of that block.

The the results are...

*Windows - AWS c5.2xlarge*

Run on (8 X 3000 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 1048K (x4)
  L3 Unified 25952K (x1)
--
Benchmark   Time   CPU Iterations
--
GeodeHashBM/std_string/828353 ns  28250 ns  24889
GeodeHashBM/std_string/64   27747 ns  27623 ns  24889
GeodeHashBM/std_string/512  31941 ns  32087 ns  22400
GeodeHashBM/std_string/4096 62409 ns  61384 ns  11200
GeodeHashBM/std_string/8192 98233 ns  97656 ns   6400
GeodeHashBM/std_u16string/8 7 ns  7 ns   8960
GeodeHashBM/std_u16string/64   59 ns 59 ns   1120
GeodeHashBM/std_u16string/512 593 ns600 ns112
GeodeHashBM/std_u16string/4096   4816 ns   4757 ns 144516
GeodeHashBM/std_u16string/8192   9641 ns   9835 ns  74667

We can see here that windows has really poor performance converting from
UTF-8 to UTF-16 when compared to other results below. This is likely due to
bugs in the C++ runtime they ship that are supposed to be addressed in the
2019 release.


Linux - AWS c5.2xlarge
--
Run on (8 X 3000 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 1024K (x4)
  L3 Unified 25344K (x1)
--
Benchmark   Time   CPU Iterations
--
GeodeHashBM/std_string/8  116 ns116 ns6042733
GeodeHashBM/std_string/64 488 ns488 ns1434877
GeodeHashBM/std_string/512   2612 ns   2612 ns 268202
GeodeHashBM/std_string/4096 19639 ns  19639 ns  35640
GeodeHashBM/std_string/8192 39025 ns  39025 ns  17930
GeodeHashBM/std_u16string/8 5 ns  5 ns  133394926
GeodeHashBM/std_u16string/64   47 ns 47 ns   14862333
GeodeHashBM/std_u16string/512 449 ns449 ns1558067
GeodeHashBM/std_u16string/4096   3628 ns   3628 ns 192958
GeodeHashBM/std_u16string/8192   7260 ns   7261 ns  96415


*2013 MacBook Pro*
---
Run on (8 X 2600 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1

Re: JIRA and Wiki Access

2018-05-07 Thread Dan Smith 
Hi Nick,

Welcome to the Apache Geode project :)

I don't see your username in JIRA or the wiki - have you created an
account? You need to manually create an account in both systems.

-Dan

https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute

On Mon, May 7, 2018 at 11:00 AM, Nicholas Vallely 
wrote:

> Hello!
>
> I am new to Pivotal and need to get access to JIRA and the Wiki for my
> user:
> nvallely
>
> Please let me know what other information you may need.
>
> Nick
>

JIRA and Wiki Access

2018-05-07 Thread Nicholas Vallely 
Hello!

I am new to Pivotal and need to get access to JIRA and the Wiki for my user:
nvallely

Please let me know what other information you may need.

Nick

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #910 was SUCCESSFUL (with 2385 tests)

2018-05-07 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #910 was successful.
---
Scheduled
2387 tests in total.

https://build.spring.io/browse/SGF-NAG-910/





--
This message is automatically generated by Atlassian Bamboo

Re: Reviewing our JIRA's

2018-05-07 Thread Michael Stolz 
Good first step!

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
Download the GemFire book here.


On Sun, May 6, 2018 at 10:38 AM, Anthony Baker  wrote:

> As a first step, I closed 30 issues that hadn’t been updated in 2 years.
>
> project = GEODE AND issuetype = Bug AND resolution = Unresolved AND
> (labels in (CI, Ci, ci, Flaky, flaky) OR summary ~ ci) and updated <= -104w
> ORDER BY created DESC, priority DESC, updated DESC
>
> Anthony
>
>
> > On Apr 26, 2018, at 6:24 PM, Lynn Hughes-Godfrey <
> lhughesgodf...@pivotal.io> wrote:
> >
> > Modifying your filter to look at jiras that haven't been updated in a
> year
> > (vs. created in the past year) ... there are 114 to review.
> > That probably means there were updates for 34 of those when they
> reproduced
> > in CI, etc, so we wouldn't want to close those.
> >
> > Looking specifically at GEODE-552 ... GEODE-640 was a duplicate of this
> and
> > has been marked closed (use port 0 so we use next available port vs.
> > default port) ... so really this one looks like a bookkeeping issue
> > (GEODE-552 should be closed as a duplicate of GEODE-640).
> > Same for GEODE-554 ... it is the same as GEODE-552, GEODE-640 (and also
> > open).
> >
> > I will probably take some more time tomorrow to look through the
> remaining
> > 112  to see if I can see any reason why we shouldn't just resolve
> them
> > now.
> > I will send you more feedback then.
> >
> >
> >
> >
> > On Thu, Apr 26, 2018 at 11:53 AM, Galen O'Sullivan <
> gosulli...@pivotal.io>
> > wrote:
> >
> >> I'm for it. Less noise is a good thing, and I don't think they're likely
> >> to get prioritized anyways. If we close as WONTFIX or similar, we can
> >> always look back for them later if we want.
> >>
> >>
> >>
> >> On 4/26/18 10:39 AM, Anthony Baker wrote:
> >>
> >>> Thanks Lynn!
> >>>
> >>> As I first step I’d like to focus on issues labeled as ‘CI’.  There are
> >>> 220 open issues and 148 [1] of those have been open for > 1 year.  If I
> >>> look at the metrics jobs [2, 3, 4] I see a clear mismatch between
> failures
> >>> that are currently relevant and our JIRA backlog.  That is, a bunch of
> >>> tests that used to fail don’t anymore.  Perhaps that’s because of the
> >>> transition away from Jenkins or something else, but it makes it hard to
> >>> figure out what is important.  GEODE-552 [5] is a good example—is this
> >>> still a problem and if so is it worth doing compared to more recent
> issues?
> >>>
> >>> So I’d like to make a radical proposal:  let’s close out all 148 of
> those
> >>> stale CI issues.  If a test failure recurs, we can always reopen the
> ticket.
> >>>
> >>> Why I think this is important:  I’ve noticed a few reports from users
> >>> that did not get timely attention and caused frustration.  I think
> reducing
> >>> the sheer volume of issues will help us focus on the most important
> issues.
> >>>
> >>> Let me know what you think.
> >>>
> >>> Thanks,
> >>> Anthony
> >>>
> >>> [1]https://issues.apache.org/jira/issues/?filter=12343689&jq
> >>> l=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%
> >>> 20resolution%20%3D%20Unresolved%20AND%20(labels%20in%20(CI%
> >>> 2C%20Ci%2C%20ci%2C%20Flaky%2C%20flaky)%20OR%20summary%20~%
> >>> 20ci)%20and%20created%20%3C%3D%20%20-52w%20ORDER%20BY%
> >>> 20created%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >>> [2] https://concourse.apachegeode-ci.info/teams/main/pipelines/d
> >>> evelop-metrics/jobs/GeodeDistributedTestMetrics/builds/66
> >>> [3] https://concourse.apachegeode-ci.info/teams/main/pipelines/d
> >>> evelop-metrics/jobs/GeodeIntegrationTestMetrics/builds/66
> >>> [4] https://concourse.apachegeode-ci.info/teams/main/pipelines/d
> >>> evelop-metrics/jobs/GeodeFlakyTestMetrics/builds/66
> >>> [5] https://issues.apache.org/jira/browse/GEODE-552
> >>>
> >>> On Apr 20, 2018, at 3:19 PM, Lynn Hughes-Godfrey <
>  lhughesgodf...@pivotal.io> wrote:
> 
>  I can help with that.
> 
> 
>  On Fri, Apr 20, 2018 at 1:46 PM, Anthony Baker 
>  wrote:
> 
>  I surfed through our JIRA backlog and cleaned up a bunch of old
> > issues—primarily issues that we missed resolving when the fix was
> > made.  In
> > some cases I asked for help determining if the issue should be
> closed.
> > If
> > you got one of these requests please try and follow up in the next
> week
> > or
> > so and close if needed.
> >
> > There are a number of issues remaining that probably deserve a deeper
> > review.  Some of these include:
> >
> > - Bugs that have insufficient detail and can’t be reproduced
> > - Tasks that may no longer be relevant
> > - Ideas that are good but we may never get around to doing them
> > - CI failures that no longer occur
> >
> > Ideally I’d like to close out issues where appropriate to make the
> > backlog
> > m

Re: Requesting Geode Wiki Edit Permissions

2018-05-07 Thread Kirk Lund 
Done! Let me know if you need anything else.

On Fri, May 4, 2018 at 4:55 PM, Dale Emery  wrote:

> Hello,
>
> I am requesting permission to add and edit Geode Wiki pages.
>
> My user ID on Apache Confluence is: demery
>
> Cheers,
> Dale
>
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
>