I know that Graphics cards are faster at solving algorithms like SHA-256 because of the many builtin processors, but are there Algorithms that take actually longer on a Graphics card than on a modern consumer CPU (Amd/intel)?
This specific situation is a central part of the analysis of password hashing functions. Indeed, for hashing a password, we want a function which is:
slow in a tunable way;
such that the most cost-effective hardware for evaluating many instances of the function is the hardware that the expected defender will use, i.e. a "normal PC".
"Cost" here means actual money. For the attacker, it does not matter whether he will need 10, 100 or 1000 units of whatever hardware he'll use; only the total cost will be necessary. It can be argued that with modern hardware, in particular GPU, the majority of the budget for crunching passwords will be spent on electrical power, not on purchasing the hardware. Therefore, it makes sense to define the cost of the function with regards to the energy consumed by its computation, on both general-purpose CPU, and various GPU.
The bcrypt password hashing function appears to be indeed such a function, that is more expensive (energy-wise) to compute on a GPU than on a CPU. The bcrypt feature that makes it so is that it is organized around an internal 4 kB array of data which is continuously read and modified in a way which is not amenable to shortcuts, and at pseudorandom addresses. GPU are not well-equipped for that; if you try to implement bcrypt on a GPU, you will experience considerable contention for data access, and most of the GPU cores will be stalled at any time (and such a stalled core still consumes power).
The Password Hashing Competition was organized to define new functions that fulfill a larger goal, namely to not only be more CPU-friendly than GPU-friendly, but also to "hold the line" to some extent when facing attackers with FPGA or custom ASIC. The main tool used by most candidates was again RAM, but more of it; the underlying assumption is that modern PC (servers, desktop systems...) contain a thoroughly optimized memory bus that cannot be operated at a substantially lower cost by custom hardware. It is unclear how far that assumption holds.
One of the PHC candidates, called Makwa (which I designed), did not use RAM but modular arithmetics. This is not expected to fare well against FPGA and ASIC, but, for GPU, it appears to behave well: according to my analysis, costs on CPU and GPU appear to be roughly on par for a 2048-bit modulus, and larger moduli benefit the CPU more than the GPU.
To sum up, both bcrypt and Makwa seem to be valid answers to your question, and they do so through quite different means.
Even if a small part of the encryption algorithm can be parallelized e.g 10% and the speedup of this part of the algorithm that benefits from GPU is 20fold then GPU version will appear 10% faster than the CPU version.
Mind that a good implementation on GPU will take advantage from both worlds (CPU+GPU).
So it will be very strange for someone to build a GPU only solver.
A good place to start your search would be a memory hard implementation. The most popular is scrypt. It is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2 or bcrypt. Also the winner of Password Hashing Competition (PHC) is Argon2.
PBKDF2 has one weakness (# of iterations) which makes brute-force attacks using application-specific integrated circuits or graphics processing units relatively cheap. The bcrypt key derivation function requires a larger amount of RAM (but still not tunable separately, i. e. fixed for a given amount of CPU time) and is slightly stronger against such attacks.
So the main advice is to go for Scrypt or Argon2i (better vs all other).
Argon2 was designed to be resistant against brute-force attacks using specialized hardware, such as GPUs, ASICs, or FPGAs. In July 2015, it was announced as the winner of the Password Hashing Competition.
Didnt last long to see a good implementation. Here is a GPU POC for Argon2.
The CUDA implementation can reach about 40-60 GiB/s (divide by time cost * memory cost * 1024 B to get hashes per second) on an NVIDIA Tesla K20X. For comparison, a fast Intel Xeon processor can only reach about 10 GiB/s.
So I dont think there is an algorithm that can run slower on GPU if the solver implementation is programmed using common sense.
A common approach, taken by Ethereum, for instance, is to use algorithms that are memory hard.
While GPU may contain thousands of processors, the amount of memory available does not increase in the same proportion. If the algorithm is such that the memory is absolutely required, this restricts the number of cores that could run efficiently in parallel.
GPUs have slower clock rates than CPUs, but many more threads with the restriction that large groups of threads need to execute the same code.
So an algorithm that is supposed to run faster on a CPU will have linear data dependencies so the GPU can run only a single thread (and all other threads execute NOPs) and use only one lane in the vector — then the lower clock rate takes effect.
You can also further pessimize GPU performance by making the arithmetic operations data dependent. GPU compilers will then try to generate speculative execution for all operations, followed by a
SELECT instruction to use only the result from the winning branch.