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

ЕД>.NET это достаточна хорошая солянка.
ЕД>Просто люди психологически боятся переходить на нее, думая что предыдущий
ЕД>опыт все это прошло даром.

Это то я понимаю. Плохо другое — когда вместо истинной причины пытаются обвинить дотнет во всех смертных грехах.

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

ЕД>Ну как это не важна.

Вот так вот. Отработает оно у тебя за секунду или за минуту — никому это не важно.

ЕД>Например рамблер как то одно время постоянно подвисал.

Оно подвисало по иным причинам. ИМХО там больше веб-интерфейс жрал, нежели собственно почтовик. Да и вряд ли там в сервере причина. Скорее всего канал забивали.

ЕД>Или поисковик какой-нить, там я думаю тоже альтернатива только С++.

В поисковиках согласен, по крайней мере в плане создания базы.

ЕД>Ну или например какой-нить мультимедиа сервер который разруливает
ЕД>потоки изображений от охранной системы по охранникам ну и тп.

А здесь вобще специализированные решения нужны.

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

DG>>Какой-то у тебя простенький сервер, если к нему нормально Rational цепляется.
YL>Давай так. Я на это твое сообщение отвечаю, но на другие подобные обращать внимания не буду. Мягко говоря мы уходим от темы в разборки.
YL>Выше я писал какие задачи он решает. Файлов .cpp в нем 2 630 000 byte в 53 файлах. Размер в release 2 834 432 byte.
YL>Я думаю достаточно.

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

Но про 2мб исходников скажу.

ИМХО, 2мб cpp-исходников — это очень мало.
Посмотрел свои старые cpp-ишные исходники, получилось что 2мб исходников примерно равняются 6-ти человеко-месяцам.

Что это за большой сервер, который может написать один человек за шесть месяцев?

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

YL>>Насколько я понял для приложения CLR поддерживает две кучи. Одна для малых объектов, а другая для объектов > 85000.
AVK>Правильно

Если быть точным то их более двух. Если не ошибаюсь четыре. Одна для _pin-нутых объектов. Другая для рефкаунтнотых. Неговоря уже о заморочках с временем жизни (лайфтаймом).

AVK>Затем что эффективные алгоритмы хранения в куче для маленьких и больших объектов разные

Жаль только, что алгоритм для больших объектов программистам из МС так и не покорился. Тормоза жудкие. Похоже, что если бы они оставили все в общей, то было бы лучше. Хотя... В общем на больших объектах старый хип на порядки шустрее.

AVK>Если я правильно понял то в дотнете ты еще новичек. Поэтому подробно объяснить тебе будет сложновато. Вкратце — практически любые попытки вручную управлять памятью приводят либо к резкому падению производительности GC либо к тому что из-за ошибки прикладного кода станет возможна утечка памяти. Первое неприемлемо, ибо попытка повысить производительность приводит к противоположному результату. Второе неприемлемо тоже, потому как на гарантированности уничтожения объектов в любой ситуации построено очень много алгоритмов фреймворка.

Вообще-то это все заморочки именно CLR. В MSIL-е, который является главной составляющей .NET-а, понятия GC нет. Так что на языках плюющих на правила приличия можно делать и свои хипы (неуправляемые CLR). Такими языками являются MC++ и MSIL.

Вот только лучше этго не делать. Так как производительность с маленькими объектами (коих обычно 99%) у CLR очень высока. Главное соблюдать одно правило... не делать у объектов деструктр (финалайзер). Практические эксперементы показывают, что море маленьких объектов не вызывают особых тормозов. Правда перерасход памяти больше чем у класических хипов.

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

YL>Просто в какой-то момент я ее уничтожу и освобожу сразу без лишних затрат выделенную мне память.

Нет идеальных алгоритмов. ЖЦ это правило тоже не нарушил. Одним из его недостатков является то, что нет возможности освободить память. Ну вообще нет! Память считается свободной если на нее нет ссылок. Улавливаешь? Т.е. если ты хочешь грохнуть хип, то это должен быть не ЖЦ-хип.

Можешь взять МС++ и написать нужный себе код. Потом просто использовать его из Шарпа или ВБ. Это будет работать.

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

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

