The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Рассматривается возможность перевода NTPsec на язык Rust или Go, opennews (ok), 10-Янв-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


7. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +3 +/
Сообщение от Аноним (-), 10-Янв-17, 10:11 
да
Ответить | Правка | Наверх | Cообщить модератору

12. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –3 +/
Сообщение от Пользователь Debian (?), 10-Янв-17, 10:38 
> да

Нет. STW останавливает, а параллельная сборка -- нет.

Цитата из <https://blog.golang.org/go15gc>:

«
Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978. This is a deliberate divergence from most "enterprise" grade garbage collectors of today, and one that we believe is well suited to the properties of modern hardware and the latency requirements of modern software.

In a tri-color collector, every object is either white, grey, or black and we view the heap as a graph of connected objects. At the start of a GC cycle all objects are white. The GC visits all roots, which are objects directly accessible by the application such as globals and things on the stack, and colors these grey. The GC then chooses a grey object, blackens it, and then scans it for pointers to other objects. When this scan finds a pointer to a white object, it turns that object grey. This process repeats until there are no more grey objects. At this point, white objects are known to be unreachable and can be reused.

This all happens concurrently with the application, known as the mutator, changing pointers while the collector is running. Hence, the mutator must maintain the invariant that no black object points to a white object, lest the garbage collector lose track of an object installed in a part of the heap it has already visited. Maintaining this invariant is the job of the write barrier, which is a small function run by the mutator whenever a pointer in the heap is modified. Go’s write barrier colors the now-reachable object grey if it is currently white, ensuring that the garbage collector will eventually scan it for pointers.
»

Впрочем, запрещать GC в критических участках это логичная идея.

Ответить | Правка | Наверх | Cообщить модератору

13. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +16 +/
Сообщение от КО (?), 10-Янв-17, 10:43 
>Впрочем, запрещать GC в критических участках это логичная идея.

Программа коррекции датчика времени является таковой чуть более чем полностью.
А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно.

Правда тут в соседней новости собираются написать транслятор из C в Раст, чтоб PostgreSQL потянул. Как осилят - можно будет и NTP налету конвертить. :)
  

Ответить | Правка | Наверх | Cообщить модератору

47. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от A (?), 10-Янв-17, 14:20 
Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.
Ответить | Правка | Наверх | Cообщить модератору

59. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +1 +/
Сообщение от Аноним (-), 10-Янв-17, 15:55 
> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.

На хаскеле?

Ответить | Правка | Наверх | Cообщить модератору

80. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –2 +/
Сообщение от Аноним (-), 10-Янв-17, 19:10 
> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.

Учитывая что у мозиллы браузер превращается в тыкву и гуглхорм его обижает - скоро они кажется утратят способность раздавать гранты на разную концептуальную хну. А откуда они на это деньги будут брать? :)

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

65. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 10-Янв-17, 16:14 
> А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно.

Ну, блин, это ESR. Известный своими логичными и результативными достижениями. Правда наибольшую известность он почему-то снискал как холуй проприетарщиков.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

18. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +9 +/
Сообщение от Orduemail (ok), 10-Янв-17, 11:15 
Любой сборщик мусора периодически останавливает потоки выполнения, просто потому, что нет другого способа пересчитать объекты, ссылки на которые лежат в регистрах и на стеке. Другое дело, что некоторые алгоритмы, на самом деле даже большинство алгоритмов, стремятся свести такие остановки к минимуму. Например, выполнить максимум работы в бекграунде, из параллельного потока. Помечать области памяти, с которыми идёт работа, флагом ro, с тем чтобы проводить все манипуляции несмотря на то, что программа продолжает работать с объектами -- и это проходит гладко, если программа ничего не меняет, но в случае, если она вносит изменения, процессор выкидывает исключение, выполнение задачи прерывается, сборщик мусора обрабатывает исключение и позволяет программе продолжать выполнение. Там есть разные техники преодоления этих проблем, между прочим очень любопытные -- я читал книжку об этом запоем, кстати очень рекомендую в качестве увлекательного чтения какое-нибудь систематическое описание этих алгоритмов. Но финально всё сводится к тому, что останавливаются _все_ потоки, сборщик мусора из каждого потока выковыривает содержимое регистров и стековых фреймов, быстренько составляет список объектов достижимых при помощи регистров и стека, после чего позволяет программе продолжать работу, а сам заканчивает итерацию сборки мусора. В самых продвинутых алгоритмах, этот этап остановки очень короткий и неплохо масштабируется, потому что остановив все потоки на всех процессах, сборщик мусора сам начинает работать многопоточно, задействуя все процессоры, для того чтобы быстро-быстро всё сделать.

