Re[17]: Heap в С# - Философия программирования

:???: Здравствуйте!
Насколько я понял для приложения CLR поддерживает две кучи. Одна для малых объектов, а другая для объектов > 85000.
Спрашивается а зачем ? Реализуются механизмы очищения кучи(Несколько потоков делят кучу на участки и обрабатывают ее).
Насколько я понял нет возможности создавать свои кучи(возможно здесь это идеологически не прокатывает).
Но мне лично было бы удобно создать кучу. Наплодить множество объектов и чтобы не напрягать сборщик мусора в конце написать HeapDestroy.
Т.е. мысль в том, что если есть множество клиентов, которые дергают один сервер, происходит интенсивное выделение и освобождение памяти, работать это в .NET врядли будет. Куча будет раздуваться, дефрагментация будет возрастать. В таких условиях сборщик мусора будет надолго затыкать приложение.
Какие у кого есть мысли по этому поводу.

Спасибо, Юрий

31.01.03 15:19: Перенесено модератором из '.NET' — TK

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

Мысль такая, что практика сервеных java — приложений показывает, что вырождение памяти не происходит, в отличие от многих алгоритмов детерминистической финализации.
В принципе, никто не мешает развлечься созданием массива байт требуемого размера, в котором размещать свои данные по известному алгоритму. Например, если известно, что элемнты данных будут уничтожаться только все вместе, то можно организовать стековую архитектуру. Правда, шансов, что все это будет эффективнее GC — мало. Как раз вся прелесть в том, что пока мы пишем приложения, отдельные парни полируют GC. Пользуясь им, мы имеем автоматическое улучшение перформанса при выходе следующего Framework. Самописанные алгоритмы таким ростом не страдают (не говоря о потенциальной глючности).
Говорят, в первых версиях JVM сборщик мусора работал, мягко говоря, неэффективно. Теперь он работает так, что любо-дорого.

YL>Спасибо, Юрий

... << RSDN@Home 1.0 beta 3 >>

То что они полируют GC это конечно хорошо. Но по-моему пока они не дадут программистам самим создавать кучи и удалять их толка не будет. Как бы они алгоритмы сборки мусора не оптимизировали результата не будет. У сам над этим долго бился и пока я не сделал (на С++) у каждого connection'a клиента свой heap проблема была(даже на С++), а что будет на С# я даже знаю точно. А выделение массивами( по крайне мере в моем случае не прокатывает, объекто-ориентированная среда).

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

YL>У сам над этим долго бился и пока я не сделал (на С++) у каждого connection'a клиента свой heap проблема была(даже на С++)
Вообще-то, наши теоретики ООП объяснили мне, что деградация хипа (рост фрагментации памяти) типична для С++ приложений. Именно поэтому их не рекомендуют использовать в сети. GC этому не подвержен, и на современных серверах java рвет С++ как тузик грелку. Там совсем другая специфика. Про GC доказана туева хуча теорем, насчет его поведения в экстремальных случаях. Я сам не теоретик, могу попробовать выжать из наших ссылки в ресурсы про это дело.

... << RSDN@Home 1.0 beta 3 >>

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

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

Правильно

YL>Спрашивается а зачем ?

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

YL>Реализуются механизмы очищения кучи(Несколько потоков делят кучу на участки и обрабатывают ее).
YL>Насколько я понял нет возможности создавать свои кучи(возможно здесь это идеологически не прокатывает).
YL>Но мне лично было бы удобно создать кучу. Наплодить множество объектов и чтобы не напрягать сборщик мусора в конце написать HeapDestroy.
YL>Т.е. мысль в том, что если есть множество клиентов, которые дергают один сервер, происходит интенсивное выделение и освобождение памяти, работать это в .NET врядли будет. Куча будет раздуваться, дефрагментация будет возрастать. В таких условиях сборщик мусора будет надолго затыкать приложение.
YL>Какие у кого есть мысли по этому поводу.

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

S>Говорят, в первых версиях JVM сборщик мусора работал, мягко говоря, неэффективно. Теперь он работает так, что любо-дорого.

Истину глаголят

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

Ты не понял. Я не хочу управлять памятью. Мне хотелось бы иметь механизмы манипулирования кучами памяти. Т.е. я создаю и подсовываю кучу CLR чтобы он создавал объекты именно в ней. И нет проблем если GC будет периодически в ней рыться. Просто в какой-то момент я ее уничтожу и освобожу сразу без лишних затрат выделенную мне память.

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

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

