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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 97 ]  На страницу 1, 2, 3, 4, 5 ... 7  След.
Автор Сообщение
 Заголовок сообщения: Статья: Мифы Форта. Часть 1: производительность
СообщениеДобавлено: Вс ноя 30, 2008 01:22 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Автор: Хищник
Дата публикации: 30 ноября 2008

Мифы Форта. Часть 1: производительность

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

Миф 1. Производительность.
Производительность – сама по себе сложнейший, развитый и запутанный миф. Кроме объективных характеристик, существует и масса субъективных, начиная с «компьютер летает – компьютер тормозит», и заканчивая «вообще-то в стратегию поиграть можно, но шутер на максимальных настройках уже не тянет». Эти мифы тесно наслаиваются на мифы программистов. Первый, приходящий обычно с новичками, читавшими про Форт, но не работавшими с ним – «Форт катастрофически медленный, потому что он интерпретирует». Такое утверждение вытекает из знания о том, что интерпретация – медленный процесс по сравнению с выполнением скомпилированного кода. В этом случае достаточно быстро следует пояснение, что в процессе интерпретации Форт обычно компилирует код, и выполняет уже его.
Однако больший информационный шум создает другой миф, который можно сформулировать примерно так: «имеется необходимость довести производительность машинного кода, генерируемого Фортом, до максимального уровня, имеющегося на современном рынке». Иными словами, дело представляется так, что распространению Форта мешает низкая производительность программ на нем. Посмотрим, так ли это.
Пункт первый. Что такое производительность сегодня? Посмотрим со стороны непрограммиста… и даже не пользователя – со стороны корпорации Intel. Просто из тех соображений, чтобы вдруг не поплыть против, а то и поперек течения. Intel на вопрос о тенденциях отвечает так: сначала была тенденция к повышению интеграции (например, введение сопроцессора на кристалл), затем – к повышению частоты (3 ГГц и более). Сейчас (внимание!) – к увеличению количества ядер. В том числе, кстати, и к их специализации. Например, уже достаточно давно графический ускоритель существенно обгоняет CPU в трехмерной графике, и разве что программы 10-летней давности имели режим «программная эмуляция трехмерной графики». Не так хороши CPU и в задачах цифровой обработки сигналов (производительность лимитируется пропускной способностью памяти, которая относительно невысока). Соответственно, при решении задачи необходимо посмотреть, какой процент действий выполняется центральным процессором, а какой – специализированными устройствами. Скорее всего окажется, что характеристики производительности невысоки не из-за того, что часть кода скомпилирована Фортом, а из-за вызова специальных функций в неоптимальных режимах.
Пункт второй. Синтетические и реальные тесты. Рассмотрим классическую ситуацию – сравниваются две программы, или два транслятора Форта. Для них составляется некий тест, который запускается на исполнение с замером времени. Получаемые результаты обобщаются на все характеристики такого транслятора. Все ли здесь правильно? Посмотрим на возможные источники ошибок при оценке производительности таким способом.
1. Параметры производительности зависят от размеров данных, а тест создан для короткого массива и запущен в цикле. В итоге в процессе тестирования данные уместились в кэше (вариант – поместились в основной памяти, а не оказались выгружены на диск), а на реальных задачах оказывается, что основное время уходит на обмен с диском, поэтому разница в производительности программного кода совершенно несущественна.
2. Тестовые программы по отдельности написаны корректно и аккуратно, но писать в таком стиле неудобно, и при большом объеме текста программисты «срываются» на неоптимальный стиль. Пример:
Код:
Array[] I 4 * + \ получить адрес i-го элемента массива
@ действия1
Array[] I 4 * + \ еще раз получить адрес i-го элемента массива
@ действия2


Очевидно, что два раза вычислять адрес – бросающаяся в глаза потеря производительности. К тому же хорошо бы 4 * заменить на сдвиг.
Код:
Array[] I << + DUP
@ действия1
@ действия2


