Здравствуйте, Pavel Dvorkin, Вы писали:

<skipped>

PD>1. Рост мощностей продолжится прежними темпами. В этом случае и для многих других задач станет возможным пренебречь эффективностью. Возможно, это коснется и настольных приложений. Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост".
PD>2. Рост мощностей замедлится. В этом случае для тех задач, для которых и ныненшняя мощность избыточна, все останется как сейчас. Но понемногу будут подтягиваться задачи, которые пока что или вообще не решаются (может быть, даже само их существование пока не осознано, так что их и не ставят), или же решаются с трудом, так как имеющиеся способы их решения вынуждены были ориентироваться на имеющиеся мощности (игры — классический пример). Доля этих задач будет возрастать, что приведет к возврату требований по эффективности написания кода.

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

Решил еще раз вернуться к этому вопросу и посмотреть на него с несколько иной точки зрения.

Тема оптимизации, которую я инициировал, вызвала весьма бурную реакцию. Насколько я понимаю (судя по оценкам , многие со мной согласны, в то же время были высказаны соображения, которые я если и не принимаю полностью, то отмахнуться от них все же не могу.

Вернуться к вопросу меня побудило вот это сообщение IT. Впрочем, и до него аналогичные мнения высказывали и другие.

http://www.rsdn.ru/Forum/Message.aspx?mid=1482509&amp;only=1

Автор: IT
Дата: 11.11.05

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

Оставив в покое молиеносное чтение из файла как частный случай, рассмотрим основной постулат :

>Но пока таких нет. И не только у меня, а у подавляющего большинства здесь присутствующих, т.к. времена, когда это было действительно насущей проблемой для масс давно прошли.

Не могу не признать правоты этого высказывания. Действительно, коль уж нет — то нет. А почему нет ?

Попробую высказать следующее утверждение

В последнее десятилетие рост мощности компьютеров (ограничусь только объемом RAM и скоростью процессора) был столь большим, что в результате мир IT оказался в редчайшей ситуации — возможности имеющейся техники для многих задач существенно превышают то, что необходимо для этих задач.

Попробую аргументировать.

Пусть, к примеру, создается сайт для небольшой торговой компании. Общее количество наименований продукции не более 1000. Положив по 100 Кбайт на каждый вид продукции, имеем 100 Мбайт информации, которой фирма оперирует. Из этого объема процентов 70-80 — просто файлы с документацией, доступные для скачивания, а остальное — база данных, HTML страницы и т.д. Никаких Java апплетов там не предвидится.

Кстати, 100 Мбайт — не так уж мало. 500-страничная книга — это примерно 1 Мб. Так что 100 Мб — это шкаф на сотню таких книг, что реально и имела бы фирма, если бы не было компьютеров вообще.

Обращений к этому сайту ожидается не так уж много. Сотни сеансов в день, вряд ли более.

И вот вам поручили сайт для этой фирмы сделать. Естественно, вы не запросите супер-сервер, сойдет любая современная машина в серверном (а то и не в серверном исполнении. Pentium IV, 3 GHz, 512 Mb. О сети я сегодня не говорю вообще.

А теперь зададим следующий вопрос. На каком минимально оборудовании можно было бы такой сайт создать ? Полностью игнорируем имеющееся ПО, все средства разработки и т.д. Какая машина это может потянуть ? Вот IBM PC XT — не потянет, как там ни оптимизируй, это ясно. А какая (минимально) потянет ?

Мой ответ — Pentium-100 32 Mb. Ну в крайнем случае раза в 2 лучше

Доказательство — 10 лет назад такие сайты были, если не у нас, то в США, и работали они на такой технике. И оперировали они тем же объемом информации, просто потому, что никакой принципиально новой информации у фирмы, торгующей ,к примеру, компьютерами, просто не появилось. Изменился ассортимент, вот и все.

А кстати, какой клиент это все потянет ? Netscape 3.0 на 16 Мб под Windows 95 потянет ? Тянул же он раньше...

Другой пример. Зашел я полгода назад в налоговую инспекцию. Бросил взгляд на экран компьютера, и сразу стало ясно, на чем их ПО написано — FoxPro для DOS ни с чем ни спутаешь, внешний вид уж больно характерный. Создано это ПО лет 10 назад, и до сих пор благополучно работает. Не знаю, какте там у них клиентские машины и сервер, но вряд ли что-то фантастическое. Да и зачем — в инспекции работает не более 100 человек, а каждый сотрудник 95% процентов времени работает с клиентами и бумагами, а не с компьютером. Сомневаюсь, что одновременно к этому серверу у них бывает больше 5 обращений когда бы то ни было.

Кстати, и в отделении Сбербанка у нас в Омске еще года 2 назад FoxPro DOS была. Сейчас, правда, уже нет.

Вот, кстати, немного арифметики

1983 Хороший компьютер — XT, 640 Кбайт, 4.7 MHz
1990. Компьютер 386 DX, 40MHz с 4 Мб — хороший компьютер.
2005 Приличный компьютер — Pentium IV, не менее 2 GHz, не менее 512 Mb

За первые 7 лет — рост менее чем в 10 раз
За вторые 15 лет — в 50-100 раз.

А сложность задач в 50 раз отнюдь не увеличилась. Для той торговой фирты, с которой я начал, она и не могла увеличиться в 50 раз — просто потому, что нет у нее задач такой сложности. И не предвидится.

Разумеется, я далек от мысли утверждать, что это для всех задач верно. Если, к примеру, игры взять — все мои построения немедленно рушатся. И можно еще много таких направлений назвать, которым и нынешних мощностей мало, и в 10 раз увеличь — все равно, скажут, что мало, и будут правы. И не для всех сайтов это, конечно, верно.

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

А если так, то и появилась возможность пренебречь эффективностью. Действительно, когда ресурсов у нас в 10-20 раз больше, чем требуется — зачем относиться к ним с экономией ? Если мы имеем в 10 раз больше ресурсов, чем требуется — можно позволить и 2-3 кратную потерю эффективности в той же .Net — все равно работать будет с хорошей скоростью и заказчика устроит. Тут мои оппоненты правы. В результате и появился тот самый подход, пренебрегающий эффективностью в пользу других приоритетов, о которых тут много писали.

Кстати, эта точка зрения хорошо объясняет тот факт, что ASP.NET пользуется приличной популярностью, а настольных .NET приложений очень мало. Сайт на ASP.NET работает обычно на отдельной машине, кроме него самого и средств управления там больше ничего и нет, вольготно и раздольно. Настольные же приложения работают там, где кроме них есть еще 10-20 конкурентов, поэтому то замедление, которое они бы привнесли, многим не понравится.

Позволю себе вольную аналогию. Сервер на ASP.NET — это новый русский, отгрохавший себе особняк на 20 комнат и не знающий, что теперь с ними делать. Раздолье полное, можно любые причуды реализовать. А настольное приложение проживает в обычной трехкомнатной квартире многоквартирного дома, и когда оно пытается у соседа кухню отхватить — домовладельцу это не очень нравится

Если мои соображения верны, то ИМХО возможны следующие варианты развития

1. Рост мощностей продолжится прежними темпами. В этом случае и для многих других задач станет возможным пренебречь эффективностью. Возможно, это коснется и настольных приложений. Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост".
2. Рост мощностей замедлится. В этом случае для тех задач, для которых и ныненшняя мощность избыточна, все останется как сейчас. Но понемногу будут подтягиваться задачи, которые пока что или вообще не решаются (может быть, даже само их существование пока не осознано, так что их и не ставят), или же решаются с трудом, так как имеющиеся способы их решения вынуждены были ориентироваться на имеющиеся мощности (игры — классический пример). Доля этих задач будет возрастать, что приведет к возврату требований по эффективности написания кода.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Решил еще раз вернуться к этому вопросу и посмотреть на него с несколько иной точки зрения.

Непомню кто сказал:
Увеличение произвадительности компьютера почти никак не скажется на простых задачах .
НО!
Тысячи сложных задач станут простыми ,
Станут сложными сотни очень сложных ,
И станут возможными несколько невозможных

Здравствуйте, Дарней, Вы писали:

Д>что сложнее — выдолбить из мрамора статую высотой в два метра, или построить небоскреб высотой в энное количество сотен метров?

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

Существенная разница в том, что для изготовления статуи необходимо иметь уникальное сочетание различных знаний и умений в одном человеке, в скульпторе. В "Законах Паркинсона" это сочетание качеств называется мастерством.

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

Ключевой момент в том, что даже у самого искусного руководителя возникает потребность в самых мастеровитых исполнителях. Например, когда-то я видел фрагменты документальных съемок монтирования верхушки какой-то телебашни (кажется в Канаде). Дело происходило на такой высоте, что очередную часть конструкции приходилось доставлять туда на вертолете, а принимали и укрепляли ее два строителя, пристегнутые к башне альпинистским снаряжением. Думаю, что исполнить такую работу могли только профессионалы высочайшего класса (как строители, так и пилот вертолета). Хотя для всего строительства это был всего лишь частный эпизод, один из многих моментов.

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

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

Так вот хочу заявить, что лично мне гораздо интереснее решать мелкие, но сложные задачи. Где требуется проявление личного мастерства. А вот большие и сложные, для которых нужна искусность, меня совершенно не привлекают. По разным причинам. Но, главное, ну не нравится мне делать большие разработки. Ну хоть убей! А вот маленькие, но трудоемкие и уникальные -- за милую душу, за гроши,... Да за харчи, в конце-концов! Потому, что интересно до безобразия.

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

PS
Я никому не возражал. Это скорее из разряда "крик души"
Просто последние два дня курю над очередной темой, слишком большой объем в ней намечается, а сложности/уникальности особой не видно. Вот поорать и захотелось.

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

Большинство пользователей не имеют притензий к скорости настольных приложений, написанных на VB. (.net работает быстрее.)
Зато притензий к скорости программ, написанным на С++ — масса. Возьмите Word или Windows, например. Следуя Вашей логике можно решить, что с++ — самый тормознутый язык из всех когда-либо используемых.

Ну не надо про это, прошу Вас. Смешно и грустно. Толку удручающе мало. Выбирайте другие примеры.

А вообще — не согласен я с Вами категорически. Рост требований к железу связан с увеличением алгоритмической сложности в единицу времени на единицу программиста. Отсюда и новые среды/языки. Мифическое "торможение" .net полностью теряется на фоне общего кол-ва операций, которые современным программам необходимо выполнять. На современном компьютере для .net места более чем достаточно. Значит и в будущем ничего в этом плане не изменится.

Более того, рост мощностей компьютеров будущего будет, видимо, связан в основном с многоядерными процессорами. Следовательно — быстрыми будут не оптимизированные вообще алгоритмы, а оптимизированные под многопоточное исполнение. И как следствие, программирование будущего — оно многопоточное. И хотя я не знаю, на каком языке мы будем писать эти программы, но то, что это не будет ни с++ ни asm — практически не сомневаюсь.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мой ответ — Pentium-100 32 Mb. Ну в крайнем случае раза в 2 лучше
Мало иметь 100Мб информации, нужно еще ею эффективно управлять. Это уже СУБД. А теперь представим какой объем должен кэшироваться в памяти чтобы диск не стал узким и жестко ограничивающим средством. Мы можем задумываться больше о той полезной функциональности которую мы можем реализовать. Лет 10 назад, это стоило бы значительно дороже.

PD>Доказательство — 10 лет назад такие сайты были, если не у нас, то в США, и работали они на такой технике. И оперировали они тем же объемом информации, просто потому, что никакой принципиально новой информации у фирмы, торгующей ,к примеру, компьютерами, просто не появилось. Изменился ассортимент, вот и все.
20 лет назад, если бы у нас была задача организовать сайт с такой-же нагрузкой как у RSDN — то нам бы пришлось купить компьютер размером с хорошую комнату и такой производительности, что вся бы страна гордилась. А чтобы написать аналогичный софт, нужно было-бы потратить огромнейшую кучу времени, нанять огромнейшее количество программистов, и заплатить несколько миллионов.

PD>А кстати, какой клиент это все потянет ? Netscape 3.0 на 16 Мб под Windows 95 потянет ? Тянул же он раньше...
Было уже такое. Вся нагрузка на сервер, рабочая станция — один монитор, да связь с сервером. Но количество задач решаемый сейчас пользователем значительно больше.
PD>Другой пример. Зашел я полгода назад в налоговую инспекцию. Бросил взгляд на экран компьютера, и сразу стало ясно, на чем их ПО написано — FoxPro для DOS ни с чем ни спутаешь, внешний вид уж больно характерный. Создано это ПО лет 10 назад, и до сих пор благополучно работает. Не знаю, какте там у них клиентские машины и сервер, но вряд ли что-то фантастическое. Да и зачем — в инспекции работает не более 100 человек, а каждый сотрудник 95% процентов времени работает с клиентами и бумагами, а не с компьютером. Сомневаюсь, что одновременно к этому серверу у них бывает больше 5 обращений когда бы то ни было.
PD>Кстати, и в отделении Сбербанка у нас в Омске еще года 2 назад FoxPro DOS была. Сейчас, правда, уже нет.
Это компьютер адаптированный для выполнения конкретно-поставленной задачи. Это вполне нормально и никакого противоречия я не вижу. Он не такой же как обычный, он другой. Для него требования другие.

PD>А сложность задач в 50 раз отнюдь не увеличилась. Для той торговой фирты, с которой я начал, она и не могла увеличиться в 50 раз — просто потому, что нет у нее задач такой сложности. И не предвидится.
Усложнились не задачи которые решаются торговой фирмой. Усложнились задачи выполняемые с помощью компьютера. И именно благодаря развитию железа и софта.

PD>Кстати, эта точка зрения хорошо объясняет тот факт, что ASP.NET пользуется приличной популярностью, а настольных .NET приложений очень мало. Сайт на ASP.NET работает обычно на отдельной машине, кроме него самого и средств управления там больше ничего и нет, вольготно и раздольно. Настольные же приложения работают там, где кроме них есть еще 10-20 конкурентов, поэтому то замедление, которое они бы привнесли, многим не понравится.
Ну нету у Net приложений провала в производительности. Есть отставание в 30-40 процентов. Когда я начинал, шли разговоры о борьбе между С и ассемблере. Там тоже была разница в 30-40 процентов. Сейчас об этом никто не задумывается. Если приложение специализированное, то цифра бесусловно может меняться.

PD>Позволю себе вольную аналогию. Сервер на ASP.NET — это новый русский, отгрохавший себе особняк на 20 комнат и не знающий, что теперь с ними делать. Раздолье полное, можно любые причуды реализовать. А настольное приложение проживает в обычной трехкомнатной квартире многоквартирного дома, и когда оно пытается у соседа кухню отхватить — домовладельцу это не очень нравится
Некорректно сравнивать два совершенно разных приложения предназначенных совершенно для разных целей.

PD>Если мои соображения верны, то ИМХО возможны следующие варианты развития

PD>1. Рост мощностей продолжится прежними темпами. В этом случае и для многих других задач станет возможным пренебречь эффективностью. Возможно, это коснется и настольных приложений. Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост".
Нет, не на вырост. Уже сейчас на среднем компьютере Net приложения нормально выполняются без потери эффективности. Мало того, он еще и выполняется в КПК — там где разгуляться с ресурсами нельзя.
PD>2. Рост мощностей замедлится. В этом случае для тех задач, для которых и ныненшняя мощность избыточна, все останется как сейчас. Но понемногу будут подтягиваться задачи, которые пока что или вообще не решаются (может быть, даже само их существование пока не осознано, так что их и не ставят), или же решаются с трудом, так как имеющиеся способы их решения вынуждены были ориентироваться на имеющиеся мощности (игры — классический пример). Доля этих задач будет возрастать, что приведет к возврату требований по эффективности написания кода.
Это сказка. Пути назад уже нет.

Вообще ты все время упускаешь следующую вещь. То что сейчас делает один программист, раньше стоило несколько миллионов зеленых. Мы вкатились в систему компонентов и библиотек. Я уже не должен отслеживать обратный ход луча на мониторе. Мы теперь используем более функциональные компоненты как кирпичи. И основное торможение в программах дают именно эти компоненты. Они многое могут, они сильно нам помогают, но именно они и являются тормозом производительности. Но развитие железа опережает развитие компонентов. Поэтому мы можем меньше думать о них, и больше думать о том, что мы хотим сделать. Кто может сказать что лет 15 назад он в одиночку написал бы сервер приложений?
Вообще, основное торможение и раньше давал не код, а используемые компоненты и железо. Даже на 286 было трудно написать тормозной код, но легко было стормозить программу работой диска и выводом на экран.
И еще, голову никто не отменял. Если у тебя несколько потоков деруться за один ресурс, то как бы ты не старался написать быстрый код, скорость не увеличится. Вот именно на разрешение подобных проблем, времени остается значительно больше.
Вобщем, перевод требований по эффективности кода это процесс не искуственный, это процесс эволюционный.

С уважением, Gleb.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А сложность задач в 50 раз отнюдь не увеличилась.

Вырезка из форума на Королевстве Дельфи:

№ 3198 01-11-2005 10:29 Андрей Хохлов

Есть некая Native ОС Oberon для IBM PC (http://www.oberon.ethz.ch/native/). Кто-нибудь ее ставил? (Главное опасение — не испортить установленные ОС)

№ 3214 02-11-2005 01:11 Trurl

У этой ОС есть недостаток — она не позволяет загрузить по полной современный процессор.

№ 3217 02-11-2005 01:58 Читатель

Если можно, поясните что значит "не позволяет загрузить современный процессор" и заодно, почему это недостаток.

№ 3243 03-11-2005 03:10 Trurl

Например, работая на P2-200MHz и на P4-2GHz, не замечаешь особой разницы.
Почему недостаток? Ну как же, а за что деньги плочены?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Попробую высказать следующее утверждение

PD>В последнее десятилетие рост мощности компьютеров (ограничусь только объемом RAM и скоростью процессора) был столь большим, что в результате мир IT оказался в редчайшей ситуации — возможности имеющейся техники для многих задач существенно превышают то, что необходимо для этих задач.

На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая. Что это означает? А то, что тяжело мне в жизни приходится ибо интересных мне задач очень мало. Но они есть (видишь суслика?) и я стараюсь всеми силами "грести их под себя" — такова моя жизненная философия. Я стремлюсь быть уникальным, штучным экземпляром, мне не интересно находиться на уровне рутинщика.

Вот пример. Некий поиск в коллекции (многокритериальный) через прямую имплементацию работает в 10 раз быстрее, чем если задействовать reflection (прямая имплементация — кучерява, через reflection — компактна и изящна). Но этот поиск требуется там, где совершенно несущественно, работает ли он 1 миллисекунду или 10 миллисекунд, поэтому ускорение в 10 раз совершенно не повод что-то там оптимизировать. Мотивом к оптимизации была бы ситуация, если бы решение с reflection работало бы еще в 1000 раз медленнее. То есть, счет в данном случае идет на сотни и тысячи раз, чтобы имело смысл дергаться — таков usecase. То есть, это типичная задача класса O(1) по использованию. Формально алгоритмически она — O(N), но по жизни нет ни малейшей видимой зависимости времени работы от количества данных — значит O(1). Это пример задачи, которая мне ну вообще не интересна — чисто механическая работа, примерно как свинчивать магазинную мебель. Да, мебель при этом — советская, дырки кое-где не просверлены, а те что есть — просверлены на пару миллиметров мимо, в общем, "творчество" заключается в том, чтобы при помощи молотка и такой-то матери все это таки свинтить, а потом еще и попытаться со всей этой х... взлететь. Эффективней нанять "винтильщика", который за умеренную плату выполнит эту работу (аутсорс), тем более, что у него рука набита. Но вот парадокс — грамотных винтильщиков тоже очень мало, в большинстве случаев все надо проверять, докручивать и поддтягивать за ними, иначе рано или поздно что-нибудь да отвалится (полностью не развалится, нет — чисто какая-нибудь мелочь — ручка там разболтается, дно в яшике провалится, ну дело-то житейское). А все почему? А потому, что винтильщику пофиг что там будет с этим комодом через год — у него нет мотивации. Но это уже вне темы.

Пример другой задачи — придумать способ, как генерировать 2 миллиона треугольников в секунду, вместо одного (ну, скажем, из сцены Flash). Разница — всего-навсего вдвое. Но во-первых, эта разница является мега-критичной в силу usecase, во-вторых, это тот тит задач, к которым у меня имеется хроническая наркотическая зависимость. Здесь уже не может быть и речи о том, что "заменил контейнер — ускорил вдвое". Если используется неэффективный контейнер или неэффективная сортировака, то это — халтура по определению, ибо это — самая простая часть задачи по оптимизации. Но еще раз повторю — подобных задач крайне мало и именно поэтому я заинтересован работать над ними с полной выкладкой, поскольку качество становится вопросом моей профессиональной состоятельности.

Таким оброазом, необходимость эффективных решений определяется целиком и полностью их use case. И если задачи, над которыми человек работает, относятся к категории рутинных O(1), значит таков его личный выбор в конечном итоге. Вот и всех делов.

Здравствуйте, Дарней, Вы писали:

Д>ну если для тебя написание ОС — посредственная задача, то мне остается только удивляться, почему ты еще не нанял Билли Г работать уборшиком

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

Еще раз озвучу свою позицию. Нам отведено не так уж и много времени на этой Земле и лично мне жалко тратить его на кодирование тривиальной логики. Мне хочется еще и удовольствия.

Здравствуйте, Дарней, Вы писали:

Д>какие же они "свои", если они покупаются в ближайшей лавке, только чуть более дорогой?

Ты знаешь, Дарней, фишка все-таки не в этом. Я учился играть на гитаре и стал фанатом Александра Розенбаума за его уникальную манеру в "Нарисуйте мне дом", "Белым полем дым" и т.д. Ну, говна-пирога — песни как песни. Но я хотел получить такой же звук! И я его получил. Но для этого надо было иметь 12 струн. И я их поимел, причем с шестью колками (догадайся, как)! Но при этом оказалось, что советское социалистическое производство не производит нужных струн. Поэтому пришлось наматывать струны самому и изготовить для этого специальный станок (на этом, я кстати заработал некие деньги, почти на целую квартиру). Потом я мотал струны для рокеров-панкеров, а потом это все стало неактуально... Да, мое кустарное производство сломалось под напором "перестройки", когда любые струны любых брендов стало можно купить.

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

Здравствуйте, Дарней, Вы писали:

MS>>На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая.

Д>Одного только понять не могу — откуда в представителях первой категории берется столько снобизма, что они называют любую работу кроме мегаэффективного рисования треугольников "рутиной" и "тоской зеленой"?

Можно процитировать мои слова, демонстрирующие снобизм? Речь была лишь о личных предпочтениях. У меня (лично у меня) — вот такие-то и такие-то предпочтения, и я специально сделал на этом акцент.

Д>Некоторым людям нравится решать примитивные задачи наподобие вывода треугольников, но сверхсложными способами. Тратить на решение каждой задачи массу времени и сил, но зато треугольники будут выводиться аж в два раза быстрее!

Я бы попросил читать то что написано, а не то, что хочется прочесть. Внимательнее, пожалуйста. Вывод треугольников — это действительно примитивная задача, а "вывод вдвое быстрее" — примерно такая же рутина, как и ковыряние в кривом API (собственно, это задача и относится к категории API). Натривиальным является некий способ генерации этих самых треугольников (это лишь для примера). Это очень тонкий момент, часто вызывающий непонимание. В представлении большинства людей "оптимизация" — это ковыряние на уровне машинных кодов и/или написание длинного и неряшливого спагети-кода. Это тоже на редкость тоскливое занятие. Повторю еще раз — интересной (для меня!) является прежде всего работа над алгоритмической частью, когда, например, требуется приблизить O(N log N) к O(N). Вам знакомо понятие О-нотации? Это чем-то напоминает процесс доказательства математических теорем. И язык как таковой здесь не имеет большого значения.

Д>Другим людям нравится решать сложные задачи, но простыми способамами — например, писать свои операционные системы, языки программирования и так далее. Пусть они даже работают не так быстро, как возможно — зато делают такие вещи, которые до них никто раньше не делал.

Интересно, какую такую "операционную систему" или "язык программирования" можно придумать, да еще и так, как "никто раньше не делал", и самое главное — не для самоудовлетворения, а чтобы ими пользовались хотя бы пара тысяч людей? По-моему, это что-то из области заведомой утопии. А я реалист и "наполеонством" не страдаю.

Д>Вероятно, выбор одного из этих вариантов зависит от особенностей менталитета каждого программиста. Одним нравится копать вглубь, другим — строить ввысь.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вообще мои замечания — не о .Net вовсе, а о соответствии ресурсов задачам.

Да ну?

"Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост"."
Не про .net? Явно!?

"Сервер на ASP.NET — это новый русский, отгрохавший себе особняк на 20 комнат и не знающий, что теперь с ними делать" Не про .net? Asp.Net у нас теперь стал дико неэффективным web-сервером? С каких пор???

"можно позволить и 2-3 кратную потерю эффективности в той же .Net " Это тоже не про .net? Какую-какую потерю эффективности? Доказательства голословных обвинений в студию!

И настольные .net приложения у нас теперь не пользуются популярностью, оказывается, из-за проблем с производительностью. Ага.

Никаких предрассудков и искренее желание понять. Ну да. Видное невооруженным взгядом.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Стоп-стоп. Где ее взять — вестимо, на свалке, может быть . И я восе не призываю ее там искать. Мой вопрос не в этом. Вопрос — как соотносятся задачи и ресурсы. Если ресурсов на порядок больше — слава богу. Но что это значит — не будет таких задач в массовом масштабе, которые требовали бы этих ресурсов

Я тебе как то давал ссылку на топик, в котором я описывал ситуацию с увеличением ресурсов. Вкратце — ситуация не так проста, как ты ее пытаешься описать. Даже если отбросить стоимость разработки самыми эффективными решениями для P-200 и P4-4000 скорее всего будут решения разные, потому что ресурсов у компьютера много и растут они с разной скоростью. Кроме того ускорение приложения процедура нелинейная. Практически всегда в море алгоритмов реального приложения есть бутылочное горлышко. Если мы его устраним путем роста того ресурса, в который упираемся, то это самое горлышко образуется в другом месте и совсем не факт что проблемным будет тот же самый ресурс.
Говоря по простому — решения для очень тяжелых нагрузок для больших машин будучи примененными на машинах маленьких скорее всего окажутся не самыми эффективными. С десктопами это не так заметно, но тем не менее тенденция существует.
Теперь о .NET, коль скоро ты о ней помянул. Он действительно вносит оверхед, но далеко не во всех направлениях. Точнее он заметно избыточен по памяти и слегка по процессору. Все. Теперь взгляни на современные задачи на современных десктопах. В какой ресурс они упираются? Вот тот софт что часто использую я и который работает не мгновенно (VS, Янус, TortoiseSVN), вот он весь, без исключения, упирается в жесткий диск. Таким образом полное устранение нетовского оверхеда ничего не изменит. Что еще — игрушки тоже последнее время от процессора зависят несильно, там все в видеокарту упирается. Значит и здесь принципиальных проблем в использовании .NET нет.

Здравствуйте, Pavel Dvorkin, Вы писали:

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

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

Здравствуйте, Alexey Axyonov, Вы писали:

AA>И игры продолжают требовать все более мощного и узко-специализированного железа (например того же физического сопроцессора). Оправдано ли это? Думаю да, хотя есть и исключения (к примеру: Civilization IV, как можно было сделать из походовой игры такого тормоза я не знаю).

Кстати, хороший пример.
Гейм-дизайн -- 5+, программирование -- 1-.
Самое обидное, что дичайшие тормоза убивают играбельность.
Причем, судя по всемуу, графический движок там сделан нормально (надо полагать на С/С++),
а тормозит именно скриптовая часть, сделанная с помощью питона и XML я.
Наглядный пример, до чего доводят современные модные технологии.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, McSeem2, Вы писали:

MS>На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая.

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

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, McSeem2, Вы писали:

MS>>На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая.

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


Был однажды программист, который работал с микропроцессорами.
— Смотри, как хорошо мне здесь! — сказал он программисту мейнфреймов, который зашел к нему. — У меня есть собственная операционная система и устройство для хранения файлов. Я ни с кем не делю свои ресурсы. Программное обеспечение самодостаточно и легко в обращении. Почему бы тебе не уйти с твоей теперешней работы и не присоединиться ко мне здесь?
Тогда программист мейнфреймов начал описывать другу свою систему, говоря:
— Мейнфрейм восседает в вычислительном центре, как древний мудрец погруженный в медитацию. Его дисковые накопители раскинулись из конца в конец, как огромный электронный океан. Программное обеспечение многогранно, как брильянт и переплетено, как первобытные джунгли. Программы, каждая уникальна, движутся сквозь систему, как быстротекущая река. Вот почему я счастлив там, где я есть.
Программист микрокомпьютеров, услышав это, надолго замолчал. Hо два программиста остались друзьями до конца своих дней.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, McSeem2, Вы писали:

MS>>На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая.

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

Для того, чтобы построить ввысь, надо сначала покопать вглубь и заложить хороший фундамент.
Без этого высотка просто рухнет.

Д>Одного только понять не могу — откуда в представителях первой категории берется столько снобизма, что они называют любую работу кроме мегаэффективного рисования треугольников "рутиной" и "тоской зеленой"?

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Другой пример. Зашел я полгода назад в налоговую инспекцию. Бросил взгляд на экран компьютера, и сразу стало ясно, на чем их ПО написано — FoxPro для DOS ни с чем ни спутаешь, внешний вид уж больно характерный. Создано это ПО лет 10 назад, и до сих пор благополучно работает. Не знаю, какте там у них клиентские машины и сервер, но вряд ли что-то фантастическое. Да и зачем — в инспекции работает не более 100 человек, а каждый сотрудник 95% процентов времени работает с клиентами и бумагами, а не с компьютером. Сомневаюсь, что одновременно к этому серверу у них бывает больше 5 обращений когда бы то ни было.

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

Но давай по делу.
В принципе, ZevS уже высказал основную мысль. Могу её лишь дополнить.

Когда мне дали порулить на моём первом писюке, то его стоимость равнялась примерно моим 25-ти! годовым! зарплатам. И что бы на него насобирать деньги мне пришлось бы работать примерно 80 лет. Сейчас, такой же по современным уровням компьютер, практический каждый программист в России может купить на месячную зарплату.На месячную зарплату тех кто получает по-больше можно укомплектовать офисной техникой небольшой отдел.

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

PD>А сложность задач в 50 раз отнюдь не увеличилась. Для той торговой фирты, с которой я начал, она и не могла увеличиться в 50 раз — просто потому, что нет у нее задач такой сложности. И не предвидится.

Зато соотношение стоимость разработки софта к стоимости компьютеров выросла просто неимоверно.

Господа, а не кажется ли вам, что вся эта дискуссия просто-напросто демонстрирует одно простой факт ?

Единого мира программирования попросту не существует. Эта область человеческой деятельности давно уже разбилась на ряд вполне отдельных областей, в которых действуют свои законы, и в разных областях эти законы бывают порой попросту противоположными. И то. что верно для приложений 3D графики — совсем не годится для разработки корпоративных сайтов...
Отсюда и непонимание друг друга. Все равно как если бы архитектор, создающий современные жилые дома, начал дискутировать с архитектором, чья специальность — церкви или соборы. Один про важность состыковки крупнопанельных блоков и промышленное их производство, другой ему в ответ — о том, как правильно купола делать из кирпичей.
Хотя и тот и другой — архитекторы.

Здравствуйте, Дарней, Вы писали:
Д>интересно, а что за трюк?
Да там одна ошибка при обработке прерываний в пентиуме, благодаря которой можно сэкономить пару тактов.

Шутка.

"Не понимаю" это очень правильно сказано. Именно — не понимаешь.

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

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

Подумай над этим.

Здравствуйте, Дарней, Вы писали:

Д>проблема в том, что многие из тех самых "программистов узких мест" имеют обыкновение считать всех окружающих идиотами

Есть еще и обратная проблема: многие из тех, кто в принципе не смог бы заниматься узкими местами, смотрит на специализированных специалистов свысока и снисходительно. Типа, мы-то всегда на волне, а вы в своих микрооптимизациях рельного мира-то и не видите.

Это все экстримизм, на который лучше не обращать внимания.

Хотя, иногда, после рюмки-другой 10-летней выдержки чайку "Белый Аист", хочется проронить скупую мужскую слезу, порвать рубаху со словами: "Да я!... Да сложный объект...! Да за две миллисекунды...! Да в режиме транзакционности!...".

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

Может, тебе такой ответ понравится/будет близок. .Net — это, как и Java, вещь безусловно не эфимерная. Они останутся. Но они были изначально созданы под влиянием понимания того, что не для всех задач нужна оптимизация скорости работы программы, зато оптимизация скорости работы программиста нужна всегда.

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

Если ты так уж увлечен низкоуровневым программированием — просто ищи для себя соответствующие задачи и все. Их немного, но людей, способных их эффективно решать — еще меньше. И тогда — какое тебе вообще дело до .net? Равно как и до js, например. Ну какое тебе дело до его скорости и особенностей функционирования, если ты не пишешь клиентский код для браузеров?

А если ты по каким-либо причинам вынужден иметь дело с прикладным программированием (читай — ширпотребом), тогда твои дела плохи в любом случае. Даже есои ты на .net не перейдешь, то за любовь к оптимизации тебе в этом деле никто спасибо не скажет. Тут действительно нужно менять мировоззрение, но .net тут собственно непричем.

И вообще — если вопрос практический, если он касается выбора специализации на ближайшее время... Ну подумай сам, остановки роста производительности пока нет, остановки роста объема памяти — вообще пока не предвидится, многопроцессорные машины снимут остроту проблемы одновременного запуска тяжелых приложений... Никаких выдающихся тормозов управляемый код не привносит — ну несерьезны эти 10-15 процентов на реальных приложениях. MS свое любимое детище, опять же, будет поддерживать всей своей немеренной массой.

Если вопрос теоретический, так все косточки уже обсосаны — пока железо дешевле, чем наш труд — выбор очевиден. И наоборот.

Хватит тебе уже эту тему мусолить, давайте о чем-нибудь еще поговорим. О пришествии карманных компьютеров, например.

Здравствуйте, Glоbus, Вы писали:

G><skipped>

<skipped>

Утрировано, политизировано, но кое что близко к тому что есть на самом деле.

Я бы сказал по другому:

По всей видимости есть/было намерение создать нечто "быстрорастворимое" —
систему кубиков для сборки in-house приложений которые максимально легко
настраиваемы под конекретный момент жизни предприятия. Получилось ли? Не знаю.

У ИС предприятия несколько другие критерии того что есть хорошо и что есть медленно.
В принципе всякого рода бухгалтериям все равно когда пить чай — во время или после расчета.
Им важно чтобы расчет произошел 30 числа каждого месяца.
На таких задачах всегда "рулил" VB по совершенно очевидным причинам.

Но когда мы пользуем компьютер дома у нас другие критерии.

Простой пример: есть игрушка №1 — быстрая графика но не сильно качественная и
есть игрушка N2 — графика умереть можно, но тормозит.
Играют как правило в первую. Второую же качают, смотрят и откладавыают.

На предприятии же другая система — программу покупеат руководство и тактильные
ощущения тети Маши а также её график чаепитий — до фонаря. Главное что
систему можно быстро менять после каждого заседания Думы.

Предполагется что возможность rapid design это то за что мы платим сборкой мусора.

Вообще я уже много раз говорил: каждая задача требует своего собственного оптимально инструмента.
Задачи бухгалтерии одного. Разработка Office и игр — другого.

На одной из конференций раздавали всякие презенты — оченно
показалось симптоматичным что Visual Studio.NET раздавала брелки в виде комбо ножиков-ножниц-пилки-и-отвертки.
(сделанных в Китае ) с надписью Visual Studio. Это вот оно — нечто под рукой для быстро открутить болтик.
Но для серьезной сборки профи другие "струменты" пользуют, правда?
К слову сказать оригинальное изделие (Swiss-Knife) оказалось удобнее и долговечнее. Но это так... издержки
массового производстсва. К тому же отдаю себе очтет что аналогия может быть спорная.

Здравствуйте, Дарней, Вы писали:

Д>Похоже, никто так и не понял, что я хотел сказать.
Д>Мне тоже не нравятся рутинные задачи. Но выжиманием скорости ради развлечения я давно не занимался и не собираюсь. Потому что это та же самая рутина.

"Выжимание скорости" бывает разым. Вот простейшая иллюстрация — надо удалить все пробелы из Сишной строки.
Реализация раз, индуссого типа:

for(i = 0; i < strlen(str); i++)
{
   if(str[i] == ' ') { strcpy(str + i, str + i + 1); i--; }
}

Знаешь, какова сложность данного цикла? O(N^3). Это значит, что на строке в 10 миллионов символов данный цикл не закончится никогда — врмени жизни Вселенной не хватит.

Реализация два, нормальная, O(N).

for(i = j = 0; str[i]; i++)
{
   if(str[i] != ' ') str[j++] = str[i];
}
str[j] = 0;

(возможно, что я где-то ошибся, но это не важно для иллюстрации).


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

Есть еще кодовая оптимизация, например, для данного случая — использовать адресную арифметику вместо индексной. Она тоже дает выигрыш, но соотношение усилия/эффект у него гораздо ниже. И это действительно рутиная работа (куда ж без нее?). И вот стереотип заключается в том, что большинство людей под оптимизацией подразумевают именно кодовую оптимизацию. Но для первого варианта никакая кодовая оптимизация не поможет. Это только в морг.

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

Здравствуйте, mrozov, Вы писали:

M>Подумай над этим.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

MS>>Надо лишь раз почувствовать себя уникальным.

Д>с этим никаких проблем нет идей море, аж в голове тесно становится.
Д>Другой вопрос, что времени на их реализацию мало.

Это чисто отмазка. Если действительно есть некий зуд, то ты этот "гондурас" просто не можешь не расчесывать. А если типа "идей море", но просто "времени нет", это значит что и идей-то собственно никаких нет. Таково мое мировосприятие.

Здравствуйте, GlebZ, Вы писали:

GZ>ЗЫ Какой негодяй написал что while(*p++==*p1++); нормальный способ копирования строки(хотя знаю кто , но IMHO — это ошибка)? А самое главное сказал что это нормально.

Корни этого растут из арихитектуры PDP-11 с ее автоинкрементной адресацией. Там подобный цикл, точнее сказать "do while(*p++=*p1++);" транслировался ровно в две инструкции:

$1: MOVB (R0)+,(R1)+
    BNE $1

Система команд PDP-11 торжественно похоронена, а операторы инкремента и декремента до сих пор мигритуют — и в Java и в C#. А почему мигрируют? А чисто потому, что прикольная фишка. Людям скучно жить по строгим правилам. Язык программирования компьютеров должен допускать некое хулиганство. Иначе скучно жить на этом свете.

Здравствуйте, Дарней, Вы писали:

E>>А почему Энштейн не был самым богатым человеком в мире (в свое время)?

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

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

Здравствуйте, Дарней, Вы писали:

Д>то есть примерно то же самое, что я предлагал
Д>хотя дьявол, как всегда, в деталях

Чтобы понять, что "дьявол в деталях", надо попытаться имплементировать. А этого в W3C никто не любит. Они же "теоретики"! Едреныть. И судя по неким косвенным признакам, они тоже не понимают сущности О-нотации. Ибо, если бы понимали, не гнали бы такую лажу. С SVG — то же самое. А потом они удивляются, почему это убогий Flash завоевал полмира, а наш великий и могучий SVG до сих пор в глубокой... где-то между ягодицами.

Здравствуйте, Sinclair, Вы писали:

>Ну разве не здорово иметь возможность воткнуть в документ какой-нибудь <hr id="oops">, и всё что после него, станет, к примеру, синим?

Включая физиономию программиста ?

Здравствуйте, mrozov, Вы писали:

M>Вот то-то и оно, что у тебя полностью спутаны эти понятия. Нет ничего "высококлассного" во владении низкоуровневыми технологиями. Это тут непричем.

Мы говорили об умельцах выжимать максимум. Так вот, овладение любой технологией/АПИ никогда не начинается снизу. Оно начинается сверху. Просто некоторым хватает любопытства/способностей понять как оно работает на самом деле. Т.е. высокоуровневый путь никто не минует, поверь. Разница лишь в том, что одни остаются барахтаться на уровне прикладных либ, а другим не составляет труда продвинуться чуть дальше. Я уверен, что тут дело в способностях. Оба они тратят примерно одинаковое время на свою деятельность, просто первые — чуть результативнее.

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

M>Нет никакой связи между знанием ассемблера и "высококлассностью". Можно быть богом в программировании и оптимизации запросов к СУБД и больше ничего о программировании не знать. И наоборот.

Это сказки-небылицы и заблуждения. Если человек талантлив, то он талантлив сразу во многом и достаточно любопытен. Я видел несколько DB админов "как боги", ты будешь смеяться, но часть из них выросла из микропроцессорщиков. Нельзя достичь нирваны, не понимая устройства мира. Специалист должен отчетливо представлять, что именно он делает, что кроется за хинтами блокировок и почему они должны быть разными на разных объемах, и какова истинная цена нормализации/индексов на тех же объемах (это вообще отдельная тема, но для другого форума). Понимаешь, если человек этим всем владеет (а иначе он не бог в этой области), то такой человек абсолютно не напрягаясь ныряет вверх и вниз — ему пофиг, он профи и разбирается в том, с чем работает.

Блин, ну не может талантливый ДБ-админ или девелопер быть обезъянкой в клетке SQL-инструкций. SQL-инструкции — это не цель, а ср-во. Человек решает произвести некие действия с данными, и применяет этот инструмент. Данные — они "живые", особенно на больших объемах. Их надо чуствовать, понимать их характер. Без абсолютно ясного понимания сути происходящего это просто невозможно.


-------------
Если уж говорить о высокоуровневости, то я бы рассуждал скорее не об HTML-верстальщиках и SQL-парнях, а об проектировщиках, архитекторах. Домашнее задание — найти хотя бы одного грамотного проектировщика/архитектора, который бы плохо разбирался в том самом пресловутом нижнем уровне.
В общем, если ты попытаешься действительно предпринять исследования/наблюдения на эту тему, то будешь удивлен реальным положением вещей. И оно, все-таки, не спроста.

Здравствуйте, minorlogic, Вы писали:

M>А вот и не буду , уж очень это очевидно. А если не понял , ну и не стОит ...
Ну чтож, давай поговорим что очевидно из твоего сообщения. Ты прямо намекаешь, что ты один такой крутой в белом, а все остальные сапожники и в .... Ты говоришь что ты один занимаешься творчеством, а все остальные кирпичи складывают в кучи. Ты говоришь что только ты чего-то умеешь, а у всех остальное происходит само собой. Ничего кроме прямого и недвухсмысленного оскорбления тысяч программистов(точнее судя по всему ты хочешь сказать что они недостойны этого звания) на фоне повышенного самомнения, я в этом ничего не вижу.

С уважением, Gleb.

Возникла мысль что некоторые учасники дискусии не вполне разделяют понимание что такое оптимизация.

Попробую привести пример из реальной жизни.
Кратко , есть в сжатии MP3 такой алгоритм , когда надо запихнуть сжатые данные в лимитированный объем(битрейт).

алгоритм
1. Бинарным делением мы находим величину квантизатора дающего ближайший по размеру результат.

2. находим самые искаженные частотные полосы , и для них конкретно уменьшаем величину квантизации.

3. После каждого изменения опять персчитываем сколько же места займет полученная информация.

(не будем заострять внимание что этот подход не эфективен в целом , можно лучше)


Так вот после замеров производительности , стало ясно что самым критичным является непосредственно нелинейная квантизация.

Анализ кода показал , что его разработчики знали об этой проблеме и уже постарались выжать из этого все что можно .

Что делать ? переписать на асемблере ? КОНЕЧНО ! Мне такое предлагали, даже настаивали . Но это ПОСЛЕДНЕЕ что я стал бы делать .

Первое правило оптимизатора какое ?
"Самый быстрый код — это тот который не выполняется"
И я подумал а можно ли сократить количество вызовов квантизатора ? И конечно , сразу понял что в большинстве случаев мы на каждой итерации квантизуем одни и теже данные с тем же самым шагом.

И тут добавление информации что на предыдущам шаге у нас была подобная квантизация и пересчитывать ее не надо дало прирост на порядок (этого шага)!!! И функция квантизации престала быть бутылочным горлышаком.

После этого было пару эвристик чтобы ускорить спуск бинарным поиском и т.д.

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

По жизни уже давным давно повторяю как мантру
"оптимизируйте алгоритмы а не код" нет неправильно , правильно так "ОПТИМИЗИРУЙТЕ АЛГОРИТМЫ А НЕ КОД !!!!!!"

Мне кажется что и Максим , когда говорит про "оптимизацию" совсем не имеет ввиду причесывание кода.


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

Здравствуйте, Дарней, Вы писали:

E>>Нет, главная особенность в том, что они не такие, как все остальные

Д>в таком случае, уважаемый, ты тоже занимаешься рутиной и клепанием гор посредственного кода



Не простой вопрос, на самом деле. Вот возьмем один из моих самых любимых велосипедов -- объектное хранилище ObjESSty. Сама по себе ObjESSty -- это около пятидесяти тысяч строк посредственного C++ кода (как смог, так и написал). Но вот ее использование в некоторых задачах (а именно долговременное хранение сложных С++ объектов) позвляет писать гораздо меньше прикладного кода (по сравнению с теми же SQL БД).

Так что, я занимаюсь рутиной при кодировании ObjESSty, но избавляюсь от рутины при использовании ObjESSty.

Что же до скорости -- на моем ноутбуке ObjESSty показывает время ~0.002 секунды при создании и обновлении объекта (т.к. самые дорогостоящие операции при поддержке транзакций с помощью write ahead log). Оценить, насколько это быстро я не берусь, поскольку с SQL базами данных сравнивать не совсем корректно, а других объектных БД у меня в распоряжении нет.

Д>потому что если твой велосипед не ездит быстрее остальных, то разработчик этого велосипеда — рутинщик и ламо недоученное.

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

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

Вот различие между мастерами и подмастерьями, имхо, лежит на уровне варианта b). Просто потому, что подмастерью еще не хватает ни опыта, ни чутья, чтобы определить точное место "бутылочного горлышка".

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

Та же песня и с СУБД. Ядро СУБД, от которого зависит эффективность работы СУБД, может занимать процентов тридцать от всего объема кода (не считая сопутствующих административных утилит). Но при оценке СУБД качество работы ядра будет привлекать наибольшее количество внимания. (По крайней мере для встраиваемых СУБД, типа ObjESSty, BerkeleyDB или SQLite).

Так вот называть людей, программирующих "узкие места" (будь то генерация фракталов или система кэширования страниц) рутинщиками вряд ли возможно. Хотя бы в силу уникальности решаемых ими задач. Одним из следствий, является то, что со своими специализированными навыками эти узкие специалисты больше нигде не нужны (в отличии от тех, скажем, кто пишет пользовательский интерфейс для программы генерации ландшафтов или административных утилит СУБД).

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

Здравствуйте, mrozov, Вы писали:

M>Более того, рост мощностей компьютеров будущего будет, видимо, связан в основном с многоядерными процессорами. Следовательно — быстрыми будут не оптимизированные вообще алгоритмы, а оптимизированные под многопоточное исполнение. И как следствие, программирование будущего — оно многопоточное. И хотя я не знаю, на каком языке мы будем писать эти программы, но то, что это не будет ни с++ ни asm — практически не сомневаюсь.

Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.

Тогда ответь мне на такой вопрос: для какой-то задачи нужна машина класса P-200 и 128Mb памяти. Где ее взять?

Здравствуйте, mrozov, Вы писали:

M>Павел, можно Вас попросить?
M>Не пишите про .net. Вы умный человек и очень знающий профессионал, но Ваши знания в этой области настолько малы, что на фоне предрассудков просто теряются.

Подумал я и решил еще раз ответить.

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

Если бы я судил о том, как правильно в .Net делать то-то и то-то и говорил при этом чушь — было бы вполне справедливо указать мне на это. Но я никого не учу, как в .Net что-то делать. я говорю о впечатлениях (моих) от того, как все это работает. С точки зрения пользователя, а не программиста. А для этого мне быть профессионалом в области .Net не обязательно.

Что касается моего отношения к .Net, могу сказать следующее. Я хочу понять, что это — новое слово, генеральный путь или же просто очередная мода ?

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

Первый раз это было, когда на фоне безраздельного царства Фортрана, которому, как тогда казалось, нет конца, вдруг заговорили о какой-то Аде. Шуму было, поверь мне, не меньше. Правда, тогда мне решения — осваивать Аду или нет — прнинимать не пришлось , потому что она просто до нас не дошла.
Второй раз — язык С на фоне того же Фортрана. Это было еще на СМ-4. Там Паскаль и С вместе были (на ЕС в ОС ЕС их практически никто не использовал тогда). То же самое — это новое слово или нет ? Стоит изучать ? Стоит переходить ?
Потом была Ява. Тоже, кстати, шума было до потолка — скоро Ява заменит все другие языки, она переносима между компьютерами разной архитектуры и ОС и т.д. Я к этому шуму отнесся вполне равнодушно — не поверил просто, и, как выяснилось, был вполне прав. Ява свое место в мире ИТ заняла, но отнюдь не царствует в нем.
И вот теперь опять. Я и пытаюсь понять, что это такое — очередная мода или же что-то революционное ?

Если мода — черт с ней. Пройдет.
Если революционное — я должен серьезно пересмотреть свои представления.

Одним словом — куда мы идем ?

Вот и все мои предрассудки.

Здравствуйте, bkat, Вы писали:


PD>>Немного не так. Реализовать именно эту возможность не так уж сложно (другое дело, что в дос не было стандартных диалогов). Перехватить в DOS int 21h и все дела. Написать резидент, который отображал бы каталог и оперативно изменял там информацию — не более чем курсовая работа студента тех времен.

B>И это работало бы только в курсовой этого студента.
B>Для каждой новой программы это надо было бы заново специально прикручивать.

Я же ясно написал — резидент. Т.е. нечто , что сидит в ОП и по нажатию горячей клавиши этот самый каталог отображает. А в программы это встраивать бессмысленно — не может изменяться длина файла или список их, когда диалог выбора файла висит. Потому что ДОС — однопрограммная.

Здравствуйте, c-smile, Вы писали:

CS>Сдуреть можно.

Ну его нафик, Андрей. Пойду-ка я лучше на роликах прокачусь вдоль West-side NYC.

Здравствуйте, vdimas, Вы писали:

V>Нет, спрос на высококлассных спецов не удовлетворяется избытком низкоклассных.

Вот то-то и оно, что у тебя полностью спутаны эти понятия. Нет ничего "высококлассного" во владении низкоуровневыми технологиями. Это тут непричем.
Именно об этом я и говорю.

Нет никакой связи между знанием ассемблера и "высококлассностью". Можно быть богом в программировании и оптимизации запросов к СУБД и больше ничего о программировании не знать. И наоборот.

Здравствуйте, McSeem2, Вы писали:

MS>"Выжимание скорости" бывает разым. Вот простейшая иллюстрация — надо удалить все пробелы из Сишной строки.
MS>Реализация раз, индуссого типа:
MS>

MS>for(i = 0; i < strlen(str); i++)
MS>{
MS>   if(str[i] == ' ') { strcpy(str + i, str + i + 1); i--; }
MS>}
MS>

MS>Знаешь, какова сложность данного цикла? O(N^3).

Не хочу занудстовать, но сложность "индусского" алгоритма — O(N^2). Похоже уважаемые участники обсуждения ошиблись по невнимательности.

Здравствуйте, Дарней, Вы писали:

Д>я и так работаю над одной самой многообещающей идеей. Другой вопрос, что работы там море, и моих сил может просто не хватить. А привлекать кого-то еще я пока не хочу, потому что пока нет устоявшейся основы — проект станет напоминать известную басню про рака, лебедя и щуку.

Тогда тебе могут быть интересны: Re: Совет "опытного камикадзе" если хошь

Автор: c-smile
Дата: 26.10.05

, Re[2]: Советы 5), 6) и 7)