YL>>У сам над этим долго бился и пока я не сделал (на С++) у каждого connection'a клиента свой heap проблема была(даже на С++)
S>Вообще-то, наши теоретики ООП объяснили мне, что деградация хипа (рост фрагментации памяти) типична для С++ приложений. Именно поэтому их не рекомендуют использовать в сети. GC этому не подвержен, и на современных серверах java рвет С++ как тузик грелку. Там совсем другая специфика. Про GC доказана туева хуча теорем, насчет его поведения в экстремальных случаях. Я сам не теоретик, могу попробовать выжать из наших ссылки в ресурсы про это дело.

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

С уважением, Юрий

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

YL>Ты не понял. Я не хочу управлять памятью. Мне хотелось бы иметь механизмы манипулирования кучами памяти. Т.е. я создаю и подсовываю кучу CLR чтобы он создавал объекты именно в ней. И нет проблем если GC будет периодически в ней рыться.

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

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

Не все так просто как кажется.

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

Вот то что надо. Спасибо за пример. Хотя если опять же подойти теоретически к данному вопросу:
есть механизм exception при нулевой ссылке в CLR. Наверное можно было бы обрабатывать такую ситуацию и тут.
Но это я так, мысли вслух.

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

AVK>Не все так просто как кажется.
Наверное. Не спорю.

AVK>PS: Если уж тебе очень хочется отдельную кучу, то у каждого домена куча своя, так что создав домен и создавая объекты в нем ты фактически будешь создавать их в другой куче, под управлением другого GC. Вот только в плане производительности ты не выиграешь, а проиграешь.

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

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

YL>По памяти наверное, но по скорости.... Труба.

Именно по скорости.

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

YL>Вот то что надо. Спасибо за пример. Хотя если опять же подойти теоретически к данному вопросу:
YL>есть механизм exception при нулевой ссылке в CLR. Наверное можно было бы обрабатывать такую ситуацию и тут.
YL>Но это я так, мысли вслух.

Помнишь мой первый пост? Негарантированность корректности ссылок или уничтожения объектов приведет к неприменимости многих алгоритмов фреймворка.

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

Вот за попытку управлять руками памятью в серверном софте надо бить железной линейкой по пальцам

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

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

П.П.С.: Пристрелил бы.

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

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

YL>>По памяти наверное, но по скорости.... Труба.

AVK>Именно по скорости.

Не верю. За счет чего ?

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

AVK>>Именно по скорости.

YL>Не верю. За счет чего ?

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

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

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

МС>П.С.: сам сейчас иногда вынужден разбираться с кодом одного гения, который
МС>уже давно не работает. Какие-то счетчики, ссылки, подсчеты, расчеты...
МС>Более чем уверен, что автор этих идей спустя месяц уже бы сам в них не
МС>разобрался — непоследовательная, бессистемныя реализация сиюминутных
МС>"озарений" — часто противоречащих друг другу.

МС>П.П.С.: Пристрелил бы.

Я тебя прекрасно понимаю. Сам 4 года назад был в такой ситуации. Дело в том что мне не нужно ничего особо оптимизировать. Есть клиент-серверная архитектура, которая уже работает у заказчика. Мне бы хотелось ее перевести на NET. Нет не в тупую, но алгоритмы менять — невозможно. Система просто перестанет функционировать.
И первые прикидки показывают мягко говоря проблематичность переноса. Именно по скоростным характеристикам

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

YL> Есть клиент-серверная архитектура, которая уже работает у заказчика.
YL> Мне бы хотелось ее перевести на NET. Нет не в тупую, но алгоритмы менять —
YL> невозможно. Система просто перестанет функционировать.
YL> И первые прикидки показывают мягко говоря проблематичность переноса.
YL> Именно по скоростным характеристикам

Возможно это так. К сожалению "тяжело" обсуждать эту тему ибо недостаточно
информации об уже существующей системе.
Имеет ли смысл ее переписывать? Какая у нее архитектура. Какие сервера БД
и как используются. Итд Итд Итд

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

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

МС>Возможно это так. К сожалению "тяжело" обсуждать эту тему ибо недостаточно
МС>информации об уже существующей системе.
МС>Имеет ли смысл ее переписывать? Какая у нее архитектура. Какие сервера БД
МС>и как используются. Итд Итд Итд

