chess писал(а):
Программист оптимизирует общую компоновку программы, определяя оптимальный алгоритм получения ее решения, от чего и зависит в большей степени производительность программы. Ускорение кода на локальных участках программы отдается компилятору с встроенными средствами анализа и ускорения кода. Как правило этим все и кончается.
А если программист заранее, стратегически выбирает область использования так, что избыточный код со стековыми перестановками не оказывает заметного влияния на потребительские характеристики программы?
chess писал(а):
Структура форт-кода из-за стека параметров приводит к существенному замедлению его исполнения. Собственно львиная доля работы оптимизатора Михаила и направлена на демонтаж стека из кода, что дает основной прирост скорости исполнения. Все остальное (оптимизация переходов, оптимизация работы с памятью и тд) вносит существенно меньший вклад. Ни о какой глобальной оптимизации речь пока не идет, хотя возможности для этого есть. По такой-же схеме в основном устроено 'облагораживание' форт-кода во многих других форт-системах.
Это наводит на мысль, что Форт применен попросту не по назначению. У любого языка программирования есть плюсы и минусы. Стек как "бутылочное горлышко", через которое необходимо пропускать весь поток данных - явный минус. С ним можно бороться... это получается борьба с последствиями. При этом как-то не просматриваются плюсы языка, ради которых он был выбран. Упрямство, возможность позиционировать себя как программиста на эксклюзивном языке с мистическими характеристиками - это не плюсы. Видимо, на первый план должны выходить такие факторы, как простота модификации и сопровождения программы, для чего стоило бы рассматривать конкретные подходы к выбору удобного синтаксиса, дополнительных возможностей разбора текста. Вместо этого, занимаясь мелкими оптимизациями, фортеры по сути идут по чужому пути, улучшая характеристики, которыми можно бы и пожертвовать.
Что касается связки spf+оптимизатор, то тут интересен еще и
срок, в течение которого все это развивается. Скажем так, 10 лет назад ситуация была несколько иная. И в программировании, и в экономике страны. Поэтому то, чем можно было заниматься для 486-го процессора в середине 90-х, с большими сомнениями годится для начала 10-х. Усилий надо больше, заметность результата все меньше, а альтернативных точек приложения сил существенно больше. Как существующая библиотека оптимизатор таки да, делает то, что для него заявлено. Это главная точка приложения сил на сегодняшний день, других нет?
chess писал(а):
Если даже и так, то кто дает исходные данные для этого(явно или не явно).
Что значит "если даже"?
FPGA стоят во многих устройствах, если их не конфигурирует пользователь, то про них никто и не знает. В случае Intel, да и еще ряда изделий класса "x86+FPGA на плате" наличие ПЛИС отмечается специально, и предназначена она для загрузки конфигурации по выбору пользователя. Разработать такую конфигурацию, разумеется, может и какая-то компания, но порядок разработки известен и доступен.