You might look at this:

http://software.intel.com/sites/products/collateral/hpc/vtune/performanc...

Core i7 Xeon 5500 Series

Data Source Latency (approximate)

L1 CACHE hit, ~4 cycles

L2 CACHE hit, ~10 cycles

L3 CACHE hit, line unshared ~40 cycles

L3 CACHE hit, shared line in another core ~65 cycles

L3 CACHE hit, modified in another core ~75 cycles

remote L3 CACHE ~100-300 cycles

Local Dram ~60 ns

Remote Dram ~100 ns

There are additional issues to concern yourself with, in particular TLB miss.
Listed in above guide under DTLB. Where TLB is Translation Look Aside Buffer.
The TLB is a seperate very small cache of the virtual address to physical address mappings. On listed Core i7 Xeon Series this is 64 entries forprimary and 512 entries for secondary DTLB cache. I did not see mention of clock cycles impact when reference not in 64 entry DTLB primary. If a virtual memory reference is not mapped within the cached DTLBs you might suffer an additional 1 or 2 DRAM latencies.

Also, the above DRAM latencies are for the memory latency alone. Therefore, the latency to determine a cache miss may need to be added to the DRAM latency might get hidden. DRAM access tends to be pipelined so the cache miss latency. However.... when a specific thread experiences a cache miss, the DRAM request goes into a queue (16/12 deep depending on other thread memory requests). Therefore, a specific (worst case)request could have a latency of up to (3+16)*DRAM latency.

>>And the last things what methods are used to improve the succes hit ratio of caches

a) Structure data such that computationally related information resides within same cache line.
b) Write your algorithms such that the higher frequency of access occures on (near) adjacent memory. This reduces the TLB pressure.
c) Reduce number of writes to RAM through use of temporary varibles that can be registerized (optimized into register)
d) Structure data such that you can manipulate using SSE (when possible)
e) For parallel programming, coordinate activities amongst threads sharing cache levels. (HT siblings for L1 and L2, same die or half die for L3, same NUMA node for multiple nodes).

Jim Dempsey

The stats I posted were for a Core i7 Xeon 5500 series. This is an MP (Multi-Processor). You could strike the information relating to "remote..." latencies. There may be some addional differences between the processor models (exact clock counts and memory read/write queue depth). Instead of using tables written in a specification document, I suggest you measure the performance of representative benchmarks or against your application, as too many circumstances will affect the performance observedas compared to performance expected usingpublished statistics.

Make the pudding (the proof is in the pudding).

Jim Dempsey

Not certain if this iswhat you need foryour assignment- but a simple Google search on i7-980xgenerated multiple links including: htttp://ark.intel.com/Product.aspx?id=47932

Azzedine,

From the spec sheet http://ark.intel.com/Product.aspx?id=47932 this processor has

Turbo Boost
Speed Step
Intel Smart Cache

Therefore determining latencies will be difficult. What you measure for a short run benchmark on a cold CPU will differ from a long run benchmark that causes the CPU to heat up and reduce the speed. IOW your latencies are not fixed. Any chart you produce needs to include a thermal curve as well as application thread to core mapping. So much qualification detail is on these charts as to make them meaningless for use in projecting performance estimations of an arbitrary application. Meaning you really need to run your specific application with actual data and not use best case performance latencies or industry benchmark applications.

Jim Dempsey