Решил еще раз вернуться к этому вопросу и посмотреть на него с несколько иной точки зрения.
Тема оптимизации, которую я инициировал, вызвала весьма бурную реакцию. Насколько я понимаю (судя по оценкам , многие со мной согласны, в то же время были высказаны соображения, которые я если и не принимаю полностью, то отмахнуться от них все же не могу.
Вернуться к вопросу меня побудило вот это сообщение IT. Впрочем, и до него аналогичные мнения высказывали и другие.
>Павел, знаешь в чём твоя ошибка? Особенно в терминах цели 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>Решил еще раз вернуться к этому вопросу и посмотреть на него с несколько иной точки зрения.
Непомню кто сказал:
Увеличение произвадительности компьютера почти никак не скажется на простых задачах .
НО!
Тысячи сложных задач станут простыми ,
Станут сложными сотни очень сложных ,
И станут возможными несколько невозможных
Павел, можно Вас попросить?
Не пишите про .net. Вы умный человек и очень знающий профессионал, но Ваши знания в этой области настолько малы, что на фоне предрассудков просто теряются.
Большинство пользователей не имеют притензий к скорости настольных приложений, написанных на VB. (.net работает быстрее.)
Зато притензий к скорости программ, написанным на С++ — масса. Возьмите Word или Windows, например. Следуя Вашей логике можно решить, что с++ — самый тормознутый язык из всех когда-либо используемых.
Ну не надо про это, прошу Вас. Смешно и грустно. Толку удручающе мало. Выбирайте другие примеры.
А вообще — не согласен я с Вами категорически. Рост требований к железу связан с увеличением алгоритмической сложности в единицу времени на единицу программиста. Отсюда и новые среды/языки. Мифическое "торможение" .net полностью теряется на фоне общего кол-ва операций, которые современным программам необходимо выполнять. На современном компьютере для .net места более чем достаточно. Значит и в будущем ничего в этом плане не изменится.
Более того, рост мощностей компьютеров будущего будет, видимо, связан в основном с многоядерными процессорами. Следовательно — быстрыми будут не оптимизированные вообще алгоритмы, а оптимизированные под многопоточное исполнение. И как следствие, программирование будущего — оно многопоточное. И хотя я не знаю, на каком языке мы будем писать эти программы, но то, что это не будет ни с++ ни asm — практически не сомневаюсь.
Здравствуйте, mrozov, Вы писали:
M>Более того, рост мощностей компьютеров будущего будет, видимо, связан в основном с многоядерными процессорами. Следовательно — быстрыми будут не оптимизированные вообще алгоритмы, а оптимизированные под многопоточное исполнение. И как следствие, программирование будущего — оно многопоточное. И хотя я не знаю, на каком языке мы будем писать эти программы, но то, что это не будет ни с++ ни asm — практически не сомневаюсь.
Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.
Ну и кроме того, чтобы использовать многопроцессорность и многоядерность нужно будет распараллеливание делать. Но вот имеет ли смысл делать это через многопоточность или через многопроцессовость -- это еще вопрос, который будет сильно зависеть от решаемой задачи. Ведь однопоточное приложение в разработке и отладке гораздо проще, чем многопоточное. Как следствие, часто, надежнее и дешевле.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mrozov, Вы писали:
M>Павел, можно Вас попросить? M>Не пишите про .net. Вы умный человек и очень знающий профессионал, но Ваши знания в этой области настолько малы, что на фоне предрассудков просто теряются.
Да нет у меня никаких в отношении .Net предрассудков. Я искренне пытаюсь понять — что из себя представляет это явление как таковое и куда оно нас ведет.
Все остальные замечания оставляю без комментариев, так как нового ничего здесь нет.
А вообще мои замечания — не о .Net вовсе, а о соответствии ресурсов задачам.
Здравствуйте, eao197, Вы писали:
E>Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.
Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.
Тогда ответь мне на такой вопрос: для какой-то задачи нужна машина класса P-200 и 128Mb памяти. Где ее взять?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Зря не сомневаешься. Я сейчас пишу многопоточные приложения на C++ без особых проблем. Просто потому, что всей бодягой, связанной с многопоточностью специальный фреймворк занимается.
Это какой-то замкнутый круг, ей-богу.
— Почему на с++, а не на .net, под которым надежнее?
— Потому что .net медленный.
— Да не медленный он вовсе, хватает с огромным избытком. На VBS и то куча кода написано — и ничего.
— Не будет хватать со временем, если роста скорости процессоров не будет.
— Так ведь они многопроцессорными будут.
— Ну а я на с++ тоже многопоточно писать могу.
— Я тоже могу, но ведь на .net это делать заметно проще. А там и специальные языки, заточенные под это дело подоспеют.
— Да, но .net медленный.
E>Ну и кроме того, чтобы использовать многопроцессорность и многоядерность нужно будет распараллеливание делать. Но вот имеет ли смысл делать это через многопоточность или через многопроцессовость -- это еще вопрос, который будет сильно зависеть от решаемой задачи. Ведь однопоточное приложение в разработке и отладке гораздо проще, чем многопоточное. Как следствие, часто, надежнее и дешевле.
Боюсь, что для большинства задач все-таки нужна многопоточность. И потом — в .net есть замечательная возможность запускать несколько доменов в одном процессе =)
Но по большому счету — речь просто о том, что хотя .net требует под себя доп. мощности, но эти мощности уже есть. А какого-то особого замедления работы managed программ на современном компьютере лично я не замечаю.
Здравствуйте, mrozov, Вы писали:
M> — Да, но .net медленный.
Стоп-стоп. Об этом я речи не вел вовсе. Просто ты сказал, что когда наступит эра многопоточных приложений, то на C++ их делать не будут. Вообще-то эра многопоточных приложений наступила давно. С момента появления многопоточности в OS/2 и Windows NT (массово), и где-то в это же время (POSIX 1003.1c-1995 (Threads extension)) в Unix-ах стала появляться. Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать. Более широкое распространение многопроцессорных платформ здесь ничего не изменит.
M>Боюсь, что для большинства задач все-таки нужна многопоточность. И потом — в .net есть замечательная возможность запускать несколько доменов в одном процессе =)
А если один домен зависнет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вообще мои замечания — не о .Net вовсе, а о соответствии ресурсов задачам.
Да ну?
"Похоже, авторы .Net именно на это и рассчитывают — система явно сделана "на вырост"."
Не про .net? Явно!?
"Сервер на ASP.NET — это новый русский, отгрохавший себе особняк на 20 комнат и не знающий, что теперь с ними делать" Не про .net? Asp.Net у нас теперь стал дико неэффективным web-сервером? С каких пор???
"можно позволить и 2-3 кратную потерю эффективности в той же .Net " Это тоже не про .net? Какую-какую потерю эффективности? Доказательства голословных обвинений в студию!
И настольные .net приложения у нас теперь не пользуются популярностью, оказывается, из-за проблем с производительностью. Ага.
Никаких предрассудков и искренее желание понять. Ну да. Видное невооруженным взгядом.
Здравствуйте, eao197, Вы писали:
E>Вообще-то эра многопоточных приложений наступила давно.
Да не сказал бы. Даже серверные приложения зачастую не очень-то и масштабируемы, а мастшабируемых клиентских так и вообще еще почти нет. И когда все поголовно сюда ломанутся, понадобятся совсем другие инструменты.
E>Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать
Также, как и однопоточные.
E>А если один домен зависнет?
Честно говоря — не знаю. Зависнет — значит зависнет. Остальных это затронуть не должно. По идее.
Встречный вопрос — а если зависнет один из процессов?
Здравствуйте, 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 было трудно написать тормозной код, но легко было стормозить программу работой диска и выводом на экран.
И еще, голову никто не отменял. Если у тебя несколько потоков деруться за один ресурс, то как бы ты не старался написать быстрый код, скорость не увеличится. Вот именно на разрешение подобных проблем, времени остается значительно больше.
Вобщем, перевод требований по эффективности кода это процесс не искуственный, это процесс эволюционный.
Здравствуйте, 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-овые системы уже лет двадцать так работают.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Евгений! А ты в курсе, что мы с тобой знакомы? Заочно?
До меня это только что дошло, когда ты об smpp заговорил.
Я работаю на одного из клиентов твоей компании. Ты даже можешь (возможно) мое мыло в своей переписке найти.
Я кстати, на нашей стороне проблему неравномерной загрузки решаю посредством MSMQ. Вообще — смычка там такая — библиотеки c++ используются из managed c++ dll, которая интегрируется дальше, уже в чисто c#-ый проект.
А про то, что основной враг быстрых программ — кривые руки — я знаю очень хорошо, на собственном опыте в том числе. Буквально на днях в очередной раз в этом убедился, ускорив операцию раз в 100, убрав ненужную операцию (я бы это назвал — денормализацией программы) и примерно на 5% в результате всяких микро-оптимизаций.
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)
при запуске нескольких вордов + студии + ие + Касперский(!)
Вообще хочу Вам задать вопрос: из чего появляется задача минимизации мощности обордудования для заданного программного продукта.
Явно не из экономических посылок, ибо в подавляющем большинстве случаев железо дешевле труда разработчиков. Тогда из чего?
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 — это по современным меркам мало.
Три великие достоинства программиста: лень, нетерпение, надменность... Л. Уолл
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я бы не хотел, чтобы дискуссия, если она развернется, вылилась в очередное выяснение .Net против классики, C++ против C# и т.д. Я хотел бы другое обсудить — соответствие ресурсов и задач.
E>Тогда ответь мне на такой вопрос: для какой-то задачи нужна машина класса P-200 и 128Mb памяти. Где ее взять?
Стоп-стоп. Где ее взять — вестимо, на свалке, может быть . И я восе не призываю ее там искать. Мой вопрос не в этом. Вопрос — как соотносятся задачи и ресурсы. Если ресурсов на порядок больше — слава богу. Но что это значит — не будет таких задач в массовом масштабе, которые требовали бы этих ресурсов (т.е. обществу такие задачи в массовом масшатабе не нужны просто) или же рост ресурсов был настолько быстрым, что общество за ним не успело и задачи эти еще не сформулировало ?
. 
,
,
Скорость от XP или 286 — осталась. 
