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

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

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

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

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

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

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

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

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

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

Правильно

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

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

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

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

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

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

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

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. Вот только в плане производительности ты не выиграешь, а проиграешь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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