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

M>>Большая часть "выделения-освобождения памяти" на С++ не затрачивает никаких ресурсов, как может быть быстрее ?
G>
G>Да ну?
G>Вым наверное стоит изучить как аллокаторы и GC работают.

А вам, что такое "автоматическая переменная" в C++

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

H>>Ты этой ссылкой только подтверждаешь мой тезис о том, что инфраструктура управления памятью в .Net более требовательна к оной
G>Офигеть, дайте две, а причем тут перформанс?

H>>Из заключения:
H>>

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

G>Ключевое выделил.

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

H>>Ну и про отрицательное влияние на перформанс тоже сказано... не смотря на все оптимизации.
G>Ну а где же цитата про перформанс?

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

H>>>>>>Ты же сам про процессорный кэш упоминал... Забыл?
G>>>>>Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается.
H>>>>Ты посмотри, как этот редкий процесс накручивает счетчик, когда ты мышкой водишь над кнопками на тулбаре.
G>>>Накручивает до определенной степени, потом переставет.
H>>У меня не получилось дождаться, пока перестанет. Не перестанет он.
G>У тебя определенно плохая карма. Прмерно 10 мб от первоначального объема кушат при двигании мышкой туда-сюда.
G>Это обсасывали еще при появлении персого дотнета.

Мы тут не про кушали, мы тут про счетчик GC.

H>>>>К тому же не забывай, я давал пример, когда на один вызод метода по XML-RPC происходит 3 сборки мусора. Не веришь мне, проверь сам.
G>>>Не надо в пример приводить какую-то левую либу.

H>>Да какой бы я пример не привел, ты назовешь его левым или говнософтом. Ладно, еще пример из говнософта. Запускаем Paint.NET и открываем в нем картинку (я открыл 1600x1200). Выделяем всю картинку Ctrl+A. Смотрим на счетчики GC и видим, что в мирно крутящем пунктир выделения Paint.NET'е, счетчик GC тикает раз-два-три в секунду.
G>И че, вам жалко? Че за фобия сборки мусора?

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

H>>>>Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету.
G>>>"мотаться" — громко сказано, это пара ассемблерных команд. Стандартному аллокатору чтобы поместить свободный блок в список приходится мотаться.
H>>Стандартный подчиняется ручному управлению, и на работу влияния не оказывает. В отличие от GC решившего вдруг марафет навести.
G>
G>Надо бы ло внимательнее статью читать, "вдруг" не бывает. тем более это тоже контролируется.

Именно вдруг. Работу GC ты можешь "типа контролировать" подстраивая алгоритм под его текущую стратегию. Зря чтоль Рихтер советует вызывать GC.Collect маскируя его за "тяжелыми операциями"?

G>>>http://www.rsdn.ru/forum/Default.aspx?mid=3164491

Автор: gandjustas
Дата: 06.11.08

H>>Во-первых это синтетика, не имеющая ничего общего с реальным миром. Во-вторых это не правильная синтетика.
G>Да, синтетика, которая как раз наглядно показывает что аллокатор в делфях медленее GC.

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

H>>Мне, как пользователю, не интересны резоны GC. Я вижу результат -- чрезмерное потребление.
G>Тебе как пользователю разница от цифирки в таскманагере есть?
G>Ты даже не можешь сопоставить быстродействие с этой цифиркой никак.

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

H>>Делаем простой эксперимент. Запускаем Paint.NET, который откушал сразу 35Mb (судя по твоим словам, большая часть этой цифры -- резерв, который будет возвращен в систему по первому требованию). Теперь начинаем запускать много тяжелого софта: две Delphi IDE, Open Office Writer, Abode Reader, Opera (она у меня жрет в районе 160Mb, из-за размера почтовой базы), VirtualBox. Все система ушла в своп. Смотрим на потребление Paint.NET... оно снизилось ровно на 300Кб. Выводы?
G>Вывод один — тебе срочно надо курить про workset. до этого больше тут ничего не пиши.

Я тебе еще раз говорю: это не workset, это Private bytes из Process Explorer'а. Хоть для приличия бы взглянул, уж не первый раз сказано.

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

G>GC не собирает память пока это никому не мешает, как только заполнится первое поколение — сразу же уберет, а то что не успел удбрать — сложит в другое полколение.

Это всего лишь эффект масштаба. Для С++ схему владения надо продумывать уже для довольно небольших задач (для совсем простых можно ничего не освобождать, да и всё), а для GC для задач побольше. Зато управлять GC посложнее...

Есть некоторая ниша по сложности задачи, где GC работает хорошо, но и только...

Кстати, в C++ наработано много всяких подходов к этому месту, так что обычно можно быть по крайней мере не хуже в области массовых аллокаций, чем GC...
Например, можно на каждый запрос на каждой нити создавать отдельный стековый аллокатор, и на нём ничего не освобождать, а только выделять. По окончании запроса данные, которые нужно сохранить мигрируют на обычный аллокатор, а стековый грохается целиком в начальное состояние, и мы снова готовы обработать запрос. В целом для очень многих задач такая стратегия аллокации НАМНОГО ЭФФЕКТИВНЕЕ GC...

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

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

