eu_tomat

Выгрузке чанков может препятствовать чанклодер. В зависимости от установленных модов возможны разные варианты чанклодеров. Мод OpenComputers, например, предоставляет чанклодеры, устанавливаемые в роботов. Такой робот держит загруженной область 3x3 чанка независимо от своего положения. Загруженная область движется вместе с роботом. Очень удобно. Стационарные чанклодеры тоже можно в некоторой степени мобилизовать. Для этого потребуются два чанклодера. Пока один чанклодер грузит область 3x3 чанка, черепашка переходит в один из загруженных чанков и устанавливает в него второй чанклодер. Потом черепашка возвращается за первым чанклодером, и переносит его в следующий чанк и т.д. Такая схема позволяет черепашке всегда находиться в загруженных чанках и не останавливать свою работу.

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

Лучше оформить эту просьбу отдельной темой. Это упростит поиск нужной информациии на форуме.

Тема не нова.

Обсуждение способов округления потеряло актуальность в этой теме и переехало в новую: Оптимизация округления в Lua.

Сделаю уточнение. Дело оказалось вообще не в этом. Все эти вспомогательные операции слишком мелкие, чтобы принимать их в расчёт. Главная причина в том, что сама по себе операция деления целых чисел в моей модели процессора выполняется медленнее, чем операция деления вещественных чисел в регистре SSE. Время деления на константу со значением 5 отличается примерно в два раза. Я сам решил проверить эту гипотезу, и она также не подтвердилась. Сама проверка оказалась не такой простой, как мне казалось на первый взгляд. Компилятор довольно хорошо оптимизирует код, заменяя операцию деления на константу операциями умножения и сдвига. В результате возникает иллюзия, будто бы целочисленное деление выполняется в три-четыре раза быстрее вещественного. Но это не так. Проверить это можно построением ассемблерного листинга. Мне пришлось постараться, чтобы компилятор перестал воспринимать содержимое переменной как константу, и наконец-то использовал операцию деления. Также умный компилятор вообще отказывался создавать код, если его результат не использовался в дальнейшем. Поэтому, в отличие от Lua, недостаточно просто сохранять результат в какую-то переменную. Этот результат надо где-то использовать. Также я пробовал отказаться от оптимизаций на этапе компиляции. Но в этом случае результат получается менее точным. В зависимости от выбранного способа записи результат может измениться не только количественно, но и качественно. Оптимизированный код обеспечивает более повторяемый результат. Эксперимент получился недостаточно чистым. Поэтому его полезно было бы повторить в кодах ассемблера, чтобы не продираться сквозь особенности компилятора. Но я пока не до конца осилил синтаксис ассемблера AT&T. Поэтому рабочая гипотеза такова: операция vdivsd процесcора Intel выполняется быстрее idivq.

Да и пусть ломают. Важен не домик, а полученный опыт строительства. Я, например, считаю свой опыт активности в этой теме позитивным. Раньше я вычислял длительность времени в целых тактах Майнкрафта таким кодом: dt = ((t2-t1)/0.05+0.5)//1 Теперь же я могу сделать то же самое кодом более простым и при этом более эффективным: dt = (t2-t1+0.025)//0.05 Разве это не прекрасно? Также теперь я знаю, что Lua предварительно вычисляет выражения, являющиеся константами. А до этого момента я думал, что это работает только в более "взрослых" языках программирования. Меньше заблуждений. Больше знаний. А домик из песка разрушится в любом случае.

Вторые пары скобок вызывают функцию так же, как и первые пары. loadfile("file") в качестве результата возвращает функцию. И для её вызова требуются скобки. component.list("gpu", true) возвращает итератор, перечисляющий все компоненты заданного типа. Но для получения первого компонента в списке этот итератор можно вызвать как функцию, что так же достигается использованием скобок.

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

В какой момент возникает ошибка? При загрузке системы? При запуске какой-то программы? Насколько часто?

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

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

