Перейти к содержимому
whiskas

Виртуальные компоненты

Рекомендуемые сообщения

Не знаю была ли такая темка раньше. Если да то напишите.

После прочтения этой темки у меня возникла идея. А если к каждому внешнему компоненту подключать компютер и подключать его к серверу. Потом написать программу что будет виртуализировать компоненты компов для сервера к примеру.  vcomponent.transposer.getStackInSlot(index). и при этом запросе сервер отправит сетевой реквест компу что б он выполнил component.transposer.getStackInSlot(index) и вернул результат. Понятно что прийдется реализовать какиеэто колбеки.

Тогда теоретичиски можна будет ускорить работу многих програм засчет обхода ждания тика. 

Сам вопрос который я задаю себе. Сможет ли 1 вещ пройти 10 транспоузеров за 1 тик?

Изменено пользователем whiskas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А отправка по сети сколько времени занимает?

~~~

Кажется, отличная идея: паковать все операции для всех компонентов в один пакет и отправлять broadcast-ом. Таким образом можно уменьшить задержку вызова всех компонентов до задержки вызова broadcast

Изменено пользователем hohserg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
59 минут назад, whiskas сказал:

у меня возникла идея

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

 

Но есть нюанс. Распараллеливание эффективно, когда отдельные задания, отправляемые подчинённым компьютерам, сравнительно крупны. Иначе затраты на администрирование кластера могут сожрать любой прирост производительности.

 

54 минуты назад, whiskas сказал:

Тогда теоретичиски можна будет ускорить работу многих програм засчет обхода ждания тика.

Многих? Можешь привести десяток примеров, где ускорение окажется ощутимым?


Да, теоретически можно ускорить работу некоторых специфических программ в некоторых специфических условиях. Но надо учесть лаги: лаг на отправку команды по сети, лаг на отправку ответа и лаг на приём всех ответов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
45 минут назад, eu_tomat сказал:

Многих?

Сейчас я пишу казино с используванием селекторов из овпен перипхерал. (Селекторов 16 шт) Иза бага там нельзя использовать .setSlots(). Приходится юзать setSlot(). В итоге 9*16 = 144 тика идет на выведение вещей на селекторы.

 

Старые проги для хранения ресурсов тож станут быстрее ибо можна будет передать вещ из любого сундука в любой за 1 тик а не за количество задействуваных транспоузеров. Также видил прогу что выводит содержымое кучи сундуков на монитор. Там можна розпаралелить и тогда можна будет обновлять сундуки каждый тик а не каждых (количество сундуков/20) сек.

 

Можна будет заюзать в реакторах для ускореной замены стержней и охладителей (меньше шанс взорвать). Ибо в реактора куча сторон где можна поподключать куча транспоузеров/адаптеров.

 

Можна сделать комп что будет мониторить куча реакторов и их состояние.

Изменено пользователем whiskas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
33 минуты назад, whiskas сказал:

(Селекторов 16 шт) Иза бага там нельзя использовать .setSlots(). Приходится юзать setSlot(). В итоге 9*16 = 144 тика идет на выведение вещей на селекторы.

Соглашусь. Тут приходиться костылить всеми доступными способами.

 

34 минуты назад, whiskas сказал:

можна будет передать вещ из любого сундука в любой за 1 тик а не за количество задействуваных транспоузеров

А это сомнительно. Есть рабочие примеры такого трюка?

 

35 минут назад, whiskas сказал:

Также видил прогу что выводит содержымое кучи сундуков на монитор. Там можна розпаралелить и тогда можна будет обновлять сундуки каждый тик а не каждых (количество сундуков/20) сек.

А этот лагодром чем оправдан? Да, чисто теоретически это интересно. Но на реальном сервере это получается какое-то вредительство. Игрок и содержимое одного-то сундука неспособен проанализировать за один тик, не говоря уже о десятке-другом.

 

41 минуту назад, whiskas сказал:

Можна будет заюзать в реакторах для ускореной замены стержней и охладителей (меньше шанс взорвать).

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

 

Да и в других задачах тоже нет смысла использовать виртуальные компоненты или групповое управление компонентами. Это неэффективно. Нужна возможность передать на исполнение свой кусок задачи и периодически контролировать состояние исполнителей.

 

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

 

