Здравствуйте, CreatorCray, Вы писали:

G>>>>Как аллокатор общего назначения использовать смысла нету.
CC>>>Расскажи это разработчикам Hoard, TBB и того же Windows Heap
G>>А это тут причем? Ты будешь на задумываясь использовать свой аллокатор в продакш коде?
CC>А почему нет? Я его интереса ради стресс тестами гонял в многопоточном режиме на 4хядернике.
Ну и что?
Я "ради интереса" и GC писал на C++, но в реальном проекте не стал бы его использовать.

G>>Кстати, получилось что GC порвал в 5 раз виндовый аллокатор, который на пулах, так?
CC>Ох блин. Как же трудно иногда объяснять элементарные вещи человеку с синдромом бакалавра.
CC>В HeapAlloc самые большие тормоза дает Critical Section.
Да ты че?
Конечно критическая секция дает тормоза. Кто сказал что параллельность бесплатно дается?

Здравствуйте, gandjustas, Вы писали:

G>Если программист недостаточной квалификации, то само использование unmanaged становится большой проблемой (видел такое на Delphi), не говоря уже о С++ с его примудростями.
Managed от идиотов все равно не спасает.

Здравствуйте, gandjustas, Вы писали:

CC>>А почему нет? Я его интереса ради стресс тестами гонял в многопоточном режиме на 4хядернике.
G>Я "ради интереса" и GC писал на C++, но в реальном проекте не стал бы его использовать.
Ну, если получилось что то хорошее, работоспособное и способное принести пользу проекту то почему бы и не использовать?

G>>>Кстати, получилось что GC порвал в 5 раз виндовый аллокатор, который на пулах, так?
CC>>Ох блин. Как же трудно иногда объяснять элементарные вещи человеку с синдромом бакалавра.
CC>>В HeapAlloc самые большие тормоза дает Critical Section.
G>Конечно критическая секция дает тормоза. Кто сказал что параллельность бесплатно дается?
Она не бесплатная, да. Но она вообще то обеспечивается дешевле, чем тупо натыкать critical section.

Тебе знаком термин lock-free? А per-thread аллокация?
Есть еще тут мега-чел Remark, он тебе много может рассказать.

У меня в ThreadPoolAlloc вообще получается что нет никакой необходимости в синхронизации, пока не начнешь освобождать данные, выделенные в другом потоке. Да и то вся синхронизация будет заключаться в lock-free добавлении освобождаемой памяти в deferred очередь, которую освободит родной поток.
Ну и плюс всякие мелочи типа разруливание ситуаций когда поток память навыделял и завершился, а освобождать ее будет кто то другой.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

CC>>>А почему нет? Я его интереса ради стресс тестами гонял в многопоточном режиме на 4хядернике.
G>>Я "ради интереса" и GC писал на C++, но в реальном проекте не стал бы его использовать.
CC>Ну, если получилось что то хорошее, работоспособное и способное принести пользу проекту то почему бы и не использовать?
Во-первых я тогда не работал на С++
Во-вторых не получилось ничего работоспособного, грубо говоря работало в некоторых случаях.

G>>>>Кстати, получилось что GC порвал в 5 раз виндовый аллокатор, который на пулах, так?
CC>>>Ох блин. Как же трудно иногда объяснять элементарные вещи человеку с синдромом бакалавра.
CC>>>В HeapAlloc самые большие тормоза дает Critical Section.
G>>Конечно критическая секция дает тормоза. Кто сказал что параллельность бесплатно дается?
CC>Она не бесплатная, да. Но она вообще то обеспечивается дешевле, чем тупо натыкать critical section.
Не всегда. При работе со списком свободных блоков например, без критической секции вряд ли что-то получится.

CC>Тебе знаком термин lock-free? А per-thread аллокация?
Конечно ускорения надо разделять данные между потоками и\или использовать атомные операции.
Первое сложнее в реализации и таит подводные камни, второе далеко не всегда доступно (в C++ например не доступно при выделении памяти).

CC>Есть еще тут мега-чел Remark, он тебе много может рассказать.
Я его уже перечитал.

CC>У меня в ThreadPoolAlloc вообще получается что нет никакой необходимости в синхронизации, пока не начнешь освобождать данные, выделенные в другом потоке. Да и то вся синхронизация будет заключаться в lock-free добавлении освобождаемой памяти в deferred очередь, которую освободит родной поток.
CC>Ну и плюс всякие мелочи типа разруливание ситуаций когда поток память навыделял и завершился, а освобождать ее будет кто то другой.
Ну это и есть подоводные камни.
Кроме того deferred очередь ужасно будет работать при использовании пула потоков.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

G>>Если программист недостаточной квалификации, то само использование unmanaged становится большой проблемой (видел такое на Delphi), не говоря уже о С++ с его примудростями.
CC>Managed от идиотов все равно не спасает.
А кто-то говорил что спасает?
А самое главное что вообще ничего не спасает от идиотов-менеджеров, которые думают что managed спасает от идиотов-программистов.

Здравствуйте, gandjustas, Вы писали:

G>>>Конечно критическая секция дает тормоза. Кто сказал что параллельность бесплатно дается?
CC>>Она не бесплатная, да. Но она вообще то обеспечивается дешевле, чем тупо натыкать critical section.
G>Не всегда. При работе со списком свободных блоков например, без критической секции вряд ли что-то получится.
Ну, если его реализовывать как ты его описываешь, с проходом O(n) по нему то да.

G>надо разделять данные между потоками и\или использовать атомные операции.
G>второе далеко не всегда доступно (в C++ например не доступно при выделении памяти).
Ты про что вообще?

CC>>Есть еще тут мега-чел Remark, он тебе много может рассказать.
G>Я его уже перечитал.
Осталось понять те идеи о которых он пишет.

G>Кроме того deferred очередь ужасно будет работать при использовании пула потоков.
Почему?

Здравствуйте, CreatorCray, Вы писали:

G>>надо разделять данные между потоками и\или использовать атомные операции.
G>>второе далеко не всегда доступно (в C++ например не доступно при выделении памяти).
CC>Ты про что вообще?
В .NET насколько я понимаю выделение памяти реализовано как interlocked add указателя.

G>>Кроме того deferred очередь ужасно будет работать при использовании пула потоков.
CC>Почему?
Если память выделяется в одном потоке, а освобождается в другом, то реальное освобождение может произойти очень нескоро, а прогнозировать такое развите событий с пулом потоков сложно.

CC>По своей сути С++ позволяет реализовать какой угодно аллокатор.
CC>Сравнение в таком случае С++ аллокатора (который может быть вообще любым) с конкретной реализацией GC не имеет смысла по определению.

Как на C++ реализуется перемещающий менеджер памяти? Скажем, как подменить глобальные new и delete своим менеджером памяти, чтобы он мог по запросу проводить дефрагментацию своего пула?

Если есть поддержка языка и среды, то всё понятно, мы просто копируем объекты в памяти (их размеры и положение заведомо известны). Причём если на них есть ссылки, то мы эти ссылки перезаписываем, так как у CLR есть информация о том, что является ссылкой, а что нет.

Как быть в C++, где возможно такое:

struct {
  bool tag;
  union {
    boost::int32_t integer;
    int* pointer;
  } value;
} discriminatedUnion = {};

плюс те же static_cast<void*> и reinterpret_cast<>?

Здравствуйте, Qbit86, Вы писали:

CC>>По своей сути С++ позволяет реализовать какой угодно аллокатор.
CC>>Сравнение в таком случае С++ аллокатора (который может быть вообще любым) с конкретной реализацией GC не имеет смысла по определению.

Q>Как на C++ реализуется перемещающий менеджер памяти?
Можно.
Но с заменой указателей на обёртки и вводом ограничений на использование сырых указателей.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, CreatorCray, Вы писали:

G>>>надо разделять данные между потоками и\или использовать атомные операции.
G>>>второе далеко не всегда доступно (в C++ например не доступно при выделении памяти).
CC>>Ты про что вообще?
G>В .NET насколько я понимаю выделение памяти реализовано как interlocked add указателя.
Понятнее не стало.
Что именно ты имел в виду под "второе далеко не всегда доступно (в C++ например не доступно при выделении памяти)."?
Аллокацию в С++ через инкремент указателя сделать можно. Вот только с деаллокацией придется погеморроиться.
Не надо тупо копировать решения их других платформ с их особенностями.

Здравствуйте, gandjustas, Вы писали:

G>В .NET насколько я понимаю выделение памяти реализовано как interlocked add указателя.

Насколько я понимаю, interlocked add работает только для одноядерной машины. И то я не уверен... Тут надо курить семантику освобождения. На многоядерной машине и intelocked не нужен. Просто add. Ну и проверка на достижение границы 256Kb куска.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Qbit86, Вы писали:

CC>>>По своей сути С++ позволяет реализовать какой угодно аллокатор.
CC>>>Сравнение в таком случае С++ аллокатора (который может быть вообще любым) с конкретной реализацией GC не имеет смысла по определению.

Q>>Как на C++ реализуется перемещающий менеджер памяти?
CC>Можно.
CC>Но с заменой указателей на обёртки и вводом ограничений на использование сырых указателей.

Точно. Еще у Джеффа Элждера набросок был в книге.

Здравствуйте, samius, Вы писали:

