Сегодня хотел бы рассказать про то как в компиляторе представлена профильная информация и как она предсказывается. Студентам и просто людям часто выносит мозг тот факт что компилятор статически (т.е. без реального исполнения) может предсказывать такие вещи как количество итераций у цикла или просто вероятности переходов, поэтому расскажу об этом по подробнее.
четверг, 26 мая 2016 г.
четверг, 12 мая 2016 г.
Пишем "Hello, world" на ассемблере
Так сложилось, что я совсем не знаю ассемблера. Даже несмотря на то, что я разрабатываю компиляторы, на уровень близкий к аппаратуре я почти не спускаюсь. Была пара попыток его выучить, но я просто не находил подходящего материала. В итоге решил что если его нет, то нужно написать самому. В этой заметке я планирую показать как написать простой Hello world на ассемблере.
В данной статье я преследую несколько целей:
В данной статье я преследую несколько целей:
- Изучить основы работы с ассемблером
- Сравнить ассемблеры процессоров различных архитектур и, как следствие, показать разные аппаратные особенности
- Написать материал по которому новички далее смогут самостоятельно продолжить изучение ассемблера
суббота, 9 января 2016 г.
Собираем кросс-компилятор gcc для sparc
Бывает, что перед разработчиком встаёт задача собрать проект, запускающийся на одной платформе, но при этом для разработки проекта используется другая. Для этих целей применяется кросс-компилятор - специальная сборка компилятора, работающая на host-платформе, и генерирующая код для target-платформы. Здесь я расскажу как собирать gcc с хостом на x86, генерирующий код под sparc.
вторник, 15 декабря 2015 г.
Опасность вызова функций без объявленного прототипа в C
Ещё один пост про тонкости линковки. Предыдущий лежит здесь. На этот раз речь пойдёт преимущественно о старых исходниках, переносе их в 64-х битный режим, ну и немного про режим сборки "вся программа". Пример основан на реальных событиях исходниках.
суббота, 9 мая 2015 г.
Лекции по оптимизирующим компиляторам
В последние несколько месяцев занимался довольно новым для себя делом - читал лекции по курсу "Оптимизирующие компиляторы". Раньше мне не приходилось читать лекции (ну или почти не приходилось), да и предмет не самый распространённый. В общем о том что получилось, что хочется дополнить и исправить расскажу ниже.
воскресенье, 29 марта 2015 г.
Антикафе GeekTime (почти реклама)
Расскажу про один интересный проект, к которому имею некоторое отношение. Это антикафе GeekTime (не путать с сайтом, имеющим похожее название ;) ).
среда, 3 декабря 2014 г.
Наведённые эффекты от оптимизаций
При работе с оптимизациями могут возникать весьма забавные наведённые эффекты. Они не очевидным образом влияют на скорость исполнения программ. Возьмём, например, мой недавний strict-aliasing. Когда я его исследовал столкнулся со следующим явлением:
В таблице приведены опции компиляции теста и замеры при его исполнении. Видно, что применение strict-aliasing просаживает тест на 15%. Во-первых это очень много, а во-вторых совершенно непонятно почему. Ведь strict-aliasing это даже не оптимизация, а анализ, который разрывает зависимости между LOAD/STORE. Как можно замедлить программу разорвав несколько лишних зависимостей? Оказывается легко.
В Эльбрусах есть аппаратная поддержка технологии dam (memory access disambiguation). В двух словах она делает следующее. Если на этапе компиляции невозможно определить ни независимость, ни пересечение операций, а LOAD очень хочется закинуть за STORE, то это можно сделать, и ниже поставить проверку адресов, по которым работают эти операции. Если они не совпадают, то всё хорошо, если совпадают, то уходим на компенсирующий код и делаем всё по-старому.
Так вот, теперь как это связано со strict-aliasing. Внезапно на одном тесте strict-aliasing определил независимость операций, с которыми ранее работал dam. Из-за этого dam'у пришлось применяться к другим операциям, которые по факту оказались зависимыми. Из-за этого много времени ушло на компенсирующий код, и исполнение деградировало. Теперь смотрим без dam:
Видно, что тест более не деградирует, однако исполняется заметно медленнее.
А мораль отсюда такова: даже если в целом оптимизация ведёт себя хорошо - обязательно найдётся тест, который будет работать медленнее.
"-O3" :442.34:real:438.46:user:0.51:sys
"-O3 -fno-strict-aliasing" :376.43:real:374.28:user:0.39:sysВ таблице приведены опции компиляции теста и замеры при его исполнении. Видно, что применение strict-aliasing просаживает тест на 15%. Во-первых это очень много, а во-вторых совершенно непонятно почему. Ведь strict-aliasing это даже не оптимизация, а анализ, который разрывает зависимости между LOAD/STORE. Как можно замедлить программу разорвав несколько лишних зависимостей? Оказывается легко.
В Эльбрусах есть аппаратная поддержка технологии dam (memory access disambiguation). В двух словах она делает следующее. Если на этапе компиляции невозможно определить ни независимость, ни пересечение операций, а LOAD очень хочется закинуть за STORE, то это можно сделать, и ниже поставить проверку адресов, по которым работают эти операции. Если они не совпадают, то всё хорошо, если совпадают, то уходим на компенсирующий код и делаем всё по-старому.
Так вот, теперь как это связано со strict-aliasing. Внезапно на одном тесте strict-aliasing определил независимость операций, с которыми ранее работал dam. Из-за этого dam'у пришлось применяться к другим операциям, которые по факту оказались зависимыми. Из-за этого много времени ушло на компенсирующий код, и исполнение деградировало. Теперь смотрим без dam:
"-O3 -fno-dam" :471.28:real:468.70:user:0.39:sys
"-O3 -fno-dam -fno-strict-aliasing" :473.76:real:470.96:user:0.36:sysВидно, что тест более не деградирует, однако исполняется заметно медленнее.
А мораль отсюда такова: даже если в целом оптимизация ведёт себя хорошо - обязательно найдётся тест, который будет работать медленнее.
Подписаться на:
Комментарии (Atom)