Rajat Batra’s Post

About the parameter ThreadMode. When you create a thread under TB library there is a misterious parameter called ThreadMode. If you set it to zero it behaves as default, so most people set it to zero. Be aware that this value is not related to OS "thread mode" variable, which indicates the source of a caller being user or kernel. In the TB library ThreadMode is how your thread behaves with regards to the remaining threads on the host OS. You can choose bewteen 4 values: DEFAULT, LOOPED, ACTIVE and HALTED. Default means TB chooses the apropriate value, usually it means LOOPED or ACTIVE is chosen. LOOPED means the cpu you have affinity to wait in a passive loop when stopped. ACTIVE means it waits on an active loop, and finally HALTED means it waits on halt, expecting for a NMI. LOOPED is faster when yield occurs, meaning it can awake and switch to other threads very fast, but power management is disabled. ACTIVE is slower but keeps the power management active. HALTED keeps the power to minimum but it is slow to react to an awake signal. As these parameters are difficult to calculate i recommend to leave TB to choose the right value for you. If you have found the CPU fan runs like crazy when creating new threads it is because you have chosen a mode that disables cpu step down. You may have observed the same behavior when breaking onto windbg and leaving the break active for some minutes. It happens also on some virtual machines that are managed by an unfriendly monitors. If you dont want this to happen, chose DEFAULT or ACTIVE for your TB threads.

When optimizing a large write process in code, one of your primary goals to speed things up is to minimize the number of instructions the CPU has to process. A typical low hanging fruit on this process is to remove unnecessary variable assignments in a loop. Take a look at the following examples: Unnecessary variable assignment for i:=1;i<=1000000000;i++ { var x string = strconv.Itoa(i) buffer.WriteString(x) } Direct Write for i:=1;i<=1000000000;i++ { buffer.WriteString(strconv.Itoa(i)) } In the examples above, the CPU is having to process both a variable assignment and a write to the buffer in the first block. If you simply update the loop and remove the variable assignment (2nd block) and have the buffer write the value directly, you have decreased the number of instructions the CPU has to handle in this case by a factor of 2. When iterating over 1 billion rows, this can have a dramatic impact on performance. Sometimes when doing complex calculations and for better readability, variable assignments in loops are needed. So don’t feel like you have to always Frankenstein a giant concacenated calculation inside the single write command.

This is the stuff that moves the needle. Finding bottlenecks we never know existed (maybe we were just not looking or taking it for granted ).. Take the CPU a beautiful instrument for execution instructions. To add two numbers and store the sum in memory. You load variable A into the CPU register (CPU cannot do anything with stuff in memory it has to be in its registers) you then load B into another register, you then execute 1 instruction to add the two registers and store them in a third register which then pushed that register to memory. what if I want to sum 100 pairs? you might say well that is 100 instructions. And that is the thing.. it doesn’t have to be what if tell you it can only be 25 25 executions is better than 100. Meet SIMD, single instruction multiple data (btw I didn’t know what that was this morning ) this allows one instruction to operate on multiple data at once and have multiple outputs essentially. So in our example you can store 4 variables in special vector registers and another 4 and have the CPU execute one instruction to sum 4 integers. think of it as a function that takes 8 parameters, a1,a2,a3,a4,b1,b2,b3,b4 and sum all of then at once and produce c1,c2,c3,c4 all in one shot single instruction. This is with a 128 bit vector and 32bit integer. brilliant. This is big when combined with B+Tree where we have alot of data keys and values (in pages) and we want to process it with SIMD. this paper goes deep into how a high throughput B+tree just for SIMD looks like. The paper also goes through techniques to achieve good cache locality in CPU. I love this stuff. paper here https://lnkd.in/gs2Pue8y

Jitni pass location, utni jaldi access aur utni jaldi kaam. (The thing that is closer for faster access gets the job done more quickly) __________ At a high level, we have the following pyramids for caches in our systems starting from the fastest in terms of data access speed: [1] L1 cache: - fastest memory for accessing the data - as a hardware, it's placed closest to the CPU cores - measured in KiloBytes or usually max goes up to 1MB - approx 100x faster than your system RAM The thing I recently learned about L1 cache is that it internally consists of two parts: [1] Data cache: holds the data on which the operation is to be performed [2] Instruction Cache: deals with the information about the operation that the CPU must perform [2] L2 cache: - slower in terms of data access but bigger in size than the L1 cache - also fitted inside each individual CPU core - usually measured in single-digit MBs - approx 25x faster than your system RAM [3] L3 cache: - of course larger than L1 and L2 caches - placed outside of the CPU core and shared across multiple CPU cores - It's a generic memory pool that the entire chip can use [4] RAM (also known as DRAM/Dynamic RAM): - system memory which is outside of the CPU - 4GB / 8GB / 16GB - Since it's a big pool of memory, the time needed for accessing data is slowest among other caches. Thus, the thing to note here is: ✅ Data Access speed from the cache level is directly proportional to the location of that cache from the CPU core. The less far it is, the better!