Прошу прощения. Специально достал с полки чтобы проверить, видимо я перепутал с другой попыткой протащить аудиотракт через RDP без задержек. Интересная тема, годится для отдельной статьи)
Недавно читал(если не ошибаюсь, в журнале Кот Шредингера) идею о том, что сведение к нейрону, как элементарной единице, срабатывающей на какой то пороговый стимул, не учитывает внутреннюю сложность самого нейрона, клетки, которая является эволюционным потомком одноклеточных организмов со своей внутренней логикой.
Дополнительно в экзоскелете предусмотрен функционал записи данных с датчиков, состав которых опционален и может быть выбран заказчиком под задачу
Мне кажется, одно из интересных направлений развития кроется тут - если собирать данные о движении при выполнении каких либо задач, в дальнейшем это можно использовать для роботизации, для сценариев, где классическая автоматизация невозможна или очень дорога
Мой комментарий о том, что на данный момент эта модель чудовищно неэффективна с т.з. ресурсов.
Вместо поиска/подбора причинно следственных связей появляется ритуальный магизм наподобие каргокульта
Попробую привести несколько аналогий:
Имея функционал Y=F(X) (где в данном случае F это логика игры), нейронные сети вместо поиска аналитического решения F, ищут это решение численными методами. Добавляя ресурсов оно будет бесконечно приближаться к оригиналу(если угодно, повышая порядок приближения), но это будет чудовищно неэффективно по сравнению с поиском оригинального F()
Или для хэширующей функций вместо поиска алгоритма, мы строим модель на основе радужной таблицы, и, в пределе, нам придется покрыть все пространство решений для получения приемлемого результата
Или отображение векторной/параметрической графики в растровую, где вместо поиска параметров, мы строим модель изменения конкретных пикселей
Я уверен, что средний программист, затратив определенное количество времени, сможет реализовать дум алгоритмически.
Нейросеть же оперирует результатами алгоритмов которые для нее в черном ящике(при этом затрачивая на порядки больше ресурсов) и пока даже близко не приблизилась к среднему программисту..
Об этом, собственно, немалая часть книги о которой говорят выше. Чтобы это сделать, нужна отдельная команда мотивированных профессионалов, которые могут работать практически без процесса
Если вы знакомы и с тем и с тем, то вы скорее будете выбирать технологию под конкретную задачу. Если не знакомы ни с тем, ни с тем, то, условно, кривая обучения для кафки будет sqrt(x), а для RMQ e^x.
Кроме того, на мой взгляд, для кафки нужно очень хорошо подумать сначала и потом делать, реббит в этом смысле прощает немного больше Плюс ,в энтерпрайзе, особенно если компания посажена на MS и в силу безопасности нацелена на on-prem, есть проблемы с линуксом и людьми которые его поддерживают, в то время как RMQ в дефолтной конфигурации, даже без кластеризации, будет прекрасно работать под win.
в трех словах - оно не успевает. https://www.rabbitmq.com/docs/migrate-mcq-to-qq : A quorum queue can sustain a 30000 message throughput (using 1kb messages), while offering high levels of data safety, and replicating data to all 3 nodes in a cluster. Classic mirrored queues only offer a third of that throughput and provide much lower levels of data safety
Тут, на мой взгляд указана, производительность для единственной очереди на кластере в идеальных условиях, поэтому стоит закладывать производительность с запасом на непредвиденные ситуации
В моём опыте была ситуация, когда росла внутренняя очередь сервиса отправляющего данные или, в случае цепочки очередей, первая очередь переполнялась
Поэтому для чего-то более производительного есть смысл использовать кафку, но за это придется заплатить большей сложностью как развертывания/поддержки, так и разработки
+ следить чтобы было достаточно сокетов, если они закончатся по любой причине, будут сложно отлавливаемые баги
+ если по какой либо причине закончилось место под хранилище, с большой долей вероятности оно будет испорчено
+ Не все написанное выше подходит к quorum очередям
+ В кластерной конфигурации надо очень сильно следить за состоянием кластера - ошибки в репликации или внезапные наплывы данных могут привести к рассинхронизации и, как следствие, не полученным данным
+ Как минимум в старых версиях реббит чувствителен к другой нагрузке на процессоры, при видимой средней загрузке и большом количестве context switch'ей может внезапно обрывать соединения
+ При планируемой нагрузке больше 10к сообщений в секунду стоит выбрать другую технологию
+ Подключение с oauth, проверка ландшафта и прочие улучшения могут существенно снизить производительность
+ При получении данных с concurrency > 1 порядок сообщений на клиенте не гарантирован
+ Стандартная .net библиотека не очень хорошо работает с многопоточной отправкой на большом количестве сообщений и ещё хуже с получением
Добавьте .Net, он все ещё популярен и лет на 10 минимум Легаси хватит
Прошу прощения. Специально достал с полки чтобы проверить, видимо я перепутал с другой попыткой протащить аудиотракт через RDP без задержек. Интересная тема, годится для отдельной статьи)
Доверился лагометру в веб версии. По ощущениям примерно столько же.
Да, стабильно показывает около 100мс
Недавно читал(если не ошибаюсь, в журнале Кот Шредингера) идею о том, что сведение к нейрону, как элементарной единице, срабатывающей на какой то пороговый стимул, не учитывает внутреннюю сложность самого нейрона, клетки, которая является эволюционным потомком одноклеточных организмов со своей внутренней логикой.
Этот комментарий должен быть выше?
Есть ли импортонезависимые аналоги Aris и iserver, не только для BPM но и интегрированной работы со срезами архитектуры?
Мне кажется, одно из интересных направлений развития кроется тут - если собирать данные о движении при выполнении каких либо задач, в дальнейшем это можно использовать для роботизации, для сценариев, где классическая автоматизация невозможна или очень дорога
Задумка хорошая
Нужна автоматизация, например, чтобы дальше двигаться в сторону построения решений сверху, например аналога iserver
Можно начать самим - например в теории устойчивости
И да, спасибо за статью!
Мой комментарий о том, что на данный момент эта модель чудовищно неэффективна с т.з. ресурсов.
Вместо поиска/подбора причинно следственных связей появляется ритуальный магизм наподобие каргокульта
Попробую привести несколько аналогий:
Имея функционал Y=F(X) (где в данном случае F это логика игры), нейронные сети вместо поиска аналитического решения F, ищут это решение численными методами. Добавляя ресурсов оно будет бесконечно приближаться к оригиналу(если угодно, повышая порядок приближения), но это будет чудовищно неэффективно по сравнению с поиском оригинального F()
Или для хэширующей функций вместо поиска алгоритма, мы строим модель на основе радужной таблицы, и, в пределе, нам придется покрыть все пространство решений для получения приемлемого результата
Или отображение векторной/параметрической графики в растровую, где вместо поиска параметров, мы строим модель изменения конкретных пикселей
Выглядит странно
Я уверен, что средний программист, затратив определенное количество времени, сможет реализовать дум алгоритмически.
Нейросеть же оперирует результатами алгоритмов которые для нее в черном ящике(при этом затрачивая на порядки больше ресурсов) и пока даже близко не приблизилась к среднему программисту..
Эластик отлично сюда ложится - построенный на Lucene прямо из коробки будет фасетный поиск. Кликхаус да, для другого.
Об этом, собственно, немалая часть книги о которой говорят выше. Чтобы это сделать, нужна отдельная команда мотивированных профессионалов, которые могут работать практически без процесса
Так, стоп, у нас же уже есть гит :)
Если вы знакомы и с тем и с тем, то вы скорее будете выбирать технологию под конкретную задачу.
Если не знакомы ни с тем, ни с тем, то, условно, кривая обучения для кафки будет sqrt(x), а для RMQ e^x.
Кроме того, на мой взгляд, для кафки нужно очень хорошо подумать сначала и потом делать, реббит в этом смысле прощает немного больше
Плюс ,в энтерпрайзе, особенно если компания посажена на MS и в силу безопасности нацелена на on-prem, есть проблемы с линуксом и людьми которые его поддерживают, в то время как RMQ в дефолтной конфигурации, даже без кластеризации, будет прекрасно работать под win.
Нужен минигит с clone, checkout, add, commit push, reset и флагом --force :)
А ещё visual sourcesafe, perforce, tfs..
Поверьте, не критики ради, а дополнения для
Там есть много интересных и пограничных иногда вещей, поэтому пусть это будет в комментариях к хорошой статье
в трех словах - оно не успевает.
https://www.rabbitmq.com/docs/migrate-mcq-to-qq :
A quorum queue can sustain a 30000 message throughput (using 1kb messages), while offering high levels of data safety, and replicating data to all 3 nodes in a cluster. Classic mirrored queues only offer a third of that throughput and provide much lower levels of data safety
Тут, на мой взгляд указана, производительность для единственной очереди на кластере в идеальных условиях, поэтому стоит закладывать производительность с запасом на непредвиденные ситуации
В моём опыте была ситуация, когда росла внутренняя очередь сервиса отправляющего данные или, в случае цепочки очередей, первая очередь переполнялась
Поэтому для чего-то более производительного есть смысл использовать кафку, но за это придется заплатить большей сложностью как развертывания/поддержки, так и разработки
+ следить чтобы было достаточно сокетов, если они закончатся по любой причине, будут сложно отлавливаемые баги
+ если по какой либо причине закончилось место под хранилище, с большой долей вероятности оно будет испорчено
+ Не все написанное выше подходит к quorum очередям
+ В кластерной конфигурации надо очень сильно следить за состоянием кластера - ошибки в репликации или внезапные наплывы данных могут привести к рассинхронизации и, как следствие, не полученным данным
+ Как минимум в старых версиях реббит чувствителен к другой нагрузке на процессоры, при видимой средней загрузке и большом количестве context switch'ей может внезапно обрывать соединения
+ При планируемой нагрузке больше 10к сообщений в секунду стоит выбрать другую технологию
+ Подключение с oauth, проверка ландшафта и прочие улучшения могут существенно снизить производительность
+ При получении данных с concurrency > 1 порядок сообщений на клиенте не гарантирован
+ Стандартная .net библиотека не очень хорошо работает с многопоточной отправкой на большом количестве сообщений и ещё хуже с получением