Автор: c-smile
Дата: 26.10.05

и Re: Велосипеды и эффективность решений

Автор: eao197
Дата: 26.10.05

.

E>Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.

Это какой-то замкнутый круг, ей-богу.
— Почему на с++, а не на .net, под которым надежнее?
— Потому что .net медленный.

— Да не медленный он вовсе, хватает с огромным избытком. На VBS и то куча кода написано — и ничего.
— Не будет хватать со временем, если роста скорости процессоров не будет.

— Так ведь они многопроцессорными будут.
— Ну а я на с++ тоже многопоточно писать могу.

— Я тоже могу, но ведь на .net это делать заметно проще. А там и специальные языки, заточенные под это дело подоспеют.
— Да, но .net медленный.

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

Боюсь, что для большинства задач все-таки нужна многопоточность. И потом — в .net есть замечательная возможность запускать несколько доменов в одном процессе =)

Но по большому счету — речь просто о том, что хотя .net требует под себя доп. мощности, но эти мощности уже есть. А какого-то особого замедления работы managed программ на современном компьютере лично я не замечаю.

NC>Более того, смею утверждать, что больщинство пользовательских пк имеют то же распределение загрузки:
NC>1 активное(рабочее приложение, это может быть редактор игра и т.п.) + Музыка(возможно) + 2-5 приложений в фоне. И где же ваша драка за ресурсы??? Видел проблемы только на старых компах(пень 100 192 Mb Ram)

