Когда добавляются новые документы и создается новый сегмент, информация о его neighbors set-ах становится доступной и если там есть более перспективные neighbors set-ы документов для данного запроса, то они будут просмотрены и попадут в этот C кандидатов. Ну и понятно, что C >= k всегда иначе же топ не набрать.
Есть замеры tantivy vs lucene и tantivy быстрее. Поэтому разумно ожидать что поиск построенный поверх tantivy можно сделать более быстрый чем поверх lucene. Так что здесь логичное предположение, что можно на Rust быстрее сделать в теории.
В статье Сергея написано детально о причинах, но всё таки на C++ надежный проект поддерживать сложно, а растоманов у нас тогда почти не было. Плюс можно было переиспользовать куски кода эластика скажем касательно мультиматч запросов, что бы переход для клиентов сделать плавнее. Сегодня, наверное, если начинать новый проект действительно может быть лучше взять tantivy и делать вокруг него на Rust.
Каждый раз когда вижу такие статьи на хабре понимаю, что надо всё таки дописать мою статью "Почему ваш кросс-языковой бенчмарк вам врёт". У меня там отличный пример есть, где можно на двух "совершенно одинаковых алгоритмах" получить Java сколь угодно быстрее чем Rust :)
Фантастично то, что люди получив измерения вообще не пытаются даже понять почему они такие числа получили. Вот у человека получается что Rust в 10 раз медленнее, чем Java. И ничего в голове не щелкает, человек публикует статью. Насколько странным должен получиться результат, что бы человек начал искать проблему в своем тесте? В 100 раз должен Rust проиграть Java, в 1000? :) А если бы Java на числодробилки бы оказалась медленнее, там наверное пока в миллион раз её не обгонят никто даже и не почешется, что делает что-то не так :)
Есть хороший доклад одноклассников почему они запили свой поисковой движок: https://youtu.be/7UAR1Vl_5Iw . Там в частности Solr разбирают. Solr рассчитан на маленькие нагрузки и удобный деплой в облаках. Скажем Solr запросы обрабатывает в один поток. Это обеспечивает высокую эффективность при маленьких нагрузках и большинству проектов этого достаточно.
он в СТ 80% времени тратит на рефакторинг и только 20% на написание нового кода
Очень забавно, но иногда мне кажется, что я 100% времени трачу на рефакторинг: мне часто дают задачи взять кусок кода написанный ранее левой пяткой и сделать его быструю и надежную версию к тому же добавив новый функционал.
Но свой код я рефачу достаточно редко:)
Берёте и добавляете, Python или хорошый JS читается как книга
Допустим, но я бы предпочел читать книгу не с начала. Все таки типы дают мне возможность не заглядывать в некоторые места т.к. очевидно там ничего нет. Хотя конечно это не замена документации.
Берёте и меняете… если вы меняете поведение функции то вы либо создаёте новую функцию с новым именем либо (что геморойно и зачем такое вообще?) бегаете поиском по проекту и меняете поведени, но вообще это моветон такое делать не соглосовав с коллегами.
Ну вот допустим стал ты перформенс инженером, сидишь профилируешь код: видишь какие-то умники наслушались лекций про ФП и везде возвращают значения обернутые в Optional и один такой метод горячий прям реально нагружает GC, т.к. где ФП, а где джава. Идешь и меняешь метод, он, скажем, теперь возвращает не Optional, а String но может и null теперь вернуть. Коллега, который этот метод написал давно уволился, а те кто им пользовались половина либо уволились либо стали менеджерами и забыли как программировать. Другие же трогали его год назад и уже забыли где и почему. А тимлид хочет ступеньку на графике таймингов уже завтра. Вот в такой ситуации без типов будет очень больно.
Обратите внимание на аккуратность формулировки «здесь я фактически руками реализую алгебраический тип данных» целых две оговорки в предложении.
Понятно что в Java нет АТД и нет синтаксических возможностей его выразить (но кстати в новых версиях там есть sealed классы, что бы нельзя было объявлять новых наследников, но я решил писать для статьи на Java 11). Здесь происходит такого же рода симуляция, как например люди делали в свое время ООП на чистом С, тоже корявое и рукописное.
Действительно классы и АТД удобно расширяются в разные стороны, но здесь мы ничего не расширяем и отличие как бы не заметно. Я думал об этом написать, но тогда пришлось бы объяснять double dispatch и всякие tagless final. Но не стал, т.к. во-первых статья уже огромная, во-вторых её тема это не «пишем ФП на Java». Ну и цель примера показать как можно убрать логику в декларации, а то что оно похоже на АТД в некотором роди приятный бонус.
Достаточно взять конкретные ветки этого графа, чтобы знать, откуда пришли данные, что с ними происходило, и в какой форме они могут быть в конкретном месте в программе
А как ты понимаешь глядя в локальную точку графа откуда пришли данные и какова их природа без типов? Вот если ты пришел в проект новый и тебе дали задачу на шаге X сделать ещё одно действие Y. Или все таки держать в голове весь путь от инпута до текущего шага исполнения обязательно? Тогда кажется я все корректно описал про «держать всю программу в голове»:-)
Ну вот вы написали пайплайн, а потом уволились и мне надо добавить изменений в середину? Или скажем изменить какую-то функцию, которой пользуетесь вы и ещё в нескольких разных местах разные люди? И начинается Дженга, где одно неловкое движение и башня упадет. Или вы просто выбрасываете весь ранее написанный код и переписываете его заново?:-) Я честно не понимаю.
По идее должно хорошо и просто работать в ФП языках так как там нет мутаций. Если разрешать мутации, то сразу много выплывает тонких кейсов, так что всё равно придется какие-то корректные вещи запрещать.
Ну вот например удалять из коллекции можно всегда — это не приведёт к проблемам типизации. Это на самом деле чудовищная тема если начать её копать, особенно если отойти от абстрактных вещей к конкретным. Я советую для разминки потратить где-то пол часа жизни что бы разобраться почему метод HashMap.get в Rust принимает не тип ключа K, а новый тип Q, который такой что
Ну из перечисленного только 2 чата, один из которых китайский, второй не может отправить длинное видео.
Ты вот текущий топ самой популярной музыке можешь слушать так, что бы кровь из ушей не текла? Я вот не могу.
Когда добавляются новые документы и создается новый сегмент, информация о его neighbors set-ах становится доступной и если там есть более перспективные neighbors set-ы документов для данного запроса, то они будут просмотрены и попадут в этот C кандидатов. Ну и понятно, что C >= k всегда иначе же топ не набрать.
О, т.е. я мискликнул. Забавно:)
Прошу прощения, а почему моя статья про бэкенд "Производительность базового поиска в Ozon как культурный феномен" в шортлисте по AI&ML а не в Бэкенде? :) У меня там прям вообще никакого машинного обучения нет)
Есть замеры tantivy vs lucene и tantivy быстрее. Поэтому разумно ожидать что поиск построенный поверх tantivy можно сделать более быстрый чем поверх lucene. Так что здесь логичное предположение, что можно на Rust быстрее сделать в теории.
Фаллические символы были всегда популярнее во все времена.
Все претензии к обществу.
В статье Сергея написано детально о причинах, но всё таки на C++ надежный проект поддерживать сложно, а растоманов у нас тогда почти не было. Плюс можно было переиспользовать куски кода эластика скажем касательно мультиматч запросов, что бы переход для клиентов сделать плавнее. Сегодня, наверное, если начинать новый проект действительно может быть лучше взять tantivy и делать вокруг него на Rust.
А там так же через Unsafe всё делается. У нас по сути так же.
Пожалуйста :)
Каждый раз когда вижу такие статьи на хабре понимаю, что надо всё таки дописать мою статью "Почему ваш кросс-языковой бенчмарк вам врёт". У меня там отличный пример есть, где можно на двух "совершенно одинаковых алгоритмах" получить Java сколь угодно быстрее чем Rust :)
Фантастично то, что люди получив измерения вообще не пытаются даже понять почему они такие числа получили. Вот у человека получается что Rust в 10 раз медленнее, чем Java. И ничего в голове не щелкает, человек публикует статью. Насколько странным должен получиться результат, что бы человек начал искать проблему в своем тесте? В 100 раз должен Rust проиграть Java, в 1000? :) А если бы Java на числодробилки бы оказалась медленнее, там наверное пока в миллион раз её не обгонят никто даже и не почешется, что делает что-то не так :)
Хах! Приятно что к моим статьям возвращаются :-)
На самом деле я с тех пор перевел свою статью на английский и там код уже по чище.
Но про
MaybeUninitя не знал конечно.На самом деле в итоге я забил на изучение Раста.
Есть хороший доклад одноклассников почему они запили свой поисковой движок: https://youtu.be/7UAR1Vl_5Iw . Там в частности Solr разбирают. Solr рассчитан на маленькие нагрузки и удобный деплой в облаках. Скажем Solr запросы обрабатывает в один поток. Это обеспечивает высокую эффективность при маленьких нагрузках и большинству проектов этого достаточно.
Вообще конечно выглядит как подтверждение гипотезы, что корпорации мстят Столлману за свободный софт.
Очень забавно, но иногда мне кажется, что я 100% времени трачу на рефакторинг: мне часто дают задачи взять кусок кода написанный ранее левой пяткой и сделать его быструю и надежную версию к тому же добавив новый функционал.
Но свой код я рефачу достаточно редко:)
Допустим, но я бы предпочел читать книгу не с начала. Все таки типы дают мне возможность не заглядывать в некоторые места т.к. очевидно там ничего нет. Хотя конечно это не замена документации.
Ну вот допустим стал ты перформенс инженером, сидишь профилируешь код: видишь какие-то умники наслушались лекций про ФП и везде возвращают значения обернутые в Optional и один такой метод горячий прям реально нагружает GC, т.к. где ФП, а где джава. Идешь и меняешь метод, он, скажем, теперь возвращает не Optional, а String но может и null теперь вернуть. Коллега, который этот метод написал давно уволился, а те кто им пользовались половина либо уволились либо стали менеджерами и забыли как программировать. Другие же трогали его год назад и уже забыли где и почему. А тимлид хочет ступеньку на графике таймингов уже завтра. Вот в такой ситуации без типов будет очень больно.
Понятно что в Java нет АТД и нет синтаксических возможностей его выразить (но кстати в новых версиях там есть sealed классы, что бы нельзя было объявлять новых наследников, но я решил писать для статьи на Java 11). Здесь происходит такого же рода симуляция, как например люди делали в свое время ООП на чистом С, тоже корявое и рукописное.
Действительно классы и АТД удобно расширяются в разные стороны, но здесь мы ничего не расширяем и отличие как бы не заметно. Я думал об этом написать, но тогда пришлось бы объяснять double dispatch и всякие tagless final. Но не стал, т.к. во-первых статья уже огромная, во-вторых её тема это не «пишем ФП на Java». Ну и цель примера показать как можно убрать логику в декларации, а то что оно похоже на АТД в некотором роди приятный бонус.
А как ты понимаешь глядя в локальную точку графа откуда пришли данные и какова их природа без типов? Вот если ты пришел в проект новый и тебе дали задачу на шаге X сделать ещё одно действие Y. Или все таки держать в голове весь путь от инпута до текущего шага исполнения обязательно? Тогда кажется я все корректно описал про «держать всю программу в голове»:-)
Ну вот например удалять из коллекции можно всегда — это не приведёт к проблемам типизации. Это на самом деле чудовищная тема если начать её копать, особенно если отойти от абстрактных вещей к конкретным. Я советую для разминки потратить где-то пол часа жизни что бы разобраться почему метод HashMap.get в Rust принимает не тип ключа K, а новый тип Q, который такой что и
doc.rust-lang.org/std/collections/struct.HashMap.html#method.get