Если провести аналогию с реальностью, то дети в песочнице строили домики и лепили куличики. Один из них построил домик. Спрашивает других: можно ли сделать лучше. Другие оценивают. Кто-то спрашивает: а это зачем, оно же тут лишнее. Другой говорит, нет, не лишнее, и наоборот, так даже лучше. Другие тоже заинтересовались. Обсудили, нашли лучший вариант, какой смогли, и довольные разошлись по домам. Через два дня домик смыло дождём. Но дети с радостью вспоминали опыт коллективного творчества: они обязательно применят его в своих взрослых проектах. И только вечно недовольная старуха Шапокляк злобно шептала: всё тлен, всё тлен...

Говоря о конкретике, конкретизируй. Ты сам хочешь запилить эксперимент, или просишь других его запилить? И если просишь других, то конкретизируй, какая именно конкретика тебя интересует. Какую гипотезу хочешь подтвердить или опровергнуть?

Это не совсем так. Да, компьютер регистрирует ровно те такты, которые действуют для всего Майнкрафта. В этом расхождений нет независимо от величины TPS. Но OpenComputers исполняет пользовательский код в потоке с низким приоритетом. Поэтому на перегруженном сервере компьютер, ожидая получить ответ от периферии в следующем такте, может получить результат, например, через 5 тактов. В этом случае возможно выполнить лишь 4 операции за один реакторный такт. Для качественной оценки можно пользоваться правилом: чем ниже TPS на сервере, тем чаще и продолжительнее случаются лаги компьютеров относительно игровых процессов. Для количественной же оценки требуются дополнительные исследования, как минимум. Хорошо. Я понял, что ты не вникал настолько глубоко в микроконтроль реакторов, поэтому на возникшие вопросы попробуем ответить вместе. Если что, скорректируй моё решение. А я для начала внесу коррективы в твою методику расчёта, чтобы она полнее соответствовала механике ядерных реакторов. Я рассмотрю вариант с отключением всего реактора. Предположим, от начала первой операции, отключающей реактор, и до конца последней, включающей операции проходит 4 такта. Если все операции выполнены вовремя, то фактически реактор находится выключенным 3 такта. Если мы выполняем эту серию операций, не синхронизируясь на границу реакторного такта, то с шансом 3/20 есть возможность потерять мощность, вырабатываемую реактором за реакторный такт. Или за 20 майнкрафтовских тактов. Если мы используем схему автора темы, то она требует примерно одну замену конденсатора каждые 10 секунд. Соответственно, ожидаемые потери мощности = 1/10 * 3/20 = 1.5%. На перегруженном сервере за счёт увеличения длительности операций потери увеличатся. Если же начало серии операций выравнивать на границу реакторного такта, то шанс пропустить его равен шансу того, что вся серия выполнится более чем за 20 тактов. Например, для серии из 4 операций в среднем по 5 тактов на отдельную операцию. Существует ли простой способ вычислить этот шанс в общем случае, я пока не знаю. Но его можно вычислить экспериментально на конкретном сервере и в конкретное время. И если сервер лагает не на столько, что отдельная операция выполняется более чем за 5 тактов, то реактор вообще не снижает свою мощность при его временном отключении. Даже когда операция длится ровно 5 тактов, ожидаемые потери всё ещё нулевые. На практике же длительность операций отклоняется от среднего значения, поэтому шанс потери мощности всё-таки не нулевой. Но сейчас для простоты рассуждений предположим, что отдельная операция выполняется ровно за 5 тактов, что позволяет успешно работать варианту с отключением реактора без снижения мощности. И если мы вдруг вдруг решили гасить не весь реактор, а отдельный ТВЭЛ, то в этом случае серия операций потребует уже не 20 тактов, а 25, что гарантированно приводит к потере мощности одного изъятого ТВЭЛ'а и его соседей. В примере схемы автора темы это 1/10 * 100/3840 = 0.26%. Потери небольшие, но они имеются. Плюс ко всему создаётся дополнительная нагрузка на сервер. На первый взгляд, вариант не впечатляет в сравнении с предыдущим. Но всё может поменяться, если средняя длительность отдельной операции составит 6 тактов. В этом случае синхронизация никак не поможет защититься от потери мощности. Потери варианта с полным отключением реактора будут составлять 10%. Зато потери варианта с заменой одного ТВЭЛ составят стабильные 0.26%. Правда, в этом случае план должен учитывать, что замена должна выполняться не чаще одного раза в два реакторных такта. Или в зависимости от возможностей сервера ещё реже. Надеюсь, мне удалось достаточно ясно изложить суть проблемы. Вывод, который я смог сделать: вариант с заменой одного ТВЭЛ'а оптимален, если программист не хочет синхронизировать управление с реакторным тактом, либо синхронизация из-за сильных лагов сервера невозможна.

