Why Crypto++ library's AES definition is so fast I am trying to compare the CPU cycle required for two encryption algorithms. One algorithm is AES and lets the other algorithm is B(code name). I implemented algorithm B and having fewer and simpler operations than AES and expected to take much less time/CPU cycles per encryption than AES
I am using an Intel i3, 10 gen processor, with 4MB cache. I am running both algorithms individually (with random 16-byte input) for $2^{20}$ times and taking the minimum and maximum required CPU cycles.
I see that for algorithm B CPU cycles are minimum=2707866 and maximum=4767402. But, for crypto++ definition of AES, the CPU cycles are minimum=2724 and maximum=29978194. I have performed the test multiple times and the results are almost similar. It is clear that the maximum time required for AES is much higher(7x) then algorithm B, but the minimum time for AES is much less.
I then recorded required CPU cycles for all $2^{20}$ AES encryption. I found that the first encryption is taking maximum cycles (29978194) and then the required CPU cycle reduced drastically and after 10-15 encryption it took almost same(approx 3000) CPU cycles for each encryption. For algorithm B every encryption took almost the same CPU cycles.
I do not understand the drastic reduction(10000 times) of CPU cycles for AES encryption(crypto++ library). Is there any voodoo of AES-NI? Can someone tell what kind of optimization is being done there?
Actually, your numbers seem shockingly high at 2724 cycles for one block - even with the key schedule.
Crypto++ uses standard AES-NI for the encryption of blocks and for the key generation they use AESKEYGENASSIST for the SBox (unfortunately).
Ideally the expected performance would be (for their implementation, not for one with an optimized on-the-fly key expansion):

~783 cycles for the keyschedule (as estimated by llvm-mca)
1x 1 cycle for the initial XOR of the key
10x 4 cycles for AESENC/ AESENCLAST

So overall less than 1000 cycles.
Even if we assume AES-256 here, we shouldn't get beyond 1500 cycles for the actual operations. 2700 is massively off from that and suggests inefficiencies in feeding AES data.
Also note that this kind of test is highly unfair to the AES-NI hardware because it only really shines if you give it 4 or more independent AES operations to calculate in parallel (due to latency of 4 cycles per round instruction but the throughput of 1 cycle per instruction). Furthermore note that Crypto++'s keyschedule implementation is ... rather lackluster, and optimized implementations compute a round key in less than 20 cycles, so less then 200 overall for the entire cipher.
You can find the translated key expansion code here. You can look the performance of the instructions up either at Intel's site or in Agner Fog's tables.

A fairer comparison would probably take the best non-AES-NI implementation, a AES-NI implementation of AES and an optimized implementation of your cipher and put them up against each other in these categories:

CBC encryption of long messages - measures the cipher latency and long messages &quot;hide&quot; the key schedule cost
CTR encryption of long messages - measures the maximal throughput
(Optionally) Stand-alone keyschedule computations with one encryption (which is roughly what you measured) - with an implementation optimized for fast key schedules (aka not Crypto++ as it currently stands)