OSDev

Здравствуйте.

Вот прожект, оно работает, но конечно же в ограниченном объёме. Хотелось бы услышать мнение русскоговорящих разработчиков. Западные товарищи уже опрошены, Java-сообщество - тоже.

Основной посыл - привлечь миллионы Java-разработчиков к раздумьям и созиданию в стане операционных систем.

Сразу отвечу на ряд стандартных вопросов - это действительно 100% Java, там нет ни строчки на другом языке (кроме комментариев). Способ реализации тривиальный - надо лишь сваять ассемблер под ваш целевой язык и компилятор из вашего языка в ваш ассемблер и можно писать ОС хоть на брэйн-факе.

Из потенциальных преимуществ выделю возможность запуска миллиардов строк кода на Java, чем не могут похвастаться другие любительские ОС, даже с учётом строк на С и С++. Ну и такая мелочь - любое новое железо НЕ ПОТРЕБУЕТ переписывания/перекомпилирования всего ПО под новую ось. И совсем уж смело - производительность обещается быть лучше сишной (то есть быстрее софта написаного на сях), а при условии создания спец.процессоров разрыв может быть сильно увеличен. Причина - у компилятора для С кипит мозг от попыток предсказать хитро-сочинённые операции с указателями и прочими небезопасными конструкциями, чего в Java просто нет.

В свете необходимости сбора мусора в Java (чего нет в C/C++), действительно весьма смелое утверждение.


О каких спец. процессорах идёт речь? Какие именно операции могут быть специфически поддержаны в процессоре для увеличения производительности Java-кода по сравнению с C? (речь конечно не идёт об аппаратной поддержке Java байт-кода, т.к. ничего особо специфического в таком коде нет).

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Дело в том, что необходимость освобождать память есть в любом языке/среде. И в любой среде исполнения на это тратится время. Но в С на это тратится ещё и время разработчика, как собственно на освобождение, так и на всевозможные баги с ним связанные. В результате в приличном по объёму проекте С-разработчик выдаёт заметно меньшую производительность. Но при этом он далеко не всегда выдаёт эффективный код, потому что размер проекта подталкивает к повышению скорости выдачи текстов. И вот здесь мы имеем возможность сравнить - Java-программист может не думать про кучу хитрых оптимизаций и писать в основном бизнес-логику, а С-программист вынужден возится с низкоуровневой оптимизацией (как минимум по части освобождения памяти) и при этом практически всегда получать результат хуже, чем даст качественный компилятор для Java. Здесь предвижу вопль возмущения - да как так, нас опускают, да ещё так низко !!! Ни кого я не опускаю, просто констатирую факт, который заключается в простом выводе - чем больше проект, тем меньше разработчики думают об оптимизации. То есть если задаться целью написать на С код эффективнее выдаваемого компилятором - наверное это возможно, но в реальности практически ни кто так не делает, во всяком случае при наличии задачи выдавать много текста.

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

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

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

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

Не кормите троллей - они толстеют.
Вообщем про скорость ОС вы не чего сказать не смогли. Что касается перевода в русло Java против Си++, то это очень толсто.
И сравнивать компилятор с человеком это не корректно. Ну и выводы у вас не верные так как события не зависимые.

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

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

