Я правильно понял, что вы собираетесь взять «процессор на порядок примитивнее 4004» (даже я, даже на самом грубом качественном уровне не представляю, как это вообще работает), выдать ему 520 байт SRAM, полметра DRAM, а потом «замостить плиточкой» из этого весь чип, чтобы повязать чипы в такой вот куб?
Нет, неправильно
Засада там в том, что каждый нано-вычислитель сможет достучаться до нужных данных только через цепочку других таких же, которым для этого придётся прервать свою работу.
Вот это надо будет решить, чтобы не прерывать.
Это всё очень грубое описание: про наноисполнителей и передачу задач. Надо будет применить нетривиальные решения.
В 1С поддерживаются только определенные законом формы и правила, в всё, что клиент нагородит себе, часто безжалостно ломается обновлениями.
Мы делаем дополнения к 1С, типа простых систем учета и планирования, каталогов, трекеров задач, табелей, биллинга, аналитики. В простом случае такие вещи можно сделать за 2 вечера, и клиент сам их может поддерживать. На 1С это будет мега-проект и куча ограничений.
Аналог не клиента 1С, а сервера, но повторюсь, об этом пока рано. Даже решенную проблему с унифицированным хранением данных мы пока не продаём массово, а коробочка -- это следующее поколение.
Пока необходимо проработать концепцию и предложить первое масштабируемое решение.
При нишу пока говорить рано, но далее, как водится, первым клиентом будет широкий потребитель, который получит черный ящик, который стоит копейки, но решает свою задачу и можно делать бэкапы. Так мы продаем сейчас другой, уже готовый, продукт, и это работает.
Исполнители задач будут слабее в 100-1000 раз, но их будет в десятки тысяч больше и они будут на порядок дешевле.
Процессор универсален и за эту универсальность мы платим, и платим всё больше, получая непропорциональное увеличение производительности.
Эта статья о новой универсальности, за которую тоже придется платить, но в этот раз мы хотим преодолеть предел, к которому вплотную подошли разработчики -- вернуть возможность масштабирования вычислительной мощности.
современный блок 32-битного умножения это шедевр конструкторской мысли, переполненный всевозможными инженерными хитростями, и заменив его готовый на гибкое решение, которое может быть сконфигурировано на всё-что-угодно, вы непременно проиграете в производительности.
Да, проиграем, возможно в 100 или 1000 раз. Это понятно и принято
Даже наличие тяжеловеса IBM не помогло хоть сколько запустить эту тему.
Бывает. Тут вот парни потратили миллионы долларов и годы времени на таблицу из 240+ колонок с 40+ индексами, а мы эту же задачу решили за 3 месяца работы и 1170 строк кода, уложившись в 5 колонок и 3 индекса.
В нашем случае мы специально выделили 3 или 4 ситуации, когда, например, запрос к базе из конструктора может быть неоптимален, и это чинится в пару кликов, например, меняется последовательность JOIN-ов таблиц.
Долго держались, но решились. Молодцы.
Да тут PHP 8 перевернул с ног на голову всё, а вы говорите архитектура. Да, сложности будут.
О, ДРАКОН. Интересный пост, спасибо!.Вряд ли поможет, но интересно.
Мы не пойдем убивать медведя, шкура которого ещё даже не поделена.
Нет, неправильно
Вот это надо будет решить, чтобы не прерывать.
Это всё очень грубое описание: про наноисполнителей и передачу задач. Надо будет применить нетривиальные решения.
В 1С поддерживаются только определенные законом формы и правила, в всё, что клиент нагородит себе, часто безжалостно ломается обновлениями.
Мы делаем дополнения к 1С, типа простых систем учета и планирования, каталогов, трекеров задач, табелей, биллинга, аналитики. В простом случае такие вещи можно сделать за 2 вечера, и клиент сам их может поддерживать. На 1С это будет мега-проект и куча ограничений.
Из практики, с этим проблем нет особо. Неудачно делают 1 запрос из 100, и это заметно сразу, до того как его скопируют много раз.
Аналог не клиента 1С, а сервера, но повторюсь, об этом пока рано. Даже решенную проблему с унифицированным хранением данных мы пока не продаём массово, а коробочка -- это следующее поколение.
Пока необходимо проработать концепцию и предложить первое масштабируемое решение.
При нишу пока говорить рано, но далее, как водится, первым клиентом будет широкий потребитель, который получит черный ящик, который стоит копейки, но решает свою задачу
и можно делать бэкапы. Так мы продаем сейчас другой, уже готовый, продукт, и это работает.Исполнители задач будут слабее в 100-1000 раз, но их будет в десятки тысяч больше и они будут на порядок дешевле.
Процессор универсален и за эту универсальность мы платим, и платим всё больше, получая непропорциональное увеличение производительности.
Эта статья о новой универсальности, за которую тоже придется платить, но в этот раз мы хотим преодолеть предел, к которому вплотную подошли разработчики -- вернуть возможность масштабирования вычислительной мощности.
Вполне удачное сравнение
Да, проиграем, возможно в 100 или 1000 раз. Это понятно и принято
Начнем анализ на уровне 1 - перемещение зарядов. Надеюсь, быстро выберем что-то готовое и поднимемся выше, иначе -- будем тут изобретать решения.
Даже и поможем ему накликать. Платформа доступна тут ideav.online. Можно зарегистрироваться в 1 клик и пройти вводные интерактивные уроки.
Да, скорее всего, свой, но для прототипа не GAAFET, а попроще. Начнём вообще с эмуляции, далее технология будет выбрана в зависимости от результатов
Запросы к базе, которые сейчас выполняются за полмиллисекунды на ssd, тогда (в 2003) отрабатываали за 10-15 мс
Это было первое, о чем меня предупредил трекер нашего стартапа, когда я рассказал про этот проект. Дадут, но есть нюансы.
О, отлично, спасибо, очень интересно!
Бывает. Тут вот парни потратили миллионы долларов и годы времени на таблицу из 240+ колонок с 40+ индексами, а мы эту же задачу решили за 3 месяца работы и 1170 строк кода, уложившись в 5 колонок и 3 индекса.
Полностью согласен
В нашем случае мы специально выделили 3 или 4 ситуации, когда, например, запрос к базе из конструктора может быть неоптимален, и это чинится в пару кликов, например, меняется последовательность JOIN-ов таблиц.
Ок, принято. Попробуйте там вот это.
Ах, там лимит 200к записей, облом.
Ок, давайте сравним с чем хотите. Десятки пользователей одновременно, база и сервер на 1 машине, загрузка видна на графике.
Там работают несколько клиентов, у самого большого 100+ пользователей, 40+ виртуальных магазинов, 6000+ товаров, тысячи заказов в работе.