Здравствуйте, Сергей Губанов, Вы писали:
AD>>...(но не решить проблему с дефрагментацией). СГ>Наверное можно и ее решить. Вот смотрите. ...
Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, Сергей Губанов, Вы писали:
AD>>>...(но не решить проблему с дефрагментацией). СГ>>Наверное можно и ее решить. Вот смотрите. ...
AD>Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
Угу. Надо иметь такое железо, что б оно физические страницы могло приклеивать/отклеивать по произвольному виртуальному адресу и произвольного размера с точностью до байта.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот и я про тоже. Надо чтобы аппаратно можно было ассоцировать/деассоциировать физические страницы с виртуальной памятью причем любого физического размера и с точностью до байта.
Ага, тогда таблица соответствия виртуальных и физических адресов будет иметь размер
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, ArtDenis, Вы писали:
AD>>Теперь можно выделить память в этом непрерывном участке. Причём эффективность метода растёт с уменьшением размера страницы.
СГ>Вот и я про тоже. Надо чтобы аппаратно можно было ассоцировать/деассоциировать физические страницы с виртуальной памятью причем любого физического размера и с точностью до байта. А размер виртуального пространства может быть очень велик 2^64 для 64 разрядных или 2^256 для 256 разрядных — так что всю виртуальную память никогда не израсходуешь (не успеешь).
Для описания виртуальной памяти в 512 мегабайт нужно минимум 1 мегабайт реальной памяти (на 64 битной машине), причем памяти, которая не свопируется. Это вообще говоря довольно серьезная проблема и ее пытаются решить путем увеличения размера страниц, а ты предлагаешь их уменьшать. Если уменьшать, то большая часть памяти будет протухать, храня в себе бесчисленные малополезные таблицы страниц.
Здравствуйте, vdimas, Вы писали:
V>Ерничать некрасиво, да еще так абстрактно. Все рассуждения можно производить только в сравнительной степени, а не абсолютной. Например, блочный аллокатор может потребовать в среднем 30 инструкций для выделения и 15 для освобождения памяти, и эта величина почти не зависит от кол-ва объектов. А в GC эти цифры от 500 для выделения и сотен тысяч или миллионов тактов для освобождения. Этих лишних тактов у нас может просто и не быть при максимальной загрузке системы.
Не нужно преувеличивать. В простом копирующем сборщике мусора выделение памяти происходит практически мгновенно, а процесс чистки занимает времени примерно порядка занятой памяти. Если считать, что занята постоянно 1/8 памяти, а средний размер объекта 128 байт, то цикл выделение-освобождение в среднем на один объект займет несколько тысяч инструкций. Это не блочный аллокатор, естественно, но зато можно выделять память для объектов произвольного размера.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, vdimas, Вы писали:
V>>Ерничать некрасиво, да еще так абстрактно. Все рассуждения можно производить только в сравнительной степени, а не абсолютной. Например, блочный аллокатор может потребовать в среднем 30 инструкций для выделения и 15 для освобождения памяти, и эта величина почти не зависит от кол-ва объектов. А в GC эти цифры от 500 для выделения и сотен тысяч или миллионов тактов для освобождения. Этих лишних тактов у нас может просто и не быть при максимальной загрузке системы.
Q>Не нужно преувеличивать. В простом копирующем сборщике мусора выделение памяти происходит практически мгновенно, а процесс чистки занимает времени примерно порядка занятой памяти. Если считать, что занята постоянно 1/8 памяти, а средний размер объекта 128 байт, то цикл выделение-освобождение в среднем на один объект займет несколько тысяч инструкций. Это не блочный аллокатор, естественно, но зато можно выделять память для объектов произвольного размера.
Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций...
Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, ArtDenis, Вы писали:
AD>>Здравствуйте, Сергей Губанов, Вы писали:
AD>>>>...(но не решить проблему с дефрагментацией). СГ>>>Наверное можно и ее решить. Вот смотрите. ...
AD>>Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
СГ>Угу. Надо иметь такое железо, что б оно физические страницы могло приклеивать/отклеивать по произвольному виртуальному адресу и произвольного размера с точностью до байта.
Ты подумай сначала, сколько памяти потребуется такому железу, что бы склеивать страницы памяти... И кому оно такое будет надо?
Здравствуйте, AndreyFedotov, Вы писали:
AF>Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций... AF>Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Ну так ведь речь шла о самом простом и универсальном GC. Кто мне мешает сделать "блочный" GC с эффективной реализацией value типов? В этом случае память будет выделяться также быстро как и руками, а осовобождаться будет лишь с небольшим оверхедом, вызванным теоретическими многочисленными ссылками на некоторые объекты. Думаю, реально для любой специфической задачи создать GC, который затормозит программу не более, чем на 10%.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций... AF>>Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Q>Ну так ведь речь шла о самом простом и универсальном GC. Кто мне мешает сделать "блочный" GC с эффективной реализацией value типов? В этом случае память будет выделяться также быстро как и руками, а осовобождаться будет лишь с небольшим оверхедом, вызванным теоретическими многочисленными ссылками на некоторые объекты. Думаю, реально для любой специфической задачи создать GC, который затормозит программу не более, чем на 10%.
Это теоретически. На практике действительно идёт большая работа над алгоритмами, которые позволяют достичь предсказуемости работы GC, а так же осуществления сборки мусора мелкими порциями и есть даже некоторые успехи в этой области. В переспективе это действительно позволяет использовать GC и основанные на нём технологии во всё новых и новых областях, в том числе и некоторых из тех, где раньше это было сложно себе представить.
Однако замечу — что GC всё ещё остаётся достаточно дорогой (в смысле ресурсов и по сравнению с Heap или статическим распределением памяти) и по-прежнему хватает применений, где по этой причине использование GC мало реально.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Это теоретически. На практике действительно идёт большая работа над алгоритмами, которые позволяют достичь предсказуемости работы GC, а так же осуществления сборки мусора мелкими порциями и есть даже некоторые успехи в этой области. В переспективе это действительно позволяет использовать GC и основанные на нём технологии во всё новых и новых областях, в том числе и некоторых из тех, где раньше это было сложно себе представить. AF> Однако замечу — что GC всё ещё остаётся достаточно дорогой (в смысле ресурсов и по сравнению с Heap или статическим распределением памяти) и по-прежнему хватает применений, где по этой причине использование GC мало реально.
Хотелось бы добавить, что ещё остались области где до сих пор используется голый асм вместо C, голый CmixAsm вместо C+RTOS со статическим распределением памяти, в рунете есть места где вам на чистом русском языке с примерами из жизни объяснят всё насчёт оверхеда в критических приложениях