Если коротко. Многоуровневая архитектура, вытекающая из трехуровневой.
БД- ORACLE. К базе прямой доступ через Call Inerface.Переходники(а-ля ODBC) не используются. Медленные и нет всех возможностей.
Клиент который работает с системой за короткое время может сделать к базе 100 и даже 1000 запросов.
Компания Форс(занимаются поддержкой ORACLE в России) наше пользование БД по другому как извращением не называет.
Думаю что другие БД просто бы не выдержали такой подход. Microsoft SQL слил.
Свой язык логики. Свой язык запросов к базе. Свой дизайнер. Обмен через Window Socket.
А надо ли переписывать ? А хрен его знает. Может хочется что-то новенького или старею.

YL> Думаю что другие БД просто бы не выдержали такой подход.
YL> Свой язык логики. Свой язык запросов к базе. Свой дизайнер.
YL> Обмен через Window Socket.
YL> А надо ли переписывать ? А хрен его знает.

После "беглого" ознакомления с этой краткой информацией мое ИМХО, что
ничего сделать с этой системой не получится, тем более силами одного
человека. Перевод ее на .NET — это отдельный большой проект.
Как мне кажется единственная возможность попользовать .NET в
этой ситуации это выделить какое-то подмножество запросов
клиентского приложения и форвардить их на .NET (NewTechnology

)
сервер, потом возвращать клиенту. Изврат конечно, но другого
способа поиграться в .NET в данной ситуации не вижу.

YL> Может хочется что-то новенького или старею.

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

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

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

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

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

Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

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

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

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

: приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

МС>Понимаю. Сам сейчас сижу с готовой системой писанной давным давно на плюсах.
МС>Угнетает. Хочется "большого и светлого". Приходится урывать часы на работе
МС>и тратить домашнее время для занятия любимым делом.

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

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

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

A>А всем хорошо известно, что никакая техника выделения памяти в
A>хипе не сравнится по скорости со стеком.

эта еще почему?

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

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

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

A>>А всем хорошо известно, что никакая техника выделения памяти в
A>>хипе не сравнится по скорости со стеком.

МС>эта еще почему?

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

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

A>>>А всем хорошо известно, что никакая техника выделения памяти в
A>>>хипе не сравнится по скорости со стеком.

МС>>эта еще почему?

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

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

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

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

A>>>>А всем хорошо известно, что никакая техника выделения памяти в
A>>>>хипе не сравнится по скорости со стеком.

МС>>>эта еще почему?

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

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

Да, идея выделения памяти в .NET такая. Но никто не говорит, что реализация также проста. А освобождение памяти в .NET вообще очень далеко от тривиальности.

A> Да, идея выделения памяти в .NET такая.
A> Но никто не говорит, что реализация также проста.
A> А освобождение памяти в .NET вообще очень далеко от тривиальности.

Изначально речь шла о выделении памяти в хипе и в стеке.
Про реализацию ничего говорить не буду так как не знаю,
но: 1. над этими вещами работают не дураки, 2. механизмы
вне всякого сомнения будут совершенствоваться, 3. мощностя
камней растут как на дрожжах.

