Reciprocal throughput

Вот пусть компиляторы этой оптимизацией и занимаются (и развиваются для всё большей и большей оптимизации). Оставьте такую глубокую оптимизацию человеку строго только для случаев когда такая оптимизация жизненно необходима (и такая необходимость уже явно определена и утверждена "свыше" по результатам бенчмарков с менее глубокой оптимизацией).

Ну а вторым способом даже глубокой явной оптимизации могут стать нейросети а-ля ChaptGPT - если какой-то код надо будет явно с оптимизировать - то можно было бы скармливать менее оптимальный код нейронке - а та уже преобразовывала его в более оптимальный и прогоняла тесты (чтобы убедиться, что ничего не сломалось). Но, в большинстве случаев, надо стремиться чтобы такую оптимизацию в большинстве случаев неявно выполняли компиляторы.

А чтобы компиляторы эффективнее развивались и могли эффективно оптимизировать выходной код - нужно больше развивать идею компиляции через единый промежуточный язык .

А то и даже целых два слоя промежуточных языков, между которыми можно разместить дополнительный оптимизатор - второй слой уже платформенно-зависимый, но ещё не конечный - тут я намекаю на то, приложение может компилироваться при установке под определённую платформу (среду исполнения) с оптимизацией под неё но оставаясь всё ещё на промежуточном ЯП (просто более низкоуровневом), который уже будет компилироваться при исполнении (с кешированием на будущие старты) с продолжающимся сбором статистики исполнения и возможностью динамически перекомпилироваться иначе.

Ну а первый слой промежуточного ЯП при этом может оставаться достаточно высокоуровневым, содержащим много метаданных и высокоуровневых инструкций. Он хорошо для этапа слияния библиотек, написанных в т.ч. на разных исходных ЯП, друг с другом - т.е. это по сути продвинутая линковка.

Вот тогда можно будет куда больше внимания уделять уже более-менее стандартизированным компиляторам из промежуточного ЯП - не распыляясь на кучу исходных языков программирования, с толков вкладывая ресурсы в разработку таких компиляторов, зная что эти вложения будут полезны очень большому числу потребителей (и программистам) и очень надолго, в т.ч. для будущих ЯП. Ну и производить анализ и компиляцию единого стандартизированного упрощённого промежуточного ЯП куда проще - чем плясать от исходников на высокоуровневых языках программирования.

Да да - я всецело повторяю идеологию заложенную Крисом Латтнером в LLVM и перешедшую в WASM и MLIR - надо продолжать её развитие

Байка о том, что при(for i = 0; i < array.Length; i++)

(array.Length непосредственно в for'е) компилятор отказывается от проверок выхода за границы - это таки байка?

Если идти до конца то надо ещё запараллелить https://dotnetfiddle.net/rXS8mF
Заодно переделал на Span, и убрал unsafe.
Скорость не проверял, но надеюсь будет быстрее...

	public static long SumSimdParallel(long[] array)
	{
		var degreeOfParallelism = Math.Max(Vector<long>.Count, (int)BitOperations.RoundUpToPowerOf2((uint)Environment.ProcessorCount));
		var sums = new long[degreeOfParallelism];
		var len = array.Length / degreeOfParallelism;
		
		//Console.WriteLine($"ProcessorCount = {Environment.ProcessorCount}");
		//Console.WriteLine($"degreeOfParallelism = {degreeOfParallelism}");
		//Console.WriteLine($"len = {len}");
		//Console.WriteLine($"Count = {Vector<long>.Count}");

		Parallel.For(0, degreeOfParallelism, idx =>
		{
			var vectorSize = Vector<long>.Count;
			
			var span = array.AsSpan(idx * len, len);
			var vectorSum = new Vector<long>(span);
			span = span.Slice(vectorSize);
			while (span.Length >= vectorSize)
			{
				vectorSum += new Vector<long>(span);
				span = span.Slice(vectorSize);
			}
			sums[idx] = Vector.Dot(vectorSum, Vector<long>.One);
		});
		
		return SumSimd(sums);
	}	

Тот же изначальный код на плюсах, если попросить -O3 и -mavx2: https://godbolt.org/z/nEKodK8c1

unsigned long sum_array(unsigned long* array, unsigned long size) 
{
    unsigned long sum = 0;
    for (unsigned long i = 0; i < size; ++i)
         sum += array[i];
    return sum;
}

Сразу генерится, в такой внутренний цикл:

.L4:
        vpaddq  ymm0, ymm0, YMMWORD PTR [rax]
        add     rax, 32
        cmp     rax, rdx
        jne     .L4

и тут вряд ли что-то можно улучшить.

А вроде никто не написал такой трюк - если учитывать размер строки кэша, которая при обращении к памяти выбирается целиком, то может оказаться, что преобразование кода в два вложенных цикла, из которых внутренний будет перебирать данные, целиком помещаемые в такую строку, ускорит еще?

И почему-то никто не вспомнил про foreach, который для массивов не использует итератор и быстрее for.