Я для себя сделал простой вывод, судя по всему, в яндексе не поставлен нормально процесс on-call/triage. Обычно, разработчик, который дежурит на on-call не чинит проблемы сам, у него тупо нет возможности это сделать. Его задача заключается в другом. А для того, чтобы собрать сломанный raid массив есть SRE.
Строка 21. У вас там динамический тип — std::array, а вы в него пишете как в объект другого типа.
Но в общем случае — memset использовать нельзя.
Так с этим никто и не спорил. Я спорил с тем что memcmp использовать вообще нельзя, автор именно так написал.
Попробуйте. Будет интересно на это посмотреть. Заодно расскажите сколько времени это у вас займёт.
Там ниже уже отметили, что размер блока другой. В принципе все можно очень тривиально сделать, если писать идиоматичный код (а в случае type pun, это использование временных переменных и memcpy). У меня вот что получилось — godbolt.org/z/h4p7jB но я взял за основу пример, который нашел ниже.
Как правило, автовекторизация сильно предпочтительнее, даже если нужно колдовать над кодом, чтобы он хорошо векторизовался, по следующей причине: зачастую векторизовать код вручную очень сложно, т.к. данные могут быть не выровнены в памяти или твой алгоритм может обрабатывать по 4 елемента за раз, а на вход ему могут дать 17. Все это геморно обрабатывать, а компилятор все это умеет делать за нас. В этом примере _mm_loadu_ps наплевать на выравнивание и алгоритм работает с данными фикс. длины, поэтому все выглядит очень просто и компактно. Но это только в данном примере.
Вот вам, пожалуйста, получите, распишитесь. Удачной отладки!
Начнем с того, что там UB из-за нарушения правил алиасинга в функции bar. Я вижу что именно хотелось показать и я с этим не спорю. Тем не менее это не значит что я не могу корректно использовать memcmp.
Вот именно потому что указатель на char… он и алисится со всем подряд, что влияет на производительность.
OK, я думал имеется ввиду другое. Но допустим, что то, что это является проблемой, нужно еще доказать.
Ну если вас Core Guidelines не волнуют и скорость работы кода тоже… то да, всё хорошо.
Написал автор пассивно агрессивного сэмпла с UB :)
Найдёте компилятор, способный свернуть foo во что-то подобное bar — заходите, посмеёмся вместе.
Я уверен, что смогу переписать ф-ю так, что она векторизуется нормально. Ну и в примере foo и bar работают по разному, если что.
Об округлении, в случае double и decimal, придется подумать один раз. С fixed point об округлении приходится думать намного чаще, т.к. у промежуточные значения не представимы однозначно как fixed point.
что для финансовых данных числа с плавающей точкой не годятся
Это одна из тех фраз, которые слышишь(видишь) в каждой второй статье или книге и которые не имеют никакого отношения к действительности. Финансовые расчеты как правило выполняются с использованием double (binary64 в терминах IEEE 754). Совершенно бессмысленно использовать decimal (decimal64) для всех вычислений. Вы все равно будете получать результат, который будет требовать округления (пример, я хочу посчитать сколько индийских рупий я могу купить на 1000 рублей, курс RUB/INR — 0.91 и результат 1098,901098901 рупий, binary64 и decimal64 могут представить это значение без потери точности, при этом мне придется округлить до 1098,90). При этом операции над decimal64 — дороже чем над binary64, т.к. реализуются программно. Бухгалтерия — другое дело, там использование decimal имеет какой-то смысл.
Я никогда не был пользователем яндекс.такси, только uber. Все вышеперечисленное произошло с водителями uber, спустя какое-то время после объединения. То что с вами ничего такого не произошло, это очень хорошо. Я тоже не могу пожаловаться на большинство поездок. Но так как я пользуюсь приложениями такси каждый день для любых поездок, даже небольшой риск нарваться на неадекватного водителя рано или поздно реализуется.
Естественно, проблемы были и до объединения, проблемы были и с водителями других сервисов. Но проблемы, связанные с безопасностью это не тоже самое, что проблемы с подачей машины или запахом в салоне. Проблемы с безопасностью у меня были только в убере и только после объединения с яндексом.
Возможность нормально доехать из точки А в точку Б никуда не делась.
Ключевое слово «нормально». Именно эта возможность куда-то делась. У яндекса большие проблемы с качеством. После покупки убера яндексом со мной произошло следующее:
водитель выехал на красный на перекресток, чуть не попал в ДТП.
водитель вез мою сестру и вел себя очень стремно, спрашивал не боится ли она ездить одна и ждет ли ее кто-нибудь.
водитель на лысой резине в гололед, пришлось прервать поездку.
водитель вел себя агрессивно, насколько я понял, он считал что я не настоящий пассажир, а подставной и его так проверяет компания, не хотел выпускать из машины, заблокировав двери.
На каждое из обращений в службу поддержки было получено обещание поговорить с водителем. С другими сервисами такси ничего подобного не было ни разу за несколько лет ежедневного использования. Так что нет, вы ошибаетесь, возможность нормально доехать из точки А в точку Б пропала.
У вас отняли возможность купить яблоки? Нет. Вам просто привыкать к новому сценарию поведения. Не хотите платить за перевозку Яндексу — голосуйте рублем: рутакси, максим, таксовичкофф — кто там еще?
Я уже несколько лет не пользуюсь Uber, после того как у них упало качество и они сломали приложение (у меня без объявления войны перестала работать оплата картой, выяснилось это в такси, хорошо что с собой были наличные). Так что я проголосовал рублем, я написал им в службу поддержки по каждому удобному случаю. Но вот вы меня сейчас ругаете за то что я пишу о том, что мне не нравится. Это как-то слишком, не находите?
Оно было не у вас. Оно было у компании. Её купила другая компания, и решила не плодить сущности. О чем пользователям было сообщено заблаговременно. Вы забили присмотреть альтернативу, а теперь топаете ножками.
Какой-то стокгольмский синдром. Мы вообще-то платим за поездки и рассчитываем на лояльное отношение со стороны компании. Но компания решила поступить по свински со многими пользователями Uber (например со всеми иностранцами, приезжающими в РФ), только для того, чтобы собирать больше данных (не вижу других причин для принудительного перевода всех на локальное приложение, честно говоря). Какие тут могут быть оправдания? Просто выгода от перевода всех пользователей Uber на приложение Яндекса кажется им более существенной, нежели потеря части пользователей.
Был пользователем Uber с самого его появления в СПб в 2014-м году. После сделки с Яндексом перестал, т.к. качество упало очень сильно. Вдобавок ко всему, у меня теперь нет приложения такси, которое работало бы в командировках. Приложение, установленное из Play Store в РФ, судя по всему отличается от обычного приложения Uber и в нем сейчас даже карта не отображается.
Рейтинг Uber Russia в Play Store — 2.4. Вряд ли я это когда-нибудь установлю.
Заметим, что даже для таблиц типа Buffer не имеет смысла вставлять данные по одной строке, так как таким образом будет достигнута скорость всего лишь в несколько тысяч строк в секунду, тогда как при вставке более крупными блоками, достижимо более миллиона строк в секунду (смотрите раздел «Производительность»).
Пока только монолитная нода. Можно обеспечить HA, если использовать две ноды и реплицировать трафик на обе. Для того, чтобы реализовать кластеризацию нужно сначала реализовать запись в прошлое. Пока что roadmap такой:
— Запись в прошлое, обновление старых данных и тд.
— Простая репликация, HA с полным набором данных на двух нодах и синхронизацией в случае, если одна из них уходила offline.
— Тут уже можно начинать думать про кластеризацию.
Сама проблема довольно сложна. Непонятно даже как раскидывать метрики между нодами, ведь запросы часто вытаскивают множество метрик и если распределять их случайным образом, то каждый запрос будет задействовать все узлы кластера (разделить на фактор репликации).
Строка 21. У вас там динамический тип — std::array, а вы в него пишете как в объект другого типа.
Так с этим никто и не спорил. Я спорил с тем что memcmp использовать вообще нельзя, автор именно так написал.
Там ниже уже отметили, что размер блока другой. В принципе все можно очень тривиально сделать, если писать идиоматичный код (а в случае type pun, это использование временных переменных и memcpy). У меня вот что получилось — godbolt.org/z/h4p7jB но я взял за основу пример, который нашел ниже.
Как правило, автовекторизация сильно предпочтительнее, даже если нужно колдовать над кодом, чтобы он хорошо векторизовался, по следующей причине: зачастую векторизовать код вручную очень сложно, т.к. данные могут быть не выровнены в памяти или твой алгоритм может обрабатывать по 4 елемента за раз, а на вход ему могут дать 17. Все это геморно обрабатывать, а компилятор все это умеет делать за нас. В этом примере _mm_loadu_ps наплевать на выравнивание и алгоритм работает с данными фикс. длины, поэтому все выглядит очень просто и компактно. Но это только в данном примере.
Начнем с того, что там UB из-за нарушения правил алиасинга в функции bar. Я вижу что именно хотелось показать и я с этим не спорю. Тем не менее это не значит что я не могу корректно использовать memcmp.
OK, я думал имеется ввиду другое. Но допустим, что то, что это является проблемой, нужно еще доказать.
Написал автор пассивно агрессивного сэмпла с UB :)
Я уверен, что смогу переписать ф-ю так, что она векторизуется нормально. Ну и в примере foo и bar работают по разному, если что.
Чего это вдруг?
Какой еще алиасинг если у тебя указатель на char*?
Мне сам подход удивителен, постановка проблемы, вывод и конфликт.
Про автовекторизацию посмешило конечно — godbolt.org/z/7UAUBa
Это одна из тех фраз, которые слышишь(видишь) в каждой второй статье или книге и которые не имеют никакого отношения к действительности. Финансовые расчеты как правило выполняются с использованием double (binary64 в терминах IEEE 754). Совершенно бессмысленно использовать decimal (decimal64) для всех вычислений. Вы все равно будете получать результат, который будет требовать округления (пример, я хочу посчитать сколько индийских рупий я могу купить на 1000 рублей, курс RUB/INR — 0.91 и результат 1098,901098901 рупий, binary64 и decimal64 могут представить это значение без потери точности, при этом мне придется округлить до 1098,90). При этом операции над decimal64 — дороже чем над binary64, т.к. реализуются программно. Бухгалтерия — другое дело, там использование decimal имеет какой-то смысл.
Естественно, проблемы были и до объединения, проблемы были и с водителями других сервисов. Но проблемы, связанные с безопасностью это не тоже самое, что проблемы с подачей машины или запахом в салоне. Проблемы с безопасностью у меня были только в убере и только после объединения с яндексом.
Ключевое слово «нормально». Именно эта возможность куда-то делась. У яндекса большие проблемы с качеством. После покупки убера яндексом со мной произошло следующее:
На каждое из обращений в службу поддержки было получено обещание поговорить с водителем. С другими сервисами такси ничего подобного не было ни разу за несколько лет ежедневного использования. Так что нет, вы ошибаетесь, возможность нормально доехать из точки А в точку Б пропала.
Я уже несколько лет не пользуюсь Uber, после того как у них упало качество и они сломали приложение (у меня без объявления войны перестала работать оплата картой, выяснилось это в такси, хорошо что с собой были наличные). Так что я проголосовал рублем, я написал им в службу поддержки по каждому удобному случаю. Но вот вы меня сейчас ругаете за то что я пишу о том, что мне не нравится. Это как-то слишком, не находите?
Какой-то стокгольмский синдром. Мы вообще-то платим за поездки и рассчитываем на лояльное отношение со стороны компании. Но компания решила поступить по свински со многими пользователями Uber (например со всеми иностранцами, приезжающими в РФ), только для того, чтобы собирать больше данных (не вижу других причин для принудительного перевода всех на локальное приложение, честно говоря). Какие тут могут быть оправдания? Просто выгода от перевода всех пользователей Uber на приложение Яндекса кажется им более существенной, нежели потеря части пользователей.
Рейтинг Uber Russia в Play Store — 2.4. Вряд ли я это когда-нибудь установлю.
— Запись в прошлое, обновление старых данных и тд.
— Простая репликация, HA с полным набором данных на двух нодах и синхронизацией в случае, если одна из них уходила offline.
— Тут уже можно начинать думать про кластеризацию.
Сама проблема довольно сложна. Непонятно даже как раскидывать метрики между нодами, ведь запросы часто вытаскивают множество метрик и если распределять их случайным образом, то каждый запрос будет задействовать все узлы кластера (разделить на фактор репликации).