caxapa.ru :: Мы пошли по кругу. loop_unroll - это мелкая локальная оптимизация на уровне нескольких инструкций процессора. Я же говорю об оптимизациях совершенно другого масштаба. Когда компилятор, в зависимости от исходных данных сам определяет, а нужен ли вообще этот цикл или можно как-то по-другому задачу решить. Но для этого компилятор должен видеть не конкретную реализацию конкретного алгоритма, а саму задачу целиком. Императивные языки этого не позволяют, а тот же SQL (теоретически)

LightElf (24.12.2021 18:38, просмотров: 267) ответил Mahagam на нет. статью читай. инфы и так дохрена, loop_unroll компиляторы умеют, и паралеллизм находят. просто зависимостей между возможностями и ограничениями исполнительных блоков становится так много, что хре всё учтёшь оптимально.

Мы пошли по кругу. loop_unroll - это мелкая локальная оптимизация на уровне нескольких инструкций процессора. Я же говорю об оптимизациях совершенно другого масштаба. Когда компилятор, в зависимости от исходных данных сам определяет, а нужен ли вообще этот цикл или можно как-то по-другому задачу решить. Но для этого компилятор должен видеть не конкретную реализацию конкретного алгоритма, а саму задачу целиком. Императивные языки этого не позволяют, а тот же SQL (теоретически)

может.

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

Ответить

- иногда человек не знает как задачу решить в целом. а ты хошь чтобы тебе компилятор решение выдал, да не простое, а сразу оптимальное. вот даже простой выбор как хранить большие структуры данных, в виде 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)
        
        А как сейчас юзер делает выбор из 5 вариантов? Всю работу выполняет менеджер пакетов (в линухе), плеймаркет (в андроиде), инсталлятор в винде. Запустился, проверил что за процессор и выкачал бинарник под него. - LightElf(25.12.2021 04:19)

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