Summary: Only tested in release mode, sigh. Fixed a failing asserd.

Test Plan: tested in dbg mode

Reviewed By: tudorb@fb.com

FB internal diff: D546318

Summary:
https://phabricator.fb.com/D544159 reveals a large performance gap between
fbstring and std::string for repeated appends of short strings, which I
consider a relatively urgent matter (as much of our code uses such patterns).

This diff attempts to fix the issue in a principled manner by first appending
the first character with exponential reallocation, after which the rest of the
characters are appended normally.

With the proposed fix the benchmarks are much faster than the previous fbstring
and also than std::string (numbers to follow in comments).

Test Plan: unittested and benchmarked

Reviewed By: soren@fb.com

FB internal diff: D545416

Summary: ... and is shorter and more readable

Test Plan: folly/test

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D545774

Summary:
fbvector was not accepting move_iterators for
InputIterator-templated construct, assign, and insert. The root cause
was the check '(b_ <= &*first && &*first < e_)', used to check if the
assignment was from internal data. This addressof check does not compile
with rvalue-references, and causes the first iterator to be dereferenced
more than once; both against the contract of std::vector. The standard
allows for undefined behaviour in the self-iterator case, so there are
no contractual barriers to removing this check.

Test Plan:
run fbvector test and benchmark. An fbgs for 'assign' turns
up few matches; the seem to be normal use-case. Test fbvector assign
with self-iterators in order (i.e. fbv.assign(fbv.begin(), fbv.end()));
this seems to work fine.

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D535012

Summary: ^

Test Plan: Unit tests

Reviewed By: delong.j@fb.com

FB internal diff: D543586

Summary:
Appending many small strings to fbstring appears much slower (~3x) vs.
std::string. Adding benchmark case to illustrate.

[If this isn't wanted, I can revert]

Test Plan: This is a benchmark.

Reviewed By: soren@fb.com

FB internal diff: D544159

Test Plan: none

Reviewed By: delong.j@fb.com

FB internal diff: D543196

Test Plan: built

Reviewed By: delong.j@fb.com

FB internal diff: D543320

Summary:
because, shockingly, glibc doesn't divert to the gcc builtins which are
inlined and fast

Test Plan: folly/test

Reviewed By: sding@fb.com

FB internal diff: D543363

Summary:
by removing the unnecessary constraint that the input and output be in
the same register (copypasta from https://phabricator.fb.com/D542718)

Test Plan: folly/test

Reviewed By: soren@fb.com

FB internal diff: D543310

Summary:
If compiled for a popcnt-supporting target (-march=corei7, for example),
use __builtin_popcount, as it's presumably inlined.  Otherwise, detect
on startup (in the same way as glibc dispatches to one of the many
flavors of memcpy): GCC allows us to add a resolver function which the
dynamic loader will call on startup to resolve a function to one of
various alternatives; we check (using the cpuid instruction) whether
popcnt is supported, and use it if available.

Test Plan: tests added

Reviewed By: soren@fb.com

FB internal diff: D542977

Summary:
It appears that std::unordered_map is no longer relocatable in
gcc-4.7.  Use std::vector instead, until fbvector supports non-
relocatable types.

Test Plan: Built and ran facebar tests under gcc-4.7.  Also ran folly unittests.

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D543099

Summary: Add operator== and operator!= to folly::StlAllocator, which are required by some other libraries.

Test Plan: Tested by running with recursive_wrapper in boost::variant, and unit tests in folly/test.

Reviewed By: delong.j@fb.com

FB internal diff: D541237

Test Plan: Compiled.

Reviewed By: andrewjcg@fb.com

FB internal diff: D541226

Summary: github pull #11

Test Plan: None.

Reviewed By: andrewjcg@fb.com

FB internal diff: D541230

Summary:
fbstring generates some apparently false positive uninitialized warnings
under gcc-4.7.1.  This diff disables the '-Wuninitialized' flag for
fbstring.

Test Plan: build

Reviewed By: ldemailly@fb.com

FB internal diff: D542722

Test Plan: test added

Reviewed By: soren@fb.com

FB internal diff: D538703

Summary:
Currently, takeOwnership lets a user pass in a data buffer and wraps it in an
IOBuffer. However, the capacity and length of the user buffer are required to
be same.

Added a new API to allow buffers where the capacity and length can be different.

Users of existing API should not be affected.

Test Plan:
1) Added new test case to IOBufTest that checks buffers with length
different from capacity
2) Run existing IOBuf test cases to verify no regressions

Reviewed By: brianp@fb.com

FB internal diff: D536575

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