В смысле вы отказываетесь аргументировать свои возражения ?
ОС - это среда обитания компилятора, да ещё и оптимизированная до уровня железа. В этом и состоит связь ОС со скоростью.
Скорее против С, ибо все линуксы с виндами именно сишные. Ну да не суть в конкретном языке. Суть в появлении возможности получить готовый меганабор Java-приложений на адаптированной под них платформе. То есть все рассуждения про оптимизацию здесь вполне уместны, а возможность для Java-разработчиков углубляться до уровня железа даёт дополнительный бонус. Ну и независимость байткода от железа даёт изящную возможность менять хардовую платформу быстро и дёшево.
Почему некорректно ? Человек может работать в режиме подвига сколько-нибудь длительное время ? А компилятор может. Тут речь об автоматах против людей. Автоматы в своей нише бесспорно победили и постоянно расширяют свою нишу. Вопрос только в обозначении ниши. Концентрация на бизнес-логике и есть ниша человека, а оптимизация на уровне регистров и выделения памяти - всё это ниша компиляторов (автоматов). И здесь начинает играть роль уровень абстракции, с которым работает тот или иной язык программирования. Кто-ж виноват, что на С принято писать на низком уровне абстракции ? Можно, особенно на С++, писать в высокоуровневом стиле, но тогда мы получим Java. Ну а раз ОС сделана на Java, то как же обойтись без преимуществ целевой среды при обсуждении этой ОС ?
Я конечно сорри, но парсер есть всего лишь преобразователь из одного представления в другое. Суть преобразованной информации при этом ни на грамм не изменяется. Поэтому лучше не стоит начинать ещё и разговор про парсеры. Давайте лучше поговорим про оптимизацию, когда компилятору нужно понять какие адреса памяти и каким образом используются. И вот здесь всяческие трюки с указателями ведут к быстрому росту сложности компилятора. В случае с Java этой сложности можно избежать.
В сети есть масса сравнений, в том числе показывающих превосходство обычной Java-машины над сишным кодом. Но подчеркну главный момент - если на сях писать так же как и на Java, то сишный компилятор тоже сможет находить те же способы оптимизации, что и Java-компилятор. А вот если писать с указателями, небезопасными преобразованиями типов и т.д. - вот тут сишный компилятор проиграет. Не потому, что он знает меньше алгоритмов, но потому, что программист закрыл для него возможность предсказать путь исполнения программы использованием указательной арифметики и (по сути) отказом от строгой типизации переменных (небезопасное приведение типов). Всё выше сказанное означает, что для сравнения производительности Java и С компиляторов нужно выбирать корректный пример, когда оба компилятора обрабатывают код для одной и той же достаточно большой системы, но написанной в двух вариантах (на двух языках). Такие примеры есть (типа тех же XML-парсеров), но вот серьёзные сравнения их возможностей нужно ещё поискать, в смысле так просто я их найти не смог. Хотя можно и самим попытаться что-то такое сделать, если вы не против.
Не совсем понял вашу мысль. Вы опять на троллизм намекаете ? Так а как же тогда показывать преимущества новой ОС ?

Вы забываете, что ручное освобождение памяти не затрачивает никаких лишних ресурсов свыше необходимого - ни памяти, ни времени. И это даже не главное, главное - 100% предсказуемость работы! В то же время, ни один автоматический сборщик не может даже приблизится по эффективности к ручному освобождению и требует периодической полной остановки полезной работы. Но я чувствую, что вы не владеете конкретными цифрами и объяснять разницу бессмысленно. Автоматический сбор мусора вполне допустим в приложениях, но использование его в ядре ОС весьма сомнительно. Как вы будете планировать время CPU? Как вы запустите выделение страницы памяти приложению, если не можете гарантировать, что в этот момент в самом ядре не запуститься сборщик и не затребует сотни новых страниц? Кто и как их будет выделять??


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


Такое впечатление, что вы слабо представляете себе цели и задачи ОС. Тот факт, что Андроид написан не на Джаве (и более того, опирается на ядро Линукс, написанное на ненавистном С), совершенно не мешает эффективно работать на нём джава-приложениям.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

А что такое "необходимое" ? Это изменение данных в некой системной структуре в режиме монопольного доступа к ней. То есть пока операция не завершена некая часть памяти недоступна для операций и потоки, выделяющие или освобождающие память в этом регионе просто ждут. Вот это и есть те потери, которые вы почему-то не считаете важными. Собственно именно эти же потери присутствуют и в случае ОС на Java.
Ручное освобождение требует периодической полной остановки работы на период этого самого освобождения. Правда в ручном режиме освобождение размазано по программе и потому не так заметно. В случае со сборщиком мусора работа выполняется просто немного большими порциями. А необходимость обходить граф объектов на рантайме высвобождает программистам кучу времени во время разработки. Или вы не делаете ошибок при работе с памятью ? И при этом ещё и выдаёте кода не меньше, чем Java-разработчик ?
Мне видится другое слово - неохота. Ну да это ваше право, конечно.
Реализовано при помощи таймера. И проблем не обнаружил.
Коллектором можно управлять. Удивлён, что такая мысль многим не приходит в голову (вы, к сожалению, не первый). Теперь давайте попробуем объяснить это чудо. Для начала можно вспомнить о концепции прерываний. Эти штуки встречаются в том числе в ОС, написанных на С, и их возникновение совершенно не мешает работе системы. То есть если наши читатели понимают принцип работы прерываний, они отлично поймут, почему же прерывания не заставляют систему падать, запускать сборщики мусора и т.д. Вот примерно так же всё происходит и при запросе на выделение памяти - просто предпринимается ряд мер для предотвращения печальных последствий. В описании архитектуры (по ссылке "description") приведены подробности по типам используемых коллекторов и их реализации, там всё довольно просто. Но самое главное - коллектор можно тривиально выключить, если нужно. Ещё используемый вариант - просто закэшировать необходимые объекты заранее и не использовать дополнительную память (и её выделение с освобождением) вообще. То есть это всё давно решённые многими способами проблемы.
То есть вы согласны, что эффективность Java не хуже ненавистного С ? Ну а на самом деле андроидная джава есть весьма убогая поделка. Оно работает, даже некоторые системные фичи из Java можно дёргать, но тем не менее постоянно упираешься в стену, которую сгородили архитекторы системы. Поэтому под Андроид весьма популярен NDK (native development kit).
В принципе, что бы сделать качественный и удовлетворяющий всех сравнительный тест, нужно начать с операционной системы на Java. Иначе сторонники С всегда будут возражать - Java использует сишные системные вызовы, так не честно ! Хотя бы с этой точки зрения я уже вижу пользу от 100% Java операционной системы

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


