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


Фотография

Разработка новой операционной системы. WinOS.

WinOS

  • Закрытая тема Тема закрыта
Сообщений в теме: 142

#1 Оффлайн   RccHD

RccHD
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 01 Сентябрь 2017 - 03:36

Чтобы бы там не говорил Fingercomp по поводу написания своих ОС, я таки пишу свою ОС :)

Планы такие:
1) разработать операционку с многозадачностью на основе OpenOS с полной совместимостью
2) запуск нескольких программ одновременно(в том числе графических)
3) возможность разбивки экрана на прямоугольные зоны для предоставления программам доступа к этим зонам(программы не будут рисовать графику вне предоставленной зоны)
4) буферизация графики с ускорением отрисовки (как у ECS). Я не стал брать либу от ECS потому что она использует другие либы того же автора и потому что реализована эта библиотека довольно коряво в плане стиля написания кода(мое личное мнение). В общем, я переписал либу ECS с нуля под нужды операционки, кол-во кода сократилось в 5 раз. Все программы написанные на моей OC будут иметь "графическое ускорение" по умолчанию.

Пункты 2 и 3 фактически уже закончены(по-крайней мере мне так кажется)
Буферизация(пункт 4) работает прекрасно, отрисовка графики в некоторых случаях может быть в 3-15 раз быстрее(относительно gpu api)

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС
В частности, хочу реализовать ОЧЕНЬ сильно урезанную реализацию моего любимого оконного менеджера xmonad


Важно: все OpenOS-программы можно будет запустить на моей OC


Сообщение отредактировал Alex: 16 Апрель 2018 - 13:54


#2 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 01 Сентябрь 2017 - 04:03

Надеюсь, что мне не надоест разрабатывать эту OC, иначе будет еще одна R.I.P операционка

Планирую закончить разработку максимум через месяц. По истечении этого времени, я либо выложу готовый результат/альфа-версию, либо забью на разработку

 
P.S. я школьнег и мне кроме написания OC еще учиться надо :)


Сообщение отредактировал RccHD: 01 Сентябрь 2017 - 04:04


#3 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 910
  • Уровень сигнала: 6,17%
  • В игре: 49 час. 56 мин.

Награды

                          

Отправлено 01 Сентябрь 2017 - 08:43

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС

Важно: все OpenOS-программы можно будет запустить на моей OC

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

Основные проблемы:
* Кооперативная многозадачность потребует обязательной доработки запускаемых программ. А в случае подвисания одной из программ подвиснет вся система.
* Для совместного использования оборудования запускаемые программы тоже потребуют доработки, а в отдельных случаях такая доработка невозможна.

#4 Оффлайн   Zer0Galaxy

Zer0Galaxy
  • Гуру
  • Сообщений: 1 229
  • Уровень сигнала: 0%
  • В игре: 0 час. 0 мин.

Награды

   5                              

Отправлено 01 Сентябрь 2017 - 09:44

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

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

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

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.


  • Alex это нравится

#5 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 740
  • Уровень сигнала: 0,27%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 01 Сентябрь 2017 - 10:42

Ну, если пост Фингера прочитан, все риски взвешены, план битвы составлен и мосты сожжены - желаю удачи =)

Посмотрим, что получится.


  • Alex и FelixBanan это нравится

#6 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 01 Сентябрь 2017 - 16:23

блиотека довольно коряво в плане стиля написания кода(мое личное мнение)

 

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно  :wacko:

 

А вообще интересно, каким образом ты уменьшил размер сырцов в 5 раз - уж не путем ли удаления половины "не нужных" для твоей ОС элементов? Го инфу, любопытно стало.


Сообщение отредактировал ECS: 01 Сентябрь 2017 - 16:46

  • Alex, eu_tomat, qwertyMAN и еще 1 это нравится

#7 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 910
  • Уровень сигнала: 6,17%
  • В игре: 49 час. 56 мин.

Награды

                          

Отправлено 01 Сентябрь 2017 - 20:49

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

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

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.

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

Поэтому данное утверждение не соответствует действительности:

Важно: все OpenOS-программы можно будет запустить на моей OC

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

