The stagnation in desktop single-core performance is taking a toll on my productivity as software continues to bloat. Yes, I have a massive number of cores in my desktop workstation, but most are idle at any given moment. With CPU-wasteful single-threaded software, there are far too many applications that routinely fail to keep up with my input.
I know it's popular to advise new programmers to avoid concurrency because it's a "hard problem," but the wasted cores of my CPU keep screaming for something to do. They yell: "It's a shame so few people write multithreaded applications! Alas, back to sleep for me."
Well, why don't you learn a concurrent language like Go, CUDA, or OpenCL and do something about that?
From my vantage point, I remain amazed that people have fled concurrent programming in an age where the hardware for doing so has not only thrived, but which may also be the only path forward from here.
I write plenty of multithreaded code of my own. What I am grieving is our CS education teaching new programmers that they should avoid concurrency because it's "too hard." I don't have time to make Thunderbird use more CPU cores so that its user interface doesn't block at times.
Go isn't comparable to CUDA or OpenCL in terms of parallelism, which is what matters here. Go doesn't even have SIMD available without writing assembly.
The stagnation in desktop single-core performance is taking a toll on my productivity as software continues to bloat. Yes, I have a massive number of cores in my desktop workstation, but most are idle at any given moment. With CPU-wasteful single-threaded software, there are far too many applications that routinely fail to keep up with my input.
I know it's popular to advise new programmers to avoid concurrency because it's a "hard problem," but the wasted cores of my CPU keep screaming for something to do. They yell: "It's a shame so few people write multithreaded applications! Alas, back to sleep for me."