Sql sever engine batch mode and cpu architectures

Editor's Notes

• #6: If the TOP 5000 is changed to TOP 30000 in the query to created the enlarged FactInternetSales table, it can be scaled up to 1095600000 rows.
• #7: The key takeaway point from this slide is that memory access is 100% CPU intensive, it is not subject to any locking or throttling back via contention.
• #9: Signal wait time = total wait time is to be expected for short waits on uncontended spin locks. The big problem with wait statistics is that they shed no light whatsoever on where CPU cycles are being expended whilst a thread is using its 4 ms quantum of scheduler time.
• #13: The current generation of Xeons is the i-series, where as the previous Core 2 architecture achieved a quad core design by gluing two dual core CPUs together on the same packaging, this is a native – “From the ground up” modular design. The memory controller was integrated onto the processor from the outset, also with the Sandybridge architecture, the IO hub is integrated into the uncore area and the L3 cache is connected to the cores via a bi-directional ring bus.
• #14: A big penalty is paid for going off CPU for data, this is also the case with using main memory in order to access the memory page table. Hekaton is not mentioned in this slide deck for the simple fact that memory optimised tables need to fit into memory, level 3 caches tend to be around 24Mb in size at a maximum for an eight core CPU, hence it is highly unlikely that any table of note can fit inside a CPU cache. When data is required that cannot be found in the L0, 1, 2, or 3 cache, this is known as a “CPU stall” or “Last level cache miss”.
• #15: Note the difference in latency between accessing the on CPU cache and main memory, accessing main memory incurs a large penalty in terms of lost CPU cycles, this is important and one of the drivers behind the new optimizer mode that was introduced in SQL Server 2012 in order to support column store indexes.
• #21: The core I series use the empty pipelines caused by CPU stalls to schedule a second ( hyper ) thread per core, prior to this Intel used a technology called ‘Net burst’, this aimed to fill all empty slots, as a technology this produced disappointing results, hyper threading with the core i series is a different matter however. AMD favours ‘Strong’ threads whereby each thread runs on its own dedicated core.
• #22: Xperf can provide deep insights into the database engine that other tools cannot, in this case we can walk the stack associated with query execution and observe the total CPU consumption up to any point in the stack in milliseconds
• #23: This slide is the “Big reveal”, for the column store created on the pre-sorted data, there are four points of interest when comparing the two call stacks: The hash table lookup is more expensive for the query using the column store created on the non-sorted data, by an order of magnitude. We see a line below the Flookup for the query against the column store created on non-sorted data which we do not see in the other call stack. The hash aggregate lookup for the query on the “Non-sorted” column store is throttling back the column store scan more than its counterpart in the other call stack, this is based on the number of times this is called. The scan for the sorted column store is twice as expensive as that for the non-sorted column store.
• #25: This slide is the “Big reveal”, for the column store created on the pre-sorted data, there are four points of interest when comparing the two call stacks: The hash table lookup is more expensive for the query using the column store created on the non-sorted data, by an order of magnitude. We see a line below the Flookup for the query against the column store created on non-sorted data which we do not see in the other call stack. The hash aggregate lookup for the query on the “Non-sorted” column store is throttling back the column store scan more than its counterpart in the other call stack, this is based on the number of times this is called. The scan for the sorted column store is twice as expensive as that for the non-sorted column store.
• #28: Thread numbers taken away… Removed bottom
• #37: Modern Intel CPUs speak two languages, programs are compiled into x86 architecture instructions, internally the CPU uses micro operations which are similar in nature to RISC instructions such as those that ARM processors use. In short this is so that the CPU can leverage RISC-like performance optimisations.
• #38: To get the best possible throughput from the CPU, all pipeline slots should be utilised, ‘Bubbles’ or empty slots are to be avoided at all costs, of all the things that can degrade CPU performance, getting branch prediction wrong is devastating in that this leads to the flushing of whole instruction pipe lines. There are techniques for utilising empty slots such as out of order execution and hyper threading. However, great efforts are put into the design of branch prediction logic in order to avoid the pipeline flushing in the first place, generally speaking each new micro architecture always includes some form of enhancement to the branch prediction logic.
• #41: The results for this graph have been obtained using a single instance with large pages, LPIM, 40Gb max memory, the ‘Sorted’ column store index and a warm large object cache.