Intel Core 2 Duo E4400:
Sometimes 4xxx Doesn't Mean Low Performance

Audio Encoding

An "olde" test group which nearly lost its importance today due to high result predictability.

Video Encoding

And again E6300 scores 104 points. It just can't break away from this value...

Games

Both processors were not perfectly scalable here. Even the E4400 rolled back from its usual 108-110 range down to 106 points. Well, games are more sensitive to GPU than to CPU, as we know.

Total score

The total score doesn't tell us any news. Essentially, in all benchmarks except one the game was the same, so the final result was rather predictable.

Supposed power consumption

And this is more interesting already. It seems that Core 2 Duo E6300 didn't get away with VT support and faster bus: its idle power consumption is much higher than that of E4300/4400. Speaking of 12W of the faster E4400 vs. 13W of the slower E4300, we shouldn't forget there are measurement errors. And it's not exactly CPU power consumption that we measure, as well...

Conclusions

As we have mentioned in the beginning, the competition of faster bus and higher clock rate is rather predictable, and within a single architecture the latter wins. But we still had some hopes that the lag would be slight... Alas, we can't say 4% is slight in the value CPU price segment, where buyers count money well, and the choice is dictated by price. If Core 2 Duo E4400 becomes more cheaper (and, judging by the product, this is actually possible), then E6300 would only be recommended for those in dire need of virtualization. For all other customers there would be no sense in overpaying for a 1066 MHz FSB, which is de facto useless here.

There's actually a rather straightforward way out of this situation: to avoid competition between its own products, one of which is surpringly better than the other despite their market positioning, Intel can just quietly remove E6300 from the market. And leave E6320 instead, for example, with its doubled L2 cache. Will E6320 outperform E4400 armed with both faster bus and larger cache? An interesting question it is, and the answer is not that predictable already. We shall conduct the necessary benchmarking in the nearest future...