Ничего подобного. Кажется, вы не понимаете очевидной вещи:
Ручное освобождение - это ТОЛЬКО освобождение.
Автоматический сбор - это сначала ПОИСК свободных объектов, в процессе которого приложение работать не может, а только затем освобождение. Первая фаза занимает в сотни и тысячи раз больше времени, чем вторая. Я согласен, что в некоторых сборщиках две фазы объединены, но тем не менее, они обе присутствуют.


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


Я разве ЭТО сказал??? Я лишь сказал, что для обеспечения работы джавы не нужна ОС, написанная на джаве, т.к. задачи ОС совершенно другие.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ну вы ведь тоже (наверное) писали свою ОС ? И вы (наверное) реализовали там какое-то управление памятью ? И вы по прежнему утверждаете, что для вашей реализации необходим лишь один указатель и более ничего ? Надеюсь на ваше благоразумие.
Ну давайте рассмотрим типичную задачу с какой-нибудь обработкой данных. Только (естественно) не тривиальной 2*2. В типичной задаче у данных есть некая достаточно сложная структура, что подразумевает активную работу с элементами этой структуры. И эти элементы обычно организуются в виде классов (на Java или С++) или в виде структур на простых сях. И эти структуры нужно постоянно елозить туда-сюда передавая всяческим компонентам на обработку и получая от них результаты. При этом разработчик на Java просто не задумывается над потрохами всего этого процесса, но экономя личное время, просто передаёт объекты на вход неких обработчиков и не парится НИ О ЧЁМ. При этом масса таких объектов получается созданной во время обработки и большинство из них становятся ненужными после обработки. И эту массу совершенно нельзя назвать "несколькими неиспользуемыми", но следует называть "почти все созданные становятся неиспользуемыми". Вот поэтому-то нагрузка на систему при обходе графа объектов в памяти и не приводит к ужасной потере производительности, но вполне сравнима с потерями на ручную деаллокацию. Но с одним важным отличием от С - разработчик просто даже не вспоминает о такой проблеме, за него ВСЁ делает JVM. А разработчик на С вынужден терпеливо убирать за собой весь свой полёт фантазии, ну или как-то изворачиваться и пытаться хитрыми алгоритмами минимизировать необходимость создания новых объектов. И в процессе длительной разработки большого проекта ни кто не станет изобретать сложные велосипеды для минимизации использования памяти, все просто будут её использовать когда удобно, что означает постоянное наличие задачи по уничтожению нагенерированного мусора.
Очень даже "при чём". Либо вы не используете многопоточность, либо вы делаете доступ к управляющим памятью структурам монопольным. И все потоки ждут, пока структура снова станет доступной для монополизации.
Я выше показал самый что ни на есть стандартный пример работы, когда первая фаза может занимать даже меньше времени, чем вторая.
Эти утверждения связаны, вот в чём проблема. Одно без другого есть действительно подмена реальной ситуации некой сказочной. Поэтому мы должны рассматривать именно оба процесса - программист в длительном полёте предпочитает НЕ ДУМАТЬ над столь однообразными и давно надоевшими деталями. Java думает за разработчика, С же заставляет разработчика отвлекаться, но при этом разработчику всё равно очень быстро надоедает каждый раз думать об этих надоевших деталях. Поэтому он вырабатывает для себя какой-то простой шаблон действий и сколько при этом раз выделяется или освобождается память его просто НЕ ВОЛНУЕТ. Поэтому затраты на работу с памятью растут. И поэтому производительность падает. А если мы вспомним, что доморощенный шаблон большинства разработчиков очень часто сильно менее оптимален, чем возможности, заложенные в оптимизирующий компилятор, то мы и получим в среднем более убогий код по производительности. То есть коротко - оптом можно лучше оптимизировать процесс, чем в случае индивидуальных попыток в миллионах узких областей миллионами средних (или даже хуже) разработчиков (ведь качественных разработчиков всегда мало).
А разве кто-то говорил про отсутствие этой проблемы ? Она есть, но на фоне добавляющейся к ней кучи проблем в случае ручного управления памятью - она просто незаметна.
Задачи ОС универсальны и НИ КАК не зависят от языка, на котором она написана. Поэтому указанная вами связь между ненужностью JavaOS и задачами ОС совершенно некорректна.