Re[2]: Нетривиальные проблемы с GC
От: remark Россия http://www.1024cores.net/
Дата: 11.09.07 13:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, remark


E><...информация прочитана, усвоена и почикана...>


R>>Какие мысли?


E>Главная мысль в том, что перечисленные тобой случаи можно назвать граничными условиями использования GC. Да, в них GC становится одним из условий решаемой задачи, поскольку нужно принимать в расчет его возможные (и невозможные) фокусы.


Я думаю, тут всё зависит от масштаба и уровня приложения.
В крупном/серьёзном/развиваемом продукте такие "граничные условия" скорее всего рано или поздно появятся. Дальше будет основной вопрос — возможно ли их вообще обойти при использовании выбранных технических средств? ...


E>Но с другой стороны, есть масса очень простых случаев, когда GC берет на себя заботы программиста. Тем самым упрощая разработку и снижая количество ошибок. А если учесть, что при использовании GC выделение памяти обходится (по слухам) дешевле C-шных malloc-ов, а освобождается затем всем скопом, то GC может привести (и приводит, по benchmark-ам по крайней мере) к увеличению скорости работы программы на некоторых задачах.


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


E>Так что, если вспомнить закон потребления пива 20/80, то GC является отличным инструментом в 80% случаев. Зато в оставшихся 20% с ним придется бороться.


E>Явное же управление памятью наоборот, вызывает лишние затраты в 80% случаев, зато в 20% это именно то, что нужно.


Да. Если ты пишешь только 80%. Если же ты пишешь и оставшиеся 20%, и соотв. у тебя есть решения для этих 20%, то не вижу смысла не применять их в других 80%. Точнее так — я не вижу больше проблемы.


E>Справедливости ради нужно сказать, что в C++, к счастью, есть возможность создавать объекты на стеке и передавать их по значению. Что часто очень серьезно снижает количество операций new/delete.


В C# тоже есть "структуры", которые создаются на стеке и передаются по значению.



Приемущество "Сишных" malloc/free в данном контексте — они просты как 2 копейки. В них просто нет ничего, что могло бы вообще вызывать какие-либо нарекания, или какие-либо проблемы. Именно они сами, не то, как их использовать.
Я не помню, что бы слышал какие либо нарекания именно в адрес самих malloc/free. Да, это низкоуровневое средство. И оно хорошо делает одну чётко определённую вещь...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.