After the publication of the experiments with Boost.Unordered on Fil-C, some readers asked for a comparison of run-time performances between Fil-C and Clang's AddressSanitizer (ASAN).
Please do not construe this article as implying that Fil-C and ASAN are competing technologies within the same application space. Whereas ASAN is designed to detect bugs resulting in memory access violations, Fil-C sports a stricter notion of memory safety including UB situations where a pointer is directed to a valid memory region that is nonetheless out of bounds with respect to the pointer's provenance. That said, there's some overlapping between both tools, so it's only natural to question about their relative impact on execution times.
Our previous benchmarking repo has been updated to include results for plain Clang 18, Clang 18 with ASAN enabled, and Fil-C v0.674, all with release mode settings. The following figures show execution times in ns per element for Clang/ASAN (solid lines) and Fil-C (dashed lines) for three Boost.Unordered containers (boost::unordered_map, boost::unordered_flat_map and boost::unordered_node_map) and four scenarios.
![]() |
![]() |
|---|---|
| Running insertion | Running erasure |
|
|
|---|---|
| Successful lookup | Unsuccessful lookup |
In summary:
- Insertion:
Fil-C is between 1.8x slower and 4.1x faster than ASAN (avg. 1.3x faster). - Erasure:
Fil-C is between 1.3x slower and 9.2x faster than ASAN (avg. 1.9x faster). - Successful lookup:
Fil-C is between 2.5x slower and 1.9x faster than ASAN (avg. 1.6x slower). - Unsuccessful lookup:
Fil-C is between 2.6x slower and 1.4x faster than ASAN (avg. 1.9x slower).
So, results don't allow us to establish a clear-cut "winner". When allocation/deallocation is involved, Fil-C seems to perform better (except for insertion when the memory working set gets past a certain threshold). For lookup, Fil-C is generally worse, and, again, the gap increases as more memory is used. A deeper analysis would require knowledge of the internals of both tools that I, unfortunately, lack.




No comments :
Post a Comment