Сообщение Re[45]: Nemerle через 5 лет - выстрелит или скончается? от 08.10.2014 23:27
Изменено 08.10.2014 23:30 Evgeny.Panasyuk
Здравствуйте, VladD2, Вы писали:
EP>>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
VD>А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).
Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
То есть кроме выделения не производится абсолютно никаких операций.
VD>В дотнете и явы ты используешь эдакий универсальный пул. Причем используешь не от случая к случаю, а все время. Следить за тем как ты освобождаешь память не надо.
Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.
EP>>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++
VD>Дык стандартный и используются в 99% случаев.
Да, но используются они совершенно по-разному.
В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокаций — одна на массив указателей, и по одной на каждый объект.
VD>Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.
Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.
VD>Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают.
Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.
EP>>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
VD>А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).
Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
То есть кроме выделения не производится абсолютно никаких операций.
VD>В дотнете и явы ты используешь эдакий универсальный пул. Причем используешь не от случая к случаю, а все время. Следить за тем как ты освобождаешь память не надо.
Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.
EP>>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++
VD>Дык стандартный и используются в 99% случаев.
Да, но используются они совершенно по-разному.
В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокаций — одна на массив указателей, и по одной на каждый объект.
VD>Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.
Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.
VD>Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают.
Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.
Re[45]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
EP>>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
VD>А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).
Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
То есть кроме выделения не производится абсолютно никаких операций.
VD>В дотнете и явы ты используешь эдакий универсальный пул. Причем используешь не от случая к случаю, а все время. Следить за тем как ты освобождаешь память не надо.
Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.
EP>>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++
VD>Дык стандартный и используются в 99% случаев.
Да, но используются они совершенно по-разному.
В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.
VD>Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.
Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.
VD>Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают.
Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.
EP>>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
VD>А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).
Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
То есть кроме выделения не производится абсолютно никаких операций.
VD>В дотнете и явы ты используешь эдакий универсальный пул. Причем используешь не от случая к случаю, а все время. Следить за тем как ты освобождаешь память не надо.
Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.
EP>>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++
VD>Дык стандартный и используются в 99% случаев.
Да, но используются они совершенно по-разному.
В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.
VD>Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.
Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.
VD>Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают.
Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.