Short answer
On one head-to-head case (a 46.8 million cell mesh of a 5.8 GHz patch, stepped 5,000 times, on the same workstation), the RayRF GPU solver ran 68.5x faster than openEMS: 9,843 versus 144 MCell per second, a 25.4 second solve versus 27 minutes 44 seconds. RayRF on the same CPU ran about 4.3x faster.
Speed claims are cheap. A benchmark is only worth reading when both tools do the same work. This is one head-to-head case where RayRF on GPU, RayRF on CPU, and openEMS all solve the identical setup on one machine. These are the same numbers shown on the RayRF benchmarks page.
The numbers
The case is a 5.8 GHz rectangular patch on a 46.8 million cell mesh, stepped 5,000 times, on an RTX 5070 Ti GPU and a Ryzen 9 9950X CPU. Throughput is FDTD cell updates per second, so higher is faster.
Same 46.8M-cell setup, 5,000 timesteps, one workstation. RayRF v1.0.0, openEMS 0.0.36.| Engine | Throughput | Wall-clock | Speedup |
|---|
| RayRF GPU (RTX 5070 Ti) | 9,843 MCell/s | 25.4 s | 68.5x |
| RayRF CPU (Ryzen 9 9950X) | 623 MCell/s | 6 m 17 s | 4.3x |
| openEMS (CPU SSE) | 144 MCell/s | 27 m 44 s | 1.0x (baseline) |
Why this is a fair fight
The two engines build their meshes independently, so the active cell counts differ by 0.46 percent (about 212,000 cells) on the same geometry. openEMS actually has fewer cells here, so if anything the comparison runs slightly against RayRF, which is updating more cells per timestep. Throughput is computed against the cell count of each engine, so the per-engine numbers are directly comparable.
Note
This is one representative case, the 5.8 GHz patch reference, against the openEMS 0.0.36 CPU SSE build. The point is not a single magic multiple, it is the difference between a 25 second answer and a 28 minute one. That gap is what makes an interactive, edit-and-rerun workflow possible.
Speed is only half the story
A fast wrong answer is useless. RayRF is also checked against hardware: the measured-versus-simulated S-parameter comparisons live on the validation page, and the full benchmark setup with the throughput chart is on the benchmarks page. If you want the GUI and the GPU solver in one app instead of a script and a CPU wait, that is what RayRF as an openEMS alternative is for.
Frequently asked questions
How much faster than openEMS is RayRF?
On one head-to-head case (a 46.8 million cell mesh of a 5.8 GHz patch, stepped 5,000 times, same workstation), the RayRF GPU solver ran 68.5x faster than openEMS: 9,843 versus 144 MCell per second, a 25.4 second solve versus 27 minutes 44 seconds. RayRF on the same CPU as openEMS ran about 4.3x faster.
Is the RayRF vs openEMS benchmark a fair comparison?
Both engines solve the identical setup on the same workstation. They mesh independently, so the cell counts differ by 0.46 percent, and openEMS actually has fewer cells, so if anything the comparison runs slightly against RayRF. Throughput is computed against the cell count of each engine, so the numbers are directly comparable.
What hardware and software was used?
AMD Ryzen 9 9950X, NVIDIA RTX 5070 Ti, 32 GB RAM, Windows 11. RayRF v1.0.0 and openEMS 0.0.36 (CPU SSE build). The test case is a 5.8 GHz rectangular patch at 5x mesh scale, 5,000 timesteps.
Where can I see these numbers on the site?
The same run is on the RayRF benchmarks page, with the throughput chart and the full setup table. The blog post and the benchmarks page report identical figures.
Try RayRF on your own design
Draw a board, slide the quality preset, and click Run. 30-day free trial, no card required. Windows and Linux.
Start the free trial