Но как бы там ни было, остановки, пускай и короткие, происходят, причём чем круче алгоритм, тем менее предсказуемо когда произойдёт остановка. Любая запись в память может привести к прерыванию и переключениям между ring3 и ring0. Периодически же будут возникать остановки типа stop-the-world. Это может быть неважно для десктопного приложения, но для синхронизации времени, где речь идёт о микросекундах -- это не вариант. Точнее не так: это может быть допустимо, и Раймонд говорит о том, что может быть "и так проканает", если паузы действительно будут измерятся небольшим числом микросекунд, как обещают go-фаги. Но может быть и не проканает.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –17 +/
Сообщение от лютый жабист__ (?), 10-Янв-17, 11:39 
Ох уж эти эксперты по сборке мусора опеннета 8))))) можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов.

А послушаешь местных аналитиков, так получается что программы на GO полчаса работают, потом час висят, мусор разгребают.

Ответить | Правка | Наверх | Cообщить модератору

23. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +7 +/
Сообщение от Orduemail (ok), 10-Янв-17, 12:05 
> можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов.

Об этом тебе лучше молчать. Если ты несколько часов активно удаляешь объекты (ну и создаёшь соответственно активно, чтобы было что удалять активно), а сборщик мусора при этом бездействует, то твоей программе место в каком-нибудь специальном загончике для прочих жаба программ, жрущих оперативную память гигабайтами.

Ответить | Правка | Наверх | Cообщить модератору

66. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –1 +/
Сообщение от Аноним (-), 10-Янв-17, 16:15 
> закончить) с того, что сборщик обычно включается раз в несколько часов
> и при активном удалении объектов.

По закону подлости он решит отпедалить все это именно тогда когда интересовало точное время. Которое после такой диверсии перестанет быть точным, очевидно. Ведь если мусор несколько часов не собирали - вклин будет надолго.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

102. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +1 +/
Сообщение от Аноним (-), 11-Янв-17, 00:33 
Есть реализации GC без Stop The World. Такая, например, используется в Erlang. Достигается это тем, что у каждого микропроцесса в Erlang'е своя куча.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

115. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 11-Янв-17, 12:19 
STW-то официально может и нет, но потоки останавливаются точно так же. Другое дело что паузы очень короткие и эрланг сам по себе просто тормоз для конкретно этой задачи.
Ответить | Правка | Наверх | Cообщить модератору

120. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 11-Янв-17, 18:41 
>STW-то официально может и нет, но потоки останавливаются точно так же.

Нет, не точно так же. Во-первых, не нужно синхронизировать остановку всех потоков, т.е. сами потоки не бывают остановлены на дольшее время чем нужно для сборки мусора в их конкретной куче. Во-вторых, остановка никогда не происходит в произвольном месте, обычно сборка мусора происходит при вызовах, выделяющих память, либо на блокирующих функциях типа ввода-вывода или, в случае erlang, отсылки-приёма сообщений. На том же хацкелле можно легко написать код, работающий в константной памяти и не дёргающий GC в принципе.

Erlang, кстати, не такой тормоз. Но других косяков у него до жопы :(

Ответить | Правка | Наверх | Cообщить модератору

55. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +1 +/
Сообщение от rshadow (ok), 10-Янв-17, 15:20 
В любом случае производительность рандомно проседает. Для реалтайма под нагрузкой GC наверно самое худшее решение.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

130. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от qsdg (ok), 12-Янв-17, 02:24 
В той статье где разработчики Go хвалятся их будущим супер-сборщиком мусора на самом деле на рассмотрено ни одно негативное последствие их решения. Они преподносят свою идею как нечто революционно новое, хотя на самом деле всё что они делают уже давно известно 10+ лет. Они просто выбирают все возможные компромиссы ради укорочения паузы сборки мусора (но, например, частота таких пауз у них возрастает). Вот более подробный анализ недостатков их hype-collector:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

И таки да, любой сборщик мусора требует STW, даже теоретически невозможно сделать по-другому. Другое дело, что если этот STW -- считанные микросекунды, то всем пофиг. Хотя проектам типа NTP может быть и не пофиг.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

76. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +1 +/
Сообщение от www2 (ok), 10-Янв-17, 18:08 
> да

Вытесняющая многозадачность, даже если в системе несколько ядер или процессоров, тоже прерывает выполнение программы. Выполняется ваша программа без сборщика мусора, а тут прерывание прилетает - диск сообщил, что прочитал заказанные секторы. Выполняется дальше - а тут сетевая карта сообщает, что она буфер пакетами наполнила. Особенно много подобных эффектов будет в нагруженных системах, где работает больше одной программы. Там сборка мусора может быть просто незаметной на общем фоне торможения.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру