eu_tomat

1 минуту назад, hohserg сказал:

Прикол в том, что целочисленное деление на целое число должно быть быстрее целочисленного деления на дробное

О том и речь. Делимое-то тоже целочисленное. Всё целочисленное: и операция деления, и делимое, и делитель, и частное. Но есть нюанс.

Для понимания сути происходящего пришлось погрузиться в чтение исходников 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. Возможно, там нужны ещё какие-то операции перемещения из регистра в регистр, но они быстрые в сравнении с названными выше.

8 часов назад, man_cubus сказал:

Это небось всякие оптимизации под SSE влияют

Влияют. Тем не менее я рискну предположить, что на чистом Си без вспомогательных проверок целочисленное деление выполнится быстрее нежели дробное. Даже с 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.

7 часов назад, hohserg сказал:

@Zer0Galaxy используется local uptime=require("computer").uptime, наверное @ECS скопировал его.

Мы тут все слегка изменяем код Zer0Galaxy.

7 часов назад, hohserg сказал:

@eu_tomat использует local uptime=os.clock

Это фрагмент варианта ECS. Ему, похоже, было лень менять название на другое. И я тоже не стал переделывать.
Название вводит в заблуждение, но логика кода верная.

computer.uptime() возвращает округлённое до целых тиков время работы компьютера с момента его включения.
os.clock() возвращает время, в течение которого компьютер был занят вычислениями, не округляя его до тиков.

Конкретно в этом случае для измерения уместнее использовать именно os.clock.

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

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

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

23 часа назад, ECS сказал:

OpenComputers-MC1.12.2-1.7.5.192.jar

Я перепроверил. На этой версии наши результаты также расходятся. Это стандартный пакет? Какой-либо модификации не подвергался? Если нет, то остаётся только влияние железа. Какой у тебя процессор?

Процессор, на котором проводил замеры я:

$ cat /proc/cpuinfo | grep name | uniq -c
      8 model name	: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz

11 час назад, ECS сказал:

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

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

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

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

Кстати, @OpenReactor, обрати на это внимание. Наиболее быстрый способ округления на Lua не должен содержать вызова какой-либо функции.

3 минуты назад, NEO сказал:

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

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

1 минуту назад, ECS сказал:

Один фиг победа за первым методом

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

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

Чекнул дополнительно пару известных вариантов округления.

Что-то у тебя интервал времени получился крошечный. Там погрешность получается большая. Возьмём интервал побольше.

Код:

local uptime=os.clock

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 = 2e7

os.sleep(0.05)start=uptime()
for i=1,n do
  round1(1.234)
end
print("Constant ",uptime()-start)

os.sleep(0.05)start=uptime()
for i=1,n do
  round2(1.234)
end
print("Upvalue ",uptime()-start)

os.sleep(0.05)start=uptime()
for i=1,n do
  math.floor(1.234+0.5)
end
print("math.floor ",uptime()-start)

local floor=math.floor

os.sleep(0.05)start=uptime()
for i=1,n do
  floor(1.234+0.5)
end
print("local floor ",uptime()-start)

local function round3(num)
  return (num+0.5)//1
end

os.sleep(0.05)start=uptime()
for i=1,n do
  round3(1.234)
end
print("(num+0.5)//1 ",uptime()-start)

Результат:

Итог: лучшее время стабильно показывает local floor=math.floor

Версия мода OpenComputers-MC1.7.10-1.7.5.1290-universal.jar

50 минут назад, Zer0Galaxy сказал:

Предложенный топикстартером вариант эффективнее и моего и floor()

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

А учитывая, что вариант с использованием floor() выглядит наиболее очевидно, имеет смысл предпочесть именно его.

10 минут назад, OpenReactor сказал:

Мы майним Duino-Coin (0.00106335$ прайс) примерно в день будет 3 -5 шт.

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

В общем случае 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 позволяют упростить преобразования хэшей.
• На каждую операцию требуется один тик времени. И если прочитать содержимое МЭ-сети можно за одну операцию, то на обработку каждого слота сундука требуются две операции. Это может представлять проблему для сундуков со свободным доступом для игроков, но информацию о содержимом сундуков с исключительно программным доступом можно кешировать, чтобы избегать повторных вычислений.

В конкретно этом случае также возможны хитрости.

10 часов назад, Teen_Romance сказал:

задача: в сундуке в первом слоте лежит пчела, мне нужно найти таких же пчел в me сети и переместить их в сундук. При этим, у пчел есть показатель поколений в неволе, который мне нужно игнорировать.

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

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

