^(almost) murphy.de

I partially disagree here. Multi CPU/Core systems are becoming more and more common, it isn't rare to see 4 cores in even home systems, not to talk about commercial grade systems that have more then 100 paralell threads on a single machine. Having a woderful algorithm that runs twice as fast but leaves the other cores idle and in the end still uses more then a few times the execution time to finish isn't a gain either and it isn't the best way either.
The best way of programming fast applications in my eyes is to use the untilities at hand, if you have a few cores to work with leaving them sit and idle is definetly not the best way, brutally making everything concurrent isn't either.

I'd say multi-cores are becoming more common because they stopped making faster processors years ago. We were already at 2 GHz in 2003. Moore's Law was never about performance, but number of transistors. So, concurrency is the only way to keep computational power growing (and it needs to). Still, I mourn this development; it's far more challanging to make concurrent algorithms. All the communication, interation, switching and synchronization is overhead I'd rather save. Also, the hardware isn't nearly up to the CPU speed(s), as always - we're still mainly waiting for HDD and SSDs. Additionally, I personally had meager success in making anything faster by making it concurrent. That said, I hope you're proving me wrong with EPIC.

1

1

1

1

1

1