Software informs the hardware how the hardware should work, software needs to adapt how the hardware likes to work, if software informs the hardware in a way that isn't effective it will not work good.
A graphics driver packs GPU data before it sends it to the gpu. Sending data to the video card is a high latency operation and if you send many small packets it will be much slower compared to sending one big packet. This is much more important on Core 2 compared to Phenom because the FSB likes long trains of data. Core 2 only have one way where data is sent or read from other hardware too. If the software wasn't sending data in long trains (leaving gaps for other data to travel) using the FSB but instead splits the data in many small packets it would be able to the same amount of data. When the FSB is moving data in different directions it also slows down.
If it also need to move memory the traffic increases.
Mouse data is also sent using the FSB on Core 2.
It could be that Core 2 isn't that exact compared to Phenom because Phenom has more capacity moving data to and from the CPU, I/O data doesn't compete with memory traffic.
When I have done heavy work on Intel this is the problem, the speed is often ok. Things get done as fast or maybe faster compared to Phenom but it is trouble to work with other applications when some applications is working hard and the first that starts to behave strange is the mouse. If I start one application that stresses the CPU only it isn't a problem. Thread switching works ok and no problem with data sent to and from the CPU. But if the traffic to and from the CPU increases the mouse will not move as it used to do.
I think that games uses the DirectX driver to read mouse data (don't think they use WIN32 events or API's, haven't read about it so don't know), it also uses the driver to send data to the GPU. It could be that if one have done this badly for that type of hardware the result is that the game will not work well.
Bookmarks