Если NULL будет равен сам себе, то внешние соединения по нулевым полям дадут совершенно неинтуитивный результат. Отсутствующее отчество у Джона Смита — это не то же, что отсутствующее отчество у Джимми Вонга
Вот только 0,001 секунд без fwirte достигается из-за того, что умный компилятор вырезает вообще все вычисления, потому что их результат никак не используется.
Если изменение состояния часов происходит раз в минуту (т. е. минутная ходит по 1/60 круга, а часовая — по 1/720), то получаем дополнительное ограничение , которое оставляет одно или два решения.
Или предполагается, что одна стрелка движется рывками, а другая непрерывно?
Совершенно согласен с тем, что в будущем и в психологии, и в медицине искусственный интеллект будет занимать всё большее место.
Что касается конкретной теории, то, увы, она слишком похожа на «простое объяснение всего на свете», а не на научную гипотезу — хотя бы отсутствием статистически достоверных экспериментальных данных. Ведь корреляцию цветовых предпочтений с какими-либо особенностями характера проверить совсем несложно. Где же статьи с революционными открытиями? Поделитесь ссылками?
Но, повторюсь, с точки зрения выпускного проекта это совершенно неважно. А важно то, что редактор корпоративного блога не уделил достаточно внимания хорошему оформлению материала. Я мало что знаю об OTUS'е и подобная небрежность оставляет довольно неприятное впечатление. Уверен, что Ваше исследование не заслуживает такого отношения.
Довольно сомнительная с точки зрения научности тема — это ещё можно пережить. В конце концов, если никакими экспериментами предложенная теория не обосновывается (я, во всяком случае, найти быстро не смог), то применение машинного обучения вполне сойдёт за какое-никакое, но обоснование.
Но, чёрт возьми, код скриншотами, практически никаких технических подробностей, картинки с не вполне внятными подписями... Так себе реклама, как по мне.
Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем vendor со всеми пакетами лежит в репозитории?
Вы совершенно правы, и именно поэтому статья располагается в разделе "ненормальное программирование". Практических целей у дальнейших оптимизаций нет, просто было интересно.
При реальном бане с запасом хватает скорости наивной реализации, а бан делается пачкой через ipset, потому что добавление правил по одному в iptables, конечно же, сильно тормозит (в том числе и обработку длинной цепочки правил). Кстати, в README репозитория есть инструкции на этот счёт.
Если взять просто разделение строк по memchr, то производительность выходит порядка 0,26Гб/0,173 с = ~1,5 Гб/с.
В оригинальной статье про simdjson указано, что на Skylake@3,4GHz парсинг происходил со скоростью 2,2Гб/с. На виртуалке тоже Skylake, но на частоте 2,3GHz, что при пересчёте даёт те же 1,5 Гб/с.
Таким образом, если задействовать AVX, который использует memchr , и делить на строки одновременно с парсингом, то, думаю, схожей производительности можно и добиться. Как-нибудь надо будет попробовать...
А 12 Гб/с simdjson достигает, судя по той же таблице на с. 17, на select, то есть выборке из уже разобранного дерева. Кстати, в этом он не чемпион, его обгоняет sajson.
Кстати, логи можно собирать с нескольких серверов. nginx умеет логировать в rsyslog, а тот умеет пересылать логи по сети.
В имеющейся схеме парсер логов запускается раз в минуту, и чем меньше времени (и, соответственно, ресурсов) он будет отъедать при разборе накопившегося — тем лучше.
Да, это точно. Я полагаю, что даже простое изменение формата лога (просто в виде IP/datetime) сильно бы помогло производительности. Но интересно было решать задачу именно с заданным форматом.
Лично меня очень путала разница = / := (и ещё можно пользоваться var, а можно и нет). А читать мешает то, что тип указывается после переменной/параметра, но без двоеточия. Для меня привычно смотрятся варианты bool a (как в C/Java/PHP) и a: bool (как в Паскале/Python/TypeScript). А вот Go в обоих случаях идёт особым путём.
Если
NULLбудет равен сам себе, то внешние соединения по нулевым полям дадут совершенно неинтуитивный результат. Отсутствующее отчество у Джона Смита — это не то же, что отсутствующее отчество у Джимми ВонгаВот только 0,001 секунд без
fwirteдостигается из-за того, что умный компилятор вырезает вообще все вычисления, потому что их результат никак не используется.Если изменение состояния часов происходит раз в минуту (т. е. минутная ходит по 1/60 круга, а часовая — по 1/720), то получаем дополнительное ограничение
, которое оставляет одно или два решения.
Или предполагается, что одна стрелка движется рывками, а другая непрерывно?
Да, по сути это то же самое. При этом для меня, честно говоря, комплексную экспоненту гораздо проще визуализировать в контексте часовых задач.
Какое любопытное графическое решение! Но и тут требуется дополнительный шаг, чтобы убрать «задвоение» 12 часов
Как неожиданно приятно, спасибо за комментарий!
Совершенно согласен с тем, что в будущем и в психологии, и в медицине искусственный интеллект будет занимать всё большее место.
Что касается конкретной теории, то, увы, она слишком похожа на «простое объяснение всего на свете», а не на научную гипотезу — хотя бы отсутствием статистически достоверных экспериментальных данных. Ведь корреляцию цветовых предпочтений с какими-либо особенностями характера проверить совсем несложно. Где же статьи с революционными открытиями? Поделитесь ссылками?
Но, повторюсь, с точки зрения выпускного проекта это совершенно неважно. А важно то, что редактор корпоративного блога не уделил достаточно внимания хорошему оформлению материала. Я мало что знаю об OTUS'е и подобная небрежность оставляет довольно неприятное впечатление. Уверен, что Ваше исследование не заслуживает такого отношения.
Довольно сомнительная с точки зрения научности тема — это ещё можно пережить. В конце концов, если никакими экспериментами предложенная теория не обосновывается (я, во всяком случае, найти быстро не смог), то применение машинного обучения вполне сойдёт за какое-никакое, но обоснование.
Но, чёрт возьми, код скриншотами, практически никаких технических подробностей, картинки с не вполне внятными подписями... Так себе реклама, как по мне.
Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем
vendorсо всеми пакетами лежит в репозитории?Вы совершенно правы, и именно поэтому статья располагается в разделе "ненормальное программирование". Практических целей у дальнейших оптимизаций нет, просто было интересно.
При реальном бане с запасом хватает скорости наивной реализации, а бан делается пачкой через
ipset, потому что добавление правил по одному вiptables, конечно же, сильно тормозит (в том числе и обработку длинной цепочки правил). Кстати, в README репозитория есть инструкции на этот счёт.Если взять просто разделение строк по
memchr, то производительность выходит порядка 0,26Гб/0,173 с = ~1,5 Гб/с.В оригинальной статье про simdjson указано, что на Skylake@3,4GHz парсинг происходил со скоростью 2,2Гб/с. На виртуалке тоже Skylake, но на частоте 2,3GHz, что при пересчёте даёт те же 1,5 Гб/с.
Таким образом, если задействовать AVX, который использует
memchr, и делить на строки одновременно с парсингом, то, думаю, схожей производительности можно и добиться. Как-нибудь надо будет попробовать...А 12 Гб/с simdjson достигает, судя по той же таблице на с. 17, на
select, то есть выборке из уже разобранного дерева. Кстати, в этом он не чемпион, его обгоняет sajson.Кстати, логи можно собирать с нескольких серверов.
nginxумеет логировать вrsyslog, а тот умеет пересылать логи по сети.В имеющейся схеме парсер логов запускается раз в минуту, и чем меньше времени (и, соответственно, ресурсов) он будет отъедать при разборе накопившегося — тем лучше.
Да, это точно. Я полагаю, что даже простое изменение формата лога (просто в виде IP/datetime) сильно бы помогло производительности. Но интересно было решать задачу именно с заданным форматом.
Лично меня очень путала разница
=/:=(и ещё можно пользоватьсяvar, а можно и нет). А читать мешает то, что тип указывается после переменной/параметра, но без двоеточия. Для меня привычно смотрятся вариантыbool a(как в C/Java/PHP) иa: bool(как в Паскале/Python/TypeScript). А вот Go в обоих случаях идёт особым путём.Это, кажется, дело вкуса. По моим ощущениям в сравнении с C/Java/PHP оба достаточно инопланетные.
Кстати, меня удивило, что количество строк практическо одинаковое (700 и 711), при том, что Go продвигается именно под соусом "простоты".
А в чём ещё проще?
Кстати, а чем Go удобнее для Вас?
Присоединяюсь к идее открыть максимум данных
И на промежуточный вариант тоже было бы интересно посмотреть.
Спасибо! Было бы интересно прочитать более подробное описание, если это возможно
Если я правильно нашёл в тексте, то это «съёмный магнитный диск», то есть подходят дискеты любого размера.
А если серьёзно, то я правильно понял, что запатентован примерно тот же метод, что был описан в посте несколько лет назад?