Skip to content

Tags: facebook/folly

Tags

v2025.10.06.00

Toggle v2025.10.06.00's commit message
avoid folly::hardware_concurrency optimization on android

Differential Revision: D83869948

fbshipit-source-id: d002c16f50fa27099df7e7f1a27dd6d66bb2405c

v2025.09.29.00

Toggle v2025.09.29.00's commit message
pull out encodePrivateKey from OpenSSLKeyUtilsTest file

Summary: This diff pulls out the encodePrivateKey function from the test file into the public interface so that other tests may reutilize this function without defining it themselves.

Reviewed By: mingtaoy

Differential Revision: D83207363

fbshipit-source-id: e8e530d96804ee7d8f545cff723e2b30067c5b27

v2025.09.22.00

Toggle v2025.09.22.00's commit message
Introduce folly::irange

Summary:
A type-safe, const-safe for-loop.

This has nicer ergonomics than `std::views::iota` in two ways. First, there is
a one-argument version `irange(N)` that loops through the range `[0, N)`
whereas `iota(N)` will loop through the range `[N, max/infinity/???)`. Second,
if the data types of two input the arguments mismatch the first argument will
be cast to the type of the second argument with a sanity check (which could be
strengthened).

swolchok and I introduced this to PyTorch and ExecuTorch a couple of years ago
and it is now the primary and recommended way of writing host code for-loops in
those projects. It prevents issues such as
```
for(int i=0; i < vec.size();i++)
```
where large datasets can result in indexing issues due to range limitations on
`i`.

Reviewed By: yfeldblum

Differential Revision: D82760961

fbshipit-source-id: f675868d51b9093007d03b859a4255a50ac08b26

v2025.09.15.00

Toggle v2025.09.15.00's commit message
Revert D82049706: Async transcoding - MediaTranscoder changes

Differential Revision:
D82049706

Original commit changeset: 2306c5eadc43

Original Phabricator Diff: D82049706

fbshipit-source-id: 72f2699fca88b7c8ec0a2c4ee81029d1542711c6

v2025.09.08.00

Toggle v2025.09.08.00's commit message
Assert that unsafe movers trigger mandatory copy elision

Summary:
This is a follow-up to snarkmaster's D81090508 when I realized that the new
`must_use_immediately_unsafe_mover` CPO represents a choke-point where
constraints like "custom unsafe movers of `T` must return exactly `T`" can be
cheaply and globally enforced.

Reviewed By: snarkmaster

Differential Revision: D81796674

fbshipit-source-id: 51453ee28376b89f511b2aba0dd25d64039bb1dd

v2025.09.01.00

Toggle v2025.09.01.00's commit message
Add PHP's Strict Base64 Decoder to Folly

Summary:
PHP's `base64_decode` function skips specific whitespace characters even when the strict parameter is set to true since the decoder is following the MIME Base64 format as specified in RFC 2045 Section 6.8. This difference from Folly's default Base64 decoder can be confusing for users of both since the implementation is not in parity with each other.

Add a Base64 decoder to Folly based on PHP's Base64 decoder with strict mode enabled. The implementation uses a skip table to skip the characters: '\t', '\n', '\r', and ' '. After skipping those characters, it decodes the remaining Base64 input using the regular Base64 decoder in Folly.

Benchmarks show that this two-pass approach (even by using the default scalar Base64 decoder) is more performant than the one-pass approach using a switch case implemented by PHP and Hack/HHVM's Zend Engine (`php_base64_decode_impl`) as well as a variant that uses a temporary 4-byte buffer.

Based on the disassembly and some analysis using `perf`, for the two-pass approach, the compiler decided to unroll the whitespace skip loop by a factor of 8 and the decoder loop by a factor of 2, which improved the performance. On the other hand, the one-pass approaches require some conditional branching to correctly handle whitespaces and padding, which proved to be too expensive. LLVM MCA's analysis does not seem to match the benchmark results most likely due to insufficient modelling of memory accesses, frontend operations, and branch/jump instructions.

