Summary: modified AtomicHashArray and AtomicHashMap to support move constructible types

Test Plan: tested with fbcode/folly/test/AtomicHashArrayTest.cpp and fbcode/folly/test/AtomicHashMapTest.cpp

Reviewed By: philipp@fb.com

FB internal diff: D527270

Summary: The format benchmark that was ported some time back has few data points to show - http://fburl.com/3545876

Test Plan: fbmake --log-to-rfe runbenchmarks_opt

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D524306

Summary: KiB, MiB, GiB, TiB, etc

Test Plan: by hand in a program using them

Reviewed By: philipp@fb.com

FB internal diff: D527001

Summary:
This diff makes RWTicketSpinLock eventually start calling
sched_yield() during shared and aggressive exclusive lock access, to
avoid pathologies that can arise when the number of threads far
exceeds the number of actual cores.

Test Plan:
1. unit tests
2. benchmark w/o + w/ diff

Reviewed By: nathan@fb.com

FB internal diff: D524897

Summary: Applies a function to a std::tuple of arguments.

Test Plan: Unit test.

Reviewed By: tjackson@fb.com

FB internal diff: D520190

Summary: That's all.

Test Plan: .

Reviewed By: philipp@fb.com

FB internal diff: D520116

Summary:
... which are supported in gcc 4.7, but not 4.6, and they enable useful
optimizations.  As long as we're planning to support both 4.6 and 4.7 in
our code base, we should write code using these macros.

Test Plan:
test added, compiled with both 4.6 and 4.7, verified the
assertion in the test comment by looking at dissassembly output in the
4.7 version

Reviewed By: delong.j@fb.com

FB internal diff: D520343

Test Plan: yes

Reviewed By: delong.j@fb.com

FB internal diff: D519897

Summary:
If you allocate N bytes and then try to grow that in place using rallocm
(ALLOCM_ZERO | ALLOCM_NO_MOVE) to M > N, our code assumed that all
memory from N to M would be zeroed.  In fact, rallocm only zeroes *new*
memory, so if jemalloc actually allocated N1 > N bytes initially,
rallocm will only zero memory from N1 to M.

Fixed by using calloc.

Test Plan: thread_local_test, tested in production

Reviewed By: delong.j@fb.com

FB internal diff: D519781

Summary:
Is there any better solution? Maybe a generic flag in Benchmarks to say
please don't run benchmarks?

Test Plan: (not in folly)

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D503619

Summary: I could have sworn I undid that un-templatification of the constructor.

Test Plan: build folly/test

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D518981

Summary: As they can both be used to represent ranges of bytes.

Test Plan: test added

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D518666

Test Plan: No

Reviewed By: lucian@fb.com

FB internal diff: D515713

Test Plan: all folly tests

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D517118

Summary:
gcc errors out when code that throws is compiled with
'-fno-exceptions'.  Since we add Malloc.h into our custom libstdc++
use the exception wrappers from functexcept.h so that they can build
with third-party projects that use '-fno-exceptions'.

Test Plan:
Built llvm in the gcc-4.7.1-glibc-2.14.1-fb platform with these
changes.

Reviewed By: tudorb@fb.com

FB internal diff: D516577

Summary:
Looks like a typo, it should obviously be std::memory_order_relaxed (all
necessary synchronization is done on numMapsAllocated_).

Test Plan: compiled it, ran tests

Reviewed By: sahrens@fb.com

FB internal diff: D515322

Summary:
A boost regex dependency wasn't added to the Makefile.am file.  Also
the it appears that boost thread lib dependencies had a typo in the
makefile variable name.

Test Plan: ran builds on ubunutu and fedora VMs

Reviewed By: tudorb@fb.com

FB internal diff: D514039

Test Plan: no

Reviewed By: philipp@fb.com

FB internal diff: D512868

Summary:
IOBuf::prepend needs to increment length_.

Added IOBufQueue::prepend, which uses the headroom in the first buffer
instead of growing the queue at the head.

Test Plan: tests added

Reviewed By: simpkins@fb.com

FB internal diff: D513676

Summary:
This optimization eliminates about 75% of the multiplications and bounds
checking in the original code by using constant lookup tables to convert
from decical digit to (shifted) binary number, instead of arithmetic.
The total cost of the lookup tables is 2KB of static memory, but the
average throughput gain across the range from 1 to 19 characters is 27%.
The throughput distributes as follows: (in million iters/sec)
Bytes   Orig    New     Speedup
1       101.31  110.12  109%
2       97.42   110.12  113%
3       97.42   105.53  108%
4       79.13   101.31  128%
5       74.48   97.42   131%
6       74.48   93.81   126%
7       70.35   93.81   133%
8       61.77   79.14   128%
9       58.9    72.35   123%
10      58.9    74.48   126%
11      56.28   74.48   132%
12      50.22   64.93   129%
13      48.52   60.3    124%
14      47.74   61.77   129%
15      46.88   61.77   132%
16      42.54   55.06   129%
17      41.51   51.69   125%
18      40.97   52.76   129%
19      39.57   52.76   133%