Отступая от темы производительности хипА:
Очень важный момент состоит в том, что если речь не идет о
драйверах, кодеках и т.п. пиковая производительность некоторого
участка кода не является критичной. С современными мощностями
и объемами оверхед на проведение некоторых действий
(тем более таких важных как корректное управление памятью)
вполне допустим.
Рулезы, которые предлагает .NET настолько повышают
другие показатели такие как: надежность, скорость разработки,
легкость развертывания, простота развития итд, что с некоторой
потерей производительности по сравнению с "идеальной системой,
написаной идеальным программистом на плюсах или ассемблере" можно
вполне смириться.
Если объемы данных/количество операций велико, то можно сделать
вывод, что фирма может поставить на сервер лишний гиг памяти или
дополнительный процессор.
Кроме того сейчас очень "модно" тащить все в память, например,
восстанавливать объекты БД и хранить их на протяжении всего жизненного
цикла приложения в памяти. Подобные подходы могут посадить все что
угодно и .NET, и C++, и все остальное (всегда есть объем с которым
не справится система).
При правильном подходе многих проблем с производительностью может
не возникать и на более медленных чем .NET вещах. Не даром в какой-то
статье разработчика из MS (помоему про X#) подчеркивалось, что сейчас
программисты слишком злоупотребляют объектно-ориентированным
подходом применяя его подчас где он совершенно не нужен, так для
обработки данных очень часто не нужно их объектного представления в памяти.

Все пора прекращать флейм, а то модератор сейчас пристрелит...

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

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

Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.

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

Какую то ты ерунду говоришь. Ручное управление памятью никогда ни к чему хорошему не приведет. Каким образом это обезопасит пользователей мне непонятно. Или ты хочешь на каждого пользователя свой хип? Ну так тогда домены приложений это именно то что нужно. В домене ты изолируешь и обезопасишь не только память.

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

A>Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

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

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

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

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

Хинт: value типы создаются в стеке.

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

: приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

AVK>>Именно по скорости.

YL>Не верю. За счет чего ?

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

A>>Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

AVK>Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

В теории. На практике же проблеммы фрагментации не так страшны, как их малюют, а GC не такой эффективный.

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

AVK>Не надо к нему привыкать — явно кривота в приложении. Во первых — по моим экспериментам сам по себе GC запускается очень неохотно. Во вторых я видел EJB сервера с тем же GC под немаленькой нагрузкой — никакого постоянного запуска сборщика не наблюдалось. Видимо в этом приложении по поводу и без него ручками постоянно вызывается GC.Collect()

Не правильно. Никаких GC.Collect() там и в помине не было.

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

AVK>Хинт: value типы создаются в стеке.

Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

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

: приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

AVK>Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

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

Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

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

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

У меня апп-сервера дышат ровно и вообще пышут здоровьем (тьфу-тьфу-тьфу-три-раза)

С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

AVK>>Хинт: value типы создаются в стеке.

A>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

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

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

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

A>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

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

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

AVK>>Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

A>В теории. На практике же проблеммы фрагментации не так страшны, как их малюют, а GC не такой эффективный.

Нормальный GC, проверено как раз на практике. По крайней мере страшных тормозов при огромном количестве мелких объектов , как это бывало в обычном хипе, нет.

A>Не правильно. Никаких GC.Collect() там и в помине не было.

Тогда не понимаю почему там GC работал постоянно. Может памяти совсем мало было?

A>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

Ага, а в СОМ ты стринг на стеке сможешь передать?

AVK>>Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

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

Позволь узнать — ты какого размера документы туда грузил? Загрузи мег на 15 — вот после этого и сравнивай. Хотя конечно расход у GC памяти повышенный, это давно известно. Плата за удобство.

A>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

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

... << RSDN@Home 1.0 beta 5 (developer build)>>

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

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

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

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

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

С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

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

AVK>>>Хинт: value типы создаются в стеке.

A>>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

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

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

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

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

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

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

A>>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

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

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

AVK>Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.
1.Практика показывает обратное. Ты сильно сгущаешь краски.
2. Rational Rose написали отличные ребята( это я об утечках памяти).

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

AVK>Какую то ты ерунду говоришь. Ручное управление памятью никогда ни к чему хорошему не приведет. Каким образом это обезопасит пользователей мне непонятно. Или ты хочешь на каждого пользователя свой хип? Ну так тогда домены приложений это именно то что нужно. В домене ты изолируешь и обезопасишь не только память.

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

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

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

Да делал уже. На С++ и С#. Для NETa последствия хреновые. Это говорит о том, что писать на NET сервер приложения нецелесобразно. Да это будет надежно, можно быстро локализовывать ошибки, но это будет вселенский тормоз.
Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.
С уважением, Юрий

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

AVK>>Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.
YL>1.Практика показывает обратное. Ты сильно сгущаешь краски.

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

YL>2. Rational Rose написали отличные ребята( это я об утечках памяти).

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

YL>Правильно, но не совсем. Не на пользователя а на соединение на сервере приложения. И когда пользователь закрывает соединение разрушается heap. Т.е. никаких утечек не происходит !!!

Тогда домен самое оно. Заодно можно исключить выполнение привилегированного кода пользователем.

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

YL>Да делал уже. На С++ и С#. Для NETa последствия хреновые.

У меня почему то картинка обратная (да не только у меня, IT тебе ссылочку привел)

YL>Это говорит о том, что писать на NET сервер приложения нецелесобразно.

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

YL> Да это будет надежно, можно быстро локализовывать ошибки, но это будет вселенский тормоз.

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

YL>Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.

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

... << RSDN@Home 1.0 beta 5 (developer build)>>

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

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

а можно по подробнее что за глюки такие (извините за отступ от темы)

AVK>Вот как раз практика и показывает что писание серверов для большого кол-ва пользователей (>100) на языках с ручным выделением памяти это полный писец. Не знал не говорил бы. Утекло где нить пару десятков байт, а потом через неделю продакшн сервер встал. А тестовый работает и не глючит.

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

YL>>2. Rational Rose написали отличные ребята( это я об утечках памяти).

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

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

YL>>Правильно, но не совсем. Не на пользователя а на соединение на сервере приложения. И когда пользователь закрывает соединение разрушается heap. Т.е. никаких утечек не происходит !!!

AVK>Тогда домен самое оно. Заодно можно исключить выполнение привилегированного кода пользователем.

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

YL>>Да делал уже. На С++ и С#. Для NETa последствия хреновые.

AVK>У меня почему то картинка обратная (да не только у меня, IT тебе ссылочку привел)

Мне эти ссылкочки неинтересны по одной простой причине. Пока сам не пощупаю не поверю.
А все очень просто. Беру С++ кусок кода и делаю замеры и NET. Вопросы отпадают.
YL>>Это говорит о том, что писать на NET сервер приложения нецелесобразно.

AVK>Именно для серверов приложений дотнет прежде всего и делался. Сейчас в мире тяжелые сервера пишут как правило на джаве.
Не хочу бросать камень в огород жабистов, но мне хватает инсталлятора ORACLE написаного на жабе.
YL>> Да это будет надежно, можно быстро локализовывать ошибки, но это будет вселенский тормоз.

AVK>Железка дешевле софта.
Вроде windows платформа вроде еще не работает на mainfram'ах. штучек так 200(может конечно ошибаюсь, особо не слежу)

YL>>Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.

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

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

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

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

Глупость ты полную предлагаешь. Чего ты сравнивать собрался? Неизвестно какой сервер с неизвестно каким? Чего еще?

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

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

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

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

Тогда чего здесь флейм разводить? Пощупай, а не спрашивай здесь. Или тебе поспорить хочется?

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

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

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

Там проблемы с симантековской JVM, а не с джавой.

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

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

... << RSDN@Home 1.0 beta 5 (developer build)>>

AVK>Глупость ты полную предлагаешь. Чего ты сравнивать собрался? Неизвестно какой сервер с неизвестно каким? Чего еще?
А я тебе не сравнивать предлагаю. Во-первых я хотел бы показать тебе свое, о котором ты кричишь, что это работать не может и через неделю все остановится.
А во-вторых хотелось бы посмотреть на твое изобретение на платформе NET и какие задачи оно решает. Или я многого хочу ?
Есть у меня такое подозрение что ничего серьезного на NET не написано.
YL>>Ну на это заявление только один вывод. Или незнание или неумение работать с Rational Purify и Rational Quantify.

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

AVK>В общем доказывать свою правоту у меня нет никакого желания. Ты спросил — тебе ответили. Не веришь — твое право. А пиписьками меряться я не буду.

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

AVK>Тогда чего здесь флейм разводить? Пощупай, а не спрашивай здесь. Или тебе поспорить хочется?

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

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

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

AVK>Очень странный заказчик. На что ему скорость? Солить что ли? И если ему скорость то накой он вобще с писюками связался?
Дело в том что заказчики, т.е. множественное число. А зачем скорость ? Да очень просто. Чем больше продал — больше заработал. Не всегда PC.

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

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

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

Звиняй, но не сейчас. Со временем совсем абзац.

YL>А во-вторых хотелось бы посмотреть на твое изобретение на платформе NET и какие задачи оно решает. Или я многого хочу ?

Сервер на нете? На нете у меня нет того что можно показать. Есть на джаве, то его больно муторно разворачивать.

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

В плане серверов? Нет конечно — времени совсем мало прошло. Впрочем тут тебе лучше с IT пообщаться — он у себя что то под дотнет переписал. Да, rsdn.ru тоже на нете писат. Или это по твоему несерьезно?

AVK>>Очень странный заказчик. На что ему скорость? Солить что ли? И если ему скорость то накой он вобще с писюками связался?
YL>Дело в том что заказчики, т.е. множественное число. А зачем скорость ? Да очень просто. Чем больше продал — больше заработал. Не всегда PC.

Ты полагаешь что объем продаж зависит от скорости работы сервера приложений?

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

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

... << RSDN@Home 1.0 beta 5 (developer build)>>

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

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

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

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

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

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

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

С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MS>а можно по подробнее что за глюки такие (извините за отступ от темы)

При интенсивном использовании регексов просиходит утечка. Видимо где-то остаются ссылки на отработанные объекты. Проблема была решена тотальным выносом всех Regex объектов в статические переменные.

ЗЫ. Интересно, починили ли это в новом фреймворке?

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

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

А зачем?

У меня BoundChecker уже полгода просит лицензию обновить, да мне всё лень админа попрость, т.к. нафиг не надо.

AVK>>У меня почему то картинка обратная (да не только у меня, IT тебе ссылочку привел)

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

А можно твои тесты в студию, а то может мы там чего откопаем?

YL>>>Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.

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

Так воткни ещё пару процессоров в каждый сервер и будет тебе и заказчику счастье.

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

AVK>>Я вот тоже — беру кусок кода и делаю замеры. Только я еще мерю время, потраченное на отладку и доработку.
YL>К сожалению чаще происходят ошибки в логике программы. И там и там шансы равны.

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

AVK>>Очень странный заказчик. На что ему скорость? Солить что ли? И если ему скорость то накой он вобще с писюками связался?
YL>Дело в том что заказчики, т.е. множественное число. А зачем скорость ? Да очень просто. Чем больше продал — больше заработал. Не всегда PC.

Ты говоришь о скорости чего?

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

А что делать

IT>GC такие аппетиты даже и не снились.

А у GC аппетиты тоже не слабые, я бы так сказал.

Я думаю тут разница в подходах
МС позиционирует новую среду как среду которая избавляет
программистов от необхоимости лезть в системные дела,
заниматься разработкой КвикХеапов и прочего, но он не
говрит между прочим, что GC самый быстрый способ работать с памятью.
Не думаю я, например, что следующее поколение МС СКЛ сервера будет использовать
GC. наверняка напишут или возьмут нечто подобное QH.

Поэтому думаю, что GC по сравнению со средствами типа QH написанных на С++
никогда не выиграет по скорости.

В задачах бизнес логики GC удобнее так как все равно обработка СКЛ запроса
есть 90%(а то и более) всего времени работы объекта.

IT>А зачем? :xz: У меня BoundChecker уже полгода просит лицензию обновить, да мне всё лень админа попрость, т.к. нафиг не надо.
Речь не о том шла чем пользоваться.Знания конечто великая вещь. Но как пел один товарищ. "Кто-то любит шприц, кто-то любит взад". По мне неважно каким продуктом ты пользуешься. Главное чтоб было удобно. Rational ближе к Microsoft'у и уже работает с NET.

AVK>>>У меня почему то картинка обратная (да не только у меня, IT тебе ссылочку привел)

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

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

IT>:)))

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

