Size: a a a

2020 December 03

EK

Evgeny Khramtsov in ErlangRus
Anton Kuranda
ну если очень сильно теоретизировать, то можно к каждому серверу присобачить независимый источник каких-нибудь стабильных колебаний и один раз синхронизировать все эти источники, ну типа атомные часы к каждому серверу приделать

тогда, мне кажется, можно какие-то гарантии предоставлять

но в реальном мире это будет слишком дорого и походу ненужно
Google такое делает так-то
источник

AK

Anton Kuranda in ErlangRus
да ну нах, что они делают
источник

AK

Anton Kuranda in ErlangRus
я в качестве бреда написал если что
источник

AB

Alex Bubnov in ErlangRus
Anton Kuranda
да ну нах, что они делают
они, еяпп, для спаннера что-то такое делали, вот
One of the most surprising and inspired facets of Spanner is its use of atomic clocks and GPS clocks to give participating nodes really accurate wall time synchronization. The designers of Spanner call this "TrueTime", and it provides a tight bound on clock offset between any two nodes in the system.
источник

AK

Anton Kuranda in ErlangRus
бля, надо было патентовать идею(
источник

AB

Alex Bubnov in ErlangRus
https://research.google/pubs/pub39966/
The underlying time references used by TrueTime are GPS and atomic clocks.
источник

AK

Anton Kuranda in ErlangRus
я погуглил уже на самом деле и тоже это нашел - непонятно только, это было такими же измышлениями или они реально в прод запустили

я бы почитал вайт пейперы на тему, прямо очень интересно, взлетело ли
источник

AB

Alex Bubnov in ErlangRus
TrueTime is implemented by a set of time master machines per datacenter and a
timeslave daemon per machine. The majority of masters have GPS receivers with
dedicated antennas; these masters are separated physically to reduce the effects of
antenna failures, radio interference, and spoofing. The remaining masters (which we
refer to as Armageddon masters) are equipped with atomic clocks. An atomic clock is
not that expensive: the cost of an Armageddon master is of the same order as that of a
GPS master.
источник

EK

Evgeny Khramtsov in ErlangRus
Anton Kuranda
я погуглил уже на самом деле и тоже это нашел - непонятно только, это было такими же измышлениями или они реально в прод запустили

я бы почитал вайт пейперы на тему, прямо очень интересно, взлетело ли
для спаннера, да. Но это был конкретный фейл, потому что в 2014 году придумали hybrid logical clocks (HLC), которые делают то же самое
источник

AK

Anton Kuranda in ErlangRus
лучший канал для самообразования
источник

EK

Evgeny Khramtsov in ErlangRus
если кому-то тут нужно общее время с гарантией happened-before, то конечно лучше HLC заюзать, оно на коленке в 3 строчки пишется
источник

V

Vasilii Demidenok in ErlangRus
Поговорим о микробенчмарках.. есть код вида
get_val(1) -> val1;
get_val(2) -> val2;
...
get_val(N) -> valN.
И так порядка 50 бранчей. Вопрос - при матчинге оно будет достаточно умное чтобы прыгнуть на нужный бранч если он меньше 50, или будет перебирать все по одному? Потому что если последнее (это то как я помню что оно устроено), т есть идея скажем сложить всё это в какой-нибудь рекорд, для быстрого прыжка. Или что-то ещё замутить..
источник
2020 December 04

PK

Petr Kozorezov in ErlangRus
Там есть спец инструкция у бима для выбора нужного клоза без перебора, как я понимаю. Можешь в асм скомпилить посмотреть.
Кроме того я мерил на большом количестве элементов (больше сотни) get из мапы по атому от матчинга таком стиле не отличаются.
источник

V

Vasilii Demidenok in ErlangRus
у меня не атом, а чиселка. поэтому и думал за консантное время прыгать
источник

V

Vasilii Demidenok in ErlangRus
но гляну на асм, хорошее идея
источник

PK

Petr Kozorezov in ErlangRus
Там дальше асма нужно будет посмотреть реализацию этой инструкции в биме. До этого я не дошёл.
источник

D

Dim in ErlangRus
Vasilii Demidenok
Поговорим о микробенчмарках.. есть код вида
get_val(1) -> val1;
get_val(2) -> val2;
...
get_val(N) -> valN.
И так порядка 50 бранчей. Вопрос - при матчинге оно будет достаточно умное чтобы прыгнуть на нужный бранч если он меньше 50, или будет перебирать все по одному? Потому что если последнее (это то как я помню что оно устроено), т есть идея скажем сложить всё это в какой-нибудь рекорд, для быстрого прыжка. Или что-то ещё замутить..
Писал нечто подобное.
Только отображение было строка -> строка.
Как вариант постоянного и быстрого справочника.
Работало достаточно шустро при нескольких десятках тысяч инвариантов функции
источник

EK

Evgeny Khramtsov in ErlangRus
Vasilii Demidenok
Поговорим о микробенчмарках.. есть код вида
get_val(1) -> val1;
get_val(2) -> val2;
...
get_val(N) -> valN.
И так порядка 50 бранчей. Вопрос - при матчинге оно будет достаточно умное чтобы прыгнуть на нужный бранч если он меньше 50, или будет перебирать все по одному? Потому что если последнее (это то как я помню что оно устроено), т есть идея скажем сложить всё это в какой-нибудь рекорд, для быстрого прыжка. Или что-то ещё замутить..
да, будет быстро
источник

PK

Petr Kozorezov in ErlangRus
Vasilii Demidenok
Поговорим о микробенчмарках.. есть код вида
get_val(1) -> val1;
get_val(2) -> val2;
...
get_val(N) -> valN.
И так порядка 50 бранчей. Вопрос - при матчинге оно будет достаточно умное чтобы прыгнуть на нужный бранч если он меньше 50, или будет перебирать все по одному? Потому что если последнее (это то как я помню что оно устроено), т есть идея скажем сложить всё это в какой-нибудь рекорд, для быстрого прыжка. Или что-то ещё замутить..
посмотрел
external инструкцию зовут select_val
дальше она разворачивается в internal в зависимости от аргументов
для твоего случая когда аргменты натуральные числа и идут подряд (ну или почти, с небольшими пропусками) генерится jump_on_val которая просто делает jump на нужный вариант
т.е. — да, работает такой вариант максимально оптимально за константное время
источник

PG

Pig Greenest in ErlangRus
а когда вы собираете iolist, вы его делаете proper или improper?
источник