Modern Garbage Collectors under the Hood

Продукти, библиотеки и програмни интерфейси (API) за разработка на игри и модове.
Потребителски аватар
stoiko
Power User
Power User
Мнения: 617
Регистриран: 04 дек 2003 15:44
Контакти:

Modern Garbage Collectors under the Hood

Мнение от stoiko » 21 май 2013 13:41

http://www.gamedev.net/page/resources/_ ... hood-r2995

оп, май това беше за "програмиране на игри"

Потребителски аватар
KosSiO
Power User
Power User
Мнения: 317
Регистриран: 20 окт 2008 19:29
Местоположение: Targovishte,Sofia

Re: Modern Garbage Collectors under the Hood

Мнение от KosSiO » 22 май 2013 15:52

защо си мисля, че в днешно време един shared_ptr ти оправя всички проблеми с паметта ...

aSmith
Regular User
Regular User
Мнения: 80
Регистриран: 11 авг 2004 20:09
Местоположение: София

Re: Modern Garbage Collectors under the Hood

Мнение от aSmith » 22 май 2013 17:31

Хората тествали го, твърдят, че четенето/писането на ref-count-а при всеки достъп до shared_ptr-то ти скапва скоростта при много нишки (cache pollution или някакви други такива термини ползват).

ikolev
модератор
модератор
Мнения: 1667
Регистриран: 20 ное 2003 22:39
Местоположение: София
Контакти:

Re: Modern Garbage Collectors under the Hood

Мнение от ikolev » 23 май 2013 11:57

Интересно какво трябва да правят многото нишки, за да бъркат едновременно в брояча на даден shared_ptr. Примерно да си го подават по стойност вместо по const&, или изобщо да си подават shared_ptr вместо директно Т* или Т&. Мислех че FUD-а около shared_ptr е разпръснат вече.

Едно сериозно предимство на GC е че фрагментацията е нула - цялата използвана памет е в един блок, с всички последствия от това (поне при .NET е така, вероятно и другите системи с GC го правят). Примерно, заемането на нова памет е моментално - увеличаване на един указател. Освен това предполагам че се подобрява локализацията на достъпа.

Отговори