IT>Так воткни ещё пару процессоров в каждый сервер и будет тебе и заказчику счастье.
Эх, если бы было так просто.

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

ЕД>Поэтому думаю, что GC по сравнению со средствами типа QH написанных на С++
ЕД>никогда не выиграет по скорости.

Мужики, меня вот удивляет почему вы хотите доказать что дотнет полный ацтой? Есть у GC недостатки, никто не спорит. Вот только не нужно говорить что он не нужен или не годится почти везде.

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

IT>Ты говоришь о скорости чего?
О работе пользователя, время отклика на его действия.

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

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

ЕД>>Поэтому думаю, что GC по сравнению со средствами типа QH написанных на С++
ЕД>>никогда не выиграет по скорости.

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

Я не доказываю что это ацтой,
даже больше наоборот.
Например я только под него код и пишу
бизнес логика и ГУИ на С#
веб интерфейс на АСП.НЕТ и мне это нравится
и производительность устравивает
я же и говрю что для написания простых апп серверов(простота в смысле уровня программирования)
.НЕТ идеальна. собственно про это и говрю и МС говрит тоже самое

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

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

IT>>А зачем?

У меня BoundChecker уже полгода просит лицензию обновить, да мне всё лень админа попрость, т.к. нафиг не надо.
YL>Речь не о том шла чем пользоваться.Знания конечто великая вещь. Но как пел один товарищ. "Кто-то любит шприц, кто-то любит взад". По мне неважно каким продуктом ты пользуешься. Главное чтоб было удобно. Rational ближе к Microsoft'у и уже работает с NET.

