eu_tomat

Мы ж программисты. Давай рассуждать логически. Да, додумал. Благо, вариантов не так много. Например, ты согласен с источником, и в случае его ошибочности заблуждаешься вместе с ним. Либо, отдавая себе отчёт в некорректности утверждения, намеренно вводишь читателей в заблуждение. Я предпочёл первый вариант. Додумал. Какие ещё существуют причины для вброса ложного утверждения? Смотрим выше и видим конкретные места в исходниках (с кусками ассемблерного кода и описанием причин): Выше есть и результаты замера пар int/float и int/int: В сухом остатке в твоём посте новой информацией оказались лишь результаты замера для пары float/float. Да и то, для операции обычного деления, а не целочисленного. А это разные операции: в случае обычного деления не требуется округление результата. Начинался же пост претенциозной фразой: Мораль: обесценивая сообщения предыдущих участников и претендуя на новизну, будь готов к тому, что любой высказанный тобой тезис также будет подвергнут оценке и, возможно обесценен. Полагаю, вопрос ценности и новизны исчерпан. Возвращаемся к исходному вопросу. Что именно ты предлагаешь? Как эту тему назвать? О чём она? Об оптимальном способе округления? Об оптимизации кода? О целочисленном делении? Какие посты предлагаешь перенести из этой темы в новую? Или ничего переносить не надо, а просто процитировать в новой теме? И о объединении каких материалов идёт речь? Что, с чем и как предлагаешь объединять? И как предлагаешь систематизировать наработанный материал, учитывая, что на результат измерений влияет не только оборудование, но и другое ПО, разделяющие общие с Lua ресурсы? Была когда-то тема с похожей идеей. Но там тоже всё сложно.

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

Во-первых, эта гипотеза не подтверждается исходниками Lua. Во-вторых, не подтверждается экспериментально. Усечённый листинг исходников я уже продемонстрировал, теперь настало время демонстрации. 1. Этот эксперимент показывает явную зависимость типа возвращаемого результата от типов операндов: > return 7//3 2 > return 7.0//3 2.0 В первом случае результат целочисленный, а во втором – дробный. Если операнды предварительно округляются, то зачем приводится к дробному типу результат операции? Да и и если бы эта гипотеза была верна, то операция с целочисленными операндами выполнялась бы быстрее, нежели с дробными. А ситуация явно противоположная. 2. Этот эксперимент демонстрирует, что округляется лишь результат, но не операнды: > 3 // 1 3 > return 3.1//1.1 2.0 > 3.9 // 1.9 2.0 Теперь почитаем приведённый выше учебник Роберту – наше всё – Иерузалимски: Практика является критерием истины и в данном случае позволяет считать утверждение об округлении операндов ошибочным. Ошибаются все. И авторы учебников тоже. Даже хорошие авторы хороших учебников. И я тоже могу ошибиться. Поэтому не верь мне, а проверь.

О том и речь. Делимое-то тоже целочисленное. Всё целочисленное: и операция деления, и делимое, и делитель, и частное. Но есть нюанс. Для понимания сути происходящего пришлось погрузиться в чтение исходников Lua. Пересказывать всю цепочку поисков слишком долго. Поэтому кратко изложу принципы. Сначала ищем по всем файлам фрагмент "idiv", затем сопоставляем, что откуда вызывается, а для завершения картины запрашиваем построение ассемблерного листинга нужных файлов с использованием опций из makefile. В сухом остатке имеем: Есть две разные операции целочисленного деления: для целых и для дробных чисел, как бы странно это не звучало. Операция целочисленного деления реализована гораздо более сложным кодом, нежели деление дробных чисел. Целочисленное деление дробных чисел: # lobject.c:81: case LUA_OPIDIV: return luai_numidiv(L, v1, v2); vdivsd %xmm1, %xmm0, %xmm0 # v2, v1, tmp101 vroundsd $9, %xmm0, %xmm0, %xmm0 #, tmp101, <retval> ret Целочисленное деление целых чисел: # lobject.c:60: case LUA_OPIDIV: return luaV_idiv(L, v1, v2); movq %rcx, %rdx # v2, movq %rax, %rsi # v1, jmp luaV_idiv # ... luaV_idiv: leaq 1(%rdx), %rax movq %rdx, %rcx cmpq $1, %rax jbe .L350 movq %rsi, %rax cqto idivq %rcx xorq %rsi, %rcx js .L351 ret ... Часть кода вырезана, там обрабатываются проверки деления на ноль и работы с отрицательными числами. Но и в этом куске кода почти все операции выполняют эти самые проверки. Необходимыми же операциями являются лишь idivq, да ret. Возможно, там нужны ещё какие-то операции перемещения из регистра в регистр, но они быстрые в сравнении с названными выше. Влияют. Тем не менее я рискну предположить, что на чистом Си без вспомогательных проверок целочисленное деление выполнится быстрее нежели дробное. Даже с SSE-оптимизациями. Возможно, кто-то проверит.

