Hardware

CUDA, OpenCL and CPU: choosing a backend

OpenPuzzle can coordinate several execution backends, but the backend choice affects compatibility, sustained throughput and operational behavior rather than the probability of an individual key being correct.

CUDA and OpenCL solve the same search problem

For compatible NVIDIA hardware, CUDA provides the native compute path used by cuBitCrack. OpenCL provides a vendor-neutral interface and is useful for compatible AMD and other devices through the available OpenCL runtime. Both receive explicit range boundaries and the same public target from the OpenPuzzle client.

The backend does not change which candidate keys are valid. It changes how quickly a device can enumerate and test them and which tuning profile is appropriate for that device.

Why a local benchmark is necessary

Model names alone are not enough to size work. Driver versions, power limits, thermal conditions, kernel compilation, background workloads and device-specific tuning can materially change sustained speed. OpenPuzzle therefore benchmarks locally and uses measured throughput to estimate a range that fits the target assignment duration.

Sustained speed beats a short peak

A GPU can report an attractive short benchmark and then slow once temperature or power limits settle. Operationally, the useful number is the rate maintained over the assignment. Progress heartbeats provide recent measured speed, allowing the public network statistic to reflect active work rather than a static hardware catalogue.

CPU remains a valid participant

CPU key search is much slower than modern GPUs for this workload, but it remains useful for portability, validation and systems without a supported accelerator. OpenPuzzle’s fairness rule does not exclude slow hardware. Speed affects the amount of work assigned for a target duration, not the participant’s place in a priority queue.

Multiple GPU slots need independent state

When CUDA and OpenCL run concurrently, each slot must retain its own assignment, process identity and recovery path. One device stopping or recovering must not erase the other device’s state. This isolation is especially important after interruption or during safe update handling.

Practical check: openpuzzle doctor validates local engine files, detected hardware, usable backends and runtime state before an assignment is requested.
Related reading: Bitcoin Puzzles background · Methodology · FAQ.

← Back to all research notes