Интересно, автор слышал про Квинтетную модель данных? Это как раз самодостаточная, предельно унифицированная структура, применяемая на практике, в отличие от теории здесь.
FPGA использует конкретные механизмы, конкретные полупроводниковые решения и стандартные коммутации. Мы же применим свои приемы коммутации и оркестрирования, не ограничиваясь существующими решениями в этой области. Наше решение не будет основано на переконифгурировании FPGA хитрым образом, хотя первый прототип вполне себе может быть собран на существующей элементной базе с гигантскими накладными расходами, как это успешно делает наша квинтетная модель данных в обычной реляционной СУБД.
Я пытался объяснить это в статье: это будет единое поле самых простых исполнителей, даже, я бы сказал, поле кирпичиков, из которых эти исполнители строятся. Рабочий фрагмент, который делает полезную работу, -- это комбинация кирпичиков, создающая простых исполнителей. Исполнитель работает так: 1. Получает задачу 2. Конфигурируется по очень простым правилам для её выполнения, задействуя соседние поля при необходимости, 3. Выполняет задачу 4. Передает результат заказчику задачи 5. Если пришла новая задача, а исполнитель занят, он передаёт её далее, причем это происходит прозрачно для исполнителя, он не прерывает работу Пока состав поля и его исполнителей я объяснить не могу, потому что это не готово. Но вы обязательно узнаете о прогрессе, как он будет.
Функционально похоже, но архитектурно и физически будет выполнено по-другому. Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
У нас софт работает хорошо именно потому что это no-code, в котором толковые разработчики когда-то заранее продумали и запрограммировали простые действия, из которых всё собирается.
Вот здесь в моем комментарии приведен пример мониторинга одного из наших серверов. Там зарегистрировано 1500+ баз клиентов, ежемесячно активны около 150 клиентов, у которых под 300 пользователей суммарно, из которых в пиковые часы работают 30-60 одновременно. Вот они прекрасно параллелятся как между базами, то есть, работают полностью независимо, так и внутри одной базы, когда работают с несвязанными напрямую сущностями.
И им не нужно даже показывать прогресс-бар, потому что даже работая с одной таблицей в БД, они не конфликтуют, ожидая запрос 10-30 мс.
Анимация используется для развлечения пользователя, пока он ждет выполнения. Она же не делает работы сама и никак не влияет на скорость выполнения работы, результат которой вы ожидаете. Работа делается где-то на другом компе/сервере.
Тогда кроме ожидания будет ещё неопределенность: работает оно или нет. Когда в Windows 2000 появился бесконечный (зацикленный) прогресс-бар, это был лютый треш с точки зрения пользовательского опыта, но то что творится сейчас при загрузки сайтов и приложений, это многократно хуже.
Как ядра, нашедшие у себя результат, сообщат об этом владельцу запроса? Да так, чтобы не мешая друг другу. Должен быть сложный протокол согласования, кто с кем и когда говорит, посложнее, чем само примитивное ядро.
Это сложная задача, которую надо будет решить. Почти самая сложная во всем проекте.
Вот эту проблему со слоями мы практически решили квинтетной моделью данных и ядром конструктора приложений: пользователь конфигурирует своё приложение и оно работает, минуя множество абстракций, сборку и необходимые для них соответствующие компетенции.
Покликать можно здесь:
https://integram.io/
https://habr.com/ru/articles/465161/
Интересно, автор слышал про Квинтетную модель данных? Это как раз самодостаточная, предельно унифицированная структура, применяемая на практике, в отличие от теории здесь.
Подход следует поменять радикально, иначе -- да, стандартным путем идти шансов нет.
FPGA использует конкретные механизмы, конкретные полупроводниковые решения и стандартные коммутации. Мы же применим свои приемы коммутации и оркестрирования, не ограничиваясь существующими решениями в этой области.
Наше решение не будет основано на переконифгурировании FPGA хитрым образом, хотя первый прототип вполне себе может быть собран на существующей элементной базе с гигантскими накладными расходами, как это успешно делает наша квинтетная модель данных в обычной реляционной СУБД.
Я пытался объяснить это в статье: это будет единое поле самых простых исполнителей, даже, я бы сказал, поле кирпичиков, из которых эти исполнители строятся.
Рабочий фрагмент, который делает полезную работу, -- это комбинация кирпичиков, создающая простых исполнителей. Исполнитель работает так:
1. Получает задачу
2. Конфигурируется по очень простым правилам для её выполнения, задействуя соседние поля при необходимости,
3. Выполняет задачу
4. Передает результат заказчику задачи
5. Если пришла новая задача, а исполнитель занят, он передаёт её далее, причем это происходит прозрачно для исполнителя, он не прерывает работу
Пока состав поля и его исполнителей я объяснить не могу, потому что это не готово. Но вы обязательно узнаете о прогрессе, как он будет.
Так это почти то же, что в прошлой вашей ссылке.
Нет, концептуально всё иначе.
Функционально похоже, но архитектурно и физически будет выполнено по-другому. Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
Да, динамически конфигурируемые
В исходном комментарии я жалуюсь, что на элементарное действие нужно столько накладных расходов, что даже нужен прогресс-бар, чтобы юзер не заскучал
Прогресс-бар на фронте, с бэком и его распределенными вычислениями не связан. Или я не так понял?
Если тема про клиентскую станцию и рендеринг аяксовской крутилки, то это другая тема.
У нас софт работает хорошо именно потому что это no-code, в котором толковые разработчики когда-то заранее продумали и запрограммировали простые действия, из которых всё собирается.
Вот здесь в моем комментарии приведен пример мониторинга одного из наших серверов. Там зарегистрировано 1500+ баз клиентов, ежемесячно активны около 150 клиентов, у которых под 300 пользователей суммарно, из которых в пиковые часы работают 30-60 одновременно. Вот они прекрасно параллелятся как между базами, то есть, работают полностью независимо, так и внутри одной базы, когда работают с несвязанными напрямую сущностями.
И им не нужно даже показывать прогресс-бар, потому что даже работая с одной таблицей в БД, они не конфликтуют, ожидая запрос 10-30 мс.
Анимация используется для развлечения пользователя, пока он ждет выполнения. Она же не делает работы сама и никак не влияет на скорость выполнения работы, результат которой вы ожидаете. Работа делается где-то на другом компе/сервере.
Скорее, конструктивно это будет квадрат, после нанесения слоев куба на единую поверхность.
А вы пробовали? Тут есть интерактивные уроки ideav.online
Тогда кроме ожидания будет ещё неопределенность: работает оно или нет. Когда в Windows 2000 появился бесконечный (зацикленный) прогресс-бар, это был лютый треш с точки зрения пользовательского опыта, но то что творится сейчас при загрузки сайтов и приложений, это многократно хуже.
Это сложная задача, которую надо будет решить. Почти самая сложная во всем проекте.
Ссылку из статьи пришлось убрать, но вот она:
https://habr.com/ru/companies/neoflex/articles/433058/
Вот эту проблему со слоями мы практически решили квинтетной моделью данных и ядром конструктора приложений: пользователь конфигурирует своё приложение и оно работает, минуя множество абстракций, сборку и необходимые для них соответствующие компетенции.