The thing about bcrypt is that despite using small data structures in memory (kilobytes) it reads and writes and rewrites a lot of data into them (megabytes, when choosing common work factors). And the small size of its data structures is still just a bit too big to fit many parallel instances of bcrypt in GPU L2 caches. So it is effectively "memory hard" on GPUs.
Contrast this with scrypt which writes memory (typically megabytes) only once, and a byte is read, on average, only once.
bcrypt and scrypt are both, at the moment, memory hard on GPU, but for different reasons. bcrypt reads/writes many times a small buffer. scrypt reads/writes once a large buffer.
Don't pay too much importance on comparing the hash/sec of these 2 algorithms in this specific benchmark. The configurable work factors influence speed a lot.
One day L2 caches will be big enough and we will see a sudden massive cracking speed improvement for bcrypt. This isn't going to happen anytime soon for scrypt.
Contrast this with scrypt which writes memory (typically megabytes) only once, and a byte is read, on average, only once.
bcrypt and scrypt are both, at the moment, memory hard on GPU, but for different reasons. bcrypt reads/writes many times a small buffer. scrypt reads/writes once a large buffer.
Don't pay too much importance on comparing the hash/sec of these 2 algorithms in this specific benchmark. The configurable work factors influence speed a lot.
One day L2 caches will be big enough and we will see a sudden massive cracking speed improvement for bcrypt. This isn't going to happen anytime soon for scrypt.