С кэшем связана одна существенная проблема — усложнение архитектуры. Появляется дополнительный сильно связанный слой.
В конечном итоге оптимальным выбором является действительно использовать кэш минимально. Но в этом случае, встает задача эффективного выбора основного хранилища. В заметке, например, сказано что MySQL был выбран исключительно по субъективным причинам. В тоже время, возможно, если бы к выбору хранилища данных подошли бы более ответственно, то необходимость в кэшировании могла бы вообще не возникнуть.
Мы в последнее время вообще отказались и от MySQL и от кэша. В итоге производительность только улучшилась отпало множество проблем связанных с обслуживанием кэша, архитектура стала куда прозрачнее.
Кстати, в натуральном ряде нет нуля, если уж вы о чистоте наименований.
Таким образом ваш тип — это целые неотрицательные числа.
Поэтому стандартное обозначение лучше отражает истиное положение вещей чем ваше.
Они оба генерят более быстрый код. Просто на разных реальных примерах. Я как то сравнивал. Нельзя сказать какой из них быстрее. В каких то случаях Clang быстрее, в каких-то gcc.
У Clang ввод подсвечен — удобнее ошибки компиляции высматривать. Но начиная с версии 5.0 gcc тоже стал вывод раскрашивать. Так что теперь они вообще оба хороши.
В последнее время появилось много подобных библиотек и фреймворков. Но всем им не хватает полноценного шаблонизатора. Сейчас они все в основном нацелены на отдачу json.
На самом деле, забабашить именно бэкенд не так уж сложно, благо асинхронных библиотек хватает. Я не умаляю заслуг Матье Гарригес — он действительно проделал огромную работу.
А вот генерация страничек, задача по-сложнее. Хотелось бы чего нибудь эдакого, но что бы не тянуть телегу зависимостей. Вот тогда можно про динамические языки и не вспоминать.
Эх поздно я вашу заметку увидел. Не дает мне Хабр ее плюсануть уже.
Солидарен на 100%. Тоже всегда вызывает недоумение.
Самое интересное, что ассоциативные контейнеры есть ведь во многих языках. Но только в php придумали использовать их вместо объектов. И не просто придумали, это стало просто эпидемией какой-то. Пандемия.
Честно скажу, исходники Редиса не ковырял, но как я себе представляю его устройство: он может держать открытыми несколько соединений, но обрабатывает их он один за одним. Полностью. Могу ошибаться, конечно, но как иначе в рамках однопоточной архитектуры?
Может быть проблема в php-клиенте или вашем коде?
Вот этот комментарий: https://habrahabr.ru/company/pushall/blog/280218/#comment_8823146 исчерпывающе объясняет почему у вас появились проблемы.
От себя могу добавить, что у меня Редис работает c 2011-го через Unix-сокет ни разу не было проблем. Хатя нагрузки были вполне приличные.
Да и с точки зрения ОС Unix-сокет не может быть менее надежным. Я поэтому удивился когда увидел у вас такие выводы. TCP-сокет добавляет сетевой стек — это его принципиальное отличие.
У меня не установлен php 7, поэтому, к сожалению, ваш бенчмарк запустить не могу.
За 3 секунды Redis не успел их у себя до конца обработать — это одна из деталей, которую надо учитывать. Если слишком быстро считывать значения, можно поймать момент, когда они еще старые.
Редис же однопоточный и, как следствие, все операции выполняет атомарно. Или я отстал от жизни и редис сейчас уже многопоточный?
Исправьте выводы в посте, пожалуйста. Вам уже подсказали выше в комментариях о причинах ваших не правильных выводов.
Unix-сокет быстрее и надежнее TCP-сокета. Единственным недостатком использования Unix-сокета является является более сложная экосистемы.
Кстати, использовать PHP как промежуточный слой для тестирования именно редиса — не самое удачное решение.
LedMatrix создан как библиотека общего назначения. То есть она не делает ни каких предположений о конфигурации пользовательского монтажа, а допускает любую конфигурацию в рамках аппаратных ограничений.
Поэтому включение методов управления конкретной конфигурацией было бы нарушением целостности. Это архитектурно не правильно включать в библиотеку общего назначения реализацию конкретной конфигурации.
Например, матрицы могут быть скомпонованы в две строки или четыре. Или в горизонтальный блок. Или вообще для игры в тетрис.
Я согласен, что в большинстве случаев, библиотека будет использоваться (ну я надеюсь, что будет) для управления однострочной горизонтальной компоновкой. Правильное решение — это сделать отдельную библиотеку поверх этой.
У меня есть такие планы.
Если кратко, то нужно с помощью метода void setCol(const Col &col, buint8_t value); установить соответствующие столбцы.
Сейчас нет интерфейса для конвертации строки в набор символов с автоматической установкой в матрицу. Т.е. что бы работать с чем то вроде const char * / const wchar_t *.
Но как я уже сказал, это отдельная задача, которая должна быть (и возможно, будет) реализована в отдельной библиотеке.
Даже более того, благодаря constexpr и семантике переноса, исполняемый код получается даже более эффективный. Поскольку часть повторяющихся вычислений может быть перенесена на этап компиляции. А семантика переноса позволяет избежать ненужных копирований, заменив их переносом.
С чего бы коду на C++11 быть медленнее? Медленнее может быть только компиляция, да и то вряд ли и вы этого даже не заметите. А исполняемый код ни чем не будет отличаться от кода на чистом C или на классическом C++.
ТМ конечно, изверги. Столько лет не могут прикрутить отображение LaTeXa. Читать формулы булевой алгебры в виде (not X1)*X3*(not X4), X3*(not X4)*(not X5) во втором часу ночи выше моих сил. Статья на редкость интересная, но честно, пока не осиливаю. Завтра попробую на свежую голову еще раз перечитать.
В конечном итоге оптимальным выбором является действительно использовать кэш минимально. Но в этом случае, встает задача эффективного выбора основного хранилища. В заметке, например, сказано что MySQL был выбран исключительно по субъективным причинам. В тоже время, возможно, если бы к выбору хранилища данных подошли бы более ответственно, то необходимость в кэшировании могла бы вообще не возникнуть.
Мы в последнее время вообще отказались и от MySQL и от кэша. В итоге производительность только улучшилась отпало множество проблем связанных с обслуживанием кэша, архитектура стала куда прозрачнее.
Таким образом ваш тип — это целые неотрицательные числа.
Поэтому стандартное обозначение лучше отражает истиное положение вещей чем ваше.
У Clang ввод подсвечен — удобнее ошибки компиляции высматривать. Но начиная с версии 5.0 gcc тоже стал вывод раскрашивать. Так что теперь они вообще оба хороши.
На самом деле, забабашить именно бэкенд не так уж сложно, благо асинхронных библиотек хватает. Я не умаляю заслуг Матье Гарригес — он действительно проделал огромную работу.
А вот генерация страничек, задача по-сложнее. Хотелось бы чего нибудь эдакого, но что бы не тянуть телегу зависимостей. Вот тогда можно про динамические языки и не вспоминать.
Солидарен на 100%. Тоже всегда вызывает недоумение.
Самое интересное, что ассоциативные контейнеры есть ведь во многих языках. Но только в php придумали использовать их вместо объектов. И не просто придумали, это стало просто эпидемией какой-то. Пандемия.
Может быть проблема в php-клиенте или вашем коде?
От себя могу добавить, что у меня Редис работает c 2011-го через Unix-сокет ни разу не было проблем. Хатя нагрузки были вполне приличные.
Да и с точки зрения ОС Unix-сокет не может быть менее надежным. Я поэтому удивился когда увидел у вас такие выводы. TCP-сокет добавляет сетевой стек — это его принципиальное отличие.
У меня не установлен php 7, поэтому, к сожалению, ваш бенчмарк запустить не могу.
Редис же однопоточный и, как следствие, все операции выполняет атомарно. Или я отстал от жизни и редис сейчас уже многопоточный?
Unix-сокет быстрее и надежнее TCP-сокета. Единственным недостатком использования Unix-сокета является является более сложная экосистемы.
Кстати, использовать PHP как промежуточный слой для тестирования именно редиса — не самое удачное решение.
Раз уж речь о C++17, то
Как то пессимистично у вас все написано. Самое интересное, вы сами понимаете почему комитет так осторожничает. Все не так плохо.
LedMatrix создан как библиотека общего назначения. То есть она не делает ни каких предположений о конфигурации пользовательского монтажа, а допускает любую конфигурацию в рамках аппаратных ограничений.
Поэтому включение методов управления конкретной конфигурацией было бы нарушением целостности. Это архитектурно не правильно включать в библиотеку общего назначения реализацию конкретной конфигурации.
Например, матрицы могут быть скомпонованы в две строки или четыре. Или в горизонтальный блок. Или вообще для игры в тетрис.
Я согласен, что в большинстве случаев, библиотека будет использоваться (ну я надеюсь, что будет) для управления однострочной горизонтальной компоновкой. Правильное решение — это сделать отдельную библиотеку поверх этой.
У меня есть такие планы.
На самом деле, даже сейчас это совсем не сложная задача. Вот два примера:
https://github.com/valmat/LedMatrix/blob/master/examples/MultiShift/MultiShift.ino
https://github.com/valmat/LedMatrix/blob/master/examples/HelloHabr/HelloHabr.ino
Если кратко, то нужно с помощью метода
void setCol(const Col &col, buint8_t value);установить соответствующие столбцы.Сейчас нет интерфейса для конвертации строки в набор символов с автоматической установкой в матрицу. Т.е. что бы работать с чем то вроде
const char */const wchar_t *.Но как я уже сказал, это отдельная задача, которая должна быть (и возможно, будет) реализована в отдельной библиотеке.
Убедится можно так:
И смотрим папку frames
На сам скетч, который гоняет строку, я двумя комментариями ниже ссылку дал. Можете посмотреть и сами проверить.
constexprи семантике переноса, исполняемый код получается даже более эффективный. Поскольку часть повторяющихся вычислений может быть перенесена на этап компиляции. А семантика переноса позволяет избежать ненужных копирований, заменив их переносом.(not X1)*X3*(not X4), X3*(not X4)*(not X5)во втором часу ночи выше моих сил. Статья на редкость интересная, но честно, пока не осиливаю. Завтра попробую на свежую голову еще раз перечитать.