eu_tomat

31 минуту назад, daniilFigaSystem сказал:

Я хочу mine os Старой версии!

А вопрос в чём?

В 24.07.2022 в 02:59, union сказал:

уже 1 час сижу а только 5 луашек переписал

А я тогда удивлялся, как же ты так быстро переписываешь эти луашки. А вот он, оказывается, секрет:

4 минуты назад, Fingercomp сказал:

Ловко.

18 часов назад, kintser31 сказал:

Поддержка больше 1<...

О чём идёт речь в этой фразе? На каком языке она написана?

18 часов назад, kintser31 сказал:

ТОЛЬКО белый список: все кто в него не входят отмечаются красным на экране и частицами.

Что в этой фразе значит "только"? Как обрабатывать находящихся в белом списке?

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

проблема таких утилит в том, что они идут под api конкретной ос, а вдруг у меню другая ос?

Для реализации кроссплатформености потребуется придумать какой-то стандарт хранения данных и в дальнейшем следовать ему. Данные в EEPROM могут храниться хоть в текстовом, хоть в двоичном виде. Но хранение файла конфигурации в виде текста способно обеспечить высокий уровень кроссплатформенности с минимальными накладными расходами. Игрок может скорректировать файл конфигурации, воспользовавшись любимым текстовым редактором, а затем твоя утилита считает данные из файла, приведёт информацию к более компактному виду и запишет данные в EEPROM. Главное, в каждом конкретном случае дать игроку внятную документацию, объясняющую, что даёт изменение того или иного параметра, и каковы их рабочие пределы. Я знаю два эффективных текстовых формата в среде Lua: это либо формат сериализованной таблицы, либо это обычный код на Lua. Второй формат обеспечивает лучшую производительность и гибкость.

Дав пользователю возможность отделить данные от кода в тех случаях, когда они и так фактически разделены, ты можешь сделать свою утилиту более полезной. Она, может, и не станет настолько же универсальной как flash из OpenOS, но хотя бы обеспечит большее удобство решения какого-то круга задач.

4 часа назад, rootmaster сказал:

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

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

Например, ты мне прислал файл прошивки вместе с данными, а я эти данные скорректировал под свои нужды. Затем ты исправил ошибку в прошивке и снова выслал мне файл, в котором я вынужден ещё раз корректировать эти данные, хотя я бы предпочёл иметь возможность просто выбрать файл с нужными мне данными во время прошивки. Это пример затруднений для пользователя.

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

33 минуты назад, Bumer_32 сказал:

мне кажется или счётчик тпс немнооооожечко так врёт?

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

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

да и в крафтах всё крафтится с 3 попытки

Я заходил 5 минут назад. Выполнил 3 отдельных крафта. Каждый получился с первой попытки.

3 часа назад, rootmaster сказал:

которую я не тестил, потому что пишет мол шел, а потом пишет too long without yielding(не blue скрин)

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

Иронично, что система, нацеленная на противодействие TLWY, сама не может авторизовать пользователя по причине TLWY.

3 часа назад, rootmaster сказал:

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

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

Ранее я дал приблизительную оценку производительности:

В 04.08.2022 в 16:34, eu_tomat сказал:

в реализации с coroutine.yield в каждой итерации цикла и вовсе замедлит выполнение программы раз в 100. То есть, программа будет выполняться в 100 раз дольше, сохраняя ту же нагрузку на игровой сервер.

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

OpenOS:

lua> time=computer.uptime t0=time()for i=1,1e8 do end print(time()-t0)
  1.35
lua> time=os.clock t0=time()for i=1,1e8 do end print(time()-t0)
  1.307

Цикл под Cynosure создаёт более высокую нагрузку на Cpu и поэтому часто обрывается ошибкой TLWY:

lua> time=require"computer".uptime t0=time()for i=1,1e8 do end print(time()-t0)
  -- две первые попытки оборвались ошибкой TLWY
  -- 3-я попытка: 200.45
lua> time=os.clock t0=time()for i=1,1e8 do end print(time()-t0)
  -- 4 первые попытки оборвались ошибкой TLWY
  -- 5-ая попытка: 85.68

Итоги:

