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

YL>Я конечно не один. А насчет угнетает и.т.д. это точно. Задолбало уже оптимизировать, улучшать и баги подчищать.


Это будет всегда. Вопрос только в объемах работ.

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

YL>Насколько я понял рвет он только по работе с памятью если присутствует одна большая куча ?
YL>Ну тогда это не показатель. По моему мнению плюсы будут всегда быстрее этих языков(java, C#).

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

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

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

Опять таки если не химичить. Он же тебе ясно говорит, что он память вообще не освобождает. Я так понимаю у его классов или вообще нет деструкторов, или оператор делит ничерта не делает. А грохается весь хип. Эта операция очень быстрая.

Вот только в программе еще опирации есть. И тромоза в его программе вовсе не от памяти. А от 100 запросов к Ораклу.

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

A>А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

Ты мерил?

A>Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

Это не файкт, а скорее нонсенс. Или плохо спроектированное приложение или откровенно глючащае.

A>Еше одна мысль. В C++ объекты не обязательно в хипе создавать, можно и на стеке. В .NET же, выбора особенно нет. А всем хорошо известно, что никакая техника выделения памяти в хипе не сравнится по скорости со стеком.

На то есть вэбю-типы.

A>Еще один момент есть в GC. Когда памяти становится мало, и даже основная часть памяти выгружена в page file, GC может захотеть "проверить" всю память (и причем это может происходить периодически), что приведет к постоянному swapping'y. Я это тоже видел : приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

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

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

A>Я запускал Word XP, ограничив его Working Set до 5MB — работает безо всяких тормозов. А с янусом такое можно сделать?

Запусти ограничив его мегом. Или загрузи в него файл на 600 кил. Обещаю незабываемые ощущения.

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

IT>Лидер (QH) — это как раз тот самый случай ручной оптимизации хипа на C++. Только вопрос какой ценой даётся это лидерство.

Да, да. Нделю трахался.

Кстати, на реальном приложение (использующем смарт-массивы и другие фичи) выигрыщь 2-15%. Т.е. не очень серьезный.

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

A>Печальный тест для GC. QuickHeap — это, кстати, то, что очень легко получается. Такие наработки уже есть и в большом количестве.

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

A>Ради экперемента понаблюдай за perf counter, который показывает время проведенное в GC, при нагруженном сервере.

Ты еще ради интереса посмоти время проведенное в идле. Тебя поразит, что оно самое большое, хотя вроде сервер загружен на 100%.

A>А почему бы и нет. std::string между прочем для маленьких строк в хипе память не выделяет.

Аго. Жаль только проигрывает CString-у постоянно.

A>Дело не в конкретных классах, а в возможности.

Ну а кто мешает узкое место написать на плюсах? Или из-за 0.1% кода ты будешь мучиться всю жизнь?

A>Сам Word при этом отнимал 20MB, 15 из которых были в page файле.

Ну а ты загрузи все же 600 килобайтных файл и сделай по нему замену контекстную. А то так и Хоум загрузится. ЖЦ дергается ой как редко если память выделяется.

A>Хороший пример: memory leaks в .NET тоже возможны. Интересно узнать, а как вы все-таки обнаружили причину?

Вообще-то есть специальные программки, но можно и на глаз. Главное что количество таких ошибок несравнимо меньще.

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

С нашим будраном другая проблема. Он больше не летает.

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

МС>Читайте того же Рихтера. В CLR managed heap работает так же как стек.
МС>Есть указатель на границу памяти и меняется только он.

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

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

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

Откуда ты взял эту чушь?

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

AVK>За счет того что он как правило вобще не освобождает ничего сразу.

Да и занимает в разы быстрее. Особенно если классический хип сильно фрагментрирован. ЖЦ же по поределению не может быть фрагментирован.

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

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

Ты позги не компостируй. Если твой софт стоит 100 килобаксов, то покупая для него технику в 101 килобакс ты платишь за железо больше.

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

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

VD>Ты позги не компостируй. Если твой софт стоит 100 килобаксов, то покупая для него технику в 101 килобакс ты платишь за железо больше.

А ты покупал? А я (моя контора) покупал эти грёбаные саны. Саны стоят ~250k, а софт к ним ~1.25M. А дерьмецо ещё то, всё древнее, плесенью покрылось, с трудом оттуда выудили хоть кое-какой XML

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

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

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

IT>>>Обрати внимание на первую половину графика, выигрыш GC в 3-4 раза. Лидер (QH) — это как раз тот самый случай ручной оптимизации хипа на C++. Только вопрос какой ценой даётся это лидерство.

A>>Печальный тест для GC.

IT>Что печально? То что C++ с Win32 хипом курят?

То, что производительность GC спадает так резко.

Вообще-то, этот тест много подозрений вызывает. Почему GC.Collect() явно вызывается? Почему объекты не связываются друг с другом, как это просходит в реальных программах, и где GC приходится раскручивать ссылки? Почему выделение памяти с помощью Win32 функций быстрее, чем с помощью new? Почему QH работает так подозрительно быстро: не реализуется ли здесь какой-то вырожденный случай?

A>>QuickHeap — это, кстати, то, что очень легко получается. Такие наработки уже есть и в большом количестве.

IT>Это легко получается в однозадачной среде, в ДОСе я и сам таким страдал. В многозадачной среде захватывать всю возможную память слишком расточительно, GC такие аппетиты даже и не снились.

IT>>>У меня апп-сервера дышат ровно и вообще пышут здоровьем (тьфу-тьфу-тьфу-три-раза) С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

A>>Ради экперемента понаблюдай за perf counter, который показывает время проведенное в GC, при нагруженном сервере.

IT>Наблюдал, ничего криминального не заметил

А что заметил? Какое поведение?

IT>>>И CString тоже на стеке, и std::string?

A>>А почему бы и нет. std::string между прочем для маленьких строк в хипе память не выделяет.

IT>А где он её выделяет? В стеке? А для совсем маленьких наверное прямо в регистрах

ROTLF

IT>>>А документ какой-нибудь ты в него загружал?

A>>Сам Word при этом отнимал 20MB, 15 из которых были в page файле.

IT>Так ты с документом пробовал работать или нет?

Издеваешься?

IT>>>Проблема у GC одна — если ты забъёшь память неиспользуемыми объектами, на которые где-то болтаются ссылки (впрочем, проблема будет не только у GC). Подобные глюки были замечены. Например на нашем сайте. ASP.NET одно время периодически перегружалась после того как пожирала неимоверное количество памяти. Оказалось, что это из-за глюка в Regex'ах. По всей видимости, где-то оставались ссылки на отработанные объекты. После соответствующей модификации кода глюки исчезли.

A>>Хороший пример: memory leaks в .NET тоже возможны.

IT>Это явный глюк. Помнишь как несколько бакспейсов, используемых в printf из ms'овской ctrl убивали любую винду наповал? Что мне теперь утверждать, что C++ вообще ацтой? Глюк, он и есть глюк.

A>>Интересно узнать, а как вы все-таки обнаружили причину?

IT>Форматирование сообщений на RSDN сделано полностью на регексах. На одно сообщение их вызывается примерно до сотни, при раскраске кода используются монстры по нескольку десятков кб. При нашей нагрузке всё стало заметно очень быстро.

Какие-нибудь средства отладки использовали?

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

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

Во первых даже начиная с AS400 там в комплекте софта уже дочерта. В приведенном примере OS/400, DB2 и куча мелочи. Во вторых софт под такие машинки тоже стоит совсем другие деньги. Даже в России типичный ERP-проект для предприятия, которому не хватает писюковых серверов где то под лимон.

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

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

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

Так он сам сначала розу поминал, а потом уж на пьюрифай переключился.

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

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

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

Быстрые на один процессор. Но как только речь заходит о SMP то все становится печально. 2 процессора еще туда-сюда, 4 уже много хуже, на 16 добавление новых уже ничего не дает — шина памяти забита под завязку. Я то не про процессоры а про машинки. В общем для 1-2 процессоров может и быстрее, а вот дальше все плохо. Всякие там NUMA на писюковых камнях это уже точно не писюки.

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

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

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

Там не в гуях дело, а в кривоте симантековской машины.

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

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

Лайфтайм работает поверх GC — это высокоуровневая фишка.

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

Видать скорее всего что то с дефрагментацией намудрили. Других причин торможения именно на больших объемах я не вижу.

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

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

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

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

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

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

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

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

Вот только в программе еще опирации есть. И тромоза в его программе вовсе не от памяти. А от 100 запросов к Ораклу.
/////////////////////////////////////////////////////////////////////////////////////

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