Памяти не хватает дико:

На фоне (трей): Miranda, Shareaza, SharpReader, Winamp, RSDN@Home, PuntoSwitcher, Avast Antivirus, MSN Messenger, SystemScheduler, Apache, AC sound Manager, Process Explorer.

Открытые окна: 2-3 Windows Explorer, Opera (штук десять табов), Mozilla Firefox (штук пять табов).
Часто открываемые: Adobe Photoshop, Macromedia Dreamweaver.

512 MB на все это добро не хватает никак. Только винда жрет 100. Opera+FireFox+Janus — еще сто (Опера у меня нередко сам доходит до 80 МБ). MSN Messenger — 30 метров (за что? зачем?) В общем, сейчас у меня запито 528 метров (из 512). А если еще Фотошоп с Дримуивером запустить....

Вчера под вечер сидел на 800 МБ (из 512 )

Но! Есть конечно но. Если работать только с одним/двумя приложениями, то рекция этих приложений более, чем адекватная.

Здравствуйте, vlad_gri, Вы писали:

_>Здравствуйте, eao197, Вы писали:


E>>Так вот, если в моем распоряжении есть P4-2GHz, то у меня есть выбор -- сделать задачу за месяц на Smalltalk/Ruby или за два месяца на C++. При этом реализация на Smalltalk/Ruby будет грузить процессор на 80% (при пиковой нагрузке), а C++ -- на 20%.