Test Plan: Passes all unit tests

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D493245

Summary: Add ability to set and get N consecutive bits from the bit sequence.

Test Plan: test added

Reviewed By: lucian@fb.com

FB internal diff: D511438

Summary:
adding what seems to be a missing constructor to StringPiece --
I need to be able to take a piece of another StringPiece. (It's possible
to do that with all sorts of strings already, except StringPiece...)

Test Plan: na -- tested as part of other (dependent) diffs

Reviewed By: delong.j@fb.com

FB internal diff: D508545

Test Plan: No

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D509324

Summary: These were handy in the old framework and easy enough to add.

Test Plan:
ran ThreadCachedIntTest - got better (but not perfect due to
subtraction of single-threaded baseline from multi-threaded results).

Reviewed By: sherman.ye@fb.com

FB internal diff: D490324

Summary:
A lot of libstdc++-4.7 headers dropped includes of unistdc.h, so
we'll probably see more of these.

Test Plan: built folly

Reviewed By: simpkins@fb.com

FB internal diff: D508871

Reviewed By: philipp@fb.com

FB internal diff: D491952

Summary: The main reason being so that they can be fed to some automated systems, if required.

Test Plan: Just ran few benchmarks locally

Reviewed By: andrewjcg@fb.com

FB internal diff: D501025

Summary: Simple class to handle IOBuf as an array of objects of fixed size.

Test Plan: test added

Reviewed By: brianp@fb.com

FB internal diff: D497287

Summary:
This is part 1 of a change to add hysteretic behavior to a blocking queue based on ProducerConsumerQueue.

Knowing the size is useful for monitoring and possibly for objects that contain a ProducerConsumerQueue.

Test Plan:
Added tiny test-case.

Tests pass

Reviewed By: delong.j@fb.com

FB internal diff: D496787

Summary: Function is documented in the header.

Reviewed By: soren@fb.com

FB internal diff: D494315

Summary: As title

Test Plan: Deployed to wormhole_apps.dragon.dev

Reviewed By: asharma@fb.com

FB internal diff: D493253

Summary: follybenchmark and follyfingerprint need folly to work.

Test Plan: built on ubuntu

Reviewed By: andrewjcg@fb.com

FB internal diff: D494955

Summary:
The __m128i type is a pair of 64-bit signed ints and the values
generated in generate_varint_tables.py overflow this range, which
causes clang to complain.

Test Plan:
Built and ran unittests.  Also verified that the GroupVarintTable.o
data section was identical with and w/o this change.

Reviewed By: tudorb@fb.com

FB internal diff: D494645

Test Plan: No

Reviewed By: delong.j@fb.com

FB internal diff: D494525

Summary:

Moves some string manipulation code like humanify into folly

Moves hash-related functions into folly and removes some old includes
to clean up some code

Adds generic hashing for tuples, similar to pairs

Updates all of the build breakages from the above

Test Plan: run unit tests

Reviewed By: delong.j@fb.com

FB internal diff: D490478

Summary: They're (signed) long long.

Test Plan: built, folly/test

Reviewed By: andrewjcg@fb.com

FB internal diff: D493270

Summary: It creates too many threads, stop when we run out of resources.

Test Plan: by hand, in a loop, in a memory-constrained environment

Reviewed By: delong.j@fb.com

FB internal diff: D493239

Summary:
Fix bug in FBStringTest (don't reuse the same file name)

Don't use VLOG, as that requires that glog is compiled with gflags
support, which it isn't always.

Add other targets and tests, make all tests pass.

Test Plan: tests

Reviewed By: delong.j@fb.com

FB internal diff: D493018

Summary:
Fix bug in FBStringTest (don't reuse the same file name)

Don't use VLOG, as that requires that glog is compiled with gflags
support, which it isn't always.

Add other targets and tests, make all tests pass.

Test Plan: tests

Reviewed By: delong.j@fb.com

FB internal diff: D493018

Summary:
Also generate fingerprint tables every time, so the code doesn't rot.

TODO(tudorb): move benchmark to folly
TODO(tudorb): Include the program used to generate the polynomials
(can't build as it requires NTL from http://www.shoup.net/ntl/)

Test Plan: folly/test

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D492455