eu_tomat

Тема не нова.

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

Сделаю уточнение.

В 08.10.2021 в 20:35, eu_tomat сказал:

Операция целочисленного деления реализована гораздо более сложным кодом, нежели деление дробных чисел.

Дело оказалось вообще не в этом. Все эти вспомогательные операции слишком мелкие, чтобы принимать их в расчёт. Главная причина в том, что сама по себе операция деления целых чисел в моей модели процессора выполняется медленнее, чем операция деления вещественных чисел в регистре SSE. Время деления на константу со значением 5 отличается примерно в два раза.

В 08.10.2021 в 20:35, eu_tomat сказал:

Тем не менее я рискну предположить, что на чистом Си без вспомогательных проверок целочисленное деление выполнится быстрее нежели дробное. Даже с SSE-оптимизациями. Возможно, кто-то проверит.

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

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

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

Эксперимент получился недостаточно чистым. Поэтому его полезно было бы повторить в кодах ассемблера, чтобы не продираться сквозь особенности компилятора. Но я пока не до конца осилил синтаксис ассемблера AT&T. Поэтому рабочая гипотеза такова: операция vdivsd процесcора Intel выполняется быстрее idivq.

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

Есть основательные предположения что лучший домик или куличик всего навсего сломают те у кого не получилось.

Да и пусть ломают. Важен не домик, а полученный опыт строительства. Я, например, считаю свой опыт активности в этой теме позитивным.

Раньше я вычислял длительность времени в целых тактах Майнкрафта таким кодом: dt = ((t2-t1)/0.05+0.5)//1

Теперь же я могу сделать то же самое кодом более простым и при этом более эффективным: dt = (t2-t1+0.025)//0.05

Разве это не прекрасно?

Также теперь я знаю, что Lua предварительно вычисляет выражения, являющиеся константами. А до этого момента я думал, что это работает только в более "взрослых" языках программирования.

Меньше заблуждений. Больше знаний. А домик из песка разрушится в любом случае.

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

Что именно означают вторые пары скобок? Для чего они нужны?

Вторые пары скобок вызывают функцию так же, как и первые пары.

loadfile("file") в качестве результата возвращает функцию. И для её вызова требуются скобки.

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

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

Обычно происходит просто так, но не часто.

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

15 минут назад, TayzlexBH сказал:

Причём это даже на обычной OpenOS)

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

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

Ну-ка, ну-ка, какая ее часть тебе кажется недостаточно оптимизированной и почему?

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

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

В общем, всё сложно, но всё возможно.

29 минут назад, TayzlexBH сказал:

Столкнулся с проблемой, too long without yiedling, что делать?

Если проблема проявляется не часто, достаточно заново включить компьютер.

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

Существует более сложный путь: заняться оптимизацией MineOS.

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

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

Если провести аналогию с реальностью, то дети в песочнице строили домики и лепили куличики.

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

Через два дня домик смыло дождём. Но дети с радостью вспоминали опыт коллективного творчества: они обязательно применят его в своих взрослых проектах. И только вечно недовольная старуха Шапокляк злобно шептала: всё тлен, всё тлен...

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

Как на счет запилить репродуцируемый эксперимент, чтобы обсуждение поконкретнее было?

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

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

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

А при чем тут перегруженость сервера? Если ТПС сервера 10 тогда и реактор работает в 2 раза медленее и комп также.

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

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

24 минуты назад, whiskas сказал:

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

Я и пытаюсь понять, на чём основана твоя уверенность. Да, конденсаторы меняем в разное время. Причём, намеренно в разное, чтобы повысить шанс вписаться в размер такта реактора.

Работать быстрее будет лишь в одном случае, и то ценой снижения мощности реактора:

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

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

Что мы имеем в итоге:

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

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

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

Второй компьютер позволит превозмочь ограничения ОС? Т.е. две отдельные системы из контроллера и транспозера, которые мониторят каждая свою половину.

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

В этом нет никакого смысла, исходя из информации, предоставленной @eu_tomat, если во время замены конденсаторов, происходит реакторный тик, то нагрев все равно произойдет

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

21 час назад, whiskas сказал:

Впринципе можна менять конденсаторы через метод из openPeripheral.swapStacks. Просто нужно будет иметь в реакторе 1 пустую клетку. Всегда туда ложить целый конденсатор и потом менять его с поломаным. В этом случае реактор никогда не останется без конденсатора и можна будет заменять их не офая реактор. 

Второй способ вынимать стержни урана (моха) которые охлаждает данный конденсатор. В этом случае отключение реактора будет точечное и не сильно будет влиять на общую прыбыль. 

Интересное компромиссное решение. Хорошо, что останавливается лишь часть реактора. Но плохо, что увеличивается количество операций. Это является критичным на лагающих серверах.

Можешь объяснить в каких случаях такой способ замены предпочтительнее полного останова реактора?

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

2 минуты назад, prop сказал:

Потом вообще убрал её.

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

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

Я вот хочу, например, понять сколько каждая GPU операция стоит времени. Как мне это максимально точно определить?

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

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

Забавно выходит

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

Практически все первые проверки той или иной идеи микроконтроля я выполняю вручную. Благо, для этого не требуется высокая скорость. Главное, попадать в такт процессам реактора. Да и это не всегда требуется.

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

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