E>>В пользу чего делать выбор?
_>Если поставленна задача сделать за месяц то Smalltalk/Ruby.
_>А через месяц еще задача, которая будет крутится паралельно и.т.д.
_>И начнется ...

Никаких "начнётся". Нельзя выбирать заведомо трудоёмкое решение из-за каких-то "начнётся". Вопросы надо РЕШАТЬ, а не перманентно обдумывать. Завтра вы нафантазируете ещё больше и будете писать КОНКРЕТНУЮ рассматриваемую задачу на кодах процессора?

В конце концов, программный комплекс — это совокупность программы и железа. И если заказчик ПОТОМ решит установить на это же железо ещё чего-нибудь, то это уже будет его проблема.

Здравствуйте, Шахтер, Вы писали:

Ш>Для того, чтобы построить ввысь, надо сначала покопать вглубь и заложить хороший фундамент.
Ш>Без этого высотка просто рухнет.

построить дом без фундамента можно. Построить фундамент без дома тоже можно, только это абсолютно бессмысленно.

Ш>А я вот наоборот не понимаю, когда подмастерья начинают наезжать на мастеров -- типа и кисти с красками у него свои, а не дешёвый ширпотреб из ближайшей китайской лавки, и пишет он расчитываяя каждый мазок, то ли дело мы -- наляпаем абы как, всё равно заказчит в живописи ничего не смыслит, "пипл хавает".

Как быстро ты записал меня в подмастерья, а себя — в мастера. У тебя есть точные данные, что дело обстоит именно так?

Если уж ты заговорил про художников, давай расставим все точки над "Ё"
Ну так вот — у художников все стандартизовано куда покруче, чем у программистов.
Стандартны материалы, стандартны инструменты, и даже техники нанесения рисунка — тоже стандартны. Так что мастера просто используют набор готовых стандартов. Изобретают что-то новое только гении, которых можно пересчитать на пальцах за всю историю человечества. Вероятно, именно к этому разряду ты себя и относишь?

Здравствуйте, Дарней, Вы писали:

E>>Совсем не обязательно. Я лично смотрю на это так: некоторым людям жуть как не хочется заниматься рутиной. И они (т.е. мы ) находят для себя занятия по интересам. McSeem2, скажем, делает это увеличением скорости работы графики. Я -- в изобретении велосипедов для разработчиков. Кто-то еще чем-то страдает. Факт, однако, в том, что не так уж много народу хочет заниматься подобными вещами. Либо хочет, но не настолько, чтобы этим решиться на это.

Д>Вероятно, главная особенность твоих "велосипедов" — это то, что они ездят быстрее аналогов?

Нет, главная особенность в том, что они не такие, как все остальные

Здравствуйте, minorlogic, Вы писали:

M>Я допускаю такую гипотетическую возможность , но к сожалению ни разу не встречал такого в жизни.
Я встречал таких уродов. И много встречал. Один раз пострадал конкретно. Делали программу, нужна была библиотека для COM портов(это было еще во времена DOS). Каждый делал свой модуль. И вроде бы парнишка головастый, и вроде бы не новичок. Вобщем все сделали, а COM связи нет. Клиент волнуется. Две недели его тыркали. Пригнал все таки модуль. Крутой модуль. Куча кода. На WASM. Асинхронный и еще зачем-то с приделанным кэшом. Только ни фига не работал. Ошибка сплошная на ошибке. Вобщем клиента не убедили подождать, послал он нас подальше. И что обидно, потеряли не деньги, потеряли ценного клиента. Я потом тот же модуль из принципа написал попроще, на том же WASM. День на это ушло. Асинхронный но без всяких излишеств. И функции только те которые нужны. И кода раз в 20 меньше. Если все это сделать на С и без всякой асинхронности, то и за час можно было управиться. Поэтому таких уродов без поводка нельзя держать. Крутизна никому не нужна если она не помогает создавать что-то нужное.
А из таких уродов можно сделать человека. Их просто нужно обламывать смолоду. И держать на поводке. Потому что с крутизны ничего хорошего не получается и не создается. Самое хорошее решение — простое решение. И если человек умеет находить эти простые решения — то он более ценен чем тот кто знает низкоуровненые языки.
Честно говоря сам был когда-то таким. Но у меня несколько другие обстоятельства были, и никто коммерчески от меня не зависил. К сожалению рядом не было старших товарищей, и учился на своих ошибках. И стремлению к простоте, путем ушибов я вроде научился.

С уважением, Gleb.

Здравствуйте, minorlogic, Вы писали:

M>В общем я не про себя говорил. Но ЛИЧНО я страемлюсь заниматься интерессными для МЕНЯ задачами. Я не горжусь занимаясь рутиной , для меня это не ценность.
А тебе не кажется что можно получать несказано много удовольствия от того что ты построил полезную программу, и то что она приносит пользу людям? Тебе не кажется что без творчества ни одной полезной программы построить просто нельзя?

M>Ну это уже твои комплексы , я например вижу завитсь к людям которые не хотят заниматься рутиной , а стремятся заниматься тыорчеством. Зависть эта черная и не полезная.
Чего, чего? Меня обвиняют в зависти? Послушайте, у меня высокое самомнение о самом себе. Может быть я фору дам многим по этому показателю. Но самомнение основано на оценках самого себя, и не в коем случае на оценках других.
M>Поверь мне , люди занимающиеся творческими задачами , многим жертвуют.
О, великий гуру! Спасибо что ты посетил этот сайт и послал творческое сообщение заблудшей овце. Мы благодарны тебе за то что ты не погнушался оставить свои творческие отпечатки на творческой клавиатуре. Спасибо вам за то что жертвуете себя ради нас.

Вобщем, отвечать больше не буду, вы перешли на личности, советую прочитать правила форума.

Без подписи.

Здравствуйте, eao197, Вы писали:

E>Нет, главная особенность в том, что они не такие, как все остальные

в таком случае, уважаемый, ты тоже занимаешься рутиной и клепанием гор посредственного кода

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

необходимое железо + стоимость разработки + стоимость поддержки = затраты. Минимум затрат большая прибыль.

Здравствуйте, eao197, Вы писали:

E>Может измениться. Вот у меня был случай -- в одном месте, которое вызывалось слишком часто, было два обращения к new. В многопоточном приложении, где каждый new -- это очень дорого. Я переписал это место так, что new вызывался только один раз. В результате большой кусок кода заработал в два раза быстрее и перестал быть узким местом. Еще больших результатов можно было бы достичь, конечно, изменением алгоритма (там даже не алгоритм а целая идеология бы поменялась), но затраты на такие изменения алгоритма были бы не соизмеримы с полученным выигрышем, а сложность решения серьезно бы увеличилась.

Угу. Я именно подобное и имел в виду. У меня, к примеру, new где-то в глубине циклов априорно антипатию вызывает — знаю, чего это стоит, Это не значит. что я от него обязательно откажусь, но стоп-сигнал сразу срабатывает — дескать, что это я такое здесь делаю ? Может, и оставлю в конце концов, но бездумно не пропущу.

Здравствуйте, Дарней, Вы писали:

Д>абсолютно не понимаю, что ты хотел продемонстрировать этими прописными истинами

Давай мы с тобой не будем спорить? Ибо "Если ты споришь с идиотом, вероятно, то же самое делает и он". Это ни в коем случае не оскорбление, наоборот — это некий само-сарказм. Чем больше мы с тобой разговариваем, тем большим идиотом я себя чувствую.

Здравствуйте, McSeem2, Вы писали:

MS>Кто познал сущность О-нотации, тот истинно крут! Какая такая "особенность strcpy" может убавить O?
Честно говоря такие шняги лучше мерять от и до. Это будет примерно O(N^2)<=x<=O(N^3). В зависимости от кол-ва пробелов.
Хотя O(N^2) по сравнению с O(N) — при большом N уже показания к сипуке.

Сейчас наставят минусов, но все-таки признаюсь.
Если бы это было в месте в котором я был бы уверен в том, что количество строк 2-3 и запускается только при загрузке, то может быть я бы пропустил такой код. Гадость но не смертельная. Даже под гнетом того, что код может перекочевать. Если бы в чем-то повторяющемся, или в месте где влияет на нагрузку работы — сипука.

С уважением, Gleb.
ЗЫ Ставьте минусы предателю.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Дарней, Вы писали:

Д>>то есть примерно то же самое, что я предлагал
Д>>хотя дьявол, как всегда, в деталях

MS>Чтобы понять, что "дьявол в деталях", надо попытаться имплементировать. А этого в W3C никто не любит. Они же "теоретики"! Едреныть. И судя по неким косвенным признакам, они тоже не понимают сущности О-нотации. Ибо, если бы понимали, не гнали бы такую лажу. С SVG — то же самое. А потом они удивляются, почему это убогий Flash завоевал полмира, а наш великий и могучий SVG до сих пор в глубокой... где-то между ягодицами.

Угу. я второй месяц пытаюсь найти автора придумавшего вот это:

8.3.2 Indirect adjacent combinator
Indirect adjacent combinators are made of the "tilde" (~) character that separates two sequences of simple selectors. The elements represented by the two sequences share the same parent in the document tree and the element represented by the first sequence precedes (not necessarily immediately) the element represented by the second one.

Example:
h1 ~ prerepresents a pre element following an h1. It is a correct and valid, but partial, description of:
<h1>Definition of the function a</h1>
<p>Function a(x) has to be applied to all figures in the table.</p>
<pre>function a(x) = 12x/13.5</pre

Т.е. имея такой селектор и для того чтобы сказать "нет — не подходит" надо сканировать дерево не только вглубь но еще и вширь.
Сдуреть можно.

Здравствуйте, Дарней, Вы писали:

V>>Мы говорили об умельцах выжимать максимум. Так вот, овладение любой технологией/АПИ никогда не начинается снизу. Оно начинается сверху.

Д>любая технология/АПИ — это всего лишь инструмент, средство для воплощения идей программиста в работающий код. Фактически, АПИ — это самое "дно" тех понятий, которыми оперирует любой программист. Над которым у любого хорошего программиста должно быть еще много-много уровней абстракции, с которыми он умеет работать.
Д>Так что если человек умеет работать только с C#, например — это совсем не значит, что он "высокоуровневый специалист". На самом деле, это всего лишь неквалифицированный кодер.

Я немного не уловил это согласие или возражение. Если человек умеет работать только с C#, и плохо понимает, что за этим кроется, то, согласно моему видению, он действительно — неквалифицированный кодер.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, c-smile, Вы писали:

IS>>>Здравствуйте, c-smile, Вы писали:
CS>>>>а не написать ли нам это на Compact Framework...
IS>>>судя по коментариям, подобное поведение и требовалось получить.