Обрати внимание на выделенное

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

Так, мы оказывается тесты под бетой пускали

С этого и надо было начинать.

IT>>Так воткни ещё пару процессоров в каждый сервер и будет тебе и заказчику счастье.
YL>Эх, если бы было так просто.

Для решения проблем с GC этого достаточно

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

Какой-то у тебя простенький сервер, если к нему нормально Rational цепляется.

Тут уже это где-то говорилось, но еще раз повторю.

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

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

... << RSDN@Home 1.0 beta 3 >>

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

ЕД>Я не доказываю что это ацтой,
ЕД>даже больше наоборот.

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

.

ЕД>я же и говрю что для написания простых апп серверов(простота в смысле уровня программирования)
ЕД>.НЕТ идеальна. собственно про это и говрю и МС говрит тоже самое

А для сложных тем более.

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

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

ЕД>Так как не может быть одна вещь на все случаи жизни, это ведь не ВП.

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

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

ЕД>А что делать

А кому щас легко?

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

А этого никто и не говорит. Некоторые говорят как раз наоборот, что это самый тормозной вариаент у которого шансов нет.

ЕД>Не думаю я, например, что следующее поколение МС СКЛ сервера будет использовать GC. наверняка напишут или возьмут нечто подобное QH.

В следующем поколении MS SQL .NET будет использоваться совместно с T-SQL. И это возможно только благодаря тому, что программы работающие в CLR безопасные по определению. Т.е. убить сервер одним неверным движением ты просто не в состоянии.

