Matthew Watson's and Charlieface's answers actually explain the reason for this question, because compared to CLR, JVM has implemented more loop optimizations, including vectorization and loop unrolling, which allows the JVM to use fewer jump and inc instructions and save more time when the loop length is very long.

There is an issue on GitHub that tracks the progress of .NET loop optimizations. unfortunately the above optimizations is still ongoing.

TL:DR/summary: C# is slow because of branch mispredicts, but writing the source differently can fix that. Java makes branchless scalar asm which is ok but about 2x (or more) slower than it could be. Everyone's been focusing on loop unrolling but that's irrelevant here due to the loop-carried dependency-chain latency bottleneck for Java's branchless strategy.

C/C++ compilers (GCC and Clang) auto-vectorize in a fairly clunky way, but still much faster, or make pretty good branchless scalar asm if you tell them not to vectorize. Manually vectorizing with intrinsics for SSE2, AVX2, or NEON can go even faster (in C# or C++ or C or any language with usable intrinsics for packed-compares and arch-specific tricks like psadbw to horizontal sum bytes). About 1 vector (16 or 32 bytes) per clock cycle if memory bandwidth weren't a bottleneck. (32 elements, or only 8 if you unpacked your bytes to ints.)

C# makes branchy assembly for your if, so your random pattern of elements to be counted causes branch mispredicts

To make your C# code faster than Java (or at least equal), use this:

 count += (element > 100) ? 1 : 0; // C# or Java 

(Sharplab.io with x64 asm for this and the original).
C# .NET Framework for x64 compiles this to cmp ; setg(0/1 byte) ; movzx(zero-extend to 32-bit) ; add. Not ideal asm (movzx could be avoided by zeroing a reg outside the loop, or even using cmp/sbb $-1, %reg like GCC and Clang do), but still better than Java's worse branchless strategy which has longer critical-path latency for the loop-carried dependency chain through count. The above code might hand-hold Java into making better asm, which could make its loop unrolling useful.

 // Java's if-conversion strategy. C# compiles it to worse branching than the if! // and it would still be worse than the above for this use-case if it compiled as written, to cmp/lea/cmov count = (element > 100) ? count+1 : count; // This is worse, don't do this 

This also works on byte[] array data without any special tricks, since C# byte is unsigned like uint. Widening u8 on the fly to i32 or u32 is very cheap on modern CPUs, same cost as 32-bit load. It's a total disaster for overall performance to allocate another 4x as much memory and expand into it before doing any useful work on your data, but you left that loop out of your timed region. Usually you want to aim for more computational intensity: more work per time your data gets loaded into L1d cache or into registers. And keeping your data in a compact representation and not copying it (let alone expanding it) means a smaller cache footprint and less memory traffic for the same amount of work.

In Java, hopefully the JIT does something good with int elem = 0xFF & (int)elem_byte;. But even if it's dumb and uses movsx (sign-extending load) + and, instead of movzx (zero-extending load) or simply cmp byte [mem], 100, it's still cheaper to do this as part of the compare loop. It does make things maybe less comparable between C# and Java if you want to know how they perform for a loop where they more easily could have made the same asm. Timing a loop over the byte array would include the Java "tax" in what you're microbenchmarking for the language which doesn't provide unsigned 8-bit integers, if it fails to optimize source which could still compile to unsigned compares on bytes.

Branch mispredictions

See Why is processing a sorted array faster than processing an unsorted array? for details about that. (When that question was asked, C++ and Java compilers were like C# is now, making branchy machine code from source that uses a similar if(). It's a very similar problem, doing if (elem >= 128) sum += elem; instead of if (elem > 100) ++count;. C++ compilers now auto-vectorize, and Java makes branchless asm.)

Branch mispredicts account for most if not all of the 5x speed difference. Java's unrolling is pretty much irrelevant, especially on your Zen 1 CPU (pipeline is 5 uops wide), especially the slow way Java made branchless code with a 2 cycle critical path latency instead of 1.

C#'s asm

https://Sharplab.io/ AFAIK gets the .NET framework JIT to optimize as much as possible. It doesn't run your code, since it still works when you give it just a function with no caller that would pass it the right data, so unlike the HotSpot JIT or gcc -fprofile-generate/-fprofile-use or similar PGO (Profile-Guided Optimization) options, it doesn't have profiling information to let it know which branches are unpredictable or which loops are hot (and thus worth unrolling at the cost of more binary size and I-cache / I-TLB footprint, and worth spending more compile time on to run more optimization passes.) GCC -O3 doesn't enable -funroll-loops either; -funroll-loops is only on manually or as part of -fprofile-use PGO. Clang does unroll by default, but only for small loops; the fewer instructions in the loop body, the more it unrolls.

Anyway, C#'s inner loop from the if() version of the function looks like this. Even though the source uses foreach (int element in array), the compiler invents a 32-bit array index and redoes sign-extension to 64-bit every iteration. With crap likes this, no wonder there's such benefit to wide pipelines in modern CPUs.

Update: .NET x64 (not framework) on Sharplab (; Core CLR 9.0.525.21509 on x64) makes less clunky asm, avoiding the movsxd sign-extension of an array index, and uses cmp [mem], 100 instead of a separate load. It also avoids an indexed addressing-mode for the branchy version, but unfortunately not for branchless. And it still uses cmp/setcc/movzx instead of xor-zero/cmp/setcc.

The asm below is from .NET Framework - ; Desktop CLR 4.8.9305.0 on x64 on Sharplab.

# before this, zero idx and count, and branch over the loop if length==0 # do { L0010: movsxd r9, ecx # sign-extend idx to pointer width for use in an addressing-mode L0013: cmp dword [rdx+r9*4+0x10], 0x64 # array[idx]; I guess C# arrays have 16 bytes of metadata before the actual array. L0019: jle L001d # if (elem <= 100) goto skip_increment L001b: inc eax # ++count L001d: inc ecx # ++idx L001f: cmp r8d, ecx L0022: jg L0010 # }while(length > idx) 

With the count += (element>100); version, on a byte array:

 # do{ L0010: movsxd r9, ecx L0013: movzx r9d, byte [rdx+r9+0x10] # separately load, with zero-extension. Unscaled index this time because byte elements L0019: cmp r9d, 0x64 # int compare L001d: setg r9b # r9b (low byte of R9) = 0 or 1, upper bits unmodified, g = signed Greater L0021: movzx r9d, r9b # zero-extend into the full R9 (explicitly to 32, implicitly to 64) L0025: add eax, r9d # count += cmp_result L0028: inc ecx # ++idx L002a: cmp r8d, ecx L002d: jg L0010 # }while(length > idx) 

With macro-fusion of cmp/jg into a single uop, this is 8 uops, 7 of which need an ALU execution unit. (The load runs on a separate port). Probably only Intel Skymont E-cores can run it at 1 compare per cycle; other cores will bottleneck on the front-end and/or integer ALU ports thanks to C# doing everything it could to waste instructions inside the loop, including redoing sign-extension (movsxd) of a 32-bit index despite using foreach (int element in array) instead of manual indexing. (Lion Cove P-cores and Zen 5 are 8-wide but "only" have 6 integer ALU ports, so close to 1/clock, unlike Skymont which is also 8-wide but has 8 integer ALU ports and 3 branch execution units.)

(I don't know if Skymont can keep the cmp micro-fused into a single uop, with the indexed addressing mode and an immediate. Skylake can't. So it might even by 9 uops on most Intel CPUs, still 8 on AMD.)

This is like an exercise in how many instructions we can waste inside the loop. Redoing sign-extension of an index invented by the runtime is the most egregious sin, but that's present in the branchy version, too. Loop unrolling would help with the branchless version; instruction throughput is the bottleneck for it on most CPUs.

Even with an int array, we still get a separate mov instead of cmp [mem], 100. Same amount of work for the back-end execution units, but takes more slots in other parts of the pipeline (decode, the reorder buffer (ROB), and issue/rename. Or dispatch, to use the non-Intel terminology for sending a uop from the front-end to the back-end, as in the diagram of your CPU core in https://en.wikichip.org/wiki/amd/microarchitectures/zen#Individual_Core)

The choice of movzx r9d, r9b instead of into a different register like r10d defeats mov-elimination, so this instruction needs an execution unit. (Intel CPUs since Ivy Bridge could otherwise eliminated it. But IIRC, AMD CPUs don't eliminate movzx, only 32 and 64-bit mov reg,reg, so that wouldn't have helped when tuning for your Zen 1. What would have helped is xor-zeroing a register outside the loop and doing setg into the low byte of it. That would create another loop-carried dependency chain since the low byte isn't renamed separately from the full register, except on old Intel P6-family, and setcc is inconveniently designed to only write a byte instead of a whole register width. Intel APX will eventually fix that; until then see the setcc section of What is the best way to set a register to zero in x86 assembly: xor, mov or and?. Unrolling and zeroing xor-zeroing a register once per 4 or more setcc instructions would be good.)

Sharplab doesn't have an AArch64 target to check if it's using cinc (conditional-increment according to a flag condition). AArch64 is perfect for this problem.

Smarter compilers (like GCC or Clang, if told not to auto-vectorize: Godbolt) do much better, even avoiding materializing a 0/1 integer in a register at all, but rather adding the carry flag directly from the compare result. Or rather, subtracting it and -1, since on x86 CF is set (by sub/cmp) for "below", cleared for "above"; it's a "borrow" output from subtraction. GCC's loop is 4 uops, and can run at 1/cycle on CPUs as old as Broadwell (for single-uop sbb with a non-zero immediate) or your Zen 1.

# GCC 15 -O3 -fno-tree-vectorize for a loop doing: if(data[i] > 100) count++; .L4: # do{ cmp BYTE PTR [rdi], 101 # set flags from elem - 101. Carry Flag = 1 if elem is below 101 sbb eax, -1 # count -= (-1 + CF) // += 1 for elem >= 101, += 0 otherwise add rdi, 1 # ptr++ cmp rdi, rsi jne .L4 # }while(ptr != endp) 

Using a non-indexed addressing-mode prevents un-lamination) at issue/rename after micro-fusion in the decoder.

Clang uses the same cmp/sbb peephole optimization, but unrolls the loop by 8. This doesn't help for long-running loops except on really old CPUs with less than 4 execution units, like Sandy/Ivy Bridge. If it had unrolled with multiple registers holding separate counts (aka multiple accumulators) to add at the end, it could do 2 elements / cycle, limited by load ports. (2 loads per clock on older CPUs like Zen 1, 3 scalar loads per clock on many newer CPUs).

With signed int elements, the compare result isn't the carry flag, so there's nothing like the sbb trick. GCC uses xor-zeroing (inside the loop) / cmp / setcc / add. Same front-end uop count as C#, but xor-zeroing is literally as cheap as a NOP on Sandybridge-family and I think on Zen; no back-end execution unit needed. And of course it doesn't redo sign-extension of an index inside the loop, so only 7 uops, 5 of which need an ALU execution port.

Java makes branchless scalar asm. Its unrolling isn't useful here.

Making branchless machine code / assembly from source that uses an if is called "if conversion" optimization. In technical terminology, if-conversion is turning a control dependency into a data dependency.

See @k314159's answer for the Java asm, and my comments on it.

Java makes branchless asm using a worse strategy that can be represented in high-level source as count = (element > 100) ? count+1 : count;, which has 2 operations on the critical path from old count to new count: increment and cmov (conditional select using an ALU operation whose inputs are the compare result in FLAGS, count, count+1). AArch64 has a similar csel instruction, but also a csinc / cinc instruction that can conditionally increment as well as select, based on a flag condition.

See gcc optimization flag -O3 makes code slower than -O2 for a very similar case of branchless code-gen with a longer critical path than necessary.

Unrolling helps with throughput bottlenecks (front-end decode and alloc/rename into the back end, and execution ports), not with loop-carried dependency-chain latency bottlenecks.

Even with this cmov strategy instead of materializing a 0/1 integer to add, it could have unrolled better with multiple accumulators for count (like count1, count2 etc), summing at the end; that's a common technique for hiding floating-point ALU latency. A compiler is allowed to do it for you with integer math because it's associative, unlike FP math with rounding error. But that's not what the HotSpot JIT does, so it could be going about 2x faster (1 element per cycle) without even vectorizing. Or even more on wider CPUs like Arrow Lake or Zen 5, with multiple accumulators.

SIMD vectorization

Neither JIT (C# or Java) is doing this for you. Modern ahead-of-time compilers do (GCC and Clang), making asm that's much faster than scalar but still far from optimal.

With SSE2 or AVX2 used efficiently, you'd easily bottleneck on memory bandwidth, or close to L2 cache bandwidth (32 bytes per cycle) if data was hot in L2 or L1d. Same for NEON/ASIMD or SVE on AArch64.
With auto-vectorized machine code from GCC or Clang, you wouldn't be going that fast. Maybe fast enough to keep up with DRAM bandwidth of like 8 to 16 bytes per cycle on a desktop/laptop, even with byte elements. With 32-bit int elements, there's less unpacking/widening work per vector (using GCC/Clang's bad strategy) and the data is less dense, so even auto-vectorized C++ should just bottleneck on DRAM bandwidth for your large problem size. Manually vectorizing would be useful to let you go faster with hot caches, and waste less execution resources so the other logical core sharing a physical core can get more done.

See my comments under Matthew Watson's answer for more about SIMD. And his answer for C# with intrinsics doing an ok job, but horizontally summing the compare result inside the inner loop. Charlieface's answer shows Vector.Subtract to increment a vector of counts with the 0 / -1 compare-result vector.

The problem of accumulating byte compare results into a total count is the same as in How to count character occurrences using SIMD, where chtz's answer shows C++ with AVX2 intrinsics which accumulate counts in separate bytes for an inner loop of up to 255 iterations (the max before any element could overflow), then hsum with vpsadbw against a zeroed register and accumulate those 64-bit counts into another vector which you hsum outside the outer loop.

x86 before AVX-512 only has two integer compare predicates: equal and signed-greater. So to do unsigned above or below, one trick is x > y as min(x,y) != y; Clang does it that way, actually spending an XOR to invert the compare results from vpcmpeqb. Or using unsigned-saturating subtraction + cmpeq like GCC does. That's part of how GCC/Clang auto-vectorize, but they widen to 32-bit for every compare-result, inefficiently not even using psadbw. Or worse to 64-bit elements if your sum variable is 64-bit. Especially with AVX2 where the top 128 bits is less convenient to get at.

You can see GCC/Clang in the above Godbolt link; take out -fno-tree-vectorize from the command line options.

Saturating subtraction isn't available for arch-agnostic System.Numerics vectors, so you'd have to use Avx2.SubtractSaturate on Vector256 from System.Runtime.Intrinsics.X86 to do it that way, which would make it x86-only. But packed-min, packed-max, and equality are available. So is XOR and compare for greater-than, so you could XOR with 128 to range-shift unsigned to signed, and do (x^128) > (100^128). With the threshold reused across many vectors, XORing it as part of the setup is negligible. Or Max(v, thresh+1) == v should only be true when v>thresh.

Charlieface's version compiles nicely for int input.

For byte input, this is my rough attempt at doing something non-terrible with intrinsics in C#, despite not having access to efficient horizontal-sum of unsigned bytes (vpsadbw). And working around the compiler which wanted to use AVX-512 unsigned byte compares on Sharplab for .GreaterThan, but instead of doing a merge-masking add or sub, it turned the mask back into a vector with vpmovm2b, so it's no better than just using AVX2 to emulate unsigned compares. In fact it's worse; AVX-512 compares only run on one port on Intel CPUs, vs. vpcmpgtb with a YMM destination (instead of a k mask register) running on more ports.

... // trimmed to fit in 30k char limit Vector<ushort> outercount = new(); for (; i < unrolled_size_limit; ) { Vector<byte> vcount0 = new(); // Unroll with two u8 accumulator vectors to hide latency Vector<byte> vcount1 = new(); for(int j=0; j<255; ++j) { // Maybe use LoadUnsafe or something to avoid bounds checks? var v = new Vector<byte>(array.Slice(i, vectorSize)); var max = Vector.Max(v, vthresh_plus_1); var mask = Vector.Equals(max, v); // true when v >(unsigned) thresh vcount0 -= mask; v = new Vector<byte>(array.Slice(i+vectorSize, vectorSize)); max = Vector.Max(v, vthresh_plus_1); vcount1 -= Vector.Equals(max, v); i += 2 * vectorSize; } ... 

Sharplab with this and Charlieface's Vector<int> version, which I don't think I ended up modifying significantly since it was already good.

This has bounds-checks on each vector load inside the inner loop, so that sucks a lot for throughput, like an extra mov+lea+cmp/ja. Maybe using MemoryMarshal.Cast can do the check once, outside the loop? As in Writing a vector sum function with SIMD (System.Numerics) and making it faster than a for loop

v == max(v, thresh+1) forces the compiler to load into a register instead of using a memory source operand for vpmaxub. I really should have used XOR / signed compare for greater.

The inner loop from L0039: to dec/jne short L0039 is 19 uops for CPUs that handle 256-bit vectors as a single uop. (Unlike Zen 1, where they're 2 uops each). So maybe 2x 32-byte vectors per 4 clock cycles, or 16 byte elements per clock, on 5-wide CPUs with 256-bit vector ALUs, like Ice Lake or Zen 2. Intel might bottleneck on back-end ALU ports; AMD has separate ports for integer vs. SIMD and there's a good mix of both, plus 2 loads.

By comparison, the not-unrolled inner loop from Charlieface's version actually does still have the bounds checking, too. 10 uops for 1 vector, again about 2 cycles per 32 bytes or 16 bytes per cycle.

The outer loop code that widens to Vector<UInt16> is much worse than vpsadbw, but only runs every 2x255 vectors.

This is not an answer to the actual question, but just a demonstration of how you could optimise the C# code to use SIMD vectors.

I believe that the most likely answer is "because Java is using SIMD vector optimisations and C# is not" - but to prove this we would need to see the actual ASM generated for the Java.

If the Java is using SIMD, it might be doing something like this:

static int testSpeedVectorised(ReadOnlySpan<int> array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 100; int count = 0; int vectorSize = Vector<int>.Count; var threshold = new Vector<int>(THRESHOLD); // Vectorised loop int i = 0; for (; i <= array.Length - vectorSize; i += vectorSize) { var v = new Vector<int>(array.Slice(i, vectorSize)); var mask = Vector.GreaterThan(v, threshold); // Each 'true' in mask is -1, so Vector.Sum(mask) is negative of the match count. // Therefore, we subtract it from count rather than adding it. count -= Vector.Sum(mask); } // Handle the leftover values that didn't fit in a Vector<int> for (; i < array.Length; i++) { if (array[i] > THRESHOLD) count++; } return count; } 

If you really REALLY want to, you can write a multithreaded version of the SIMD version to make it even faster:

[MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedMultithreadedVectorised(int[] array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 100; int vectorSize = Vector<int>.Count; int length = array.Length; const int BLOCK_SIZE = 1_000_000; // Might not be optimal, adjust as needed. int total = 0; Parallel.For( 0, (length + BLOCK_SIZE - 1) / BLOCK_SIZE, () => 0, // Initial local count for each thread (blockIndex, _ /* state - not used */, localCount) => { int start = blockIndex * BLOCK_SIZE; int end = Math.Min(start + BLOCK_SIZE, length); int i = start; var threshold = new Vector<int>(THRESHOLD); for (; i <= end - vectorSize; i += vectorSize) { var v = new Vector<int>(array, i); var mask = Vector.GreaterThan(v, threshold); // Each 'true' in mask is -1, so Vector.Sum(mask) is negative of the match count. // Therefore, we subtract it from count rather than adding it. localCount -= Vector.Sum(mask); } // Handle the leftover values that didn't fit in a Vector<int> for (; i < end; i++) { if (array[i] > THRESHOLD) localCount++; } return localCount; }, localCount => Interlocked.Add(ref total, localCount) ); return total; } 

The benchmark results are as follows:

| Method | Mean | Error | StdDev | Allocated | |--------------------------------- |-----------:|----------:|----------:|----------:| | TestSpeed | 288.823 ms | 2.8061 ms | 2.6248 ms | 200 B | | TestSpeedVectorised | 20.204 ms | 0.3636 ms | 0.3401 ms | 12 B | | TestSpeedMultithreadedVectorised | 6.554 ms | 0.0168 ms | 0.0157 ms | 7844 B | 

As you can see, the optimised versions are significantly faster.

Update

I have incorporated the suggestions from other answers into my benchmarks.

However, I have not attempted to optimise for using a byte array, since I think that is a distraction from the requirement of checking which values of an int array exceed a particular threshold.

To drive this point home, the test data is an array of 10 million int values between 0 and 10_000 inclusive and the threshold is 5_000.

Benchmark Code

• Original() is the original C# code from the OP.

• Optimised() rewrites the inner loop to use the suggestion from u/PeterCordes.

• Vectorised() is my original vector approach.

• BetterVectorised() incorporates a suggestion from /u/CharlieFace

• MtVectorised() is the multithreaded version of Vectorised().

• MtBetterVectorised() is the multithreaded version of BetterVectorised().

  using System.Numerics; using System.Runtime.CompilerServices; using BenchmarkDotNet.Attributes; namespace ConsoleApp1; [MemoryDiagnoser] public class Benchmark { private int[] _array = null!; [GlobalSetup] public void Setup() { var rng = new Random(321312); _array = new int[100_000_000]; for (int i = 0; i < _array.Length; i++) { _array[i] = rng.Next(0, 10_001); // Random values between 0 and 10_000. } } [Benchmark(Baseline = true)] public int Original() { return testSpeed(_array); } [Benchmark] public int Optimised() { return testSpeedOptimised(_array); } [Benchmark] public int Vectorised() { return testSpeedVectorised(_array); } [Benchmark] public int BetterVectorised() { return testSpeedVectorisedOptimised(_array); } [Benchmark] public int MtVectorised() { return testSpeedMultithreadedVectorised(_array); } [Benchmark] public int MtBetterVectorised() { return testSpeedMultithreadedVectorisedOptimised(_array); } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedVectorised(ReadOnlySpan<int> array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 5_000; int count = 0; int vectorSize = Vector<int>.Count; int i = 0; var threshold = new Vector<int>(THRESHOLD); // Vectorized loop for (; i <= array.Length - vectorSize; i += vectorSize) { var v = new Vector<int>(array.Slice(i, vectorSize)); var mask = Vector.GreaterThan(v, threshold); // Each 'true' in mask is -1, so Vector.Sum(mask) is negative of the match count. // Therefore, we subtract it from count rather than adding it. count -= Vector.Sum(mask); } // Remainder loop for (; i < array.Length; i++) { if (array[i] > THRESHOLD) count++; } return count; } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedVectorisedOptimised(ReadOnlySpan<int> array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 5_000; Vector<int> count = new(); int vectorSize = Vector<int>.Count; var threshold = new Vector<int>(THRESHOLD); // Vectorised loop int i = 0; for (; i <= array.Length - vectorSize; i += vectorSize) { var v = new Vector<int>(array.Slice(i, vectorSize)); var mask = Vector.GreaterThan(v, threshold); count = Vector.Subtract(count, mask); } var totalCount = Vector.Sum(count); // Handle the leftover values that didn't fit in a Vector<int> for (; i < array.Length; i++) { if (array[i] > THRESHOLD) totalCount++; } return totalCount; } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedMultithreadedVectorised(int[] array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 5_000; int vectorSize = Vector<int>.Count; int length = array.Length; const int BLOCK_SIZE = 1_000_000; // Might not be optimal, adjust as needed. int total = 0; Parallel.For( 0, (length + BLOCK_SIZE - 1) / BLOCK_SIZE, () => 0, // Initial local count for each thread (chunkIdx, _ /* state - not used */, localCount) => { int start = chunkIdx * BLOCK_SIZE; int end = Math.Min(start + BLOCK_SIZE, length); int i = start; var threshold = new Vector<int>(THRESHOLD); for (; i <= end - vectorSize; i += vectorSize) { var v = new Vector<int>(array, i); var mask = Vector.GreaterThan(v, threshold); // Each 'true' in mask is -1, so Vector.Sum(mask) is negative of the match count. // Therefore, we subtract it from count rather than adding it. localCount -= Vector.Sum(mask); } // Handle the leftover values that didn't fit in a Vector<int> for (; i < end; i++) { if (array[i] > THRESHOLD) localCount++; } return localCount; }, localCount => Interlocked.Add(ref total, localCount) ); return total; } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedMultithreadedVectorisedOptimised(int[] array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 5_000; int vectorSize = Vector<int>.Count; int length = array.Length; const int BLOCK_SIZE = 1_000_000; // Might not be optimal, adjust as needed. int total = 0; Parallel.For( 0, (length + BLOCK_SIZE - 1) / BLOCK_SIZE, () => 0, // Initial local count for each thread (chunkIdx, _ /* state - not used */, localCount) => { int start = chunkIdx * BLOCK_SIZE; int end = Math.Min(start + BLOCK_SIZE, length); Vector<int> count = new(); int i = start; var threshold = new Vector<int>(THRESHOLD); for (; i <= end - vectorSize; i += vectorSize) { var v = new Vector<int>(array, i); var mask = Vector.GreaterThan(v, threshold); count = Vector.Subtract(count, mask); } localCount += Vector.Sum(count); // Handle the leftover values that didn't fit in a Vector<int> for (; i < end; i++) { if (array[i] > THRESHOLD) localCount++; } return localCount; }, localCount => Interlocked.Add(ref total, localCount) ); return total; } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeed(ReadOnlySpan<int> array) { const int THRESHOLD = 5_000; int count = 0; foreach (int element in array) { if (element > THRESHOLD) { count++; } } return count; } [MethodImpl(MethodImplOptions.AggressiveOptimization)] static int testSpeedOptimised(ReadOnlySpan<int> array) { const int THRESHOLD = 5_000; int count = 0; foreach (int element in array) { count += element > THRESHOLD ? 1 : 0; } return count; } } 

Results

| Method | Mean | Error | StdDev | Ratio | Allocated | Alloc Ratio | |------------------- |-----------:|----------:|----------:|------:|----------:|------------:| | Original | 317.927 ms | 2.0464 ms | 1.9142 ms | 1.00 | 200 B | 1.00 | | Optimised | 44.469 ms | 0.4871 ms | 0.4557 ms | 0.14 | 33 B | 0.17 | | Vectorised | 20.041 ms | 0.3954 ms | 0.3698 ms | 0.06 | 12 B | 0.06 | | BetterVectorised | 16.191 ms | 0.2009 ms | 0.1879 ms | 0.05 | 12 B | 0.06 | | MtVectorised | 6.755 ms | 0.0590 ms | 0.0523 ms | 0.02 | 7806 B | 39.03 | | MtBetterVectorised | 6.590 ms | 0.1058 ms | 0.0990 ms | 0.02 | 7824 B | 39.12 | 

Observations

• The simple inner loop change to count += (element > 100) ? 1 : 0; suggested by u/PeterCordes makes a huge difference, making it seven times faster.
• The BetterVectorised() version makes minor difference.
• The multithreaded vectorised version is around fifty times faster than the original version, at the expense of around 8K of additional memory usage.

You could try with a for loop rather than a foreach, but it seems the ASM is the same for those.

Either way, you need to use a tool such as BenchmarkDotNet for accurate results, do not rely on the stopwatch.

int[] _array; [GlobalSetup] public static void Setup() { string desktopPath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop); string fullPath = Path.Combine(desktopPath, "RandomFile.dat"); if (!File.Exists(fullPath)) { Console.WriteLine("The file does not exist."); return; } byte[] byteArray = File.ReadAllBytes(fullPath); _array = ByteArrayToIntArray(byteArray); } [Benchmark] [MethodImplAttribute(MethodImplOptions.AggressiveOptimization)] public static int TestSpeed() { var array = _array; if (array == null) throw new ArgumentNullException(nameof(array)); if (array.Length == 0) throw new ArgumentException("Empty array", nameof(array)); int count = 0; for (var i = 0; i < array.Length; i++) { if (array[i] > 100) count++; } return count; } 

You may also find that unrolling it will speed it up significantly. Try either 128- or 256-bit unroll, so either 4 or 8 step, depending on your processor. Removing branching is also likely to give a good speedup.

[Benchmark] [MethodImplAttribute(MethodImplOptions.AggressiveOptimization)] public static int TestSpeed2() { var array = _array; if (array == null) throw new ArgumentNullException(nameof(array)); if (array.Length == 0) throw new ArgumentException("Empty array", nameof(array)); int count = 0; int i = 0; for (; i < array.Length - 8; i += 8) { var temp0 = array[i] > 100; var temp1 = array[i + 1] > 100; var temp2 = array[i + 2] > 100; var temp3 = array[i + 3] > 100; var temp4 = array[i + 4] > 100; var temp5 = array[i + 5] > 100; var temp6 = array[i + 6] > 100; var temp7 = array[i + 7] > 100; count += Unsafe.As<bool, int>(ref temp0) + Unsafe.As<bool, int>(ref temp1) + Unsafe.As<bool, int>(ref temp2) + Unsafe.As<bool, int>(ref temp3) + Unsafe.As<bool, int>(ref temp4) + Unsafe.As<bool, int>(ref temp5) + Unsafe.As<bool, int>(ref temp6) + Unsafe.As<bool, int>(ref temp7); } for (; i < array.Length; i++) { if (array[i] > 100) { count++; } } return count; } 

You could even try using SIMD, with Vector<int>. A faster version of @MatthewWilson's parallelizes the summing, then horizontally sums only the final result, rather than horizontally summing on each loop. You can also use Unsafe.Add to avoid bounds checks.

[MethodImplAttribute(MethodImplOptions.AggressiveOptimization)] public static int testSpeedVectorised(ReadOnlySpan<int> array) { if (array.Length == 0) throw new ArgumentException(); const int THRESHOLD = 100; Vector<int> count = new(); int vectorSize = Vector<int>.Count; // initialize vector with all values the same var threshold = new Vector<int>(THRESHOLD); // Vectorised loop int i = 0; ref int start = ref MemoryMarshal.GetReference(array); for (; i <= array.Length - vectorSize; i += vectorSize) { var v = new Vector<int>(MemoryMarshal.CreateReadOnlySpan(Unsafe.Add(ref start, i), vectorSize)); var mask = Vector.GreaterThan(v, threshold); // Each 'true' in mask is -1, so we use Vector.Subtract rather than Vector.Add // Therefore, we subtract it from count rather than adding it. count = Vector.Subtract(count, mask); } var totalCount = Vector.Sum(count); // Handle the leftover values that didn't fit in a Vector<int> for (; i < array.Length; i++) { if (Unsafe.Add(ref start, i) > THRESHOLD) totalCount++; } return totalCount; }