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

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

G> Доступны. Но смысл применения Apache под Win от меня ускользает. Java?. Ее приемущества перед .NET
G>опять же мне кажутся сомнительными

В смысле создания Web-приложений? А почему сомнительными?

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

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

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

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

G> Доступны. Но смысл применения Apache под Win от меня ускользает. Java?. Ее приемущества перед .NET
G>опять же мне кажутся сомнительными

Тебе сомнително, а другим нет. Все равно утверждать что под виндовс есть только дотнет и асп не верно.

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

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

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

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

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

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

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

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

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

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

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

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

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

GZ>>По разному. Одни вкладывают деньги в свое. Другие раскладывают html на бесплатные сайты(в которых уже другие компы). Деньгу все считают. Но internet web-сайты на обычном десктопе — это извращение. Хотя бы по требованиям к надежности.
PD>Требования к надежности везде разные. если сайт чисто информационный, ну еще с отсылкой заказа без онлайн покупок, то требования небольшие. Рухнет — перезагрузим страницу.
Я говорил о железе. Рухнет — новую машинку покупать. Это несколько и дороже и дольше по времени.

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

PD>Если ресурсов на порядок больше — слава богу. Но что это значит — не будет таких задач в массовом масштабе, которые требовали бы этих ресурсов (т.е. обществу такие задачи в массовом масшатабе не нужны просто) или же рост ресурсов был настолько быстрым, что общество за ним не успело и задачи эти еще не сформулировало ?
PD>Я имел в виду, что IT (кажется) отметил, что задач, требующих эффективности, не так уж много. Вот я и хочу понять , что эта ситуация означает. А что дешевле, надежнее и т.д — тема сама по себе интересная, но не об этом сейчас речь.
Я бы тут его поправил. Задач требуеющих эффективности от конкретного программиста. Потому как наиболее эффективные компоненты уже написаны.
Возьмем к примеру Clipper. Была такая база по DOS. Она абсолютно вписывалась в те требования к памяти и производительности. Но это была навигационная база. Создание универсального механизма(хотя они были) было достаточно проблематично. В результате программисту приходилось думать не о функциональности, а о решении задач эффективности базы данных. А это намного более сложные задачи. Сейчас это даже на фоне Ассеss'a выглядит смешно. Он и может содержать значительно больше данных, он и умнее общается с программистом. Он сама решает задачи эффективности базы данных. Но если поставить вопрос, можно ли сделать вместо Accessa альтернативу специализированную под конкретную программу? Да можно. И она может быть быстрее, и меньше памяти жрать, и значительно эффективней кэшировать. Только для этого нужно очень много знать. А так у нас используется процентов 30 от тех механизмов которые там есть, остальные висят мертвым грузом. Можно поставить MSSQL, который еще эффективней. Но тогда ты будешь использовать процентов 10 от того что там есть. А может еще меньше. Можно поставить и Oracle. Тогда процент еще существенно уменьшится. Если говорить о Windows — то это одна большая помойка неиспользуемой функциональности. Но главный вопрос уже не в том, что мы не полностью используем их средства а они занимают ресурсы, главный вопрос в том, что нам полезней те высокоэффективные механизмы которые там есть чем их недостатки.
В той же степени можно сказать и о GC. Ну жрет память. Но он дает эффективность выраженную в пониженной вероятности встретить ошибку. Он эффективно выполняет работу за программиста. Конечно абсолютной универсальности нет. Можно сделать и более эффективный специализированный инструмент типа того что делается для систем САПР. Но для большинства приложений его плюсы больше чем недостатки от универсальности.

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

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

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

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

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

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

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

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

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

Не вижу где не хватает памяти дико. И еще 512 метров никак бюджет не перенапрягут.
Если уж говорить о профессиональном юзании компа(разработка, у вас я вижу Photoshop, Dreamweaver) то поставить себе 1Гб-1.5 вполне нормально. Я долго работал на 512 Мб, все было ок, правла когда возникла необходимость разрабатывать на виртуалке поставил еще гиг без проблем.

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

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



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

Вы еще 8 мб вспомните. Для ненапряжной работе в каком нить ворде, просмотра фильма или музыки, общения по асе и серфинга 256 хватает(у родителей дома столько на компе), хотя это вчерашний день. Модуль 512 мб стоит 50$



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

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

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


E>В смысле создания Web-приложений? А почему сомнительными?

Птому что можно долго спорить что лучше, что мнгоие и делают. Но я бы взял то, что поддерживается
проиводителем ОС, если явных приемуществ нет. Опять же все это ИМХО.

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

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

