Core i5 6MB Cache vs Core i7 8MB Cache Without HTT

What's the difference performance-wise between a Core i5 6MB cache CPU and a Core i7 8MB cache CPU without Hyperthreading. With all other things being equal aside from the extra 2MB of cache what differences should I expect to see in performance? I expect to see virtually no difference. I would say there is a slight advantage in programs like Winrar but I don't know how much. If anyone has any idea how much more performance to expect please tell me or show me if there are any videos or articles on this subject.
 
Solution


The extra cache improves performance by a nominal amount. However, the extra cache is necessary to prevent Hyperthreading from causing problems. When Hyperthreading is enabled, the microprocessor now has two threads of execution fighting for cache...

Ryan_78

Honorable
As of single core, almost none. Since the i7 will be running at hyperthreading on default, it will be much better at multithreaded. If you're looking at. 6600k vs a 47xxk then no gaming difference, unless heavily multithreaded.
 

So if I disable hyperthreading I can pretty much say it's a Core i5? I'm trying to test the differences between a Core i5 and a Core i7 to see how much of an advantage the Core i7 really gives but I don't have a Core i5 CPU anymore and my benchmark test results with the Core i5 are limited. So if I could just simply simulate a Core i5 by disabling hyperthreading then that would be great for me to do more testing.
 


In Cinebench 11.5 the Core i5 scores 2.00 on the single core test at 4.6GHz and the Core i7 scores 2.00 at 4.5GHz. So the extra cache must be making that difference.
 


The extra cache improves performance by a nominal amount. However, the extra cache is necessary to prevent Hyperthreading from causing problems. When Hyperthreading is enabled, the microprocessor now has two threads of execution fighting for cache resources rather than one. This caused a lot of problems on the Pentium 4 microprocessors when HT was first introduced. Careful developers will avoid this pitfall by scheduling threads appropriately to minimize fighting, but not all developers are careful.
 
Solution