CS>>Не понял до конца замечания ну да ладно...
CS>>Мы разговаривали с MS. (Они знают наше приложение)
CS>>Это была их рекомендация. Мы просто её проверили.
IS>а вы от них ждали что они вам порекомендуют решение
IS>"от конкурентов". Нет (1).

Сравнивали мы с MS VC++ + SQLite.
Если это конкуренты то тогда да.

CS>>А комментарии... как тебе сказать... мы же профи
CS>>в конце концов. Да, мы это знали заранее.
CS>>Поэтому-то инициатива исходила не от нас.
IS>Именно про это я и писал. Когда изначально (2) ставиться
IS>задача показать что на солнце лететь ночью
IS>нельзя, это обычно легко доказывается.

Напрасно ты сомневаешься в нашей объективности.
Не было желания быть необъективным.

Наши комментарии отражают степень нашего собственного
обалдения от результатов.

Принимая во внимание что SQLite на той же структуре базы
работает на порядки быстрее и тот факт
что на мобильной платформе программирование UI что на C++ что на
.NET одинакового порядка сложности товарищи ясное дело выбрали Пепси.

IS>(1) + (2) приводят к предубеждению в самом начале тестирования.
IS>Начиная с предубеждения, получить непредвзятый результат невозможно.

Я не понял а при чем здесь предвзятось или нет.
.NET что девочка какая, а мы пацаны в поре созревания?

Изначальное и естественное желание минимизировать собственную
головную боль. Если CF дает бенефиты и позволяет хоть как-то
сократить стоимость разработки то за милую душу, почему нет?

Но воевать с таким SQL server'ом на батарейках... это дороже встанет.

Если уже и заходить на managed code то уж явно лучше использовать SuperWaba.
Она (VM/runtime) работает на Win, Palm и Symbian.

Назови хотя бы одну причину ради которой им нужен CF.
Только без этой эзотерики про потусторонние мотивы.

Здравствуйте, vdimas, Вы писали:

GZ>>Так уж это важно? Ну не клеются регуляры в классический конечный автомат с третьим подклассом грамматики Хомского. Значит это не подходит под термин теории. Зато то что на практике регуляры умеют больше. И в практике существует точно такой-же термин "регулярное выражение", который может обрабатывать скобки. Это ведь не важно. Важно что он интересуется, расширяет свой кругозор, а это более важно.

V>Ты не так понял. Меня ничуть не смутило, и не удивило, что он как-то по другому считал ДО этого. Меня проразил факт упорства и само трудное восприятие тех вещей, которые он должен был воспринимать как повторение пройденного (я прекрасно знаю кафедру, с которой описываемый чел вышел). Я упомянул про лоботомию именно в этом смысле — невозможность переосмыслить собственные знания.
Для этого человека было важно подтвердить свои знания(которых возможно не было). В условиях стресса. Я вполне допускаю что он пытался действовать догадками, и доказывать их. У меня на экзаменах такое прокатывало не раз.
V>На собеседовании молодых преттендентов практически бесполезно проверять накопленный багаж, интересней посмотреть на способность рассуждать, обобщать, отделять значимое от второстепенного (пусть даже он где-то будет совсем не прав,интересна сама способность к рассуждениям и принятиям решений).
+1

V>Для меня лично тот факт, что вчерашний студент изучил эти перловые регулярные выражения — ни плюс и не минус, а абсолютно ничего... Не показатель в общем, ибо это знания прикладного характера. И у него еще нет их некоей критической массы, чтобы можно было хоть как-то пытаться их проверять.
Многие не обладают и этим. Как плюс можно считать то, что он изучил. И если умеет учиться, то если родина позовет, то выучит и то что нужно.

V>Почему именно так? Вот пример на те же регулярные выражения (надуманный... только что)
V>Пусть у нас есть задача создать некий динамический лексер. Т.е. в некоем виде в "одно место" поступают правила для текущего разбора (пусть в удобно закодированной форме), а в "другое место" — входные цепочки для того самого разбора. Предположим, я предложу решить подобную задачу преттенденту и попрошу обосновать решение. Независимо от того, как он решит задачу, без обоснования решения и сравнения различных путей решения, его собственное будет стоить 0 целых 0 десятых.
V>В данном случае очевидны 2 решения (на основе имеющихся технологий):
V>- динамически строить "перловые" регулярные выражения
V>- динамически строить конечный автомат самому (или с помощью некоей известной либы)
Для этого нужно знать эту известную либу. Я например, в последнее время не пользовался ни одной либой которые бы строили конечный автомат. Максимум — COCO/R в котором автомат с магазинной памятью. А он конечным автоматом не является с одной стороны, но может функционально может его заменить.

V>В зависимости от различных входных условий может оказаться следующее:
V>- построить автомат самому сложнее/не сложнее/легче, чем построить регулярные выражения
V>- требования к эффективности высокие/не высокие/отсутствуют
V>- набор входных правил меняется "очень часто"/"не часто"/"редко".
V>И какой смысл будет рассматривать его конкретное решение,если человек недостаточно хорошо представляет, сколько он за свое (неважно какое) решение платит и где именно.
А ты абсолютно уверен что можешь быть экспертом? Я не знаю ни одной такой области где я знаю все.

V>Я и сам закончил не многим более 10 лет назад и еще прекрасно помню уровень многих своих друзей-одногрупнников на момент выпуска. Пытаюсь найти сейчас примерно такого же уровня — пусто... Блин, краткий обзор современного "продвинутого" выпускника: немного джавы, HTML, немного С++, какие-то обрывочные знания MFC/ATL/COM/Дельфи и... глубочайшие провалы в основах (на фиг тогда сдались те обрывки знаний?). Такое ощущение, что безграничная доступность машинного времени (копм у всех) банально отвлекает студентов от учебы. Написание программ мартышкиным способом (методом тупого тыка и перебора подходящих вариантов) — не лучшее времяпрепровождение. ИМХО, наоборот — весьма отупляющее занятие.
Нет. Я думаю причина в другом. В процессе учебы(по крайней мере так было у меня) выводится такая формула: нужно изучать только то что пригодится дальше, а то что не пригодится лучше просто сдавать. Сделать адекватное разделение в условиях недостатка опыта очень сложно. Я до сих пор жалею что положил на Лисп с Прологом.

V>-----------------
V>Если тебе интересно для сравнения. Любое зачитывание "в лоб" закодированных правил лексического разбора — это суть построение NFA. Собственно, сама задача построения лексера — это привести NFA к DFA (причем для реального использования даже не обязательно потом минимизировать, ибо это никак не отражается на эффективности).
Не обязательно. Решать можно и в NFA. А иногда и только в NFA. Об этом ниже.
V>Скажу только, что сразу после института я бы закодировал подобную задачку весьма быстро, а так потратил примерно пол-часа. Вот код процедуры перевода:
[Скипнуто]

V>Есть еще алгоритмы построения сразу DFA из входного описания, тогда общий код будет еще короче и не нужен промежуточный NFA. Правда, эти алгоритмы не подходят для построения лексера из описания языком расширенных регулярных выражений (не перловых).
V>Не думаю, что построитель перловых регулярных выражений был бы проще, скорее — ровно наоборот. (Опять же, от преттендентов не требуется готовый код, требуется умение рассуждать, сравнивать, пытаться обнаруживать значимое)
Да нет я думаю проще. Я не эксперт в этой области формальных языков, но полчаса поиска в интернете, что такое DFA и NFA(этих буржуйских абривеатур не знал) дал мне не только информацию о том что это детерменированный и недетерменированный конечные автоматы, но и то о чем я догадывался и раньше. За детерменировость автомата приходится платить увеличением количества состояний. Но верхняя цифра меня немножко убила — 2^n. Поэтому для построения детерменированного автомата нужно пристальней смотреть на сами входные лексемы. Универсальным такое назвать сложно. Кроме того был сразу же найден хороший алгоритм построения DFA из NFA с минимизацией в процессе трансформации(ссылку не дам, уже потерял, но источник называется A.A. Пестов, A.A. Шалыто "Преобразование недетерминированного конечного автомата в детерминированный", Санкт-Петербургский государственный университет информационныхтехнологий, механики и оптики. Найдено по гуглу.) Это может мало для принятия решений, нужно конечно больше информации, но думаю что за сутки можно выбрать уже готовый алгоритм и реализовать его. Конечно, у меня есть некоторая подготовка по грамматикам, но для разговора по данной области сходу я бы поостерегся. И вообще, лучше бы на основе имеющихся знаний выбрал готовый продукт. Проблема не в том, что я не смогу, проблема в том что этот код надо поддерживать. Протестировать грамматику, даже автоматную, весьма сложно.
Но результат такой, вряд ли ты бы меня взял к себе на работу если бы я не знал о чем будет разговор и не подготовился. К тому же перла я не знаю Так что, либо я бездельник и никому не нужный туниядец, либо у тебя слишком субъективное мнение.

С уважением, Gleb.

Здравствуйте, Cyberax, Вы писали:

C>Уже нет Начиная с первого GeForce на чипах появился GPU — это такой
C>быстрый векторный CPU, заточеный специально под графику. Он умеет
C>перемножать матрицы, рассчитывать тени и т.п.

Это все поятно. Но ни одна железяка не умеет триангулировать полигоны. Это я к тому, что нагрузка на CPU нисколько не ослабевает. Точнее, тут действует походный принцип — как только у тебя освобождается место в рюкзаке, оно сразу стремится быть заполненным чем-то более тяжелым.

Здравствуйте, mrozov, Вы писали:

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

Разница во взаимозаменяемости. Первые легко могут заменить вторых. Наоборот — никак. Первых — днем с огнем сейчас ищи, вторых — как саранчи, и т.д.

Здравствуйте, mrozov, Вы писали:

M>Возможно. Хотя возможно также, что вы просто не умеете их готовить.
M>С одной стороны — GUI повышенной сложности я не делал.
M>С другой — делал достаточно нестандартные и не заметил торможений вообще.
M>Т.е. вы можете быть правы. Но моя практика показывает обратное.

Наверное.

По поводу VB6 и VB.NET вот ссылка из MSDN

VB.NET, although slower than VB6 where Windows Forms are concerned, can do a few things much faster than VB6

здесь

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>1. Если предельная эффективнсть не требуется — значит, железо сейчас избыточно. Если бы железо было намного слабее — писали бы то же, но эффективно, выжимали бы из железа все, чтот можно. Дороже. Хуже. Но делали бы.

Есть такое мнение, что большая часть десктопного железа сейчас продается из-за игр. Там же сплошная алгоритмика и перемалывание огромных объемов данных.
Каждый год в этой отрасли появляются монстры которые способно загрузить на все 100% не только существующее железо, но и пару следующих поколений. Вспомним хотя бы Doom3 и рост продаж GeForce 6 (причем не самых дешевых из семейства) связанный с его выходом. Либо нынешний Quake4 способной на всю загрузить Geforce 7800 GT и двухъядерный Athlon 64 4800+ (заметь, оба компонета топовые):

Заблуждениям – нет! Тесты 28-и процессоров в самых современных играх



И игры продолжают требовать все более мощного и узко-специализированного железа (например того же физического сопроцессора). Оправдано ли это? Думаю да, хотя есть и исключения (к примеру: Civilization IV, как можно было сделать из походовой игры такого тормоза я не знаю). Сравни игровую атмосферу в том же F.E.A.R c чем-нибудь что ты способен запустить на P200 и все станет ясно. Жаль только, что в последнее время атмосфера эта создается эффектами а не геймплеем.

Игровая индустрия приносит большие деньги как производителям и издателям игр, так и производителям железа (по крайней мере AMD, Intel, nVidia, ATI и Creative уж точно). И именно индустрия развлечений привела к тому железу, что сейчас мы имеем на своих столах.

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

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, vdimas, Вы писали:

V>>С этим как раз никто не спорит. Я считаю, что не может быть человек специалистом и при этом не разбираться досконально в сути того, чем оперирует. Т.е. мне явно кажется надуманной точка зрения, что бывают "высокоуровневые" спецы, которые слабо разбираются в подробностях современной выч. техники, осей и т.д.

Д>Смотря до каких подробностей
Д>В любом случае, это необходимо, но отнюдь не достаточно.

Ну... флейм так флейм, ok. Назови, плиз, "достаточный" аспект для определения "грамотности" специалиста. Мне кажется, что аспектов слишком много, и большинство из них необходимы, но, разумеется, каждый в отдельности не достаточен.

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

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

Т.е., картинка современного проектирования получается немного смешной:
— оцениваем общие технические характеристики, и требования, выбираем общий вид архитектуры (N-tier и т.д.)
— выделяем наиболее общие сценарии работы с сущностями на этапе предварительного анализа, разбиваем их на классы (справочные данные, оперативные данные, регистры и т.д., по возможности, выделяем как можно больше общих моментов — он это уже детали имплементации)
— строим некую среду поддержки прикладных сущностей, которые , как предполагается, будут принадлежать некоторому классу, т.е. поддерживаться неким набором функциональности (которая, например, может представлять из себя комбинацию политик на различные аспекты). Такие вещи, как DAL, презентационный уровень, обмен м/у уровнями — как раз являются основой этой среды поддержки, и, по-сути, являются лишь техническими подробностями ее реализации. Тут уместно замечание, что до сих пор (!!!) многие путают DAL, например, и другие подробности с целевой прикладной функциональностью, т.е. разрабатывают эти моменты одновременно (одновременно с самой прикладной сущностью разрабатываются элементарные операции по ее персистентности), что мне представляется нелогичным (пусть по другому иногда никак, это не показатель). Подходы многих либ ORM (а у нас своя разработка этого плана ), в сочетании со встроенными ср-вами обеспечения транзакционности, параллельности доступа к персистентным хранилищам и т.д. позволяют как-то абстрагироваться от этих технических деталей.

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

Одним словом получается, что на разработку технических подробностей архитектуры обычно тратится куда как больше времени, сил и таланта конкретного архитектора, чем на модель прикладных целевых сущностей, которые вообще зачастую отдаются разработчикам более низкого ранга в иерархии (смешно, но факт). И вся эта т.н. "высокоуровневая архитектура" — суть выбранный способ оперирования низкоуровневыми вещами (а не реализация прикладной модели). Т.е. она, хочешь или не хочешь, но весьма плотно завязана на такие низкоуровневые вещи, как:
— возможности современных "доступных" компьютеров (может быть принято решение о кластеризации)
— характера поведения сети, ее технические характеристики, особенности сетевых протоколов
— возможности различных программных платформ, начиная от ОС, далее серверов WEB и БД, и заканчивая высокоуровневыми либами-средами, как для С++, так и еще более высокоуровневыми, типа Java или .Net (причем архитектор обычно очень хорошо разбирается именно в подробностях, и зачастую лучше кодера... ему же решения принимать надо! т.е. надо владеть максимумом информации)

--------
А теперь можно опять вернуться, ну например, к этому посту, и снова по кругу
http://www.rsdn.ru/Forum/Message.aspx?mid=1501665&amp;only=1

Автор: vdimas
Дата: 23.11.05

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Другой пример. Зашел я полгода назад в налоговую инспекцию. Бросил взгляд на экран компьютера, и сразу стало ясно, на чем их ПО написано — FoxPro для DOS ни с чем ни спутаешь, внешний вид уж больно характерный. Создано это ПО лет 10 назад, и до сих пор благополучно работает. Не знаю, какте там у них клиентские машины и сервер, но вряд ли что-то фантастическое. Да и зачем — в инспекции работает не более 100 человек, а каждый сотрудник 95% процентов времени работает с клиентами и бумагами, а не с компьютером. Сомневаюсь, что одновременно к этому серверу у них бывает больше 5 обращений когда бы то ни было.

Я работал в налоговой 8 лет. Не пользователем...

Несколько десятков клиентов. Сеть 10 мбит.

Fox тянет ВСЁ по сетке...

3 одновременных обращения и тормОзим... сильно тормОзим... очень сильно...

Здравствуйте, minorlogic, Вы писали:

E>>т.е., наличие настолько эффективного кода, который уже бесполезно вылизывать.

M>Нет не безполезно , там было куда вылизывать , но было видно : "разработчики знали, что это узкое место".

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

PD>Кстати, эта точка зрения хорошо объясняет тот факт, что ASP.NET пользуется приличной популярностью, а настольных .NET приложений очень мало. Сайт на ASP.NET работает обычно на отдельной машине, кроме него самого и средств управления там больше ничего и нет, вольготно и раздольно. Настольные же приложения работают там, где кроме них есть еще 10-20 конкурентов, поэтому то замедление, которое они бы привнесли, многим не понравится.


То, что на сервере может крутиться несколько сайтов(частое явление), или же это вообще может быть выделенный виртуальный сервер, каких несколько на одном физическом, Вы конечно не учли почемуто.

