[00:28:27] <ada_ru> (I_vlxy_I) ну, вот так оно компиляется на ev3:
[00:28:33] <ada_ru> (I_vlxy_I) robot@ev3dev:~/ada1$ time gnatmake hello.adb
gcc-4.9 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
real 0m33.913s
user 0m3.790s
sys 0m9.950s
[00:29:54] <ada_ru> (I_vlxy_I) ну и, для чистоты эксперимента, второй раз:
[00:30:00] <ada_ru> (I_vlxy_I) $ time gnatmake hello.adb
gcc-4.9 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
real 0m23.134s
user 0m4.550s
sys 0m8.670s
[00:31:29] <ada_ru> (I_vlxy_I) третий, и последующие разы:
[00:31:35] <ada_ru> (I_vlxy_I) $ time gnatmake hello.adb
gcc-4.9 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
real 0m18.611s
user 0m9.000s
sys 0m4.030s
[00:31:56] <ada_ru> (I_vlxy_I) так что да, в 5-10 раз быстрее в докере получается через qemu-user
[00:32:11] <ada_ru> (I_vlxy_I) А главное - у десктопа ОЗУ сильно больше
[12:55:44] <ada_ru> (I_vlxy_I) Гм. Мне изменяет память, или действительно hello world на турбопаскале на 386 компилировался около секунды?
[13:04:35] <ada_ru> (I_vlxy_I) Выходит современные компили раз в 100-300 медленней компилируют.
[13:07:38] <ada_ru> (IvanAlf) Действительно. Только турбопаскаль вроде слыхом не слыхивал такое слово как "оптимизации". После него дизассеблировал я код, так там построчное переложение кода на машинные инструкции. Ни скорости, ни размера.
[13:08:52] <ada_ru> (IvanAlf) Т.е. если написать a := 10; a := 20; то в машинных кодах будет ровно это. Сперва присвоение 10, потом присвоение 20.
[13:09:18] <ada_ru> (I_vlxy_I) Дык я и Аду собирал же с параметрами оптимизации по умолчанию
[13:09:24] <ada_ru> (I_vlxy_I) То есть O0
[13:09:42] <ada_ru> (I_vlxy_I) То есть без оптимизаций - максимальная скорость компиляции
[13:10:50] <ada_ru> (I_vlxy_I) В общем понятно почему турбопаскаль тогда занимал примерно ту же нишу, что сейчас питон :-)
[13:15:54] <ada_ru> (IvanAlf) Вроде всё равно, даже на -O0 какие-то примитивные оптимизации делаются. Просто команды транслируются последовательно в машинный код, а не размазываются в спагетти, как при более высоких оптимизациях.
[13:16:42] <ada_ru> (I_vlxy_I) Надо глянуть. Вроде лишние присваивания, как в примере выше, остаются.
[13:16:58] <ada_ru> (IvanAlf) Ну и опять же gcc - целая куча конвейеров. Компилятор, оптимизатор, компилятор в ассемблер, ассемблер, линкер =)
[13:17:52] <ada_ru> (I_vlxy_I) Такая себе отмазка :-)
[13:18:34] <ada_ru> (I_vlxy_I) Ты еще скажи, что Ада намного более сложный и мощный язык нежели турбопаскаль :-)
[13:19:02] <ada_ru> (IvanAlf) Вот чего не помню, того не помню. Гарантированно пустые присваивания останутся, только если переменная как volatile помечена (в сях, не знаю, есть ли такое в аде).
[13:21:45] <OCTAGRAM> по регистрам Турбо Паскаль раскладывает, это ведь оптимизация
[13:23:37] <OCTAGRAM> бинарный формат TPU устраняет повторный парсинг; в GNAT есть ALI, но не факт, что настолько же полезный
[13:23:46] <ada_ru> (IvanAlf) Ну тут скорее не в Аде дело, а в универсальности GCC стека. А за это приходится тормозами расплачиваться.
[13:24:18] <OCTAGRAM> в GCC ассемблерный код текстом передаётся постоянно
[13:25:17] <OCTAGRAM> это, скорее, юникс-вейность, текстовые потоки вместо объектов, как в SOM, или интерфейсов, как в COM
[13:25:47] <ada_ru> (I_vlxy_I) Это оптимизация бекенда.
[13:26:39] <ada_ru> (I_vlxy_I) (раскладка по регистрам)
[13:29:57] <OCTAGRAM> а если компилятор получает какое-то значение в ax, и если оно ноль, то и вернуть из функции нужно значение, которое представлено 0 в ax, хотя это может быть другой тип, и компилятор видит это дело и ставит условный прыжок сразу в конец, это оптимизация?
[13:30:55] <ada_ru> (I_vlxy_I) Если бы hello world компилировался на 386 300 секунд, кажется на таком яп никто бы не писал. А сейчас выходит, что на тройке ада собиралссь бы как раз около 300 секунд.
[13:32:27] <OCTAGRAM> но вообще, когда я переходил с Турбо Паскаля и Делфи на Аду, мне бросилось в глаза, что в Турбо Паскале и Делфи — ассемблерные вставки, а на Аде — ассемблерные шаблоны с дотошным указанием регистров и зависимостей по данным, так что да, там возможностей для оптимизации явно побольше, раз такие требования
[13:34:46] <Vovanium> По идее пустые присваивания должны оставаться на случай отладки по шагам. На высоких уровнях оптимизации правда отладчик может заявить, что переменная "optimized out".
[13:36:15] <ada_ru> (IvanAlf) Вообще надо сравнить gc и gccgo. На тему разницы в скорости компиляции.
[13:37:32] <ada_ru> (IvanAlf) Понятно, что gc будет быстрее, но вот вопрос в том насколько?
[13:39:07] <ada_ru> (IvanAlf) На счёт неиспользуемых переменных ругается обычно компилятор, когда ему сказано ругаться warning-ами.
[13:42:40] <ada_ru> (I_vlxy_I) Go на такое ошибку компиляции выдает :-)
[13:42:57] <ada_ru> (IvanAlf) Ну да.. В го ворнингов нет =)
[13:44:09] <ada_ru> (IvanAlf) А в хаскеле ещё проще. Там нет переменных =)
[13:51:51] <ada_ru> (I_vlxy_I) ну, собственно пруф на тему оптимизаций: https://godbolt.org/g/TEP4bJ
[13:52:22] <ada_ru> (I_vlxy_I) при O0 нет оптимизаций.
[13:52:37] <ada_ru> (I_vlxy_I) все заточено на максимальную скорость компиляции и удобство отладки
[13:53:09] <ada_ru> (I_vlxy_I) однако собирается 30 секунд на 300 Мгц камне. hello world.
[14:02:14] <ada_ru> (IvanAlf) Да, действительно, совершенно дубовый опкод получается. Значит львиную долю времени отжирает цепочка все gcc-шных тулзов. Там же на этой машинке ещё и оперативы небось кот наплакал?
[14:02:31] <ada_ru> (I_vlxy_I) да дофигища оперативы
[14:02:33] <ada_ru> (I_vlxy_I) 64 метра!
[14:02:53] <ada_ru> (I_vlxy_I) я смотрел - во время компиляции оного хелловорлда оно в своп не уходит
[14:02:57] <ada_ru> (I_vlxy_I) и даже половины не выжирает
[14:04:37] <ada_ru> (I_vlxy_I) это вам не 80386 с парой метров рамы 😊
[14:26:11] <ada_ru> (IvanAlf) Сейчас попробую на "жирненьком" allwinner a10 с гигом рамы собрать.
[14:30:01] <ada_ru> (IvanAlf) # time gnat compile helloworld.adb
gcc-4.9 -c helloworld.adb
real 0m3.228s
user 0m0.630s
sys 0m0.300s
# time gnat compile helloworld.adb
gcc-4.9 -c helloworld.adb
real 0m0.655s
user 0m0.490s
sys 0m0.110s
[14:31:17] <ada_ru> (IvanAlf) В общем получается при первом прогоне он складывается все gcc-шные тулзы с флеша в кэши, и тупит. При втором уже прям из рамы берёт.
[14:32:38] <ada_ru> (IvanAlf) На 64метрах видимо всё в кэш не лезет, и ему каждый раз надо всю цепочку подгружать с флеша.
[14:35:20] <ada_ru> (I_vlxy_I) не всю. я ж там несколько прогонов выкладывал.
[14:35:44] <ada_ru> (I_vlxy_I) первый - 30 секунд, второй - 23 секунды, а последующие примерно по 18 секунд
[14:35:55] <ada_ru> (IvanAlf) На сях картина не намного веселее:
[14:36:07] <ada_ru> (IvanAlf) # time gcc helloworld.c
real 0m2.043s
user 0m0.330s
sys 0m0.230s
# time gcc helloworld.c
real 0m0.427s
user 0m0.230s
sys 0m0.150s
[14:36:31] <ada_ru> (I_vlxy_I) и еще нюанс - ты удалял между компиляциями сгенереные промежуточные файлы?
[14:36:38] <ada_ru> (I_vlxy_I) всякие объектники и проч?
[14:37:02] <ada_ru> (IvanAlf) Там там без объектников же. Только один бинарь генерится. Но сейчас попробую.
[14:37:33] <ada_ru> (IvanAlf) А.. Пардон.. Затупил. Сейчас грохну.
[14:38:11] <ada_ru> (I_vlxy_I) и сам бинарь и промежуточные 😊
[14:38:20] <ada_ru> (I_vlxy_I) а то компайлеры шибко сильно умные нонче
[14:41:51] <ada_ru> (IvanAlf) # ./test.sh
gcc-4.9 -c helloworld.adb
real 0m3.283s
user 0m0.660s
sys 0m0.340s
"./helloworld.ali" has been deleted
"./helloworld.o" has been deleted
gcc-4.9 -c helloworld.adb
real 0m0.626s
user 0m0.470s
sys 0m0.120s
"./helloworld.ali" has been deleted
"./helloworld.o" has been deleted
[14:41:52] <ada_ru> (IvanAlf) Тот же результат.
[14:42:36] <ada_ru> (IvanAlf) Похоже проблема в том, что gcc, собака бешенная, весь в 64mb не лезет =)
[14:55:51] <ada_ru> (I_vlxy_I) оно бы тогда свопилось, не?
[14:56:40] <ada_ru> (I_vlxy_I) точнее так - gcc отжирает ОЗУ под компиляцию и тем мешает дисковому кешу работать. как-нибудь так
[14:56:54] <ada_ru> (I_vlxy_I) плюс у меня ж это все на microSD до кучи
[14:58:05] <ada_ru> (I_vlxy_I) ну и видно, что даже чисто user+sys = 13 секунд. то есть оно конечно протупило где-то секунд 5, но на 13 то секунд оно честно проц грузануло.
[14:58:31] <ada_ru> (I_vlxy_I) $ time gnatmake hello.adb
gcc-4.9 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
real 0m18.611s
user 0m9.000s
sys 0m4.030s
[14:58:32] <ada_ru> (I_vlxy_I) как-то так.
[15:00:16] <ada_ru> (I_vlxy_I) просто проц довольно простой таки. это вам не жиррный кортекс! да и рама небось медленная и кешей не так чтобы очень много у проца
[15:00:50] <ada_ru> (I_vlxy_I) это TI Sitara AM1808 (ARM926EJ-S core)
[15:01:37] <ada_ru> (I_vlxy_I) http://www.ti.com/lit/ds/symlink/am1808.pdf
[15:02:10] <ada_ru> (I_vlxy_I) конкретно этот - 300 МГц. (в спеке почему-то более жирный)
[15:08:02] <ada_ru> (I_vlxy_I) интересно, Адакоре не собирается сделать baremetal для ev3?
[15:09:02] <ada_ru> (IvanAlf) Сейчас читаю, что про что там time говорит в своих выводах
[15:09:49] <ada_ru> (IvanAlf) На STM32? =)
[15:09:54] <ada_ru> (I_vlxy_I) м? зачем stm32?
[15:10:35] <ada_ru> (IvanAlf) Ну что бы совсем барэ-барэ было =)
[15:11:05] <ada_ru> (I_vlxy_I) ну а чем TI Sitara AM1808 (ARM926EJ-S core) не барэ-барэ? 😊
[15:13:27] <ada_ru> (IvanAlf) Жирный очень =)
[15:15:06] <ada_ru> (I_vlxy_I) ну, какой есть 😊 но я то конкретно про поддержку lego ev3 говорил. штука в образовании шибко популярная, ну и у тех кто на досуге робототехникой занимается (если на работе этого вдруг не достаточно 😊 )
[15:20:47] <ada_ru> (IvanAlf) Да это понятно. Просто какой резон на голое железо садиться, если туда ось успешно встаёт. Разве что для какого-то жесткого рилтайма.
[15:21:16] <ada_ru> (I_vlxy_I) ну, чтобы эффективней ресурсы контроллировать. и это ж робот - реалтайм жесткий там как бы в тему будет.
[15:31:42] <ada_ru> (IvanAlf) Интересно, а в ev3 обычное ядро, или RT?
[15:32:03] <ada_ru> (I_vlxy_I) оммм... а вот фиг знает. надо глянуть.
[15:32:35] <ada_ru> (I_vlxy_I) тем более, что нужно же отличать - тот линух, что стоит на ev3 искаропки и этот линух, что я на sd-карту поставил (который ev3dev на базе дебиана)
[15:33:15] <ada_ru> (IvanAlf) Не думаю, что будут заморачиваться специально под ev3. Разве что кто из энтузиастов рантайм накрутит.
[15:33:32] <ada_ru> (I_vlxy_I) ну для nxt же было
[15:37:13] <ada_ru> (I_vlxy_I) но вообще, RT-ядро, как пишут, делает ось более тормозное. что, в общем то, логично.
[15:40:42] <ada_ru> (IvanAlf) Да, но зато рилтайм - операции за гарантированное время.
[15:41:33] <ada_ru> (I_vlxy_I) но вообще, если на то пошло, там народ вообще на питоне и js роботов программит... Какое нафиг гарантированное время в этом мире интерпретируемого разврата?
[15:42:01] <ada_ru> (IvanAlf) Я глянул, в NXT там AVR, для него вообще не проблема что-то сваять.
[15:42:56] <ada_ru> (IvanAlf) На Лого надо, на Лого =)
[15:43:01] <ada_ru> (I_vlxy_I) М? Разве? Вроде там тоже TI ARm, но сильно проще
[15:43:31] <ada_ru> (I_vlxy_I) не, вру, не TI
[15:43:35] <ada_ru> (I_vlxy_I) Atmel AT91SAM7S256 (ARM7TDMI core) @48 MHz
[15:43:37] <ada_ru> (IvanAlf) А.. точно.. Не туда глянул Atmel 32-Bit ARM AT91SAM7S256
[15:43:53] <ada_ru> (I_vlxy_I) ARM7TDMI - старый знакомый 😊
[15:44:35] <ada_ru> (IvanAlf) AVR это у них некий сопроцессор.
[15:52:14] <ada_ru> (IvanAlf) А STM32 я помянул в связи с этим https://github.com/simonjwright/cortex-gnat-rts
[16:44:46] <landgraf> а зачем этот симон когда есть Фабиан?
[16:45:08] <landgraf> с драйверами, rts и прочими HAL-ами
[16:45:36] <ada_ru> (IvanAlf) Ну что нашел. Ссыль есть?
[16:46:06] <landgraf> ada drivers library на гитхабе
[16:46:39] <landgraf> https://github.com/AdaCore/Ada_Drivers_Library
[16:47:02] <landgraf> там прям взял и рисуй квадратики на stm32f329 discovery!
[16:47:24] <ada_ru> (IvanAlf) Спасибо. Посмотрю
[16:56:22] <ada_ru> (I_vlxy_I) фабиан - это от слова "дебиан" ?
[17:11:44] <ada_ru> (nitrocerber) Ну вообще он произносится как ФабьЯн.
[17:11:51] <ada_ru> (nitrocerber) Так что врядли)
[17:18:26] <ada_ru> (I_vlxy_I) ДебьЯн!
[17:24:47] <landgraf> и часто это у тебя?
[17:25:24] <OCTAGRAM> Дебра + Ян, значит, по логике ДебъЯн
[17:33:11] <ada_ru> (I_vlxy_I) http://blog.qt.io/blog/2018/04/23/beta-qt-webassembly-technology-preview/
[17:33:14] <ada_ru> (I_vlxy_I) Жгут
[17:36:26] <OCTAGRAM> GNUStep бы
[17:36:41] <ada_ru> (I_vlxy_I) закопали же. нинужин!
[17:36:46] <ada_ru> (I_vlxy_I) все на веб!
[17:36:58] <ada_ru> (I_vlxy_I) html/js/css рулят миром
[17:38:30] <OCTAGRAM> макОС закопали?
[17:39:17] <ada_ru> (I_vlxy_I) ну там таки и не совсем гнустеп. и чем дальше, тем меньше они похожи
[17:48:12] <ada_ru> (IvanAlf) хм собрал в Ada Drivers Library мигалку из примеров.
[17:48:22] <ada_ru> (IvanAlf) Memory region Used Size Region Size %age Used
flash: 91024 B 1 MB 8.68%
sram12: 25064 B 128 KB 19.12%
[17:48:23] <ada_ru> (IvanAlf) Нехило так.
[17:50:12] <ada_ru> (I_vlxy_I) многовато ресурсов для мигалки сожрало?
[17:51:52] <ada_ru> (I_vlxy_I) ну, скорее важнее насколько потребление вырастет с ростом программы.
[17:52:11] <ada_ru> (IvanAlf) Это да. Надеюсь что он туда нехилое ядро закатал
[17:53:02] <OCTAGRAM> надо поддерживать, чтоб оставалось похоже
[18:00:33] <OCTAGRAM> Qt и Gtk+ как были астрономически далеки, так и остаются, видимо, архитектура принципиально ущербная
[18:01:32] <OCTAGRAM> но они и моложе, их не шлифуют с 80х, по ним не пишут книги с 80х
[18:01:53] <ada_ru> (I_vlxy_I) а сейчас книги пишутся по гнустепу?
[18:03:32] <ada_ru> (I_vlxy_I) а, кстати, вопрос по системе сборки: можно gprbuild как-то настроить, чтобы он написал в лог подробно что сколько времени заняло? какой файлик сколько времени собирался.
[18:03:51] <ada_ru> (I_vlxy_I) Профилирование такое проекта.
[18:06:12] <ada_ru> (Максим) не видел такого
[18:06:49] <ada_ru> (nitrocerber) не, такого нету
[18:06:58] <ada_ru> (I_vlxy_I) для плюсов я использую связку cmake+ninja, вот последнее лог таков ведет. сколько каждый объектник компилялся (точнее время старта и окончания компиляции каждой единицы компиляции)
[18:07:15] <ada_ru> (I_vlxy_I) по итогам я делаю flamegraph
[18:07:24] <ada_ru> (nitrocerber) хммммм. а если в cgpr вместо компайлеров биндеров и прочего вкорячить time %toolname% чо будет))
[18:07:55] <ada_ru> (nitrocerber) небось сдохнет из-за пробела -_-
[18:09:46] <ada_ru> (I_vlxy_I) просто я сейчас на работе как раз перетряхиванием проекта в сторону оптимизации сборки занимаюсь. и сразу интересно, как оно в Аде, которая как раз задизайнена для огромных проектов.
[18:14:39] <ada_ru> (nitrocerber) оптимизация процесса сборки и оптимизация результата ж разные вещи, и что-то мне кажется, что в адском мире второе ну сииильно важнее первого
[18:15:01] <ada_ru> (nitrocerber) собирает-то могучий мейнфрейм, чо ему будет
[18:15:41] <ada_ru> (I_vlxy_I) ну, фиг знает. можно сэкономить на могучем мейнфрейме 😊
[18:15:52] <ada_ru> (I_vlxy_I) плюс какие-то части проекта один фиг локально собираешь ведь
[18:16:46] <ada_ru> (nitrocerber) на досках-то? туда чо вфлешили, то и есть
[18:17:04] <ada_ru> (nitrocerber) много там не соберёшь)) это только вы тут угораете на 64 мб рамы
[18:17:47] <ada_ru> (Максим) да ладно, скоро в каждом выключателе столько будет 😄
[18:18:02] <ada_ru> (nitrocerber) это не значит, что на выключателях надо будет компилять))
[18:18:09] <ada_ru> (nitrocerber) вон казино уже хакнули через аквариум))
[18:18:40] <ada_ru> (nitrocerber) так и через выключатели всех похакают. даёшь программистский луддинзм! или как он там
[18:19:18] <ada_ru> (I_vlxy_I) отвечает (nitrocerber) на <на досках-то? туда ч…>
ненене. по работе то я оптимизирую сейчас сборку на вполне себе нормальной рабочей станции. с 64 гигами рамы, всеми делами. Когда проект большой, это важно.
[18:20:10] <ada_ru> (Максим) что медленно с++ компиляет?
[18:20:59] <ada_ru> (I_vlxy_I) да не, нормально. просто периодически нужно проект таки обслуживать 😊
[18:22:09] <ada_ru> (I_vlxy_I) вообще, медленно, это сильно растяжимое понятие - кому то и час, это уже быстро, а кому-то 10 минут полной пересборки проекта это аццки медленно.
[18:25:39] <ada_ru> (I_vlxy_I) в плюсах, кроме всего прочего, не нужно злоупотреблять шаблонами шаблонов рекурсивными, ну и хедеры оккуратно организовать надо. тогда быстро.
ну и зависимости между модулями правильные сделать. чтобы минимизировать объемы пересборки если что.
[18:25:48] <ada_ru> (I_vlxy_I) но это уже общечеловеческие ценности пошли.
[18:28:54] <ada_ru> (I_vlxy_I) но понятно, что тот же Go собирает быстрее. но там ни шаблонов ни хедеров 😊
[20:01:28] <geniepro> помнится, когда-то я запускал в досе NYU-ada интерпретатор, и работало...
[20:06:59] <ada_ru> (I_vlxy_I) интерпретатор? не компайлер?
[20:09:20] <geniepro> тогда это был интерпретатор, да ещё и не полный
[20:10:25] <geniepro> я не понял, он что, со временем стал GNAT'ом? о_О
[20:16:28] <ada_ru> (I_vlxy_I) был вроде и досовый компайлер
[22:55:50] <ada_ru> (Максим) Я застал мерит-аду, он компилировал в пи код какой-то и исполнял его.
[22:59:25] <ada_ru> (I_vlxy_I) это паскалевской машины?
[22:59:41] <ada_ru> (I_vlxy_I) https://en.wikipedia.org/wiki/P-code_machine
[23:02:52] <ada_ru> (Максим) Даже не знаю, глубоко не копал. Вскоре гнат появился потом
[23:05:09] <ada_ru> (I_vlxy_I) да, Ада была тогда сильно сурова и для персоналок не предназначена вообще никак.