#8 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 01 Сентябрь 2017 - 21:28

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал :)
Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки



#9 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 01 Сентябрь 2017 - 21:40

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно  :wacko:
 
А вообще интересно, каким образом ты уменьшил размер сырцов в 5 раз - уж не путем ли удаления половины "не нужных" для твоей ОС элементов? Го инфу, любопытно стало.

По поводу моей субъективной оценки твоего кода:

Я вот такие вещи вообще видеть не могу, это вообще не по-человечески так писать:

changes[buffer.currentFrame[index]] = changes[buffer.currentFrame[index]] or {}
changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] = changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] or {}
				
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], x)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], y)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], table.concat(sameCharArray))
				

 
Когда я вижу подобный код, я начинаю думать:
1) У автора этого кода паническая боязнь переменных(или он проспорил кому-то)
2) Автор думает, что любая созданная переменная занимает гигабайты в оперативке, поэтому их не использует
3) У автора Крутой Продвинутый Текстовый Редактор ™, который позволяет написать "buffer.currentFrame[index]" сразу в трех местах
 
 
Так как я не фанат различных навороченных редакторов текстовых редакторов и не боюсь переменных и знака "=", я бы написал этот код вот так:
 

local el0 = buffer.currentFrame[index],
      el1 = buffer.currentFrame[indexPlus1]

changes[el0] = changes[el0] or {}
changes[el0][el1] = changes[el0][el1] or {}
				
table.insert(changes[el0][el1], x)
table.insert(changes[el0][el1], y)
table.insert(changes[el0][el1], table.concat(sameCharArray))
				

По поводу нагрузки на ЦПУ:
писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия:
1) получает значение переменной "buffer"
2) получает поле "currentFrame" объекта "buffer"
3) получает поле "index" объекта "buffer.currentFrame"

А если хранить это значение в переменной, то будет одно действие:
1) получает значение переменной "el0"


Сообщение отредактировал RccHD: 01 Сентябрь 2017 - 21:50


#10 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 01 Сентябрь 2017 - 22:46

По поводу нагрузки на ЦПУ: писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия: 1) получает значение переменной "buffer" 2) получает поле "currentFrame" объекта "buffer" 3) получает поле "index" объекта "buffer.currentFrame" А если хранить это значение в переменной, то будет одно действие: 1) получает значение переменной "el0

 

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же



#11 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 01 Сентябрь 2017 - 23:10

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

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

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

 