На настольной машине одновременно работают 3,5,7 — 10 максимум пользовтаельских приложений. А "активно"(т.е. жрут память и проц) 1-2. Не верим — давайте считать(приведу свой пример, буду рад если то же напишут другие о себе):
Вариант 1: Я работаю
Вижуал Студия 1-2 штуки, в каждый момент времени юзается одна из них. "Активно" юзается только при компиляции — это не так уж часто.
10-15 окон ие — считаю это как одно приложение ибо в Опере, к примеру, это и былоб одно приложение Пассивно едят немного памяти, не жрут более ничего.
ВинАмп — вот второе приложение, которое грузит проц, правда незаметно.
Ворд и(или) Ексель — тоже просто висят.
Пара TotalCommnderoв.
Ах да, забыл файерволл + антивирус возможно.
---
Итог:минимум 8, максимум 10 приложений. Из которых "активны" 2-4

Вариант 2: я гамаю
Игра + Винамп(фон файерволл+ антивирус)
4 приложения, 2х последних может не быть. Винампа кстати тоже.

Вариант 2,5: смотрю фильм
3 активных приложения.

Более того, смею утверждать, что больщинство пользовательских пк имеют то же распределение загрузки:
1 активное(рабочее приложение, это может быть редактор игра и т.п.) + Музыка(возможно) + 2-5 приложений в фоне. И где же ваша драка за ресурсы??? Видел проблемы только на старых компах(пень 100 192 Mb Ram)
при запуске нескольких вордов + студии + ие + Касперский(!)

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

Здравствуйте, Pavel Dvorkin, Вы писали:

_>>Есть задача загрузки контейнера (напихать в фуру побольше разных коробок).
PD>Так нужно им это или нет ? Или они просто не знают, что это возможно ?

То, что нужно — это 100% — мне подобные запросы на заказы поступали не раз, другое дело, что я отказывался. Знают ли? Да, знают.

Нынешние руководители уже поняли, что компьютеры могут делать достаточно много работы вместо человека, они видят, упоминавшихся ранее в этом форуме бухгалтеров, которые пьют чай, в то время как 1С считает зарплату, выставляет счета и т.д. И, как мне кажется, именно сейчас наступает тот период, когда у руководителей начинает сносить крышу от такого счастья — они не спят ночами, они думают как заработать еще больше (вполне нормальное состояние, правда?!)... И вот, с заговорческим видом, они подходят к сисадмину / программеру / сыну секретарши, который обслуживает контору и спрашивают:

— А ли можно сделать так, чтобы (...)?

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

З.Ы. простите, что так много — наболело

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, c-smile, Вы писали:

CS>>[поскипано]

CS>>"без особого углубления в проблему" и тем более без знания CSS
CS>>последний(ие) запрограммировать невозможно вообще.

Д>давайте лучше отставим в сторону менторский тон и поищем в идеях фатальные недостатки, несовместимые с жизнью. Если таковые там есть.

Давай. Только сначала придется разобраться что есть cascading, selector specificity.

повторю себя же:

Если хочешь серьезно вникнуть в проблему
то вот мой ответ David Hyatt (Apple, Safari)
http://lists.w3.org/Archives/Public/www-style/2005Nov/0086.html
Там в тексте есть ссылка на его блог и описаны хрустальные зАмки оптимизации в Safari.

Если пойти по ссылке то можно прочитать следующее:

WebCore (in upcoming Safari releases) has a really cool optimization that I came up with to avoid even having to compute the set of declarations that apply to an element. This optimization in practice results in not even having to match style for about 60% of the elements on your page.

The idea behind the optimization is to recognize when two elements in a page are going to have the same style through DOM (and other state) inspection and to simply share the front end style information between those two elements whenever possible.

There are a number of conditions that must be met in order for this sharing to be possible:
(1) The elements must be in the same mouse state (e.g., one can't be in :hover while the other isn't)
(2) Neither element should have an id
(3) The tag names should match
(4) The class attributes should match
(5) The set of mapped attributes must be identical
(6) The link states must match
(7) The focus states must match
(8) Neither element should be affected by attribute selectors, where affected is defined as having any selector match that uses an attribute selector in any position within the selector at all
(9) There must be no inline style attribute on the elements
(10) There must be no sibling selectors in use at all. WebCore simply throws a global switch when any sibling selector is encountered and disables style sharing for the entire document when they are present. This includes the + selector and selectors like :first-child and :last-child.

Примерно же такая оптимизация работает в Mozilla насколько мне известно.
У меня используется несколько иная схема — традиционный caching. Быстрее работает в моем случае.

Приведенный список 10 ситуаций (особенно последняя тема) сводят на нет возможные способы редуцирования O(N*M*D)
Например сайты семейства wikipedia в принципе не оптимизируемы из-за своей системы стилей.

CSS level 3 добавляет еще штук 10 селекторов которые вообще делают невозможным caching и сходные трюки.
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#selectors

Проблема усугубляется еще тем что мало найти список стилей в который попадает данный элемент,
нужно осуществить собственно последовательное наследование этих стилей для получения финального.

CSS level 3 это примерно 60-70 атрибутов у одного стиля.
Т.е. style resolving это серьезно.

Здравствуйте, Дарней, Вы писали:

Д>Пройти по документу, сгруппировать все однотипные элементы (линки — в одну кучку, простой текст — в другую, и т.п.). Для каждой из этих групп извлекаем соответствующий стиль и применяем ко всем элементам, которые попали в группу.
Это подходит только для случаев, когда селекторов в CSS мало. А если их много? А это — суровая реальность соврменной верстки.
Д> Вместо N * M получаем N + const * M, что уже намного лучше.

Д>Правда, узлы, для которых переопределяется CSS, усложняют положение. Придется проводить такую обработку не для всего документа в целом, а для каждого из его узлов, имеющего свою под-CSS.
Д>Альтернативный вариант — пройти по документу и построить глобальную плоскую CSS, заменив у элементов стили на новые. После чего обработать весь документ как одно целое.
Идея хорошая, но сколько она будет стоить? В том-то вся и проблема, что для "планаризации" CSS нужно для каждого элемента выполнить сканирование списка правил и выбрать те, которые применимы. Вычисление применимости селектора в общем случае требует просмотра полного списка предков, а также подглядывания в соседей.
Когда список правил построен, его нужно отсортировать по важности и специфичности. А затем для каждого из запрошенных атрибутов вычислить его фактическое значение с учетом приоритета. Многие стили придется брать из предка; некоторые атрибуты для вычисления потребуют вычисления значения атрибута предка.
Я не специалист, но геморрой тут заметен невооруженным взглядом.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мысль любопытная, но согласиться не могу. Они же этот софт обратно себе получат, не кому-нибудь. Это же не паленый кофе, который можно в дикую страну заслать, там все сожрут, а мы будем у себя хороший кофе попивать... Что-то здесь не то.
Почему не то? Ты что думаешь, в штатах продают кроссовки Nike, собранные в белой зоне? Щас прям. Все та же малайзия и вьетнам — зарплата 30 баксов в месяц. Технологии обеспечения качества. Ширпотреб вполне можно делать безликой массой. Конечно, им хочется оставить себе интересные разработки, для которых надо мозги напрягать.
Вот, опять же, всякие id software что-то не замечены в массовом аутсорсинге.

Небольшое отступление.

Вот многие говорят что ресурсы кушаются но непонятно куда и т.д. Забывая о многих вещах .

Например банальное окошко "Open File" , сравните такое окошко в досе и например в XP , казалось практически одно и то же делает .

Но !!!

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

Для юзера вроде и небольшое отличие , но сложность в реализации по всей системе огромная.

_>Вы когда-нибудь занимались не шарашками расчитанными на месяц, типа получил бабки и свалил,
_>а нормальным сопровождением своих же програм которое длится более n лет.
_>Деньги нужно брать не за РЕШЕНИЕ, а за то что оно (ваше РЕШЕНИЕ) будет работать и приносить клиенту прибыль.
_>n — 1,2,3 и.т.д

Согласен. Это больше вопрос отношения к делу. Мой подход подразумевает отношения с заказчиком как разработчик-заказчик, а не пиявка-жертва. При этом подходе архитектуру надо проектировать. Это работа. Но лучшая работа, чем лишний труд, основанный на бездумном загадывании на будущее.
РЕШЕНИЕ, в моём понимании — именно решение задачи, сформулированной заказчиком. Предполагается (с некоторыми допущениями ) что заказчик знает, что он делает, и вы не думаете за него на каждом шаге. И если Вы видите дополнительные проблемы (в нашем понимании — задачи ) которые встанут перед заказчиком, лучше сразу сообщать ему об этом, или закладываясь на эти задачи, хотя бы ставить заказчика в известность.
А не работать на вырост просто так, потому что вам так придумалось. Это тоже должно быть частью РЕШЕНИЯ.

Но это только моя позиция. Я её Вам не навязываю.
К примеру, некоторые здесь считают алгоритмирование — основной задачей программирования, а всё остальное фуфлом. У каждого свой подход, и, исходя из этого, своё место в жизни.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вообще-то "художественное мастерство, которое скрывается под словом "дизайн"" — ИМХО не дело программиста вообще. Для этого дизайнеры существуют. А для "навыки психологии www-user-а" есть специалисты по психологии, эргономике и т.д.

Ты что-то говорил про оторваность преподавателей от реалий бытия? Не в твой огорд камень, но мы все знаем как должно быть, но работают в этих условиях единицы. И, когда приходит заказчик, ковыряясь антеной от сотка в носу и говорит "Э..." — будь добр — выполни, если хочешь прокормить себя и семью.

PD>Я, например, ни за что красивую иконку не нарисую. Не умею, и все, нет у меня художественных способностей. Ну и что ?

А то, что ты не можешь заменить гуйщика на требуемом уровне (т.е. речь шла о полной взаимозаменяемости) будь ты трижды гуру низкоуровневого программирования. Собственно это я и имел ввиду, когда оспаривал утверждение vdimas о том, что "Первые легко могут заменить вторых. Наоборот — никак". Обратного утверждения о том, что заменить один другого не может в принципе, я тоже не говорю. Да, я могу писать интерфейс, я даже могу писать HTML-ки... Но как это будет выглядеть? Наш веб-программер, наверняка, если придется спустится и до API и прочего "нижнего", но как это будет написано и как это будет работать?

Здравствуйте, mrozov, Вы писали:

M>Павел, можно Вас попросить?
M>Не пишите про .net. Вы умный человек и очень знающий профессионал, но Ваши знания в этой области настолько малы, что на фоне предрассудков просто теряются.

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

Все остальные замечания оставляю без комментариев, так как нового ничего здесь нет.

А вообще мои замечания — не о .Net вовсе, а о соответствии ресурсов задачам.

Евгений! А ты в курсе, что мы с тобой знакомы? Заочно?
До меня это только что дошло, когда ты об smpp заговорил.
Я работаю на одного из клиентов твоей компании. Ты даже можешь (возможно) мое мыло в своей переписке найти.

Я кстати, на нашей стороне проблему неравномерной загрузки решаю посредством MSMQ. Вообще — смычка там такая — библиотеки c++ используются из managed c++ dll, которая интегрируется дальше, уже в чисто c#-ый проект.

А про то, что основной враг быстрых программ — кривые руки — я знаю очень хорошо, на собственном опыте в том числе. Буквально на днях в очередной раз в этом убедился, ускорив операцию раз в 100, убрав ненужную операцию (я бы это назвал — денормализацией программы) и примерно на 5% в результате всяких микро-оптимизаций.

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Кстати, эта точка зрения хорошо объясняет тот факт, что ASP.NET пользуется приличной популярностью, а настольных .NET приложений очень мало. Сайт на ASP.NET работает обычно на отдельной машине, кроме него самого и средств управления там больше ничего и нет, вольготно и раздольно. Настольные же приложения работают там, где кроме них есть еще 10-20 конкурентов, поэтому то замедление, которое они бы привнесли, многим не понравится.

Скорее всего популярность ASP.NET обясняется тем, что это очень удобная технология разработки для WEB, во всяком случае удобнее ASP. Ну и еще тем, что, по сути ничего другого под Win просто нет

PD>1. Рост мощностей продолжится прежними темпами. В этом случае и для многих других задач станет возможным пренебречь эффективностью. Возможно, это коснется и настольных приложений. Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост".

Вряд ли это так. У меня на P4-2.26 c 256Mb Ram вполне нормально работают: Firefox + 2Explorer'a + WinAmp + Fiewall + Anitivirus + VisualStudio 2005 + еще что то может быть не очень тяжелое, хотя вчера еще Photoshop запускал. И работать вполне можно. А ведь 256Mb — это по современным меркам мало.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.

Тогда зачем нужно было в своем тематическом сообщении помещать свои предрассудки на тему дотнета? Глядишь не сделай ты это и разговор мог бы пойти совсем в другм русли.

mrozov прав. Тебе лучше, по крайней мерее пока, не высказываться о дотнете и темболее о его производительности. Для этго тебе неплохо было бы по глубже разобраться в вопросе.

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А вообще мои замечания — не о .Net вовсе, а о соответствии ресурсов задачам.

M>Да ну?

M>"Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост"."
M>Не про .net? Явно!?

Ну и что ?

M>"Сервер на ASP.NET — это новый русский, отгрохавший себе особняк на 20 комнат и не знающий, что теперь с ними делать" Не про .net? Asp.Net у нас теперь стал дико неэффективным web-сервером? С каких пор???

Я этого как раз и не говорил. А под словами "не знающий, что теперь с ними делать" имелось в виду, что он имеет долстаточно ресурсов, на которых может вольготно расположиться.

M>"можно позволить и 2-3 кратную потерю эффективности в той же .Net " Это тоже не про .net? Какую-какую потерю эффективности? Доказательства голословных обвинений в студию!

Я уже не раз сравнения производительности проводил. См. топики здесь и в .net.

M>И настольные .net приложения у нас теперь не пользуются популярностью, оказывается, из-за проблем с производительностью. Ага.

http://www.rsdn.ru/poll/1275.aspx

