The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликован второй кандидат в релизы встраиваемой СУБД libmdbx 1.0

07.01.2020 16:31

После пяти лет разработки доступен для тестирования второй кандидат в релизы библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базой данных класса ключ-значение. Текущая версия (0.5) является техническим релизом, отмечает завершение каких-либо доработок и переход к фазе публичного финального тестирования и стабилизации, с последующем формированием первого полноценного релиза библиотеки. Код libmdbx распространяется под лицензией OpenLDAP Public License.

Библиотека MDBX является существенно переработанным ответвлением от LMDB - транзакционной встраиваемой СУБД класса «ключ-значение» на основе дерева B+ без упреждающей журнализации, которая позволяет многопоточным процессам конкурентно и эффективно работать с локально-разделяемой (не сетевой) БД. В свою очередь MDBX быстрее и надёжнее LMDB, и при этом сохраняет все ключевые возможности своего прародителя, такие как ACID и неблокирующее чтение с линейным масштабированием по ядрам CPU.

Результаты тестирования производительности (отправка параллельных запросов на чтение/поиск в 1-2-4-8 потоках на CPU i7-4600U c 2-я физическими ядрами в режиме 4-х потоков HyperThread):

Самые важные отличия MDBX, относительно LMDB:

  • Принципиально больше внимания уделяется качеству кода, тестированию и автоматическим проверкам.
  • Существенно больше контроля во время работы, начиная от проверки параметров, до внутреннего аудита структур базы данных.
  • Авто-компактификация и автоматическое управление размером БД.
  • Единый формат БД для 32-битных и 64-битных сборок.
  • Оценка объёма выборок по диапазонам (range query estimation).
  • Поддержка ключей вдвое большей длины и выбираемый пользователем размер страницы БД.

Выпущенный кандидат в релизы libmdbx является результатом принятого в августе 2019 решения о разделении проектов MDBX и MithrilDB. При этом в libmdbx было решено устранить (рациональный) максимум технического долга и стабилизировать библиотеку. По факту в обозначенном направлении сделано в 2-3 раза больше, чем оценивалось и планировалось исходно:

  • Реализована поддержка macOS и платформ «второго эшелона»: FreeBSD, Solaris, DragonFly BSD, OpenBSD, NetBSD. Поддержка AIX и HP-UX может быть добавлена при необходимости.
  • Проведена санация кода при помощи Undefined Behavior Sanitizer и Address Sanitizer, устранены все предупреждения при сборке с "-Wpedantic", все предупреждения Coverity Static Analyzer и т.д.
  • Актуализация описания API.
  • Слияние (амальгамация) исходного кода для удобства встраивания.
  • Поддержка CMake.
  • Поддержка вложенных транзакций.
  • Использование bootid для определения факта перезагрузки ОС (грязной остановки БД).
  • Сквозной подсчёт обновлённых/старых страниц и расширенная информация о транзакциях.
  • Опция MDBX_ACCEDE для подключения к уже открытой БД в совместимом режиме.
  • Использование OFD-блокировок при их доступности.
  • Горячее резервное копирование в pipe.
  • Специализированный оптимизированный алгоритм внутренней сортировки (до 2-3 раз быстрее "qsort()" и до 30% быстрее "std::sort()").
  • Увеличена максимальная длина ключа.
  • Автоматическое управление read ahead (стратегией кэширования файла БД в памяти).
  • Более агрессивная и быстрая авто-компактификация.
  • Более оптимальная стратегия слияния страниц B+ дерева.
  • Контроль нелокальных файловых систем (NFS, Samba и т.п.) для предотвращения повреждения БД при неверном использовании.
  • Расширен набор тестов.

Разработка «следующей» версии libmdbx будет продолжена в рамках отдельного проекта MithrilDB, в том время как вектор разработки «текущей» версии MDBX направлен на заморозку набора возможностей и стабилизацию. Такое решение принято по трём причинам:

  • Полная несовместимость: для реализации всех запланированных возможностей в MithrilDB требуется другой (несовместимый) формат файлов БД и другой (несовместимый) API.
  • Новый исходный код: для исходного кода MithrilDB обеспечена лицензионная независимость от LMDB, а сам проект планируется опубликовать под другой лицензией (одобренной OSI лицензией Apache 2.0, а не OpenLDAP Public License).
  • Разделение позволяет избежать потенциальную путаницу, внести больше определённости и обеспечить независимость пути развития проектов.