M>>>Большая часть "выделения-освобождения памяти" на С++ не затрачивает никаких ресурсов, как может быть быстрее ?
G>>
G>>Да ну?
G>>Вым наверное стоит изучить как аллокаторы и GC работают.

E>А вам, что такое "автоматическая переменная" в C++
Не поверите, такие же переменные есть в .NET

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

G>>Эта наивная реализация во многих местах осталась и по сей день.
CC>Это проблемы тех мест а не С++ в целом.

+1
Кроме того, там конечно завались просто классных и быстрых GC...

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

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

H>>>Ты этой ссылкой только подтверждаешь мой тезис о том, что инфраструктура управления памятью в .Net более требовательна к оной
G>>Офигеть, дайте две, а причем тут перформанс?

H>>>Из заключения:
H>>>

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

G>>Ключевое выделил.
H>Угу, а при его отсутствии начнется деградация производительности (ведь алгоритмы перестанут работать эффективно, как следует из цитаты)
Я например замечаю что память кончается конда показатель выделенной физической памяти подбирается к 98 процентам.
В таких условиях тормозит все.

H>>>Ну и про отрицательное влияние на перформанс тоже сказано... не смотря на все оптимизации.
G>>Ну а где же цитата про перформанс?

H>Во ведении там есть несколько слов, найдешь А вообще, слова теже самые, что и у Рихтера. Я вообще удивлен, чего ты этот очевидный и признаваемый факт отрицаешь...
Ага, видно что прочитал введение и заключение.

H>Не жалко. Просто ты говорил о редких сборках мусора, а я тебе примеры привожу, которые показывают обратное.
3 раза в секунду это часто?
На гигагерцовом процессоре за секунду выполняется 1000000000 тактов. При этом если в приложении ничего не происходит, то все поколение становится мксором и не происходит фактически уплотнения кучи.
Сборщик мусора на многопроцесорной машине работает в фоновом режиме по большей части.
Так что влияние на производительность минимальная.


H>>>>>Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету.
G>>>>"мотаться" — громко сказано, это пара ассемблерных команд. Стандартному аллокатору чтобы поместить свободный блок в список приходится мотаться.
H>>>Стандартный подчиняется ручному управлению, и на работу влияния не оказывает. В отличие от GC решившего вдруг марафет навести.
G>>
G>>Надо бы ло внимательнее статью читать, "вдруг" не бывает. тем более это тоже контролируется.

H>Именно вдруг. Работу GC ты можешь "типа контролировать" подстраивая алгоритм под его текущую стратегию. Зря чтоль Рихтер советует вызывать GC.Collect маскируя его за "тяжелыми операциями"?
Мдя... не надо так явно показывать свою недалекость. Читайте про GCSettrings.LatencyMode.

H>Синтетика все что угодно показать может, главное приготовить как надо. Ты, как надо было тебе, приготовил.
Ну приготовь как тебе надо, покажи обратное.

H>>>Мне, как пользователю, не интересны резоны GC. Я вижу результат -- чрезмерное потребление.
G>>Тебе как пользователю разница от цифирки в таскманагере есть?
G>>Ты даже не можешь сопоставить быстродействие с этой цифиркой никак.

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

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

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

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

G>>GC не собирает память пока это никому не мешает, как только заполнится первое поколение — сразу же уберет, а то что не успел удбрать — сложит в другое полколение.

E>Это всего лишь эффект масштаба. Для С++ схему владения надо продумывать уже для довольно небольших задач (для совсем простых можно ничего не освобождать, да и всё), а для GC для задач побольше. Зато управлять GC посложнее...
На чем основано такое мнение? Уж точно не на длительном использовании .NET и профилировании программ.

E>Есть некоторая ниша по сложности задачи, где GC работает хорошо, но и только...
Вам наверное стоит почитать на каких допущениях работает GC. И на основе каких программ эти допущения получены.

E>Кстати, в C++ наработано много всяких подходов к этому месту, так что обычно можно быть по крайней мере не хуже в области массовых аллокаций, чем GC...
Да, в C++ надо думать о том когда и как выдеоять и освобожать память.
В .NET об этом думать не надо. Если будет тормозить тогда смотреть профайлером.

E>Например, можно на каждый запрос на каждой нити создавать отдельный стековый аллокатор, и на нём ничего не освобождать, а только выделять. По окончании запроса данные, которые нужно сохранить мигрируют на обычный аллокатор, а стековый грохается целиком в начальное состояние, и мы снова готовы обработать запрос. В целом для очень многих задач такая стратегия аллокации НАМНОГО ЭФФЕКТИВНЕЕ GC...
Это теория, покажите такие программы на практике.
Обычно ручная возьня с ресурсами очень сильно увеличивает время разработки программ. Такую возьню могут позволить себе только очень крупные фирмы.

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

