LINUX.ORG.RU

simdjson 4.0.0 и 4.0.1

 , , , ,


1

3

12 и 13 сентября состоялись выпуски 4.0.0 и 4.0.1 высокопроизводительной, SIMD-оптимизированной, библиотеки simdjson.

Значительные изменения:

  • Добавлен API builder для сериализации структур данных в строку JSON:
std::vector<std::vector<double>> c = {{1.0, 2.0}, {3.0, 4.0}};
std::string json = simdjson::to_json(c);
  • Добавлена экспериментальная поддержка статической рефлексии стандарта C++26 (подробнее о компиляторах: p2996/README.md), позволяющая производить сериализацию и десериализацию данных пользовательских типов:
struct Car {
    std::string make;
    std::string model;
    int64_t year;
    std::vector<double> tire_pressure;
};
void f() {
    Car c = {"Toyota", "Corolla", 2017, {30.0, 30.2, 30.513, 30.79}};
    std::string json = simdjson::to_json(c);
}

или

struct Car {
    std::string make;
    std::string model;
    int year;
    std::vector<float> tire_pressure;
};
std::string json = R"( { \"make\": \"Toyota\", \"model\": \"Camry\", \"year\": 2018,
       \"tire_pressure\": [ 40.1, 39.9 ] } )";
simdjson::ondemand::parser parser;
simdjson::ondemand::document doc = parser.iterate(simdjson::pad(json));
Car c = doc.get<Car>();
  • На 10-70% увеличена скорость сериализации.
  • Другие оптимизации и исправления ошибок.
  • В версии 4.0.1 исправлена совместимость со старыми версиями CMake.

>>> Подробности на GitHub

★★★★★

Проверено: hobbit ()
Ответ на: комментарий от ann_lortemp2

Старое, от конкурента: https://github.com/miloyip/nativejson-benchmark. Я собирать не пробовал.

Но лучше бы добавить в https://github.com/stephenberry/json_performance.

dataman ★★★★★
() автор топика
Последнее исправление: dataman (всего исправлений: 1)

Выбрать медленный текстовый формат и тратить силы на сложную оптимизацию, вместо выбрать быстрый бинарный формат

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от sena

быстрый бинарный формат

А дампы Википедии в нём выкладывают?

dataman ★★★★★
() автор топика
Ответ на: комментарий от question4

Каким бинарным форматом заменить JSON?

  • protobuf
  • asn
  • tlv

И прям до жопы всяких местячковых «у нас новый вариант сериализации».

bdrbt
()
Ответ на: комментарий от bdrbt

protobuf кал, он тащит «схему» в данных, а вот MsgPack нашечка!

И почему все забыли самый популярный на свете бинарный формат - TL используемый внутри Telegram и VK?

https://github.com/VKCOM/tl https://core.telegram.org/mtproto/TL

JSON супер удобен для конфигов. ini-файлы слишком просты, иногда хочется бахнуть список. YAML - ущербен требованиями к ссаным пробелам как Python. JSON прям золотая середина. Конфиг nginx не json, но очень похож на него и на простую сишную программку. Лишнюю кавычку в JSON поставить не развалишься и всё очееь читаемо, а вот ссаные отступы в YAML уже полную дурку шизов наплодили и выпишут их не скоро!

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 3)
Ответ на: комментарий от bdrbt

protobuf,asn,tlv

ASN помнится что Abstract Syntaxis Notation - язык описания данных. Кто/что включает-наследует-содержит-ссылается,типы,длины,флаги,коды..в тесной связи с X.500

A в бинарь отродясь данные кодировались разными BER,DER (и прочими *ER). Боюсь ошибиться, но сдаётся что данные описанные в ASN могут кодироваться и по правилам TLV и в protobuf.

MKuznetsov ★★★★★
()
Ответ на: комментарий от dataman

А как же TOML?

Для простых конфигов — TOML легче читается. Для сложных ситуаций с многократными вложениями массивов и пар ключ-значение — JSON лучше приспособлен. Да, такие ситуации желательно избегать, но если уж влип, JSON менее многословен.