With the two-pass approach, we also have the advantage of decoupling the whitespace removal step from the decoding step. As a result, we can swap out the decoding pass to use the SWAR or SSE4.2 decoder instead, which is even more performant. This approach is also better than PHP's SIMD decoder, which simply devolves to the scalar version once a whitespace character is encountered in the input string.

More fuzzing test cases have also been added to ensure that whitespaces are properly handled.

Base64 PHP Strict Decoder Implementation Performance Benchmarks:

- Two-pass with scalar decoder:
```
============================================================================
Base64Benchmark.cpp                          relative  time/iter   iters/s
============================================================================
decodePHPSmallString                                       16.24ns    61.57M
decodePHPMediumString                                      88.62ns    11.28M
decodePHPLargeString                                        1.67us   597.17K
decodePHPExtraLargeString                                   1.66ms    601.17
----------------------------------------------------------------------------
```

- Two-pass with SIMD decoder:
```
============================================================================
Base64Benchmark.cpp                          relative  time/iter   iters/s
============================================================================
decodePHPSmallString                                       16.01ns    62.44M
decodePHPMediumString                                      62.49ns    16.00M
decodePHPLargeString                                      954.29ns     1.05M
decodePHPExtraLargeString                                 943.06us     1.06K
----------------------------------------------------------------------------
```

- One-pass switch case:
```
============================================================================
Base64Benchmark.cpp                          relative  time/iter   iters/s
============================================================================
decodePHPSmallString                                       17.96ns    55.68M
decodePHPMediumString                                     144.26ns     6.93M
decodePHPLargeString                                        2.97us   336.69K
decodePHPExtraLargeString                                   2.66ms    375.83
----------------------------------------------------------------------------
```

- One-pass 4-bytes buffer:
```
============================================================================
Base64Benchmark.cpp                          relative  time/iter   iters/s
============================================================================
decodePHPSmallString                                       18.92ns    52.85M
decodePHPMediumString                                     111.43ns     8.97M
decodePHPLargeString                                        2.36us   424.06K
decodePHPExtraLargeString                                   2.40ms    416.90
----------------------------------------------------------------------------
```

Reviewed By: DenisYaroshevskiy

Differential Revision: D77838213

fbshipit-source-id: af73c6431a8c02460f945aef65551c849c523dd1

v2025.08.25.00

Toggle v2025.08.25.00's commit message
fbcode/folly

Reviewed By: dtolnay

Differential Revision: D80780795

fbshipit-source-id: e75e3b7c36210e426c582a104e758242ddb693d3

v2025.08.18.00

Toggle v2025.08.18.00's commit message
Remove unused fn

Summary: This is causing issues when bringing in some fbcode deps - see: https://fb.workplace.com/groups/560979627394613/permalink/3341361656023049/

Reviewed By: skrueger

Differential Revision: D80342140

fbshipit-source-id: 6f098cbaeb9d9418ca5882a2f018cfa2ddae5bed

v2025.08.11.00

Toggle v2025.08.11.00's commit message
Fix bug in folly::Optional::toStdOptional

Summary:
See https://fb.workplace.com/groups/145730152809376/permalink/1685600578822318/ for context. If you call toStdOptional on folly::Optional<bool>, the following cast will not work as expected:

```
folly::Optional<bool> optional = false;
// This will convert optional to bool and then construct std::optional<value>!
auto value = static_cast<std::optional<Value>>(optional);
```

So we just need to not rely on the cast and implement it in the more verbose way.

Differential Revision: D79928399

fbshipit-source-id: ea41ff6bf9c7724704b7d7056c0fd812e1faf0b6

v2025.08.04.00

Toggle v2025.08.04.00's commit message
Test thread priority inheritance on add() on non-dynamic CPUThreadPoo…

…lExecutor

Summary:
If `CPUThreadPoolExecutor` is configured without dynamic thread creation, it is expected that no new threads are created on `add()`. This is important because `add()` may come from threads with different priority, and that would be inherited by the newly created threads.

Using static size protects from that behavior. This is widely depended on, so we should have a test for it.

Reviewed By: uvdn7

Differential Revision: D79378022

fbshipit-source-id: 3ccbd305a001b0cdd09e7142a6ee0ddb1a44c73a