Bishwajit,

You are not the first to ask about the 'shared' L3. Here are a couple of other references that you might find of interest:

1) http://superuser.com/questions/413246/is-the-l3-cache-shared-by-all-cores-for-a-sandy-bridge-e-xeon-cpu

2) http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/4

hi,

depends on the processor. Each core has its L1 cache, other levels might be shared. If you are running your code on Linux you should bind processes to avoid transferring processes and consequently local data between cores/CPUs.

Best regards

You won't be able to stop any context switching, the best you can do is minimize it.

Look at it another way: If you have the processor all to yourself, wouldn't you

expect a performance boost over when there are memory hungry applications running on the other cores?

If that is the case, then by definition, other processes running on other cores

can slow you down.

The best you can do on modern Intel processors is to pin your process to

a particular core, and to minimize memory accesses beyond the L2 cache.

Novice Question... How can i pin a process to a particular core... is there any library to do so .

Taskset on linux for a single process.

OpenMPI has mpirun options for pinning MPI processes,, as does

Intel's mpirun.

Cray's aprun command has an even richer set.

The URL

https://blogs.cisco.com/performance/process-and-memory-affinity-why-do-you-care/

has some information you might find useful.

Try googling

processor affinity

or

memory affinity

to get more URLs.

LIKWID contains, among other things, a pinning tool: http://code.google.com/p/likwid

Nevertheless, even if you have pinned your process to a core, you cannot avoid context switching for other processes if the number present in the machine (your processes, ,OS processes or other users processes). That is, if you cannot execute your process "isolated" from the rest of processes in the machine.

Hey Juan Orduna. What you said is very interesting. I also found context switches even pin the process to a single core. Could you explain a bit about the reason and also the solutions?

well the question you have asked depends on the architecture of the Intel processor.

If we consider the modern Intel processors, where a processor has 4 cores (Quad-core) along with multi-threading/hyper-threading technology (not with the scope of this discussion) option, then each core has L1 and L2 caches of its own, but the L3 cache is shared among the 4 cores. Now L1 is closely situated on each core, whereas L2 is little further from that core and L3 is situated even further. Hence the access time on each level of cache increases with the hierarchy of the cache (L3>L2>L1). For example if we consider the latency between L1 and the core is 1 then the latency between L2 and the core may be 4 and for L3 it might be 20, whereas the latency between the main memory and processor is around 50 or even more (this is complete assumption but in reality it depends on the architecture of the processor yet close to this concept).

Now since the L1 and L2 cache memory is on-chip, for that reason it can not accommodate big memories because of the fixed size of the die of each core or the processor to an extent. For this reason the closer the cache memory i.e. L1, the smaller will be the size of that level of cache. For example L1

even if you want to pin a process (actually a thread) to a core in a processor using processor affinity, first you need to understand the concept of parallel algorithms because it is a programmers duty to implement programs properly depending on the processor architecture to gain desired performance.

For example, even if you pin a task to a core but while execution if another process interferes with that execution then you may get a high resultant timing for that process instead because of the interruptions and delays associated with that. So the programmer has to be intelligent enough to efficiently parallelise the code first then implement processor affinity to each task so that there is no interference or delay.

Again it also depends on which kind of architecture you want to implement that:

OepnMP (for shared memory architecture) or MPI(message passing) (for distributed memory architecture).

Remember: "You are the programmer, Performance is your Responsibility"

'With Great Power, comes Great Responsibility'-Unlce Ben, Spiderman! :D

A Core has private L1 instruction/data cache, but may not have private L2 cache. Most of multi-core processors share L2 cache among multiple cores.

You should understand that you don't have fine grained control over the different cache levels. The processor decides what to cache. Also you should know that everything that is within L1 cache can also (usually) be found in L2 and in L3 and in main memory. Caches mostly duplicate data so that the core has faster access. I think that when programming you should just ignore the fact that there are caches involved. If you really want to optimize performance on a cache level then you need to learn about processor architecture and data alignment. There are many tricks how to handle your data to get optimal performance. But, this is a very broad topic, so I just ignore it.

I usually advice against pinning your processes to a specific core. I did this once using as many threads as I had cores, pinning one thread to one core each, and it significantly slowed down my application. As long as you are running your application on a mostly regular computer where lots of processes (e.g. mail, browser, ...) are running you should avoid processor pinning. In these cases the operating system will be smarter and efficiently reserve compute time on different cores. In my opinion it only makes sense on cluster computers where nothing else is running and you have a compute node all to yourself.

You can try to use hard affinity but you need to explain what you are trying to achieve. You can avoid context switching by disabling the processor interrupt (atomic instructions) but I'm not sure if that's what you want.