Я и пытаюсь понять, на чём основана твоя уверенность. Да, конденсаторы меняем в разное время. Причём, намеренно в разное, чтобы повысить шанс вписаться в размер такта реактора. Работать быстрее будет лишь в одном случае, и то ценой снижения мощности реактора: Для замены одного конденсатора с использованием отключения реактора требуется 4 операции. При использовании свободного слота требуется выполнить всего 3 операции. Но заплатить за это придётся снижением мощности реактора. Поэтому слот освобождаем лишь по необходимости, но тогда для замены одного конденсатора потребуется уже 5 операций. Если извлекать смежные с к конденсатором ТВЭЛ'ы, то возникают варианты. Если ТВЭЛ всего один, то требуются 4 операции. Но, как правило, ТВЭЛ'ов больше одного. Если их 2, потребуется уже 6 операций, а если их 4, то операций требуется 10. Для ненагруженного сервера такое увеличение нагрузки не критично, но там и защита от лагов не требуется. Редкие микролаги не сильно мешают. Зато на перегруженном сервере каждая дополнительная операция в серии увеличивает шанс не закончить её в отведённое время. Что мы имеем в итоге: Обычный способ замены конденсаторов с отключением реактора. С некоторой вероятностью пропуска реакторного такта и полной потерей мощности за пропущенный такт. Есть медленные способы замены. Они уменьшают потери мощности в единичном инциденте, но повышают вероятность самого инцидента. Есть быстрый способ замены. Он сводит к нулю вероятность непредвиденного снижения мощности. Но снижает плановую мощность. Каждый из этих способов имеет свои недостатки, и у меня нет уверенности в абсолютном преимуществе одного из них.

В этом нет смысла потому, что эту задачу можно решать постепенно, а не одним большим куском. Но если очень хочется пойти экстенсивным путём, то можно и второй компьютер подцепить. У меня есть положительный опыт разгрузки алмазного сундука на 108 слотов за три такта (тика). То есть, теоретически ничто не мешает полностью пересобрать реакторную схему между реакторными тактами. Практически же схема является более требовательной к вычислительным мощностям и устойчиво работает только при отсутствии лагов. Да и сама она на слабом сервере становится лагодромом. Но на тестовом сервере результаты впечатляют. Интересное компромиссное решение. Хорошо, что останавливается лишь часть реактора. Но плохо, что увеличивается количество операций. Это является критичным на лагающих серверах. Можешь объяснить в каких случаях такой способ замены предпочтительнее полного останова реактора? Эта схема уменьшает потери от единичного инцидента, но увеличивает частоту самих инцидентов. С одной стороны, реактор не отключается полностью и поэтому лишь слегка снижает выработку энергии, если во время замены конденсаторов возникает всплеск лагов. С другой стороны, увеличение количества операций повышает шанс на то, что этот всплеск приведёт к снижению выработки. Какой из этих двух эффектов проявляет себя сильнее, и в каких условиях?

Он внимательно читал сообщения и применил полученные знания на практике.

На эту тему есть хорошая статья от @Fingercomp:

История этой находки следующая. Пытаясь прояснить для себя нюансы механики реактора, я многократно перекладывал компоненты в реакторе и каждый раз заново включал и выключал реактор. В конце концов меня этот процесс утомил, и я попытался его упростить. Для этого я проверил возможность перемещения теплоотводов без останова реактора. Новый подход не только ускорил мои исследования, но и позволил обнаружить большую роль именно моментов извлечения и помещения компонентов в реактор. Так родилась идея микроконтроля ядерных реакторов. Практически все первые проверки той или иной идеи микроконтроля я выполняю вручную. Благо, для этого не требуется высокая скорость. Главное, попадать в такт процессам реактора. Да и это не всегда требуется. Кстати, по-русски правильно говорить именно такт, а не тик. Но айтишники зачастую впервые узнают это слово либо из англоязычных источников, либо от других айтиншиков, которые уже используют кальку с английского. Но старые электронщики, учившиеся по советским учебникам, используют термины такт и тактовый сигнал.

