Альтернатива для сборщика "мусора"

В C ++ можно сделать выделение кучи ОДИН РАЗ для ваших объектов, а затем повторно использовать эту память для последующих объектов, я видел, как это работает, и это было невероятно быстро .

Это применимо только к определенному набору проблем, и сделать это правильно сложно, но возможно.

Одна из радостей C ++ заключается в том, что у вас есть полный контроль над управлением памятью, вы можете решить использовать классические команды new / delete или реализовать собственный подсчет ссылок или сборку мусора.

Однако - вот драконы - вам действительно, действительно нужно знать, что вы делаете.

Если скорость имеет значение, а память - нет, то самая быстрая и простая стратегия распределения - никогда не освобождать. Выделение - это просто поднятие указателя вверх. Вы не можете быть быстрее этого.

Конечно, если ничего не выпускать, это может привести к переполнению доступной памяти. Очень редко память действительно «не важна». Обычно имеется большой, но конечный объем доступной памяти. Одна из стратегий называется «распределением по регионам». А именно, вы распределяете память в нескольких больших блоках, называемых «регионами», с помощью стратегии смещения указателя. Выпуск происходит только по целым регионам. Эта стратегия может быть применена с некоторым успехом, если рассматриваемая проблема может быть структурирована в последовательные «задачи», каждая из которых имеет свой собственный регион.

Для более общих решений, если вы хотите распределение в реальном времени (т. Е. Гарантированные ограничения на время ответа от запросов на выделение памяти), тогда сборка мусора - это правильный выбор. Сборщик мусора в реальном времени может выглядеть так: объекты выделяются с помощью стратегии смещения указателя. Кроме того, при каждом выделении памяти распределитель выполняет небольшую сборку мусора, при которой «живые» объекты копируются в другое место. В некотором смысле сборщик мусора работает «одновременно» с приложением. Это подразумевает небольшую дополнительную работу для доступа к объектам, потому что вы не можете переместить объект и обновить все указатели, чтобы они указывали на новое местоположение объекта, сохраняя при этом обещание «реального времени». Решения могут включать барьеров , например дополнительное косвенное обращение. Сборщик мусора поколений обеспечивает беспрепятственный доступ к большинству объектов, сохраняя при этом время паузы в строгих пределах.

Эту статью необходимо прочитать всем, кто хочет изучить распределение памяти, в частности сборку мусора.

Нет лучшей альтернативы сборщику мусора, вы можете утилизировать объект самостоятельно, но он не лучшая идея. если вы действительно не уверены в том, что делаете, не беспокойтесь о сборке мусора, поскольку современные сборщики мусора хорошо справляются со своей работой.

Если память не имеет значения, то применимо то, что говорит @Thomas. Учитывая гигантские объемы памяти современного оборудования, это вполне может быть жизнеспособным вариантом - все зависит от процесса.

Ручное управление памятью не обязательно решает ваши проблемы напрямую, но оно дает вам полный контроль над тем, КОГДА происходят события с памятью. Generic malloc, например, не является операцией O(1). Она делает всевозможные потенциально ужасные вещи, как в куче, управляемой самим malloc, так и операционной системой. Например, никогда не знаешь, когда "malloc(10)" может привести к тому, что виртуальная машина выгрузит что-то на страницу, и теперь ваши 10 байт оперативной памяти имеют неизвестный компонент дискового ввода-вывода - упс! Что еще хуже, эта страница может оказаться ВАШЕЙ памятью, которую вам нужно будет немедленно вернуть обратно! Теперь c = *p - это удар по диску. УРА!

Но если вы знаете об этом, то можете спокойно настроить свой код так, чтобы все критические по времени части фактически не занимались управлением памятью, а работали с заранее выделенными структурами для этой задачи.

