caxapa.ru :: Дык я именно об этом. Компилятор не смогли осилить (точнее результат так себе) именно потому, что текст программы уже написан на императивном языке (C, ++, еще что-то), в котором важная информация уже потеряна. Компилятор пытается выцедить параллелизм из текста, изначально подразумевавшего последовательное выполнение. Т.е. сначала программист раскладывает задачу на набор последовательных маленьких шагов, а потом компилятор пытается из фарша слепить стейк.

LightElf (24.12.2021 17:59 - 18:09, просмотров: 323) ответил Mahagam на этой "скрываемой потенциально важной инфы" слишком дохрена. а на каком проце оно будет распараллеливаться? а стоит ли дёргать работой 32 ядра, если поиск в 32-х элементах? а с какого конца лучше искать? да почитай статью про процы на хабре. VLIW не смогли осилить потому что компилятор под это дело хрен напишешь. так там задача проста и ясна - вот текст программы, выдай код чтобы все исполнительные блоки запрячь.

Дык я именно об этом. Компилятор не смогли осилить (точнее результат так себе) именно потому, что текст программы уже написан на императивном языке (C, ++, еще что-то), в котором важная информация уже потеряна. Компилятор пытается выцедить параллелизм из текста, изначально подразумевавшего последовательное выполнение. Т.е. сначала программист раскладывает задачу на набор последовательных маленьких шагов, а потом компилятор пытается из фарша слепить стейк.

Программист знает, что элементов всего 32. Но он использует какую-нибудь библиотечную функцию сортировки, автор которой не знал, что элементов всего 32 и написал универсальное решение. Компилятор, например, знает сколько элементов. Но он не знает как поменять функцию для такого вырожденного случая. Для некоторых простых стандартных функций (типа memset, memcpy) у компиляторов есть эвристики, но для произвольной функции таких эвристик нет, в том числе и потому, что эти функции сами написаны на тех же самых языках.

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

Средства и методы разработки