Agreed- however in the (distant) past we've had to do exactly this because of bugs in the driver state caching. I've also seen Cg hitting state changes fairly hard on some platforms- there was an optimisation to prevent this but it used to cause memory leaks. It can be difficult to know exactly what's going on under the hood there and you can't really blame the application developers for this without knowing the specific circumstances.

Absolutely true. My anecdotes above were in regards to very specific hardware so this comment doesn't really change what I'm saying, but it's an important thing to understand in a general sense.

To be fair, you're accusing the dev in question of not optimising for your card when you admit that the card in question was unusual and probably released after the game in question was developed- otherwise you probably would have worked with them to improve their software? It's all well and good to say "they should have known better" (and I've used that line before, so I know how you feel) but if you're the odd man out, it's hard to really blame the dev for not being able to predict how performance would change in the future. Especially if the dev is using some kind of third-party engine or graphics library (eg. Cg) where they don't necessarily have fine control over state changes.

I don't know the details of your case so I won't comment further, but it's worth remembering that there are two sides to every story.

One thing I learned from writing video games is that driver developers often don't know much about real-world performance. ;-) Much of the performance advice we have seen given by GPU teams in the past had zero benefit to game performance and took weeks of developer time to implement and maintain. On the other hand, sometimes you come across a real gem.

Short version: good programmers good, bad programmers bad. Sometimes what is good for one case is not good for another case.

I found SimCity on the iPad to be pretty good actually. Not perfect- it could do with a few minor fixes- but well worth the money and one of the bigger time-wasters for me.

I would think that most C++ programmers consider the lack of GC to be a feature, not a limitation. Speaking for myself, that's one of the major reasons why I prefer C++ over other 'more modern' languages- GC introduces a whole class of potential bugs and limitations that don't exist without it, and encourages the programmer to ignore object life cycle. I'm not saying that GC is all bad, but neither is it clearly better than the alternative for complex programs.

Regarding multithreading, program architecture is far more important than your choice of language. If you design a sensible flow of information through your program, you'll end up with an efficient and (relatively) bug-free result. If you have poor flow, you'll end up with horrible performance and deadlocks. A 'safe' programming language like Java/C# doesn't protect you from this.

You're right that C++ lacks standardised cross-platform libraries; the situation is improving, but slowly. It's not a deal-breaker in many cases but it is a cost that needs to be considered. The same is actually true of the other languages you name to greater or lesser degrees- C# really isn't practically cross-platform in many cases, despite Mono. Java is known for having poor cross-platform UI support. At least they get the lower-level primitives right though.

At the point of download, you have the choice of:

* Downloading it to your photo roll.
* Copying it to the clipboard.
* Emailing it.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

A quick question about this- what happens if you continuously push the end of the bar at the speed of sound in the material? Obviously you can't get a situation where the bar collapses to zero length, but that is the "obvious" outcome from what you describe.

I've always wondered about that one and never bothered to learn.

100 devices per developer, not per app.

This is the first assumption that you'd jump to, but there's no real evidence that it's true. Perhaps the "one game" simply uses more ram than the others, and thus hits a "faulty bit" in one of the ram chips. Perhaps the graphics drivers have an off-by-one condition that causes them to over-read a vertex buffer and into unallocated memory. Even on "identical" machines, this may not crash unless the application's allocations match an exact pattern that causes the bad read to touch an unmapped page. We've seen both of these in practice.

Sure, there are plenty of bugs - pretty much any software has some, and some software more than others, but it's fair to say that the "my machine is fine, it must be the software" mentality leads to some very poor conclusions from time to time, even though it's an understandable position for a user to take.

Yup, we certainly see some of this as well. Loyal users can sometimes be fast to jump on people reporting valid bugs.

Just an anecdote from the other side of the fence, and not saying this is necessarily your case. Certainly not defending Mass Effect, I've never tried the game personally.

We've had numerous users report serious defects in our products over many years, and faced all sorts of threats and insults, only for the fault to be eventually traced to the user's "tried and tested hardware." Each program that you may use exercises different components of your PC in different ways. Sometimes subtle differences can make a massive difference in results; the difference between working fine and not even starting up. Should the developer pay because you have some mildly faulty ram?

We've also seen vastly different behavior from hardware/drivers built to the same spec but sourced from different manufacturers, or from the same manufacturer but over different periods. Sometimes these deviations are within the spec but not covered by reasonable testing; often these deviations are outside the spec completely. Should the developer pay because one or more of your components do not follow the specs, or deviate significantly from what was standard practice at the time the software was developed?

As a user, I have to agree that it sucks when products don't work as advertised. I agree that there should be a mechanism for complaint against any vendor, whether their product be physical or virtual. But I'm not sure that I agree that there should be an absolute right of refund at the user's discretion. That's just open for abuse - whether deliberate or incidental.

I'm also not particularly fond of DRM and yet that would seem to be the only way that a vendor could offer true "returns" of a software-only product.

It's probably worth noting that I'm not claiming that all bugs are the user's fault; but it's certainly not the case that all bugs are the application developer's fault, either.

Moore's law does not describe performance.

He's right though; the user cares about the response time between their action and the final result. They care about the time cost of transferring multiple packets just as much as they care about the time cost for the round trip. To optimize this, you can attack either:

* The round trip time (outside the reach of most users and companies.)
* The number of round trips (may be open to tweaking by predicting which files will be requested as a group, etc.)
* The quantity of data transferred. This tends to have less impact than the others for people on fast connections, but still adds up. For people on slower connections, this may be the largest factor.

Which products were you referring to? I can think of a few of theirs that are a little exxy, but nothing like that much, and most of their products seem quite competitively priced. I can understand that people might want a configuration that Apple doesn't offer - and fair enough if that's you - but if you fall into one of their target markets, they're pretty hard to beat on price.

This doesn't sound correct. As far as I'm aware, overriding the admin password will not grant access to keychain?