That depends? If it's the fault of them using poorly designed libraries that they wrote in the past, it could be a cost/time saving measure, definitely a bad one, but the company could have pushed them down that road. It could be the developer's fault, but that really depends on the timeline they had for doing the work they had to get done. Development doesn't always go the way you want it to. Sometimes that's the developer's fault and sometimes it isn't. It's hard to say without being inside the company and seeing what is going on but, one thing is certain, it's definitely EA (DICE)'s fault as a whole.
I don't dispute that for a second.
I would put winrar/winzip and other compression utilities in the category of workloads that are more easily paralleled than others because of the nature of what they're doing. Once again, this comes down to the workload argument. Archival applications and games are two very different kinds of workloads, it's a lot easier to make something like LZMA2 to run in parallel than something like a game which is incredibly more stateful than something like an algorithm for compression or decompression. This isn't a matter of tools, you could have all the tools in the world but that won't change the nature of some applications and how they need to be implemented. OpenCL doesn't solve all programming issues and it doesn't mysteriously make things that couldn't be run in parallel to suddenly able to be. These tools you talk about enable already parallel applications to scale a lot better and across more compute cores than they did before, it doesn't solve the problem of having to make your workload thread-safe without being detrimental to performance in the first place.
You complain about me nitpicking, but you're pointing out things that require that level of analysis and detail because problems like these aren't as easy to solve as you make them out to be.
One question, have you ever tried to write some OpenCL code and running it on a GPU? Try doing something useful in it if you haven't and you'll understand real quickly why only applications that are mostly parallel code in the first place use OpenCL. I get the impression that you haven't so you shouldn't talk about something if you've never done it. I am, because I have... trust me, it's not intuitive, it's hard to use, and it's only helpful in very selective situations. I would never use it unless I was working with purely numerical data that was tens of gigabytes large or bigger and only if the algorithm I'm implementing is almost completely stateless (or functional if you will). Games (other than the rendering part, which GPUs are already doing,) hardly fit any of those criteria. It's not that developers aren't using OpenCL, it's that they can't or it doesn't make sense to in most real world applications in the consumer market.
I do enjoy listening to you try to say what developers are and are not doing right when you're not in their shoes. Even as a developer I wouldn't presume to think I knew more about another developer's project than they do without even seeing the code itself and having worked with it. So I find it both amusing and disturbing that you feel that you can voice you opinion in such an authoritative way when not even I would make those kinds of claims given my own experience in the subject as I'm a developer professionally and I'm even working on a library that uses multiple threads.
Tell me more about why you're right.
