Back in around 2006 I was doing GPGPU regex and string matching and decided to google around for parallel string matching algorithms. I spent a good chunk of time scrolling around in the Vishkin's algorithm implementation and wondering why it all felt so familiar; it was only when I scrolled back to the top of the file that I realized it was familiar because I wrote it.
A fine example of why you should comment your code, as the person who reads it in 10 years from now will be a stranger, even if that person is you.
This is great! I'm really inspired by the work CMU does on parallelism. They have a parallel programming course[0] that results in some really impressive final projects [1]. I also hear that CMU takes a "parallel-first" approach to teaching algorithms and data structures, but I have not been able to find out exactly how they do that.
Animations link appears to be broken. After doing some way back machine snooping, looks like it hasn't been up since about 2000[0]. You can access the legacy java applet animations here[1]
These algorithms are written in NESL, which is perhaps the cleanest example of the oft-mentioned theory that parallel programming becomes simple in a functional setting. It really is remarkable how flexible it is. Unfortunately, I'm not sure NESL ever managed to run particularly fast in practice.
As someone who has done a lot of parallel programming, I really can't recommend Java 8 streams enough. They have a bit of overhead, however, they are incredibly easy to use and are extremely expressive.
I've done some tinkering with streams, and I was initially very excited. They do come with some frustrating limitations. Foremost in my mind: Concatenation of streams is fairly straightforward, but how do I perform a parallel join (zip?) of multiple streams?
In other words, given [1,2,3] and ["A","B","C"], how do I map over [[1,"A"],[2,"B"],[3,"C"]]?
AFAIK this isn't possible yet in a straightforward way, and it boils down to limitations of the type system (lack of tuples resp. value types in general), and the (understandable) refusal of many to do it in way that's hacky and potentially slow.
In the talk "Clojure Concurrency" [1], Rich Hickey demands that everyone in the room read "Java Concurrency in Practice" [2]. "It will scare the crap out of you."
Ah ok. I was confused by the reponse to slaymaker1907 who recommended Streams directly, as it didn't seem to address the Stream API. I guess many of the challenges of concurrent computing still applies here.
Didn't say that, I said that we rarely need parallelization for raw number crunching. Developers use parallelization for coordinating expensive IO way more often, and Java 8 streams solve almost nothing for that. Still need to know and worry about other Java concurrency primitives like volatiles, monitors, thread pools, etc. and all their pitfalls (race conditions, deadlocks, etc.).
You should still read JCIP, it is still highly relevant in Java-land. Java 8 streams solved almost nothing in terms of concurrency (in fact they probably created more problems than they solved...). You should still be scared of concurrency in general, and particularly in Java. And you should definitely consider a different language with more sane and modern concurrency primitives if you really need concurrency.
The parent might be saying that we already have some good techniques for speeding up raw number crunching in parallel, so it's not as desirable to add yet another.
A fine example of why you should comment your code, as the person who reads it in 10 years from now will be a stranger, even if that person is you.