Sounds like an ambiguous question. Most algorithms are "arbitrarily expensive". It generally depends on some measure of the data you're putting in. But in case you mean "an arbitrary algorithm", then no, nobody knows how to do that. But it appears that the most useful things people actually want to do lie somewhere in the middle: not trivial to parallelize but also not exactly impossible.
Just to be clear, I meant what I wrote: an arbitrary expensive algorithm, i.e., solving the general case.
As for "most useful things people actually want to do", it seems to me that a lot of relatively computationally expensive software still isn't using lots of cores where they're available in practice today.
One significant example is computer games. Since the advent of GPUs with effectively hundreds or thousands of parallel computations available, rendering hasn't been the bottleneck it once was. Today the bottleneck might instead be the game control logic that runs on a CPU, and is often still either single-core or divided among at most a small, fixed number of cores doing different tasks.
Another common real world example is graphics and image processing software. You'd think there might be a lot of natural data parallelism to exploit, but software in this area has made relatively little use of algorithms that scale to arbitrary numbers of cores so far.
A third example would be real-time processing, say operations on high speed network traffic. In this case you can sometimes dispatch different packets to different cores to process them in parallel, but the amount of processing you can do on any given packet might well be limited by the speed of a single core, because the overheads for cache misses or inter-core communications are prohibitive. If your processing needs to consider more than one packet at once, so you can't just spray packets at different cores as they arrive, then this can become a very significant real world bottleneck.
This isn't to say that none of these problems will ever be solved as we develop more understanding and better tools, but even in 2016 the state of the art is far from using as many cores as we have available efficiently for a lot of real world use cases. Manual parallelisation often has architecture-level implications and few development teams have the experience and foresight to get it right consistently with today's programming tools. Automatic optimisation to exploit data parallelism is an interesting research field but still in its infancy, and many mainstream programming languages have far from ideal semantics for such optimisations because of aliasing issues and the like. Either or probably both of these areas will have to advance considerably before we can assume that scaling out into more cores is generally going to give better performance than scaling up with faster CPUs and related hardware architecture.
