Я бы сказал так, что прирост в десятки раз наблюдается не по сравнению с массовой электроникой, а по сравнению с кластерами на x86... Скажем, пару сотен GFlops уже как бы нельзя реализовать ни на читалке, ни даже на разумном количестве x86 (у них еще и на синхронизацию уйдет время). А для FPGA это характеристики одноплатного модуля.

Это предложение или намёк вынести оптимизатор из кода и оформить его как подключаемую библиотеку?

Привязку в основном ядре ключевых управляющих слов оптимизатора возможно имеет смысл оставить и может быть маркировать примитивы ядра да и по необходимости высокоуровневый код этими словами?

Это предложение аккуратно относиться к терминам, и не называть оптимизатором то, что им не является. Редкость Форта не означает, что любой, посчитавший себя фортером, может творить что хочет только на том основании, что все равно никто не поймет. Конечно, можно долго-долго прятаться в Форте и не казать оттуда носа, а любую критику списывать на черную зависть окружающих. С учетом того, что "если долго мучиться, что-нибудь получится", то есть какие-то результаты периодически появляются, они срабатывают как дополнительные корни, пущенные посреди глухого леса. В итоге мы видим оптимизаторы aka набор чего-то, заработавшего быстрее, чем предыдущее что-то, и сетевые форт-процессоры, на поверку оказывающиеся обычными ARM.

А ну, как же chess ответит в этом споре
Можно трактовать термины широко... и считать оптимизатором всё, что преобразует код в сторону большего быстродействия.
В частности, если в некоем документе к компилятору содержится строка, что "оптимизируются прыжки", то это означает, что замена одних переходов на другие (и ничего больше) всё-таки рассматривается как оптимизирующее преобразование. В боьшинстве продвинутых компиляторов можно вообще отключать оптимизирующие замены по частям

Минуточку. Вот у нас есть переход по однобайтовому смещению и по четырехбайтовому. Второй, кроме того, что занимает больше места, еще и медленнее. Выбор короткого перехода вместо длинного является оптимизацией?

Массовый потребитель на данные характеристики - это игровая и
мультимедиа индустрия с переконфигурируемыми решениями
(конкурентными) от разных производителей.

P.S. Может и Форт, в этом случае, на что-нибудь сгодится:)
и какой оптимизатор, в этом случае необходим, если стековая архитектура будет использована аппаратно? АRM процессоры ввели для ускорения Java (Jazelle) PC не понятно какие механизмы имеют, кроме JIT перекомпиляции, ускорения Java байт кода.
Применяемая в Андроид устройствах регистровая виртуальная машина (Dalvik), по оценкам менее эффективна в сравнении даже с Mono, хотя код dex, odex, apk файлов получают преобразовывая class файлы после java компилятора и впосл
едствии применяя свою JIT.

Да, это допустимо так понимать. Делать вручную ассемблерные вставки в сотнях и тысячах мест — было бы неоправданно.

Да, оформлено в специфичное расширение к spf — такое понимание тоже вполне допустимо.

Как бы там ни было, этот модуль автору надо как-то называть. Основное его назначение: модификация объектного кода с целью улучшения некоторых характеристик. А конкретней — уменьшение времени исполнения. Часто такой процесс улучшения характеристик называют оптимизацией. Таким образом, этот модуль и был назван "оптимизатор".

Тем не менее, эти "сотни и тысячи мест" откуда-то ведь взялись? Почему нельзя было писать сразу с приемлемым качеством кода?

Под оптимизацией в математическом смысле понимается максимизация некоторого функционала качества. Для машинного кода это будет, к примеру, выбор между разворачиванием цикла (много места, меньше тактов) или отказом от разворачивания (мало места, больше тактов). С учетом того, что нам надо и мало места, и мало тактов, а одновременно удовлетворить оба этих требования невозможно, приходится использовать интегральный критерий "качество кода", который приведет к тому, что цикл на миллиард итераций развернут не будет, а на десять - скорее всего будет.
В случае же "оптимизатора" имеет место замена плохого кода на хороший. Вместо функционала качества используется лобовое перечисление условий, когда и что менять. Я понимаю, что в spf все круто до неимоверности, но общаться на его темы все же следует по-русски и технически корректно. А конкретно Максимову - возможно, не во всех обсуждениях тут же упоминать оптимизатор, что вот он есть, и вот с ним будет хорошо. Потому что предсказуемость его тезисов прямо-таки зашкаливает.

