Комментарии 16
Что означает синяя полоса слева?
Что означает её отсутствие?
Тема, наверное, интересная, но читать решительно невозможно.
Начиная с ненужных ударений, заканчивая непонятным стилем всей статьи, страннымр предположниями, листингами и прочим. Ну и про Луа тоже неясно ничего, как и про АРМ, Итаниум и т.д.
Впечатление, что это какой-то отрывок курса 15-20-летней давности, притом непонятно как оформленный.
А так, повторюсь, тема неплохая.
За упоминание Lua ЗДЕСЬ извиняюсь — по инерции (Lua используется в ином модуле системы — habr.com/ru/post/530078). Ударения ставил только там, где подозревал СОМНЕНИЯ читающих (давно с народом общаюсь, знаете ли, отношения с языком страны проживания у многих недостаточно уважительные)…
Спасибо, приятно увидеть такой стиль изложения средь моря околоайтишной журналистики. Хабр иногда ещё торт.
А что автор думает про провал Intel Itanium веренее про компиляторы так и не смогли реализовать все задумки которые были заложены в железо. Может существующие языки программирования не пригодны для подобной архитектуры и требуется нечто-то иное?
Например: halide-lang.org пытается решить задачу разделив представление, размещение и дозирование данных, алгоритм, и порядок исполнения программы, что бы хоть как-то упростить жизнь программистам со всеми этими хитрыми ядрами, векторизациями и кешами.
Например: halide-lang.org пытается решить задачу разделив представление, размещение и дозирование данных, алгоритм, и порядок исполнения программы, что бы хоть как-то упростить жизнь программистам со всеми этими хитрыми ядрами, векторизациями и кешами.
Внутри Intel не сИживал… Много публикаций о мАлой «плотности кода» (мыслю, что что «связка» команд очень малозаполнена и работа близкА к последовательному выполнению). Имеено поэтому пришло в голову переформировать ЯПФ так, чтобы
обеспечить требуемое (https://habr.com/ru/post/530078/)… Далее — весь soft надо перекомпилировать (сложным компилятором, «умеющим» заолнять командами всю «связку»). Для серверов нет проблем — soft довольно однообразный. Потом «лучше побольше привЫчного, чем неривЫчное». Подозреваю (уверен!), что Intel на Itanium накопил МНОГО знаний и наступит время их активного применения!..
обеспечить требуемое (https://habr.com/ru/post/530078/)… Далее — весь soft надо перекомпилировать (сложным компилятором, «умеющим» заолнять командами всю «связку»). Для серверов нет проблем — soft довольно однообразный. Потом «лучше побольше привЫчного, чем неривЫчное». Подозреваю (уверен!), что Intel на Itanium накопил МНОГО знаний и наступит время их активного применения!..
Плотность кода это только вершина айсберга. Для вычислений надо подводить и отводить обрабатываемые данные. Тут тоже не всё так тривиально как хотелось бы.
Это важная (вторая после работы в SMP-памятью и ГКВ-данными) проблема DF — «накладные расхода пожирают пр-сть»… Поэтому-то и придумали гранулу распараллеливания УВЕЛИЧИТЬ (проект Large-Grain Data Flow; R.I.Babb, Parallel Processing with Large-Grain Data Flow Techniques. Computer, № 07, vol. 17, pp. 55-61, 1984). Однако представьте себе выч. трудоёмкость нахождЕния последовательных цепочек в программе..!
Так проблема шире, не в цепочках дело. Проблема в том что бы эффективно учитывать все ухищрения которые есть в железе приходится писать очень сложный код. Причем сложность растёт экспоненциально, приходиться учитывать слишком много факторов вручную, что очень дорого для императивного описания программы.
Что бы эффективно использовать все возможности современных CPU, GPGPU и DPU вне области для которой они задумывались очень не простая задача. А оптимизировать сферических коней в вакууме вообще неисчерпаемая тема. Поэтому мало кто заморачиваеться и используют готовые библиотеки которые предоставляют производители этого железа.
Что бы эффективно использовать все возможности современных CPU, GPGPU и DPU вне области для которой они задумывались очень не простая задача. А оптимизировать сферических коней в вакууме вообще неисчерпаемая тема. Поэтому мало кто заморачиваеться и используют готовые библиотеки которые предоставляют производители этого железа.
Там еще проблема с энергопотреблением. Одно дело когда числа дробить, там всё здорово и прекрасно параллелится, а вот когда управляющий код с условными переходами тогда настает пичаль — приходится считать несколько веток программы и потом отбрасывать невалидные по предикату, но ведь энергию не отбросить. Получилось что «в реальной жизни» выгоднее сделать более умный диспетчер загрузки исполнителей, нежели перенести его логику в компиляторы и т.п. Да и потому что статикой никогда не обуздаешь динамику. Программы зависят не только от сложности алгоритмов но и еще от входных данных в динамике, поэтому куда проще (выгоднее) добавить в процессор SMT/SIMD для эффективной загрузки вычислительных блоков и снижения энергопотребления. То что происходит на уровне процессора в диспетчере загрузок исполнителей (суперскалярность и OoO) сейчас стали переносить в программы, которые во время исполнения собирают данные по ветвлениям прямо на ходу и специализируют себя увеличивая производительность кода программы на конкретных данных еще больше. По сути специализаторы времени выполнения, JIT
В 80386 появились SETcc, в Pentium pro появились CMOVcc. Первая устанавливает байт в зависимости от флагов. Вторая копирует.
Хоть что-то.
Помню, в системе команд ARM вначале было поле условия выполнения, а потом пропало. Где-то я прочитал, что пропало оно «из-за ненадобности, т.к. современные предсказатели ветвлений очень хорошо работают». В архитектуре RISC-V тоже нет подобных команд. Почему?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Это непростое условное выполнение