ЕД>Поэтому думаю, что GC по сравнению со средствами типа QH написанных на С++ никогда не выиграет по скорости.

QH — это очень частное решение. Думаю, что как раз MS SQL на 101% состоит из таких частных решений. Это продукт, над которым годами работают одни и те же люди. На Привете ребята из SQL team как-то рассказывали почему они не используют stl, но это совсем не значит, что stl теперь вообще никому использовать не стоит.

ЕД>В задачах бизнес логики GC удобнее так как все равно обработка СКЛ запроса есть 90%(а то и более) всего времени работы объекта.

Ну наконец-то. Ну вот и славненько

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

.

Дык я и не воспринимаю

Знаю что ты лирик

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

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

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

Например рамблер как то одно время постоянно подвисал.
Или поисковик какой-нить, там я думаю тоже альтернатива только С++.
Ну или например какой-нить мультимедиа сервер который разруливает
потоки изображений от охранной системы по охранникам ну и тп.

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

Сложной логикой в плане бизнес логики(там собственно не логика сложна, а запросы

). Так вот сам сервер,
который обрабатывает столь сложную логику(сервера БД) они ведь не используют GC.
Думаю там что-то свое.

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 3 >>

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

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

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

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

Жаль только, что алгоритм для больших объектов программистам из МС так и не покорился.

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

Нет идеальных алгоритмов. ЖЦ это правило тоже не нарушил.

Одним из его недостатков является то, что нет возможности освободить память.

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

PS

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

... << RSDN@Home 1.0 beta 4 >>

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

AVK>>Вот за попытку управлять руками памятью в серверном софте надо бить железной линейкой по пальцам

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

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

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

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

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

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

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

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

Гы-гы.

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

Но такой же надежности он не обеспечивает. Забыл освободить память — получи лик.

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

Еще можно соревнуться в скорости получения конечного результата на Шарпе с ЖЦ и на С++ с 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>Значит у нас тобой разные сферы применения продукта. У меня заказчикам наплевать на объемы дисков, памяти. А вот скорость — главный критерий

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

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

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

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

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

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

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

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

Людям важна функциональность.

... << RSDN@Home 1.0 beta 4 >>

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

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

Т.е. ты ему предлагаешь неделю сидить?

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

... << RSDN@Home 1.0 beta 4 >>

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

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

IT. Опть же нефига суда ком совать. Достаточно С++. Все проблемы от него.

На Шарпе или ВБ (даже 5-6) ком работает замечательно.

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

Да мужик. Дохлый пока у вас сервачек.

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

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

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

Эта сволочь не может ее поймать! Неужели третьего (или боллее) парядка! Мать перемать!!! Да эта роза паганая глючит сам как...

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

Здравствуйте, 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>Что это за большой сервер, который может написать один человек за шесть месяцев?

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

... << RSDN@Home 1.0 beta 4 >>

Здравствуйте, 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>Эх, если бы было так просто.

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

Ты мерил?

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

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

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

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

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

: приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

Здравствуйте, 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 тоже возможны. Интересно узнать, а как вы все-таки обнаружили причину?

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

... << RSDN@Home 1.0 beta 4 >>

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

... << RSDN@Home 1.0 beta 4 >>

Здравствуйте, 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-проект для предприятия, которому не хватает писюковых серверов где то под лимон.

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

VD>Жаль только, что алгоритм для больших объектов программистам из МС так и не покорился.

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

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

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

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

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

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

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

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

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

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

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

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

VD>Крут ты однако.

Скока тебе платят?