Правильнее сказать очень много задач для очень узкого круга лиц. Причем программы для решения этих задач должны быть созданы этим самым узким кругом лиц. Сторонние программы как работали раньше без ускорителей точно так и будут работать уже при наличии этих ускорителей. А это вся ОС и очень много программ для очень широкого круга лиц.
У меня это направление работ вызывает сомнение именно из-за отношения к нему основных разработчиков x86.
Они не заинтересованы плодить конкурентов и будут совершенствовать свои процессора самостоятельно.
Повышение производительности PC в основном тормозится наличием большого количества наработанного ПО, а не аппаратной платформой.

Разве это как-то ограничивает возможность работ в данном направлении? Да, ускорение вычислений на базе ПЛИС - прежде всего узкоспециализированные и эксклюзивные задачи. Но тут возникает вопрос, а у нас что? Если завод с конвейером, который вот-вот встанет, и его надо бы загрузить, то ПЛИС вряд ли быстро помогут. А вот если хочется потратить поменьше в относительном выражении денег на оборудование и побольше - на интеллектуальную собственность, то ПЛИС расширяет круг возможного приложения усилий по сравнению с процессорами примерно так же, как программирование - с использованием только готового софта. Кто возьмется убедить программиста на Си, что в Excel уже все написано и надо только таблички заполнять?

Подобная же ситуация была с 3D-ускорителями. Пока программ под них не было, они оставались интересными и дорогими игрушками.


http://news.ferra.ru/hard/2010/11/23/105475/
?

Ну вот это и есть подтверждение совершенствования платформы самими разработчиками x86.
Только вот цифр о повышении производительности пока нет. Поживем увидим, хотя я считаю, что
существенного прогресса не будет.

Форт для PC архитектуры аппаратно не поддержан и оптимальность Форт программ тут ни при чём. Доступа к микрокоду интеловских процессоров тоже нет:) Остаётся один
вариант - писать на ассемблере! Но кто скажет что ассемблерным кодом легко можно оперировать в голове и программа на нём оптимальнее чем сгенерированная компилятором из высокоуровневого кода?

В практическом варианте стиль программирования задачи должен
использовать элементы архитектуры процессорного ядра
(сдвиги, анализы флагов, ручное управление регистров и много чего ещё, пример как в С--), но это уже сильная завязка на
конкретную архитектуру.

Оптимизация по правилам генерируемого кода - это один
из способов обойти обозначенные выше ограничения и при этом
создать вменяемый код, сравнимый с ассемблером при оперировании высокоуровневыми понятиями.

P.S. Наблюдение из жизни: есть в CAD системах проектирования
печатных плат автотрассировщики, но зачастую электронщики
ими не пользуются, а разводят платы вручную (парадокс).
Почему же программисты так надеются на всемогущество
оптимизаторов когда возможность создать нерабочий код
у оптимизатора с максимальными опциями оптимизации существенна (например у IAR Си компилятора)

Atom собран просто с FPGA, без всякого совершенствования платформы. Точнее, она усовершенствована тем, что к процессору добавлен другой чип, от производителя FPGA.

Кремний тоже не Intel добывает. Главное здесь кто конфигурирует FPGA и стыкует с процессором.

1.

2.


Рассматривая 1 и 2, я все больше и больше настораживаюсь. Раз Форт аппаратно не поддержан, то и основа кода, его общая структура уже изначально неоптимальна для x86. Если мы хотим оптимальности, то получается, что этому удаву надо обрезать хвост по самые уши. Что, кстати, было сделано в Microsoft, где положили в основу .net стековую машину, но код реструктурируется довольно глубоко. Странно, почему они Максимова не спросили, как надо это делать, и заодно уж - как размещать в рамках Форта другие языки...


Вот именно! При трассировке печатной платы конструктор сразу оценивает общую компоновку, а в процессе работы идентифицирует проблемные участки. Вряд ли грамотный конструктор будет решать проблему оптимизации мешанины дорожек натравливанием на нее оптимизатора топологии. Скорее он примет меры совершенно иного характера - введет дополнительные слои, расставит по-другому компоненты. С программированием в целом аналогично - если программа работает медленно, надо сначала идентифицировать проблемные участки кода, а потом постараться решить проблему кардинально.

В любом случае, я указываю в основном на тот факт, что Михаил упорно стягивает внимание к своим разработкам, причем делает это широким фронтом. Я сомневаюсь, что кто-то еще не в курсе, что надо писать правила оптимизатора и размещать языки в рамках Форта, и все это с помощью микроплатежей Читая начало темы, можно увидеть, что речь-то шла о новой платформе. Так ли уж надо перекрывать кислород новым разработкам, утверждая, что без оптимизатора ничего хорошего не получится?