1 час назад, whiskas сказал:

Можна сделать комп что будет мониторить куча реакторов и их состояние.

Можно. Но какое преимущество тут дают виртаульные компоненты?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
24 минуты назад, eu_tomat сказал:

Можно. Но какое преимущество тут дают виртаульные компоненты?

количество обновлений. Ибо если ты мониториш 200 реакторов то при 20 тпс ты обновляеш юайку раз в 10 сек

24 минуты назад, eu_tomat сказал:

А это сомнительно. Есть рабочие примеры такого трюка?

 

Я ж задал этот вопрос. Сейчас зайду в майн протещу

Изменено пользователем whiskas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зашел и протестил. Кароче план с транспоузерами накрылся. Модем берет 1 тик на сообщение.

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

 

 

Запускал такие проги на компах.

Скрытый текст

image.png.cee2fe4d68f96b0485647fd94c62aa53.png

 

 

компы так стоят http://prntscr.com/tujqci

 

было 3 транспоузер. В 1 сторону передавало за 1 запуск. (вещ проходила 3 транспоузера)

а в другую сторону пригало по 1. (типо как обычно)

Изменено пользователем whiskas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну виртуальные компоненты могут быть полезные еще в обходе количества компонентов)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как проверить, что предмет передался за 1 тик?

 

2 часа назад, whiskas сказал:

А передача вещей неспашет ибо транспозеры сработают все в 1 тик в рандомной очереде и потом гадай куда вещ ушла)

А что, если в задаче конвейер? Типо, нужно постоянно из сундука А передавать стаки предметов в сундук Б и между ними несколько промежуточных сундуков? Тогда имеет смысл активировать все транспозеры синхронно(с точностью до тика). Тогда не учитывая разогрев(передача нескольких первых предметов) и охлаждение(передача последних нескольких предметов) скорость перемещения предметов как раз будет 1 стак/тик независимо от количества промежуточных сундуков. 

В задаче с конвейером виртуальные компоненты очень помогут.

 Соглашусь с @eu_tomat: виртуальные компоненты дают прирост производительности на ограниченном классе задач

Изменено пользователем hohserg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
22 минуты назад, hohserg сказал:

А как проверить, что предмет передался за 1 тик?

 

большым количеством сундуков). Или уменьшив тики модом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
14 часа назад, hohserg сказал:

В задаче с конвейером виртуальные компоненты очень помогут.

Для увеличения производительности требуется минимизировать коммуникацию. Поэтому и в задаче с конвейером надо уходить от идеи виртуальных компонентов. Тогда схема становится асинхронной, где каждый из узлов получает своё задание и выполняет его с максимально возможной скоростью, изредка общаясь с головным компьютером.

 

С задачей увеличения производительности виртуальные компоненты пока справляются плохо. Но в этой идее есть рациональное зерно.

 

В 05.08.2020 в 12:04, whiskas сказал:

к каждому внешнему компоненту подключать компютер и подключать его к серверу. Потом написать программу что будет виртуализировать компоненты компов для сервера

Предлагаю расширить изначальную идею и считать виртуальным компонентом весь удалённый компьютер (микроконтороллер, робот, дрон) с любыми подключенными к нему реальными компонентами.

 

А вместо синхронно управляемого конвейера я предлагаю систему умных воронок.

 

Умная воронка это микроконтроллер со встроенным транспозером и простой программой в EEPROM, которая принимает к исполнению задачу от управляющего компьютера. Задачи могут быть любыми: перемещать все обнаруженные предметы с максимальной скоростью с запада на юг, или с востока и севера наверх; выбирать направление перемещений в зависимости от типов предметов или других условий; сообщать управляющему компьютеру об изменениях в инвентаре; и т.п.

 

При этом далеко не всем микроконтроллерам требуется работать на пределе возможностей и порождать лагодромы. Зачастую требуется проверка инвентаря раз в минуту или реже. Производственная логистика в Майнкрафте легко поддаётся планированию, что позволяет избавиться от ежетиковых проверок.

 

Управляющий компьютер может посылать умным воронкам новое задание, если предыдущее задание предусматривает возможность его отмены. Или может ставить текущий процесс на паузу. Или давать временные задания, прекращающиеся по таймеру или иному условию.

 