question4 ★★★★★
()
Ответ на: комментарий от dataman

Это называется .ini файлы. Виндовозное блевотное поделие с квадратными скобочками этими. Пишите везде JSON, он проще некуда.

Посмотрел подробнее. Это какая-то адовая помесь .ini-файлов и JSON-структур) Бугага, вот клоуны. Нельзя просто так взять и сразу поюзать няшный JSON.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от bdrbt

до жопы всяких местячковых «у нас новый вариант сериализации»

Вот в этом и проблема. Эталонные реализации не покрывают все возможные случаи использования, других библиотек нет, спецификации помимо их исходников нет. У bson хотя бы есть MongoDB (хотя прочие реализации не выглядят живыми).

tlv

Tag-length-value — отличная идея, но конкретные форматы не всегда документируются. Я как-то несколько недель не мог найти спецификации нестандартных чанков FLIC. С XML и JSON проще, что есть возможность давать человекочитаемые названия.

asn

Что это такое? ASN.1, существующий уже лет 40? Если он удобен, почему его не начали использовать для чего-либо помимо сетевых протоколов?

protobuf

Заглянул в Википедию и не осилил.

question4 ★★★★★
()

Воу, круто.

Жаль, плюсы, а не чистый Си, вкорячить поиграться было бы полегче :)

GFORGX ★★★
()
Ответ на: комментарий от lesopilorama

protobuf кал, он тащит «схему» в данных, а вот MsgPack нашечка!

Таки что в этом плохого (в строгом формате со схемой)?

GFORGX ★★★
()
Последнее исправление: GFORGX (всего исправлений: 2)
Ответ на: комментарий от bdrbt

protobuf Его не то чтобы сильно быстро получалось парсить, спасибо varint encoding

Softwayer ★★
()
Ответ на: комментарий от zx_gamer

Зачем ты упаковываешь json, еслиты не упаковываешь ini? Для json есть в любом ссаном линуксе консольные утилиты «напечатай красиво с цветовой раскраской».

lesopilorama
()
Ответ на: комментарий от lesopilorama

Если не важна читаемость, то лучше бинарный формат. Он компактнее, быстрее обрабатывается. И такой же не читаемый.

zx_gamer ★★★
()
Ответ на: комментарий от lesopilorama

И почему все забыли самый популярный на свете бинарный формат - TL используемый внутри Telegram и VK?

А потомучто он приколочен гвоздями к little-endian и на big-endian просто не собирается даже.

Q-Master
()

Скоро целые институты будут работать над увеличением производительности жсон-парсера и упаковщика. И чего все в нем нашли?

pihter ★★★★★
()
Ответ на: комментарий от question4

Каким бинарным форматом заменить JSON?

Просто складывай данные байт за байтом. В жизни все равно все джонины одинаковые в каждом конкретном случае

pihter ★★★★★
()
Ответ на: комментарий от lesopilorama

JSON супер удобен для конфигов

Это ты lua не пробовал)

pihter ★★★★★
()
Ответ на: комментарий от blex

Его финансисты в последнее время полюблять стали.

Так он изначально часть Fix-протокола. Хотя всю эту экзотику типа sbe, apache avro и т.д. Лучше тестить именно на своих данных, а то бенчмарки смотришь - лепота, использовать начинаешь - срамота.

bdrbt
()
Ответ на: комментарий от gns

Неправильно.

We support ARM NEON, SSSE3, AVX2, AVX-512 and POWER instructions, among others.

dataman ★★★★★
() автор топика
Ответ на: комментарий от blex

прочитала про протокол, ради любопытства. гуманитарии узнали про hex, сделали hex фиксированной длины и прикрутили к нему схемы. но всё же лучше, чем JSON, если схема одна, а данных много. не так эффективно, как какой-нить ASN1, но фиксированная длина позволяет парсить отдельные поля без разбора всего пакета.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Somebody