Количество действий, безусловно, сократилось. Правда, теперь, особенно если между двумя @ достаточно много текста, при взгляде на @ действия2 программист может внезапно задаться вопросом «а откуда это я забираю данные?». Да, разумеется, с точки зрения «высокой теории» и «правильной организации производства», а также «необходимости поддерживать высокую квалификацию и культуру творческого труда» такому программисту можно бы попенять, и сказать, что для него писать оптимально на уровне исходного текста, не перекладывая работу на компилятор – дело чести. А то и зарплаты. Однако стоит посмотреть и реально – человек имеет некоторое моральное право не быть 8 часов без перерыва роботом с высочайшей концентрацией внимания, и писать только неизбыточный код. К Форту это относится не в большей степени, чем к другим языкам – программист может повторно инициализировать переменные «на всякий случай», оставить лишнюю информацию для отладки логики программы, наконец, лишний раз инкапсулировать данные, заставив процессор выполнять вызовы функций вместо исполнения линейного кода. Весь вопрос в том, что все эти действия могут оказаться отнюдь не в критической части программы. Или, исходя из пункта 1, при работе реального проекта внимание пользователя будет уделяться совсем другим аспектам, а вовсе не скорости выполнения подготовительных и вспомогательных действий.
3. Программист оценивает важность тестов не по их значимости для пользователя, а по сложности разработки. Успех в реализации сложного участка программы приятен. Психологически хочется еще раз осознать, какая же важная работа проделана, и какие замечательные показатели достигнуты. Это заставляет программиста, возможно неосознанно, чрезмерно выпячивать важность именно тех частей программы, над которыми работал лично он. Можно указать также на выкладывавшийся в интернете тест-шутку (!), состоявший из большой таблицы весовых коэффициентов для компиляторов разных языков программирования. Предлагалось путем манипулирования коэффициентами вывести на первое место любимый компилятор. Возможности теста по созданию ложного лидерства, что характерно, весьма велики.
Пункт третий. Все ли технологии программирования ориентированы на достижение максимальной производительности выполняемого кода? Ответ – нет. Даже скорее нет, чем да. Чаще первый релиз продукта предназначен для обозначения своей позиции на рынке, а потом идет выпуск апдейтов, сервис-паков и новых версий. К тому же с аппаратной платформой тоже не все так просто. Здесь и закон Мура (Гордона, а не Чарльза), в соответствии с которым в процессе повышения производительности программы на 10% она может повыситься на столько и «естественным путем» - за счет выпуска нового процессора (но все это время компания доводила свой продукт, а не продавала его, а значит, и денег не получала), и дифференциация самих компьютеров. Существуют рабочие станции и домашне-игровые десктопы с мощными процессором и видеокартой, офисные десктопы со слабым процессором и встроенной графикой, «обычные» ноутбуки со средними параметрами, «мобильные интернет-устройства» (MID) – компактные ноуты и нетбуки… о каком же компьютере идет речь? Скорее всего, пользователь программы не будет с секундомером замерять производительность приложения, а при неудовлетворительной работе на нетбуке согласно кивнет головой и перейдет на десктоп. Поэтому колебания производительности кода на 20-30% вряд ли будут даже выявлены, не говоря уже о категорическом отказе от программы, которая работает немного медленнее, чем ожидалось.
Пункт четвертый. Требуется ли программисту обязательно писать очень производительный код, чтобы хорошо зарабатывать? Общая ситуация в высокотехнологичной отрасли утверждает обратное. Например, дефицит специалистов IT-индустрии в России за 2007 год составил около 25%! То есть на 4 рабочих места есть только 3 специалиста, и никто не гарантирует, что это хотя бы нормальные сотрудники, не говоря уже о квалифицированных. Вследствие этого, а также общего провала квалифицированных специалистов, общие требования к программным продуктам понижаются. В ряде случаев создается ситуация, когда для качественной программы попросту нет соответствующей инфраструктуры – с ней не готовы работать сотрудники заказчика, она резко выделяется на фоне других программных средств, наконец, не она является слабым звеном, так что заказчик правильно полагает, что выбросит деньги на ветер, приобретая избыточное качество. В мировом масштабе, кстати, можно обратить внимание хотя бы на мем «программист-индус». Какие здесь ассоциации? В основном «таких программистов очень много, и они массово пишут некачественный код». Спрашивается, почему тогда индусы, неужели нельзя вместо 10 малограмотных найти одного профессионала? Разгадка кроется в особенностях программы как рыночного продукта – бурный рост аппаратной базы и автоматизация инструментария разработки и распространения привели к тому, что программ надо очень много, а главное – быстро. И даже скорее быстро, чем качественно, потому что пользователи еще не всегда сами толком знают, что же им объективно нужно. Прежде чем возмущаться такой неграмотностью и безответственностью (см. «пипл все схавает, Microsoft ему объяснит, что он должен хотеть»), надо хотя бы посмотреть на прогресс вычислительной техники в пределах одного поколения. Например, сколько человек (в процентах от населения) имели доступ к компьютеру в 1983-88 годах (20-25 лет назад). Сколько человек имели мобильный телефон 10 лет назад? Насколько те же 10 лет назад были распространены сети масштаба предприятия (и вообще сетевые технологии, включая интернет-магазины и MMORPG – а ведь в этих областях также присутствуют приличные объемы финансов). В результате оказывается, что подготовка специалистов, которые могли бы поддерживать высокую планку производительности программ по всем направлениям, сильно отстает от распространения вычислительной техники, как среди населения, так и в промышленности, медицине, связи и т.д.
Пункт пятый. Реален ли путь конкурирования с ведущими компиляторами, используемыми в компьютерной индустрии? Необходимо указать как минимум на тот факт, что «компьютерные науки» (computer science) не так давно окончательно оформились в отдельное научное направление, хотя раньше исследуемые ими вопросы могли попадать в разделы прикладной или вычислительной математики. Тем не менее, уже сейчас небольшая с точки зрения ее вовлеченности в построение компилятора задачка может быть целым направлением научного коллектива, сопряженной с многолетними исследованиями, публикацией статей, защитой диссертаций и т.д. Можно работать в рамках такого коллектива, но надеяться на самостоятельный параллельный выпуск трансляторов Форта, отстающих от лидеров на единицы процентов, бессмысленно.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 01:38 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Реален ли путь конкурирования с ведущими компиляторами, используемыми в компьютерной индустрии? Необходимо указать как минимум на тот факт, что «компьютерные науки» (computer science) не так давно окончательно оформились в отдельное научное направление, хотя раньше исследуемые ими вопросы могли попадать в разделы прикладной или вычислительной математики. Тем не менее, уже сейчас небольшая с точки зрения ее вовлеченности в построение компилятора задачка может быть целым направлением научного коллектива, сопряженной с многолетними исследованиями, публикацией статей, защитой диссертаций и т.д. Можно работать в рамках такого коллектива, но надеяться на самостоятельный параллельный выпуск трансляторов Форта, отстающих от лидеров на единицы процентов, бессмысленно.

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

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 01:41 
Не в сети
Administrator
Administrator
Аватара пользователя

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

