How to choose a processor for your rig

Penguinoo

Honorable
Jan 17, 2014
7
0
10,520
To start this isn't a question but A helping guide
What many people, normally gamers, will tell you is you want like a amazing I7 with hyper threading! Also its clock is 3.2GHz! Oh and you can get a 6 core!
Well don't listen to them.
Nothing out there that you will play will require 6 core processes with 12 hyper threads.
First off, clock speed is just the rate a microprocessor executes instructions, it tells it what should do what and where it should be, faster the speed, faster it can do this. What no-one pays attention to is the cache.
The cache is used to reduce the average time which the processor accesses memory. While you may have a I7 with a 8MB cache, I have an Intel Xeon with a 12MB. Even though yours is quad core with 3.2GHz and mine is quad core with 2.4GHz, I can access memory faster than yours which is almost instantly beating it. Now with that out of the way, 8MB cache is still decent, but there is another thing bottlenecking your way. Hyper threads. Lets say you have a Intel 6 core with 12 hyper threads! Well hyper threads aren't physical bus lanes, they are virtual, and pretty much allow everything to even out. So take it this way: you have a freeway with 6 lanes but you say there are two more on the side, making it eight! So now people use these two fake lanes and the end up merging with lane 6 and 1, making 6 and 1 INCREDIBLY slower. Now if you disable hyper threading (via BIOS)
It will take out those extra virtual lanes and you may notice A slight difference in performance. Last but not least for all you gamers: know if your game is CPU or GPU heavy..I've dealt with many people wondering why their gtx 660 and Intel2 dual core processor isn't running counter-strike: global offensive on max... just a friendly tip: games on source engine or quake engine (pretty much older games and all the Counter-Strike including csgo) are all CPU heavy, as there wasn't a GPU too offload the video on.
for any questions please reply, add me on steam (steamcommunity.com/Id/elpenguino) or email me at randle.brandon@gmail.com
If you believe I messed up on this guide please email me a fix, as I am German and normally get English wrong.
Thanks
Penguin.
 
Bit wrong. You are implying that cache is more important than clock speed (in the same architecture).

Compare the 2.4Ghz Xeon to a overclocked 4670k @4.2Ghz in games and watch it blow the 2.4ghz Xeon away.
 
From what I was told I thought with a better cache it would preform better! Guess I shouldn't be listening to IBM architects haha
 
You implied that more cache would gain faster access to the cache, the different cache levels have different usages.
Cache are not very important today, as all have more than enough, for it to actually impact the performance.

With the hyper-threading it wont "INCREDIBLY slower", it would if they used the same ports, which hyper-threading wont do.
I too have been talking with people from IBM(was there in ireland with my school for a job-interview and some other stuff).

I do believe you have misunderstood something.
 
An i7@3.2 GHz is going to demolish a Xeon@2.4GHz with 12MB of cache in almost any scenario.

***Warning - this is about to get real technical real quick ***
You are wrong that increase cache speeds up how quickly the processor can access information, it does not. Actually a larger cache takes longer to check and therefore slows down the speed at which your processor can access the information.

The caching is done in layers, anything the CPU is using should be in L1, anything it expects to use soon or anything shared between cores should be in L2, L3 is for things that the threads might call but it is unlikely. If a memory access gets out to L3 cache you are already taking a decent performance hit, not as bad as going out to RAM but you are now talking 10+ cycles to access the data rather than 1 or 2 if it was in L1. Most consumer applications also have little enough active data going on that the caching should be able to keep it in L1 or L2, larger L3 is only really useful when running either lots of unrelated threads or a thread with a large active data set.

As for hyper threading making things slower, it does happen occasionally, but in general hyperthreading will not hurt you and most applications can't make use of enough threads for it to help you.

Hyper threading works because of dependencies in code keeping the CPU from utilizing all of its execution units all the time, if nothing can go forward until you know if A/B>1 then you have a lot of execution units sitting there waiting to be used while the division chugs along for a couple cycles. Hyper threading works by having a second set of data registers and instruction registers for each execution unit that can hold on to the data from a second thread, so if thread A is tied up for 10 cycles waiting to know if A/B>1 so it can decide on which fork to take, thread B can be pumping a lot of unrelated commands through the ALU(int math), memory controller, and even shove some commands in behind the division in the FPU to make the best use of the available resources in the processor. The image below shows it best, treat each column as a separate execution unit like the ALU, MMU, and FPU. As you can see it is nothing like merging two lanes of traffic together, but more like merging a couple sports cars in front of a big semi trying to get up a steep hill, there is a large space there, you can either use it and make better use of that lane, or let everyone sit and wait for the hill to be over.
hyperthreading_image1.gif