Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 00:17

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 152 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  След.
Автор Сообщение
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 10:36 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
Кремний тоже не Intel добывает. Главное здесь кто конфигурирует FPGA и стыкует с процессором.

Но не Intel же конфигурирует.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: оптимизация
СообщениеДобавлено: Пт дек 23, 2011 11:08 
Хищник писал(а):
spf писал(а):
Делать вручную ассемблерные вставки в сотнях и тысячах мест — было бы неоправданно.
Тем не менее, эти "сотни и тысячи мест" откуда-то ведь взялись? Почему нельзя было писать сразу с приемлемым качеством кода?
Вопрос некорректен, т.к. производимые улучшения объектного кода не зависят от качества исходного кода. Т.е., даже когда исходный код приемлемого качества, объекный код все-равно подлежит улучшению.
Например, простейшая компиляция фрагмента "DUP 123 = IF" в машинный код запишет вызов DUP, помещение литерала 123 на стек, вызов слова "=", снятие флага со стека и условный переход. Этот фрагмент может быть заменен на машинную команду сравнения вершины стека (регистра) с литералом и условный переход. Таким образом, улучшение идет на уровне вариаций представления иходного фрагмента в машинном коде.

Хищник писал(а):
spf писал(а):
Основное его назначение: модификация объектного кода с целью улучшения некоторых характеристик. А конкретней — уменьшение времени исполнения. Часто такой процесс улучшения характеристик называют оптимизацией.
Под оптимизацией в математическом смысле понимается максимизация некоторого функционала качества.
Да, нахождение экстремума целевой функции.
В прикладных же областях даже процесс улучшения значения целевой функции называют оптимизацией (так уж сложилось). Т.е., достаточно, что новое значение ближе к экстремуму, чем предыдущее — сам экстремум может быть и не найден.


Хищник писал(а):
Для машинного кода это будет, к примеру, выбор между разворачиванием цикла (много места, меньше тактов) или отказом от разворачивания (мало места, больше тактов).
Да, разворачивание циклов — это тоже частный случай прикладной оптимизации. Правда, эта оптимизация не зависит от объектного кода вообще (и, в отличии от случая выше, может быть проведена даже на уровне исходного кода). Одно дополняет другое.


Хищник писал(а):
В случае же "оптимизатора" имеет место замена плохого кода на хороший. Вместо функционала качества используется лобовое перечисление условий, когда и что менять.
функция заданна таблично — вполне нормальный подход.


Хищник писал(а):
А конкретно Максимову - возможно, не во всех обсуждениях тут же упоминать оптимизатор, что вот он есть, и вот с ним будет хорошо.
согласен.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 11:32 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
spf писал(а):
Вопрос некорректен, т.к. производимые улучшения объектного кода не зависят от качества исходного кода. Т.е., даже когда исходный код приемлемого качества, объекный код все-равно подлежит улучшению.
Например, простейшая компиляция фрагмента "DUP 123 = IF" в машинный код запишет вызов DUP, помещение литерала 123 на стек, вызов слова "=", снятие флага со стека и условный переход. Этот фрагмент может быть заменен на машинную команду сравнения вершины стека (регистра) с литералом и условный переход. Таким образом, улучшение идет на уровне вариаций представления иходного фрагмента в машинном коде.

Если подобные фрагменты так важны, слово =IF сделает примерно то же самое. Однако будет наглядно показывать, что именно делается, и что это - одно слово и один фрагмент кода. Более того, подобное слово никоим образом не выходит за рамки конкатенативной компиляции.
spf писал(а):
Т.е., достаточно, что новое значение ближе к экстремуму, чем предыдущее — сам экстремум может быть и не найден.

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

При этом в данном случае присутствует экстремум - при превышении некоего порога объем программы станет чрезмерно большим, интегральный показатель качества снизится до неприемлемых значений (Blu-ray с развернутыми циклами в десяток миллиардов итераций не годится для использования).
spf писал(а):
функция заданна таблично — вполне нормальный подход.