Автор: Pavel Dvorkin
Дата: 12.10.05
Вопрос: Сколько профессионально сделанных программ для .net имеется на Вашем компьютере ? (Pavel Dvorkin)
(Повтор голосования #937 спустя год)

Сколько профессионально сделанных программ для .net имеется на Вашем компьютере ? (Pavel Dvorkin)
(Повтор голосования #937 спустя год) (Pavel Dvorkin)
Ни одной 52 36,36%
Не больше 3 66 46,15%
Не больше 5 16 11,19%
Не больше 10 6 4,20%
Больше 10 3 2,10%

О причинах я могу только судить, а вот результаты...

Здравствуйте, eao197, Вы писали:

E>Вообще-то эра многопоточных приложений наступила давно.

Это вряд ли. И не наступит пока многопроцессорные решения не станут на рынке основными. Многопоточное решение практически всегда сложнее, медленнее и глючнее однопоточного на однопроцессорной машине.

E>А если один домен зависнет?

Домен не может зависнуть, он с потоком никак не связан.

Здравствуйте, eao197, Вы писали:

E>А что до глючности, то на многопроцессорной технике они еще более глючные (имхо, конечно),

Разумеется. Но там хоть овчинка выделки стоит. А вот если я сейчас начну переписывать алгоритмы януса на многопоточный лад — кому от этого станет лучше?

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, McSeem2, Вы писали:

MS>>На самом деле это всего лишь вопрос личных предпочтений. Лично я люблю решать задачи, которые изначально требуют максимально возможной эффективности. Другие задачи мне не интересны. Ну не интересны и все тут — рутина и тоска зеленая.

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

Я так понимаю что человек который это написла , и близко не представляет сложности задач по быстрому "выводу треугольника". Которая НА ПОРЯДКИ труднее лабания горы посредственного одноразового кода.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Или то, что хорошо понимают, но что вызывает эту тоску — именно потому. что понимают

если так хорошо понимают — почему их имен нет в списке самых богатых людей мира?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Что касается моего отношения к .Net, могу сказать следующее. Я хочу понять, что это — новое слово, генеральный путь или же просто очередная мода ?

Генеральный путь.

Давай я тебе пару примеров приведу: Windows vs DOS, Windows vs OS/2, IE vs Navigator, VisualC++ vs (Borland C++ + Zortech C++ + Watcom C++ + любой другой C++), Microsoft Office vs любой другой Office, Windows Mobile vs PalmOS.

Сейчас мы наблюдаем .NET vs (Java + C++ + все остальное, что не сможет переползти в .NET).
В общем, доминировать со временем будет .NET, адназначна! ((C)Владимир Вольфович).
Но, если вспомнить закон потребления пива, то большинство задач (80%) будет делаться минимальным (20%) набором инструментов, т.е. .NET. Но я надеюсь, что мне повезет заниматься оставшимися 20% задач

PD>Одним словом — куда мы идем ?

Re: Куда катится мир ?

Автор: eao197
Дата: 19.07.05

см. анекдот про орла и воробья.

Здравствуйте, Шахтер, Вы писали:

Ш>Нет там никакой сложности -- подписка на уведомление об изменении каталога.

Я полагаю, что minorlogic имел в виду, как это в системе организовано, т.е как она шлет эти уведомления. Это несколько сложнее, задействуются объекты ядра (файл), а для этого нужно, чтобы был диспетчер объектов и т.д — в общем, ядро NT.

Здравствуйте, McSeem2, Вы писали:

MS>Я бы попросил читать то что написано, а не то, что хочется прочесть. Внимательнее, пожалуйста. Вывод треугольников — это действительно примитивная задача, а "вывод вдвое быстрее" — примерно такая же рутина, как и ковыряние в кривом API (собственно, это задача и относится к категории API). Натривиальным является некий способ генерации этих самых треугольников (это лишь для примера). Это очень тонкий момент, часто вызывающий непонимание. В представлении большинства людей "оптимизация" — это ковыряние на уровне машинных кодов и/или написание длинного и неряшливого спагети-кода. Это тоже на редкость тоскливое занятие. Повторю еще раз — интересной (для меня!) является прежде всего работа над алгоритмической частью, когда, например, требуется приблизить O(N log N) к O(N). Вам знакомо понятие О-нотации? Это чем-то напоминает процесс доказательства математических теорем. И язык как таковой здесь не имеет большого значения.
+1

MS>Есть подозрение, что то, что Вы, уважаемый Дарней понимаете под "сложными задачами" — это на самом деле строительство вширь, когда конструкции могут стоять только на земле, а при попытке что-то соорудить из них ввысь, получается нелепое и неустойчивое нагромождение.
Кому как. Каждый смотрит со своей колокольни. У каждого свои понятия сложности. Мне интересен процесс построения объемных задач. Если говорить об аналогии со строительством(что-то это для всех стало популярной аналогией), это строить дом из булыжников. Нужно построить его так, чтобы он крепко стоял. А булыжники все разные. И нужно подобрать именно нужный булыжник с нужной геометрией. Иногда подработать напильником. Один неверный булыжник всех ситизенов похоронит. Мне сейчас такое интересно. А булыжников много. Это непростая задача.

С уважением. Gleb.

Приведу сравнение возможно спорное но очень яркое.


1. Годами из мрамора вытачивать произведение искусства.
2. Годами и ТОННАМИ оттачивать мрамогрые глыбы для строительства .

Конечно глыбы точить можно творчески , улучшая производительность и т.д. но глыбы все равно остануться глыбами ...

Здравствуйте, Pavel Dvorkin,

PD>1. Если предельная эффективнсть не требуется — значит, железо сейчас избыточно. Если бы железо было намного слабее — писали бы то же, но эффективно, выжимали бы из железа все, чтот можно. Дороже. Хуже. Но делали бы.
PD>2. Эта избыточность ресурсов — что означает ?
--
Производя "железо", очень трудно предвидеть заранее, какие именно программы и в каком количестве на нем будут использоваться. В такой ситуации наиболее выигрышной генеральной стратегией с точки зрения производителя было бы выпускать наиболее производительное железо, которое позволяло бы охватить наибольший класс задач.
Другими словами, избыточность железа, скорее всего, связана не с тем, что нет задач, способных это железо загрузить, а с тем, что не известно заранее, какие и сколько задач на этом железе будут работать.
Если же это известно, то выбор железа можно произвести оптимально, исходя из потребностей этой задачи, обеспечивая ее оптимальную загрузку.

PD>3. Что будет, если этот рост прекратится ?
PD> a) произойдет возврат к борьбе за эффективность, так как потребности общества все же будут расти, а ресурсы расти не будут или будут расти медленнее потребностей
--
Это, скорее всего, так.
Однако даже если производительности железа будет ограничена свойствами "физического мира", есть сравнительно простой способ повышения производительность — использовать несколько "ограниченных" устройств параллельно, одновременно.

С уважением,
Геннадий Майко.

Здравствуйте, Дарней, Вы писали:

MS>>По моему глубокому убеждению, вопрос материальной состоятельности других людей не должен Вас беспокоить. Вообще не должен.

Д>А меня и не беспокоит. Мне просто интересно — почему это мозг вселенского масштаба, достигший глубочайшего просветления в области программирования, и вдруг работает на дядю — вместо того, чтобы рулить своей корпорацией?

А почему Энштейн не был самым богатым человеком в мире (в свое время)?

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, eao197, Вы писали:

E>>А почему Энштейн не был самым богатым человеком в мире (в свое время)?

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

У нас ОЧЕНЬ разный взгляд на то , что такое программирование ...

Здравствуйте, mrozov, Вы писали:

M>"Не понимаю" это очень правильно сказано. Именно — не понимаешь.

M>Очень глупо думать, что использующие низкоуровневые языки и функции программисты — гуру, а мастера верстки dhtml-ных страниц — ламеры. На самом-то деле, все может быть с точность до наоборот.

Я допускаю такую гипотетическую возможность , но к сожалению ни разу не встречал такого в жизни.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, minorlogic, Вы писали:

M>>Приведу сравнение возможно спорное но очень яркое.
GZ>А теперь начинаем объяснять нам глупым, что здесь имелось ввиду.

GZ>С уважением, Gleb.

А вот и не буду , уж очень это очевидно. А если не понял , ну и не стОит ...

Здравствуйте, Дарней, Вы писали:

Д>А меня и не беспокоит. Мне просто интересно — почему это мозг вселенского масштаба, достигший глубочайшего просветления в области программирования, и вдруг работает на дядю — вместо того, чтобы рулить своей корпорацией?

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

Приведу цитату.

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

Есть сильное подозрение, что большинство людей, которые искренне любят решения Microsoft, привлекают не технические решения, а объемы денег этой фирмы. Достаточно слов "миллиарды долларов" и все — можно брать тепленьким, схавает любую баланду и готов горбатиться нещадно. На это и делается весь расчет.

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

Д>Части — тривиальны, построение же из них целого — чрезвычайно сложная задача.

Это тоже в конечном итоге не сложность, а тот же объем. У нас разные понятия о сложности.

Здравствуйте, GlebZ, Вы писали:

GZ>Ну чтож, давай поговорим что очевидно из твоего сообщения. Ты прямо намекаешь, что ты один такой крутой в белом, а
все остальные сапожники и в ....

В общем я не про себя говорил. Но ЛИЧНО я страемлюсь заниматься интерессными для МЕНЯ задачами. Я не горжусь занимаясь рутиной , для меня это не ценность.

GZ>Ты говоришь что ты один занимаешься творчеством, а все остальные кирпичи складывают в кучи.

Я не говорил о том чем занимаюсь. Я говорил о ценности работы. Ты лично много знаешь знаменитых каменщиков ? а скульпторов ?
Любой ТРУД уважаем (кроме плохого), но если человек не стремится РАСТИ над собой , а горд тем что слился с серой массой , это не авызовет у меня уважения.


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

Ну это уже твои комплексы , я например вижу завитсь к людям которые не хотят заниматься рутиной , а стремятся заниматься тыорчеством. Зависть эта черная и не полезная.
Поверь мне , люди занимающиеся творческими задачами , многим жертвуют.

Здравствуйте, eao197, Вы писали:

E>Есть еще и обратная проблема: многие из тех, кто в принципе не смог бы заниматься узкими местами, смотрит на специализированных специалистов свысока и снисходительно.

не вижу для этого причин, за исключением фатальных ошибок в генетическом коде но таких особей к любому вида программирования подпускать нельзя

E>Хотя, иногда, после рюмки-другой 10-летней выдержки чайку "Белый Аист", хочется проронить скупую мужскую слезу, порвать рубаху со словами: "Да я!... Да сложный объект...! Да за две миллисекунды...! Да в режиме транзакционности!...".

Здравствуйте, eao197, Вы писали:

E>Может измениться. Вот у меня был случай -- в одном месте, которое вызывалось слишком часто, было два обращения к new. В многопоточном приложении, где каждый new -- это очень дорого. Я переписал это место так, что new вызывался только один раз. В результате большой кусок кода заработал в два раза быстрее и перестал быть узким местом. Еще больших результатов можно было бы достичь, конечно, изменением алгоритма (там даже не алгоритм а целая идеология бы поменялась), но затраты на такие изменения алгоритма были бы не соизмеримы с полученным выигрышем, а сложность решения серьезно бы увеличилась.

E>Так что элементарную эффективность на уровне кода так же нельзя сбрасывать со счетов.
Со временем это работает на автомате.

Здравствуйте, minorlogic, Вы писали:

E>>Так что элементарную эффективность на уровне кода так же нельзя сбрасывать со счетов.
M>Со временем это работает на автомате.

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

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, minorlogic, Вы писали:

E>>>Так что элементарную эффективность на уровне кода так же нельзя сбрасывать со счетов.
M>>Со временем это работает на автомате.

E>При всем уважении, не могу согласиться. Слишком много факторов сейчас влияют на разработчика, чтобы можно было предугадать, где произойдет потеря производительности.

Могу ответить прямо если бы я так думал , то был бы уже давно уволен.

Здравствуйте, GlebZ, Вы писали:

GZ>Индус — гений. Такое придумать жутко умная голова нужна.

Между прочим, пример вполне реальный, примерно пятилетней давности. И это был именно индус, очень коричневого цвета морды лица.

MS>>Знаешь, какова сложность данного цикла? O(N^3).
GZ>Учитывая особенности функции strcpy — меньше. Правда картины не меняет. Но все равно круто.

Кто познал сущность О-нотации, тот истинно крут! Какая такая "особенность strcpy" может убавить O?

Кстати, я был неправ в оценке времени для первого варианта. На 10 миллионах символов, при одной наносекунде на условную операцию это будет работать всего-навсего 31 тысячу лет. Ничтожное время по космическим меркам. Но зато на 100 миллионах уже будет 31 миллиард лет — вполне ощутимое время.

Здравствуйте, GlebZ, Вы писали:

ПК>>

ПК>>O( N * N * (N/4) ) == O( 1/4 * N^3 ) == O( N^3 )
ПК>>

GZ>Грешен, ляпнул не разобрамшись. Почему делить на 4?

Наверное потому что на современных процах одно слово — это четыре байта. Можно делить на 8, на 1024, на 65536. Это не имеет значения. Сложность все равно остается "эн-куб".

Здравствуйте, McSeem2, Вы писали:

MS>А плюсик можно поствить?
Да на здоровье

MS>Я честно сказать тоже не понимаю О-нотацию. Но осмелюсь утверждать, что понимаю в ней хотя бы что-то. Это действительно сильное колдунство. Например, если в строке не более одного, не более тысячи, не более миллиарда пробелов, то формальная сложность алгоритма остается O(N^2) вне зависимости от фактического количества — ибо есть ограничение в виде некой константы. Но как только мы говорим, что каждый десятый символ — пробел, то сложность цикла сразу становится O(N^3). Можно даже сказать, что каждый миллиардный символ — пробел и все равно это будет N^3. Хотя фактически и практически никакой разницы нет.
У O нотации есть множество подводных камней. Один из которых ты как раз указал. Более классический пример — quicksort и пузырек. По моему ты как-то упоминал что с этим боролся. Полностью и маразматически доверять O нотации нельзя. Иначе мы бы давно сидели бы на хешах. Построить функцию которая будет с очень большой(даже можно сказать космической) вероятностью уникальна для значения(как это делается в криптохешах) в принципе легко. То есть организовать доступ O(1) для любой структуры можно. Но благодаря тому, что такая функция сама по себе достаточно тормозная, а результат функции будет достаточно большой по объему, никому это в голову и не приходит.

MS>Я и не утверждаю, что это плохо. Есть случаи, где такое вполне допустимо. Но!!! Надо четко оговаривать ограничения — типа не более 1000 символов. Или даже — "я написал лажу, вы имеете право ее использовать". Но таких признаний никто не любит — и в этом заключается весь корень зла. Типа одни индусы подразумевают, что "у нас супер-ультра-функция", а другие индусы, не подозревая о неявных ограничениях, используют эту функцию для 5000 символов. Получается полная вешалка.
Фигово когда не проводится нагрузочное тестирование и программа не анализируется через профайлер. В маленьких программах это действительно не особо нужно, так как все алгоритмы перед глазами. А вот в крупных комплексах, будь у тебя семь пядей во лбу, фиг спрогнозируешь что и где будет тормозить. К сожалению такие вещи не всегда возможны, но пытаться на опытных данных попробывать какая получилась производительность, и где находится bottle neck надо. И тогда никакие индусы не страшны.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>У O нотации есть множество подводных камней. Один из которых ты как раз указал.

На самом деле, надо понимать две веши. Первая, что O(N^3) на 100 миллионах не закончится никогда, вторая — при каких N алгоритм O(N^3) начинает работать медленнее, чем O(N). Эти вещи должны впитываться с молоком матери... Ой, пардон. Конечно же я хотел сказать "с портвейном студенчества"...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет, Глеб. Это нормальный код, который напишет любой начинающий программист. Он уже понял, как писать программы и работать со строками. И если забыть про эффективность — в этом коде ничего плохого нет. Он, кстати, понятнее и логичнее.

Павел, если ты учишь студентов, то наилучшим объяснением О-нотации будет попросить их представить, как эта "байда" будет работать при ста миллиардах чего-то там на входе. Ну или когда студент приносит сомнительный код не зачет, попросить его сделать оценку времени выполнения для 100 миллиардов. У меня есть сильное опасение, что 90% так называемых "программистов" вообще не имеют предствления, что такое О-нотация. А уж НП-полность (Nondeterministic Polynomial Completeness) — это и для меня загадка, примерно как квантовая механика. И чем дальше копаешь, тем запутанней все это становится.

Здравствуйте, c-smile, Вы писали:
CS>Угу. я второй месяц пытаюсь найти автора придумавшего вот это:
Самое забавное, имхо, — в том, что эти грабли уже давно обнаружены и документированы. Я еще в 1991 году где-то читал насчет того, что большинство инциатив комитетов пошли в девнулл, а то, что налабали на коленке практики имеет тенденцию жить.

У меня перед глазами ODMG OQL, где столь же небрежным росчерком пера запретили практически любые оптимизации — до сих пор нет полной реализации. И, скорее всего, никогда не будет.
Вот теперь вы, два опытных человека, рассказываете про то, какие благоглупости выходят из недр W3C. И ведь все из благих побуждений! Ну разве не здорово иметь возможность воткнуть в документ какой-нибудь <hr id="oops">, и всё что после него, станет, к примеру, синим?

Здравствуйте, eao197, Вы писали:

E>Тогда тебе могут быть интересны: Re: Совет "опытного камикадзе" если хошь

Автор: c-smile
Дата: 26.10.05

, Re[2]: Советы 5), 6) и 7)

Автор: c-smile
Дата: 26.10.05

и Re: Велосипеды и эффективность решений

Автор: eao197
Дата: 26.10.05

.

полностью согласен.
Даже пофлеймить не о чем

Здравствуйте, vdimas, Вы писали:

V>Разница во взаимозаменяемости. Первые легко могут заменить вторых. Наоборот — никак.
Да вот ничего подобного. Ничего общего со взаимозаменяемостью нет. Разные специализации абсолютно, разные навыки.

V>Первых — днем с огнем сейчас ищи, вторых — как саранчи,
В соответствии со спросом, в общем-то.

V>и т.д.
Что и т.д.? Пока не впечатляет.

Здравствуйте, Pavel Dvorkin, Вы писали:

Вот только что знакомые закончили тесты:

Они портируют приложение с PalmOS.
Одному их прожект менеджеру пришла светлая идея
а не написать ли нам это на Compact Framework...

Device used in Feasibility Study: DELL Axim X51v, 624 MHz, 64 MB RAM, 256 MB ROM, Intel PXH270 (typical high end device).

DB: MS SQL Mobile Edition

Insert 6000 records into DB:
1729 sec = 29 min
(Device became irresponsive even to power button until the end of insert operation )

Additional comment on power consumption:
Insertion of 6000 contacts into database consumed 24% of the battery.

К слову сказать оригинальное приложение на полу-придушенном PalmOS девайсе
приемлемо работает с 16 тыс. записями.