Компоненты ломаются во время реакторного тика до генерации энергии.

Реактор производит вычисления с компонентами один раз в секунду. Это событие можно назвать реакторным тиком. Можешь предложить лучший термин. Далее каждый майнкрафтовский тик (или просто тик) реактор генерирует некоторое количество энергии, вычисленное в момент последнего реакторного тика. В это время реактор продолжает работу независимо от наличия красного сигнала. Наличие или состояние компонентов реактора не играет никакой роли до следующего реакторного тика. Эти утверждения основаны на экспериментальных данных.

Об этом выше уже упомянул @serafim : Но с этим вроде как разобрались: На практике проверял я. Момент узнать можно. Ты в своей программе уже выполняешь проверку tr.getStackInSlot(sides.up,23).damage > 1000. И если будешь сравнивать значение прочности с полученным на предыдущем шаге, ты поймаешь тот майнкрафтовский тик, в который был выполнен реакторный тик конкретно этого реактора. Следующий реакторый тик повторится ровно через 19 майнкрафтовских тиков. И так далее с интервалом 20 тиков, пока чанк не перезагрузится. После перезагрузки чанка потребуется синхонизироваться заново. За 19 тиков теоретически можно выполнить 9 обменов конденсаторов. Или даже 10 обменов, если отказаться от постоянного чтения запроса прочности конденсатора. Но всё это актуально, если нет лагов. Даже на ненагруженном сервере иногда случаются микролаги, и в запасе оказывается не 19 тиков, а всего 18. Да и транспозер также может отработать не за положенный тик, а за два. А на лагающем сервере вообще может потребоваться несколько тиков. К сказанному добавлю, что короткое отключение реактора в правильно выбранный момент и вовсе не приводит к снижению выработки энергии. Главное, держать реактор включенным в момент реакторного тика. А в течение остальных 19 тиков реактор можно держать выключенным, без конденсаторов и топлива. Такова механика. Если интерес чисто теоретический, то конденсаторы можно менять без останова реактора. На лагающих же серверах реактор лучше останавливать, правильно выбрав момент. При наличии лагов отключение подстрахует от взрыва. А при отсутствии лагов реактор даже и не заметит отключения. Но нужно помнить, что все эти лишние включения-выключения создают нагрузку на сервер. Как, собственно, и непрерывная проверка износа конденсатора также нагружает сервер. Следующая идея, которая поможет успешно решить задачу: слона надо есть по частям. То есть, не надо пытаться между реакторными тиками поменять сразу все конденсаторы. Схема с тремя столбиками конденсаторов выдаёт 9856 hu/s. Ёмкость же лазуритового конденсатора составляет 100k hu. Это значит, что замена конденсатора требуется в среднем один раз в 100000/9856 = 10.146 секунд. За это время пройдёт 10 реакторных тиков. В идеале реактор будет требовать внимания один раз в 10 секунд. Но такое планирование требует серьёзно расшевелить мозги, да и алгоритм может оказаться тяжеловатым для сервера. Но можно решить задачку попроще: спланировать график ближайших замен всех компонентов таким образом, чтобы за один реакторный тик требовалось не более одной замены. А если ещё и отказаться от непрерывной проверки износа конденсатора, то получим рекордные две операции на один реакторный тик. Это будет лучшей защитой как управления реактора от лагов сервера, так и самого сервера от некачественного управления реактором.

Самое значимое из темы "Очень много электричества": Быстрее транспозера ничего пока не придумали. Возможность менять конденсаторы, не отключая реактор, имеется. Но универсальный рецепт отсутствует. Остальная информация менее значима. Что для тебя является значительным в контексте этой темы?

Осталось найти ещё 36 ошибок.