Lua не перестаёт удивлять. $ lua5.3 -e 't0=os.clock()local v for i=1,1e9 do v=i//1.0 end print(os.clock()-t0)' 11.848781 $ lua5.3 -e 't0=os.clock()local v for i=1,1e9 do v=i//1 end print(os.clock()-t0)' 16.08497 Операция целочисленного деления на целочисленную константу работает медленнее, нежели на константу с плавающей точкой. Соответственно, округление (val+0.5)//1.0 также будет выполняться быстрее, чем (val+0.5)//1.

Мы тут все слегка изменяем код Zer0Galaxy. Это фрагмент варианта ECS. Ему, похоже, было лень менять название на другое. И я тоже не стал переделывать. Название вводит в заблуждение, но логика кода верная. computer.uptime() возвращает округлённое до целых тиков время работы компьютера с момента его включения. os.clock() возвращает время, в течение которого компьютер был занят вычислениями, не округляя его до тиков. Конкретно в этом случае для измерения уместнее использовать именно os.clock.

Это-то я и пытаюсь понять. Выше я упомянул, что готов пересмотреть это объяснение. В этом контексте оно не является обоснованием верности одних или других результатов измерений. Это скорее объяснение того, почему я изначально усомнился в правильность твоих замеров, списав возникшее расхождение на обычную погрешность. Я перепроверил. На этой версии наши результаты также расходятся. Это стандартный пакет? Какой-либо модификации не подвергался? Если нет, то остаётся только влияние железа. Какой у тебя процессор? Процессор, на котором проводил замеры я: $ cat /proc/cpuinfo | grep name | uniq -c 8 model name : Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz

Я несколько лет пользовался другим объяснением, но с учётом новой информации его, возможно, придётся пересмотреть. А объяснение было таким. На обычных операциях (если это не обработка длинных строк или преобразование больших таблиц) наибольший вклад в затраты времени даёт интерпретатор Lua. Вклад же полезной нагрузки минимален. Поэтому простая функция, написанная на Lua, будет исполняться дольше функции из стандартных библиотек. И мой опыт всегда подтверждал эту гипотезу. Ситуация может резко измениться, если отказаться от оборачивания кода в функцию. Например, вынеся код return (num+0.5)//1 из функции можно получить примерно 5-кратное ускорение выполнения этого участка кода. И это тоже объяснимо. Обработка вызова функции, наверное, во всех языках программирования является затратной в сравнении с арифметическими операциями. Кстати, @OpenReactor, обрати на это внимание. Наиболее быстрый способ округления на Lua не должен содержать вызова какой-либо функции.

Тогда что влияет? Какие предлагаешь варианты?

Что-то не бьются у нас результаты. Какая у тебя версия OpenComputers?

Что-то у тебя интервал времени получился крошечный. Там погрешность получается большая. Возьмём интервал побольше. Код: Результат: Итог: лучшее время стабильно показывает local floor=math.floor Версия мода OpenComputers-MC1.7.10-1.7.5.1290-universal.jar

Чуть лучше или по крайней мере не хуже должен быть вариант с использованием local floor=math.floor. Вызов же math.floor имеет двойную цену: за обращение к полю таблицы (глобальной переменной) и за, собственно, вызов функции. Что и видно по результатам теста. Локальный же вызов floor() работает шустро. А учитывая, что вариант с использованием floor() выглядит наиболее очевидно, имеет смысл предпочесть именно его.

На каком сервере уже разрешили майнить?

