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

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

Рекомендуемые сообщения

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

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

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

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


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

Изменено пользователем Alex

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

Основные проблемы:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

  • Нравится 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
блиотека довольно коряво в плане стиля написания кода(мое личное мнение)

 

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

 

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

Изменено пользователем ECS
  • Нравится 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал :)

Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно  :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
  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

  • В шоке 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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


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


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

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

Изменено пользователем RccHD
  • Нравится 3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Изменено пользователем RccHD
  • Нравится 4
  • Одобряю 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

  1. выполнение buffer.currentFrame[index]

     -- обращение к переменной buffer

     -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.

         - расчёт hash("currentFrame")

         - определение смещения по хешу

         - выборка списка (может дерева) элементов по смещению из массива

         - разрешение коллизий (дорого)

         - ...

 

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

 

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

 

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

 

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

 

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

 

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

 

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

  • Нравится 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Переменная весит сколько весит ссылка в ОS.

А вот объект на который ссылается переменная весит в зависимости от типа.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.

×
×
  • Создать...