G>> Доступны. Но смысл применения Apache под Win от меня ускользает. Java?. Ее приемущества перед .NET
G>>опять же мне кажутся сомнительными

VD>Тебе сомнително, а другим нет. Все равно утверждать что под виндовс есть только дотнет и асп не верно.

Не верно, не спорю. Просто есть средства разработки и ПО, которые, де-факто являются стандартом в определеной среде, как то ASP в Win или Apache+php/java в Unix. А все остальное из области экспериментов. Мне так кажется

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

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

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

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

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

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

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

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

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

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

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

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

Я такого не мог сказать. Эффективность никогда не помешает. Вопрос лишь в соотношении полезного выхлопа от достигнутого к цене.

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

M>Большинство пользователей не имеют притензий к скорости настольных приложений, написанных на VB. (.net работает быстрее.)

Обе части этого statement вызывают у меня как у практика серьезные причины для недоверия
к тому что написано дальше.

Особенно вторая часть про VB не далее как вчера мною проверялась в присутствии представителей фирмы производителя.
Задача: типовая морда лица на VB и VB.NET. Последний и рядом не стоял на конкретной задаче.

Для серверных задач с другим патерном раходования памяти managed code кое в чем выигрывает.

Внимание: я ничего не говорю про потребительские качества разаработки managed/unmanaged. Вопрос
сугубо о скорости.

Более того мне лично не известно ни одно успешное коммерческое чисто managed приложение которое
конкурирует с тем же Оффисом. Более того сама фирма производитлеь не выпускает такие приложения.

Я лично принимал участие в качестве архитектора системы близкой по составу функций Оффису
topproducer.com/products/TOPPRODUCER7i/Comp_Features.asp (Java и С++)
и могу сказать что без native code (например модуль WordProcessor) это просто не работает.

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

G><skipped>

<skipped>

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

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

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

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

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

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

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

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

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

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

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

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

Windows 2.0 у меня неплохо одно время поработала на 286-й 17MHzб 2 MB ОЗУ

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

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

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

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

Абсолютно верно для систем класса Бухгалтерия.

Но не забывай о том что вычислительные возможности растут на почве все возврастающих потребностей.
Простой пример: как-то на w3c мы обсуждали проблемы быстродейтсвия броузеров и прочего.
Так вот Борис Збарский (Mozilla) в конце концов признался (и то в частном порядке) что концепция броузера
как thin client (легковесность и быстродействие) никогда в команде не рассматривалась.
Я думаю что все помнят что представляла собой мозила в то время по сравнению с IE.

Еще один пример: cascading style sheets и их computational complexity.

Смотри, для документа с N DOM элементами, M стилями и D — средняя глубина дерерва
задача нахождения стиля для каждого элемента это O( N * M * D ). Могу тебе сказать сразу — без тщательной прорабоки алгоритмов, просто так в лоб эту задачу не решить. Кстати я например использую один трюк который на managed в принципе не реализуем. Но это к слову.

Все дело в том что например 7 лет назад про CSS только говорили хотя стандарту уже как лет 12.
Сейчас используют просто потому что наконец-то появились мощности для этого.

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

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

C GUI пока проблемы. .Net-ные аппликухи демонстрируют заметные минизадержки при открытии окон с большим кол-вом контролов. Тут 2 причины:

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

2. WindowsForms писалась в расчете на STA, однако они перестраховались, и не придумали ничего лучше, как регистрацию КАЖОГО контрола в мапах (HWND handler <==> Control instance) с синхронизацией. Т.е. создание каждого окна виндов сопровождается синхронизацией. Разрушение — аналогично. В нашей проге, когда закрывается окно с большим кол-вом элементов, иногда мелькает белая непрорисованная область окна под ним (последний раз наблюдал нечто такое на каких-нить P100), поэтому мы делаем хитро: сначала гасим окно, потом один раз вызываем Application.DoEvents(), потом только разрушаем погашенное окно. Буквально соседнее аналогичное по насыщенности контролами приложение, написанное на С++, визуально работает молниеносно.

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

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

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

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

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

CS>Абсолютно верно для систем класса Бухгалтерия.

А мы тут что обсуждаем? PD, можно подумать, видел в налоговой инспекции систему, разработанную аутсорсерами из НАСА по заказу марсиан Тоже мне, блин, rocket science, всё там типа заоптимизировано, по уму, везде только блочное чтение...

CS>Но не забывай о том что вычислительные возможности растут на почве все возврастающих потребностей.

Совершенно верно. Отходы, брак, кстати, тоже увеличиваются. Производство как ни как. Ширпотреб.