MithrilDB как и MDBX, также основывается на дереве B+ и также будет отличатся предельно высокой производительностью, при этом устраняя ряд принципиальных недостатков MDBX и LMDB. В частности, будет ликвидирована проблема «долгих чтений», проявляющаяся как «распухание» БД из-за того, что переработка мусора блокируется долгим читающими транзакциями. Среди новых возможностей MithrilDB следует отметить:

  • Поддержка размещения БД на нескольких разнородных носителях: HDD, SSD и энергонезависимой памяти.
  • Оптимальные стратегии для «ценных» и «малоценных», для «горячих», «теплых» и «холодных» данных.
  • Использование Merkle tree для контроля целостности БД.
  • Опциональное использование WAL и существенно более высокая производительно в сценариях с интенсивной записью и гарантиями на целостность данных.
  • Ленивая догоняющая фиксация данных на дисках.


  1. Главная ссылка к новости (https://github.com/leo-yuriev/...)
  2. OpenNews: Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP
  3. OpenNews: Новая версия СУБД ArangoDB 3.6
  4. OpenNews: Выпуск библиотеки хэш-функций Fast Positive Hash 2.0.1
  5. OpenNews: Выпуск LDAP-сервера ReOpenLDAP 1.1.9
  6. OpenNews: В рамках проекта LiteTree развивается вариант SQLite с поддержкой ветвления БД
Автор новости: erthink
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52147-libmdbx
Ключевые слова: libmdbx, lmdb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, user90 (?), 19:09, 07/01/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –6 +/
     
  • 1.3, Аноним (3), 19:11, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как раз недавно пригодилась нативная альтернатива mapdb. Попробую
     
     
  • 2.4, Аноним (3), 19:15, 07/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Алсо если кто-то уже использует, как оно для совсем маленьких датасетов?
     
     
  • 3.22, erthink (ok), 11:13, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Также хорошо как и для больших.
    На самом деле, то насколько (не)подходит MDBX определяется другим.

    MDBX совсем не подойдет, если:
    - много изменений, которые нельзя потерять = нужна БД с WAL.
    - много коротко живущих изменений (значения часто обновляются) и/или много коротко живущих данных (данные удаляются вскоре после добавления) = нужна БД на основе LSM.
    - требуются долгие читающие транзакции на фоне постоянных изменений.
    - требуется несколько пишущих транзакций одновременно.

    MDBX очень хорошо подойдет, если:
    - много чтения и мало изменений (характерный пример LDAP).
    - много изменений, но данные можно потерять при системной аварии.

     

  • 1.5, Аноним (5), 19:17, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это как Berkeley DB?
     
     
  • 2.12, anonymous (??), 01:31, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет.
     
  • 2.26, erthink (ok), 12:38, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Это как Berkeley DB?

    И да и нет.

    MDBX является сильно переработанным форком LMDB, в свою очередь LMDB была сделана для замены Berkeley DB в OpenLDAP.

    Поэтому API libmdbx похоже и на dbm и на Berkeley DB, но существенно проще.

     
  • 2.49, adolfus (ok), 12:38, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.
     
     
  • 3.50, erthink (ok), 15:04, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Исторически прародитель обсуждаемой СУБД создавался для замены BerkeleyDB, в ч... большой текст свёрнут, показать
     

  • 1.6, Аноним (6), 20:00, 07/01/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     
  • 1.8, ананим.orig (?), 21:25, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Библиотека MDBX является существенно переработанным ответвлением от LMDB

    прозрачная замена предполагается?
    например для самбы.

     
     
  • 2.23, erthink (ok), 11:27, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > прозрачная замена предполагается?
    > например для самбы.

    Совсем прозрачная - нет, поскольку у LMDB есть совершенно кошмарная специфика.
    Например:
    - в LMDB курсоры нужно по-разному закрывать/переиспользовать в пишущих и читающих транзакциях.
    - в LMDB DBI-хендлы нужно открывать заранее.
    - в LMDB разный формат БД для 32-битных и 64-битных платформ (не считая зависимости от endianess).

    Но никаких проблем с заменой быть не должно, только плюсы.
    В частности, в MDBX есть авто-компактификация и LIFO-политика для переработки мусора.
    Поэтому в MDBX нет одной из мега-проблем LMDB - если БД распухает (например из-за долгих читающих транзакций), то это навечно и при этом еще деградирует производительность.

     
     
  • 3.35, ананим.orig (?), 17:27, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    спасибо. как раз то что хотел услышать.
    нужно присмотреться к сабжу
     

  • 1.9, Аноним (9), 21:39, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость? Ну вроде бы это неплохо, но таких немало. Чем эта выделяется? У неё < 300 звёзд на гитхабе и не очень ясно, где она используется. То есть выглядит так, что это слабоизвестная экспериментальная разработка в области, где есть дохрена оттестированных проверенных временем решений.
     
     
  • 2.10, Аноним (6), 21:43, 07/01/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Потому что это форк LMDB. LMDB - это широко известная key-value база для хайлоада. Используется в Firefox и rpm в том числе.
     
     
  • 3.19, Сарабонг (?), 10:22, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Странно, что нет результатов сравнения с IOWOW...
     
     
  • 4.24, erthink (ok), 11:53, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Странно, что нет результатов сравнения с IOWOW...

    На сайте IOWOW есть сравнение c LMDB, в свою очередь MDBX немного быстрее LMDB.
    На всякий следует уточнить, что "внутри" MDBX до 20% быстрее LMDB, но это не видно в большинстве CRUD-тестов, так как узким место становится запись на диск.
    Но в некоторых "особо синтетических" тестах MDBX может быть чуть медленнее LMDB из-за различных дополнительных проверок (LMDB падает в корку или повреждает данные в массе случаев при неверном использовании API).

    Тем не менее, это всё достаточно условные сравнения "теплого" с "мягким". В MDBX и LMDB есть транзакции с ACID, доказанная не-ломаемость при системых авариях и отсутствие фазы восстановления, плюс неблокируемое чтение с линейным масштабирование по CPU. А в IOWOW, насколько я знаю ничего из этого нет. Это не значит что IOWOW какая-то плохая/ущербная, но показывает что это сильно разные БД для разных целей.

     
  • 2.11, Аноним (11), 22:55, 07/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость?

    Как минимум, потому что релиз 1.0. На этой стадии, кстати, вполне позволительно иметь <300 звёзд.
    Ну и БД действительно гораздо важнее всяких нескучных ZorinOS и ламeрских наeздов на линуксовый планировщик задач.

     
     
  • 3.14, Аноним (14), 02:38, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.
     
     
  • 4.37, erthink (ok), 20:50, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.

    Не история завершена, а остановлено развитие, ибо некуда.

    В libmdbx уже сделано примерно всё что можно в рамках текущего формата БД и API. Какие-то мелкие доработки и улучшения конечно возможны, но принципиальное развитие возможно только с изменением формата и сломом совместимости.

     
  • 2.15, arisu (ok), 06:14, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    потому что автору очень хочется, чтобы его велосипед заметили. и потому что порядочные люди после небольшого data mining с автором работать не хотят, и его велосипеды тоже не хотят.
     
     
  • 3.17, Аноним (-), 07:36, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > потому что автору очень хочется, чтобы его велосипед заметили. и потому что
    > порядочные люди после небольшого data mining с автором работать не хотят,
    > и его велосипеды тоже не хотят.

    Я уже сделал clone, потом профайл разработчика посмотрел и планы по "развитию" базы. И пришлось F8 нажать. "Ребята, нас надули, это не яйцеклетка, это кариес!!!"

     
  • 3.25, erthink (ok), 12:24, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    "Велосипед" давно "широко известен в узких кругах", примерно с доклада на highload++ в 2015.
    На всякий стоит отметить, что "велосипед" был сделан для Мегафона, когда ребята из Symas не смогли устранить ряд проблем.

    Ну а data mining как раз и покажет, что "порядочные люди" с "автором" вовсю работают )

    Тем не менее, для полноты картины следует упомянуть и о проблемах.
    Собственно, из публичных в production была история с мессенджером Mirinda NG - там проявился унаследованный из LMDB баг перебалансировки дерева.
    Кроме этого, было несколько багов в коде самого мессенджера (в коде БД-драйвера использующего MDBX).
    В результате это затронуло несколько десятков пользователей (если я правильно оцениваю).
    Но в целом, Mirinda NG - отдельная история, они используют свою версию libmdbx, со своими правками.
    При этом мне сложно сказать, корректны ли эти изменения и насколько корректно сейчас там используется API библиотеки.

     
     
  • 4.31, arisu (ok), 13:45, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > для Мегафона

    стало ещё хуже.

     
  • 4.44, крокодил (?), 05:20, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В миранде это под вайном не работает, приходится ждать когда допилят sqlite3 драйвер базы
     
     
  • 5.46, erthink (ok), 13:55, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В миранде это под вайном не работает, приходится ждать когда допилят sqlite3
    > драйвер базы

    Это из-за ограничений/недоделок вайна, видимо в нем не реализованы такие функции как NtExtendSection() и т.д.

    Ситуация слегка анекдотическая: MDBX была сделана для linux (не поддерживала windows), потом поддержка windows была добавлена с решением массы проблем (винда многого не умеет), теперь жалобы о том, что виндовая версия (внезапно) не работает под эмулятором винды на linux.

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

     
  • 5.51, erthink (ok), 15:35, 19/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции NtExtendSection().
    Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.

    Заведен соответствующий баг https://bugs.winehq.org/show_bug.cgi?id=48620

    В libmdbx добавлен костыль
    https://github.com/erthink/libmdbx/commit/f750086bc190d581cf3d25aa1300714dd4e2

    Вероятно в какое-то разумное время эти изменения попадут в Миранду.

     
     
  • 6.52, JL2001 (ok), 00:38, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
    > NtExtendSection().
    > Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.

    а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял

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

     
     
  • 7.53, erthink (ok), 01:49, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
    >> NtExtendSection().
    >> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.
    > а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял

    Функционал NtExtendSection() требуется для увеличения размера файла с данными "на ходу", не только без закрытия/открытия, но и автоматически при активной транзакции.

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

    Проблема Wine в том, что функция NtExtendSection() экспортируется из ntdll.dll, но при её вызове процесс тупо и безусловно терминируется, а причину можно увидеть только в логах wine (если не отключены).
    https://bugs.winehq.org/show_bug.cgi?id=48620

    Исправить это внутри Wine достаточно проблематично - нужно не только реализовать NtExtendSection(), но и существенно допеределать все управление вируальной памятью. Поэтому пришлось ставить костыли внутри libmdbx/

     
     
  • 8.54, erthink (ok), 01:59, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и коммитов получилось в итоге несколько см https github com erthink li... текст свёрнут, показать
     

  • 1.16, Аноним (-), 07:34, 08/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И всем бы хороша была либа, казалось бы. Но увы, нет в жизни счастья: разработчик стремный, политоту в профайл гитхаба тащит. Какие гарантии что он в код бэкдоров не впихнет? Читать вообще все его коммиты от и до, с особым пристрастием? И лицензия какая-то своеобразная. А так все хорошо, прекрасная маркиза.
     
     
  • 2.18, Сарабонг (?), 09:45, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > политоту в профайл гитхаба тащит.

    Adolf Hitler, Stepan Bandera, (внезапно) George Soros. Это как же надо упороться, чтобы Сороса через запятую в одном ряду с Гитлером перечислять.

     
     
  • 3.20, Аноним (-), 10:52, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не знаю, но проверять что может откаблучить такой разработчик, да еще из стремной фирмы применительно ко мне - впадлу. С такого разработчика надо все комиты под микроскопом штудировать. Лениво, сорь.
     
     
  • 4.28, Товарищ майор (?), 13:23, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    У него есть позиция и срать он хотел на твое мнение, затрода анонимная.
     
     
  • 5.33, Аноним (33), 16:47, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нет у него позиции как ему сказали так и будет.
     
  • 5.39, Аноним (-), 00:23, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У него есть позиция

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

     
     
  • 6.42, erthink (ok), 00:30, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> У него есть позиция
    > При том я догадываюсь кто в какой позе в этой позиции. Очень
    > хорошо что я профайл разработчика и планы по развитию позырил: предупрежден
    > - значит вооружен.

    А мне-то покажете где вы увидели "планы по развитию", а то я не в курсе (но может-быть забыл где-то что-то удалить/почистить)?

     
  • 3.21, Аноним (21), 10:56, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    VataDB какая-то
     
     
  • 4.27, Аноним (6), 13:21, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это не вата, это кодекс поведения государева человека.
     
     
  • 5.40, Аноним (-), 00:25, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не вата, это кодекс поведения государева человека.

    Жириновский как раз задвинул недавно и о кодексах и о том как эти государевы человеки на самом деле называются.

     
     
  • 6.45, Аноним (6), 10:27, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >2020
    >обращать внимание на Жириновского
     
  • 4.30, Аноним (30), 13:43, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    HoholDB, точнее, если уж Stepan Bandera
     

  • 1.29, Аноним (29), 13:42, 08/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ю  больше внимания уделяется качеству кода
    Фи, как несовременно!
    Сейчас надо писать быстро, потому что пока вы будете писать свой качественный код, макаки выкинут на рынок своё быстровысер, а потом вы припрётесь на рынок со своим качественным продуктом, потребитель откажется от макакоподелия и вы будете виноваты провале перспективного инновационного макакостартапа.
     
     
  • 2.32, Аноним (33), 16:46, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лучше в коде макак найти что-то годное, чем юзать продукт человека, который пише... большой текст свёрнут, показать
     
     
  • 3.34, erthink (ok), 17:08, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > про себя: "антагонист Java"

    Да, ибо не люблю лишних абстракций ради абстракций и последующей героической борьбы с ними.

    > А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба.

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

    > Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте.

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

    + Но я таки еще раз вам доставлю, написав еще одну "статью" в продолжение.
    Ибо текущий вариант внутренней сортировки в libmdbx на 10-30% быстрее std::sort, причем как на Эльбрусе, так и на x86.

    > Вангую что сабжевый автор еще дальше отъехавший чем Шигорин.

    Это комплимент, я читаю.

     
     
  • 4.36, erthink (ok), 19:11, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чтобы не быть голословным и доставить удовольствие местным анонимным икспёртам ... большой текст свёрнут, показать
     
     
  • 5.41, Аноним (-), 00:26, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux

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

     
     
  • 6.43, erthink (ok), 00:40, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux
    > А конфига которую вот просто хрен проверишь и сравнишь - специальна взята,
    > чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее
    > в гости.

    Если у вас нет Эльбруса, то вы _никак_ это не проверите, вне зависимости от прочего.

    Но как вы наверно заметили, показаны циферки и для x86-64. Попробуйте взять [исходники](https://github.com/leo-yuriev/libmdbx/blob/devel/src/elements/core.c#L1472-L20) и показать тест, в котором эта сортировка целых чисел (мне нужно именно это) не будет обгонять 'std::sort()' (с 'qsort()' сравнивать некорректно, ибо там много накладных расходов на вызов компаратора).

     
  • 3.38, Аноним (38), 23:37, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > чем юзать продукт человека, который пишет про себя: "антагонист Java"

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

     
     
  • 4.55, _hide_ (ok), 17:45, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ява работает вполне адекватно. По производительности она уделывает питон раз в 100 и проигрывает чистым сям в 2-10 раз, что не так уж и много.
    А использование фреймворка для фреймворка ещё не говорит, что тормозит язык, а не используемый подход.
    Да и ниша явы такая, что докупить пачку серверов всегда дешевле.
     

  • 1.47, Аноним (47), 18:32, 09/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > линейным масштабированием по ядрам CPU.

    Ага-ага, на графике его прямо видно.

     
     
  • 2.48, erthink (ok), 18:41, 09/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ага-ага, на графике его прямо видно.

    На графике показаны результаты теста на ноутбуке 2013-го года, с i7-4600U у которого "на самом деле" два ядра (4 в режиме HyperThreading). Информация о модели CPU есть в [README](https://github.com/leo-yuriev/libmdbx#performance-comparison). Кроме этого, там достаточно быстро узким местом становится memory bandwidth.

    Но в целом, это действительно ляп, который требует (как минимум уточнения). Поэтому спасибо за наводку!

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру