Forth http://www.fforum.winglion.ru/ |
|
Глазковая оптимизация в Форте http://www.fforum.winglion.ru/viewtopic.php?f=58&t=3185 |
Страница 2 из 2 |
Автор: | Victor__v [ Пн фев 25, 2019 00:26 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Hishnik писал(а): Victor__v писал(а): Повышение ТТХ Новы и приложений написанных на ней (размер, скорость и пр.). А, в свою очередь, зачем нужно вот это?
Хищник, Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка. А реализация оптимизатора это и монотонность действий для осознания себя да и на полученный результат потом приятно взглянуть в дизассемблере. |
Автор: | Victor__v [ Пн фев 25, 2019 00:27 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Движок опять задублировал сообщение |
Автор: | Hishnik [ Пн фев 25, 2019 01:45 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Victor__v писал(а): Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка. Я совершенно согласен, что если оптимизация - это не абсолютное спасение, то это никак не означает, что она вообще не нужна. Просто при работе хорошо иметь "флажки", которые в нужный момент "упадут" и покажут, что пора переключаться на что-то другое. Если разобраться, 90+% разработки ПО заключается именно в такой вот работе по установлению взаимосвязей и нащупыванию критериев оценки тех или иных действий. С Фортом это особенно важно, потому что устоявшихся методик нет (Мур, Forth Inc и прочие методиками не занимались). Полезно посмотреть для сравнения: ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Там есть много интересного, из которого оптимизация, которая на самом деле есть повышение быстродействия, укладывается в п. 4.4. А в 4-м разделе стандарта пункты с 4.1 по 4.6... |
Автор: | ath [ Пн фев 25, 2019 11:33 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Victor__v писал(а): При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма). Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма. Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC? Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. |
Автор: | Victor__v [ Пн фев 25, 2019 12:30 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
ath писал(а): Victor__v писал(а): При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма). Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма. Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC? Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. У меня всё что можно убрано в инлайн. Поддержка такого механизма на уровне ядра. По поводу резервов. Экономит замена связки "вызов кода, конец определения" на безусловный переход на вызов кода. Препроцессор вообще изголяется так на входе Код: ... WORD ; на выходе Код: ... [ ' WORD 3 ] AGAIN [ Однако такая подмена в Нове возможна далеко не для всех слов, пришлось прописывать все возможные адекватные варианты через множество. Ещё очень специфичная вещь: оптимизация компилирующих слов, которые шаманят непосредственно кодами. Т.е. у нас код 0x1 C, 0x2 C, преобразуется в 0x0102 W, Но сильнее всего экономит оптимизация условий. тот же DUP IF неплохо усекается. Ну оптимизации со стеком возвратов (из-за специфики моего форта). Была ещё оптимизация вида "0 ;" заменить на "jmp FALSE". Но я от неё отказался, хотя экономило нормально. |
Автор: | Victor__v [ Пн фев 25, 2019 13:02 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
ath писал(а): Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. Отличия только в подходе. Препроцессор может тупо "сломаться" на коде с полиморфизмом. Для ядра вариант идеальный из-за простоты задания правил. Но вот для оптимизации на ходу он достаточно сомнителен. ath писал(а): В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. ??? В ядре Новы + DUP и иже с ними как раз инлайнятся. |
Автор: | ath [ Пн фев 25, 2019 18:55 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна. Конечно, в конкретном случае для Новы ситуация может отличаться. Но в старых системах одни и те же реализации (словарные статьи) + DUP вызывали и ядро, и приложение. Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая. |
Автор: | Victor__v [ Пн фев 25, 2019 19:47 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
ath писал(а): Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна. Видимо под инлайном понимаем разное. В форт компилируется примитив. Тот же DUP он метится флагом INLINE И теперь, когда каким-нибудь словам захочется вызвать DUP в режиме компиляции, то в коде не будет вызова, в коде будет сам код примитива DUP В данном конкретном случае, под приложением я понимаю форт плюс нужный функционал. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо? 28 кб под форт по современным меркам мелочь. ath писал(а): Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая. С AGAIN ничего весёлого. Это слово переопределено в ЦК, что позволяет ему корректно компилировать код под виртуальные адреса, на которых и собирается форт. |
Автор: | ath [ Пн фев 25, 2019 20:19 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Правильно я понял, что у вас в любом случае в целевом (получившимся после своей компиляции) Форте будет откомпилированный отдельно «DUP» — например, для вызова в режиме интерпретации? |
Автор: | Victor__v [ Пн фев 25, 2019 20:55 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Да. Всё так и есть. |
Автор: | ath [ Пн фев 25, 2019 21:15 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. Victor__v писал(а): В данном конкретном случае, под приложением я понимаю форт плюс нужный функционал. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо? Когда Нова компилирует приложение, она сперва пропускает через себя исходный код своего ядра? Или есть какая-то готовая двоичная заготовка? |
Автор: | Victor__v [ Пн фев 25, 2019 21:35 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом. В векторное слово <MAIN> можно прописать нужный указатель для старта приложения. Естественно, реальный адрес начала форта и образа должны совпадать. Они и совпадают. Значение в винде для старта кода по траlиции 0x00402000 Цитата: Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. А ссылки кто двигать будет на освободившиеся место? С учётом нативности Новы и архитектуры интела задача не совсем простая. Особенно если вызовы слов, ставятся на обратный ход. Для справки, если мы опять друг друга не поняли. В любой версии Новы лишних слов нет. От ЦК там нет ничего. |
Автор: | ath [ Пн фев 25, 2019 22:15 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
Victor__v писал(а): Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом. Это ядро туда каждый раз из исходников Новы строится? Victor__v писал(а): Цитата: Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. А ссылки кто двигать будет на освободившиеся место? Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе. Конечно, если целью является «проблемно-ориентированный язык», компилятор должен знать все слова этого языка, чтобы случайно их не выкинуть при избавлении от неиспользованных слов. Но если из всей подключенной строковой библиотеки используется лишь COMPARE — на втором проходе остальные слова из набора слов String не войдут в исполняемый файл. Victor__v писал(а): Для справки, если мы опять друг друга не поняли. В любой версии Новы лишних слов нет. От ЦК там нет ничего. Это да. Я всё ещё мыслю в терминах Баранова. Целевая (машина, система, компилятор) это то, куда идёт компиляция и что получается. А где происходит компиляция — привык называть инструментальным (пространством, средой и т.п.). Вы, насколько я понял, ЦК называете наоборот, компилятор с возможностью выбора целевой платформы. |
Автор: | Victor__v [ Пн фев 25, 2019 22:29 ] |
Заголовок сообщения: | Re: Глазковая оптимизация в Форте |
ath писал(а): Это ядро туда каждый раз из исходников Новы строится? Нет в этом случае исходники не трогаются ath писал(а): Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе. Выпиливание всего полезного, пусть и не используемого кода, это вредная оптимизация для форта. Размер же Новы 28 кб. Минимум. И то девочка на диете, худеет байтами По поводу понятий же всё спорно. Вам лучше в исходники глянуть SRC-VC/SERVICE/SELF-COMPILE.F там прописывается весь процесс создания образа форта. |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |