Найти комбинацию соседних чисел, имеющих самое большое произведение

А кроме прямого перебора никакие оптимизированные методы не искали?

Если бы речь шла про сумму, можно было бы все распараллелить и оптимизировать через операцию свертки (Conv2D в данном случае) с несколькими ядрами. С другой стороны, так как числа по определению > 0, то логарифм произведения есть сумма логарифмов. Так что можно посчитать поэлементно логарифм, а потом применить операцию свертки.
PS — идея абсолютно не протестирована ).

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

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

UPD: я подумал еще раз и понял, что сильно быстрее не станет, извиняюсь.

Комментария для автора: А можно более реальные алгоритмы разбирать? Например выборку-формулы для trend \ hot допустим видео, как делают такое на разных сайтах.

Спасибо, интересная задача!
Я применил некоторые оптимизации, результат ускоряется очень сильно. Понятно, что 20x20 будет работать быстро и без опnимизаций, поэтому я мерил производительность на двух случаях: 1) матрица 10,000x10,000, заполненная случайными значениями, и 2) матрица 1,000x1,000, заполненная «наихудшими» значениями так, чтобы максимальное произведение четырех соседних элементов было в самом конце.
Без оптимизаций первый вариант я не дождался, когда закончит вычисления, а второй вариант — 30 секунд.
Оптимизация, которую нашел vesper-bot, — пропускать числа, умножение которых на 99*99*99 будет меньше уже найденного результата, улучшает сильнее всего — «случайный» вариант ускоряется до 8 секунд, наихудший — никак не ускоряется (так как я специально подбирал для него значения!)
Кроме этого, если текущее значение = 99*99*99*99, то можно дальше не искать, так как это максимально возможный результат. Это ускоряет случайный вариант до 6 секунд.
Далее, так как перебирать всех соседей всех клеток на каждом шаге дорого, то до начала работы можно вычислить уникальные пути из четырех клеток. Их оказалось всего 102. Это ускоряет случайный вариант до 3 секунд, а наихудший — с 30 до 2 секунд.
При этом в случайном варианте заполнение матрицы случайными значениями занимает больше времени, чем решение задачи. Поэтому последня оптимизация — не создавать всю матрицу с нуля, а создать первые 4 строчки, а потом сдвигать их вверх, вычисляя четвертую строчку на каждом шаге. Также, на данном этапе проверка выхода за границу матрицы уже дает ощутимый вклад, поэтому еще одна оптимизация — расширить матрицу на три клетки во все стороны, заполненные нулями. Это ускоряет случайный вариант до 0.2 секунд, а наихудший — до 1 секунды, больше я ускорить не смог. Еще я проверил идею заменить произведение суммой логарифмов, но особо результат не ускорился (но и не замедлился).

Интересно, что хотя сложность задачи совершенно явно O(n*n), но для случайной матрицы, если она достаточно большая, рано или поздно найдется максимальное произведение (99*99*99*99), и дальше можно будет не искать. Учитывая, что оптимизированная версия создает матрицу построчно, скорость работы в среднем случае для случайной матрицы, похоже, будет O(n). Именно поэтому «случайный» вариант работает в 10 раз быстрее на большей матрице.

я бы построил граф с весами и нашел Гамильтонову цепь глубиной 4 (в Вашем случае). Поскольку у Вас достаточно жесткая структура(матрица), то так же можно легко построить список деревьев (те самые «уникальные пути») и пройтись по ним, найдя дерево с самым большим весом. НЕ используйте массивы для таких задач