function buffer:readLine(chop, timeout)
  self.timeout = timeout or (computer.uptime() + self.readTimeout)
  local start = 1
  while true do
    local buf = self.bufferRead
    local i = buf:find("[\r\n]", start)
    local c = i and buf:sub(i,i)
    local is_cr = c == "\r"
    if i and (not is_cr or i < #buf) then
      local n = buf:sub(i+1,i+1)
      if is_cr and n == "\n" then
        c = c .. n
      end
      local result = buf:sub(1, i - 1) .. (chop and "" or c)
      self.bufferRead = buf:sub(i + #c)
      return result
    else
      start = #self.bufferRead - (is_cr and 1 or 0)
      local result, reason = readChunk(self)
      if not result then
        if reason then
          return nil, reason
        else -- eof
          result = #self.bufferRead > 0 and self.bufferRead or nil
          self.bufferRead = ""
          return result
        end
      end
    end
  end
end


#12 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 01 Сентябрь 2017 - 23:39

Всегда считал, что переменные(они же указатели на объекты) не могут занимать много памяти... Хотя бы потому что исходники библиотек OpenOS прямо-таки напичканы переменными. Может дело все-таки не в таких мелочных деталях как переменные, а в самой реализации?

 

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

 

А насчет исходников OpenOS - с каких это пор они стали эталоном грамотного и эффективного кода? Лично я вообще не понимаю, что в ней может кушать столько памяти (пс-с-ст, более 200 КБайт по дефолту, жуть какая). Хотя приведенный тобой пример вносит определенную ясность хд



#13 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 01:10

Реализована возможность запуска нескольких программ одновременно!!!
В этом примере каждая программа запущена в отдельном окне 10х10 символов.
agigi.gif


Это 2 одинаковых программы. Эта программа будучи запущенной в "одиночном" режиме занимает все окно:
agigi.png


Примечание: в скиншоты попал мой терминал(фиолетовая область). Я криворукий и мне лень переделывать

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


Сообщение отредактировал RccHD: 02 Сентябрь 2017 - 01:12

  • Totoro и eu_tomat это нравится

#14 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 01:21

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


Сообщение отредактировал RccHD: 02 Сентябрь 2017 - 01:21


#15 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 01:25

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


Приведи пример такой коллизии. Я пока не придумал ни одного

Сообщение отредактировал RccHD: 02 Сентябрь 2017 - 01:26


#16 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 07:21

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:

vokoscreen-2017-09-02_06-15-30.gif

Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая :)

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок


Сообщение отредактировал RccHD: 02 Сентябрь 2017 - 07:25

  • Totoro, eu_tomat и qwertyMAN это нравится

#17 Оффлайн   Seryoga

Seryoga
  • Пользователи
  • Сообщений: 108
  • Уровень сигнала: 0,32%
  • В игре: 2 час. 33 мин.
  • ГородSaint-Petersburg

Награды

        

Отправлено 02 Сентябрь 2017 - 14:45

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

RccHD немного не убедительно написал, я попробую его поправить.

  1. выполнение buffer.currentFrame[index]
     -- обращение к переменной buffer
     -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.
         - расчёт hash("currentFrame")
         - определение смещения по хешу
         - выборка списка (может дерева) элементов по смещению из массива
         - разрешение коллизий (дорого)
         - ...
     -- выборка из полученной таблицы элемента с индексом, что приводит к 'см выше'
     -- если вы 'lucky boss' то разрешение кеш промахов (это очень затратная операция)
  2.  выборка значения переменной
     -- если интерпретатор lua переменную положил на стек, то это бесплатная операция, иначе:
         - чтение данных из ОЗУ (если есть кеш, то это тоже почти бесплатная op)
         - в худшем случае разрешение 1 кеш промаха

Мне что-то подсказывает, что выполнять операцию (1) много раз не стоит.
Если у вас есть проблемы со своевременной очисткой памяти, то можно вручную вызвать сборку мусора.
Но таких проблем быть не должно.
Мне кажется, что кто-то просто забывает писать ключевое слово local.
И переменная весит ровно 64 бита.
Если у вас локальная переменная долго живёт а объект который по ней находится больше не будет использоваться,

то можно написать var = nil. И gc, по возможности, удалит объект, на который ссылалась переменная.
А сама ссылка удалится как закончится её область видимости (без gc).


Сообщение отредактировал Seryoga: 02 Сентябрь 2017 - 14:46


#18 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 02 Сентябрь 2017 - 16:09

RccHD немного не убедительно написал, я попробую его поправить.

  1. выполнение buffer.currentFrame[index]
     -- обращение к переменной buffer
     -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.
         - расчёт hash("currentFrame")
         - определение смещения по хешу
         - выборка списка (может дерева) элементов по смещению из массива
         - разрешение коллизий (дорого)
         - ...

 

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

 

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

 

Ручной вызов GC в OpenComputers невозможен, эта фича отключена авторами мода по понятным причинам. Если бы я мог активировать сборку мусора - то неужели стал бы писать сюда о проблемах с локальными переменными?

 

И переменная весит ровно 64 бита.

 

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

 

Мне кажется, что кто-то просто забывает писать ключевое слово local.

 

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


  • Alex и eu_tomat это нравится

#19 Оффлайн   Seryoga

Seryoga
  • Пользователи
  • Сообщений: 108
  • Уровень сигнала: 0,32%
  • В игре: 2 час. 33 мин.
  • ГородSaint-Petersburg

Награды

        

Отправлено 02 Сентябрь 2017 - 16:24

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

Переменная весит сколько весит ссылка в ОS.
А вот объект на который ссылается переменная весит в зависимости от типа.
Как ты понимаешь ссылка это не объект на стеке и она ссылается на объект в твоей мапе который ты и так хранишь.

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



#20 Оффлайн   Seryoga

Seryoga
  • Пользователи
  • Сообщений: 108
  • Уровень сигнала: 0,32%
  • В игре: 2 час. 33 мин.
  • ГородSaint-Petersburg

Награды

        

Отправлено 02 Сентябрь 2017 - 16:31

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

Даже если это так, то ты наверное понимаешь, что это всё равно не сравнимо с чтением объекта по ссылке.



#21 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 02 Сентябрь 2017 - 17:45

Переменная весит сколько весит ссылка в ОS.
А вот объект на который ссылается переменная весит в зависимости от типа.
Как ты понимаешь ссылка это не объект на стеке и она ссылается на объект в твоей мапе который ты и так хранишь.
nil помогает в том случае если у тебя переменная находится в скопе из которого ты часами не выходишь.

 
Для справки: каждая переменная-указатель на таблицу или функцию в Lua весит в равной мере 9 байт.
 
А теперь немного сухих расчетов: представим простейшую трехмерную сцену из восьми кубиков. Каждый куб имеет 8 вершин, каждая вершина - это трехмерная таблица-вектор с числовой индексацией, в сумме кушающая 40 (table) + 8 (double) * 3 = 64 байта. Все вершины заносятся в массив вершин сцены для минимизации расхода памяти. Также каждый куб имеет таблицу-линковщик, содержащую индексы вершин, образующие треугольники для отрисовки куба в количестве 12 штук. Каждый треугольник с ссылками на три вершины - это такой же трехмерный вектор, кушающий все так же 64 байта. Итого получаем 64 * 8 = 512 байт на вершины и 64 * 12 = 768 байт на линковку вершин, итого 1280 байт на куб. Сколько у нас там их? Восемь? Итого трехмерная сцена выжрет 1280 * 8 = 10240 байт = 10 КБайт. Это тот минимум, который необходим для старта отрисовки графики, материалы и текстуры для простоты рассматривать не будем. Если же использовать локальные переменные-сокращалки, то расход памяти взлетит по экспоненте.

 

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

for triangleIndex = 1, #OCGL.triangles do
	vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][1]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][1]][2], OCGL.vertices[OCGL.triangles[triangleIndex][1]][3]
	vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][2]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][2]][2], OCGL.vertices[OCGL.triangles[triangleIndex][2]][3]
	vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][3]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][3]][2], OCGL.vertices[OCGL.triangles[triangleIndex][3]][3]
	material = OCGL.triangles[triangleIndex][4]

