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 ()
Ответ на: комментарий от pihter

Дословно этот json - 126 байт. Перепаковать в MessagePack - 99 байт.

27 байтов сэкономили ценой нечитабельной каши.

------

Так просто. На Хабре читал человека про «Выбрали MessagePack, ускорились на 46% относительно JSON». Хоть убейся не получается даже близко похожее на 46%.

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

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

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

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

27 байтов сэкономили ценой нечитабельной каши.

а зачем ты пытаешься читать машинный выхлоп? он вообще может быть бинарным и почти все файлы на твоём компе - «нечитабельная каша». зато эта «каша» прекрасно перерабатывается или исполняется на процессорах и не жрёт лишних ресурсов компов и сетей. и сэкономленные 27 байтов для одного блока данных в ситуации, когда у тебя миллиарды таких блоков, могут дать очень существенный прирост производительности.

а для хомосапов обычно есть утилиты, которые парсят машинное представление для «читабельного» вида.

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

Вот бы xbps свои пакеты в двоичных template делал, которые и читать и писать можно только через «утилиты, которые парсят машинное представление».

json тем и прекрасен, и людям понятен с одного взгляда, и машины его практически как родной читают. Я вот прям в восторге от всяких json_to_recordset() и обратно.

Но 46% - это аргумент. За 46% я согласен отказаться от json.

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

ты не занимайся софистикой. «пакеты» (темплейты) xbps - это файлы, которые непосредственно пишутся и правятся людьми. а все бинарные данные для софта вполне нормально обрабатываются софтом. там никаких json'ов нет и близко.

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

ну, С++ всё-таки ещё не настолько макакопомойка. он ещё не скатился до уровня ниже плинтуса. поэтому так, да.

так что есть есть желание «твёрдой руки» и всякого безальтернативного решалова за тебя какими-то чужими дядями, то не надо брать плюсЫ. есть огромное множество всякой скриптятины и иже с ней, где всё уже сделали за тебя. квадратно-гнездовой подход, думать не нужно, выбирать не нужно, мозг не требуется от слова совсем.

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

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

Я бы вообще зафиксировал лексическое ядро языка, а в новых стандартах только библиотеку расширял.

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

если ты разработчик, то ты знаешь формат и в дебаггере сам разберёшься. для этого никогда не были нужны никакие json'ы. вообще ни разу.

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

https://github.com/dacez/zzzjson

The fastest JSON parser written in pure C

Вот многие любят так писать. 😃

уделывает все известные мне до сих пор реализации json’а.

Предполагаю, что https://github.com/ibireme/yyjson будет быстрее. И активно развивается.
Ещё полезное (yy_double) от автора: https://github.com/ibireme/c_numconv_benchmark.

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

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

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

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

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

если ты разработчик, то ты знаешь формат

:)

Если до тебя было 40 разработчиков, то в накопившейся документации чёрт ногу сломит. А если документация вдобавок предоставлена сторонней компанией под NDA, тогда совсем хреново. Был случай, когда пришлось в дебаггере реверсить библиотеку, а затем патчить бинарник.

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

мне это не надо рассказывать. я много лет работаю в разработке. но это не причина лепить всякий жир в протоколы.

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

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

Да, там всё просто. Но, наряду с FIX, это рабочая лошадка большой части HFT (High Frequency Trading).

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

от патчения бинарников я избавилась, когда ушла с маздая. нет маздая - нет неизвестных бинарников.

Я в своё время в Линукс пришёл как раз ради запуска бинарников, которые не хотели портировать под Виндоуз — только X, только OpenGL :)

Но да, случай редкий.

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

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

Никто, кроме одного клиента, который тоже ты пишешь

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

Так я с этим-то не спорю, я просто выражаю сомнение в том, что «аккуратно форматировать исходники» == JSON-даже-там-где-он-не-нужен

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

Дословно этот json - 126 байт. Перепаковать в MessagePack - 99 байт.

ip - 4 байта маска – 5 бит ( округлим до байта ) шлюз - 4 байта dns - 4 байта dhcp - 1 бит ( тоже округлиб до байта, чтоб не паковать с маской из лени )

итого – 14 байт, если уж на то пошло

но в данном случае это не важно: ручная смена айпишника – редкая операция и она ручная, пользователь не заметит разницы в скорости передачи 14 байт и 126 байт, вопрос был в другом, нахрена при передаче структуры из сишной программы в сишную было использовать сериализацию да еще и однослойный json

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

«аккуратно форматировать исходники» == JSON-даже-там-где-он-не-нужен

JSON — один из способов аккуратно форматировать данные. Далеко не идеальный, но вполне рабочий. Как принудительные отступы в Питоне :) Кто-то может писать на Си без ошибок, но большинство проще загнать в узкие рамки, поступившись скоростью и краткостью. JSON заменил XML, который был гораздо более громоздок.

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

Кто-то может писать на Си без ошибок, но большинство проще загнать в узкие рамки

Блин. Ладно когда этот аргумент еще для всякого JS… хотя я и там против, но это же си.. давайте еще ассемблеристов в рамки загонять, чтоб они глупенькие не наделали ошибок.

Ну я, в общем, понял: давайте всех, кто не умеет программировать не учить программировать, а заставим их работать с фреймворками, там они по-тупому физически написать не смогут, фреймверк не позволит. Я категорически с этим не согласен

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

JSON — один из способов аккуратно форматировать данные

А как ты отнесешься к тому, чтоб эту джисонину перед отправкой еще в xml с одним полем упаковать? А на выходе распарсить сначала xml, а потом json? Вопрос риторический. А почему ты отнесешься к этому отрицательно? Очевидно, ты скажешь, что упаковка в xml тут лишняя и без нее все было структурировано, а я скажу что это – разумный подход, только я то же самое и про json в данном случае скажу

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

А как ты отнесешься к тому, чтоб эту джисонину перед отправкой еще в xml с одним полем упаковать? … А почему ты отнесешься к этому отрицательно?

Благодаря твоему вопросу я наконец сформулировал для себя, что мне не нравится в XML в качестве контейнера для хранения информации :)

В JSON 2 вида данных — массивы равнозначных данных и словари ключ-значение. Которые можно вкладывать друг в друга в любых количествах. И этого достаточно.

В XML есть пары ключ-значение, есть тэги и есть текст внутри тэгов. Разнообразие тэгов, теоретически, позволяет всё упорядочивать и организовывать, ограничивая действия пользователя многомегабайтными правилами, но практически оказывается ненужно.

Да, JSON избыточен уже тем, что текстовый. Хорошо было бы все числа записывать в бинарном виде, ключи сократить до 4 байт и стандартизовать, указывать длину элемента вместо скобок в начале и конце, булев тип данных сократить до 1 бита… Формат IFF существует со времён 8-битных домашних компьютеров, но его и его потомков регулярно не осиливают и изобретают что-то другое. Обычно с прицелом на возможность парсить глазами и редактировать в Nano. Поэтому лучше JSON, чем другие текстовые.

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