tag:blogger.com,1999:blog-7754674872362895099.post8549819777370876618..comments2023-05-03T16:18:51.793+03:00Comments on Очень серьезный блог: GC or not GCAnonymoushttp://www.blogger.com/profile/10666299351005530153noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-7754674872362895099.post-667519514342515802011-04-19T13:26:01.347+04:002011-04-19T13:26:01.347+04:00Если я правильно понял, то с копированием объектов...Если я правильно понял, то с копированием объектов этот граф содержащий root будет разрастаться. Скопировали один объект, добавился еще один root на него или не так?wayhttp://www.blogger.com/profile/13693311846296781315noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-13656693220874128972011-04-19T13:26:01.038+04:002011-04-19T13:26:01.038+04:00ну судя по статье, CLR реализует стандартную схему...ну судя по статье, CLR реализует стандартную схему с generational gc, но видимо были какие-то особенности реализации, которые просаживали производительность для маленьких объектов - я если найду сслыку на то обсуждение, то кину в комментарийAlex Otthttp://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-65398973590044770852011-04-19T13:26:00.742+04:002011-04-19T13:26:00.742+04:00Apple, начиная с набора инструментов разработчика ...Apple, начиная с набора инструментов разработчика для Mac OS X 10.6, настаивает на использование GC в Cocoa-проектах.<br><br><a href="http://i2.fastpic.ru/big/2010/0314/56/28887336a85888c9350facf33e6ffd56.png" rel="nofollow">Пруфпик</a> с презенташки одной из сессий WWDC '09kemiistohttp://www.blogger.com/profile/03979879729267971884noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-86010205534760024382010-06-20T12:46:18.132+04:002010-06-20T12:46:18.132+04:00Этот комментарий был удален администратором блога.Bobihttps://www.blogger.com/profile/04997334912223943767noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-72594154356811318302010-03-14T01:32:08.200+03:002010-03-14T01:32:08.200+03:00Apple, начиная с набора инструментов разработчика ...Apple, начиная с набора инструментов разработчика для Mac OS X 10.6, настаивает на использование GC в Cocoa-проектах.<br /><br /><a href="http://i2.fastpic.ru/big/2010/0314/56/28887336a85888c9350facf33e6ffd56.png" rel="nofollow">Пруфпик</a> с презенташки одной из сессий WWDC '09Anonymoushttps://www.blogger.com/profile/03979879729267971884noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-53198482295492629942009-11-25T00:08:58.091+03:002009-11-25T00:08:58.091+03:00> упершиеся в скорость аллокации
Вот именно в ...> упершиеся в скорость аллокации<br /><br />Вот именно в скорость аллокации, а не скорость shared_ptr.<br /><br />Давайте всё-таки различать аллокацию памяти и подсчет ссылок.Ivan Sorokinhttp://ivansorokin.livejournal.comnoreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-56533369019405027312009-11-16T09:25:05.061+03:002009-11-16T09:25:05.061+03:00Скажите, вы видели хоть одну программу упершуюся в...<i>Скажите, вы видели хоть одну программу упершуюся в скорость shared_ptr?</i>Я видел программы упершиеся в скорость аллокации, а так-же огромное количество ошибок работы с памятью. И я не сомневаюсь, что можно написать такую программу, которая таки упрется в скорость shared_ptr :DAnonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-38281301325269803872009-11-10T02:03:07.132+03:002009-11-10T02:03:07.132+03:00Скажите, вы видели хоть одну программу упершуюся в...Скажите, вы видели хоть одну программу упершуюся в скорость shared_ptr?<br /><br />Ну и какой смысл руссуждать о скорости того, что занимает 0% времени CPU? :-)<br /><br />Что же касается скорости, заметьте:<br /><br />1 Не все объекты создаются в хипе.<br />2 Не под каждый объект создаётся свой блок памяти.<br />3 Не на все объекты, под которые создается свой блок памяти, ссылаются используя shared_ptr.<br /><br />И, кстати...<br />4 сборщик мусора, тоже, не бесплатная вещь.Ivan Sorokinhttp://ivansorokin.livejournal.com/noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-39907420918867005892009-11-02T11:40:30.925+03:002009-11-02T11:40:30.925+03:00Если я правильно понял, то с копированием объектов...Если я правильно понял, то с копированием объектов этот граф содержащий root будет разрастаться. Скопировали один объект, добавился еще один root на него или не так?Unknownhttps://www.blogger.com/profile/13693311846296781315noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-550812313530222952009-11-02T09:33:30.419+03:002009-11-02T09:33:30.419+03:00А разве для того, чтобы работал GC у каждого объек...<i>А разве для того, чтобы работал GC у каждого объекта не присутвует счетчик ссылок, который точно так же увеличивается самим GC, и доступ к которому нужно точно так же разграничивать?</i><br />Насколько я понимаю, в .NET, это просто указатели. Сборщик мусора строит граф, начиная с корневых объектов(статические объекты, объекты в стеке, и тд), для того, что-бы определить, содержит-ли тот объект указатели на другие объекты используется информация о типах, она там доступна динамически, а не только во время компиляции. Затем, алгоритм GC, с помощью обычного memcpy уплотняет кучу, сдвигая используемые объекты и обновляя указатели на них.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-65899407427048912162009-11-02T06:34:13.474+03:002009-11-02T06:34:13.474+03:00Операции над указателями: в случае GC, мы просто к...<i>Операции над указателями: в случае GC, мы просто копируем их, в случае not GC, копирование указателя приводит к изменению счетчика ссылок объекта.</i><br /><br />А разве для того, чтобы работал GC у каждого объекта не присутвует счетчик ссылок, который точно так же увеличивается самим GC, и доступ к которому нужно точно так же разграничивать?Unknownhttps://www.blogger.com/profile/13693311846296781315noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-44609914493332986922009-11-01T15:19:08.907+03:002009-11-01T15:19:08.907+03:00ну судя по статье, CLR реализует стандартную схему...ну судя по статье, CLR реализует стандартную схему с generational gc, но видимо были какие-то особенности реализации, которые просаживали производительность для маленьких объектов - я если найду сслыку на то обсуждение, то кину в комментарийAlex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-57270569650708683952009-11-01T14:57:07.339+03:002009-11-01T14:57:07.339+03:00У меня недостаточно опыта, для того, что-бы судить...У меня недостаточно опыта, для того, что-бы судить, насколько сборщик мусора CLR хорош для ФЯ. Я недавно читал <a href="http://msdn.microsoft.com/en-us/library/ms973837(classic).aspx" rel="nofollow">одну</a> статью в MSDN. Там говорится о том, что нужно минимизировать количество изменений объектов, особенно тех, которые живут долго. Значит, неизменяемость объектов в ФЯ, хорошо скажется на производительности сборщика мусора CLR.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-47688767146321683012009-11-01T13:46:15.871+03:002009-11-01T13:46:15.871+03:00насколько я помню, сборщик мусора CLR отнюдь не ид...насколько я помню, сборщик мусора CLR отнюдь не идеален, и при использовании ФЯ (и выделении очень большого кол-ва маленьких объектов), с ним возникает много проблем и проседаний в производительности - это кто-то из разработчиков F# писалAlex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.com