Умные воронки время от времени посылают на управляющий компьютер короткий отчёт, чтобы тот знал, что воронки не зависли. Время отправки отчётов можно выбирать псевдослучайно, чтобы равномерно размазать передачу сообщений во времени. Управляющий компьютер может давать воронкам команду на отключение или будить их.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, eu_tomat сказал:

микроконтроллер со встроенным транспозером

емм это вроди невозможно. Там можна контроллер инвентаря вроди но транспоузер подключить нельзя

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
14 минуты назад, whiskas сказал:

емм это вроди невозможно. Там можна контроллер инвентаря вроди но транспоузер подключить нельзя

Засовываем транспозер в контроллер во время сборки.

В EEPROM пишем код:

-- EEPROM для микроконтроллера со встроенным транспозером:
-- ладодром, переносящий предметы снизу вверх.

local transfer = component.proxy(component.list"transposer"()).transferItem

while true do
  transfer(0,1)
end

Работает, проверено на OC 1.7.5.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Делал хранилище на умных трубах, всяко умнее "умных воронок".

Компьютер держит в памяти все сундуки и чтобы извлечь нужный предмет, в нужном количестве, двигает транспозерами предметы по цепочке сундуков. Это вот совсем никак не запараллелить, ибо сначала надо дать команду на самые дальние транспозеры, потом ближе и ближе.

Зато не требуется постоянно стучать по сундукам, не надо ставить по компу на транспозер, система включается, отрабатывает команду и выключается моментально (максимально возможная цепочка занимает 12 тиков)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
51 минуту назад, Doob сказал:

хранилище на умных трубах, всяко умнее "умных воронок".

Не всяко. Зависит от масштабов логистики и от применения в каждой конкретной ситуации. Параллельная обработка позволяет манипулировать одновременно несколькими стаками предметов, что иногда может оказаться полезным. И я надеюсь, что это обсуждение поможет отделить полезные применения от вредных.


А в остальном я с тобой согласен: не надо заставлять сервер молотить то, что можно получить без молочения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, микроконтроллерам не требуется проводка, поэтому можно сделать хранилище большей плотности - фулл заполненный n*m*k куб в шахматном порядке.

По сравнению с проводными транспозерами будет лишь задержка в один тик на отправку сообщения с инструкциями всем воронкам

Изменено пользователем hohserg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, hohserg сказал:

Кстати, микроконтроллерам не требуется проводка

А енергию они откуда брать будут?

Ну и задержка в 1 тик звучит не сильно много. Но это 1 тик на действие что длится 1 тик. Тоесть в 2 раза медленее

Изменено пользователем whiskas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю в случае с транспоузерами что б сделать максимальную скорость нужно просто их соеденять правильно. Не делать просто палку из транспоузеров. (ибо с последнего сундука при 20 транспоузерах будет вещ ити 1 сек). А соеденять их более компитентно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 06.08.2020 в 19:44, whiskas сказал:

Ну и задержка в 1 тик звучит не сильно много. Но это 1 тик на действие что длится 1 тик. Тоесть в 2 раза медленее

Потому-то я и предлагаю не заниматься микроконтролем микроконтроллеров. Например, если требуется быстро перегнать сотню стаков, то даём всей цепочке микроконтроллеров макрозадачу: перегнать 100 стаков. И пусть они пытаются перемещать, пока каждый из них не насчитает 100 успешных перемещений, или не истечёт таймаут в случае неполадок.

 

В случае одной операции накладные расходы удваиваются. А в случае 100 операций они составляют всего один процент.

 

Если цепочки перемещений длинные, то имеет смысл вспомнить о роботах. Они способны перемещать 8 стак*блок/тик. Транспозеры же перемещают всего 2 стак*блок/тик. Транспозеры в 4 раза медленее, при этом они требуют в 8 раз больше операций на единицу времени и в 32 раза на единичное перемещение стака.  Поэтому роботы более предпочтительны для транспортировки на дальние дистанции. Минус роботов лишь в ожидании погрузки и разгрузки, но на длинных дистанциях это не критично.

Изменено пользователем eu_tomat
upd: в 32 раза на единичное перемещение стака

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...