FutureChips

> I'm not familiar with the internals of the prefetcher of any CPU at this level

So better not speculate, what you think could be done when you are not familiar with the details typically tends to be a lot harder when you are familiar with the details and are tasked with the implementation. The devil is in the details and there is a very appreciable gap between theory and practice.

Further reading: http://www.futurechips.org/chip-design-for-all/prefetching.html

Note the caution against using lists and trees and an advice to stick to arrays, which are typically accessed sequentially.

> Btw. you can add prefetch instructions in your code manually if you do linked list traversals or similar. In GCC you can use __builtin_prefetch() compiler intrinsic.

And that is exactly the point, if you don't supply the knowledge neither the processor nor the compiler can do this for you. If the processor or the compiler could do this then those __builtin_prefetch calls would not be required.

I think the most dangerous part of C is that many people assume C is perfectly efficient. It's as if C was the "100%" of performance and other languages are converging towards it as they get better.

But I don't see how this is true. Pointer aliasing is the biggest example probably:

http://www.futurechips.org/tips-for-power-coders/how-to-trick-cc-compilers-into-generating-terrible-code.html

And then there is the huge abstraction penalty for things like `qsort()` where C++ is actually way ahead of C.

I'm usually the first to upvote well-written GPGPU articles, but I'm flagging this as spam. See:

http://news.ycombinator.com/submitted?id=iliastsagklis
http://news.ycombinator.com/submitted?id=kioub
http://news.ycombinator.com/submitted?id=javacodegeeks

Not to mention, it's a direct copy of this post (which they've credited; but still it smells like spam): http://www.futurechips.org/chip-design-for-all/cpu-vs-gpgpu.html