Mahagam (24.12.2021 15:43, просмотров: 276) ответил =AlexD= на А где взять декларативный компилятор для компиляции декларативного
компилятора?-
- Не, процессор остается какой есть. И у него конечно остается
какой-то ассемблер для крайних случаев, всяких там загрузчиков,
кусочков ОС и тыды. И языки типа Цэ никуда не денутся. А вот эта
вся тряхомудия, вроде жаб и прочих котлинов - должна сгинуть, бо
втыкая между железом и целевой задачей 100500 прослоек ничего не
дает в смысле возможностей алгоритмической оптимизации. - LightElf(24.12.2021 15:52)
- Твой компилятор врятли нормально заработает без нейросетки
достаточно большого масштаба. - =AlexD=(24.12.2021 16:32)
- Ну вот к примеру Verilog (который я не знаю). Он, вроде как, вполне
декларативный. То есть описывается что должно получиться, а не
"которую 2И-НЕ с этим триггером соединить". Вроде же справляются
как-то, синтезируют в сильно разные плиски и не жужат. - LightElf(24.12.2021 17:05)
- там как раз примерно "хочу 2и-не и с триггером". ты когда пишешь
int i; не поясняешь, где это i должно быть - в общей куче, на стеке
или в регистре. так и верилог - ты ему "хочу 2И-НЕ", а он тебе "а я
тебе в LUT`ы логику запихнул, оно будет работать, не сумлевайся". - Mahagam(24.12.2021 17:17)
- Ну да, оно (как я понимаю) само выбирает куда запихнуть и что с чем
соединить, чтобы получить заданную логическую функцию. Когда я пишу LightElf(537 знак., 24.12.2021 17:31)
- этой "скрываемой потенциально важной инфы" слишком дохрена. а на
каком проце оно будет распараллеливаться? а стоит ли дёргать
работой 32 ядра, если поиск в 32-х элементах? а с какого конца
лучше искать? да почитай статью про процы на хабре. VLIW не смогли
осилить потому что компилятор под это дело хрен напишешь. так там
задача проста и ясна - вот текст программы, выдай код чтобы все
исполнительные блоки запрячь. - Mahagam(24.12.2021 17:37)
- Дык я именно об этом. Компилятор не смогли осилить (точнее
результат так себе) именно потому, что текст программы уже написан
на императивном языке (C, ++, еще что-то), в котором важная
информация уже потеряна. Компилятор пытается выцедить параллелизм
из текста, изначально подразумевавшего последовательное выполнение.
Т.е. сначала программист раскладывает задачу на набор
последовательных маленьких шагов, а потом компилятор пытается из
фарша слепить стейк. LightElf(518 знак., 24.12.2021 17:59 - 18:09)
- CUDA, OpenCL - там есть подсказки компилеру, что параллелить. - Evgeny_CD(24.12.2021 18:24)
- но туда изначально суют только распараллеливаемые задачи. иначе оно
будет медленнее atom`а - Mahagam(24.12.2021 18:34)
- Это вторая часть проблемы. - Evgeny_CD(24.12.2021 18:59)
- но туда изначально суют только распараллеливаемые задачи. иначе оно
будет медленнее atom`а - Mahagam(24.12.2021 18:34)
- я в своё время пытался обогнать memcpy самописным кодом на ARM7. ничего не получилось. посмотрел в отладчике - там если размер мелкий, то оно копировалось классическим методом, по байтику за раз. но как только размер для копирования был более чем N байт, то организовывался хитрый цикл с командами ldm stm, а некратный N остаток копировался опять же по классике. так что нормальные библиотеки учитывают множество различных случаев. - Mahagam(24.12.2021 18:13)
- нет. статью читай. инфы и так дохрена, loop_unroll компиляторы
умеют, и паралеллизм находят. просто зависимостей между
возможностями и ограничениями исполнительных блоков становится так
много, что хре всё учтёшь оптимально. - Mahagam(24.12.2021 18:03)
- Мы пошли по кругу. loop_unroll - это мелкая локальная оптимизация
на уровне нескольких инструкций процессора. Я же говорю об
оптимизациях совершенно другого масштаба. Когда компилятор, в
зависимости от исходных данных сам определяет, а нужен ли вообще
этот цикл или можно как-то по-другому задачу решить. Но для этого
компилятор должен видеть не конкретную реализацию конкретного
алгоритма, а саму задачу целиком. Императивные языки этого не
позволяют, а тот же SQL (теоретически) LightElf(6 знак., 24.12.2021 18:38)
- иногда человек не знает как задачу решить в целом. а ты хошь чтобы
тебе компилятор решение выдал, да не простое, а сразу оптимальное.
вот даже простой выбор как хранить большие структуры данных, в виде
SoA или AoS ? оно ж зависит от того что с ними делают сейчас, и что
планируют делать завтра. и в каких объёмах. - Mahagam(24.12.2021 18:50)
- Компилятор вполне может просчитать, что в данной конкретной
программе выгоднее и сам выбрать SoA или AoS. Более того, он может
воткнуть код преобразования туда-обратно, если оно того стоит в
конкретном млучае. Вполне может быть, что для VLIW выгоднее одно, а
для обычных процов - другое. - LightElf(24.12.2021 19:03)
- вот только компилятор не знает на чём оно будет исполнятся. и это
ломает всю сказку. в случае VLIW даже при знании того для чего
компилят - и то не могут найти оптимальное решение более простой
задачи - Mahagam(24.12.2021 19:49)
- Почему это не знает? Даже у gcc есть ключи компиляции под
конкретную архитектуру, а уж гипотетическому "языку будущего" они в
обязательном порядке нужны. На дискетах/CD софт давно не
распространяется, а при загрузке с инета можно выдавать юзеру
бинарник, оптимизированный под его систему. Хоть какая-то польза
будет от анальных зондов. LightElf(1 знак., 24.12.2021 20:46, ссылка)
- ключи есть, а вы когда с нета любую софтинку скачиваете, вы вот под
свой конкретно проц скачиваете? или просто x64 версию? то-то и оно.
создавая софт на сторону, никто не будет делать набор сборок под
разные процы. а когда собираете для VLIW TMS320C6747, то вы
собираете под конкретно это ядро C674x. и на другом вы запускать
код не будете без пересборки - Mahagam(24.12.2021 21:09)
- Выглядит как придумывание отмазки ;-) Нет ни одной проблемы делать
сборки со всеми возможными ключами и выдавать их юзеру. Те же
линуховые репозитории держат несколько архитектур и не жужат. Ну
будет не пять вариантов, а пятьдесят. Докупят места на хостинге. Со
всякими гугломаркетами и того проще. - LightElf(24.12.2021 21:58)
- ну 50 вариантов. а как юзер будет знать какой качать? - Mahagam(24.12.2021 22:38)
- Выглядит как придумывание отмазки ;-) Нет ни одной проблемы делать
сборки со всеми возможными ключами и выдавать их юзеру. Те же
линуховые репозитории держат несколько архитектур и не жужат. Ну
будет не пять вариантов, а пятьдесят. Докупят места на хостинге. Со
всякими гугломаркетами и того проще. - LightElf(24.12.2021 21:58)
- ключи есть, а вы когда с нета любую софтинку скачиваете, вы вот под
свой конкретно проц скачиваете? или просто x64 версию? то-то и оно.
создавая софт на сторону, никто не будет делать набор сборок под
разные процы. а когда собираете для VLIW TMS320C6747, то вы
собираете под конкретно это ядро C674x. и на другом вы запускать
код не будете без пересборки - Mahagam(24.12.2021 21:09)
- Почему это не знает? Даже у gcc есть ключи компиляции под
конкретную архитектуру, а уж гипотетическому "языку будущего" они в
обязательном порядке нужны. На дискетах/CD софт давно не
распространяется, а при загрузке с инета можно выдавать юзеру
бинарник, оптимизированный под его систему. Хоть какая-то польза
будет от анальных зондов. LightElf(1 знак., 24.12.2021 20:46, ссылка)
- вот только компилятор не знает на чём оно будет исполнятся. и это
ломает всю сказку. в случае VLIW даже при знании того для чего
компилят - и то не могут найти оптимальное решение более простой
задачи - Mahagam(24.12.2021 19:49)
- Компилятор вполне может просчитать, что в данной конкретной
программе выгоднее и сам выбрать SoA или AoS. Более того, он может
воткнуть код преобразования туда-обратно, если оно того стоит в
конкретном млучае. Вполне может быть, что для VLIW выгоднее одно, а
для обычных процов - другое. - LightElf(24.12.2021 19:03)
- иногда человек не знает как задачу решить в целом. а ты хошь чтобы
тебе компилятор решение выдал, да не простое, а сразу оптимальное.
вот даже простой выбор как хранить большие структуры данных, в виде
SoA или AoS ? оно ж зависит от того что с ними делают сейчас, и что
планируют делать завтра. и в каких объёмах. - Mahagam(24.12.2021 18:50)
- Мы пошли по кругу. loop_unroll - это мелкая локальная оптимизация
на уровне нескольких инструкций процессора. Я же говорю об
оптимизациях совершенно другого масштаба. Когда компилятор, в
зависимости от исходных данных сам определяет, а нужен ли вообще
этот цикл или можно как-то по-другому задачу решить. Но для этого
компилятор должен видеть не конкретную реализацию конкретного
алгоритма, а саму задачу целиком. Императивные языки этого не
позволяют, а тот же SQL (теоретически) LightElf(6 знак., 24.12.2021 18:38)
- CUDA, OpenCL - там есть подсказки компилеру, что параллелить. - Evgeny_CD(24.12.2021 18:24)
- Дык я именно об этом. Компилятор не смогли осилить (точнее
результат так себе) именно потому, что текст программы уже написан
на императивном языке (C, ++, еще что-то), в котором важная
информация уже потеряна. Компилятор пытается выцедить параллелизм
из текста, изначально подразумевавшего последовательное выполнение.
Т.е. сначала программист раскладывает задачу на набор
последовательных маленьких шагов, а потом компилятор пытается из
фарша слепить стейк. LightElf(518 знак., 24.12.2021 17:59 - 18:09)
- этой "скрываемой потенциально важной инфы" слишком дохрена. а на
каком проце оно будет распараллеливаться? а стоит ли дёргать
работой 32 ядра, если поиск в 32-х элементах? а с какого конца
лучше искать? да почитай статью про процы на хабре. VLIW не смогли
осилить потому что компилятор под это дело хрен напишешь. так там
задача проста и ясна - вот текст программы, выдай код чтобы все
исполнительные блоки запрячь. - Mahagam(24.12.2021 17:37)
- Ну да, оно (как я понимаю) само выбирает куда запихнуть и что с чем
соединить, чтобы получить заданную логическую функцию. Когда я пишу LightElf(537 знак., 24.12.2021 17:31)
- там как раз примерно "хочу 2и-не и с триггером". ты когда пишешь
int i; не поясняешь, где это i должно быть - в общей куче, на стеке
или в регистре. так и верилог - ты ему "хочу 2И-НЕ", а он тебе "а я
тебе в LUT`ы логику запихнул, оно будет работать, не сумлевайся". - Mahagam(24.12.2021 17:17)
- Ну вот к примеру Verilog (который я не знаю). Он, вроде как, вполне
декларативный. То есть описывается что должно получиться, а не
"которую 2И-НЕ с этим триггером соединить". Вроде же справляются
как-то, синтезируют в сильно разные плиски и не жужат. - LightElf(24.12.2021 17:05)
- там другая оптимизация - как написать пиздец какой сложный софт
скудным человеческим умишком. и чтобы он не разваливался на ходу. - Mahagam(24.12.2021 16:31)
- Придумать свою прослоечку. Круг замкнулся! - VLLV(24.12.2021 16:44)
- Твой компилятор врятли нормально заработает без нейросетки
достаточно большого масштаба. - =AlexD=(24.12.2021 16:32)
- Не, процессор остается какой есть. И у него конечно остается
какой-то ассемблер для крайних случаев, всяких там загрузчиков,
кусочков ОС и тыды. И языки типа Цэ никуда не денутся. А вот эта
вся тряхомудия, вроде жаб и прочих котлинов - должна сгинуть, бо
втыкая между железом и целевой задачей 100500 прослоек ничего не
дает в смысле возможностей алгоритмической оптимизации. - LightElf(24.12.2021 15:52)