30 минут назад, OpenReactor сказал:

Я писал что бы узнать можно ли вообще такое реализовать. Чистый интерес.

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

20 минут назад, OpenReactor сказал:

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

Конкретно этой программой убить трудно. Но никто не мешает доработать её. Зачем ограничивать себя в майнинге?

3 минуты назад, Wolframoviy сказал:

если хочешь могу дать исходник полный, скачаешь юнити, соберёшь

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

10 минут назад, Wolframoviy сказал:

3. Ставим приложение на android - *тык*

Как-то боязно устанавливать неизвестное приложение. Как понять, что оно не содержит трояна?

Здесь уместнее был бы исходный код приложения и инструкция по его сборке.

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

Писал в рофл. Готов выслушать критику по коду и тд.

Критиковать буду саму идею.

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

Но какие есть причины для майнинга в OpenComputers?

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

занимаюсь уже разработкой базы на opencomputers и всеми забытым computronics

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

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

52 минуты назад, Leva5678567 сказал:

Я так и делал у меня так и пишет что нету биоса я вставлял именно EEPROM (Lua BIOS) и до-сих-пор эта ошибка

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

18 минут назад, GolyboiNoyName сказал:

А если без библиотеки? функций, напрмер? 

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

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

22 часа назад, hot9rot сказал:

тема мертва?

Часто встречаю подобный этому вопрос, но не понимаю его смысла. О чём он?

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

Поэтому я предлагаю вместо общефилософских вопросов на тему жизни и смерти сразу перейти к конкретике.

Что именно интересует по предложенной автором теме? Удалось ли запустить программу? Если не удалось, то какие именно возникли сложности?

В 18.09.2021 в 09:49, _bongo_ сказал:

Есть 2 вида карт биоса : EEprom и EEprom( Lua Bios ) 
Я уверен на 100% ты вставил карту EEprom которая не подходит для пк, а нужная тебе карта называется EEprom( Lua Bios )

Не совсем так. Это утверждение справедливо, если код EEPROM не был модифицирован. Например, игрок только что скрафтил EEPROM, и поэтому может быть полностью уверен в отсутствии модификаций. Модификация же кода EEPROM может привести к тому, что и при загрузке с EEPROM (Lua BIOS) появится та же ошибка, и наоборот, возможна успешная загрузка с просто EEPROM без метки.

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

Загрузка с EEPEOM, не содержащей кода, даже с правильной меткой "Lua BIOS" приведёт к ошибке "no bios found".

Загрузка с EEPROM с работоспособным кодом, даже без метки "Lua BIOS" к ошибке не приведёт. А если и приведёт, то не к этой ошибке.

6 минут назад, Del сказал:

Нет, такое изменение не будет принято. Да и я не думаю, что кто-то будет делать такие странные изменения.

Согласен. Слоники не всем нравятся. Все же котиков любят.

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

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

Собираюсь сделать что-то вроде ос для серверов, может быть с гуи, минимум ресурсов на ось, мультизадачность.

В чём специфика операционных систем именно для серверов применительно к OpenComputers? И как должна проявить себя мультизадачность?

11 минуту назад, Del сказал:

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

Каков текущий список задач?

9 минут назад, Del сказал:

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

А если я переделаю какой-нибудь GUI на кнопочки в виде слоников, такое изменение будет принято?

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

Да и вообще, я же написал что эта фигня бесполезна, может потом что-то годное и выйдет, типо майн ОС, но похуже и полегче

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

Обычно идея о написании новой программы или системы приходит так: Нам нужна программа с определённым свойством. Ничего подобного мы не видели. Давайте напишем сами.

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

Похоже, что в этой теме речь идёт о втором случае. Сама-то по себя идея достойная, но меня смущает этот момент:

17 часов назад, Del сказал:

Вы можете нам помочь! Если вы программист, и вы хотели бы учавствовать в жтом, напишите мне в ЛС, с удовольствием приму вас.

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

16 минут назад, Del сказал:

Я теперь не один. Пока что не буду говорить об этом человеке, мало ли...

Сколько бы вас там ни было, нет смысла создавать тему в разделе "Программы" без самих программ.

Переношу тему в Беседку.

27 минут назад, Del сказал:

Если вы программист, и вы хотели бы учавствовать в жтом, напишите мне в ЛС, с удовольствием приму вас.

В чём именно  поучаствовать? В чём суть этой системы? Чем она будет отличаться от других?