какая-то порнуха по ссылке

Ленивые вычисления дело такое :)

тут получше

но я бы отсоветовал сильно увлекаться

т.к. в сильно-лямбдированном коде потом не айс разбираться

пздц, некоторые на работе в опенофисе ващет

большое человеческое спасибо

Походу похачили сайт, вебархив показывает нормальное содержимое в прошлом году

перепрофилировались

Опен спейс в смысле ? А то я спнрва подумал ексель там :)))

Ну да. Опенспейс. Разволновался от увиденного ))

Почему автор уверена, что весь массив не поместится в кеш память и проход с начала, а не с конца будет быстрее?

Можно предложить более рациональное на первый взгляд решение задачи: просматривать массив в обратном порядке, суммируя элементы, и завершить цикл, как только встретится отрицательный элемент:

<код>

В этой программе каждый элемент массива анализируется не более одного раза,
а ненужные элементы не просматриваются вообще. Казалось бы, мы позаботились об эффективности, но на самом деле результат может оказаться даже хуже,
чем в предыдущем варианте! Это связано с тем, что в современных процессорах
для оптимизации применяется опережающее чтение в быстродействующую память (кэш), поэтому при «естественном» порядке просмотра массива следующие элементы окажутся в кэше с большей вероятностью.

Ну там надо смотреть что там в ассемблере или байт-коде. Варианты возможны любые, тащемто.

Бенчмарк вас рассудит

железо, компилятор и всё такое, да

вот я тоже за вот этот вариант, а есть те кто утверждает что

Потому что в страйд попадает участок вида adr + положительный оффсет
Он не будет тебе в кеш грузить адреса назад

Я думаю, когда требуется мыслить на таком уровне, то ошибка на уровне выбора языка уже возникает.
Если приходится задумываться об адресах, оптимизации и эффективности, то тут Си + ассемблер.

Я имею в виду _такой эффективности_