Недостаточно информации, чтобы ответить на нее, не делая гораздо больше предположений, которые вы не указали.
Нетривиально векторизовать эту проблему с SIMD, потому что индексирование массива обращено для X[i][j] вместо Y[j][i]. Таким образом, проблема состоит в том, чтобы сделать транспонированную копию массива (и добавить +200) Да, SIMD может помочь, но вам понадобятся инструкции перемешивания и смешивания, а также вертикальное добавление, поэтому детали Многое зависит от деталей перемешивания и смешанных инструкций, которые предоставляет ISA. Или прогуливались грузы или собирали инструкции?
А также о том, насколько умен ваш компилятор, использует ли он вообще SIMD-инструкции. Или, может быть, он загружает вектор и делает +200 с SIMD, но затем рассеивает результат с помощью скаляра? Даже стоимость извлечения элементов вектора в память зависит от ISA. Например, в x86 для SSE2 требовалось отдельное перемешивание, чтобы получить нужный элемент в нижней части вектора. Но SSE4.1 добавил pextrq, который может хранить qword double в памяти. Но его версия AVX может получить доступ только к младшим 2 элементам вектора.
Многоядерные и SIMD не противоречат друг другу, они ортогональны . На самом деле большинство реальных многоядерных процессоров имеют некоторую форму SIMD, потому что инструкции SIMD стоит добавить к одному ядру, прежде чем стоит создавать сложность многоядерного процессора.
Запуск скалярного кода на 4 процессорах обычно является пустой тратой на проблемы с параллелизмом данных. В реальной жизни вы бы векторизовали проблему с SIMD, а затем (если это достаточно большая проблема) разделили ее на несколько потоков для ускорения мультипликативного MIMD x SIMD.
Ускорение использования нескольких потоков для доступа к одним и тем же данным может быть не линейным. Эта проблема касается каждого элемента массива только один раз, поэтому, вероятно, она связана с памятью. Но у него сложная схема доступа. Нет оснований предполагать, что эта проблема будет связана с ALU и масштабируется линейно с количеством ядер. На практике все ядра будут конкурировать для чтения / записи в одну и ту же оперативную память. Или их частные кэши должны прочитать результаты.
При тщательном проектировании транспонирования вы, вероятно, сможете избежать необходимости многократного чтения несколькими потоками одних и тех же строк кэша.
Затраты на запуск также важны для практического использования параллелизма на уровне потоков MIMD. Может быть, предполагается, что вы предполагаете нулевые накладные расходы или что вы делаете это неоднократно для разных массивов с минимальными затратами на синхронизацию? Тогда убедитесь, что вы можете принять нулевые накладные расходы при запуске.
(Если вы не говорите о параллелизме на уровне инструкций в одном ядре. Это бесплатно. Но вы упомянули систему с 4 процессорами, что подразумевает также параллелизм на уровне потоков. Конечно, в реальной жизни, как правило, это только стоит построение нескольких ядер после использования низко висящих фруктов для одного ядра с суперскалярным и SIMD, так что реальный код потенциально может запускать 3 векторных инструкции за такт на каждом ядре, причем каждая команда работает с 8 векторными элементами SIMD.)
например. это то, что вы получите на четырехъядерном процессоре Skylake с одинарной точностью float векторов.
Но вопрос требует от вас тренировки Инструкция Считает?
сравнить количество инструкций, выполненных на машине SIMD с машиной MIMD.
Откуда вы знаете, сколько там циклов и сколько компилятор развертывает.
И что еще более важно, как именно разработаны инструкции перемешивания / смешивания, чтобы вы могли транспонировать.
Интересно, была ли переключенная индексация ошибкой , потому что это гораздо более простая проблема, которую легко поддается простому вертикальному SIMD, если это просто копирование и добавление без транспонирования.