- 19 Jun, 2015 1 commit
-
-
Marc Horowitz authored
Summary: dynamic's integer type is signed, so make sure array indices are not negative. (See https://our.intern.facebook.com/intern/tasks/?t=7445055) Reviewed By: @Gownta Differential Revision: D2145689
-
- 17 Jun, 2015 3 commits
-
-
James Sedgwick authored
Summary: Instead of the one-off Nothing struct Reviewed By: @yfeldblum Differential Revision: D2158621
-
James Sedgwick authored
Summary: Three strategies 1. Optimistic locking 2. Acquire-release memory ordering instead of full sequential consistency 3. Some low-hanging branch miss optimizations Please review carefully; the dogscience is strong with this one ``` Before: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 127.99ns 7.81M promiseAndFuture 94.89% 134.89ns 7.41M withThen 28.40% 450.63ns 2.22M ---------------------------------------------------------------------------- oneThen 446.68ns 2.24M twoThens 58.35% 765.55ns 1.31M fourThens 31.87% 1.40us 713.41K hundredThens 1.61% 27.78us 35.99K ---------------------------------------------------------------------------- no_contention 4.63ms 216.00 contention 80.79% 5.73ms 174.52 ---------------------------------------------------------------------------- throwAndCatch 10.91us 91.64K throwAndCatchWrapped 127.14% 8.58us 116.51K throwWrappedAndCatch 178.22% 6.12us 163.32K throwWrappedAndCatchWrapped 793.75% 1.37us 727.38K ---------------------------------------------------------------------------- throwAndCatchContended 1.35s 741.33m throwAndCatchWrappedContended 139.18% 969.23ms 1.03 throwWrappedAndCatchContended 169.51% 795.76ms 1.26 throwWrappedAndCatchWrappedContended 17742.23% 7.60ms 131.53 ---------------------------------------------------------------------------- complexUnit 127.50us 7.84K complexBlob4 100.14% 127.32us 7.85K complexBlob8 100.16% 127.30us 7.86K complexBlob64 96.45% 132.19us 7.57K complexBlob128 92.83% 137.35us 7.28K complexBlob256 87.79% 145.23us 6.89K complexBlob512 81.64% 156.18us 6.40K complexBlob1024 72.54% 175.76us 5.69K complexBlob2048 58.52% 217.89us 4.59K complexBlob4096 32.54% 391.78us 2.55K ============================================================================ After: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 85.28ns 11.73M promiseAndFuture 88.63% 96.22ns 10.39M withThen 30.46% 279.99ns 3.57M ---------------------------------------------------------------------------- oneThen 231.18ns 4.33M twoThens 60.57% 381.70ns 2.62M fourThens 33.52% 689.71ns 1.45M hundredThens 1.49% 15.48us 64.58K ---------------------------------------------------------------------------- no_contention 3.84ms 260.19 contention 88.29% 4.35ms 229.73 ---------------------------------------------------------------------------- throwAndCatch 10.63us 94.06K throwAndCatchWrapped 127.17% 8.36us 119.61K throwWrappedAndCatch 179.83% 5.91us 169.15K throwWrappedAndCatchWrapped 1014.48% 1.05us 954.19K ---------------------------------------------------------------------------- throwAndCatchContended 1.34s 749.03m throwAndCatchWrappedContended 140.66% 949.16ms 1.05 throwWrappedAndCatchContended 164.87% 809.77ms 1.23 throwWrappedAndCatchWrappedContended 49406.39% 2.70ms 370.07 ---------------------------------------------------------------------------- complexUnit 86.83us 11.52K complexBlob4 97.42% 89.12us 11.22K complexBlob8 96.63% 89.85us 11.13K complexBlob64 92.53% 93.84us 10.66K complexBlob128 90.85% 95.57us 10.46K complexBlob256 82.56% 105.17us 9.51K complexBlob512 74.13% 117.12us 8.54K complexBlob1024 63.67% 136.37us 7.33K complexBlob2048 50.25% 172.79us 5.79K complexBlob4096 26.63% 326.05us 3.07K ============================================================================ ``` Reviewed By: @djwatson Differential Revision: D2139822
-
Praveen Kumar authored
Summary: Directly pass the arguments to respective constructors. Instead of first making temporary and then pass that. Closes #218 Reviewed By: @yfeldblum Differential Revision: D2156978 Pulled By: @sgolemon
-
- 16 Jun, 2015 3 commits
-
-
Sara Golemon authored
-
Sarang Masti authored
Summary: Fix leaks in unit tests Reviewed By: @djwatson Differential Revision: D2153681
-
Giuseppe Ottaviano authored
Summary: It is often useful to retrieve the value preceding the current value in an Elias-Fano iterator, for example when the list represents adjacent ranges. This diff implements a new method `previousValue` in `EliasFanoReader`. It also adds a new `kUnchecked` boolean template argument to `EliasFanoReader` which skips bounds checking. Reviewed By: @philippv Differential Revision: D2155049
-
- 15 Jun, 2015 8 commits
-
-
James Sedgwick authored
Summary: add remove<T>, remove(Handler*), removeFront(), removeBack() to Pipeline employ these to fix up reusing client pipelines with client dispatchers, which in turn fixes the broken ServiceTest Reviewed By: @djwatson Differential Revision: D2152636
-
Nathan Bronson authored
Summary: AtomicUnorderedInsertMap is a concurrent hash table that firmly at the performance end of the generality <-> performance spectrum. If you don't need updates (or can use your own concurrency control when overwriting values), you never need to delete, and you can predict your capacity perfectly, then you will get wait-free reads, lock-free inserts, safe concurrent iteration, and excellent cache and performance outlier behavior. Arbitrary key and value types are supported. Reviewed By: @yfeldblum Differential Revision: D2145281
-
Woo Xie authored
Summary: the openssl improvement does not support compression and decompression. Reviewed By: @Invalid auth token., @afrind Differential Revision: D2151003
-
Sara Golemon authored
Summary: This reverts commit 0968dcc2f0e02998fa53007853e0c0aad0a423b7. Reverts D2151582 Reviewed By: @iainb Differential Revision: D2153840
-
Sarang Masti authored
Summary: Since readCallback_ could be uninstalled in any of callbacks, we need to ensure that readCallback_ != nullptr before calling handleRead. Reviewed By: @djwatson Differential Revision: D2140054
-
Tudor Bosman authored
Summary: Because Ex resolves to SomeException&, and then all the tests in optimize<> fail. Reviewed By: @yfeldblum Differential Revision: D2152893
-
Sara Golemon authored
Remove duplicate header file Somehow this was already correct in the internal repo, but not the external one. Thanks!
-
Bin Wang authored
-
- 12 Jun, 2015 10 commits
-
-
Praveen Kumar authored
Summary: Directly pass the arguments to respective constructors. Instead of first making temporary and then pass that. Closes #218 Reviewed By: @JoelMarcey Differential Revision: D2151582 Pulled By: @sgolemon
-
Praveen Kumar authored
Summary: Defaulted (*=default*ed) default constructors are better because they can be constexpr and/or noexcept when C++ Standard thinks it is right to do so. And they remain user-declared rather than user-provided. Regarding *=default*ed default constructor, benifit is that the work might be done during compilation and we might not need to worry about exception paths. And for destructors, apart from that that =defaulted definition is in sync with defaulted default constructor we might discover that in some cases "() {}" might be ill-formed when "= default;" compiltion indicates so. If =defaulted definition for destructor doesn't do any harm then why not go for it. Closes #216 Reviewed By: @yfeldblum Differential Revision: D2145322 Pulled By: @sgolemon -
Praveen Kumar authored
Summary: We might be doing: 1) Create a temporary 2) Copy/Move out of it 3) Destroy that temporary. Which isn't needed in many places. And copy/move elision doesn't work for a temporary bound to a reference. We can forward arguments, directly. To get the work done three constructors were added. Closes #222 Reviewed By: @JoelMarcey, @yfeldblum Differential Revision: D2151731 Pulled By: @sgolemon
-
Misha Shneerson authored
Summary: To be able to use fiber lock in thrift Reviewed By: @brianwatling, @yfeldblum Differential Revision: D2149936
-
Yablonskyy@axilera.com authored
Summary: parseLeadingNumber does not contain EOS validation and raise an exception when '/sys/devices/system/cpu/cpu0/index0/shared_cpu_list' contains only one number like '0'. Closes #207 Reviewed By: @yfeldblum Differential Revision: D2148015 Pulled By: @sgolemon
-
Hans Fugal authored
Summary: Some internal malloc shims broke on using folly::ThreadLocal, so only do that for `__APPLE__`. Reviewed By: @brianwatling Differential Revision: D2151318
-
Nicholas Ormrod authored
Summary: Clang warns when types with vtables are memcpy'd. If the type has declared itself to be relocatable, then this is the desired behavior. If the type has not declared itself to be relocatable, then the memcpy codepath is dead. However, the dead codepath is still instantiated (it's inside an if block with a static check, but c++ doesn't have static-if), so the compiler spits out a nasty warning anyways. Each memcpy reference inside of fbvector has been void-ified. I have looked at all the codepaths leading to the memcpys, and see that they have isRelocatable or isTriviallyCopyable checks. Reviewed By: @markisaa Differential Revision: D2148286
-
Alan Frindell authored
Summary: As in title Reviewed By: @djwatson Differential Revision: D2151092
-
Nicholas Ormrod authored
Summary: For standard containers, assignment tries to reuse heap space. Dynamic assignment does not - it calls destroy(), and then reconstructs a new dynamic. In the case that the old and new types are the same (eg assigning a dynamic-vector to a dynamic-vector) we can call through to the underlying type's assignment operator. Reviewed By: @jdelong Differential Revision: D2148093
-
Woo Xie authored
Summary: this taks advantage of the SSL_write_iovec function to improve CPU. According our testing, it saves 10+% CPU. Reviewed By: @djwatson Differential Revision: D2119223
-
- 11 Jun, 2015 14 commits
-
-
Fifi Lyu authored
Summary: Folly still continue to build and work on earlier boost versions(boost < 1.56). **boost::context::make_fcontext() change history:** * __1.55:__ fcontext_t * make_fcontext( void * sp, std::size_t size, void(* fn)(intptr_t) ); * __1.56:__ fcontext_t make_fcontext(void* sp,std::size_t size,void(*fn)(intptr_t)); **boost doc:** http://www.boost.org/doc/libs/1_55_0/libs/context/doc/html/context/context/boost_fcontext.html http://www.boost.org/doc/libs/1_56_0/libs/context/doc/html/context/context/boost_fcontext.html Closes #205 Closes #210 Reviewed By: @jwatzman Differential Revision: D2148069 Pulled By: @sgolemon
-
Sara Golemon authored
Summary: Some OSs have python named according to a version ID e.g. `python2.7` without a symlink from plain `python` Use autotool's AM_PATH_PYTHON to search for a suitable interpreter and use that to generate the *Tables.cpp files. Closes #109 Reviewed By: @yfeldblum Differential Revision: D2147977
-
Alexander Böhn / FI authored
Summary: On non-Linux systems, the autotools-based build system conditionally appends `detail/Clock.h` to `libfollybase_la_SOURCES` – even though that file is in there statically no matter what (as per [line 46](https://github.com/facebook/folly/blob/master/folly/Makefile.am#L46)), which causes the `install` command to error out trying to install the file twice, during `make install`… this patch takes out the conditional append. Closes #201 Reviewed By: @yfeldblum Differential Revision: D2148004 Pulled By: @sgolemon
-
Hans Fugal authored
Summary: OSX doesn't support C++11's `thread_local`. :-/ (yet? http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports/29929949#29929949) We have `FOLLY_TLS` in `Portability.h` https://github.com/facebook/folly/blob/master/folly/Portability.h#L163-L175 So replace the usages of `thread_local` with `FOLLY_TLS`. But `__thread` is not drop-in compatible with `thread_local`, specifically the former requires global storage and needs a constexpr initializer, and a trivial destructor. `futures/QueuedImmediateExecutor` now uses `folly::ThreadLocal` (because `std::queue` has a non-trivial destructor). It might end up in one more alloc, per thread. I also rearranged the code to clarify the fact that although there may be many `QueuedImmediateExecutor`s, they all share the same queue per thread. I didn't use `folly::ThreadLocal` for fibers, because I thought it might be too expensive. But now I'm not so sure. I had to do the "check for default and then initialize" thing because of the requirement for constexpr initialization for `__thread` (and therefore `FOLLY_TLS`). Reviewed By: @jsedgwick Differential Revision: D2140369
-
Hans Fugal authored
Summary: Something's broken here, will track fixing in #7372389 Reviewed By: @jsedgwick Differential Revision: D2144077
-
Hans Fugal authored
Summary: They don't pass, but they build! Reviewed By: @jsedgwick Differential Revision: D2141717
-
Hans Fugal authored
Summary: Discard a result but propagate an exception. cf https://www.facebook.com/groups/715931878455430/permalink/879624552086161/ Reviewed By: @sammerat Differential Revision: D2144567
-
Woo Xie authored
Summary: This fucntion will be re-used for different SSL write functions in future. Reviewed By: @djwatson Differential Revision: D2117529
-
Hans Fugal authored
Summary: OSX apparently knows better than all of us plebes, and got rid of anonymous semaphores. Rather than try to work around that directly, I just switched to folly::LifoSem, which seems like a not-terrible idea anyway. Reviewed By: @jsedgwick Differential Revision: D2143566
-
Hans Fugal authored
Summary: ((not yet) more performant) sugar for `via(&x).then(func)` Reviewed By: @hannesr Differential Revision: D2131246
-
Tudor Bosman authored
Summary: Give IOBuf a copy constructor, which clones the whole chain. (IOBufs have shared pointer semantics). You could argue for cloning one single IOBuf, but cloning the whole chain has the nice side effect of making Thrift structures with IOBufs in them copyable, so there's that. Reviewed By: @djwatson Differential Revision: D2127209
-
James Sedgwick authored
Summary: Next step towards killing RequestEventBase hackery. Use EBs from global IO executor instead Reviewed By: @fugalh Differential Revision: D2123142
-
James Sedgwick authored
Summary: this is going to be a really common pattern, so I'm providing a shortcut Reviewed By: @fugalh Differential Revision: D2146008
-
James Sedgwick authored
Summary: No reason to go through the whole Promise rigamarole. Add an appropriate Core ctor and use that to make a completed Future with just the core alloc Note the big win in the `constantFuture` benchmark. ``` Before: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 120.50ns 8.30M promiseAndFuture 91.99% 130.98ns 7.63M withThen 28.17% 427.77ns 2.34M ---------------------------------------------------------------------------- oneThen 430.48ns 2.32M twoThens 58.03% 741.86ns 1.35M fourThens 31.85% 1.35us 739.97K hundredThens 1.61% 26.80us 37.32K ---------------------------------------------------------------------------- no_contention 4.58ms 218.48 contention 83.70% 5.47ms 182.86 ---------------------------------------------------------------------------- throwAndCatch 8.09us 123.55K throwAndCatchWrapped 94.43% 8.57us 116.67K throwWrappedAndCatch 154.69% 5.23us 191.12K throwWrappedAndCatchWrapped 614.06% 1.32us 758.70K ---------------------------------------------------------------------------- throwAndCatchContended 967.54ms 1.03 throwAndCatchWrappedContended 103.48% 935.04ms 1.07 throwWrappedAndCatchContended 148.24% 652.70ms 1.53 throwWrappedAndCatchWrappedContended 14313.28% 6.76ms 147.94 ============================================================================ After: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 69.11ns 14.47M promiseAndFuture 55.12% 125.37ns 7.98M withThen 16.49% 419.18ns 2.39M ---------------------------------------------------------------------------- oneThen 370.39ns 2.70M twoThens 55.11% 672.05ns 1.49M fourThens 29.00% 1.28us 782.89K hundredThens 1.23% 30.22us 33.09K ---------------------------------------------------------------------------- no_contention 4.56ms 219.46 contention 82.82% 5.50ms 181.77 ---------------------------------------------------------------------------- throwAndCatch 8.30us 120.42K throwAndCatchWrapped 96.40% 8.61us 116.08K throwWrappedAndCatch 162.66% 5.11us 195.89K throwWrappedAndCatchWrapped 680.39% 1.22us 819.36K ---------------------------------------------------------------------------- throwAndCatchContended 979.17ms 1.02 throwAndCatchWrappedContended 103.09% 949.84ms 1.05 throwWrappedAndCatchContended 153.55% 637.71ms 1.57 throwWrappedAndCatchWrappedContended 10468.47% 9.35ms 106.91 ============================================================================ ``` Reviewed By: @fugalh, @hannesr Differential Revision: D2144664
-
- 10 Jun, 2015 1 commit
-
-
Praveen Kumar authored
Summary: Use of std::max from libc++ resulted in error. std::max found type of its arguments diffrent whereas it expected them to be same. This diff fix the error. Closes #223 Reviewed By: @yfeldblum Differential Revision: D2144639 Pulled By: @sgolemon
-
