Перейти к содержимому

Лидеры


Популярный контент

Показан контент с высокой репутацией за 28.09.2021 во всех областях

  1. 8 баллов
    Экспериментальное обновление Ocelot. Я синхронизировал Ocelot Brain с последними изменениями в оригинальном моде. (Релиза у них ещё не было, но вроде фишки интересные, имеет смысл подтянуть их в эмулятор). Основное изменение это буферы видеопамяти (vram), можно делать графику быстрее и круче (в теории). Кто-нибудь уже игрался с этим? Протестируйте пожалуйста, потому что пока всё сделано на черновую. Ocelot Desktop VRAM Edition - Скачать бесплатно без СМС
  2. 6 баллов
    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.
  3. 5 баллов
    Хэй, у меня тут зачесались ручки накодить какую-нить игрульку под MineOS (а то их что-то совсем мало). Ну и я вспомнил, что угадайка была в первых версиях оси (еще на основе OpenOS). Ну, короче, GuessWord for MineOS. Из основных отличий: Игра переписана с нуля для поддержки GUI оськи. Более минималистичный и однотонный интерфейс (современная мода, а вы как хотели) Увеличен размер окна, элементы теперь крупнее. Поддержка нескольких языков (раскладка клавиатуры описывается в файле локализации, размеры не более 13х3) Поддержка ввода с реальной клавиатуры К сожалению, у меня пока еще нет базы слов для английского языка, поэтому, если кто хочет помочь с составлением, пишите сюда или в дискорд: Bs()Dd#5299. Скачать игру можно в MineOS App Market. Репозиторий на GitHub.
  4. 5 баллов
    Посмотрим на байт-код: $ echo 'local function round(nul) return nul + (2 ^ 52 + 2 ^ 51) - (2 ^ 52 + 2 ^ 51) end' | luac5.3 -l -l - main <stdin:0,0> (2 instructions at 0x55f08348ca20) 0+ params, 2 slots, 1 upvalue, 1 local, 0 constants, 1 function 1 [1] CLOSURE 0 0 ; 0x55f08348cc60 2 [1] RETURN 0 1 constants (0) for 0x55f08348ca20: locals (1) for 0x55f08348ca20: 0 round 2 3 upvalues (1) for 0x55f08348ca20: 0 _ENV 1 0 function <stdin:1,1> (4 instructions at 0x55f08348cc60) 1 param, 2 slots, 0 upvalues, 1 local, 1 constant, 0 functions 1 [1] ADD 1 0 -1 ; - 6.7553994410557e+15 2 [1] SUB 1 1 -1 ; - 6.7553994410557e+15 3 [1] RETURN 1 2 4 [1] RETURN 0 1 constants (1) for 0x55f08348cc60: 1 6.7553994410557e+15 locals (1) for 0x55f08348cc60: 0 nul 1 5 upvalues (0) for 0x55f08348cc60: Видно, что ADD и SUB тут работают с константой. Обращение к константе быстрое, доступное, лёгкое, воздушное. В предложенном варианте появляется upvalue, к которым доступ будет дольше. Так что эффективнее не станет.
  5. 3 балла
    https://pastebin.com/Er41hk6A вот програма всё работает,
  6. 3 балла
    Это обсуждение было отпочковано от темы Майнинг OpenComputer. local function round(num) return num + (2 ^ 52 + 2 ^ 51) - (2 ^ 52 + 2 ^ 51) end Вот мне просто интересно, каждый раз при вызове функции двойка будет четыре раза возводиться в степень? Не будет ли эффективнее сделать так? local huge = 2 ^ 52 + 2 ^ 51 local function round(num) return num + huge - huge end Да и подход к округлению странный. Чем не устраивает math.floor(num+0.5) ? Зачем для получения timeDifference нужно реальное время? Измерять временнЫе интервалы в OpenOS можно не пропиливая жесткий диск. И самый главный вопрос: откуда будут сыпаться биткойны и много ли уже насыпалось?
  7. 3 балла
    Во-первых, эта гипотеза не подтверждается исходниками 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 Теперь почитаем приведённый выше учебник Роберту – наше всё – Иерузалимски: Практика является критерием истины и в данном случае позволяет считать утверждение об округлении операндов ошибочным. Ошибаются все. И авторы учебников тоже. Даже хорошие авторы хороших учебников. И я тоже могу ошибиться. Поэтому не верь мне, а проверь.
  8. 3 балла
    О том и речь. Делимое-то тоже целочисленное. Всё целочисленное: и операция деления, и делимое, и делитель, и частное. Но есть нюанс. Для понимания сути происходящего пришлось погрузиться в чтение исходников 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-оптимизациями. Возможно, кто-то проверит.
  9. 3 балла
    Посмотрел я на тему "Возрождаем OpenNet (не опять, а снова)" и ради интереса решил накодить свою реализацию. Так вот. Представляю NetQuartz. Что эта ерундовина может: Многоуровневые IP адреса. Можно хоть 1.2, хоть 26.89.1.2, хоть 734.84.1.97.73.4, все зависит от вложенности роутеров. Встроенный DNS. Простенький веб-сервер и браузер с поддержкой цветов. Простая регистрация устройства в сети (хочешь подключиться - поставил ПО на клиента, написал одну команду - все готово!) Что она пока не может: Нема API. Нема всяких <hr> <a href> и прочей фигни. Ну и браузер бы полностью гуишным сделать. Тестил только на проводных подключениях! В теории конечно и вайфай должен работать, но в теории. Что она не может и добавлять не планирую: Шифровка трафика и прочая ерунда с безопасностью Терминология: роутер == маршрутизатор Корневой роутер (сервер), корень [сети] - основой компьютер, связывающий маршрутизаторы и клиентов, выполняющий функции DNS сервера и лежащий в иерархии сети выше всех. Всегда имеет IP 0.0. В одной сети может быть только 1. Маршрутизатор, роутер - компьютер, обеспечивающий перенаправление пакетов (маршрутизацию) от отправителя к получателю. Пакет (в контексте данного проекта) - 4 текстовых поля - Отправитель, Получатель, Тип, Данные Клиент - Любой компьютер / планшет / микроконтроллер / дрон / робот, подключенный к сети, являющийся конечным узлом. (То бишь, не имеющий дочерних узлов.) Узел - любое устройство в сети. Как это все работает: В контексте данного раздела "послать" == modem.send(). Все работает на 1110 порту. Если пакет типа DATA или DNSANSWER (в последнем случае 3-ий шаг выполнятся не будет, т.к. пакет уже послан с корня сети.): Клиент-отправитель посылает пакет на роутер, который его зарегистрировал в сети. Роутер получает пакет. Теперь есть несколько вариантов обработки: 1. Получатель находится в подсети роутера (включая вложенные подсети): роутер находит MAC узла, находящегося в адресе получатеся сразу после IP данного роутера и посылает на него пакет. Здесь неважно, является ли этот узел роутером или уже клиентом. Если получит роутер - пункт 2 повторится. 2. Получатель находится вне подсети роутера: Здесь еще проще - роутер просто посылает этот пакет родительскому узлу. Корневой сервер получает пакет. Данный шаг будет проделан, только если во время 2-ого шага роутеры добросали пакет вверх прямо до корня (например, в случае если отправитель 1.2, а получатель 2.3). Тут происходит все то же самое как и в 2.1. Клиент-получатель принимает пакет. На этом путь пакета завершен. Как он будет обработан - определяет ПО. Если пакет типа DNSREG или DNSLOOKUP: Клиент-отправитель посылает пакет на роутер, который его зарегистрировал в сети. Роутер получает пакет и перенаправляет его на родительский узел. Так повторяется, пока пакет не достигнет корня. Корень получает пакет, обрабатывет его и посылает ответ в виде DNSANSWER пакета. Если пакет типа FINDPARENT: (эти действия происходят при вып. кмд qclient find. При исп. другого ПО алгоритм обработки пакетов на стороне клиента может отличаться.) Клиент-отправитель посылает пакет методом broadcast. В поле данные указано "find". Любой роутер, получивший это отзывается сообщением (не пакетом) "FINDROUTER:ME". В т.ч. и корень. Клиент получает самый первый пакет и отсылает обратно уже методом send пакет FINDPARENT. В поле данные уже указан MAC роутера, на котором клиент желает зарегистрироваться. Собственно на этот же MAC и отсылается пакет. Роутер, получивший пакет, сравнивает свой MAC с указанным, и если они совпадают, то выдает клиенту IP и отсылает клиенту сообщение (не пакет) с его IP. Клиент сохраняет все в qclient.conf в формате MACродителя;свойIP. Железо и ось: Требования по железу: Обязательная сетевая карта. Минимум 25КБ свободного дискового пространства. Видеокарта 1+ ур. Рекоменд. дисплей. Процессор мин 1+, рекоменд 2+. ОЗУ не тестил. На тестовых компах стояло 2*2уровень На всех тестовых компах стояла ОпенОСЬ из коробки без модификаций. Как этим безобразием пользоваться: Создаем корневой сервер: Качаем на него root.lua и ttf.lua в папку /home/. Создаем папку /home/QuarksRouter/. Запускаем root.lua Создаем роутеры: Качаем unit.lua и ttf.lua в папку /home/. Создаем папку /home/QuarksRouter/. Подключаем и запускаем роутеры: Качаем qclient.lua в папку /home/. Пишем qclient find. После запускаем unit.lua Подключаем клиентов: Качаем qclient.lua в папку /home/. Пишем qclient find. Настраиваем веб-сервер: Качаем server.lua, желательно в папку /home/QServer/. Там же создаем папку /home/QServer/mctpdocs/, в нее будем пихать странички. ОБРАТИТЕ ВНИМАНИЕ! Страницы без расширений. Домашняя - index. Делаем странички: Пихаем файлы без расширений в папку /home/QServer/mctpdocs/. В них пишем любой текст. Поддерживается цветовое форматирование как в обычном майне, с помощью &. Также можно менять фон. Для этого пользуемся теми же колоркодами, только с префиксом не &, а ^. Запускаем сервер server.lua Ставим браузер на клиента: Качаем web.lua. Пишем web <url>/<page> (web test.low/test) для доступа. Регистрируем домен: На веб-сервере пишем qclient -p -l --r="0.0" --d="DNSREG;тутжелаемыйдомен". Собственно все. Гайд по qclient: -p - обязательно писать -l - слушать входящий пакет --r="ip.получателя" --d="типпакета;данные" Гайд по пакетам: Формат пакета: IPотправителя;IPполучателя;тип;данные Возможные типы: DNSREG - регистрация домена. В поле ДАННЫЕ пишем желаемый домен DNSLOOKUP - поиск ip по домену. В поле ДАННЫЕ пишем желаемый домен. DATA - пакет с данными. Типы, которые юзать нежелательно: DNSANSWER - ответ корневого сервера. В поле ДАННЫЕ указано QDNS:ответ. FINDPARENT - единственный broadcast-пакет. Регистрация в сети. Ссылки: root.lua https://pastebin.com/BDBsU4qm unit.lua https://pastebin.com/drZQ4MD0 qclient.lua https://pastebin.com/wMZqWwwL ttf.lua https://pastebin.com/rhbG8CW8 server.lua https://pastebin.com/mjzSm4Hi web.lua https://pastebin.com/xNYssMWc P.s. это мой первый проект на луа.
  10. 3 балла
    Мы тут все слегка изменяем код Zer0Galaxy. Это фрагмент варианта ECS. Ему, похоже, было лень менять название на другое. И я тоже не стал переделывать. Название вводит в заблуждение, но логика кода верная. computer.uptime() возвращает округлённое до целых тиков время работы компьютера с момента его включения. os.clock() возвращает время, в течение которого компьютер был занят вычислениями, не округляя его до тиков. Конкретно в этом случае для измерения уместнее использовать именно os.clock.
  11. 3 балла
    Сидел читал форум, наткнулся на тему "Управление роботом с планшета" и сразу понял что моего ума хватит на создание программы которая позволит управлять роботом с НАСТОЯЩЕГО ТЕЛЕФОНА на системе android. И так, представляю вам - RRCM - Robot Remote Controll Mobile Что вам понадибится? 1. Телефон на android 2. Робот с минимальными компонентами и open os 3. Интернет карта на роботе Установка: 1. На робота ставим программу RRCM (pastebin get y2Twekz8 RRCM) 2. Ставим серверный скрипт на сервер/свой пк(если порт 5000 открыт): -- 1. Ставим python -- 2. После установки python3 вводим в терминал/cmd команды: "pip install flusk" "pip install flusk-restful", также если в четвёртом шаге у вас возникнет ошибка, пробуйте "pip3 вместо "pip" -- 3. Скачиваем скрипт - *тык* -- 4. Запускайте скрипт(windows: двойной клик по скрипту, linux: "python3 название_скрипта" 3. Ставим приложение на android - *тык* 4. Запускаем приложение, вводим только домен/ip:port нажимаем connect - если появляются кнопки управления - работает, если приложение виснет - какая-та проблема(скорее всего приложение не видит сервер 5. В скрипте RRCM на роботе изменяем локальный ip:port на ваш домен/ip:port 6. Запускаем RRCM на роботе. 7. Всё должно работать. Если у многих будут проблемы, запишу видео. В будущем планирую сделать скрипт на EFI что-бы не тратится на диск. Не удивляйтесь малому функционалу, проект был заброшен 2 раза, скоро сделаю обнову. (возможно) UPD: Забыл сказать! Для остановки скрипта надо перезагружать робота, но в скором времени сделаю кнопку в приложении для остановки скрипта Если будут ошибки - пишите, разберусь. UPD2: Если вы боитесь за безопасность устройства то вот вам исходник приложения - *тык* Приложение билдить на андроид в unity
  12. 3 балла
    В общем случае 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 позволяют упростить преобразования хэшей. На каждую операцию требуется один тик времени. И если прочитать содержимое МЭ-сети можно за одну операцию, то на обработку каждого слота сундука требуются две операции. Это может представлять проблему для сундуков со свободным доступом для игроков, но информацию о содержимом сундуков с исключительно программным доступом можно кешировать, чтобы избегать повторных вычислений. В конкретно этом случае также возможны хитрости. Необходимость частично игнорировать информацию о предмете делает невозможным прямое использование хешей. Но есть возможность заранее составить таблицы подходящих хешей с учётом вариаций показателей, которые требуется игнорировать. И даже если предварительное формирование и хранение таких таблиц представляет трудность, варианты оптимизации всё равно остаются. Например, можно хранить таблицы хешей только для пчёл, хранящихся в общей МЭ-сети, а для работы с пасеками применять отдельную МЭ-сеть, которая позволит анализировать всех вновь поступивших пчёл и хранить только актуальные хеши.
  13. 2 балла
    Отключаешь обои - и вуаля, хватает 2 планок оперативы за глаза, только если не запускать какое-нибудь 3D. Чистая оська в минимальной конфигурации требует ~600 кбайт доступной памяти, и я не сказал бы, что это прям лютые и неадекватные затраты: Такова цена граф. интерфейса в изначально консольной среде: тут уже хз, как извернуться, чтобы "скукожить" граф. буфер, жрущий минимум 400 кбайт, словно избалованный толстый кис. Остальные 200 кбайт объедков достаются юишным объектам, либам и буферам I/O. В целом опенкомпы по концепции не предназначены для подобных юишных извратов, поэтому смиренно жрем, чо дали
  14. 2 балла
    Если провести аналогию с реальностью, то дети в песочнице строили домики и лепили куличики. Один из них построил домик. Спрашивает других: можно ли сделать лучше. Другие оценивают. Кто-то спрашивает: а это зачем, оно же тут лишнее. Другой говорит, нет, не лишнее, и наоборот, так даже лучше. Другие тоже заинтересовались. Обсудили, нашли лучший вариант, какой смогли, и довольные разошлись по домам. Через два дня домик смыло дождём. Но дети с радостью вспоминали опыт коллективного творчества: они обязательно применят его в своих взрослых проектах. И только вечно недовольная старуха Шапокляк злобно шептала: всё тлен, всё тлен...
  15. 2 балла
    Впринципе можна менять конденсаторы через метод из openPeripheral.swapStacks. Просто нужно будет иметь в реакторе 1 пустую клетку. Всегда туда ложить целый конденсатор и потом менять его с поломаным. В этом случае реактор никогда не останется без конденсатора и можна будет заменять их не офая реактор. Второй способ вынимать стержни урана (моха) которые охлаждает данный конденсатор. В этом случае отключение реактора будет точечное и не сильно будет влиять на общую прыбыль.
  16. 2 балла
    История этой находки следующая. Пытаясь прояснить для себя нюансы механики реактора, я многократно перекладывал компоненты в реакторе и каждый раз заново включал и выключал реактор. В конце концов меня этот процесс утомил, и я попытался его упростить. Для этого я проверил возможность перемещения теплоотводов без останова реактора. Новый подход не только ускорил мои исследования, но и позволил обнаружить большую роль именно моментов извлечения и помещения компонентов в реактор. Так родилась идея микроконтроля ядерных реакторов. Практически все первые проверки той или иной идеи микроконтроля я выполняю вручную. Благо, для этого не требуется высокая скорость. Главное, попадать в такт процессам реактора. Да и это не всегда требуется. Кстати, по-русски правильно говорить именно такт, а не тик. Но айтишники зачастую впервые узнают это слово либо из англоязычных источников, либо от других айтиншиков, которые уже используют кальку с английского. Но старые электронщики, учившиеся по советским учебникам, используют термины такт и тактовый сигнал.
  17. 2 балла
    Реактор производит вычисления с компонентами один раз в секунду. Это событие можно назвать реакторным тиком. Можешь предложить лучший термин. Далее каждый майнкрафтовский тик (или просто тик) реактор генерирует некоторое количество энергии, вычисленное в момент последнего реакторного тика. В это время реактор продолжает работу независимо от наличия красного сигнала. Наличие или состояние компонентов реактора не играет никакой роли до следующего реакторного тика. Эти утверждения основаны на экспериментальных данных.
  18. 2 балла
    Мы ж программисты. Давай рассуждать логически. Да, додумал. Благо, вариантов не так много. Например, ты согласен с источником, и в случае его ошибочности заблуждаешься вместе с ним. Либо, отдавая себе отчёт в некорректности утверждения, намеренно вводишь читателей в заблуждение. Я предпочёл первый вариант. Додумал. Какие ещё существуют причины для вброса ложного утверждения? Смотрим выше и видим конкретные места в исходниках (с кусками ассемблерного кода и описанием причин): Выше есть и результаты замера пар int/float и int/int: В сухом остатке в твоём посте новой информацией оказались лишь результаты замера для пары float/float. Да и то, для операции обычного деления, а не целочисленного. А это разные операции: в случае обычного деления не требуется округление результата. Начинался же пост претенциозной фразой: Мораль: обесценивая сообщения предыдущих участников и претендуя на новизну, будь готов к тому, что любой высказанный тобой тезис также будет подвергнут оценке и, возможно обесценен. Полагаю, вопрос ценности и новизны исчерпан. Возвращаемся к исходному вопросу. Что именно ты предлагаешь? Как эту тему назвать? О чём она? Об оптимальном способе округления? Об оптимизации кода? О целочисленном делении? Какие посты предлагаешь перенести из этой темы в новую? Или ничего переносить не надо, а просто процитировать в новой теме? И о объединении каких материалов идёт речь? Что, с чем и как предлагаешь объединять? И как предлагаешь систематизировать наработанный материал, учитывая, что на результат измерений влияет не только оборудование, но и другое ПО, разделяющие общие с Lua ресурсы? Была когда-то тема с похожей идеей. Но там тоже всё сложно.
  19. 2 балла
    Вопрос обсуждался здесь: https://github.com/IgorTimofeev/MineOS/issues/356 Если кратко - документации нет, и знания придется добывать самостоятельно
  20. 2 балла
    Я несколько лет пользовался другим объяснением, но с учётом новой информации его, возможно, придётся пересмотреть. А объяснение было таким. На обычных операциях (если это не обработка длинных строк или преобразование больших таблиц) наибольший вклад в затраты времени даёт интерпретатор Lua. Вклад же полезной нагрузки минимален. Поэтому простая функция, написанная на Lua, будет исполняться дольше функции из стандартных библиотек. И мой опыт всегда подтверждал эту гипотезу. Ситуация может резко измениться, если отказаться от оборачивания кода в функцию. Например, вынеся код return (num+0.5)//1 из функции можно получить примерно 5-кратное ускорение выполнения этого участка кода. И это тоже объяснимо. Обработка вызова функции, наверное, во всех языках программирования является затратной в сравнении с арифметическими операциями. Кстати, @OpenReactor, обрати на это внимание. Наиболее быстрый способ округления на Lua не должен содержать вызова какой-либо функции.
  21. 2 балла
    Чекнул дополнительно пару известных вариантов округления. Топикстартеру респект за наиболее производительное решение: 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
  22. 2 балла
    Чуть лучше или по крайней мере не хуже должен быть вариант с использованием local floor=math.floor. Вызов же math.floor имеет двойную цену: за обращение к полю таблицы (глобальной переменной) и за, собственно, вызов функции. Что и видно по результатам теста. Локальный же вызов floor() работает шустро. А учитывая, что вариант с использованием floor() выглядит наиболее очевидно, имеет смысл предпочесть именно его.
  23. 2 балла
    @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()
  24. 2 балла
    Это да, но в основном я это придумал для что-бы троллить друзей/управлять роботом сидя на диване с телефоном, а не сидя на стуле и с мышкой.
  25. 2 балла
    Локальный) И только для теста. Это просто бессмысленно)
  26. 2 балла
    На каком сервере уже разрешили майнить?
  27. 2 балла
    1. Исправлю 2. Исправлю 3. Мы майним Duino-Coin (0.00106335$ прайс) примерно в день будет 3 -5 шт.
  28. 2 балла
    1) Другого способа сравнения двух таблиц, кроме как поэлементного, не существует. Ты не можешь использовать операторы ">" и "<" для таблиц. Можешь, правда, сравнивать на "равно-не равно", но сравнение всегда вернет falsh, если это разные таблицы, даже если они содержат одинаковые элементы. Другими словами, сравниваются не таблицы, а их адреса. Так что, смирись и брутфорси.
  29. 2 балла
    Кому все еще нужно, в местном магазине теперь есть приложение OpenOS Имеется интеграция с майносью, а именно: Отображение os.getenv('_') в титлбаре Настоящий биос доступен из опеноси непосредственно computer.addUser/computer.removeUser/computer.uptime работают с настоящим компьютером Цветовая схема Настоящий диск смонтирован по пути /mnt/mineos
  30. 1 балл
    Короче решил написать майнер для OC. За основу взял Duino-Coin : https://github.com/revoxhere/duino-coin Вот сам майнер: https://github.com/ReactorNefg/OpenComputer-Miner-Duino Програма полу рабочая (в любой момент может крашнуть) Писал в рофл. Готов выслушать критику по коду и тд.
  31. 1 балл
    У меня кстати была идейка набросать IDE для Майноси, дабы было проще делать графические проги под нее. НО тема эта достаточно сложная, так что... даже не знаю дойдут ли руки)0)0))).
  32. 1 балл
    Я о том же, зато оптимизировали. Если представить себя мыжпрограммистами и провести аналогию с реальностью, то команда просто так потратила время на преждевременную оптимизацию. Обязательно к прочтению
  33. 1 балл
    Одного хватит в любой схеме. Пофиг что он используется на 1/1000 за ту секунду что будет около 1 стержня
  34. 1 балл
    Познавательно выходит. Забыл про этот кусок кода: if (this.updateTicker++ % this.getTickRate() != 0) { return; } Таки да. Интересный момент, всякий раз updateTimer инициализируется не нулем, а псевдослучайным числом в диапазоне от 0 до 20. Из этого следует что первый реакторный тик случайно происходит.
  35. 1 балл
    Скорее всего половина, а то и больше ошибок пропадут как только там будет стоять } в конце
  36. 1 балл
    Всё что могу сказать, так это что тебе нужно поставить в конце } так как ты не закрыл class
  37. 1 балл
    Вы запускаете один и тот же код? Я вижу, что у @Zer0Galaxy используется local uptime=require("computer").uptime, наверное @ECS скопировал его. А @eu_tomat использует local uptime=os.clock В чем их различие, кстати?
  38. 1 балл
    Нет, офк. Я ж скинул аналогичный результат на чистом консольном луа той же версии, так чего на разность модов-то грешить? Загвоздка явно в поведении железяк. Но боюсь, я абсолютно некомпетентен в этом вопросе, чтобы сгенерировать какие-либо выводы. Цпуинфа: 8 model name : Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
  39. 1 балл
    Согласен, это так. Но... только в рамках бенчмарка синтаксически различных участков кода на одной машине. Тут, вне сомнений, Lua VM царь и бог, и на результат скорее повлияют локальные особенности трансляции в байт-код, нежели пара лишних операций в исходнике А как быть в нашем случае, когда эквивалентный код под одной VM на различном железе выдает различную производительность?
  40. 1 балл
    Железо скорее. Луа-консоль запускал на рабочей вдске, сервак кубача поднимаю там же, т.к. сингловый клиент на дешманском ноуте умирает с TLWY даже на 1млн итераций, не говоря уже о 20 млн. С точки зрения дилетанта могу предположить, что наибольшее влияние на однопоточные вычисления оказывает набор инструкций ЦП, объем кеша и частота. Возможно, надо байт-код для каждого метода и каждой машины чекать, чтобы сказать наверняка (он вообще может отличаться для одинаковых версий луа?)
  41. 1 балл
    Интервал зависит от кол-ва итераций, а оно такое же, как в примере 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 И на опенкомпах: Один фиг победа за первым методом
  42. 1 балл
    Что-то у тебя интервал времени получился крошечный. Там погрешность получается большая. Возьмём интервал побольше. Код: Результат: Итог: лучшее время стабильно показывает local floor=math.floor Версия мода OpenComputers-MC1.7.10-1.7.5.1290-universal.jar
  43. 1 балл
    На практике OpenComputers способен выполнять довольно тяжёлые алгоритмы. Вылеты по причине длительной неуступки времени можно сделать очень редкими, а к самому компьютеру можно прикрутить подобие сторожевого таймера. Другое дело, что не существует универсального способа адаптировать произвольный алгоритм. Но в каждом конкретном случае можно найти хорошее решение, максимально использующее вычислительные возможности игрового сервера. Конкретно этой программой убить трудно. Но никто не мешает доработать её. Зачем ограничивать себя в майнинге?
  44. 1 балл
    асуждай дальше, а я продолжу возрождать сервер
  45. 1 балл
    10 АФСУшек со всех сторон подключённых к компу, хехе.
  46. 1 балл
    Не убьешь. Тут или краш програмы или компьютер выключится.
  47. 1 балл
    Я писал что бы узнать можно ли вообще такое реализовать. Чистый интерес.
  48. 1 балл
    Критиковать буду саму идею. Я могу понять попытки реализовать шифрование RSA на OpenComputers. Та задача тоже сильно нагружает вычислениями игровой сервер, но она хотя бы решает какие-то игровые задачи. Да и нагрузка на сервер не постоянная. Но какие есть причины для майнинга в OpenComputers?
  49. 1 балл
    Оптимизированы наиболее часто используемые методы библиотеки Screen, работающей с экранными буферами: если ранее для каждого рисуемого пикселя выполнялась проверка вхождение в регион отрисовки, то теперь все прямоугольные команды автоматически рекомпонуются, чтобы уместиться в этот регион. Странно, что это не было сделано изначально, но тем не менее скорость перемещения сложных оконных приложений с кучей мелких прямоугольников и картинок (типа местного Finder) ощутимо подросла Ну и забавы ради добавлен метод screen.blur(), применяющий эффект размытия к указанному региону и, опционально, накладывающий цветовой фильтр, а также виджет GUI.blurredPanel, чтобы создавать окна с заливкой в стиле AcrylicBrush из UWP Вообще изначально было реализовано полноценное размытие по Гауссу, но, учитывая мизерные размеры экранов, оказалось, что простого box blur будет более чем достаточно, и визуальной разницы нет. Вопрос прожорливости остается за кадром:
  50. 1 балл
    @BrightYC Фига скилловая софтина, уважаю
Эта таблица лидеров рассчитана в Москва/GMT+03:00
×
×
  • Создать...