так вон выше привели пример SBE (Simple Binary Encoding). там как раз схема (формат) в заголовке, а дальше - байтик за байтиком, ну, плюс-минус. немного попсово и без суровой оптимизации, но лучше, чем прямо совсем уж развесистая клюква вроде json или чистого xml. самодокументируемые данные.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Ну так а я ж разве против?? Отвечал на вопрос,«как клиенту объяснить?».. :)

Так-то я и сам бинарные форматы предпочитаю, только хорошо документированные... :))

Somebody ★★★
()
Ответ на: комментарий от Somebody

я тоже любитель бинарных данных. я пришла в программирование софта из суровой разработки железа. а там нет ни единого лишнего бита. есть много уже готовых бинарных форматов данных. для некоторых реализаций мы писали свои протоколы, если вдруг не хватало. а то расточительство, которым кишит веб, - это просто караул. там просто 90% данных можно было бы смело выбросить за ненужностью.

но даже это ещё не самое худшее в вебе. самое худшее там то, что куча потоков плодит кучу одинаковых запросов, потому что макакам так проще. в итоге, оверхед может превышать 100%, причём во много раз. и никакие кэши не спасают. поэтому современный веб такой тупой и тормозной.

тащемта, я хочу нанести по этому рассаднику удар и сделать оптимизированную реализацию ActivityPub. не знаю, выстрелит это или нет. но наблюдение всего этого бардака так меня удрочало, что я решила, что можно это переписать и сделать всё нормально.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Somebody

кстати, я нашла ну очень шустрый json от какого-то китайца. тупой, возможно, там реализован не весь стандарт, но шустрый прямо как понос:

https://github.com/dacez/zzzjson

я к нему маленько дописала обёртки-макросы и оно прямо летает. уделывает все известные мне до сих пор реализации json'а.

если не будет лень, попробую собрать тесты и сравнить его с simdjson, ради интереса. я подыскивала оптимальную софтину для работы с json. если simd будет быстрее, я могу использовать его.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

прямо как понос

Звучит угрожающе... ;P :))

если не будет лень, попробую собрать тесты и сравнить его с simdjson, ради интереса. я подыскивала оптимальную софтину для работы с json. если simd будет быстрее, я могу использовать его.

Надеюсь на вашу публикацию здесь...

Somebody ★★★
()
Ответ на: комментарий от question4

А как потом объяснить клиенту этот формат?

Ну как-то десятилетиями люди справлялись, хидер опубликовать, например

ну я же не улетевший предлагать новые форматы в неконтролируемых тобой местах, если у тебя там клиенты – то конечно удобнее общеупотребимый

вот как иллюстрация к моей мысли: у меня чувак на работе написал настройку сетевых параметров командой вида: {"value":{"ip":"192.168.216.66","netmask":"255.255.255.0","gateway":"192.168.216.254","dns":["192.168.216.252"],"dhcp":false} клиент один, сервер один, оба места пишет он, больше никто сюда не полезет и никто больше этим пользоваться не будет, нахрена тут json? И это еще на плюсах, а не на js каком-нибудь где json – родной

pihter ★★★★★
()
Последнее исправление: pihter (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Какую из них? Нет, рили, этих библиотек как собак нерезаных и у каждой свой интерфейс, свой набор фич, свои баги. Вместо того, чтобы дрочить на функции Лежандра, добавьте уже нормальные тулзы в библиотеку.

Хотя учитывая, что ты сишница, тебе норм закатывать Солнце вручную.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от pihter

клиент один, сервер один, оба места пишет он, больше никто сюда не полезет и никто больше этим пользоваться не будет

А если никто не будет, зачем вообще писать? :)

Причина та же, по которой надо аккуратно форматировать исходники и давать переменным описательные и информативные имена. Чтобы этим можно было пользоваться через несколько лет, и не только первоначальному автору.

Первые лет 10-15 своего существования компания, где я работаю, тоже так делала. Каждый программист изобретал свой формат, исходники доступны, все довольны. Лет через 10 пришло понимание, что в таком бардаке работать невозможно, и начали пытаться упорядочивать: ini, sqlite, HDF5…

question4 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.