Four benchmark suites on one machine: desktop frame rates read straight off
live captures, every AEAD cipher this OpenSSL build ships, thirteen compression
algorithms across three corpora, and software versus fixed-function video
encoding. Every number was measured on the system listed below, and the method
is stated alongside each table so the figures can be reproduced.
GLDoze native Wayland
wlroots DRM/KMS compositor · no X11 in the render path
Capture resolution
2560 × 1440
16:9 · every shot is a native full-desktop frame
Frame limiting
VSync off · uncapped
compositor rate limiting disabled for the run
Results
Ranked by the frame rate reported by the performance HUD. The overlay gauge
shows the same measurement rounded for display, so both readings from each
capture are listed side by side.
Frame rates as read from the eight captures, fastest first.
Application
HUD FPS
Overlay FPS
GPU frame
CPU frame
Terminal
2281.202
2282.4
0.07 ms
0.31 ms
GLTop system monitor
2249.734
2251.7
0.07 ms
0.33 ms
TechLobby
2215.740
2225.2
0.23 ms
0.28 ms
GLAI agent console
1856.803
1861.9
0.20 ms
0.26 ms
GLDeck media player
1801.614
1802.4
0.14 ms
0.70 ms
GLDoze Browser (CEF)
1043.133
1042.8
0.21 ms
0.26 ms
GLService Manager
402.166
402.2
0.10 ms
0.30 ms
GLSync file synchroniser
389.223
388.3
0.24 ms
0.29 ms
Spread across the set: 389.2 FPS at the dense end (GLSync, 71 comparison rows)
to 2281.2 FPS at the light end (Terminal). All eight sit far above display
refresh because VSync and compositor rate limiting were off for the run.
Numbers are as captured — they are a snapshot of one session, not a
controlled multi-run average.
The captures
Each thumbnail carries its measured frame rate. Click any image to open it
full size, where the overlay gauge and the performance HUD are both legible.
Every AEAD cipher this OpenSSL 3.5.7 build exposes, plus GLDoze's own vendored
AEGIS-128L and AEGIS-256. Throughput is raw symmetric encrypt/decrypt on a
16 KiB buffer, no key derivation, no disk.
Encrypt throughput for every AEAD cipher in the set. The axis is logarithmic because the range spans 196× — on a linear axis the software-only ciphers would be invisible. Exact figures are in the table below.
1 thread12 threadshover any bar for the exact figure
AEAD throughput in MB/s (16 KiB buffer), fastest first. 1 thread
measures one core; 12 threads saturates all 6 cores / 12 threads.
Cipher
Encrypt 1T
Decrypt 1T
Encrypt 12T
Decrypt 12T
1. aes-128-gcm
14,801.8
13,951.5
90,868.0
83,567.4
2. aes-192-gcm
14,111.1
13,334.1
85,451.1
79,259.5
3. aes-256-gcm
13,276.8
12,695.3
81,095.3
75,106.3
4. aes-128-ocb
9,579.6
8,642.5
54,545.9
50,692.2
5. aes-192-ocb
8,317.9
7,749.4
48,039.2
45,349.3
6. aes-256-ocb
7,113.8
6,886.5
43,093.3
41,019.7
7. chacha20-poly1305
5,289.1
5,247.4
33,422.8
33,468.7
8. aes-128-ccm
2,065.6
2,045.4
22,601.9
22,256.8
9. aes-192-ccm
1,756.9
1,729.6
19,240.1
18,956.1
10. aes-256-ccm
1,528.8
1,511.7
16,516.6
16,360.8
11. aes-128-siv
1,479.8
1,473.4
13,362.6
13,520.2
12. aes-192-siv
1,291.7
1,265.8
11,687.4
11,916.3
13. aes-256-siv
1,149.4
1,132.2
10,545.1
10,680.0
14. aes-128-gcm-siv
498.3
505.3
3,950.5
3,883.9
15. aes-192-gcm-siv
495.2
493.9
3,877.1
3,778.3
16. aes-256-gcm-siv
467.7
466.5
3,783.9
3,707.9
17. aria-128-gcm
195.5
193.7
1,528.0
1,525.5
18. aria-192-gcm
166.7
170.8
1,331.9
1,329.5
19. sm4-gcm
161.2
161.9
1,483.0
1,476.3
20. aegis-128l (soft)
151.7
150.8
863.9
887.4
21. aria-256-gcm
148.8
150.5
1,184.6
1,185.8
22. aegis-256 (soft)
103.4
81.7
588.0
536.7
23. aria-128-ccm
98.9
97.7
775.6
778.5
24. aria-192-ccm
85.4
83.8
673.2
677.1
25. sm4-ccm
81.0
79.6
735.5
747.5
26. aria-256-ccm
75.7
75.0
598.5
599.0
26 ciphers, 104 measurements.
Fastest is aes-128-gcm at 14,801.8 MB/s single-threaded;
slowest is aria-256-ccm at 75.7 MB/s — a
196× spread across the set.
AES-GCM and AES-OCB ride AES-NI and lead outright; ChaCha20-Poly1305 is the
fastest cipher without AES-NI. ARIA, SM4 and the software-only AEGIS builds are
one to two orders of magnitude behind the hardware AES paths.
Method. The 24 OpenSSL ciphers come from
openssl speed -evp (2 s, wall-clock, 16384-byte buffer,
-decrypt for the decrypt pass, -multi 12 for the 12-thread
pass). AEGIS has no OpenSSL provider in this build, so it was measured with a
custom per-message harness calling GLDoze's libgldoze-aegis.so.
The two methods were cross-validated on the 56 rows they share:
median agreement 7.4%, worst 18.4% — the residual is per-message setup
cost, which matters most on the very fastest ciphers.
AEGIS note: GLDoze ships the portable soft implementation
(software AES, no AES-NI) because Debian's OpenSSL has no AEGIS at all. The
figure is honest for that module — it is not an AEGIS-with-hardware number.
Compression algorithms
13 compressors across 87 level configurations and three corpora
chosen to span the entropy range — because a compressor's ranking
depends entirely on what you feed it.
The classic compression trade-off: how fast each configuration compresses against how much it saves. Better is down and to the right — the bottom-right corner is fast and small. Anything at or above 1.00 grows the input instead of shrinking it.
Real mixed contentHighly repetitiveHigh entropyhover any point for the level and both speeds
Winners per corpus.
Corpus
Fastest compression
Best ratio
Fastest decompression
Real mixed content (90.7 MB of project source text)
lz4 1 — 1,636.0 MB/s
xz 9e — 0.0379
lz4 9 — 1,902.5 MB/s
Highly repetitive synthetic data (64 MB)
lzo1x 1 — 13,874.1 MB/s
brotli 4 — 0.0000
lzo1x 1 — 4,127.7 MB/s
High-entropy data (64 MB, essentially incompressible)
snappy default — 3,345.7 MB/s
brotli 4 — 1.0000
lzo1x 1 — 3,724.5 MB/s
The twelve fastest decompression runs on the real mixed corpus, linear scale. Decompression matters more than compression for most workloads, and the top of this list is dominated by lz4, zstd and libdeflate.
Both directions of every configuration on one plot. Points above the diagonal decompress faster than they compress, which is the normal case — 81 of 87 do. A configuration that sits up and to the right is fast in both directions; the top-left corner (slow to compress, fast to release) is where heavily-tuned archival levels land.
Real mixed contentHighly repetitiveHigh entropyhover for ratio and both speeds
Real mixed content (90.7 MB of project source text)
Real mixed content — compress throughput for all 29 configurations, fastest first, in the same order as the table below. This is the corpus that behaves like everyday data: lz4 races ahead on speed while the xz and brotli levels trade speed for the tightest ratio.
29 configurations, sorted by compress speed. Ratio is
compressed / original (lower is better).
Algorithm
Ratio
Space saved
Compress MB/s
Decompress MB/s
lz4 1
0.3809
61.9%
1,636.0
1,816.9
snappy default
0.3771
62.3%
649.4
935.2
lzo1x 1
0.3809
61.9%
605.1
578.3
lzop 1
0.3851
61.5%
491.6
498.5
lzf default
0.3820
61.8%
426.5
579.3
zstd 1
0.2712
72.9%
375.1
1,201.0
lz4 9
0.2836
71.6%
318.0
1,902.5
libdeflate 1
0.2656
73.4%
302.8
1,107.0
brotli 4
0.0496
95.0%
287.3
856.0
zstd 3
0.2401
76.0%
257.2
1,072.9
brotli 6
0.0443
95.6%
148.3
894.3
zlib 1
0.2902
71.0%
143.9
377.7
libdeflate 6
0.2371
76.3%
128.0
1,185.4
gzip 1
0.2901
71.0%
115.6
219.8
libdeflate 9
0.2347
76.5%
57.9
1,123.6
lzo2a 999
0.3014
69.9%
50.0
533.5
zlib 6
0.2364
76.4%
49.5
423.0
gzip 6
0.2364
76.4%
44.1
245.1
zlib 9
0.2353
76.5%
27.1
426.4
gzip 9
0.2352
76.5%
24.5
247.5
bzip2 1
0.2250
77.5%
20.2
62.0
bzip2 9
0.1973
80.3%
18.0
51.2
zstd 22
0.0399
96.0%
17.5
1,573.9
lzop 9
0.2725
72.7%
15.2
554.4
zstd 19
0.0399
96.0%
12.8
1,764.0
libdeflate 12
0.2270
77.3%
6.7
1,145.4
xz 6
0.0379
96.2%
3.9
678.8
brotli 11
0.0382
96.2%
3.5
820.4
xz 9e
0.0379
96.2%
3.4
587.4
Highly repetitive synthetic data (64 MB)
Highly repetitive data — a different picture entirely. Throughput runs three orders of magnitude higher than on real content because almost every byte is redundant, and the axis is logarithmic to fit it.
29 configurations, sorted by compress speed. Ratio is
compressed / original (lower is better).
Algorithm
Ratio
Space saved
Compress MB/s
Decompress MB/s
lzo1x 1
0.0065
99.4%
13,874.1
4,127.7
snappy default
0.0483
95.2%
10,500.5
2,480.8
zstd 1
0.0001
100.0%
3,719.7
3,228.9
lzf default
0.0130
98.7%
2,922.2
3,586.6
lzop 1
0.0068
99.3%
2,377.9
2,236.5
lz4 1
0.0046
99.5%
2,314.8
2,725.2
zstd 3
0.0001
100.0%
2,173.5
3,340.8
libdeflate 1
0.0037
99.6%
1,090.6
3,540.1
brotli 4
0.0000
100.0%
991.3
1,095.9
brotli 6
0.0000
100.0%
955.7
1,063.3
libdeflate 6
0.0035
99.6%
822.3
3,986.3
zlib 1
0.0077
99.2%
814.9
1,883.8
libdeflate 9
0.0035
99.7%
784.1
3,803.9
zstd 19
0.0001
100.0%
562.1
2,927.0
zlib 6
0.0034
99.7%
421.3
1,886.1
gzip 1
0.0077
99.2%
416.4
496.0
zlib 9
0.0034
99.7%
411.4
1,945.2
lz4 9
0.0041
99.6%
331.8
3,009.6
gzip 6
0.0034
99.7%
319.9
428.9
gzip 9
0.0034
99.7%
312.8
431.1
lzo2a 999
0.0050
99.5%
238.6
2,264.6
lzop 9
0.0058
99.4%
233.4
2,182.7
zstd 22
0.0001
100.0%
218.4
1,778.5
xz 6
0.0002
100.0%
91.9
1,482.4
libdeflate 12
0.0035
99.7%
52.8
3,618.5
xz 9e
0.0001
100.0%
39.2
1,695.5
brotli 11
0.0001
100.0%
11.1
1,075.7
bzip2 1
0.0030
99.7%
8.6
188.8
bzip2 9
0.0004
100.0%
4.9
62.3
High-entropy data (64 MB, essentially incompressible)
High entropy data — essentially incompressible. Speeds span a wide range but the ratio chart above shows why it barely matters: on this input almost every configuration returns the data at its original size or larger.
29 configurations, sorted by compress speed. Ratio is
compressed / original (lower is better).
Algorithm
Ratio
Space saved
Compress MB/s
Decompress MB/s
snappy default
1.0000
-0.0%
3,345.7
2,682.6
lzo1x 1
1.0039
-0.4%
3,107.3
3,724.5
lz4 1
1.0000
-0.0%
1,710.2
1,950.1
lzop 1
1.0000
-0.0%
1,678.1
1,722.9
zstd 1
1.0000
-0.0%
1,421.6
2,442.0
zstd 3
1.0000
-0.0%
1,182.9
2,545.2
lzf default
1.0310
-3.1%
343.7
2,218.6
lz4 9
1.0000
-0.0%
304.1
1,969.3
brotli 4
1.0000
-0.0%
227.3
1,902.7
libdeflate 1
1.0001
-0.0%
167.0
3,722.7
libdeflate 9
1.0001
-0.0%
117.4
3,677.4
libdeflate 6
1.0001
-0.0%
116.7
3,420.8
brotli 6
1.0000
-0.0%
101.7
1,776.0
zlib 1
1.0003
-0.0%
63.1
1,865.0
zlib 9
1.0003
-0.0%
61.6
1,869.5
zlib 6
1.0003
-0.0%
61.0
1,915.3
lzo2a 999
1.1216
-12.2%
60.7
1,036.2
libdeflate 12
1.0001
-0.0%
53.2
3,491.3
gzip 1
1.0002
-0.0%
51.4
278.3
gzip 6
1.0002
-0.0%
48.0
275.0
gzip 9
1.0002
-0.0%
47.7
275.3
lzop 9
1.0000
-0.0%
21.8
1,721.8
bzip2 1
1.0080
-0.8%
14.5
31.7
bzip2 9
1.0044
-0.4%
13.8
24.6
zstd 22
1.0000
-0.0%
5.7
1,736.7
zstd 19
1.0000
-0.0%
4.7
2,475.6
xz 6
1.0001
-0.0%
3.0
1,973.2
xz 9e
1.0001
-0.0%
2.7
1,343.3
brotli 11
1.0000
-0.0%
0.9
1,616.7
Method. Single-threaded throughout (zstd -T1,
xz -T1, brotli is single-threaded by design) so the table compares
algorithms, not thread pools. Best of three runs per cell. CLI tools timed with
wall clock; library-backed compressors (snappy, libdeflate, lzo, lzf, zlib) timed
with a C++ harness excluding file I/O. Every cell was round-trip verified —
output must decompress back to the exact original before the number is published.
Video encode — CPU vs Intel Arc A750
One 10-second lossless clip, 1920×804 at 23.976 fps (240 frames),
encoded by every software encoder FFmpeg 7.1.5 ships, then by the Arc A750's
fixed-function blocks over VA-API and QSV. Quality is PSNR/SSIM against the
same lossless source, so the two tables are directly comparable.
Every encoder in the video benchmark on one axis, hardware and software side by side. The seven hardware paths occupy the top of the chart as a block; the fastest software encoder reaches the same region, the rest fall away sharply.
CPU, software (14)GPU, fixed-function (7)hover for quality
Speed against fidelity. The upper-right corner is what you want, and it is where the Arc A750 paths sit: hardware encodes at 144–174 fps while scoring 43–48 dB, a region only a couple of software encoders approach and none match on both axes at once.
CPU, softwareGPU, fixed-functionffv1 omitted: lossless, so PSNR is infinite
Software encoders (CPU, 12 threads)
14 configurations, sorted by frames per second.
Encoder
FPS
Speed
PSNR
SSIM
Size
mpeg4 default
170.1
7.09×
37.48 dB
0.9285
1,430 KiB
libx264 veryfast CRF23
138.8
5.79×
46.25 dB
0.9885
1,775 KiB
ffv1 level3 (lossless)
104.8
4.37×
∞ dB
1.0000
91,679 KiB
libsvtav1 preset8 CRF32
95.9
4.00×
47.35 dB
0.9905
1,220 KiB
libxvid default
79.7
3.32×
37.96 dB
0.9399
1,643 KiB
libx264 medium CRF23
78.9
3.29×
47.85 dB
0.9910
2,210 KiB
libsvtav1 preset6 CRF32
56.9
2.37×
47.94 dB
0.9915
1,109 KiB
libx265 fast CRF28
54.6
2.28×
45.46 dB
0.9860
828 KiB
libx265 medium CRF28
52.4
2.19×
45.93 dB
0.9872
822 KiB
libopenh264 default
50.2
2.09×
43.73 dB
0.9807
2,329 KiB
libvpx VP8 2M
23.8
0.99×
45.65 dB
0.9854
2,224 KiB
libaom-av1 CRF33 cpu-used6
18.2
0.76×
47.33 dB
0.9905
879 KiB
libvpx-vp9 CRF32
12.7
0.53×
46.95 dB
0.9891
1,282 KiB
libtheora default (round-trip failed)
4.6
0.19×
25.60 dB
0.8580
307 KiB
Hardware encoders (Intel Arc A750)
7 configurations, sorted by frames per second.
AV1, H.265, H.264 and VP9 all encode in fixed-function hardware; the CPU is
only feeding frames.
Encoder
FPS
Speed
PSNR
SSIM
Size
H.264 QSV — QSV
173.9
7.25×
47.22 dB
0.9898
2,029 KiB
H.265 QSV — QSV
172.5
7.20×
45.66 dB
0.9862
908 KiB
H.265 VA-API — VAAPI
171.8
7.17×
45.09 dB
0.9843
861 KiB
H.264 VA-API — VAAPI
171.8
7.16×
46.90 dB
0.9889
1,811 KiB
AV1 VA-API — VAAPI
171.6
7.16×
47.88 dB
0.9909
1,830 KiB
AV1 QSV — QSV
171.3
7.14×
43.43 dB
0.9805
558 KiB
VP9 VA-API — VAAPI
144.2
6.01×
38.64 dB
0.9506
607 KiB
Same codec: hardware against software
Each Arc A750 path against the closest software encoder for the same codec — 1.25× to 11.4× faster, with the pair and both quality scores on hover. Rate control differs between APIs, so these are speed ratios at broadly comparable quality rather than at identical settings.
Each row pairs the Arc A750 path with the nearest software encoder for
the same codec, so the comparison is like for like. Speedup is
hardware fps divided by software fps.
Codec
Hardware encoder
HW fps
HW PSNR
Software encoder
SW fps
SW PSNR
Speedup
H.264
H.264 QSV
173.9
47.22
libx264 veryfast CRF23
138.8
46.25
1.25×
H.264
H.264 VA-API
171.8
46.90
libx264 medium CRF23
78.9
47.85
2.18×
H.265
H.265 VA-API
171.8
45.09
libx265 fast CRF28
54.6
45.46
3.15×
H.265
H.265 QSV
172.5
45.66
libx265 medium CRF28
52.4
45.93
3.29×
AV1
AV1 VA-API
171.6
47.88
libsvtav1 preset8 CRF32
95.9
47.35
1.79×
AV1
AV1 QSV
171.3
43.43
libsvtav1 preset6 CRF32
56.9
47.94
3.01×
VP9
VP9 VA-API
144.2
38.64
libvpx-vp9 CRF32
12.7
46.95
11.40×
Matched codec against codec, the Arc A750 wins every pair —
between 1.25× (H.264 over QSV versus
libx264 veryfast) and 11.4× (VP9 versus
libvpx-vp9) the software encoder's speed. For H.264 it wins on quality as well
as speed: 47.22 dB at 173.9 fps against 46.25 dB at
138.8 fps. AV1 is the standout — the A750 encodes it as fast as
H.264, and beats SVT-AV1 on both counts. All seven working hardware paths clear
144.2 fps, between 6.0× and 7.3× real time.
Rate control differs by path (VA-API -qp, QSV
-global_quality, software CRF), so quality points are broadly
comparable rather than exactly matched — read PSNR alongside speed instead
of assuming equal settings. The fastest software encoder overall,
mpeg4 at 170.1 fps, is a 1998-era codec scoring 37.48 dB;
it is not comparable to hardware H.264/AV1 quality and is not what the table
above measures.
Not measured: VP9 over QSV — the driver refuses VP9 encode over QSV on
this hardware, so it is published as a genuine failure rather than omitted.
Method. Source clip derived from a real film with
ffmpeg -ss 600 -t 10 -an -c:v ffv1 -level 3 (lossless, so PSNR
measures encode loss only; sha256 525e5259…0488). Resolution
is deliberately left at the native 1920×804 rather than padded to
1920×1080 — letterbox bars compress trivially and would flatter every
encoder. Hardware rows use -init_hw_device vaapi with
hwupload, or the QSV path; -hwaccel none on the software
table guarantees no silent hardware fallback. Quality is measured in a separate
pass with positional frame alignment forced, because FFmpeg's default
psnr/ssim framesync mispairs frames when the reference
PTS is millisecond-quantised. Timings were taken with the machine idle —
back-to-back repeats agreed within 0.1–2.0%.
GLDoze