MK>Так это получается, что все в форумах NET и NET GUI просто дебилы какие-то, выбирающие инструмент по рекламкам.
MK>Считай это как призыв не юзать подобные аргументы. Все же в деле заняты, а не в бирюльках.

Ну просто на PC обычно можно забить на прожорливость GUI, например...

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

kuj>Разработчика, который пытается использовать ВСЮ память надо бить сильно по рукам.

Я знаю задачи, в которых это правильная стратегия...

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

G>Только этот оверхед не влияет на производительность.
Но только на платформах, где памяти очень много...

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

CC>Лично участвовал в С++ серверном проекте для унесённого ныне кризисом Lehman Brothers.

Вот именно! Видишь до чего С++ доводит?

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

G>Можете посмотреть <...> Windows Media Center — аналогично.
А чему там тормозить в принципе?

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

G>У тебя видимо плохая карма что все .NET программы тормозят.
Да нет, просто у него на ноуте 512 метров RAM...

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

G>Не поверите, такие же переменные есть в .NET
Почему не поверю? Я советовал ведь не "проверить, есть ли в С++ автоматические переменные", а изучить, что это такое...

Скажем на С++ можно делать так

Автор: Erop
Дата: 27.02.07

...

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

G>На чем основано такое мнение? Уж точно не на длительном использовании .NET и профилировании программ.
Исключительно на переходе на личности основано

E>>Есть некоторая ниша по сложности задачи, где GC работает хорошо, но и только...
G>Вам наверное стоит почитать на каких допущениях работает GC. И на основе каких программ эти допущения получены.
Да и на каких? Сколько в той статистике было баз данных? Сколько 3D движков? Сколько распознавалок? Сколько переводчиков?..

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

Просто в С++ проектирование такого рода надо начинать на намного более простых задачах. Но на реально сложных это надо делать и там и там...

E>>Кстати, в C++ наработано много всяких подходов к этому месту, так что обычно можно быть по крайней мере не хуже в области массовых аллокаций, чем GC...
G>Да, в C++ надо думать о том когда и как выдеоять и освобожать память.
G>В .NET об этом думать не надо. Если будет тормозить тогда смотреть профайлером.
Ну и поспотришь ты профайлером, и что дальше будет? Если у тебя проектирования не было, а задача сложная, то будет тормозное г., при этом факт того, что это тормозное г. будет задокументирован профайлером

E>>Например, можно на каждый запрос на каждой нити создавать отдельный стековый аллокатор, и на нём ничего не освобождать, а только выделять. По окончании запроса данные, которые нужно сохранить мигрируют на обычный аллокатор, а стековый грохается целиком в начальное состояние, и мы снова готовы обработать запрос. В целом для очень многих задач такая стратегия аллокации НАМНОГО ЭФФЕКТИВНЕЕ GC...
G>Это теория, покажите такие программы на практике.
Какие "такие"? Быстрые и написанные на неуправляемом языке? Ядро линукса, например, устроит?

G>Обычно ручная возьня с ресурсами очень сильно увеличивает время разработки программ. Такую возьню могут позволить себе только очень крупные фирмы.
Обычно, ручная возня с ресурсами занимает очень маленькую часть затрат на разработку действительно сложного ПО (например переводчика, или операционной системы)...

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

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

А подробности будут?
Я всё равно не верю, что, Ada и С++ имеют одинаковый показатель.
Кроме того, на чём же тогда статистика для С# собрана, если только КРУПНЫЕ проекты идут в счёт? На сингулярити, что ли?

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

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

S>>Для разработчика это очень рискованно связываться с C#, т.к. требуется тащить .net runtime и привяжешь себя к Виндам.
MK>Вот-вот! Только представь, каждый день на работу и обратно таскать эти два тяжелых чемоданчика с .net runtime. Там по 20 кг в каждом! Порог вхождения очень высок

Осталость только домыслить "привяжешь себя к виндам" — привязал себя веревкой к оконной раме.

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

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

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

E>А подробности будут?
E>Я всё равно не верю, что, Ada и С++ имеют одинаковый показатель.
Можете не верить.

E>Кроме того, на чём же тогда статистика для С# собрана, если только КРУПНЫЕ проекты идут в счёт? На сингулярити, что ли?
На C# очень много крупных проектов, с миллионами строк кода.

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

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

G>>Не поверите, такие же переменные есть в .NET
E>Почему не поверю? Я советовал ведь не "проверить, есть ли в С++ автоматические переменные", а изучить, что это такое...

E>Скажем на С++ можно делать так

Автор: Erop
Дата: 27.02.07

...


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

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

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

G>>Только этот оверхед не влияет на производительность.
E>Но только на платформах, где памяти очень много...
Это вы себя пытаетесь убедить?
Посмотрел то что я писал, для программы показатель COMMITED памяти редко переваливает за 300 метров, это очень много?