Igor's Techno Club

When Random Numbers Generator Becomes  a Performance Bottleneck

High-Frequency Calls in Tight Loops

The Problem: When you call an RNG millions of times in a tight loop—a common scenario in simulations, numerical computing, or procedural generation—the computational cost of each call adds up quickly.

The Solution: Choose faster Pseudo-Random Number Generators (PRNGs) and consider pre-generation strategies.

For Java applications, replace java.util.Random with faster alternatives:

// Instead of this:
Random random = new Random();
for (int i = 0; i < 1_000_000; i++) {
    doSomething(random.nextInt());
}

// Use this for better performance in single-threaded contexts:
ThreadLocalRandom random = ThreadLocalRandom.current();
for (int i = 0; i < 1_000_000; i++) {
    doSomething(random.nextInt());
}

For C/C++, consider modern PRNGs like xoshiro256++ or PCG (Permuted Congruential Generator), which offer excellent performance and strong statistical properties:

// PCG example
pcg32_random_t rng;
// Seed with a combination of time and a memory address for a good initial state
pcg32_srandom_r(&rng, time(NULL), (intptr_t)&rng);
for (int i = 0; i < 1000000; i++) {
    uint32_t value = pcg32_random_r(&rng);
    // Use the generated value
}

Pre-generation Strategy: For scenarios where you know the quantity of random numbers needed upfront, generate them in a single batch:

int[] randomBuffer = new int[1_000_000];
ThreadLocalRandom tlr = ThreadLocalRandom.current();
for (int i = 0; i < randomBuffer.length; i++) {
    randomBuffer[i] = tlr.nextInt();
}
// Now, access randomBuffer[i] in your performance-critical loop

This approach amortizes the generation cost and trades memory for CPU cycles, which can dramatically improve performance by keeping the CPU's pipeline full and improving cache efficiency.

Thread Contention: The Silent Killer

The Problem: Sharing a single RNG instance across multiple threads creates lock contention. While Java’s Random class is thread-safe, this safety comes at the high cost of synchronization overhead, which can cripple concurrent applications.

The Solution: Use thread-local RNGs to give each thread its own generator, eliminating contention entirely.

// Problematic: A single shared RNG slows down all threads
Random sharedRandom = new Random();
// Multiple threads calling sharedRandom.nextInt() will contend for the same lock.

// Solution 1: A thread-local wrapper (for older Java versions)
ThreadLocal<Random> localRandom = ThreadLocal.withInitial(Random::new);
int value = localRandom.get().nextInt();

// Solution 2: Use ThreadLocalRandom (the preferred approach in Java 8+)
int value = ThreadLocalRandom.current().nextInt();

ThreadLocalRandom is designed for this exact use case and provides excellent performance in multi-threaded code. It is also statistically superior to creating simple thread-local Random instances, as it helps avoid unintentional correlations between generators on different threads.

For applications using SplittableRandom (Java 8+), you can create independent, high-quality generators for each thread from a master source:

SplittableRandom masterRNG = new SplittableRandom();
// In each thread, create a split-off generator:
SplittableRandom threadRNG = masterRNG.split();
// Now use threadRNG without any contention.

Cryptographically Secure RNG: When Security Meets Performance

The Problem: SecureRandom is orders of magnitude slower than standard PRNGs because it gathers entropy from the operating system (e.g., hardware events, device drivers). Using it for non-cryptographic tasks can devastate performance.

The Solution: Use SecureRandom only where cryptographic security is a genuine requirement.

// Use SecureRandom ONLY for cryptographic material
SecureRandom secureRandom = new SecureRandom();
byte[] cryptoKey = new byte[32];
secureRandom.nextBytes(cryptoKey);

// For bulk non-cryptographic randomness, seed a fast PRNG with a secure value
SecureRandom seeder = new SecureRandom();
long seed = seeder.nextLong();
Random fastRng = new Random(seed);

// Now use 'fastRng' for high-volume generation
for (int i = 0; i < 1_000_000; i++) {
    int value = fastRng.nextInt();
    // process value
}

This hybrid approach gives you a cryptographically strong starting point while maintaining high performance for bulk generation. The suitability of this pattern depends on your threat model, but for many applications, it provides an excellent balance of security and speed.

Hardware and System Entropy Limits

The Problem: On some operating systems, particularly Linux, the default entropy source (/dev/random) can block if the system's entropy pool is depleted. This leads to the application freezing unpredictably, causing severe performance and availability issues.

The Solution: Configure your environment to use a non-blocking entropy source.

For Java applications on Linux, add this JVM argument to use /dev/urandom:

-Djava.security.egd=file:/dev/./urandom

Note: The ./ in the path is intentional—it’s a workaround for a known issue in some Java versions' entropy source selection logic. This tells the JVM to use /dev/urandom, which provides non-blocking behavior with security that is sufficient for nearly all applications.

You can also set this property programmatically for cross-platform safety:

// Do this early in your application's startup sequence
if (System.getProperty("os.name").toLowerCase().contains("linux")) {
    System.setProperty("java.security.egd", "file:/dev/./urandom");
}

Memory Bandwidth Saturation in High-Performance Computing

