I wonder how a language/platform like Erlang/Beam VM, with its 100s of thousands/millions of concurrent processes can be utilized for speeding up deciphering/key search operations.
The math operations for each process would have to be made really fast using C libraries or custom assembly code.
Other concurrent languages/libraries would offer the same benefits I suppose.
I guess the same question can be asked of operations on current generation of GPUs.
For computation-bound processes, having more than one thread per CPU just means you pay task-switching fees unnecessarily.
In fact, "I'm just starting with Erlang/Haskell/Go and I wanted to play with parallelization so I took the first 100 million integers and spawned a thread to add each individual pair together in a distributed fashion and it's ten thousand times slower than just using a C loop, WTF?" is a very popular post on the relevant language forums. In that situation what happens is because the "payload" of each thread is a single machine-language instruction (give or take loading and saving to memory), all you see is the overhead of starting, stopping, and joining threads. (Or processes or greenlets or whatever.)
Key search is embarrassingly parallel, which is basically a term of art that means "it's so easy anything works".
Highly unlikely to be helpful if good randomness is used for key generation; the security parameters of most encryption schemes means that with the fastest known algorithms, you can't break crypto without exhausting the known energy content of the universe =)
