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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 13:19 
mOleg писал(а):
просто альтернатива с локальными данными на стеке данных (а не возвратов, как в локалсах стандартных) удобнее, быстрее и как бы фортовее, т.е. логичнее.
А зачем они вообще? Берется кто-нибудь доказать, что программа с локалсами удобнее и красивее программы без них? Вон, любители иероглифов или оптимизации, например, так и не смогли придумать практическую задачу, где их изобретения дали бы хоть какой-то выигрыш.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 14:16 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
gudleifr писал(а):
Вон, любители иероглифов или оптимизации, например, так и не смогли придумать практическую задачу, где их изобретения дали бы хоть какой-то выигрыш.

необходимо избегать безосновательных утверждений :D - в любой задаче оптимизация даёт выигрыш


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 14:22 
вопрос писал(а):
необходимо избегать безосновательных утверждений :D - в любой задаче оптимизация даёт выигрыш
Это безосновательное утверждение. Огульная оптимизация очень часто вредна. Увеличиваются сложность и вероятность ошибки, теряется управляемость кода. Бывает, даже растет время работы. Да, просто, ненужная трата ресурсов...
Байка. При очередном запуске ракеты "Ариан" ракета заглохла на старте. Оказалось, процессор поменяли на более быстрый. Он успел прогнать тесты задолго до того, как было приведено в готовность остальное железо и от нечего делать все выключил.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 14:42 
Не в сети
Administrator
Administrator
Аватара пользователя

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 15:53 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
gudleifr писал(а):
Это безосновательное утверждение.

заменим на "почти в любой", но этот спор неконструктивен
Хищник писал(а):
Программа успевает. Будем оптимизировать?
в этом случае дополнительно - нет, т.к. она уже есть и дополнительные усилия тратят именно то, что должна экономить оптимизация - человеко-часы в первую очередь (на создании ассемблерных вставок и т.п.)
Цитата:
Он успел прогнать тесты задолго до того, как было приведено в готовность остальное железо и от нечего делать все выключил.
это не имеет никакого отношения к оптимизации :D


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 16:47 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
Хищник писал(а):
Программа успевает. Будем оптимизировать?

Похоже на предложение, например, использовать Форт без оптимизатора? (коих много)
а потом поняв, что программа не успевает лихорадочно искать приемлемое решение?

P.S. Не проще ли использовать Форт-систему с существующим оптимизатором для подстраховки от описанного случая?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 17:52 
Не в сети
Administrator
Administrator
Аватара пользователя

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

P.S. Не проще ли использовать Форт-систему с существующим оптимизатором для подстраховки от описанного случая?

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

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



За это сообщение автора Hishnik поблагодарил: Wlad
Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вс мар 18, 2012 20:25 
Думаю, что зафлуживать еще одну тему проблемами нужности оптимизации нет смысла. Проблема не в этом. Проблема в том, что о чем бы ни шел разговор: о локалсах (здесь), оптимизации, иероглифах или еще о чем-либо, сторонники этих нововведений жульничают. Они начинают свою песнь словами "Всем понятно, что претворяя в жизнь решения партсъезда..." - и считают, что дальнейшая аргументация избыточна. Т.к., на словах, все выразили готовность подкреплять свои слова практикой, то предлагаю не рассуждать о том, что было бы "хорошо", а честно анализировать применимость представляемого метода: в чем проблема, почему нельзя решить иначе, насколько помогло и т.д.

С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.

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

P.S. Да и грузить подробностями реализации для конкретной системы, думаю, менее полезно, чем подробно алгоритмизировать важные моменты. (Это я посмотрел на код, который выложил.)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Пн мар 19, 2012 04:13 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Берется кто-нибудь доказать, что программа с локалсами удобнее и красивее программы без них?
Конечно, все относительно... ;) Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще. IMHO, это единственное их достоинство. Без локалсов, конечно, можно. Но с локалсами проще. ;) Сам стараюсь не использовать - Мура начитался... :)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Пн мар 19, 2012 12:41 
in4 писал(а):
Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще...
Но с локалсами проще. Сам стараюсь не использовать - Мура начитался...
Когда это Мур призывал отказываться от того, что проще? Просто, он (и я) считает, что локалсы это ненужное усложнение. И пока я не видел контрпримеров.
Возьмем, например, C++. Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Пн мар 19, 2012 18:53 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Я, собственно, к тому, что если писАть в стиле Мура - локалсы как бы и не нужны. А если переписывать на FORTHе исходники с С или делать интерфейс с Windows - то с локалсами исходник чище - меньше стековой эквилибристики. Ну и исходники выходят похожими, можно легко найти аналогичные места.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Пн мар 19, 2012 20:50 
in4 писал(а):
делать интерфейс с Windows - то с локалсами исходник чище
Никоим образом, если не считать локалсами 4 вечных параметра сообщения. См. FOBOS.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Вт мар 27, 2012 14:23 
Не в сети
Аватара пользователя

Зарегистрирован: Чт апр 26, 2007 21:09
Сообщения: 303
Благодарил (а): 12 раз.
Поблагодарили: 10 раз.
gudleifr писал(а):
Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
Я пытаюсь. Особенно в методах установки/записи в поле "структуры". И очень себе благодарен потом, что не поленился! ;)
Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.

Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Ср мар 28, 2012 12:28 
Не в сети
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: локальные фреймы данных
СообщениеДобавлено: Ср мар 28, 2012 20:33 
Не в сети
Аватара пользователя

Зарегистрирован: Чт апр 26, 2007 21:09
Сообщения: 303
Благодарил (а): 12 раз.
Поблагодарили: 10 раз.
chess писал(а):
Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля.

Если Вас не затруднит (или это не нарушает какого-то копирайта), не могли бы вы выложить здесь или кинуть в личку код реализации этого механизма?!!!!!!!
У Броуди, в "Думай Фортно" :) , я встретил упоминание такой вещи, но Форт - у меня практически не используется, хотя мне интересен. Вот мне очень бы хотелось глянуть, как это сделано! Хотя Броуди и ратует в книге про открытость всего и вся, но мне модульный вариант ограничения видимости, предложенный Виртом (Модула-2, Обероны), очень много раз жизнь облегчал и спасал, и, скажем так, "более понятен" с точки зрения создания моделей систем...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2, 3  След.

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


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

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


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

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