по моим меркам мало, но я работаю над этим

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

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

2мб исходников?

я же не зря написал 6 человеко-месяцев.

Реальная картина, это 3 человека пищищуе такой за 2 месяца, и еще 1 месяц отладки, итого 3 месяца.

При программировании на cpp, 3 месяца это очень маленький срок, реальный срок больших проектов — 1г и больше

... << RSDN@Home 1.0 beta 3 >>

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

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

Похоже, рыдая, ты пропустил самое интересное:

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

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

YL>Я своим ребятам показал — они уже стоять не могут.

Хорошо смеётся тот, кто сам знаешь когда смеётся

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

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

Так что послушай его лучше, он дело говорит.

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

Не могу не встрять. Была у нас как-то задача почту рассылать — извещения подписчикам.
Сначала все через outgoing smtp от провайдера начали валить. Он нас быстро послал, типа — спамеры мы. Поставили свой. Не помню щас, как оно называлось, но штука серъезная — native Win-Api, $1000 за лицензию... Рекламы про него — и умнный, и быстрый, и все дела... Более 200000 писем в сутки он разослать не мог. Увы. Написали свой на жабе. Использовал MS SQL для хранения исходящей очереди. На том же железе и всем таком выплевывал более миллиона писем в сутки. И это был не предел — явственно просматривались возможности по оптимизации. Правда потрахаться с ним пришлось — дай бог.

... << RSDN@Home 1.0 beta 5 >>

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

S>Увы. Написали свой на жабе. Использовал MS SQL для хранения исходящей очереди. На том же железе и всем таком выплевывал более миллиона писем в сутки. И это был не предел — явственно просматривались возможности по оптимизации. Правда потрахаться с ним пришлось — дай бог.

Так о том и речь. Определенные особенности GC позволяют делать сервера как минимум не медленнее нативных.

... << RSDN@Home 1.0 beta 5 (np: тихо) >>

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

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

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

Падает, но на каких цифрах? Там же написано, при таких размерах и при таком количестве объектов лучше сразу обращаться к доктору. Сам подумай, что такое объект в один килобайт.

A>Вообще-то, этот тест много подозрений вызывает. Почему GC.Collect() явно вызывается?

В конце теста? Это что-бы хоть как-то уровнять шансы C++. Если GC.Collect() в конце не вызывать, то по завершении программы она и вызываться не будет, так как это ни к чему. Будут только вызваны деструкторы объектов, которые находяться в отдельной колекции и всё.

A>Почему объекты не связываются друг с другом, как это просходит в реальных программах, и где GC приходится раскручивать ссылки?

Почему не связаны? Есть большой массив, который содержит объекты, которые содержат массивы и объекты, которые содержат массив. Массив в CLR между прочим тоже объект. К тому же структура объектов усложнялась по всякому, на результаты практически не влияет ни в C++ ни в GC.

A>Почему выделение памяти с помощью Win32 функций быстрее, чем с помощью new?

Потому что, MSVC'шная куча работает через Win32 функции.

A>Почему QH работает так подозрительно быстро: не реализуется ли здесь какой-то вырожденный случай?

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

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

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

Я же уже говорил, дышит ровно, пышит здоровьем, тьфу-тьфу-тьфу-три-раза. Правда там по два процессора стоит и памяти по гигу, может в этом всё дело

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

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

Значит не загружал?

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

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

Нет, если не считать Task Manager средством отладки. А так только с помощью дедуктивного метода и какой-то матери.

	От:	YuraL
	Дата:	28.01.03 15:19
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	28.01.03 15:29
Оценка:

	От:	YuraL
	Дата:	28.01.03 15:44
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	28.01.03 16:59
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	28.01.03 18:04
Оценка:

От:	MikaRSDN Soukhov	Stock#
Дата:	30.01.03 08:40
Оценка:

От:	IT	linq2db.com
Дата:	30.01.03 14:24
Оценка:	3 (1)

	От:	Ерусов Дмитрий
	Дата:	30.01.03 14:46
	Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	30.01.03 15:26
Оценка:

От:	VladD2	www.nemerle.org
Дата:	31.01.03 02:49
Оценка:

	От:	МихаилС
	Дата:	29.01.03 08:20
	Оценка:

	От:	МихаилС
	Дата:	29.01.03 08:32
	Оценка:

	От:	МихаилС
	Дата:	29.01.03 08:55
	Оценка:

	От:	МихаилС
	Дата:	29.01.03 09:05
	Оценка: