Vladislav
как сейчас в boehm сделано?
Aidar
В D, go есть же
Aidar
Или где там
babysitter
http://www.hboehm.info/gc/
Aidar
Они тоже статически линкуются
Anatoly
http://www.hboehm.info/gc/
"garbage collecting replacement for C malloc or C++ new. " Спасибо тебе :))
Denis
сапэпро наводнили непонятым спамам, так что тут спрошу
Denis
Понадобилась структура данных Trie. Префексное дерево
Denis
Гуглил всю ночь, и нагуглил одну реализацию, которая страшно выглядит
Denis
Может есть в бусте что-то похожее?
Cinder
рк просто не может в сборку мусора с циклическими ссылками
Anatoly
rc gc - форма gc. Это в том числе мнение сатера
По сути да, по реализации нет. Врожденный случай какой-то
cyber
https://habrahabr.ru/post/282544/
на тему gc в с++
Cinder
Любой указатель внутрь выделенной области держит эту область. Я даже больше скажу: любая последовательность байт, которую можно интерпретировать как указатель держит область, в которую указывает. И кресты тут не причём. В сишке также. Это конструкция недогц боехемгц
Cinder
как сейчас в boehm сделано?
Anatoly
https://habrahabr.ru/post/282544/
на тему gc в с++
Это попытка его реализации, но это не он всё же. Зато интересно что людям он нужен в плюсах
Anatoly
Я считаю иначе. И реализовать его для плюсов полноценно вряд ли удастся.
Anatoly
И не нужно
Vladislav
Любой указатель внутрь выделенной области держит эту область. Я даже больше скажу: любая последовательность байт, которую можно интерпретировать как указатель держит область, в которую указывает. И кресты тут не причём. В сишке также. Это конструкция недогц боехемгц
вопрос был о том, кто инициирует сборку
Vladislav
рк просто не может в сборку мусора с циклическими ссылками
из других минусов - overhead на создание ссылок и непредсказуемое время работы деалокации ссылки
babysitter
это такой ответ ради ответа. очевидно, что умные указатели — это гк, но говорить об этом в разговоре про нормальный сборщик даже смысла не вижу.
Anonymous
++
Cinder
из других минусов - overhead на создание ссылок и непредсказуемое время работы деалокации ссылки
а ещё непредсказуемая глубина рекурсии
Cinder
стека
babysitter
Может есть в бусте что-то похожее?
я когда-то тоже гуглил. раз ты ночь гуглил, то наверное знаешь даже больше, чем я. вот эту еще находил, она вроде не такая мертвая
https://github.com/ytakano/radix_tree
Крылатый
https://medium.com/@phostershop/building-a-c-hybrid-spin-mutex-f98de535b4ac#.6lf3aanpb
Square
https://medium.com/@phostershop/building-a-c-hybrid-spin-mutex-f98de535b4ac#.6lf3aanpb
преамбула агонь!)
да и статья доставляет. мне вообще многопточные штуки нравятся всякие
Square
а вот тут рекомендую про локфри, атомики и скорость!
http://moodycamel.com/blog/2014/detailed-design-of-a-lock-free-queue
🦥Alex Fails
а вот тут рекомендую про локфри, атомики и скорость!
http://moodycamel.com/blog/2014/detailed-design-of-a-lock-free-queue
😍 #lockfree #concurrency
Evgenii
😍 #lockfree #concurrency
Вот это серия хороша кстати https://habrahabr.ru/post/314948/
Mikhail
Личное мое имхо. Чем возиться с этими lock free структурами данных проще разобраться как реализовывать кооперативную многозадачность на плюсах и делать количество потоков равное количество ядер, и каждое независимо от другого. А внутри потоков все раскинуто по эвентам.
Mikhail
А так эти лок фрии структуры поощеряют потоковый ад внутри приложения
Artem
https://twitter.com/HookTM/status/807622367144865793
Square
А так эти лок фрии структуры поощеряют потоковый ад внутри приложения
А как ты между потоками будешь данные гонять?
Square
Когда тебе надо чертовски быстро
Mikhail
Ну во первых не нужно данные между потоками гонять
Square
А вообще мне атомики полюбились, особенно если билдить интеловским компилем - на xeon'ах в 2-3 раза быстрее
Mikhail
а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят
Square
а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят
Они всегда прокатывают
Square
Но если задача выжать максимум из железа
Square
Например разбирать 10ge на лету :D
Square
а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят
Но в любом случае со своим уставом в чужой монастырь не буду лезть.
Мне локфри доставляет и что самое главное решает проблемы
Square
Я поделился тем, что считаю достойным
Square
А статья там реально годная
Mikhail
Хорошо, допустим что тебе нужна максимальная производительность. Во первых, если количество потоков больше количества ядер - ты быдешь тратить дополнительное время на переключение процесса. Во вторых, у ядер процессора нет доступа напрямую ко всей оперативной памяти, есть только свой участок, или его вообще нет, и тогда он обращается к памяти через соседнее ядро.
🦥Alex Fails
а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят
мьютексы да, но они обычно много переключений контекста требуют. Поэтому придумывают fast mutexes, lock-free data types и прочую ересь)
Mikhail
И хорошо если требуемая память будет в прямом доступе у соседнего ядра, а не у еще соседнего
Artem
была у меня схожая задача. Нормальная буферизация по писателям + мьютексы победили решение с локфри
Square
Хорошо, допустим что тебе нужна максимальная производительность. Во первых, если количество потоков больше количества ядер - ты быдешь тратить дополнительное время на переключение процесса. Во вторых, у ядер процессора нет доступа напрямую ко всей оперативной памяти, есть только свой участок, или его вообще нет, и тогда он обращается к памяти через соседнее ядро.
Это все пройдено было. У меня есть имплементация, которая жарит нормально и всех устраивает
Mikhail
о. второе - это же нума
Так и что? Я к тому, что если ты шаришь данные между потоками, эти данные все равно будут находить я определенном доступе ядра. А если ты создашь несколько потоков на одном ядре, будешь терять время на переключение контекста
🦥Alex Fails
дак я не спорю)
Mikhail
Это все пройдено было. У меня есть имплементация, которая жарит нормально и всех устраивает
Победить можно все что угодно, но многопоточные локфри решения всегда будут страдать этими недостатками
Mikhail
в то время как кооперативная многозадочность эти проблемы не создает
🦥Alex Fails
можно совместить N тредов на N ядер и локфри
Mikhail
🦥Alex Fails
достойный компромисс)
Mikhail
можно совместить N тредов на N ядер и локфри
Ну я же уже сказал, если у тебя будет количество потоков больше чем количество ядер, будешь терять на переключение контекста
Mikhail
Речь шла о максимальной производительности
Square
Ибо hyperthreading
Mikhail
так вот она доступна только при количестве ядер равное количеству потоков и отсутсвия общих данных между потоками
Alexey
Ну я же уже сказал, если у тебя будет количество потоков больше чем количество ядер, будешь терять на переключение контекста
так стоп.. а кто сказал, что если у тебя 16 потокв и 16 ядер, то тебе достанется каждому потоку по ядру
Mikhail
Square
Mikhail
Определенный поток определенному ядру
Mikhail
и потоки
Square
Affinity*
Mikhail
по крайней мере через апи системы точно
Mikhail
как там в современном с++ не знаю
Alexey
по крайней мере через апи системы точно
ты в любом случае такие вещи будешь делать через апи системы