Как сторонний наблюдатель, для меня "Для репликации данных в реальном времени… много разных инструментов" (далее 6 разных вариантов) не реклама Кафки, а большое предостережение. Я бы задумался что заставило Убер, ЛинкедИн и Сейслфорз тратить свое время на создание велосипедов, почему не воспользовались существующими? Что так кардинально плохо в официальных решениях, что вместо использования открытости и исправления существующих решений, все они делают полностью своё?
Сообщая такую новость, нельзя пропускать особенности Техасского патентного "правосудия" (под видом которым *** организовали фабрику обслуживания патентных троллей), и что большинство местных решений опровергаются судом высшей инстанции.
С (целочисленными) последовательностями и Фибоначчи в частности есть засада, они быстро выходят за размер целого числа. Сотое число Фибоначчи уже не влезает в 64 бита. Так что если считать сложность алгоритма честно, то нужно учитывать что умножение чисел выполняется не за константу, а становится дороже при росте чисел :). Получится уже не логарифм.
Исправьте пункт насчёт Теслы и Убера. В оригинале идёт речь про две разные аварии, в одной оператор Убера сбил пешехода, в другой водитель Теслы разбился. Никакого "автомобиля Tesla из автопарка Uber" нет, у Убера была Вольво, как раз она и на фото помятая.
Спасибо, хороший обзор.
Совет: использовать одни и те же единицы измерения. Скажем, читателя может испугать "колоссальное давление – более 400 ГПа", но это "всего лишь" 4 миллиона атмосфер, что конечно очень много, но уже близко к встречавшимся в статье, скажем, 2.6 миллиона атмосфер.
Интересно, ClickHouse такие выражения оптимизирует?
Тот же SUM поверх окна вроде ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW всеми движками вычисляется инкрементально, то есть весь результат будет вычислен за линейное время. sumArray(arrayMap(arraySlice)) если делать "по простому" создаст N массивов, будет считать сумму по каждому заново, и общая стоимость будет квадратичной. Теоретически и такое можно распознать и оптимизировать, но поскольку выражения более общие, то гораздо сложнее.
Да, типичный fang :) Только несколько поправок по опыту МС и Гугла.
У microsoft нет монорепо, и подразделения слишком не доверяют друг другу чтобы использовать общий репо. Мода на монорепо пришла из Гугла, но там большая команда занимается его поддержкой и тулзами по автоматическому рефакторингу таких репозиториев.
Обилие собственных «велосипедов» тоже пришло из Гугла. В Майкрософте, благодаря тому что у каждой группы свой репо, каждая группа может изобрести конечное количество велосипедов. Когда репо общее, то и велосипеды общие, так что их много :)
А вот «засунут на проект, где у тебя меньше всего опыта, а область, где у тебя есть знания, отдадут человеку, который в ней не разбирается» — это уже типичный Майкрософт.
Переработки это тоже Майкрософт (хотя зависит от группы). В Гугле переработки не приняты, а за дежурства всегда платят.
К счастью, Эппл не совсем удалила субпиксельное сглаживание из macOS в 2018 году :). А то уже слишком привык подключать к маку 4k, а из-за короны пришлось пока работать на 1440. Они удалили это только из настроек в UI, внутри пока все есть, и включается из командной строки. Моя теория заговора, удалили чтобы продать кучу новых фирменных мониторов (стоят они у Эппла не дешево). Вот чудо команда:
А над тем, чтобы регулярно обновлять bigquery snapshot тоже вы работаете?
Они писали что планируют регулярно обновлять базу OSM в bigquery,
но пока там та же версия что опубликовали изначально.
Насчёт применения кнопки, у сигнализации Nest есть удобная функция. Для установленных внутри датчиков можно разрешить краткосрочное именно этого отключение датчика кнопкой. То есть чтобы открыть дверь не надо идти отключать всю сигнализацию, достаточно нажать кнопку и открыть дверь. Конечно это trade-off безопасности за удобство, но удобный :)
Дополнительные параметры вряд-ли подойдут, придется при добавлении каждого нового параметра модифицировать все существующие определения., Скорее надо добавить макро — XMACRO, YMACRO и так далее, все с разным числом аргументов. Это по крайней мере можно поддерживать.
Но перед включением заголовка надо будет определять их всех. Выглядеть всё равно будет ужасно.
То есть для узкой задачи как у вас — макро подходит и наверное что-то улучшает. Для общей задачи, стоявшей перед МС — они сделали более менее правильный выбор.
Майкрософтовский XML поддерживает гораздо больше возможностей — множественные counter sets, разные типы счётчиков, дополнительная информация, скажем description. Макросы ОК для ограниченного случая, но использование внешнего описания даёт гораздо больше функциональности ценой всего-то запуска генератора при добавлении счётчика (что обычно довольно редко).
Я бы в укор МС поставил только использование XML вместо создания простенького DSL для счётчиков. Но время такое было, XML использовался где надо и не надо :)
Это, кстати, соответствует майкрософтовской документации (см мой коммент выше), что ^0 это индекс за-концом массива (а не последний как в статье), ^1 это последний элемент, а ^2 предпоследний.
Не, это как раз нормальное и ожидаемое поведение в С-подобных языках.
Вот если бы было как описал автор, то последнее значение в Range не включено, если индекс с начала, то включено, если индекс с конца — я бы решил что что-то не так.
Я думаю с операторами просто — унарный оператор `~` уже есть. Так что использование ~0 создало бы неоднозначность в грамматике — то ли это индексирование с конца, то ли побитное инвертирование, как раньше. Поэтому добавили унарный оператор ^. Он, кстати, никак не мешает добавить позже бинарный оператор ^ для возведения в степень.
Знак вопроса уже используется в подобных местах, скажем x ?? -1, возвращает х, если тот не пустой, или -1. Так же логично сделали x?.foo, x?[0]. Менять поведение по умолчанию и семантику существующего кода не хотят, ввели новые операторы.
The ^0 index is the same as sequence[sequence.Length]. Note that sequence[^0] does throw an exception, just as sequence[sequence.Length] does.
То есть ^0 это не последний элемент, как написано в статье, а индекс за-последним. Индексировать по нему нельзя, выбросится исключение! Это то же самое, что collection::end() в С++.
В Майкрософтовском предложении для взятия последнего элемента есть пример
var lastItem = list[^1]; // list[Index.CreateFromEnd(1)]
Разобравшись с индексами, становится понятно, что никакой путаницы с тем, включается ли последний элемент диапазона, нет — он никогда не включается! Независимо от того, берется ли последний индекс в диапазоне с начала или с конца.
[0..^0] работает и описывает весь массив именно потому что второй индекс ^0 не включается, иначе бы бросалось исключение.
(* описываем кто у нас есть *)
Things == { "Man", "Goat", "Wolf", "Cabbage" }
(* вначале никто не пересек реку *)
Init == locs = [x \in Things |-> FALSE]
(* условие безопасности: козел с человеком либо не там где волк или капуста *)
IsSafe == \/ locs'["Goat"] = locs'["Man"]
\/ (/\ locs'["Goat"] /= locs'["Wolf"]
/\ locs'["Goat"] /= locs'["Cabbage"])
(* следующее состояние после пересечения реки с "х" - "х" и человек меняют сторону реки *)
CrossWith(x) == /\ locs["Man"] = locs[x]
/\ locs' = [locs EXCEPT !["Man"] = ~locs[x], ![x] = ~locs[x]]
(* шаг это пересечение реки, можно с кем угодно из Things *)
Next == /\ (\E x \in Things : CrossWith(x))
/\ IsSafe
(* хотим чтобы все пересекли реку *)
IsDone == locs = [x \in Things |-> TRUE]
Я про то, что те кому нужен coremark / watt — и так на ARM, MIPS, и Байкал смотрят. А те, кто смотрит на производительность и покупает Интел — будут покупать.
То есть эта уязвимость ни для одной из этих групп ровно ничего не поменяла, Интел даже со всеми патчами быстрее, а ARM и MIPS по прежнему экономичнее. Может измениться немного выбор внутри одной группы, скажем AMD vs Intel — но даже это довольно незначительно. Но идти с Интела на Байкал из-за этих уязвимостей это сумасшествие.
Baikal-T1. Coremark: 12k.
Intel i7-3930k: 151k.
То есть производительность чуть меньше того, сколько современный Интел теряет от установки патча. Вряд-ли хорошая замена Интелу.
Как сторонний наблюдатель, для меня "Для репликации данных в реальном времени… много разных инструментов" (далее 6 разных вариантов) не реклама Кафки, а большое предостережение. Я бы задумался что заставило Убер, ЛинкедИн и Сейслфорз тратить свое время на создание велосипедов, почему не воспользовались существующими? Что так кардинально плохо в официальных решениях, что вместо использования открытости и исправления существующих решений, все они делают полностью своё?
Сообщая такую новость, нельзя пропускать особенности Техасского патентного "правосудия" (под видом которым *** организовали фабрику обслуживания патентных троллей), и что большинство местных решений опровергаются судом высшей инстанции.
Вот про Маршалл, Техас, как раз где нынешний случай:
https://www.bloomberg.com/opinion/articles/2017-05-25/the-texas-town-that-patent-trolls-built-j34rlmjc
Правда недавно появился конкурент, тоже техасский конечно:
https://www.ipwatchdog.com/2019/02/18/newest-patent-rocket-docket-waco-texas/id=106453/
С (целочисленными) последовательностями и Фибоначчи в частности есть засада, они быстро выходят за размер целого числа. Сотое число Фибоначчи уже не влезает в 64 бита. Так что если считать сложность алгоритма честно, то нужно учитывать что умножение чисел выполняется не за константу, а становится дороже при росте чисел :). Получится уже не логарифм.
Исправьте пункт насчёт Теслы и Убера. В оригинале идёт речь про две разные аварии, в одной оператор Убера сбил пешехода, в другой водитель Теслы разбился. Никакого "автомобиля Tesla из автопарка Uber" нет, у Убера была Вольво, как раз она и на фото помятая.
Спасибо, хороший обзор.
Совет: использовать одни и те же единицы измерения. Скажем, читателя может испугать "колоссальное давление – более 400 ГПа", но это "всего лишь" 4 миллиона атмосфер, что конечно очень много, но уже близко к встречавшимся в статье, скажем, 2.6 миллиона атмосфер.
Интересно, ClickHouse такие выражения оптимизирует?
Тот же SUM поверх окна вроде
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROWвсеми движками вычисляется инкрементально, то есть весь результат будет вычислен за линейное время.sumArray(arrayMap(arraySlice))если делать "по простому" создаст N массивов, будет считать сумму по каждому заново, и общая стоимость будет квадратичной. Теоретически и такое можно распознать и оптимизировать, но поскольку выражения более общие, то гораздо сложнее.У microsoft нет монорепо, и подразделения слишком не доверяют друг другу чтобы использовать общий репо. Мода на монорепо пришла из Гугла, но там большая команда занимается его поддержкой и тулзами по автоматическому рефакторингу таких репозиториев.
Обилие собственных «велосипедов» тоже пришло из Гугла. В Майкрософте, благодаря тому что у каждой группы свой репо, каждая группа может изобрести конечное количество велосипедов. Когда репо общее, то и велосипеды общие, так что их много :)
А вот «засунут на проект, где у тебя меньше всего опыта, а область, где у тебя есть знания, отдадут человеку, который в ней не разбирается» — это уже типичный Майкрософт.
Переработки это тоже Майкрософт (хотя зависит от группы). В Гугле переработки не приняты, а за дежурства всегда платят.
defaults write -globalDomain CGFontRenderingFontSmoothingDisabled -bool NOdefaults write -globalDomain AppleFontSmoothing -int 1
Последний параметр подобрать по вкусу, после этого перезагрузиться, и можно наслаждаться очень неплохой (почти как на виндоусе) картинкой на 1440.
Они писали что планируют регулярно обновлять базу OSM в bigquery,
но пока там та же версия что опубликовали изначально.
Насчёт применения кнопки, у сигнализации Nest есть удобная функция. Для установленных внутри датчиков можно разрешить краткосрочное именно этого отключение датчика кнопкой. То есть чтобы открыть дверь не надо идти отключать всю сигнализацию, достаточно нажать кнопку и открыть дверь. Конечно это trade-off безопасности за удобство, но удобный :)
Дополнительные параметры вряд-ли подойдут, придется при добавлении каждого нового параметра модифицировать все существующие определения., Скорее надо добавить макро — XMACRO, YMACRO и так далее, все с разным числом аргументов. Это по крайней мере можно поддерживать.
Но перед включением заголовка надо будет определять их всех. Выглядеть всё равно будет ужасно.
То есть для узкой задачи как у вас — макро подходит и наверное что-то улучшает. Для общей задачи, стоявшей перед МС — они сделали более менее правильный выбор.
Майкрософтовский XML поддерживает гораздо больше возможностей — множественные counter sets, разные типы счётчиков, дополнительная информация, скажем description. Макросы ОК для ограниченного случая, но использование внешнего описания даёт гораздо больше функциональности ценой всего-то запуска генератора при добавлении счётчика (что обычно довольно редко).
Я бы в укор МС поставил только использование XML вместо создания простенького DSL для счётчиков. Но время такое было, XML использовался где надо и не надо :)
Это, кстати, соответствует майкрософтовской документации (см мой коммент выше), что ^0 это индекс за-концом массива (а не последний как в статье), ^1 это последний элемент, а ^2 предпоследний.
0..^0 это тоже весь массив.
Тогда уже 0..^1.
Вот если бы было как описал автор, то последнее значение в Range не включено, если индекс с начала, то включено, если индекс с конца — я бы решил что что-то не так.
`~`уже есть. Так что использование ~0 создало бы неоднозначность в грамматике — то ли это индексирование с конца, то ли побитное инвертирование, как раньше. Поэтому добавили унарный оператор^. Он, кстати, никак не мешает добавить позже бинарный оператор^для возведения в степень.Знак вопроса уже используется в подобных местах, скажем
x ?? -1, возвращает х, если тот не пустой, или -1. Так же логично сделалиx?.foo, x?[0]. Менять поведение по умолчанию и семантику существующего кода не хотят, ввели новые операторы.docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/ranges
и в описании новых фич:
docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#indices-and-ranges
То есть ^0 это не последний элемент, как написано в статье, а индекс за-последним. Индексировать по нему нельзя, выбросится исключение! Это то же самое, что collection::end() в С++.
В Майкрософтовском предложении для взятия последнего элемента есть пример
Разобравшись с индексами, становится понятно, что никакой путаницы с тем, включается ли последний элемент диапазона, нет — он никогда не включается! Независимо от того, берется ли последний индекс в диапазоне с начала или с конца.
[0..^0] работает и описывает весь массив именно потому что второй индекс ^0 не включается, иначе бы бросалось исключение.
Я эту же задачу делал на Майкрософтовском (MSR) пруфере TLA.
Там похоже, но чуть проще на мой взгляд и выглядит математичнее.
Опишу кратко здесь, полный код можно найти на
https://github.com/mentin/tla/blob/master/river2/mega_crossing.tla
В TLA /\ обозначает "или", а \/ — "и", они для красоты пишутся и вначале тоже.
То есть эта уязвимость ни для одной из этих групп ровно ничего не поменяла, Интел даже со всеми патчами быстрее, а ARM и MIPS по прежнему экономичнее. Может измениться немного выбор внутри одной группы, скажем AMD vs Intel — но даже это довольно незначительно. Но идти с Интела на Байкал из-за этих уязвимостей это сумасшествие.
Intel i7-3930k: 151k.
То есть производительность чуть меньше того, сколько современный Интел теряет от установки патча. Вряд-ли хорошая замена Интелу.