Нормальный - это для каких размеров таблиц? Если та же проверка условия будет скомпилирована чуть иначе, выявит ли ее оптимизатор? И сколько таблиц потребуется, чтобы выявить практически используемые фрагменты кода в различных их сочетаниях?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 11:38 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Хищник писал(а):
Вот именно! При трассировке печатной платы конструктор сразу оценивает общую компоновку, а в процессе работы идентифицирует проблемные участки. Вряд ли грамотный конструктор будет решать проблему оптимизации мешанины дорожек натравливанием на нее оптимизатора топологии.

Да, конструктор задает общую компоновку. Этим в основном и определяется оптимальность топологии.
Затем может запустить автотрассировщик и получить информацию по критическим(ему известным трассам). Если эта информация его не устраивает, то да, делает работу по ним вручную. Как правило если задать требования по критическим связям заранее, то все будет нормально. 'Интеллекта' автотрассировщика сегодня на это хватает.
Программист оптимизирует общую компоновку программы, определяя оптимальный алгоритм получения ее решения, от чего и зависит в большей степени производительность программы. Ускорение кода на локальных участках программы отдается компилятору с встроенными средствами анализа и ускорения кода. Как правило этим все и кончается.
Если все-же быстродействие не устраивает, то программист ускоряет код вручную. Аналогия просматривается. Отличие в том, что программист имея открытый транслятор может самостоятельно внести изменения в блок анализа и модификации кода транслятора, в первую очередь, если это изменение направлено на ускорение достаточно типичных фрагментов кода. Структура форт-кода из-за стека параметров приводит к существенному замедлению его исполнения. Собственно львиная доля работы оптимизатора Михаила и направлена на демонтаж стека из кода, что дает основной прирост скорости исполнения. Все остальное (оптимизация переходов, оптимизация работы с памятью и тд) вносит существенно меньший вклад. Ни о какой глобальной оптимизации речь пока не идет, хотя возможности для этого есть. По такой-же схеме в основном устроено 'облагораживание' форт-кода во многих других форт-системах.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 11:42 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Хищник писал(а):
Но не Intel же конфигурирует.

Если даже и так, то кто дает исходные данные для этого(явно или не явно).

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 12:24 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
Программист оптимизирует общую компоновку программы, определяя оптимальный алгоритм получения ее решения, от чего и зависит в большей степени производительность программы. Ускорение кода на локальных участках программы отдается компилятору с встроенными средствами анализа и ускорения кода. Как правило этим все и кончается.

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

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

Что значит "если даже"? :) FPGA стоят во многих устройствах, если их не конфигурирует пользователь, то про них никто и не знает. В случае Intel, да и еще ряда изделий класса "x86+FPGA на плате" наличие ПЛИС отмечается специально, и предназначена она для загрузки конфигурации по выбору пользователя. Разработать такую конфигурацию, разумеется, может и какая-то компания, но порядок разработки известен и доступен.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 13:50 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Хищник писал(а):
А если программист заранее, стратегически выбирает область использования так, что избыточный код со стековыми перестановками не оказывает заметного влияния на потребительские характеристики программы?

Что касается стековых перестановок. Не только стековые перестановки сами по себе замедляют код, а еще много чего из-за наличия стека параметров не имеющего аппаратной проекции в вычислительной среде, что проявляется в коде на каждом шагу. При наличии средств демонтажа стека в коде 'стратегические' раздумья на эту тему становятся бессмысленными.
Хищник писал(а):
Это наводит на мысль, что Форт применен попросту не по назначению. У любого языка программирования есть плюсы и минусы. Стек как "бутылочное горлышко", через которое необходимо пропускать весь поток данных - явный минус.

Стек может стать узким горлышком, если он не поддержан аппаратно и при этом не поддержан программно.
На уровне создания программ стек, наоборот, в сочетании с другими архитектурными особенностями форта дает много плюсов.
В языке становится проще поддерживать сразу много разных парадигм, что обеспечивает менее трудоемкую адаптацию к любой предметной области. Насчет затрат на оптимизацию в спф у вас сложилось неверное мнение. Никто кроме Михаила на нее времени не тратил. Да и он давно тоже этим не занимается, что впрочем характерно и для других форт-систем на РС. Основное там давно сделано.
Хищник писал(а):
Что значит "если даже"? FPGA стоят во многих устройствах, если их не конфигурирует пользователь, то про них никто и не знает. В случае Intel, да и еще ряда изделий класса "x86+FPGA на плате" наличие ПЛИС отмечается специально, и предназначена она для загрузки конфигурации по выбору пользователя. Разработать такую конфигурацию, разумеется, может и какая-то компания, но порядок разработки известен и доступен.

А, я не понял. Не прочитал ваши ссылки.
А так, понятно. Поставили ПЛИС для пользователей. Для решения их спец. задач на PC.
Вот только это никак не скажется на производительности уже существующего ПО, о чем я и говорил. Вот если бы тот же Microsoft
вместе с Intel оптимизировал код хотя бы своих ОС с учетом ПЛИС. А так да, доп. строчка в рекламных материалах от Intel появится.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 14:20 
Хищник писал(а):
Если подобные фрагменты так важны, слово =IF сделает примерно то же самое. Однако будет наглядно

Для Форта даже сам IF может произвести действия по оптимизации, если предварительно изменить код INTERPRET, но разговор о другом что такой код может написать в программе хоть кто и даже не важно пока нет данных о тормознутости этого и даже если тормозит то оптимизировать его не составит труда в разных вариантах.
Приоритеты каждый Фортёр раставляет, сам желателен или
нет оптимизатор и в каком виде в коде. Например для контроллеров значимость оптимизации "несколько" преувеличина (но и задачи пытаются ими решать черезмерные), но если
мы будем снижать тактовую частоту (для уменьшения потребления) и проверять функциональность устройства то
выявим предел возможностей:)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 14:34 
Хищник писал(а):
Стек как "бутылочное горлышко", через которое необходимо пропускать весь поток данных - явный минус. С ним можно бороться... это получается борьба с последствиями.

Не такое уж и узкое. Например у PIC, 51-го да и у части других контроллеров узкое горлышко аккумулятор и архитектура команд
часто CISC ну и что - это не мешает разгонять контроллеры
до 100МГц. (51-е ядро). У PIC вообще 4-е такта на команду
и ничего.


Хищник писал(а):
При этом как-то не просматриваются плюсы языка, ради которых он был выбран. .

Раз мы здесь то в плюсах нас не надо убеждать.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 14:43 
chess писал(а):
Насчет затрат на оптимизацию в спф у вас сложилось неверное мнение. Никто кроме Михаила на нее времени не тратил. Да и он давно тоже этим не занимается, что впрочем характерно и для других форт-систем на РС. Основное там давно сделано.
.

Дополню. В некомерческих системах оптимизации, зачастую вообще нет. Число Форт систем вошедших в Бенчмарк от MPE считанные разработки, и там SPF показывает неплохие результаты при том, что специально под эти тесты не оптимизировался.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 15:03 
Хищник писал(а):
Видимо, на первый план должны выходить такие факторы, как простота модификации и сопровождения программы, для чего стоило бы рассматривать конкретные подходы к выбору удобного синтаксиса, дополнительных возможностей разбора текста.

А это одна из тем так или иначе обсуждаемая на форуме.
Какие удачные находки? (каждый оценивает сам). Кому то
фреймы, кому то стековые перестановки и др.:)

Хищник писал(а):
Поэтому то, чем можно было заниматься для 486-го процессора в середине 90-х, с большими сомнениями годится для начала 10-х. Усилий надо больше, заметность результата все меньше, а альтернативных точек приложения сил существенно больше. сегодняшний день, других нет?

И эта тематика обсуждалась:) По большому счёту мало что изменилось - всё теже поиски "серебренной пули" в диспуте
а-ля Седова.

P.S. Какие значимые вещи произошли в мире IT за эти годы, что предпологает кардинально пересмотреть все существующие
знания о мире? (например IT).

P.S. Тему уже можно переименовывать во что-то другое:)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 18:31 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
Не только стековые перестановки сами по себе замедляют код, а еще много чего из-за наличия стека параметров не имеющего аппаратной проекции в вычислительной среде, что проявляется в коде на каждом шагу.

Именно что проявляется. Это то, чем мы платим за простоту кодогенерации.
chess писал(а):
При наличии средств демонтажа стека в коде 'стратегические' раздумья на эту тему становятся бессмысленными.