С системой GC у вас может быть похожая возможность - это зависит от коллектора. Я не думаю, что в Sun JVM, например, есть возможность "отключения" на короткие периоды времени. Но если вы работаете с предварительно выделенными структурами и вызываете весь свой собственный код (или точно знаете, что происходит в библиотечной рутине, которую вы вызываете), у вас, вероятно, есть хорошие шансы не задеть менеджер памяти.

Потому что суть дела в том, что управление памятью - это большая работа. Если вы хотите избавиться от управления памятью, пишите на старом добром FORTRAN с ARRAYs и COMMON блоками (одна из причин, почему FORTRAN может быть таким быстрым). Конечно, вы можете написать "FORTRAN" почти на любом языке.

С современными языками, современными GC и т.д. управление памятью было отодвинуто на второй план и стало проблемой "10%". Сейчас мы довольно небрежно относимся к созданию мусора, копированию памяти и т.д. и т.п., потому что GC и т.д. облегчают нам задачу. И для 90% программ это не является проблемой, поэтому мы не беспокоимся об этом. Сейчас это проблема настройки, на поздних стадиях процесса.

Так что лучший вариант - установить все сразу, использовать, а потом выбросить. Часть "использовать" - это то, где вы получите последовательные, надежные результаты (при условии достаточного количества памяти в системе, конечно).

Это распространенное заблуждение, что управляемые языки не подходят для высокопроизводительных сценариев с низкой задержкой. Да, при ограниченных ресурсах (таких как встроенная платформа) и небрежном программировании вы можете прострелить себе ногу так же эффектно, как и в случае с C++ (и это может быть ОЧЕНЬ ОЧЕНЬ эффектно).

Эта проблема возникла при разработке игр на Java/C#, и решением было использовать пул памяти и не позволять объектам умирать, следовательно, не нужно запускать сборщик мусора, когда вы этого не ожидаете. На самом деле это тот же подход, что и в неуправляемых системах с низкой задержкой - ТРЕБОВАТЬ РЕАЛЬНО ОЧЕНЬ ТРУДНО НЕ РАСПРЕДЕЛЯТЬ ПАМЯТЬ.

Итак, учитывая тот факт, что реализация такой системы на Java/C# очень похожа на C++, преимущество в том, что вы делаете это по-мужски (управляемо), у вас есть "приятность" других особенностей языка, которые освобождают ваши умственные циклы, чтобы сосредоточиться на важных вещах.

В качестве «альтернативы» сборке мусора C ++ имеет специальные указатели. boost :: shared_ptr <> (или std :: tr1 :: shared_ptr <>) работает точно так же, как сборка мусора с подсчетом ссылок в Python. На мой взгляд, shared_ptr - это сборка мусора. (хотя вам может потребоваться сделать несколько вещей weak_ptr <>, чтобы убедиться, что циклические ссылки не возникают)

Я бы сказал, что auto_ptr <> (или в C ++ 0x, unique_ptr <> ...) представляет собой жизнеспособную альтернативу со своим набором преимуществ и недостатков. Auto_ptr имеет неуклюжий синтаксис и не может использоваться в контейнерах STL ... но он выполняет свою работу. Во время компиляции вы «перемещаете» владение указателем с переменной на переменную. Если переменная владеет указателем, когда она выходит за пределы области видимости, она вызывает свой деструктор и освобождает память. Только один auto_ptr <> (или unique_ptr <>) может владеть настоящим указателем. (по крайней мере, если правильно использовать).

В качестве другой альтернативы вы можете хранить все в стеке и просто передавать ссылки на все нужные вам функции.

Эти альтернативы на самом деле не решают общую проблему управления памятью, которую решает сборка мусора. Тем не менее, они эффективны и хорошо протестированы. Auto_ptr не использует больше места, чем изначально указывал указатель ... и нет накладных расходов на разыменование auto_ptr. «Движение» (или присваивание в Auto_ptr) связано с небольшими накладными расходами, чтобы отслеживать владельца. Я не проводил никаких тестов, но уверен, что они быстрее, чем сборка мусора / shared_ptr.