The Problem: In GPU computing or SIMD-heavy workloads, memory bandwidth can become the limiting factor when generating large amounts of random data.

The Solution: Use vectorized implementations and strategic batching.

For GPU applications, leverage specialized libraries:

// CUDA example using cuRAND
curandGenerator_t gen;
curandCreateGenerator(&gen, CURAND_RNG_PSEUDO_DEFAULT);
curandSetPseudoRandomGeneratorSeed(gen, time(NULL));

float *d_data;
cudaMalloc(&d_data, n * sizeof(float));
curandGenerateUniform(gen, d_data, n);

For CPU SIMD workloads, use vectorized RNG implementations. Intel’s MKL provides excellent SIMD-optimized generators:

// Intel MKL Vector Statistics Library
VSLStreamStatePtr stream;
vslNewStream(&stream, VSL_BRNG_MT19937, seed);
vdRngUniform(VSL_RNG_METHOD_UNIFORM_STD, stream, n, r, 0.0, 1.0);

The key principle is to generate random numbers in large batches rather than one at a time, reducing memory allocation overhead and improving cache locality.

Complex Distribution Sampling

The Problem: Generating random numbers from non-uniform distributions (normal, exponential, etc.) can be computationally expensive, especially with naive algorithms.

The Solution: Use optimized algorithms and specialized libraries.

For normal distributions, replace the naive Box-Muller transform with faster, built-in methods like the Ziggurat algorithm:

// Instead of slower Box-Muller
double u1 = random.nextDouble();
double u2 = random.nextDouble();
double normal = Math.sqrt(-2 * Math.log(u1)) * Math.cos(2 * Math.PI * u2);

// Use optimized implementations
ThreadLocalRandom tlr = ThreadLocalRandom.current();
double optimizedNormal = tlr.nextGaussian(); // Uses an optimized algorithm internally

For discrete distributions, the alias method provides O(1) sampling after an initial O(n) preprocessing step. Libraries abstract this complexity away:

// Apache Commons Math provides efficient implementations
EnumeratedDistribution<String> distribution = new EnumeratedDistribution<>(
    Arrays.asList(
        new Pair<>("A", 0.3),
        new Pair<>("B", 0.5),
        new Pair<>("C", 0.2)
    )
);
String sample = distribution.sample();

Libraries like Apache Commons Math, Colt (for Java), or NumPy (for Python) provide battle-tested implementations of these algorithms.

I/O-Bound Systems with Randomized Operations

The Problem: Even in I/O-bound systems, RNG can become a bottleneck if it’s called frequently for randomized operations like load balancing, cache eviction, or A/B testing.

The Solution: Decouple RNG generation from critical paths and use appropriate algorithms.

// Pre-generate random data for I/O operations
List<Integer> randomPorts = new ArrayList<>();
ThreadLocalRandom tlr = ThreadLocalRandom.current();
for (int i = 0; i < 1000; i++) {
    randomPorts.add(tlr.nextInt(8000, 9000));
}

// Use pre-generated values in I/O operations
int nextPort = randomPorts.get(requestCount % randomPorts.size());

For testing and fuzzing scenarios, consider using deterministic randomness by fixing the seed:

// Use the same seed for reproducible "random" behavior
Random testRandom = new Random(12345L);
// This makes debugging easier while maintaining randomized testing coverage

Benchmarking and Profiling RNG Performance

When optimizing RNG performance, measurement is crucial. Here’s a simple, fair benchmark framework for Java that includes a warm-up phase to ensure JIT compilation has occurred.

import java.security.SecureRandom;
import java.util.Random;
import java.util.concurrent.ThreadLocalRandom;
import java.util.function.Supplier;

public class RNGBenchmark {
    private static final int ITERATIONS = 10_000_000;

    public static void benchmark(String name, Supplier<Integer> rng) {
        long start = System.nanoTime();
        for (int i = 0; i < ITERATIONS; i++) {
            // The get() call invokes the specific RNG method
            rng.get();
        }
        long end = System.nanoTime();
        System.out.printf("%-20s: %.2f ns/op%n", name, (end - start) / (double) ITERATIONS);
    }

    public static void main(String[] args) {
        Random random = new Random();
        ThreadLocalRandom tlr = ThreadLocalRandom.current();
        SecureRandom secureRandom = new SecureRandom(); // Instantiate ONCE!

        System.out.println("--- Benchmarking RNG performance ---");
        // Warm-up phase to allow JIT compilation
        benchmark("Warm-up (TLR)", tlr::nextInt);
        System.out.println("--- Main Benchmark ---");

        benchmark("java.util.Random", random::nextInt);
        benchmark("ThreadLocalRandom", tlr::nextInt);
        // Note: Even when instantiated once, SecureRandom is significantly slower.
        benchmark("SecureRandom", secureRandom::nextInt);
    }
}

This benchmark will help you quantify the impact of your optimizations and choose the right PRNG for your use case.

Conclusion

The key takeaway is that there is no one-size-fits-all RNG. Choose your generator based on your specific requirements: security needs, threading model, performance targets, and statistical quality. A game engine has different needs than a cryptocurrency wallet, and your RNG strategy must reflect that.