Хищник как всегда лев (по гороскопу)! :))
вопрос писал(а):
Трезвость подсказывает, что нужно искать "хорошо оформленный" вариант производительности -
для форта это достаточно сделать путём вложенного ин-лайна и всё, можно минимальную оптимизацию, чтобы не было совсем торможения если вдруг что.
А дальнейшая оптимизация - как получится. Но инлайн должен быть стандартом...
ИМХО

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 01:43 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
вопрос писал(а):
Трезвость подсказывает, что нужно искать "хорошо оформленный" вариант производительности -

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 01:45 
Не в сети

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

Цитата:
инлайны и прочие хитрости
Инлайн не хитрость, это закономерное, очень простое и эффективное противоядие против непомерной вложенности слов форта

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 08:30 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
вопрос писал(а):
Инлайн не хитрость, это закономерное, очень простое и эффективное противоядие против непомерной вложенности слов форта


Так это что же, получается, что и факторизация - зло?
:shock:

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 11:25 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
WingLion писал(а):
вопрос писал(а):
Инлайн не хитрость, это закономерное, очень простое и эффективное противоядие против непомерной вложенности слов форта

Так это что же, получается, что и факторизация - зло? :shock:

Наоборот, добро, а инлайн, это способ избавиться от побочных нежелательных последствий. Ведь следствие факторизации - несколько call - ret в каждом слове дополнительно (в цикле таковых могут быть миллионы).

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс ноя 30, 2008 12:41 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Циклы, которые выполняются миллионы раз - штука редкая и специфичная. Сколько таких на программу? Сколько внимания уделяет им программист? Обычно рано или поздно находится нормальный вариант реализации, когда везде аккуратно и со вкусом заинлайнены критические места. Но такие программы редко пишутся "на потоке". Кроме того, что такое миллионы циклов, когда за секунду выполняются миллиарды? И наконец, пп. 3,4 статьи. Часто важнее получить хоть что-то уже работающее и запустить это "в жизнь" (а заодно и в получение отзывов, обратной связи, багрепортов), чем месяцами доводить производительность с 90% идеала до 95%.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 14:35 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Хищник писал(а):
Однако стоит посмотреть и реально – человек имеет некоторое моральное право не быть 8 часов без перерыва роботом с высочайшей концентрацией внимания, и писать только неизбыточный код.


Для этого и существуют автоматические оптимизаторы, чтобы снять часть проблемы с программиста.
И форт тут не исключение. Эффективность скомпилированного кода, может быть последним аргументом
при выборе средства программирования.

Хищник писал(а):
Все ли технологии программирования ориентированы на достижение максимальной производительности выполняемого кода? Ответ – нет.


Для всех желателен.

Хищник писал(а):
в соответствии с которым в процессе повышения производительности программы на 10% она может повыситься на столько и «естественным путем» - за счет выпуска нового процессора (но все это время компания доводила свой продукт, а не продавала его, а значит, и денег не получала), и дифференциация самих компьютеров.


Стало-быть быстродействие не устраивало пользователей, если из-за него задерживали выпуск продукта.