...

Также привожу скриншот с результирующим FPS в 7 единиц и расходом оперативной памяти в 46% от максимального запаса (4 Мб)

 

IXkJ4qZ.png?1

 

 

А теперь намутим-ка локальных сокращений для минимизации нагрузки на ЦП:

local ti, ve1, ve2, ve3
for triangleIndex = 1, #OCGL.triangles do
	
	ti = OCGL.triangles[triangleIndex]
	ve1, ve2, ve3 = OCGL.vertices[ti[1]], OCGL.vertices[ti[2]], OCGL.vertices[ti[3]]

	vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + ve1[1], renderer.viewport.yCenter - ve1[2], ve1[3]
	vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + ve2[1], renderer.viewport.yCenter - ve2[2], ve2[3]
	vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + ve3[1], renderer.viewport.yCenter - ve3[2], ve3[3]
	material = OCGL.triangles[triangleIndex][4]

...

Результат плачевный. Не замечено ни прироста, ни убыли значений FPS, однако расход памяти возрос до 61%. Магия? Нет, особенности конкретного ЯП и его интеграции в виде мода.

 

tq3OUxU.png?1


  • Alex это нравится

#22 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 18:04

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

#23 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 910
  • Уровень сигнала: 6,17%
  • В игре: 49 час. 56 мин.

Награды

                          

Отправлено 02 Сентябрь 2017 - 18:23

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки

Словом «все», взятым в кавычки, я надеялся выразить свою иронию. Но твоя новая формулировка меня устраивает: большинство программ – это не все программы, тем более с таким выделением жирным шрифтом:

