Лидеры

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

Нет, офк. Я ж скинул аналогичный результат на чистом консольном луа той же версии, так чего на разность модов-то грешить? Загвоздка явно в поведении железяк. Но боюсь, я абсолютно некомпетентен в этом вопросе, чтобы сгенерировать какие-либо выводы. Цпуинфа: 8 model name : Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz

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

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

Спасибо

Железо скорее. Луа-консоль запускал на рабочей вдске, сервак кубача поднимаю там же, т.к. сингловый клиент на дешманском ноуте умирает с TLWY даже на 1млн итераций, не говоря уже о 20 млн. С точки зрения дилетанта могу предположить, что наибольшее влияние на однопоточные вычисления оказывает набор инструкций ЦП, объем кеша и частота. Возможно, надо байт-код для каждого метода и каждой машины чекать, чтобы сказать наверняка (он вообще может отличаться для одинаковых версий луа?)

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

Как это влияет?

OpenComputers-MC1.12.2-1.7.5.192.jar

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

Интервал зависит от кол-ва итераций, а оно такое же, как в примере Zer0Galaxy. Тестил я на десктопном некомпилируемом Lua 5.3.1, лень кубач было ставить. Не нравится? Да пожалуйста, вон результат на 2e7 итераций: Constant 1.152 Upvalue 1.375 math.floor 1.749 floor (no indexing) 1.425 Lua 5.3+: num + 0.5 // 1 1.524 Lua 5.2+: num - num % 1 1.733 И на опенкомпах: Один фиг победа за первым методом

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

Чекнул дополнительно пару известных вариантов округления. Топикстартеру респект за наиболее производительное решение: Constant 0.017 Upvalue 0.023 math.floor 0.027 floor (no indexing) 0.025 Lua 5.3+: (num + 0.5) // 1 0.022 Lua 5.2+: num - num % 1 0.026

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

@Fingercomp Опыт подтверждает твои выводы: local uptime=require("computer").uptime local function round1(num) return num + (2 ^ 52 + 2 ^ 51) - (2 ^ 52 + 2 ^ 51) end local huge = 2 ^ 52 + 2 ^ 51 local function round2(num) return num + huge - huge end n = 1000000 start=uptime() for i=1,n do round1(1.234) end print("Constant ",uptime()-start) start=uptime() for i=1,n do round2(1.234) end print("Upvalue ",uptime()-start) start=uptime() for i=1,n do math.floor(1.234+0.5) end print("math.floor ",uptime()-start) Предложенный топикстартером вариант эффективнее и моего и floor()

обменник руды с поддержкой словаря руд ( ore dictionary ) https://pastebin.com/jaYhuD0k или pastebin get jaYhuD0k exchange требуется мод OpenPeripheral после запуска обязательно снять клавиатуру с экрана Ложем в сундук руду (например медную индастриал крафт и получаем два медных слитка индастриал крафт или меди из других модов) множитель Х2 можно настроить под отдельные руды слитки будут в том же сундуке, обменник заберёт ровно столько руды сколько может обменять слитков из МЕ на экран выводится список принимаемой руды, множитель, а также сколько слитков доступно в МЕ сети также к МЕ можно поставить переработчик руды (дробилка + печка) чтоб сеть сама пополняла запас слитков Поскольку список руд ручками составить тяжело, написал прогу для формирования списка https://pastebin.com/0JSr91DQ или pastebin get 0JSr91DQ list Требования: пк второго уровня (золотой) видеокарта второго уровня адаптер 2 штуки база данных первого уровня МЕ интерфейс сундук Пример сборки: