1) я написал очень упрощённый вариант glibc функции strpbrk, которая векторизирует поиск скобочек в строке (после беседы с twinklede). Без этого будет по-моему 700ms (там можно раскоментировать вариант с enumerate). Тогда даже на такой простой задаче С++ не догнать по определению, если прочий код будет работать одинаково. (Хотя я подозреваю что потоковый парсер плюсов мы не догоним). Без unsafe вы не получите sse42.
2) Прямой доступ к памяти это Вы про mmap? Возможно он не обязателен. Кстати mmap там кросс платформенный используется. Но во многих примерах выше он тоже присутсвовал.
Да я не аккуратно писал с unsafe, надо было как то завернуть в модуль, обложить комментариями и т п. По сути инвариант там всего один (я надеюсь :), нам надо скармливать буфер определённого размера в векторный регистр. Если дадим указатель на меньше памяти чем надо, то привет UB, я использовал растовый итератор chunks_exact а не арифметику с указателями чтобы сделать это более явно.
Алгоритм мержа у меня тоже не правильный. Я думал над тем какой лучше, но походу зависит от характера входных данных. Для нашего датасета, логичнее всего по быстрому отбрасывать повторения. Поэтому думаю это не так важно для сравнения. Upd: Вообще я подумал задача довольно странная мы соревнуемся в том чтобы как можно быстрее отбрасывать данные. Какая-то ддос атака. Достаточно было бы сравнить скорость сериализации до получения DebtRec.
Решение на го действительно выглядит красиво, просто и работает быстро. На serde писать свои Visitor далеко не так приятно. Но если данные не "грязные" а следуют обычному формату то можно было бы обойтись #[derive]. Хотя в го коде есть всякие читики, типа резервация векоторов на 10 елементов и вектора вместо set, я не знаю на сколько это влияет.
Я к сожелению на go не смог построить heatmap через perf, т.е. я построил но имена функции все unknown. Кто подскажет?
Тогда ТЗ не понятно, например HashSet для телефонов не нужен, достаточно общего HashMap. С учётом того что у нас там постоянно to_owned, выкидывание лишней строчки даёт ускорение на 10%. Например в последней версии на го вообще выкинули HashSet и всё в vector, что для десятка телефонов работает наверное быстрее с учетом константы. Но если телефонов тысяча тогда я уверен решение на го сольётся.
Должно объеденить всё в одного, но это не происходит. Я думаю этот неправильный алгоритм перекочивал во все примеры из комментариев, кроме многопоточки на С++ там подругому merge сделан.
Почему нет? Все лайфтаймы и заимствование ссылок описаны в объявлении функции. Далее есть код по одну сторону интерфейса (клиент) и по другую (библитека). Им ничего не нужно знать про друг друга — они работают через интерфейс. Есть время жизни 'static для каких-то синглетонов библиотеке. Safe Раст не возвращает голый указатель. Если мы возвращаем ссылку из функции то должны объявить её время жизни, которое зависит от времени жизни входных параметров. Или мы можем передать владение объектом наверх.
Если мы имеем дело с dll которая на Cи то нужно писать обёртку через unsafe. Ну тут серебрянной пули не существует. Либо жить на си/плюсах либо писать обёртки либо переписывать всё на раст. Очевидно что в зависимтости от ситуации и количества кода то или иное решение оптимально.
Мы присутсвуем при историческом событии. Это первый шаг: "ИИ прочитал статью по питону и написал об этом на хабр". Потом ещё пару книг прочтет и начнет писать код. Следите за новостями.
Они же проверяют свой ког clang анализатором? Т.е это наглядно показывает что pvs находит больше или как минимум что то новое я правильно понял посыл статьи?)
С докером при разработке чаще проблема в том, что не все IDE умеюют подключать интерпретатор/компилятор из контейнера а также нужные импорты/инклюды оттуда.
unsafe используется:
1) я написал очень упрощённый вариант glibc функции strpbrk, которая векторизирует поиск скобочек в строке (после беседы с twinklede). Без этого будет по-моему 700ms (там можно раскоментировать вариант с enumerate). Тогда даже на такой простой задаче С++ не догнать по определению, если прочий код будет работать одинаково. (Хотя я подозреваю что потоковый парсер плюсов мы не догоним). Без unsafe вы не получите sse42.
2) Прямой доступ к памяти это Вы про mmap? Возможно он не обязателен. Кстати mmap там кросс платформенный используется. Но во многих примерах выше он тоже присутсвовал.
Да я не аккуратно писал с unsafe, надо было как то завернуть в модуль, обложить комментариями и т п. По сути инвариант там всего один (я надеюсь :), нам надо скармливать буфер определённого размера в векторный регистр. Если дадим указатель на меньше памяти чем надо, то привет UB, я использовал растовый итератор chunks_exact а не арифметику с указателями чтобы сделать это более явно.
Алгоритм мержа у меня тоже не правильный. Я думал над тем какой лучше, но походу зависит от характера входных данных. Для нашего датасета, логичнее всего по быстрому отбрасывать повторения. Поэтому думаю это не так важно для сравнения. Upd: Вообще я подумал задача довольно странная мы соревнуемся в том чтобы как можно быстрее отбрасывать данные. Какая-то ддос атака. Достаточно было бы сравнить скорость сериализации до получения DebtRec.
Решение на го действительно выглядит красиво, просто и работает быстро. На serde писать свои Visitor далеко не так приятно. Но если данные не "грязные" а следуют обычному формату то можно было бы обойтись
#[derive]. Хотя в го коде есть всякие читики, типа резервация векоторов на 10 елементов и вектора вместо set, я не знаю на сколько это влияет.Я к сожелению на go не смог построить heatmap через perf, т.е. я построил но имена функции все
unknown. Кто подскажет?Кстати автор ещё не оценивал решения на предмет обработки ошибок. Добавил мусор в джсон:
Assertion `IsObject()' failed. Aborted (core dumped)Error("expected value", line: 1, column: 69)Понятно что можно это везде реализовать, но в раст у меня не получилось бы подругому, либо паника либо сообщение об ошибке и его обработка.
Написал потоковый (как на Гошке) парсер на расте, с аллокациями не заморачивался, думаю можно ещё ускорить. Результаты на моём i5, это однопоточка:
Бойлерплейта много слабонервным не смотреть: https://gist.github.com/technic/5f23603ac955d246a90a8421a667c8c2#file-main-rs (лицензия кода на rust MIT)
PS На гист так же залил исходники плюсов и гошки с которой сравнивал. Надеюсь авторы не против.
PPS Возможно это не самая быстрые версии на альтернативных языках, что удалось найти среди комментов.
Тогда ТЗ не понятно, например HashSet для телефонов не нужен, достаточно общего HashMap. С учётом того что у нас там постоянно to_owned, выкидывание лишней строчки даёт ускорение на 10%. Например в последней версии на го вообще выкинули HashSet и всё в vector, что для десятка телефонов работает наверное быстрее с учетом константы. Но если телефонов тысяча тогда я уверен решение на го сольётся.
А ещё может быть экранированный бекслэш. Что тогда?
\"
Добавте ссылку в статью. или ссылку на код которым этот файл сгенерирован.
Алгоритм не правильный.
[
{"company":"Рога и копыта", "debt": 800, "phones": [123, 234, 456]},
{"company":"Первая коллекторская", "debt": 1200, "phones": ["2128506", 456, 789]},
{"company":"Святой престол", "debt": "666", "phones": 666},
{"company": "Казачий спас", "debt": 1500, "phones": [234567, "34567", 789], "phone": 666},
{"company": {"name": "Шестерочка"}, "debt": 2550, "phones": 788, "phone": 789}
]
Должно объеденить всё в одного, но это не происходит. Я думаю этот неправильный алгоритм перекочивал во все примеры из комментариев, кроме многопоточки на С++ там подругому merge сделан.
Торт на картинке это офисный корпоратив в честь релиза или наглый фотошоп? Или надо статью целиком читать чтобы узнать?)
Отвечу сам себе. Открыл issue на гитхабе и проблему пофиксили.
Почему нет? Все лайфтаймы и заимствование ссылок описаны в объявлении функции. Далее есть код по одну сторону интерфейса (клиент) и по другую (библитека). Им ничего не нужно знать про друг друга — они работают через интерфейс. Есть время жизни 'static для каких-то синглетонов библиотеке. Safe Раст не возвращает голый указатель. Если мы возвращаем ссылку из функции то должны объявить её время жизни, которое зависит от времени жизни входных параметров. Или мы можем передать владение объектом наверх.
Если мы имеем дело с dll которая на Cи то нужно писать обёртку через unsafe. Ну тут серебрянной пули не существует. Либо жить на си/плюсах либо писать обёртки либо переписывать всё на раст. Очевидно что в зависимтости от ситуации и количества кода то или иное решение оптимально.
Но почему Донбасс и Палестина, когда есть примеры менее спорные.
Поддерживаются ли тайп аннотации через комментарии в питон 2? К сожалению иногда ещё приходится с ним работать.
В этом и фишка раст.
Мы присутсвуем при историческом событии. Это первый шаг: "ИИ прочитал статью по питону и написал об этом на хабр". Потом ещё пару книг прочтет и начнет писать код. Следите за новостями.
А откуда автор заранее знал как будет выглядеть полученный PDF и в каком div будет лежать ответ на сайте? Это была не первая виза?)
Они же проверяют свой ког clang анализатором? Т.е это наглядно показывает что pvs находит больше или как минимум что то новое я правильно понял посыл статьи?)
С докером при разработке чаще проблема в том, что не все IDE умеюют подключать интерпретатор/компилятор из контейнера а также нужные импорты/инклюды оттуда.
Я думаю даже ссылки на хабр поставлять можно.
Жаль, а почему не расскажете? Потому что гитлаб легко перенести потом на приватный хостинг? Спасибо за ответ.
Только гитхаб и битбакет, а гитлаб.ком можно?