S>Насколько я понимаю, interlocked add работает только для одноядерной машины. И то я не уверен... Тут надо курить семантику освобождения. На многоядерной машине и intelocked не нужен. Просто add. Ну и проверка на достижение границы 256Kb куска.
Вааааау!

Всё совсем наоборот.

Q>>Как на C++ реализуется перемещающий менеджер памяти?
CC>Можно. Но с заменой указателей на обёртки...

Я правильно понимаю, что:
1) Такой менеджер нельзя внедрить прозрачно — сломается код как твоей библиотеки, так и пользовательский код.
2) Увеличится расход памяти на каждый указатель.
3) Добавится лишний уровень косвенности при вызове.
4) Ухудшится cache locality, как пространственная, так и временная?

Насколько просто будет реализовать такую обёртку, с корректным учётом квалификаторов const и volatile и их комбинаций?

CC>...и вводом ограничений на использование сырых указателей.

Это как? Написать в хэдере комментарий «Сырые указатели — ни-ни!»
Обычные ссылки тоже нельзя будет использовать? И функции, принимающие что-нибудь по ссылке (на константу)?

Здравствуйте, Qbit86, Вы писали:

Q>>>Как на C++ реализуется перемещающий менеджер памяти?
CC>>Можно. Но с заменой указателей на обёртки...
Q>Я правильно понимаю, что:
По большей части правильно, хотя кое что implementation specific.

Неправильно только одно: зачем на С++ реализовывать такой аллокатор?
Пользы от него будет меньше чем неудобств.
Более того, зачем его реализовывать как глобальный?
К примеру стоит прикручивать нечто подобное только для алгоритмов, у которых фрагментация памяти является побочным эффектом.

Еще раз говорю: не надо тупо копировать идеи и подходы из других платформ.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, samius, Вы писали:

S>>Насколько я понимаю, interlocked add работает только для одноядерной машины. И то я не уверен... Тут надо курить семантику освобождения. На многоядерной машине и intelocked не нужен. Просто add. Ну и проверка на достижение границы 256Kb куска.
CC>Вааааау!

CC>Всё совсем наоборот.

Ну тогда уж просвети, кому нужно наоборот, если

В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. (С) Рихтер. CLR via C#

Нафига там interlocked?

Ох блин, знатоки-теоретики

Здравствуйте, samius, Вы писали:

CC>>Всё совсем наоборот.
S>
S>Ну тогда уж просвети, кому нужно наоборот, если
S>

В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. (С) Рихтер. CLR via C#

S>Нафига там interlocked?

S>Ох блин, знатоки-теоретики
Ага.
Вот и расскажи мне, знаток-теоретик, какой нафиг интерлокед может быть в таком случае на однояйцевой машине, когда одновременно выполняется только 1 поток.
С чем оно интерлокит то?

Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, gandjustas, Вы писали:
G>>Читать больше надо. От константности отказались как раз в силу сложности обеспечения честной константности.
Х>а теперь расскажи мне, в чём сложность обеспечения четной константности, если даже C++ ето отлавливает на етапе компиляции? если в с++ запретить касты, разрушающие константность то окромя прямой работы с памятью возможностей изменить константный объект нет, почему же весь такой сейфанутый C# не одолел модификатор const?

Также компании Microsoft очень сложно предусмотреть в CLR возможность проверки неизменности констант-объектов или констант-параметров. CLR пришлось бы при каждой операции записи проверять, не выполняется ли запись в объект-константу, а это сильно снизит эффективность работы программы. Есте ственно, что обнаружение нарушения должно приводить к генерации исключения. Более того, поддержка констант создает дополнительные сложности для разработчиков. В частности, при наследовании неизменяемого типа, производные типы должны соблюдать это ограничение. Кроме того, неизменяемый тип, скорее всего, должен состоять из полей, которые тоже представляют собой неизменяемые типы.

(c)Рихтер

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, samius, Вы писали:

S>>Ох блин, знатоки-теоретики
CC>Ага.
CC>Вот и расскажи мне, знаток-теоретик, какой нафиг интерлокед может быть в таком случае на однояйцевой машине, когда одновременно выполняется только 1 поток.
CC>С чем оно интерлокит то?

Я ж написал, что не уверен в случае одноядерной машины. Но что в многоядерной его точно нет. А ты сказал, что все наоборот. Вот и рассказывай нафига интерлокед на многоядерной машине.

Здравствуйте, samius, Вы писали:

S>Я ж написал, что не уверен в случае одноядерной машины. Но что в многоядерной его точно нет. А ты сказал, что все наоборот. Вот и рассказывай нафига интерлокед на многоядерной машине.
Да потому, что интерлокед как таковой только для многоядерной и нужен.

Безотносительно к принципам организации менеджера памяти в .NET