How is Ethash compute intensive relative to Cuckoo Cycle?

EDIT: Ethash does 1 SHA3 at the beginning, 1 SHA3 at the end, and 64 rounds of FNV1-32 x 32.

Verification considers the intermediate digest, so really 1 SHA3 to verify.

You do more SHA3 rounds if you don't store the dataset, but this is a memory trap-door (and would require ignoring the mixDigest); the verification cost is still negligible.

In our mining pools, verification of hash values doesn't even account for 1% of of our overall CPU consumption (and this is with Scrypt).

SHA3 is also far more lightweight than SHA2, and much more parallelizable.

EDIT #2: If we want to talk about weaknesses in Ethash, I'm not sure it is FPGA resistant, given many FPGAs have DDR iterfaces on die and the access pattern of Ethash is read-only.

"Compute bound" refers to proof generation (mining), not to verification. It looks like ethash does the following computations per random memory access:

        p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
        newdata = []
        for j in range(MIX_BYTES / HASH_BYTES):
            newdata.extend(dataset_lookup(p + j))
        mix = map(fnv, mix, newdata)

I admit this doesn't look much more involved than Cuckoo's single siphash-2-4, but perhaps we can measure it. How much faster does this run if you leave out the actual memory access. i.e. replace dataset_lookup(p + j) by (p+j)?

In Cuckoo Cycle's case, avoiding the memory lookups reduces runtime by a factor 3.

I'd say the biggest advantage if you take out memory access is not latency (since most of the time latency gets hidden via pipelining), but power consumption.

When developing kernels the amount of times memory is accessed has huge impact on power-efficiency, less on actual computational throughput (especially on GPUs), unless you hit bandwidth limitations (which right now Ethash does).

EDIT: NVM - you're asking about the comparison of FNV1 vs Siphash. I haven't analyzed Siphash but I can say that FNV1 is exactly 5 clock cycles on a modern GPU (4 for a 32 bit multiply and 1 for an XOR).

I had someone run some tests where ethash was accessing only 1KB rather than the whole 1GB of dag, and runtime fell by 40%. So that's roughly the fraction of time spent on memory latency in the single threaded cpu miner. That's less than the 67% measured for Cuckoo Cycle, but still rather high. So I should say that ethash is almost memory-bound, and certainly much more so than other memory oriented hash functions.