Looks like rhash(1) is twice as slow as the SHA-2 tools:

$ ls -lh cm-10.2.1-d2spr.zip
-rw-r--r-- 1 aaron aaron 183M May 22 21:56 cm-10.2.1-d2spr.zip
$ time sha256sum cm-10.2.1-d2spr.zip
757c0d65c29fdff36d6083710803dcf313a922d476ac4a8f67c4ab15e22017ea  cm-10.2.1-d2spr.zip
sha256sum cm-10.2.1-d2spr.zip  1.95s user 0.16s system 72% cpu 2.929 total
$ time rhash --sha3-256 cm-10.2.1-d2spr.zip
f375e211b151a248e527f53de3b4a90f7498614674810917f79dcee38e632f8c  cm-10.2.1-d2spr.zip
rhash --sha3-256 cm-10.2.1-d2spr.zip  3.83s user 0.19s system 79% cpu 5.077 total

This is pretty consistent. This is unfortunate, because SHA-3 should be using less cycles per byte per the original Keccak specification. Looks like a patch should be submitted to rhash(1).