А компоненты ломаются до генерации энергии или после?

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

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

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

Реактор производит вычисления с компонентами один раз в секунду. Это событие можно назвать реакторным тиком. Можешь предложить лучший термин.

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

Эти утверждения основаны на экспериментальных данных.

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

не совсем понятно, что значит "универсальный рецепт отсутствует"?

Об этом выше уже упомянул @serafim :

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

есть маленькая проблема - низкий TPS на сервере + лаги

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

Но с этим вроде как разобрались:

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

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

На практике проверял я. Момент узнать можно.

Ты в своей программе уже выполняешь проверку tr.getStackInSlot(sides.up,23).damage > 1000. И если будешь сравнивать значение прочности с полученным на предыдущем шаге, ты поймаешь тот майнкрафтовский тик, в который был выполнен реакторный тик конкретно этого реактора. Следующий реакторый тик повторится ровно через 19 майнкрафтовских тиков. И так далее с интервалом 20 тиков, пока чанк не перезагрузится. После перезагрузки чанка потребуется синхонизироваться заново. За 19 тиков теоретически можно выполнить 9 обменов конденсаторов. Или даже 10 обменов, если отказаться от постоянного чтения запроса прочности конденсатора.

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

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

выключение реактора и замена конденсатора много времени не занимает,

да энергии чуть меньше расчётной, но зато это безопасно

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

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

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

Следующая идея, которая поможет успешно решить задачу: слона надо есть по частям. То есть, не надо пытаться между реакторными тиками поменять сразу все конденсаторы. Схема с тремя столбиками конденсаторов выдаёт 9856 hu/s. Ёмкость же лазуритового конденсатора составляет 100k hu. Это значит, что замена конденсатора требуется в среднем один раз в 100000/9856 = 10.146 секунд. За это время пройдёт 10 реакторных тиков. В идеале реактор будет требовать внимания один раз в 10 секунд. Но такое планирование требует серьёзно расшевелить мозги, да и алгоритм может оказаться тяжеловатым для сервера.

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

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

есть ли возможность менять их, не выключая реактор? Может какие то методы быстрее других?

Самое значимое из темы "Очень много электричества":

• Быстрее транспозера ничего пока не придумали.
• Возможность менять конденсаторы, не отключая реактор, имеется. Но универсальный рецепт отсутствует.

Остальная информация менее значима.

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

Я пролистал тему про "Очень много электричества" тут на форуме и не нашел ничего значительного.

Что для тебя является значительным в контексте этой темы?

В 06.10.2021 в 17:40, MURRCHAY сказал:

У меня есть скрипт, для рекламы, после того, как я его сохранил у меня появилось 37 ошибок в юнити, помогите!

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

Всё что могу сказать, так это что тебе нужно поставить в конце } так как ты не закрыл class

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

Мы ж программисты. Давай рассуждать логически.

49 минут назад, prop сказал:

Я поделился информацией, остальное кто-то додумал сам.

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

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

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

Смотрим выше и видим конкретные места в исходниках (с кусками ассемблерного кода и описанием причин):

В 08.10.2021 в 20:35, eu_tomat сказал:

# lobject.c:81: case LUA_OPIDIV: return luai_numidiv(L, v1, v2);

...

# lobject.c:60: case LUA_OPIDIV: return luaV_idiv(L, v1, v2);

Выше есть и результаты замера пар int/float и int/int:

В 02.10.2021 в 23:37, eu_tomat сказал:

$ 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

 

В сухом остатке в твоём посте новой информацией оказались лишь результаты замера для пары float/float. Да и то, для операции обычного деления, а не целочисленного. А это разные операции: в случае обычного деления не требуется округление результата.

Начинался же пост претенциозной фразой:

6 часов назад, prop сказал:

Эксперименты - это хорошо, когда нет более надежных источников.

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

Полагаю, вопрос ценности и новизны исчерпан. Возвращаемся к исходному вопросу.

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

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

Что именно ты предлагаешь? Как эту тему назвать? О чём она? Об оптимальном способе округления? Об оптимизации кода? О целочисленном делении? Какие посты предлагаешь перенести из этой темы в новую? Или ничего переносить не надо, а просто процитировать в новой теме?

И о объединении каких материалов идёт речь? Что, с чем и как предлагаешь объединять? И как предлагаешь систематизировать наработанный материал, учитывая, что на результат измерений влияет не только оборудование, но и другое ПО, разделяющие общие с Lua ресурсы?

Была когда-то тема с похожей идеей. Но там тоже всё сложно.

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

В 02.10.2021 в 23:37, eu_tomat сказал:

$ 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

 

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

И, кстати, чем обосновано это противопоставление?

55 минут назад, prop сказал:

Эксперименты - это хорошо, когда нет более надежных источников.
...

Идем в сорсы.

Оба подхода дополняют друг друга.

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

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

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

42 минуты назад, prop сказал:

// сначала конвертирует всё в инт

Во-первых, эта гипотеза не подтверждается исходниками 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

Теперь почитаем приведённый выше учебник Роберту – наше всё – Иерузалимски:

Цитата

Integer division converts operands to integers and does an integer division

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