Как уж там - вышел математик в коридор во время пожара, увидел огнетушитель и успокоился: "решение существует!" :) Ну вот есть средства демонтажа стека, и что, это означает, что оптимизация размещения значений в регистрах появится сама?
chess писал(а):
На уровне создания программ стек, наоборот, в сочетании с другими архитектурными особенностями форта дает много плюсов.
В языке становится проще поддерживать сразу много разных парадигм, что обеспечивает менее трудоемкую адаптацию к любой предметной области.

И тогда зачем так упорно превращать стек во что-то еще?
chess писал(а):
Насчет затрат на оптимизацию в спф у вас сложилось неверное мнение. Никто кроме Михаила на нее времени не тратил. Да и он давно тоже этим не занимается, что впрочем характерно и для других форт-систем на РС. Основное там давно сделано.

Раз Михаил постоянно обращает внимание на наличие оптимизатора, можно сделать вывод, что сделано далеко не все, и такого распространения, какое хочется видеть Михаилу, его оптимизатор не получил.
chess писал(а):
Вот только это никак не скажется на производительности уже существующего ПО, о чем я и говорил. Вот если бы тот же Microsoft
вместе с Intel оптимизировал код хотя бы своих ОС с учетом ПЛИС.

Появление видеокарт с ускорением трехмерной графики тоже никак не сказалось на производительности уже существовавшего ПО.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 18:35 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Гость писал(а):
Не такое уж и узкое. Например у PIC, 51-го да и у части других контроллеров узкое горлышко аккумулятор и архитектура команд
часто CISC ну и что - это не мешает разгонять контроллеры
до 100МГц. (51-е ядро). У PIC вообще 4-е такта на команду
и ничего.

Тактовая частота и производительность вычислений - разные вещи. Еще раз - производительностью мы платим за простые алгоритмы и короткий цикл разработки инструментальных средств. В форт-процессоре стеком мы платим еще и за компактную команду. Это объективно и на это нечего закрывать глаза. Мешает или нет - другой вопрос. Надо стараться сделать так, чтобы не мешало. Но зачем вести себя наподобие влюбленного юноши, который внезапно обнаружил, что его обожаемая невеста тоже иногда какает? :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 18:44 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Гость писал(а):
Какие значимые вещи произошли в мире IT за эти годы, что предпологает кардинально пересмотреть все существующие
знания о мире? (например IT).

А куда уж сразу на мир-то замахиваться??? В области IT за последние 10 лет произошла очень важная смена ориентиров. В 90-е годы это было улучшение характеристик за счет повышения тактовой частоты процессорного ядра. В середине 2000-х был установлен новый ориентир - конвергенция. Это множество связанных устройств, которые могут использоваться одним пользователем для решения разных задач. Поэтому компьютер из "верного коня" превратился в разновидность терминала для доступа к Интернету-почте-мессенджерам, сетевым документам и прочему. Отсутствие топового процессора вовсе не пропорционально ухудшает потребительские свойства компьютера. Кроме собственно процессора важны подсистема памяти, видеокарта, HDD/SSD, качество интернет-канала. Вычищение каждого байта программы уже не является единственным способом улучшения этих самых потребительских свойств.
Гость писал(а):
Тему уже можно переименовывать во что-то другое:)

А зачем? Обсуждение по-прежнему добавляет новые штрихи к потртету Forth-64 :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: gForth x64 + debian/win
СообщениеДобавлено: Пт дек 23, 2011 19:07 
Хищник писал(а):
В форт-процессоре стеком мы платим еще и за компактную команду. Это объективно и на это нечего закрывать глаза. Мешает или нет - другой вопрос. Надо стараться сделать так, чтобы не мешало.

Перефразируя стековая структура программы ещё не свидетельствует о неэффективности кода?В (о понятии эффективности это отдельно).
Всегда найдутся техники ускорения на ядерном уровне процессора. JIT показывают такую возможность. JIT можно вшить и в микрокод CPU. Эффективность данного подхода может
получится лучше по затратам энергии/производительность чем
существующее ускорение кода "8086" процессора, например
в связке с GA144 процессорами:)


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 152 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB