Garbage collection creates a different class of problems, namely that the performance characteristics of your program become non-deterministic. This is a Big Deal for certain classes of applications such as video games and in particular HFT. Would you like to be the person explaining why the GC caused your program to stall at an inopportune time for 50ms and lost somebody a few million bucks?

Exactly! I plug my Internet cable into my Internet box and it's there on my screen. What's more to know?

If by 90% of today's games you mean 90% of today's facebook games, then yes, I suppose ;). But seriously, are games less technically demanding than they were 10 years ago? Yes. Are you really going to have that much fun trying to play actual modern 3D games on medium low detail settings, no AA, low resolution, at ~30 fps? You might, obviously a lot of people wouldn't, myself included.

Well, kind of... or not really... not in the traditional sense. I can't speak for AMD but in Nvidia architectures those 2000+ "cores" are clumped into very wide (32+) groups which all share a single instruction decoder and all the parts that go around that. Are they really individual "cores" if they all have to execute the exact the exact same instruction in lockstep?

By using arithmetic or range encoding.

I'm afraid you're still an idiot, because "the stuff that turns the driver into a product" should still also be no greater than a few MB tops, even with stupid sounds, images and animations included for the printer status.

Here I go feeding the trolls...

So just so I can get this right, a printer driver is so complex a feat of engineering it is analogous to a skyscraper? A printer driver takes input data in the form of text, fonts, and images, formatting, and translates it into a format compatible with the printer in question. Entire operating systems have been written in less than 1/10th the size of some of HP's modern shipping print drivers. I never said it has to be 254 bytes, but the current level of bloat is absolutely insane and I have no idea how they even reach it. Do you know how many lines of C++ code 500MB compiled and compressed is actually equivalent to? Billions. Literally billions. I just want to understand; Do you actually believe it takes a billion lines of code to transform input document data into a format readable by a laser printer?

Then you should be impressed. If you seriously are a developer who writes printer software for HP you are bad and you should feel bad.

Why, yes I am! I've written home-brew Xbox games that included graphics and animations, sounds and music(<10MB), and reasonably complicated network software that runs as a service on many of my servers at work (<100KB). I've dabbled in writing demo code as well writing a complex synthesizer with DSP effects and tons of music content in 64kb.

If you're actually defending the need to ship printer drivers literally over 500MB I would really love to hear your logic.

The next time you churn your next 500MB printer driver think about programs like this. Think long and hard.

Sigh. Here I go feeding the trolls.

I'm not sure what point you're trying to make here, since MY main point in the rest of this topic was that modern GPUs are mostly limited by memory bandwidth, which makes the development in TFA pretty pointless. You're right! 32GB/s isn't enough to make the most of the computing resources available on a modern GPU! That was my point; How exactly would the GPU accessing main memory directly help? The fastest system RAM currently available in consumer markets in the fastest possible configuration can barely reach 30GB/s. In order for GPUs to confer a computional advantage they need to be doing heavy lifting on GDDR RAM which could deliver over 160GB/s on cards that are over 4 years old.

Yeah, that's about right. I was just quoting from the OP there. An application that was already properly optimized on the CPU generally only sees performance gains of around 10 to 20x in best case scenarios.

Wrong! The GPU is only 100x faster at doing certain problems because of the fast GDDR memory it is attached to which is optimized for very large sequential reads and writes. There are a tiny number of applications that require huge numbers of FLOPs on very small amounts of data (BitCoin mining and password hashing attacks come to mind, but that's about it.)

The "slow interconnect" you're talking about to main memory, PCI Express v3.0 has an effective bandwidth of 32GB/s which actually exceeds the best main memory bandwidth you'd get out of an Ivy Bridge CPU with very fast memory, so no, that's not a bottleneck for bandwidth, though yes, there is some latency there.

I don't know why everyone seems to forget that GPUs aren't just fast because they have a lot of ALUs (TFA included), they are fast because of the highly specialized GDDR memory they are attached to. One would be completely useless without the other. Even the lowly GTX 285 from 4 years ago was pushing 160GB/s for memory bandwidth.

One question they never seem to answer is why bother unifying the memory architecture at all? CPU and GPU memory architectures have always been different for the same reasons that CPUs and GPUs themselves are different; one is designed for fast execution of serial instructions with corresponding random smaller reads and writes to memory, and the other is designed for fast execution of parallel instructions with corresponding contiguous reads and writes that are much larger in size. It seems like you're just going to to ending compromising if you try to shoehorn one onto the other.