> Both are largely unapproachable on GPUs and ASICs.
Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2.
However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel cores[1]. You can absolutely have small amounts of fast ram in FPGA and ASICs.
[0] and a good amount of memory/core, a 1080 has ~3MB/core, a 1070 has 4 (they both have 8GB RAM but the 1080 has 2560 CUDA cores versus 1920 for the 1070)
[1] GPUs have very high memory throughput but very high latencies even for caches[2] e.g. on Kepler (a few generations back) the L1 was already 48 cycles, Skylake can go up to L3 in 42 cycles
[2] which are shared by multiple cores and are very very small: from what I've found Pascal has 64KiB of L1 per SM (with each SM grouping 64 CUDA cores) and 4MB of L2 for the entire chip
Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2.
However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel cores[1]. You can absolutely have small amounts of fast ram in FPGA and ASICs.
[0] and a good amount of memory/core, a 1080 has ~3MB/core, a 1070 has 4 (they both have 8GB RAM but the 1080 has 2560 CUDA cores versus 1920 for the 1070)
[1] GPUs have very high memory throughput but very high latencies even for caches[2] e.g. on Kepler (a few generations back) the L1 was already 48 cycles, Skylake can go up to L3 in 42 cycles
[2] which are shared by multiple cores and are very very small: from what I've found Pascal has 64KiB of L1 per SM (with each SM grouping 64 CUDA cores) and 4MB of L2 for the entire chip