Хищник писал(а):
Вследствие этого, а также общего провала квалифицированных специалистов, общие требования к программным продуктам понижаются.


Большие фирмы, захватившие некую нишу, вне конкуренции, т.к. могут производить большие по трудозатратам продукты.
Мелкие (полезные) программы, практически, все реализованы.

ЗЫ: Так какой миф относительно Форта оспаривается? Форт медленный или нет? Или это неважно?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 15:31 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Mihail писал(а):
Для этого и существуют автоматические оптимизаторы, чтобы снять часть проблемы с программиста.
И форт тут не исключение. Эффективность скомпилированного кода, может быть последним аргументом
при выборе средства программирования.

И если таких средств не существует, то это не главный контраргумент. Начнем с алгоритмической оптимизации, которая может повысить производительность программы в разы (а оптимизаторы - на проценты).
Mihail писал(а):
Хищник писал(а):
Все ли технологии программирования ориентированы на достижение максимальной производительности выполняемого кода? Ответ – нет.

Для всех желателен.

Еще раз читаем вопрос. Поголовной ориентации на максимальную производительность уже нет. Ее по факту нет, программы свободно пишутся на самых разных языках, и никто в них пальцем не тычет. Исключения заметны сразу - топовая стрелялка с разрушением окружающей обстановки и огромными открытыми пространствами, к примеру. Но можно ли утверждать, что высокая скорость там обеспечивается оптимизатором, подчищающим неаккуратности программиста?
Mihail писал(а):
Хищник писал(а):
в соответствии с которым в процессе повышения производительности программы на 10% она может повыситься на столько и «естественным путем» - за счет выпуска нового процессора (но все это время компания доводила свой продукт, а не продавала его, а значит, и денег не получала), и дифференциация самих компьютеров.

Стало-быть быстродействие не устраивало пользователей, если из-за него задерживали выпуск продукта.

И опять не не вчитался. Выпуск продукта производят. А потом выпускают патчи. И если потребители говорят, что слишком медленно, с производительностью что-то делают.
Mihail писал(а):
Мелкие (полезные) программы, практически, все реализованы.

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

Mihail писал(а):
ЗЫ: Так какой миф относительно Форта оспаривается? Форт медленный или нет? Или это неважно?

Мифы не оспариваются - на мифы указывают. Как на сказки. Ну не спорить же с ними? :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 15:43 
Не в сети
Аватара пользователя

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

Столкнувшись с Фортом ознакомился с мифом об очень высокой производительности программ на нем
(чуть хуже чем на ассме). :D Этот миф чуть позже рассеялся.
Второй миф - форт очень прост, рассеялся уже попозже.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 17:30 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Хищник писал(а):
Такой вывод ты делаешь из-за того, что их не заказывают конкретно тебе?


Никогда заказами не занимался. Работаю не зарплату (что поручит начальство). Форт применяю.

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


Что за статистика? Когда последний раз продали продукт с затратами на его производство менее 1-го человека месяца?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 17:37 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
chess писал(а):
Столкнувшись с Фортом ознакомился с мифом об очень высокой производительности программ на нем
(чуть хуже чем на ассме).


Все зависит от труда вложенного в оптимизатор.

chess писал(а):
Второй миф - форт очень прост, рассеялся уже попозже.


Избыточно сложным можно сделать все что угодно. Вообще форт это набор именованных
процедур - куда проще?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 19:21 
Не в сети
Administrator
Administrator
Аватара пользователя

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

Но тогда как-то интересно получается. Тебе работу поручает начальство, то есть решение о выборе направления деятельности принимаешь не ты. Но ты почему-то полагаешь возможным решать за других, чем им надо заниматься. Более того, наглядно демонстрируешь, что будет, если пойти по предлагаемому тобой пути - работу будет поручать начальство ;)
Mihail писал(а):
Что за статистика? Когда последний раз продали продукт с затратами на его производство менее 1-го человека месяца?

А при чем тут человеко-месяцы? Впрочем, какие-нибудь цветные крестики-нолики, или "Веселые циферки с Гарфилдом", которые сейчас лежат у детей, даже месяца у программиста на полную ставку не займут. А в каком-нибудь магазине такими штуками забиты все полки.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 01, 2008 19:35 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Хищник писал(а):
Но ты почему-то полагаешь возможным решать за других, чем им надо заниматься.


На это счет все люди имеют свое мнение, но я не помню чтобы я его высказывал.

Хищник писал(а):
Более того, наглядно демонстрируешь, что будет, если пойти по предлагаемому тобой пути - работу будет поручать начальство


По моему это по какому? Я бы хотел приобрести независимость. Но какое отношение имеет мой путь к начальству?


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

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


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

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


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

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