В общем случае Lua не имеет простого и быстрого механизма сравнения двух произвольных таблиц. В промежуточных случаях есть возможность применить некоторые трюки для ускорения операций. Предлагаю понаблюдать за работой этих команд: component.inventory_controller.store(1,1,component.database.address,1) component.database.computeHash(1) component.me_interface.getAvailableItems()[1].fingerprint.nbt_hash Первая команда запоминает в первом слоте апргейда базы данных информацию о предмете, находящемся в первом слоте сундука, стоящего над контролером инвентаря. Вторая команда вычисляет хеш информации о предмете с учётом NBT-тегов. Третья команда также получает хеш, но уже от МЭ-сети и исключительно NBT-тегов. То есть, два разных предмета, но с одинаковыми тегами будут иметь одинаковые хеши. Этот подход также имеет некоторые сложности: Эти хеши не совпадают, но ассоциативные возможности таблиц Lua позволяют упростить преобразования хэшей. На каждую операцию требуется один тик времени. И если прочитать содержимое МЭ-сети можно за одну операцию, то на обработку каждого слота сундука требуются две операции. Это может представлять проблему для сундуков со свободным доступом для игроков, но информацию о содержимом сундуков с исключительно программным доступом можно кешировать, чтобы избегать повторных вычислений. В конкретно этом случае также возможны хитрости. Необходимость частично игнорировать информацию о предмете делает невозможным прямое использование хешей. Но есть возможность заранее составить таблицы подходящих хешей с учётом вариаций показателей, которые требуется игнорировать. И даже если предварительное формирование и хранение таких таблиц представляет трудность, варианты оптимизации всё равно остаются. Например, можно хранить таблицы хешей только для пчёл, хранящихся в общей МЭ-сети, а для работы с пасеками применять отдельную МЭ-сеть, которая позволит анализировать всех вновь поступивших пчёл и хранить только актуальные хеши.

На практике OpenComputers способен выполнять довольно тяжёлые алгоритмы. Вылеты по причине длительной неуступки времени можно сделать очень редкими, а к самому компьютеру можно прикрутить подобие сторожевого таймера. Другое дело, что не существует универсального способа адаптировать произвольный алгоритм. Но в каждом конкретном случае можно найти хорошее решение, максимально использующее вычислительные возможности игрового сервера. Конкретно этой программой убить трудно. Но никто не мешает доработать её. Зачем ограничивать себя в майнинге?

Если в общий доступ, то выкладывай. Если лично мне, то не надо. Из описания я пока даже не понял, будет ли такой способ управления удобным. Про, собственно, управление не сказано ни слова. Скриншоты также отсутствуют. Как читатель сможет понять, что лично ему это будет полезным?

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

Критиковать буду саму идею. Я могу понять попытки реализовать шифрование RSA на OpenComputers. Та задача тоже сильно нагружает вычислениями игровой сервер, но она хотя бы решает какие-то игровые задачи. Да и нагрузка на сервер не постоянная. Но какие есть причины для майнинга в OpenComputers?

Как говорится, забыть computronics могут не только лишь все, мало кто может это делать. А что за база данных? Это специализированная БД для хранения каких-то определённых данных, или аналог какого-нибудь dBase?

Предлагаю проверку. В одиночной игре в творческом режиме командой oc_sc заспаунить готовый компьютер и включить его. Что покажет в этом случае?

Например, можно изучить код этой библиотеки и по аналогии написать свои функции.

Эта библиотека может хорошо помочь

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

Не совсем так. Это утверждение справедливо, если код EEPROM не был модифицирован. Например, игрок только что скрафтил EEPROM, и поэтому может быть полностью уверен в отсутствии модификаций. Модификация же кода EEPROM может привести к тому, что и при загрузке с EEPROM (Lua BIOS) появится та же ошибка, и наоборот, возможна успешная загрузка с просто EEPROM без метки. Новичку обычно не требуется этого знать, но иногда он может стать жертвой розыгрыша другими игроками. Поэтому сообщаю принцип работы этой механики: Загрузка с EEPEOM, не содержащей кода, даже с правильной меткой "Lua BIOS" приведёт к ошибке "no bios found". Загрузка с EEPROM с работоспособным кодом, даже без метки "Lua BIOS" к ошибке не приведёт. А если и приведёт, то не к этой ошибке.

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