Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.92.130.77] |
|
Страницы: (56) « Первая ... 44 45 [46] 47 48 ... 55 56 ( Перейти к последнему сообщению ) |
Сообщ.
#676
,
|
|
|
Цитата Qraizer @ Так что вполне можно представить себе реализацию компилятора, который на каждый поинтер заводит счётчик, аддрефит и декрефит его при копировании, присваивании итп и следит за областями видимости этих поинтеров. Это сделает их практически неотличимыми от shared_ptr<>. В итоге получим в общем-то тот самый GC, который хороший, детерминированный и незаметный. Ну тот же swift примерно так и работает: https://developer.apple.com/library/content...ceCounting.html Но и там есть явные "слабые ссылки". И без них (или какого-то детектора циклов) ты никак не обойдешься. Добавлено Reference Counting |
Сообщ.
#677
,
|
|
|
Оно важно, но не оно превращает GC в не-GC.
Когда приспичит GC. Да. И вся аргументация сводится к "мне так кажется". Объективных причин как за смешивание так и против, я не вижу. И в D это не мешает. Мешает просто плохой GC. Цитата D_KEY @ В эрланге нет никаких детекторов цикла. Там RC применяется к объектам, которые принципиально не могут содержать ссылки на другие объекты. Для остальных generational GC.Без детектора циклов это не имеет смысл. А если он есть, то это уже не совсем RC. Это реализация сборщика через RC Цитата D_KEY @ С чего ты взял? Сам же RC сборкой мусора не является. Вернее, в современных системах лучше эти понятия разделять. |
Сообщ.
#678
,
|
|
|
Цитата applegame @ Оно важно, но не оно превращает GC в не-GC. Это является следствием работы того, что сейчас называют GC. Полноценная сборка мусора не в состоянии обеспечить детерминированное удаление. Цитата Объективных причин как за смешивание так и против, я не вижу В таком случае лучше не смешивать, ибо так проще. Зачем усложнять, если ценность не ясна? Добавлено Цитата applegame @ Там RC применяется к объектам, которые принципиально не могут содержать ссылки на другие объекты Тогда это можно рассматривать в качестве оптимизации GC для конкретных случаев. От программиста что-то требуется? Цитата Цитата D_KEY @ С чего ты взял?Сам же RC сборкой мусора не является. Вернее, в современных системах лучше эти понятия разделять. Это же просто классификация. Называя RC сборкой мусора легко ввести в заблуждение. Добавлено applegame, посмотри на статью про ARC в swift, что я выше привел. Как думаешь, удобно бы было, если бы они называли это сборкой мусора? |
Сообщ.
#679
,
|
|
|
Цитата Qraizer @ Неполноценный GC получится, чреват утечками из-за циклических ссылок.Не согласен. Даже сырые поинтеры вполне можно контролировать "под капотом" технологией, похожей на C++EH. Напомню, что реализация C++EH никак не затрагивает классы и полностью обходится внешними по отношению к охраняемым им объектам структурами данных. Так что вполне можно представить себе реализацию компилятора, который на каждый поинтер заводит счётчик, аддрефит и декрефит его при копировании, присваивании итп и следит за областями видимости этих поинтеров. Это сделает их практически неотличимыми от shared_ptr<>. В итоге получим в общем-то тот самый GC, который хороший, детерминированный и незаметный. Только цена подобного решения будет велика. Если C++EH практически не сказывается на производительности кода, кроме собственно случаев, когда исключения выбрасываются, то такие поинтеры будут отнимать ресурсы ЦП постоянно. Т.к. принцип нулевой стоимости запрещает сие, поэтому и есть отдельные библиотечные типы, используя которые программер сознательно идёт на этот оверхед. Кроме того, почему-то считается, что такой GC будет медленнее современных incremental/generational GC. |
Сообщ.
#680
,
|
|
|
Цитата applegame @ Почему это? Циклы аутоматично могут детектиться, кто мешает реализовать? Неполноценный GC получится, чреват утечками из-за циклических ссылок. |
Сообщ.
#681
,
|
|
|
Цитата Qraizer @ Циклы аутоматично могут детектиться, кто мешает реализовать? Полноценно их можно детектить только в рантайме. И что ты с ними будешь делать автоматически? |
Сообщ.
#682
,
|
|
|
Цитата D_KEY @ А что усложняется? Ты можешь полностью забить на RAII и писать так же как пишешь на шарпе или жабе. А ценность ясна - ты можешь применять D для низкоуровневого кода. Я например на D даже микроконтроллеры прогаю, не пользуясь GC.В таком случае лучше не смешивать, ибо так проще. Зачем усложнять, если ценность не ясна? Цитата D_KEY @ Как и в любом языке есть рекомендации в каких ситуациях как лучше поступать или наоборот не поступать.Тогда это можно рассматривать в качестве оптимизации GC для конкретных случаев. От программиста что-то требуется? Цитата D_KEY @ То есть это вопрос чисто терминологии. Так как мы оба прекрасно понимаем, о чем говорим, то не вижу смысла в дальнейшем споре.Это же просто классификация. Называя RC сборкой мусора легко ввести в заблуждение. Цитата D_KEY @ Да все равно, если честно. Написали бы, сборка мусора обеспечивается при помощи ARC, ничего бы не поменялось. applegame, посмотри на статью про ARC в swift, что я выше привел. Как думаешь, удобно бы было, если бы они называли это сборкой мусора? |
Сообщ.
#683
,
|
|
|
Цитата applegame @ Кроме того, почему-то считается, что такой GC будет медленнее современных incremental/generational GC. Ну тут комплекс факторов. Ты не сможешь на такой основе сделать быстрое выделение памяти(которое в случае полноценного GC может сводится почти что к инкременту указателя), ибо нет фазы сборки, нет фазы перемещения и уплотнения объектов. Так же у тебя появляется оверхед на каждое копирование ссылки. Да и замеры какие-то вроде проводили, но тут у меня есть сомнения в корректности. |
Сообщ.
#684
,
|
|
|
Цитата Qraizer @ Реализовывали уже, в питоне и в Nim. Тормозно получается. Этож надо строить графы ссылок и искать в нем циклы. Поэтому этот детектор ссылок делают отключаемым. Почему это? Циклы аутоматично могут детектиться, кто мешает реализовать? |
Сообщ.
#685
,
|
|
|
Цитата applegame @ Да все равно, если честно. Написали бы, сборка мусора обеспечивается при помощи ARC, ничего бы не поменялось. Хм. Ну а как бы ты описывал необходимость в слабых ссылках? Ведь они в языках с нормальным GC есть, только совсем другие и для других целей используются. Добавлено Цитата applegame @ А что усложняется? Ты можешь полностью забить на RAII и писать так же как пишешь на шарпе или жабе. Тогда зачем мне D? Есть же kotlin и scala Добавлено Цитата applegame @ А ценность ясна - ты можешь применять D для низкоуровневого кода. Я например на D даже микроконтроллеры прогаю, не пользуясь GC. Но ведь ты сам выше писал, что D gc-ориентированный. Неужели удобнее получается, чем на крестах или rust? |
Сообщ.
#686
,
|
|
|
Цитата D_KEY @ Да, я в курсе аргументации противников ARC.Ну тут комплекс факторов. Ты не сможешь на такой основе сделать быстрое выделение памяти(которое в случае полноценного GC может сводится почти что к инкременту указателя), ибо нет фазы сборки, нет фазы перемещения и уплотнения объектов. Так же у тебя появляется оверхед на каждое копирование ссылки. Да и замеры какие-то вроде проводили, но тут у меня есть сомнения в корректности. Несколько лет назад кто-то в D в свое время перехерачил весь рантайм на ARC и доложил о нехилом приросте скорости в какой-то там игре. Но это тоже не совсем корректный замер, так как дешный GC тормозной, и у него кто угодно выиграет. Если бы все эти александрески не парили бы мозг и просто сделали бы те же плюсы, но с синтаксисом и шаблонами D, то очень вероятно, что сейчвс бы Qraizer топил бы за такой D. |
Сообщ.
#687
,
|
|
|
Цитата applegame @ Ну так как напрограмили, так и работает. Оптимизацию никто не запрещал. Реализовывали уже, в питоне и в Nim. Тормозно получается. Этож надо строить графы ссылок и искать в нем циклы. |
Сообщ.
#688
,
|
|
|
Цитата D_KEY @ Да также бы и описывал. Мне неинтересно спорить на тему является ли ARC частным случаем GC или нет. В любом разговоре достаточно договориться о терминах, а там хоть горшком назови. Я твою точку зрения понял, и когда ты будешь писать GC я учту, что ты имеешь в виду "обычный" GC как в D, жабе и т. д.Хм. Ну а как бы ты описывал необходимость в слабых ссылках? Ведь они в языках с нормальным GC есть, только совсем другие и для других целей используются. Цитата D_KEY @ Это риторический вопрос. Зачем kotlin и scala, когда есть D, Elixir и Haskell?Тогда зачем мне D? Есть же kotlin и scala Цитата D_KEY @ Да, удобнее, как ни странно. Фактически ты как бы пишешь на эдаких сильно прокачанных плюсах. Разве что библиотек нет вообще, поэтому чисто как хобби. Профессионально кодить МК на D - это безумие. Но ведь ты сам выше писал, что D gc-ориентированный. Неужели удобнее получается, чем на крестах или rust? Цитата Qraizer @ Можно конечно предположить, что программисты в Apple криворукие, но я таки склонен полагать, что это не так просто как ты считаешь. Ну так как напрограмили, так и работает. Оптимизацию никто не запрещал. |
Сообщ.
#689
,
|
|
|
Цитата Qraizer @ Оптимизацию никто не запрещал. Расскажешь, как бы ты сделал детектор циклов? Добавлено Цитата applegame @ Зачем kotlin и scala, когда есть D, Elixir и Haskell? Проще же(хотя про scala это вряд ли можно сказать). По крайней мере в рассматриваемом вопросе управления памятью. Добавлено В остальном согласен, там действительно больше о терминологии речь. |
Сообщ.
#690
,
|
|
|
Цитата D_KEY @ Не думаю, что проще. На D также легко писать как и на kotlin. Практически все дешные WAT-ы никак с GC не связаны.Проще же(хотя про scala это вряд ли можно сказать). По крайней мере в рассматриваемом вопросе управления памятью. Проблемы возникают, если в программе очень много GC-объектов болтающихся в памяти. У меня например в проекте их сотни тысяч. GC тормозит безбожно. Авторы D2 почему-то забили на опыт Apple. Насколько я помню, в Objective C долго пытались сделять полноценный GC. Мучались, пробовали и так и эдак, но в итоге забили и сделали ARC, потому, что в подобных языках полноценные GC получаются убогими. |