Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
ath писал(а): Это ядро туда каждый раз из исходников Новы строится?
Нет в этом случае исходники не трогаются ath писал(а): Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе.
Выпиливание всего полезного, пусть и не используемого кода, это вредная оптимизация для форта. Размер же Новы 28 кб. Минимум. И то девочка на диете, худеет байтами По поводу понятий же всё спорно. Вам лучше в исходники глянуть SRC-VC/SERVICE/SELF-COMPILE.F там прописывается весь процесс создания образа форта.
[quote="ath"] Это ядро туда каждый раз из исходников Новы строится? [/quote]
Нет в этом случае исходники не трогаются
[quote="ath"] Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе. [/quote] Выпиливание всего полезного, пусть и не используемого кода, это вредная оптимизация для форта. Размер же Новы 28 кб. Минимум. И то девочка на диете, худеет байтами :)
По поводу понятий же всё спорно. Вам лучше в исходники глянуть SRC-VC/SERVICE/SELF-COMPILE.F там прописывается весь процесс создания образа форта.
|
|
|
|
Добавлено: Пн фев 25, 2019 22:29 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Victor__v писал(а): Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом.
Это ядро туда каждый раз из исходников Новы строится? Victor__v писал(а): Цитата: Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. А ссылки кто двигать будет на освободившиеся место? Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе. Конечно, если целью является «проблемно-ориентированный язык», компилятор должен знать все слова этого языка, чтобы случайно их не выкинуть при избавлении от неиспользованных слов. Но если из всей подключенной строковой библиотеки используется лишь COMPARE — на втором проходе остальные слова из набора слов String не войдут в исполняемый файл. Victor__v писал(а): Для справки, если мы опять друг друга не поняли. В любой версии Новы лишних слов нет. От ЦК там нет ничего. Это да. Я всё ещё мыслю в терминах Баранова. Целевая (машина, система, компилятор) это то, куда идёт компиляция и что получается. А где происходит компиляция — привык называть инструментальным (пространством, средой и т.п.). Вы, насколько я понял, ЦК называете наоборот, компилятор с возможностью выбора целевой платформы.
[quote="Victor__v"]Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом. [/quote] Это ядро туда каждый раз из исходников Новы строится?
[quote="Victor__v"] [quote]Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация.[/quote] А ссылки кто двигать будет на освободившиеся место? [/quote] Могу три варианта предложить. Самый простой — двухпроходная схема. На первом проходе вычисляется, какие слова можно безопасно выкинуть и не компилировать в «экзешник» на втором проходе.
Конечно, если целью является «проблемно-ориентированный язык», компилятор должен знать все слова этого языка, чтобы случайно их не выкинуть при избавлении от неиспользованных слов. Но если из всей подключенной строковой библиотеки используется лишь COMPARE — на втором проходе остальные слова из набора слов String не войдут в исполняемый файл.
[quote="Victor__v"] Для справки, если мы опять друг друга не поняли. В любой версии Новы [b]лишних слов нет[/b]. От ЦК там нет ничего.[/quote] Это да. Я всё ещё мыслю в терминах Баранова. Целевая (машина, система, компилятор) это то, куда идёт компиляция и что получается. А где происходит компиляция — привык называть инструментальным (пространством, средой и т.п.). Вы, насколько я понял, ЦК называете наоборот, компилятор с возможностью выбора целевой платформы.
|
|
|
|
Добавлено: Пн фев 25, 2019 22:15 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом. В векторное слово <MAIN> можно прописать нужный указатель для старта приложения. Естественно, реальный адрес начала форта и образа должны совпадать. Они и совпадают. Значение в винде для старта кода по траlиции 0x00402000 Цитата: Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. А ссылки кто двигать будет на освободившиеся место? С учётом нативности Новы и архитектуры интела задача не совсем простая. Особенно если вызовы слов, ставятся на обратный ход. Для справки, если мы опять друг друга не поняли. В любой версии Новы лишних слов нет. От ЦК там нет ничего.
Можно сказать, двоичная заготовка для винды. Создаётся образ экзешника. И на стартовый адрес образа переносится всё ядро с навороченным поверх функционалом. В векторное слово <MAIN> можно прописать нужный указатель для старта приложения. Естественно, реальный адрес начала форта и образа должны совпадать. Они и совпадают. Значение в винде для старта кода по траlиции 0x00402000
[quote]Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация.[/quote] А ссылки кто двигать будет на освободившиеся место? С учётом нативности Новы и архитектуры интела задача не совсем простая. Особенно если вызовы слов, ставятся на обратный ход.
Для справки, если мы опять друг друга не поняли. В любой версии Новы [b]лишних слов нет[/b]. От ЦК там нет ничего.
|
|
|
|
Добавлено: Пн фев 25, 2019 21:35 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация. Victor__v писал(а): В данном конкретном случае, под приложением я понимаю форт плюс нужный функционал. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо?
Когда Нова компилирует приложение, она сперва пропускает через себя исходный код своего ядра? Или есть какая-то готовая двоичная заготовка?
Тогда что мешает после компиляции автоматически убрать из кода словарные статьи слов, все вхождения которых заменены на inline? Тоже оптимизация.
[quote="Victor__v"] В данном конкретном случае, под приложением я понимаю [b]форт плюс нужный функционал[/b]. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо? [/quote] Когда Нова компилирует приложение, она сперва пропускает через себя исходный код своего ядра? Или есть какая-то готовая двоичная заготовка?
|
|
|
|
Добавлено: Пн фев 25, 2019 21:15 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Да. Всё так и есть.
Да. Всё так и есть.
|
|
|
|
Добавлено: Пн фев 25, 2019 20:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Правильно я понял, что у вас в любом случае в целевом (получившимся после своей компиляции) Форте будет откомпилированный отдельно «DUP» — например, для вызова в режиме интерпретации?
Правильно я понял, что у вас в любом случае в целевом (получившимся после своей компиляции) Форте будет откомпилированный отдельно «DUP» — например, для вызова в режиме интерпретации?
|
|
|
|
Добавлено: Пн фев 25, 2019 20:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
ath писал(а): Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна. Видимо под инлайном понимаем разное. В форт компилируется примитив. Тот же DUP он метится флагом INLINEИ теперь, когда каким-нибудь словам захочется вызвать DUP в режиме компиляции, то в коде не будет вызова, в коде будет сам код примитива DUPВ данном конкретном случае, под приложением я понимаю форт плюс нужный функционал. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо? 28 кб под форт по современным меркам мелочь. ath писал(а): Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая. С AGAIN ничего весёлого. Это слово переопределено в ЦК, что позволяет ему корректно компилировать код под виртуальные адреса, на которых и собирается форт.
[quote="ath"]Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна.[/quote]
Видимо под инлайном понимаем разное. В форт компилируется примитив. Тот же [b]DUP[/b] он метится флагом [b]INLINE[/b] И теперь, когда каким-нибудь словам захочется вызвать [b]DUP[/b] в режиме компиляции, то в коде не будет вызова, в коде будет сам код примитива [b]DUP[/b]
В данном конкретном случае, под приложением я понимаю [b]форт плюс нужный функционал[/b]. Конечно, скомпилировать всё в отдельное приложение без форта можно в теории, но нафиг оно надо? 28 кб под форт по современным меркам мелочь.
[quote="ath"]Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая. :D[/quote] С AGAIN ничего весёлого. Это слово переопределено в ЦК, что позволяет ему корректно компилировать код под виртуальные адреса, на которых и собирается форт.
|
|
|
|
Добавлено: Пн фев 25, 2019 19:47 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна. Конечно, в конкретном случае для Новы ситуация может отличаться. Но в старых системах одни и те же реализации (словарные статьи) + DUP вызывали и ядро, и приложение. Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая.
Тут вот что. Если все + DUP убрать из ядра в инлайн — программы, написанные для подобного транслятора, могут не найти + и DUP в словаре. По крайней мере при компиляции приложения если все вхождения слова оптимизированы в inline, его статичная реализация не нужна.
Конечно, в конкретном случае для Новы ситуация может отличаться. Но в старых системах одни и те же реализации (словарные статьи) + DUP вызывали и ядро, и приложение.
Хвостовую рекурсию я оптимизирую. Там есть ещё трюк — слово ;- ставит сам программист в местах, где она применима. Но конкретная автозамена с AGAIN весёлая. :D
|
|
|
|
Добавлено: Пн фев 25, 2019 18:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
ath писал(а): Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. Отличия только в подходе. Препроцессор может тупо "сломаться" на коде с полиморфизмом. Для ядра вариант идеальный из-за простоты задания правил. Но вот для оптимизации на ходу он достаточно сомнителен. ath писал(а): В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. ??? В ядре Новы + DUP и иже с ними как раз инлайнятся.
[quote="ath"] Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.[/quote]
Отличия только в подходе. Препроцессор может тупо "сломаться" на коде с полиморфизмом. Для ядра вариант идеальный из-за простоты задания правил. Но вот для оптимизации на ходу он достаточно сомнителен.
[quote="ath"] В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.[/quote] ??? В ядре Новы + DUP и иже с ними как раз инлайнятся.
|
|
|
|
Добавлено: Пн фев 25, 2019 13:02 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
ath писал(а): Victor__v писал(а): При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма).
Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма. Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC? Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть. У меня всё что можно убрано в инлайн. Поддержка такого механизма на уровне ядра. По поводу резервов. Экономит замена связки "вызов кода, конец определения" на безусловный переход на вызов кода. Препроцессор вообще изголяется так на входе Код: ... WORD ; на выходе Код: ... [ ' WORD 3 ] AGAIN [ Однако такая подмена в Нове возможна далеко не для всех слов, пришлось прописывать все возможные адекватные варианты через множество. Ещё очень специфичная вещь: оптимизация компилирующих слов, которые шаманят непосредственно кодами. Т.е. у нас код 0x1 C, 0x2 C, преобразуется в 0x0102 W, Но сильнее всего экономит оптимизация условий. тот же DUP IF неплохо усекается. Ну оптимизации со стеком возвратов (из-за специфики моего форта). Была ещё оптимизация вида "0 ;" заменить на "jmp FALSE". Но я от неё отказался, хотя экономило нормально.
[quote="ath"][quote="Victor__v"]При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма).
Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма.[/quote] Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC?
Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.[/quote]
У меня всё что можно убрано в инлайн. Поддержка такого механизма на уровне ядра.
По поводу резервов.
Экономит замена связки "вызов кода, конец определения" на безусловный переход на вызов кода. Препроцессор вообще изголяется так на входе [code] ... WORD ; [/code] на выходе [code] ... [ ' WORD 3 ] AGAIN [ [/code] Однако такая подмена в Нове возможна далеко не для всех слов, пришлось прописывать все возможные адекватные варианты через множество.
Ещё очень специфичная вещь: оптимизация компилирующих слов, которые шаманят непосредственно кодами. Т.е. у нас код 0x1 C, 0x2 C, преобразуется в 0x0102 W,
Но сильнее всего экономит оптимизация условий. тот же DUP IF неплохо усекается.
Ну оптимизации со стеком возвратов (из-за специфики моего форта).
Была ещё оптимизация вида "0 ;" заменить на "jmp FALSE". Но я от неё отказался, хотя экономило нормально.
|
|
|
|
Добавлено: Пн фев 25, 2019 12:30 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Victor__v писал(а): При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма).
Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма. Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC? Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.
[quote="Victor__v"]При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма).
Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма.[/quote] Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC?
Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.
|
|
|
|
Добавлено: Пн фев 25, 2019 11:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Victor__v писал(а): Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка. Я совершенно согласен, что если оптимизация - это не абсолютное спасение, то это никак не означает, что она вообще не нужна. Просто при работе хорошо иметь "флажки", которые в нужный момент "упадут" и покажут, что пора переключаться на что-то другое. Если разобраться, 90+% разработки ПО заключается именно в такой вот работе по установлению взаимосвязей и нащупыванию критериев оценки тех или иных действий. С Фортом это особенно важно, потому что устоявшихся методик нет (Мур, Forth Inc и прочие методиками не занимались). Полезно посмотреть для сравнения: ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Там есть много интересного, из которого оптимизация, которая на самом деле есть повышение быстродействия, укладывается в п. 4.4. А в 4-м разделе стандарта пункты с 4.1 по 4.6...
[quote="Victor__v"]Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка.[/quote] Я совершенно согласен, что если оптимизация - это не абсолютное спасение, то это никак не означает, что она вообще не нужна. Просто при работе хорошо иметь "флажки", которые в нужный момент "упадут" и покажут, что пора переключаться на что-то другое. Если разобраться, 90+% разработки ПО заключается именно в такой вот работе по установлению взаимосвязей и нащупыванию критериев оценки тех или иных действий. С Фортом это особенно важно, потому что устоявшихся методик нет (Мур, Forth Inc и прочие методиками не занимались).
Полезно посмотреть для сравнения: ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
Там есть много интересного, из которого оптимизация, которая на самом деле есть повышение быстродействия, укладывается в п. 4.4. А в 4-м разделе стандарта пункты с 4.1 по 4.6...
|
|
|
|
Добавлено: Пн фев 25, 2019 01:45 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Движок опять задублировал сообщение
Движок опять задублировал сообщение
|
|
|
|
Добавлено: Пн фев 25, 2019 00:27 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Hishnik писал(а): Victor__v писал(а): Повышение ТТХ Новы и приложений написанных на ней (размер, скорость и пр.). А, в свою очередь, зачем нужно вот это? - just for fun
- для галочки
- чтобы было
- для собственного удовлетворения
Хищник, Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка. А реализация оптимизатора это и монотонность действий для осознания себя да и на полученный результат потом приятно взглянуть в дизассемблере.
[quote="Hishnik"][quote="Victor__v"]Повышение ТТХ Новы и приложений написанных на ней (размер, скорость и пр.). [/quote] А, в свою очередь, зачем нужно вот это?[/quote] [list] [*]just for fun [*]для галочки [*]чтобы было [*]для собственного удовлетворения[/list]
Хищник, Я прекрасно понимаю, что оптимизация корень всех зол, особенно если она делается без цели. Но надо-то чем-то занять разум пока не нащупается новая интересная задачка.
А реализация оптимизатора это и монотонность действий для осознания себя :D да и на полученный результат потом приятно взглянуть в дизассемблере.
|
|
|
|
Добавлено: Пн фев 25, 2019 00:26 |
|
|
|
|
|
Заголовок сообщения: |
Re: Глазковая оптимизация в Форте |
|
|
Victor__v писал(а): Повышение ТТХ Новы и приложений написанных на ней (размер, скорость и пр.). А, в свою очередь, зачем нужно вот это?
[quote="Victor__v"]Повышение ТТХ Новы и приложений написанных на ней (размер, скорость и пр.). [/quote] А, в свою очередь, зачем нужно вот это?
|
|
|
|
Добавлено: Вс фев 24, 2019 23:02 |
|
|
|
|