Блог*
А кстати, кто из подписчиков Блог*а сейчас в Армении?
Полгода прошло, так что повторю вопрос. Кто из подписчиков сейчас в Армении?
(Сова, про тебя я помню)
(Сова, про тебя я помню)
🤔2👍1😁1
#prog #article
Biased reference counting: minimizing atomic operations in garbage collection (pdf)
Счётчики ссылок можно считать формой сборщика мусора. Как вариант сборки мусора этот подход привлекателен низким оверхедом по памяти и короткими паузами. Однако при прямолинейном использовании этот подход даёт довольно большой оверхед по времени исполнения: ссылки создаются и уничтожаются всё время. Если используемые счётчики атомарные — что абсолютно необходимо для корректной работы в многопоточном окружении — то возня с ними может составить заметную долю общего времени исполнения программы.
Традиционные подходы к оптимизации RC полагались на оптимизации компилятора, которые позволяют убирать операции инкремента и декремента, соответствующие друг другу, или на разделение операций изменения счётчиков и освобождения мёртвых объектов. Авторы данной статьи предлагают новый подход. Именно, они подмечают, что в реальных программах доля объектов, разделяемых между потоками, крайне невелика, и потому предлагают разделить единый счётчик ссылок на два: один для подсчёта ссылок на потоке, которому объект принадлежит, и один для всех остальных потоков. Операции с первым счётчиком могут быть сделаны обычными, неатомарными операциями, что позволяет снизить долю времени исполнения на манипуляции со счётчиками.
Более подробно детали реализации — вместе с очередями объектов для обработки граничных случаев — описаны в папире. Авторы реализовали свой подход в рантайме языка Swift — который использует счётчики ссылок с оптимизациями компилятора и немедленным освобождением объектов — и замерили влияние на производительность программ. Результаты показали, что подход авторов заметно снижает общее время исполнения программ и увеличивает пропускную способность "серверных", многопоточных программ, при этом давая крайне небольшое увеличение пиковой потребляемой памяти.
We implemented BRC in the Swift programming language runtime and evaluated it with various client and server programs. We found that BRC accelerated non-deferred RC. Specifically, it reduced the average execution time of client programs by 22.5%, and improved the average throughput of server programs by 7.3%.
Авторы также сделали синтетический бенчмарк, который симулирует исполнение программы с большим количеством разделяемых между потоками объектов и обнаружили, что их подход становится хуже оригинального по производительности при доле разделяемых объектов около 75% от их общего числа.
Biased reference counting: minimizing atomic operations in garbage collection (pdf)
Счётчики ссылок можно считать формой сборщика мусора. Как вариант сборки мусора этот подход привлекателен низким оверхедом по памяти и короткими паузами. Однако при прямолинейном использовании этот подход даёт довольно большой оверхед по времени исполнения: ссылки создаются и уничтожаются всё время. Если используемые счётчики атомарные — что абсолютно необходимо для корректной работы в многопоточном окружении — то возня с ними может составить заметную долю общего времени исполнения программы.
Традиционные подходы к оптимизации RC полагались на оптимизации компилятора, которые позволяют убирать операции инкремента и декремента, соответствующие друг другу, или на разделение операций изменения счётчиков и освобождения мёртвых объектов. Авторы данной статьи предлагают новый подход. Именно, они подмечают, что в реальных программах доля объектов, разделяемых между потоками, крайне невелика, и потому предлагают разделить единый счётчик ссылок на два: один для подсчёта ссылок на потоке, которому объект принадлежит, и один для всех остальных потоков. Операции с первым счётчиком могут быть сделаны обычными, неатомарными операциями, что позволяет снизить долю времени исполнения на манипуляции со счётчиками.
Более подробно детали реализации — вместе с очередями объектов для обработки граничных случаев — описаны в папире. Авторы реализовали свой подход в рантайме языка Swift — который использует счётчики ссылок с оптимизациями компилятора и немедленным освобождением объектов — и замерили влияние на производительность программ. Результаты показали, что подход авторов заметно снижает общее время исполнения программ и увеличивает пропускную способность "серверных", многопоточных программ, при этом давая крайне небольшое увеличение пиковой потребляемой памяти.
We implemented BRC in the Swift programming language runtime and evaluated it with various client and server programs. We found that BRC accelerated non-deferred RC. Specifically, it reduced the average execution time of client programs by 22.5%, and improved the average throughput of server programs by 7.3%.
Авторы также сделали синтетический бенчмарк, который симулирует исполнение программы с большим количеством разделяемых между потоками объектов и обнаружили, что их подход становится хуже оригинального по производительности при доле разделяемых объектов около 75% от их общего числа.
🔥5👍2🤔1
Блог*
#prog #article Biased reference counting: minimizing atomic operations in garbage collection (pdf) Счётчики ссылок можно считать формой сборщика мусора. Как вариант сборки мусора этот подход привлекателен низким оверхедом по памяти и короткими паузами. Однако…
В 2019 году группа исследователей реализовала PCIe драйвера на широком наборе языков и выкатила папир по результатам исследования. Про Swift там было сказано следующее:
Swift increments a reference counter for each object passed into a function and decreases it when leaving the function. This is done for every single packet as they are wrapped in Swift-native wrappers for bounds checks. There is no good way to disable this behavior for the wrapper objects while maintaining an idiomatic API for applications using the driver. A total of 76% of the CPU time is spent incrementing and decrementing reference counters. This is the only language runtime evaluated here that incurs a large cost even for objects that are never free’d
Это, судя по всему, наихудший случай для ARC в Swift, ибо в реальных программа доля времени исполнения, занятая из изменениями счётчиков, меньше. Но даже в реальных программах эта доля нетривиальна.
Swift increments a reference counter for each object passed into a function and decreases it when leaving the function. This is done for every single packet as they are wrapped in Swift-native wrappers for bounds checks. There is no good way to disable this behavior for the wrapper objects while maintaining an idiomatic API for applications using the driver. A total of 76% of the CPU time is spent incrementing and decrementing reference counters. This is the only language runtime evaluated here that incurs a large cost even for objects that are never free’d
Это, судя по всему, наихудший случай для ARC в Swift, ибо в реальных программа доля времени исполнения, занятая из изменениями счётчиков, меньше. Но даже в реальных программах эта доля нетривиальна.
GitHub
GitHub - ixy-languages/ixy-languages: A high-speed network driver written in C, Rust, C++, Go, C#, Java, OCaml, Haskell, Swift…
A high-speed network driver written in C, Rust, C++, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python - ixy-languages/ixy-languages
❤1