• Среда Cynosure замедляет выполнение пустого цикла в 148 раз по сравнению со средой OpenOS.
• Выполнение пустого цикла в среде Cynosure снижает среднюю вычислительную нагрузку примерно в 2.26 раза, что вроде бы должно радовать, но это снижение не компенсирует возросшую длительность выполнения цикла.
• Среда Cynosure увеличивает итоговую вычислительную нагрузку при выполнении пустого цикла в 65 раз по сравнению со средой OpenOS.
• Не смотря на принятые меры по противодействию TLWY, они не снимают проблему.

19 часов назад, ProgramCrafter сказал:

В Cynosure есть файл /dev/base/load.lua: https://github.com/Ocawesome101/oc-cynosure/blob/dev/base/load.lua

Да, автор темы первой же ссылкой указал именно на этот файл.

Я тоже открыл его, но пошёл немного другим путём. Увидел ключевые слова do, repeat, и сразу вспомнил про goto. Обрушил систему этим кодом:

::c::goto c

Правда, чтобы упала и система, надо придушить ресурсы процессу Майнкрафта. Собственно, OpenOS ведёт себя похожим образом: программы вылетают с ошибкой TLWY, но сама OS продолжает работать. Но если эти трудные моменты выпадают на рестарт сервера, то падает и сама система, уже с синим экраном.

P.S.: И ещё я забыл добавить, что даже простой цикл вида while true do end, запущенный на заторможенном сервере, тоже рано или поздно уронит систему, если будет работать продолжительное время.

@ProgramCrafter А тут символ выбирается исключительно по его коду, или есть возможность как-то пролистать страницы с визуализацией самих символов?

И ещё: можешь как-то обрезать нижнюю неинформативную часть картинки с чёрным фоном?

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

после входа в root ос приветствует, а потом too long without yielding....

Вот прямо сразу после приветствия? Вообще интересно стало.

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

наконец-то что-то новенькое в open computers подъехало, да еще и unix-like круто, мне нравиться

Unix-like, конечно радует, но производительность в простых циклах очень огорчает.

12 часа назад, rootmaster сказал:

банально может не хватить места для этого, а нужно же еще как-то чекать валидность данных

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

Но, предположим, ты всё-таки не будешь сжимать блок данных:

13 часа назад, rootmaster сказал:

все равно задать данные по умолчанию проше, и на мой взгляд более правильно и элегантно

...

могут меняться, могут нет, могут меняться, но не все

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

14 часа назад, rootmaster сказал:

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

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

13 часа назад, rootmaster сказал:

если утилита flash шьет только сам скрипт, то утилита eeprom целый образ

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

39 минут назад, rootmaster сказал:

могу разве что pull-request кинуть, но вряд ли его кто-то примит

Как думаешь, почему так мало шансов на принятие?

40 минут назад, rootmaster сказал:

ты же понимаешь что данные в eeprom-data могут быть любые?

Ты же понимаешь, что данные на то и данные, что зависят от конкретных условий и могут меняться? А если эти данные могут меняться в процессе работы, то что мешает в процессе же работы их и сформировать?

5 часов назад, rootmaster сказал:

там могут быть не только адреса, но и настройки биос, уже приводил пример, но приведу еще раз, там может быть таблица "{}" или даже уже забитая данными "{password = '222', oemUnlock = false, oemUnlockAllow = true}" и в код это может банально не влезть

И эти данные никогда не меняются иначе как со сменой прошивки?

5 часов назад, rootmaster сказал:

но а в друг мне нужно часть кода поместить прямо в eeprom-data дабы сэкономить место?

Вот тут соглашусь, я и сам таким баловался. Правда, в том случае в первую очередь использовалось сжатие кода, т.к именно оно обеспечивало максимальную экономию памяти, поэтому чтение из области данных EEPROM возлагалось на распаковщик, а запись в EEPROM — на упаковщик. Заметной прибавки это решение не давало, порядка 5%, но поиграться с дополнительной памятью было увлекательно.

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

@ProgramCrafter Спасибо. Теперь мне всё ясно. Падает не только сама проблемная программа, но и вся система. Падение по TLWY воспроизводится так:

• Запускаем программу:

  local count =0
  for i=1,1e8 do
    count = count+1
  end
  print(count/1e6)

   

• Ограничиваем вычислительные ресурсы сервера
• Дожидаемся синего экрана с надписью TLWY

То есть, заявленная задача не решена: падает не только приложение, но и вся система. А самое интересное заключается в том, что решение, о котором я недавно рассказывал, к падению не приводит, и при этом раз в 50 меньше нагружает сервер:

В 28.07.2022 в 15:56, eu_tomat сказал:

Единственно верным ориентиром для оценки приближения TLWY является значение os.clock().

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

@ProgramCrafter А тебе удалось разобраться, как в этой системе создать новый файл или изменить имеющийся? А то мне эта система при любой попытке записи говорит "device is readonly".

Я даже нашёл свой старый пост, в котором когда-то обсуждал этот способ решения проблемы:

В 02.09.2017 в 18:23, eu_tomat сказал:

1) Подменить load своей функцией, автоматически расставляющей по всему коду вызовы yielding. Недостатки этого способа в том, что он провоцирует повышенное потребление памяти и процессорного времени, и годится не для любого кода. Достоинство в том, что потенциально он может спасти систему от падения в TLWY из-за одного кривого приложения.

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

Однако, блуждая по просторам основного форума opencomputers, я наткнулся на операционную системуCynosure, которая делает невозможное возможным.

Борьба с ошибкой "too long without yielding" или борьба за параллелизм не являются абсолютными целями. Вопрос всегда в цене этой борьбы.

У нас на форуме где-то имеется тема, в которой один из наших товарищей тоже писал многозадачную систему. И одной из идей также было вставлять в разные места программы какой-то сервисный код, который мог бы приостановить выполнение потока. Решение рабочее, но его производительность оставляет желать лучшего. А в реализации с coroutine.yield в каждой итерации цикла и вовсе замедлит выполнение программы раз в 100. То есть, программа будет выполняться в 100 раз дольше, сохраняя ту же нагрузку на игровой сервер. Мне это кажется слишком высокой платой как за параллелизм, так и за возможность забыть об ошибке TLWY. Тем более, TLWY преодолевается и без использования специальной операционной системы.

Данные EEPROM, конечно, полезны. Но зачем хранить их вместе с прошивкой, если они содержат уникальные, практически не повторяющиеся адреса?

В 02.08.2022 в 06:45, rootmaster сказал:

иногда хотеться выложить файлом чтобы другу отправить

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

В 02.08.2022 в 18:50, rootmaster сказал:

чужим софтом не пользуюсь, но с подобной ситуацией сталкивался, прошивая один из моих биосов после lua bios он крашился, так как в eeprom-data был адрес загрузочного диска, а биос ожидал там увидеть адрес монитора, по сути любая программа может работать некорректно если не стереть eeprom-data

Ты же совсем недавно пропагандировал следование стандартам. А стандартная прошивка Lua BIOS успешно справляется с некорректными данными в EEPROM. И не просто справляется, а сама корректирует неверные данные. То есть, проблемы нет. Или от следования стандартам ты уже отказался?

Опцию защиты от записи, пожалуй, можно было бы и добавить в утилиту прошивки. Но какой смысл хранить это состояние в файле вместе с прошивкой? Решение о защите должен принимать игрок, исходя из его текущих потребностей, а не автор прошивки. Автор может лишь рекомендовать установить защиту, указав соответствующий флаг в строке запуска утилиты.

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

Похожая история однажды приключилась и со мной. Я тоже модифицировал утилиту flash и тоже выдумал свой формат, который, к слову, был полностью совместим со стандартной утилитой. В тот раз я поставил задачу хранить метку в одном файле с прошивкой. Это позволило мне быстро (с интервалом примерно в 2 ммнуты) создавать новые версии прошивок и при этом легко ориентироваться в содержимом инвентаря.

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

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

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

Теперь делаем консервы на наковальне

Это как? Что за механика такая?

39 минут назад, Fingercomp сказал:

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно.

Интересная возможность. А можно ли с помощью подобного функционала задать метку EEPROM?

4 часа назад, rootmaster сказал:

и мог нормально в лс сообщить о отсутствии ссылки?

Я вообще думал, что ты создал эту тему ради шутки. Как-то слишком удачно тут совпало отсутствие ссылки на программу с отсутствием потребности в ней. А фраза "идея подобной утилиты напрашивалась давно" ещё более усилила атмосферу абсурда.

4 часа назад, rootmaster сказал:

что за хейт?

Хейтом принято называть открытое эмоциональное выражение ненависти, враждебности, злости. Собственно, английское слово хейт и означает ненависть. А что называешь хейтом ты?

Но раз тема не шуточная, можно обсудить её по существу:

В 28.07.2022 в 16:11, rootmaster сказал:

есть стандартная утилита flash в openOS, но она просто прошивает файл в основной раздел eeprom

проблема это утилиты в том, что она не стирает eeprom-data что может привести к некорректной работе некоторых программ

аж установить eeprom-data полмолчания, уж подавно нельзя

Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

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

То есть как понял я,  у меня есть ровно 5 секунд, для занятия потока, для того что бы выполнить вычисления, и если я не успею это сделать ровно в 5 секунд реального времени то мод убьёт мой "процесс", и комп упадёт по TWYL?  

Да, примерно так. Возможно, не 5 секунд, если изменить значение в файле конфигурации. И реальность времени там очень условна. Сколько времени займёт выполнение того или иного кода, спрогнозировать сложно. Но именно os.clock даёт точное понимание того, сколько этого времени осталось.

Процесс не убивается, но генерируется исключение. Его можно перехватить, запустив код через pcall. Вместе с ошибкой TLWY ты получишь ещё 0.5 секунд времени на то, чтобы уступить время, например, вызвав computer.pullSignal, но успеешь ли ты это сделать, тоже никто не обещает. И новый слой оборачивания вызова кода в pcall уже точно не поможет.

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

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

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

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

8 минут назад, ProgramCrafter сказал:

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

Да, скопировать EEPROM  на другой сервер вместе с данными, в которых обычно хранится уникальный адрес диска, это самое нужное дело.

Да и улучшение верстака для роботов до сих пор не изобрели.

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

Ссылка на программу отсутствует, но это не страшно. Ведь полное копирование EEPROM вместе с меткой, данными и флагом ReadOnly можно выполнить на верстаке.

4 часа назад, num_pi сказал:

Могу ли я как то узнать или высчитать, что вот сейчас machine упадёт по TLWY? Ну realTime() мне не узнать, она локальная. Я так же знаю что через 5 реальных секунд, если я не освободил поток, то machine упадёт по TLWY. Есть ли способы из под виртуального пространства, что даёт мод, из её песочницы, заранее узнать/узнавать что, вот-вот и если я не сделаю паузу в вычислениях, то machine упадёт по TLWY.

Единственно верным ориентиром для оценки приближения TLWY является значение os.clock().

Более-менее устойчиво работающий код может выглядеть, например, так:

computer.pullSignal(0)
c0 = os.clock()+4
while os.clock()<c0 do
  -- вычисления
  -- ...
end

На устойчивость влияют:

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

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

Точное прогнозирование TLWY возможно на слабонагруженных серверах. Но на реальных серверах внезапно появившаяся нагрузка может сломать любой прогноз.

Выше я упоминал, что пачку из 10 вызовов computer.pullSignal(0) желательно распределять во времени. Такой подход кроме прочих его преимуществ позволяет снизить вероятность получить TLWY. Полагаю, этот момент не требует объяснений.

14 минуты назад, Laine_prikol сказал:

по каким то причинам в Lua OpenComputers удален метод collectgarbage() который как раз принудительно пинает сборщик мусора

Причина, скорее всего, та же, по которой была добавлена ошибка TLWY: излишне агрессивные программы, создающие высокую нагрузку на сервер, должны почаще уступать ресурсы. Все же знают игроков в Майнкрафт: ради экономии планки памяти мы готовы постоянно дёргать сборщик мусора, чего обычно не происходит в более реальных применениях. А существующая механика OpenComputers позволяет запрашивать уборку мусора не чаще чем один раз в 125 ms. Это и так много — 8 раз в секунду можно прибраться. По факту получается несколько реже, т.к. часть этого времени использует сама программа.

4 часа назад, ProgramCrafter сказал:

приходилось десять раз запускать os.sleep(0)

К слову, не всегда требуется запускать именно 10 раз. Бывает так, что к текущему моменту os.sleep, например, уже запускался раз 5, а внутри него было 8 вызовов computer.pullSignal. Знание этих фактов позволяет сократить ожидание перед уборкой мусора, если хочется выжать максимум.

Также желательно вызывать серию computer.pullSignal не пачкой по 10 штук, а более размеренно чередовать их вызовы с вычислительной нагрузкой. Это позволит программам на других компьютерах поддерживать ритмичность их работы, что очень важно, например, для управления ядерными реакторами.