YL>Так вот эти все нюансы и говорят о том что я не смогу создать полноценное серверное приложение, которое работало бы интенсивно с 50-100 пользователями( я не имею в виду вариант web'a запрос — пожалуйста ответ.

Предпосылки какие-то есть... но выводы в корне не верные. Как раз ЖЦ идеальен для серверов.

PS

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

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

AVK>>Вот за попытку управлять руками памятью в серверном софте надо бить железной линейкой по пальцам Я понимаю еще на десктопе что то пооптимайзить, но на сервере! Это ж полный абзац будет если ты не дай бог где ошибешся.

YL>Не надо. Мне ими еще работать.Никакого особого абзаца не случится.

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

YL>Ну закроется у одного из клиентов, т.н. документ(например счет или расх. накладная). Откроет и продолжит работать дальше.

Если "закроется" сервер, то тебя скорее всего по головке не погладят.

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

Ты думаешь это юмор? Умор конечно, то только когда читаешь это в соотвествующем разделе. А вто когда на практике...

YL>А управление памятью как раз и помогает обезопасить других пользователей.

Гы-гы.

YL>А вот оптимизировать сервер необходимо. Время реакции у пользователя должно быть минимальным при любых загрузках

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

90% производительности приложения зависит не от качества хипа, а от качества алгоритмов. ЖЦ — это тоже алгоритм. И давольно так шустрый. Экономь время используя индексы, хэш-таблицы и другие правильные алгоритмы. А управление памяти оставь CLR. Ну или нефига писать на Шарпе. Пиши на плюсах и используй хоть черта лысого.

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

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

Ну не забывай, что на плюсах можно сделать многое. Там есть выделение памяти на стеке. Которое шустрее ЖЦ. И там можно написать алгоритмы класса ЖЦ, но с нужными характиристиками. Так мой QuickHeap делает МС-ый ЖЦ на раз. Но такой же надежности он не обеспечивает. Забыл освободить память — получи лик.

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

AVK>Железка дешевле софта.

Да? За сколько ты продавал свой софт? А вот IBM, HP и Sun продают свои серверы за миллионы баксов. Так что не факт. Только тут предпосылки не вереные. Реальной потери скорости и уж тем более вселенских тормозов не будет.

AVK>Я тут как бы на текущей работе прежде всего как раз такой заказчик а не программер. Так вот — я тебе честно скажу — на тормоза мне плевать, особенно на такие какие будут из за разных механизмов выделения памяти (можешь пообщаться с Владом, он тебе расскажет насколько изменилось быстродействие, когда он вместо стандартного использовал quick heap). А вот если в сервере будут месяцами жить утечки то в лес такой сервер. Если для изменения бизнес-логики мне придется писать код на С++ то тоже в лес такой сервер.

Я еще могу рассказать сколько стоит поиск ликов. И какой это гемарой на С++. Баунд через отдыхает.

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

YL>Не надо только так сильно шуметь. На все эти заявления я могу предложить только одно. Ты демонстрируешь свою систему я свою. Лучше конечно чтобы ты был в Москве. Если нет можно обменяться клиентскими частями. С моей стороны я тебе настраиваю доступ через интернет. Такой пустой разговор я думаю ни к чему не приведет. В данном случае столкнулся твой опыт с моим.

И что ты будешь мерять? Как сравнить совершенно разные системы? Ну давй тогда сравни вот IIS и Quake3. А мы по ржем.

Еще можно соревнуться в скорости получения конечного результата на Шарпе с ЖЦ и на С++ с new/delete. Уверяю тебя зрелище будет забавнейшее.

YL>Ну на это заявление только один вывод. Или незнание или неумение работать с Rational Purify и Rational Quantify.

Гы-гы. Сколько плюсовх строк в вашем проекте? На ниших вся эта фигня падает без обявления войны. Ошибок реальных не показывает. Попроси, к примеру эту хрень отловить COM-овские лики.

Мы вот писали всего лишь библиотеку доступа к данным. Так вот объем кода составил 5 мег приимущественно плюсового кода. Все эти Рэйшенолы и Баундчекеры показывают море фигни в которой можно утануть и в упор не видят настоящих ликов. Пол года убили только на проверки. ЖЦ же — это гарантия от ошибок и 98%-ая защита от утечек.

YL>Мне эти ссылкочки неинтересны по одной простой причине. Пока сам не пощупаю не поверю.

А кто (или что) мешает?

YL>А все очень просто. Беру С++ кусок кода и делаю замеры и NET. Вопросы отпадают.

Тут вопрос как мерять. Если мерять конечное приложение, то обычно время на занятие памяти там составляет 2-3 процента. Что толку оптимизировать не критичный участок? Если мерять именно хипы, то легко создать условия когда .NET будет как проигрывать, так и выигрывать. Например, код:

(С++)

for(i = 0; i < xxx; i++)
{
  Y * py = new Y();
  delete py;
}

Супратив:
(C#)

for(i = 0; i < xxx; i++)
{
  Y y = new Y();
}

Медленнее на порядки. Дон Бокс этот фокус красиво демострировал.

Конечно на плюсах можно создать пул и все встанет на свои места, но все же.

YL>Не хочу бросать камень в огород жабистов, но мне хватает инсталлятора ORACLE написаного на жабе.

Дык! GUI — это конек Явы.

YL>Значит у нас тобой разные сферы применения продукта. У меня заказчикам наплевать на объемы дисков, памяти. А вот скорость — главный критерий

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

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

AVK>Очень странный заказчик. На что ему скорость? Солить что ли? И если ему скорость то накой он вобще с писюками связался?

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

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

YL>Есть у меня такое подозрение что ничего серьезного на NET не написано.

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

AVK>>На твои заявления только один вывод — или незнание или неумение работать с GC платформами.
YL>Ну это на тему — дурак, сам дурак. Skip

Может AVK был груб. Но прав он в одном. Технологию рабобы ЖЦ ты полностью не осознаешь. Это факт.

YL>К сожалению чаще происходят ошибки в логике программы. И там и там шансы равны. А то что отладочные механизмы в NET удобнее никто и не спорит.

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

YL>Дело в том что заказчики, т.е. множественное число. А зачем скорость ? Да очень просто. Чем больше продал — больше заработал. Не всегда PC.

Напомни мне кто больше всех продает финансового софта в этой стране? И что ты думаешь о скоростных характеристиках софта этой изумительной конторы?

YL>За NET наверное будущее. Особенно для разработки сложных, распределенных систем. Но за надежность и удобство приходится платить. И главная плата это скорость работы. И доказывать обратное именно ошибка.
YL>С уважением, Юрий

Ты говоришь все верно... ну почти. Ошибка твоя в преоценке веремени затрачиваемом приложением на работу с памятью. Уверяю тебя что даже в супер-пупер безалаберно написаном приложении доля заемов и освобождений памяти не привышает 15%. К тому же это линейные тормоза. Т.е. предположим что товй софт не оптимально работает с памятью. Это тормозить твой совт на 20%. Значит достаточно купить процессор на 30% быстрее чтобы нивелировать этот тормоз. Основные тормоза програм складываются из не верно примененных алгоритмов и из реверного проектирования.

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

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

YL>Во-первых я хотел бы показать тебе свое, о котором ты кричишь, что это работать не может и через неделю все остановится.

Т.е. ты ему предлагаешь неделю сидить? Или к живой системе с конфиденциальными данными подключишь?

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

IT>Шансы как раз очень не равны. Разработка апп-сервера на C++/COM забирает половину времени на борьбу с последними. К глюкам в логике программы добавляются ещё глюки работы с памятью в C++ и всякие COM'оские заморочки.

IT. Опть же нефига суда ком совать. Достаточно С++. Все проблемы от него. На Шарпе или ВБ (даже 5-6) ком работает замечательно.

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

YL>Смотря что ты понимаешь под глюками. Если утечки памяти, то через Rational они быстро вычищаются, также тяжелые участки кода.

Ты сам то в эти сказки веришь? И кстати, учти что здесь слово Rational ассоциируется в первую очередь с розой, а не с пюрифаем.

YL>О работе пользователя, время отклика на его действия.

А тебе не кажется, что эта скорость зависит в основном от количества полезных действий на вызов? Ведь может статься, что даже вообще забив на освобождение памяти ты потратишь море времени на обычную работу. Ты сравнивал скорость знятия ста тысяч объектов и получения ста тысяч записей из БД?

Еще раз повторяю. Твое предсавление о скоростных характиристиках ложны.

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

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

Самое плохое это налаженки. Например, AV черз трое-пятеро суток работы. Причем если ошибка третьего порядка, и трудно восроизводится, то искать ее просто песня.

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

YL>Выше я писал какие задачи он решает. Файлов .cpp в нем 2 630 000 byte в 53 файлах. Размер в release 2 834 432 byte.

Да мужик. Дохлый пока у вас сервачек. У нас одна библиотечка 5 мег. Но я тебе гарантирую, что рано или поздно вы наедитесь по полной. И будете писать вочдоги перезаускающие серевер. Особо класно если при этом есть море клиентов.

YL>Я думаю достаточно.

В общем, да. Предсказываю тебе твое будущее. Ты постоянно будешь говорить себе: а может все же они правы? И тау же поравляться: да фигня все это! Потом снова... а может... да нет. К тому же это же ломать всю систему... Да не... Не У Нас!!! Потом появится пора когда с разных сторон наваляться проблемы. Ну там новую версию выпустили, полвина заказчиков с дури на нее перелезна... деньжата поджимать стали... нужны новые заказчики... набрали новых... у них новые требования... ну не вести же 20 прараллельных разработок?!?! Ну внесем фичу в общий релиз... ОЙ Ё!!! Лики/AV/тормоза/поча данных (нужное подчеркнуть, ну нужно покоцать). Давай суда пьюрифай!!! Ё Блин! Эта сволочь не может ее поймать! Неужели третьего (или боллее) парядка! Мать перемать!!! Да эта роза паганая глючит сам как...

Ну и в этом духе. Раз 10 переживете, а там вспоминая по начам .NET будешь холодным потом обливаться.

YL>Это да, но это даже нецелесообразно. В моей конфигурации. Одно подключение и работа с документами выявляет все что мне нужно.

До поры до времени. К тому же тут главный вопросЖ за какое время выявляет. С++ и ручное управление памятью (при любом придохранение)... короче см. выше.

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

Ну и зачем их усугублять? ЖЦ при коллекте (который происходит давольно редко) останавливает все потоки. И проблем связанных с потокми и памятью не бывает.

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

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

DG>>>Какой-то у тебя простенький сервер, если к нему нормально Rational цепляется.
YL>>Давай так. Я на это твое сообщение отвечаю, но на другие подобные обращать внимания не буду. Мягко говоря мы уходим от темы в разборки.
YL>>Выше я писал какие задачи он решает. Файлов .cpp в нем 2 630 000 byte в 53 файлах. Размер в release 2 834 432 byte.
YL>>Я думаю достаточно.

Ну все же 2 мега в релизе — это круто для 2.5 мег исходников. У нас проект 5 мег исходников, а инсталятор гдето около двух мег причем там кроме длл-лей еще куча всего напихана. Да и длл-ей штук 10.

DG>ИМХО, 2мб cpp-исходников — это очень мало.

Ну достаточно чтобы опупеть от их чтения. И компилироваться будет минут 7.

DG>Посмотрел свои старые cpp-ишные исходники, получилось что 2мб исходников примерно равняются 6-ти человеко-месяцам.

Крут ты однако. Скока тебе платят?

DG>Что это за большой сервер, который может написать один человек за шесть месяцев?

Не приувеличивай. Все же реально с отладкой это год-два.

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

YL>Rational ближе к Microsoft'у и уже работает с NET.

Rational ближе к IBM-у. http://www.ibm.com/news/us/2002/12/061.html

Да и многие баундчекер ценят выше.

YL>Вот я тут недавно Рихтера купил. И как только ознакомлюсь с этим знаменательным талмудом накропаю более извращенный тест.(Кстати много внимания он уделяет оптимизации кода, заменяя код MS на свой). И представлю публике на обозрение. И наверное буду запускать его уже под Server .NET, а не под beta framework как предыдущие.

Т.е. ты говорил о виртуальных тестах.

YL>Думаю развернется жаркая дискусия.

Она была год назад.

YL>Эх, если бы было так просто.

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

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

YL>Клиент который работает с системой за короткое время может сделать к базе 100 и даже 1000 запросов.
YL>Компания Форс(занимаются поддержкой ORACLE в России) наше пользование БД по другому как извращением не называет.

Ну вот и реальный корень всех проблем! Вот от сюда и вытекают запросы на быстродействие. Не обижайся, но я на 90% уверен, что если малость перепроектировать систему, то число запросов к Ораклу можно бдудет сократить до 1-3, а система начнем летать и через ADO запущенное поверх ODBC.

YL>Думаю что другие БД просто бы не выдержали такой подход. Microsoft SQL слил.

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

YL>Свой язык логики. Свой язык запросов к базе. Свой дизайнер. Обмен через Window Socket.

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

YL>А надо ли переписывать ? А хрен его знает. Может хочется что-то новенького или старею.

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

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

AVK>>Железка дешевле софта.

VD>Да? За сколько ты продавал свой софт? А вот IBM, HP и Sun продают свои серверы за миллионы баксов. Так что не факт.

Софт к таким серверам один хрен стоит в разы дороже самой железки.