Benchmark: branchless min vs Math.min vs cached min vs ternary vs if (2 values)

Script Preparation code:

var rnd = Math.random;
var branchlessMin = (a, b) => (a > b) * b + (a <= b) * a;
var mathMin = Math.min;
var minTernary = (a, b) => a > b ? b : a;
var minIf = (a, b) => {
   if (a > b) {
     return b;
   } else {
     return a;
   };
};

Tests:

branchless
return branchlessMin(rnd(), rnd());
Math.min (cached)
return mathMin(rnd(), rnd());
Math.min (uncached)
return Math.min(rnd(), rnd());
Min w/ Ternary
return minTernary(rnd(), rnd())
Min w/ If
return minIf(rnd(), rnd())

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
branchless
Math.min (cached)
Math.min (uncached)
Min w/ Ternary
Min w/ If

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 27 days ago):

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks!

**What is being tested?**

The provided JSON represents a benchmark test case that compares the performance of four different approaches to find the minimum value between two numbers: `branchless min`, `Math.min` (both with and without caching), `Min w/ Ternary`, and `Min w/ If`. The test cases are designed to measure the execution speed of each approach.

**Options compared:**

1. **Branchless min**: This is a custom implementation that uses bitwise operations to minimize the number of branch instructions, potentially reducing execution overhead.
2. **Math.min (cached)**: This uses the `Math.min` function with caching enabled, which means that if the input values are repeated in quick succession, the result can be cached to avoid recalculating it.
3. **Math.min (uncached)**: Similar to the previous one, but without caching, which means that each call to `Math.min` will recalculate the result from scratch.
4. **Min w/ Ternary**: This uses a ternary operator (`?:`) to concisely express the minimum value calculation in a single line of code.
5. **Min w/ If**: This uses an if-else statement to calculate the minimum value.

**Pros and Cons:**

1. **Branchless min**:
	* Pros: Reduced branch overhead, potentially faster execution times due to fewer CPU cycles spent on conditional instructions.
	* Cons: May require additional computational resources or constants that can increase memory usage, making it less cache-friendly.
2. **Math.min (cached)** and **Math.min (uncached)**:
	* Pros: Using the built-in `Math.min` function with caching provides a convenient way to calculate the minimum value without having to implement it yourself, while uncaching allows for direct access to the implementation details.
	* Cons: Caching can increase memory usage if repeated calls are made, and the actual performance gain may be negligible unless the cache is hit frequently enough.
3. **Min w/ Ternary**:
	* Pros: This approach provides a concise way to express the minimum value calculation in a single line of code, reducing code bloat and making it easier to maintain.
	* Cons: The ternary operator might not be as efficient as the other options due to the potential for unnecessary function calls or overhead from evaluating expressions.
4. **Min w/ If**:
	* Pros: This approach provides clear readability by using an if-else statement, which can make it easier to understand and maintain complex logic.
	* Cons: Compared to other options, this might be slower due to the overhead of branch instructions.

**Library usage (Math.min)**

The `Math.min` function is a built-in JavaScript method that calculates the minimum value between two numbers. It uses caching under the hood to improve performance when called with repeated arguments. The caching mechanism stores the result in memory and reuses it if the same inputs are encountered again, allowing for faster execution times.

**Special JS feature (ES6+ syntax)**

The benchmark test case does not explicitly use any ES6+ features such as template literals or destructuring. However, some of the options might rely on implicit type coercion or assumptions about variable behaviors that may be specific to certain JavaScript engines or versions.

**Alternatives**

Some potential alternatives to consider when working with similar performance-critical code:

* **Array.prototype.min**: Similar to `Math.min`, but implemented as a method on arrays instead of numbers.
* **Custom implementation using bit manipulation**: Implementing a custom minimum value calculation using bitwise operations, potentially providing faster execution times than the branchless approach.
* **Using an interpreter or JIT compiler**: Some JavaScript engines like V8 (used in Chrome) provide built-in support for just-in-time (JIT) compilation and optimization. This can result in significant performance gains for critical code paths.

In conclusion, the benchmark test case provides a valuable insight into the relative performance of different approaches to calculating the minimum value between two numbers in JavaScript. By understanding the pros and cons of each option, developers can make informed decisions about which implementation approach best suits their specific use cases and performance requirements.

Latest run results:

Run details: (Test run date: 2 years ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36

Browser/OS: Chrome 102 on Windows

View result in a separate tab

Test name	Executions per second
branchless	6513778.5 Ops/sec
Math.min (cached)	6542262.5 Ops/sec
Math.min (uncached)	5103575.5 Ops/sec
Min w/ Ternary	6553406.0 Ops/sec
Min w/ If	6542017.5 Ops/sec

Related benchmarks:

branchless min vs Math.min vs cached min vs ternary vs if (2 values) (version: 0)

Comparing performance of: branchless vs Math.min (cached) vs Math.min (uncached) vs Min w/ Ternary vs Min w/ If

Created: 2 years ago by: Guest

Jump to the latest result

branchless

Math.min (cached)

Math.min (uncached)

Min w/ Ternary

Min w/ If

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 27 days ago):