Важно: все OpenOS-программы можно будет запустить на моей OC


Многозадачность можно реализовать двумя путями:

1) Подменить load своей функцией, автоматически расставляющей по всему коду вызовы yielding. Недостатки этого способа в том, что он провоцирует повышенное потребление памяти и процессорного времени, и годится не для любого кода. Достоинство в том, что потенциально он может спасти систему от падения в TLWY из-за одного кривого приложения.

2) Подменить буквально все методы всех компонент, которые неявно выполняют уступку времени. Начать, конечно, следует с computer.pullsignal, но этого недостаточно. Например, есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периферии. Если ты готов подменить методы всех компонент, добавляя в каждый из них вызов yielding – пожимаю руку. Еще надо не забыть, что периферия может динамически подключаться и отключаться от компьютера, и таблицы методов нужно будет подменять на лету.

Предполагаю, что ты выбрал второй способ, удовлетворившись подменой pullsignal, да gpu
 

Приведи пример такой коллизии. Я пока не придумал ни одного

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

#24 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 02 Сентябрь 2017 - 19:12

Многозадачность можно реализовать двумя путями:

 

Есть третий принципиально отличающийся вариант: обработка нескольких приложений-окон в общем потоке-контейнере. Из плюсов тут стоит выделить максимальное быстродействие, т.к. выполнение скрипта не будет искусственно замедлено множественными yield() в подмененных функциях, а также простоту написания такого концепта. Из минусов - поддерживать многозадачность будет лишь то ПО, которое написано под данную ОС, все остальное будет работать в штатном режиме. А также имеет место быть стабильный краш главного потока при краше любого из приложений - проблема решается изоляцией пространства приложения от контейнера и кешированием его состояния.



#25 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 02 Сентябрь 2017 - 19:29

Есть третий принципиально отличающийся вариант: обработка нескольких приложений-окон в общем потоке-контейнере

Есть пример рабочей реализации? Чтобы две-три программы работали, рисовали графику. Я бы посмотрел исходники  :D  

#26 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 02 Сентябрь 2017 - 20:13

Есть пример рабочей реализации? Чтобы две-три программы работали, рисовали графику. Я бы посмотрел исходники

 

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

 

hTFGCqj.gif


Сообщение отредактировал ECS: 02 Сентябрь 2017 - 20:18

  • Alex, Krutoy, Totoro и еще 1 это нравится

#27 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 03 Сентябрь 2017 - 01:12

есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периф

Это что за программы? Есть пример? Я привык, что всегда нужно pullSignal писать в программе, чтобы она работала 

#28 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,52%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 03 Сентябрь 2017 - 01:59

Это что за программы? Есть пример? Я привык, что всегда нужно pullSignal писать в программе, чтобы она работала 

local redstone = require("component").redstone
while true do
  redstone.setOutput(1, math.random(15))
end 

Что примечательно, эту софтину возможно завершить только путем отсоединения редстоун-компонента. Как верно подметил eu_tomat, каждое обращение к нему ведет себя аналогично .pullSignal(), однако не вызывает его



#29 Оффлайн   qwertyMAN

qwertyMAN
  • Пользователи
  • Сообщений: 1 437
  • Уровень сигнала: 0,13%
  • В игре: 1 час. 3 мин.
  • ГородCity17

Награды

                             

Отправлено 03 Сентябрь 2017 - 11:24

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:

vokoscreen-2017-09-02_06-15-30.gif

Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая :)

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

Кто-то ещё помнит про мои змейки



#30 Оффлайн   RccHD

RccHD
  • Автор темы
  • Пользователи
  • Сообщений: 169
  • Уровень сигнала: 16,04%
  • В игре: 129 час. 42 мин.

Награды

           

Отправлено 03 Сентябрь 2017 - 14:06

Кто-то ещё помнит про мои змейки

Эти змейки почти идеально подходят для тестирования моего оконного менеджера.
Так как в них использованы самые разные функции (gpu, term, event)







Темы с аналогичным тегами WinOS

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных