Обсуждение 2020-04-17 про сборку мусора
Добавлено: 17.04.20 15:33
Из телеграма:
Вот с ячейками, в отличии от объектов, код компилируется.
Я думаю, что реализацию lock-free ядра а2 от Флориана, можно считать современной реализацией soft real-time a2
Можно диссер Флориана почитать
Вовсе не обязательно есть stop world в сборщиках мусора
Вроде бы в GC Azul есть сборщик мусора без "остановки мира"
Алгоритмы неблокирущего сборщика мусора существуют 100%.
В книге по компиляторам ( книга драконов? Не вспомню сходу) есть перечень на полстраницы.
Нашёл такую вот работу:
https://www.usenix.org/legacy/events/ve ... -click.pdf
Я хотел предложить пример про часы, которые просто считают время, и потом смотрим, насколько они отстали. Но поскольку может быть более одного рилтайм-треда, то они могут отстать по другой причине.
Я тёмен в драйверах, но я так понимаю, что иногда там важна реакция точно во время. Такие операции должны происходить в эксклюзивном режиме, тоже такой вот stop the world. Т.е., чтобы построить рилтайм приложение в ОС, нужно знать характеристики всех драйверов.
И вот ещё есть тема на лоре:
https://www.linux.org.ru/forum/development/13779416
2017-й год, все только присматривались
Дальше я ещё пытался прогуглить стоимость барьеров чтения/записи, т.к. есть смутное воспоминание, что они чертовски дороги.
И как раз по ссылке с pauseless сборкой мусора написано:
Денис Будяк, [17.04.20 15:04]
Read barriers, on the other hand, are rarely used in production
systems despite a wealth of academic research because of the
high mutator cost they usually incur.
Денис Будяк, [17.04.20 15:04]
Т.е. azul имеет свою цену, даже если он и решает проблему
Даже CAS не такой уж дешёвый - на интелах он блокирует системную шину.
https://habr.com/ru/post/195948/
Денис Будяк, [17.04.20 15:08]
А как обстоит дело с производительностью атомарных примитивов?
Современные процессоры настолько сложны и непредсказуемы, что изготовители не дают каких-то однозначных гарантий длительности тех или иных инструкций, тем более атомарных, в работе которых задействованы внутренняя синхронизация, сигнализация по шинам процессора и пр. Существует довольно большое число работ, в которых авторы пытаются замерить длительность инструкций процессоров. Я приведу измерения из [McKen05]. В этой работе авторы, помимо прочего, сравнивают длительность атомарного инкремента и примитива CAS с длительностью операции nop (no-operation). Итак, для Intel Xeon 3.06 ГГц (образца 2005 года) атомарный инкремент имеет длительность 400 nop, CAS – 850 – 1000 nop.
Денис Будяк, [17.04.20 15:08]
Справедливости ради стоит заметить, что, по моим ощущениям, с каждым новым поколением архитектуры Intel Core примитив CAS становится всё быстрее, видимо, инженеры Intel немало сил вкладывают в совершенствование микроархитектуры.
Денис Будяк, [17.04.20 15:09]
https://books.google.ru/books?id=ueXJCg ... us&f=false
Денис Будяк, [17.04.20 15:09]
см. чуть выше Listing 8.1
Это отдельные темы в общем-то, просто неблокирующие алгоритмы, наряду с другими драйверами, затрудняют достижение рилтайма. В любом случае, если в системе есть паузы, их нужно учитывать для создания гипотетического, скажем так, телефона на базе этой платформы. Просто паузы от сборщика мусора обычно менее предсказуемы. Спасибо, я изучу конечно, что там такого в сборщике мусора сделано, но пока что я не верю, что там предсказуемые паузы.
Вот с ячейками, в отличии от объектов, код компилируется.
Я думаю, что реализацию lock-free ядра а2 от Флориана, можно считать современной реализацией soft real-time a2
Можно диссер Флориана почитать
Вовсе не обязательно есть stop world в сборщиках мусора
Вроде бы в GC Azul есть сборщик мусора без "остановки мира"
Алгоритмы неблокирущего сборщика мусора существуют 100%.
В книге по компиляторам ( книга драконов? Не вспомню сходу) есть перечень на полстраницы.
Нашёл такую вот работу:
https://www.usenix.org/legacy/events/ve ... -click.pdf
Я хотел предложить пример про часы, которые просто считают время, и потом смотрим, насколько они отстали. Но поскольку может быть более одного рилтайм-треда, то они могут отстать по другой причине.
Я тёмен в драйверах, но я так понимаю, что иногда там важна реакция точно во время. Такие операции должны происходить в эксклюзивном режиме, тоже такой вот stop the world. Т.е., чтобы построить рилтайм приложение в ОС, нужно знать характеристики всех драйверов.
И вот ещё есть тема на лоре:
https://www.linux.org.ru/forum/development/13779416
2017-й год, все только присматривались
Дальше я ещё пытался прогуглить стоимость барьеров чтения/записи, т.к. есть смутное воспоминание, что они чертовски дороги.
И как раз по ссылке с pauseless сборкой мусора написано:
Денис Будяк, [17.04.20 15:04]
Read barriers, on the other hand, are rarely used in production
systems despite a wealth of academic research because of the
high mutator cost they usually incur.
Денис Будяк, [17.04.20 15:04]
Т.е. azul имеет свою цену, даже если он и решает проблему
Даже CAS не такой уж дешёвый - на интелах он блокирует системную шину.
https://habr.com/ru/post/195948/
Денис Будяк, [17.04.20 15:08]
А как обстоит дело с производительностью атомарных примитивов?
Современные процессоры настолько сложны и непредсказуемы, что изготовители не дают каких-то однозначных гарантий длительности тех или иных инструкций, тем более атомарных, в работе которых задействованы внутренняя синхронизация, сигнализация по шинам процессора и пр. Существует довольно большое число работ, в которых авторы пытаются замерить длительность инструкций процессоров. Я приведу измерения из [McKen05]. В этой работе авторы, помимо прочего, сравнивают длительность атомарного инкремента и примитива CAS с длительностью операции nop (no-operation). Итак, для Intel Xeon 3.06 ГГц (образца 2005 года) атомарный инкремент имеет длительность 400 nop, CAS – 850 – 1000 nop.
Денис Будяк, [17.04.20 15:08]
Справедливости ради стоит заметить, что, по моим ощущениям, с каждым новым поколением архитектуры Intel Core примитив CAS становится всё быстрее, видимо, инженеры Intel немало сил вкладывают в совершенствование микроархитектуры.
Денис Будяк, [17.04.20 15:09]
https://books.google.ru/books?id=ueXJCg ... us&f=false
Денис Будяк, [17.04.20 15:09]
см. чуть выше Listing 8.1
Это отдельные темы в общем-то, просто неблокирующие алгоритмы, наряду с другими драйверами, затрудняют достижение рилтайма. В любом случае, если в системе есть паузы, их нужно учитывать для создания гипотетического, скажем так, телефона на базе этой платформы. Просто паузы от сборщика мусора обычно менее предсказуемы. Спасибо, я изучу конечно, что там такого в сборщике мусора сделано, но пока что я не верю, что там предсказуемые паузы.