Trial-division code runs 2x faster as 32-bit on Windows than 64-bit on Linux
You don't say whether the windows/linux operating systems are 32 or 64 bit.
On a 64-bit linux machine, if you change the size_t to an int you'll find that execution times drop on linux to a similar value to those that you have for windows.
size_t is an int32 on win32, an int64 on win64.
EDIT: just seen your windows disassembly.
Your windows OS is the 32-bit variety (or at least you've compiled for 32-bit).
size_t is a 64-bit unsigned type in the x86-64 System V ABI on Linux, where you're compiling a 64-bit binary. But in a 32-bit binary (like you're making on Windows), it's only 32-bit, and thus the trial-division loop is only doing 32-bit division. (size_t is for sizes of C++ objects, not files, so it only needs to be pointer width.)
On x86-64 Linux, -m64 is the default, because 32-bit is basically considered obsolete. To make a 32-bit executable, use g++ -m32.
Unlike most integer operations, division throughput (and latency) on modern x86 CPUs depends on the operand-size: 64-bit division is slower than 32-bit division. (https://agner.org/optimize/ for tables of instruction throughput / latency / uops for which ports).
And it's very slow compared to other operations like multiply or especially add: your program completely bottlenecks on integer division throughput, not on the map operations. (With perf counters for a 32-bit binary on Skylake, arith.divider_active counts 24.03 billion cycles that the divide execution unit was active, out of 24.84 billion core clock cycles total. Yes that's right, division is so slow that there's a performance counter just for that execution unit. It's also a special case because it's not fully pipelined, so even in a case like this where you have independent divisions, it can't start a new one every clock cycle like it can for other multi-cycle operations like FP or integer multiply.)
g++ unfortunately fails to optimize based on the fact that the numbers are compile-time constants and thus have limited ranges. It would be legal (and a huge speedup) for g++ -m64 to optimize to div ecx instead of div rcx. That change makes the 64-bit binary run as fast as the 32-bit binary. (It's computing exactly the same thing, just without as many high zero bits. The result is implicitly zero-extended to fill the 64-bit register, instead of explicitly calculated as zero by the divider, and that's much faster in this case.)
I verified this on Skylake by editing the binary to replace the 0x48 REX.W prefix with 0x40, changing div rcx into div ecx with a do-nothing REX prefix. The total cycles taken was within 1% of the 32-bit binary from g++ -O3 -m32 -march=native. (And time, since the CPU happened to be running at the same clock speed for both runs.) (g++7.3 asm output on the Godbolt compiler explorer.)
32-bit code, gcc7.3 -O3 on a 3.9GHz Skylake i7-6700k running Linux
$ cat > primes.cpp # and paste your code, then edit to remove the silly system("pause")
$ g++ -Ofast -march=native -m32 primes.cpp -o prime32
$ taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,arith.divider_active ./prime32
Serial time = 6.37695
Performance counter stats for './prime32':
6377.915381 task-clock (msec) # 1.000 CPUs utilized
66 context-switches # 0.010 K/sec
0 cpu-migrations # 0.000 K/sec
111 page-faults # 0.017 K/sec
24,843,147,246 cycles # 3.895 GHz
6,209,323,281 branches # 973.566 M/sec
24,846,631,255 instructions # 1.00 insn per cycle
49,663,976,413 uops_issued.any # 7786.867 M/sec
40,368,420,246 uops_executed.thread # 6329.407 M/sec
24,026,890,696 arith.divider_active # 3767.201 M/sec
6.378365398 seconds time elapsed
vs. 64-bit with REX.W=0 (hand-edited binary)
Performance counter stats for './prime64.div32':
6399.385863 task-clock (msec) # 1.000 CPUs utilized
69 context-switches # 0.011 K/sec
0 cpu-migrations # 0.000 K/sec
146 page-faults # 0.023 K/sec
24,938,804,081 cycles # 3.897 GHz
6,209,114,782 branches # 970.267 M/sec
24,845,723,992 instructions # 1.00 insn per cycle
49,662,777,865 uops_issued.any # 7760.554 M/sec
40,366,734,518 uops_executed.thread # 6307.908 M/sec
24,045,288,378 arith.divider_active # 3757.437 M/sec
6.399836443 seconds time elapsed
vs. the original 64-bit binary:
$ g++ -Ofast -march=native primes.cpp -o prime64
$ taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,arith.divider_active ./prime64
Serial time = 20.1916
Performance counter stats for './prime64':
20193.891072 task-clock (msec) # 1.000 CPUs utilized
48 context-switches # 0.002 K/sec
0 cpu-migrations # 0.000 K/sec
148 page-faults # 0.007 K/sec
78,733,701,858 cycles # 3.899 GHz
6,225,969,960 branches # 308.310 M/sec
24,930,415,081 instructions # 0.32 insn per cycle
127,285,602,089 uops_issued.any # 6303.174 M/sec
111,797,662,287 uops_executed.thread # 5536.212 M/sec
27,904,367,637 arith.divider_active # 1381.822 M/sec
20.193208642 seconds time elapsed
IDK why the performance counter for arith.divider_active didn't go up more. div 64 is significantly more uops than div r32, so possibly it hurts out-of-order execution and reduces overlap of surrounding code. But we know that back-to-back div with no other instructions has a similar performance difference.
And anyway, this code spends most of its time in that terrible trial-division loop (which checks every odd and even divisor, even though we can already rule out all the even divisors after checking the low bit... And which checks all the way up to num instead of sqrt(num), so it's horribly slow for very large primes.)
According to perf record, 99.98% of the cpu cycles events fired in the 2nd trial-division loop, the one MaxNum - i, so div was still the entire bottleneck, and it's just a quirk of performance counters that not all the time was recorded as arith.divider_active
3.92 │1e8: mov rax,rbp
0.02 │ xor edx,edx
95.99 │ div rcx
0.05 │ test rdx,rdx
│ ↓ je 238
... loop counter logic to increment rcx
From Agner Fog's instruction tables for Skylake:
uops uops ports latency recip tput
fused unfused
DIV r32 10 10 p0 p1 p5 p6 26 6
DIV r64 36 36 p0 p1 p5 p6 35-88 21-83
(div r64 itself is actually data-dependent on the actual size of its inputs, with small inputs being faster. The really slow cases are with very large quotients, IIRC. And probably also slower when the upper half of the 128-bit dividend in RDX:RAX is non-zero. C compilers typically only ever use div with rdx=0.)
The ratio of the cycle counts (78733701858 / 24938804081 = ~3.15) is actually smaller than the ratio of best-case throughputs (21/6 = 3.5). It should be a pure throughput bottleneck, not latency, because the next loop iteration can start without waiting for the last division result. (Thanks to branch prediction + speculative execution.) Maybe there are some branch misses in that division loop.
If you only found a 2x performance ratio, then you have a different CPU. Possibly Haswell, where 32-bit div throughput is 9-11 cycles, and 64-bit div throughput is 21-74.
Probably not AMD: the best-case throughputs there are still small even for div r64. e.g. Steamroller has div r32 throughput = 1 per 13-39 cycles, and div r64 = 13-70. I'd guess that with the same actual numbers, you'd probably get the same performance even if you give them to the divider in wider registers, unlike Intel. (The worst-case goes up because the possible size of input and result is larger.) AMD integer division is only 2 uops, unlike Intel's which is microcoded as 10 or 36 uops on Skylake. (And even more for signed idiv r64 at 57 uops.) This is probably related to AMD being efficient for small numbers in wide registers.
BTW, FP division is always single-uop, because it's more performance-critical in normal code. (Hint: nobody uses totally naive trial-division in real life for checking multiple primes if they care about performance at all. Sieve or something.)
The key for the ordered map is a size_t, and pointers are larger in 64-bit code, making each red-black tree node significantly larger, but that's not the bottleneck.
BTW, map<> is a terrible choice here vs. two arrays of bool prime_low[Count], prime_high[Count]: one for the low Count elements and one for the high Count. You have 2 contiguous ranges, to the key can be implicit by position. Or at least use a std::unordered_map hash table. I feel like the ordered version should have been called ordered_map, and map = unordered_map, because you often see code using map without taking advantage of the ordering.
You could even use a std::vector<bool> to get a bitmap, using 1/8th the cache footprint.
There is an "x32" ABI (32-bit pointers in long mode) which has the best of both worlds for processes that don't need more than 4G of virtual address space: small pointers for higher data density / smaller cache footprint in pointer-heavy data structures, but the advantages of a modern calling convention, more registers, baseline SSE2, and 64-bit integer registers for when you do need 64-bit math. But unfortunately it's not very popular. It's only a little faster, so most people don't want a third version of every library.
In this case, you could fix the source to use unsigned int (or uint32_t if you want to be portable to systems where int is only 16 bit). Or uint_least32_t to avoid requiring a fixed-width type. You could do this only for the arg to IsPrime, or for the data structure as well. (But if you're optimizing, the key is implicit by position in an array, not explicit.)
You could even make a version of IsPrime with a 64-bit loop and a 32-bit loop, which selects based on the size of the input.