А вы говорите....

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, vdimas, Вы писали:

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

V>>если на дотнете — пиши в приват, с лексерами помогу

E>Что-то модно это сейчас стало, DSL-ями заниматься И Фаулер туда же: http://martinfowler.com/articles.html#id2251334

V>>в общем, есть потребность в разработке своих DSL, но нужен инструмент, которым легко ворочать

E>Ruby (Re[2]: Metaprogramming et al: Ruby?

Автор: eao197
Дата: 18.10.05

, [Ruby,C++] RuCodeGen -- простой фреймворк для кодогенерации

Автор: eao197
Дата: 16.11.05

),
E>Smalltalk (Re[3]: Metaprogramming et al: Ruby?

Автор: Andrei N.Sobchuck
Дата: 18.10.05

),
E>Lisp (Metaprogramming et al

Автор:
Дата: 09.07.05

, Lisp

Автор: fionbio
Дата: 12.07.05

)
E>?

С лисп и смолтолк знаком слегда, но это все не то. Rubby тоже выглядит немного "специальным" языком. Хочется иметь нечто вроде C#, но добавлять операторы языка или нечто вроде глобальных ф-ий (которые таковыми являться не будут).

С другой стороны иметь возможность некоторые конструкции убирать. Т.е. иметь возможность разработать прикладной язык, где нельзя шагнуть вправо/влево. Например, на определенном прикладном уровне вообще вычленить из языка константу null, чтобы не иметь возможности ее создавать/обрабатывать

Здравствуйте, Дарней, Вы писали:

Д>в общем, пора завязывать с "низким" и "высоким" уровнем. Очень уж эти понятия зависят от выбора точки отсчета

Я говорил о стремлении одних понимать суть вещей, которыми они оперируют, в отличие от тех, кто удовлетворяется внешними API. Это стремление не зависит от точки отсчета.

Здравствуйте, eao197, Вы писали:

E>Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.

Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.

Здравствуйте, mrozov, Вы писали:

M> — Да, но .net медленный.

Стоп-стоп. Об этом я речи не вел вовсе. Просто ты сказал, что когда наступит эра многопоточных приложений, то на C++ их делать не будут. Вообще-то эра многопоточных приложений наступила давно. С момента появления многопоточности в OS/2 и Windows NT (массово), и где-то в это же время (POSIX 1003.1c-1995 (Threads extension)) в Unix-ах стала появляться. Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать. Более широкое распространение многопроцессорных платформ здесь ничего не изменит.

M>Боюсь, что для большинства задач все-таки нужна многопоточность. И потом — в .net есть замечательная возможность запускать несколько доменов в одном процессе =)

А если один домен зависнет?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>

СГ>Например, работая на P2-200MHz и на P4-2GHz, не замечаешь особой разницы.
СГ>Почему недостаток? Ну как же, а за что деньги плочены?

Ставили как-то на пентюх Windows 2.0. Была такая. Скорость от XP или 286 — осталась.

С уважением, Gleb.

Здравствуйте, eao197, Вы писали:

E>Вообще-то эра многопоточных приложений наступила давно.
Да не сказал бы. Даже серверные приложения зачастую не очень-то и масштабируемы, а мастшабируемых клиентских так и вообще еще почти нет. И когда все поголовно сюда ломанутся, понадобятся совсем другие инструменты.

E>Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать
Также, как и однопоточные.

E>А если один домен зависнет?
Честно говоря — не знаю. Зависнет — значит зависнет. Остальных это затронуть не должно. По идее.
Встречный вопрос — а если зависнет один из процессов?

Но! Это уже точно не по теме.

Здравствуйте, mrozov, Вы писали:

E>>Вообще-то эра многопоточных приложений наступила давно.
M>Да не сказал бы. Даже серверные приложения зачастую не очень-то и масштабируемы, а мастшабируемых клиентских так и вообще еще почти нет.

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

Есть такой протокол, Short Message Peer-to-Peer (SMPP), для обеспечения обмена SMS-ами с SMS-центрами мобильных операторов. SMPP -- это компактный двоичный протокол, который подразумевает обмен пакетами (PDU) по одному TCP/IP каналу. Следовательно, пропускная способность SMPP-узла ограничивается либо пропускной способностью канала, либо возможностью софта по обработке данных. Ну вот представь себе, что через SMPP канал начнет идти 1000 транзакций в секунду. Это означает, что обработка одной транзакции должна занимать меньше миллисекунды, а это уже не слабый real-time. Но фишка в том, что балансировку здесь сделать сложно -- вся 1000 транзакций пойдет через один канал и придет в одну точку. Даже если эта точка будет load-balancer-ом, то еще нужно еще специальным образом реализовать, т.к. в SMPP есть свои заморочки с организацией сессий и пр. И представь себе софт, который разрабатывался в расчете на трафик в 10-20 транзакций, но на него стали сваливаться объемы в 100 раз большие (бизнес удачно пошел). Как его смаштабировать?

Сейчас кроме SMPP еще появился MMAP -- аналог SMPP, но на основе SOAP. Каждая отдельная транзакция в XML-е занимает гораздо больше места, чем в SMPP. Да еще HTTP в качестве транспорта. Жуть, как может показаться. А на самом деле, распараллеливание здесь делается ну просто на порядки проще. Хотя бы за счет того, что HTTP-load-balancer-ов навалом. И все, что нужно сделать -- это CGI (попросту говоря), который будет заниматься обработкой отдельных транзакций. А дальше -- ставь кластер из 10 машин, ставь туда web-сервер и распределяй по 100 транзакций на каждую машину. Особых проблем не видно.

А ведь все из-за чего -- из-за другого протокола.

M> И когда все поголовно сюда ломанутся, понадобятся совсем другие инструменты.

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

E>>Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать
M>Также, как и однопоточные.

E>>А если один домен зависнет?
M>Честно говоря — не знаю. Зависнет — значит зависнет. Остальных это затронуть не должно. По идее.

Угу. Именно, что по идее.

M>Встречный вопрос — а если зависнет один из процессов?

Он просто прибивается. Скажем через kill -9 Остальные продолжают работать. Unix-овые системы уже лет двадцать так работают.

Здравствуйте, mrozov, Вы писали:

M>
M>Евгений! А ты в курсе, что мы с тобой знакомы? Заочно?



Максим!
Как тесен мир!
Оказывается, нам нужно было раньше на "ты" переходить А я то думаю, что за ник знакомый

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.

E>Тогда ответь мне на такой вопрос: для какой-то задачи нужна машина класса P-200 и 128Mb памяти. Где ее взять?

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

Здравствуйте, eao197, Вы писали:

E>Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.

Твой фрэймворк максиму что может сделать — это немного упростить вызовы имеющегося АПИ ОС. Этого явно не достаточно чтобы сделать создание эффективных многопоточных приложений настолько простым, чтобы массы программистов не относящихся к гуру могли быстро создавать масштабируемые приложения.

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

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Мой ответ — Pentium-100 32 Mb. Ну в крайнем случае раза в 2 лучше
GZ>Мало иметь 100Мб информации, нужно еще ею эффективно управлять. Это уже СУБД. А теперь представим какой объем должен кэшироваться в памяти чтобы диск не стал узким и жестко ограничивающим средством. Мы можем задумываться больше о той полезной функциональности которую мы можем реализовать. Лет 10 назад, это стоило бы значительно дороже.

Дороже — бесспорно. Но, положа руку на сердце — для этого действительно надо 3Ghz — 512 Мб ? СУБД — да, только сколько информации в этой СУБД будет для этой фирмы ? Десятки Мб, максимум. А насчет управлять — зайди на сайт небольшой компьютерной фирмы, турфирмы и т.д.- много там этого управления ?

PD>>Доказательство — 10 лет назад такие сайты были, если не у нас, то в США, и работали они на такой технике. И оперировали они тем же объемом информации, просто потому, что никакой принципиально новой информации у фирмы, торгующей ,к примеру, компьютерами, просто не появилось. Изменился ассортимент, вот и все.
GZ>20 лет назад, если бы у нас была задача организовать сайт с такой-же нагрузкой как у RSDN — то нам бы пришлось купить компьютер размером с хорошую комнату и такой производительности, что вся бы страна гордилась. А чтобы написать аналогичный софт, нужно было-бы потратить огромнейшую кучу времени, нанять огромнейшее количество программистов, и заплатить несколько миллионов.

Э нет, не о том речь. Ты бы еще про rambler.ru или microsoft.com сказал. С ними — согласен. А вот в рамках той задачи, о которой я писал ? На rsdn уж никак не 100 сессий в день...

PD>>А кстати, какой клиент это все потянет ? Netscape 3.0 на 16 Мб под Windows 95 потянет ? Тянул же он раньше...
GZ>Было уже такое. Вся нагрузка на сервер, рабочая станция — один монитор, да связь с сервером. Но количество задач решаемый сейчас пользователем значительно больше.

Я же не спорю. Для круга задач — да. А вот для большого круга задач же — нет.

GZ>Это компьютер адаптированный для выполнения конкретно-поставленной задачи. Это вполне нормально и никакого противоречия я не вижу. Он не такой же как обычный, он другой. Для него требования другие.

А какой процент таких "других" задач ? Если вспомнить то, с чего я начал (цитата из постинга), то "И не только у меня, а у подавляющего большинства здесь присутствующих," Это не мои слова.


PD>>А сложность задач в 50 раз отнюдь не увеличилась. Для той торговой фирты, с которой я начал, она и не могла увеличиться в 50 раз — просто потому, что нет у нее задач такой сложности. И не предвидится.
GZ>Усложнились не задачи которые решаются торговой фирмой. Усложнились задачи выполняемые с помощью компьютера. И именно благодаря развитию железа и софта.

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


PD>>2. Рост мощностей замедлится. В этом случае для тех задач, для которых и ныненшняя мощность избыточна, все останется как сейчас. Но понемногу будут подтягиваться задачи, которые пока что или вообще не решаются (может быть, даже само их существование пока не осознано, так что их и не ставят), или же решаются с трудом, так как имеющиеся способы их решения вынуждены были ориентироваться на имеющиеся мощности (игры — классический пример). Доля этих задач будет возрастать, что приведет к возврату требований по эффективности написания кода.
GZ>Это сказка. Пути назад уже нет.

Кто знает...

GZ>Вообще ты все время упускаешь следующую вещь. То что сейчас делает один программист, раньше стоило несколько миллионов зеленых. Мы вкатились в систему компонентов и библиотек. Я уже не должен отслеживать обратный ход луча на мониторе. Мы теперь используем более функциональные компоненты как кирпичи. И основное торможение в программах дают именно эти компоненты. Они многое могут, они сильно нам помогают, но именно они и являются тормозом производительности. Но развитие железа опережает развитие компонентов. Поэтому мы можем меньше думать о них, и больше думать о том, что мы хотим сделать. Кто может сказать что лет 15 назад он в одиночку написал бы сервер приложений?

Все это очень хорошо. Но ты тоже не хочешь принять один момент. А именно, если задача будет такова, что для нее ресурсов не хватит, то все эти рассуждения стоить будут немного. Делать надо, а как — неважно, если одно не позволяет — другое будет.

GZ>Вобщем, перевод требований по эффективности кода это процесс не искуственный, это процесс эволюционный.

+1

Здравствуйте, Nickolay Ch, Вы писали:

NC>То, что на сервере может крутиться несколько сайтов(частое явление), или же это вообще может быть выделенный виртуальный сервер, каких несколько на одном физическом, Вы конечно не учли почемуто.

Почему не учел. И такое возможно, и, наоборот, сервер, который в действительности на десятках машин расположен (интересно, сколько их у МС на msdn.microsoft.com ?) тоже возможно. Я про частный случай говорил — есть организация, у нее сервер, второй ей не нужен.

NC>На настольной машине одновременно работают 3,5,7 — 10 максимум пользовтаельских приложений. А "активно"(т.е. жрут память и проц) 1-2. Не верим — давайте считать(приведу свой пример, буду рад если то же напишут другие о себе):

<skipped>

Ну примерно то же самое, список несколько иной. Да, 5-10

IExplore 31 Мб
svchost 21
expolrer 18
skype 18
devenv 18

остальные порядка 10 и менее. Всего сейчас commit charge 282 Мв. Правда, VS я специально сейчас запустил, так что при активной работе будет побольше.



NC>Более того, смею утверждать, что больщинство пользовательских пк имеют то же распределение загрузки:
NC>1 активное(рабочее приложение, это может быть редактор игра и т.п.) + Музыка(возможно) + 2-5 приложений в фоне. И где же ваша драка за ресурсы???

Таки есть. Не у меня, у меня 768 Мб. А вот при том же наборе программ и 256 Мб уже напряг будет. Даже если исключить VS — она там ни к чему.

NC>Вообще хочу Вам задать вопрос: из чего появляется задача минимизации мощности обордудования для заданного программного продукта.

Еще раз — нет такой задачи. А есть вопрос, который я уже задал. Повторяю его и здесь

Вопрос — как соотносятся задачи и ресурсы. Если ресурсов на порядок больше — слава богу. Но что это значит — не будет таких задач в массовом масштабе, которые требовали бы этих ресурсов (т.е. обществу такие задачи в массовом масшатабе не нужны просто) или же рост ресурсов был настолько быстрым, что общество за ним не успело и задачи эти еще не сформулировало ?

Здравствуйте, Glоbus, Вы писали:

G>Здравствуйте, Pavel Dvorkin, Вы писали:

<skipped>

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

Здравствуйте, ghecko, Вы писали:

G> Скорее всего популярность ASP.NET обясняется тем, что это очень удобная технология разработки для WEB, во всяком случае удобнее ASP. Ну и еще тем, что, по сути ничего другого под Win просто нет

Вообще-то Апач и почти любые другие разработки (например JSP) доступны под Виндовс.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Дороже — бесспорно. Но, положа руку на сердце — для этого действительно надо 3Ghz — 512 Мб ? СУБД — да, только сколько информации в этой СУБД будет для этой фирмы ? Десятки Мб, максимум. А насчет управлять — зайди на сайт небольшой компьютерной фирмы, турфирмы и т.д.- много там этого управления ?
По разному. Одни вкладывают деньги в свое. Другие раскладывают html на бесплатные сайты(в которых уже другие компы). Деньгу все считают. Но internet web-сайты на обычном десктопе — это извращение. Хотя бы по требованиям к надежности.

PD>Э нет, не о том речь. Ты бы еще про rambler.ru или microsoft.com сказал. С ними — согласен. А вот в рамках той задачи, о которой я писал ? На rsdn уж никак не 100 сессий в день...
У меня есть сайты которые иногда поисковые сервера посещают чаще чем пользователи. Есть сайты у которых 3 тысячи пользователей. Engine один и тот же. Так вот, те которые посещаются значительно меньше предпочли это решение потому что оно дешевле чем построение с нуля. Повторю ключевое слово — дешевле.
Так и все остальное. Пользователи (и мы программисты также пользователи) предпочитают готовые решения или компоненты, чем построение специализированных. Потому что так дешевле.

PD>>>А кстати, какой клиент это все потянет ? Netscape 3.0 на 16 Мб под Windows 95 потянет ? Тянул же он раньше...
GZ>>Было уже такое. Вся нагрузка на сервер, рабочая станция — один монитор, да связь с сервером. Но количество задач решаемый сейчас пользователем значительно больше.
PD>Я же не спорю. Для круга задач — да. А вот для большого круга задач же — нет.
GZ>>Это компьютер адаптированный для выполнения конкретно-поставленной задачи. Это вполне нормально и никакого противоречия я не вижу. Он не такой же как обычный, он другой. Для него требования другие.
PD>А какой процент таких "других" задач ? Если вспомнить то, с чего я начал (цитата из постинга), то "И не только у меня, а у подавляющего большинства здесь присутствующих," Это не мои слова.
тут не понял.

GZ>>Усложнились не задачи которые решаются торговой фирмой. Усложнились задачи выполняемые с помощью компьютера. И именно благодаря развитию железа и софта.
PD>С помощью компьютера можно самые разные задачи решать, не об этом речь. А вот все же как с задачей организации сайта для вышеупомянутой фирмы ?
Уже ответил.

PD>Все это очень хорошо. Но ты тоже не хочешь принять один момент. А именно, если задача будет такова, что для нее ресурсов не хватит, то все эти рассуждения стоить будут немного. Делать надо, а как — неважно, если одно не позволяет — другое будет.
Никто и не говорил что нужно писать плохо. Адаптацию под комп пользователя(или предполагаемого пользователя) никто не отменял. Просто изменение приоритетов в изменившихся условиях.

С уважением, Gleb.