OSDev

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

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

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

И по поводу администраторов.

Здесь я с вами не соглашусь. Талантливый одиночка может придумать много интересного и полезного, но согласитесь - таких одиночек, да с реально полезным выхлопом, на свете очень мало. Поэтому для человечества остаётся один путь - создавать коллективы. И в коллективах чаще всего работают далеко не Эйнштейны с Ньютонами. И вот в ситуации, когда народу много, но каждый далеко не гениален, нам всё-таки нужно давать конечный результат. Именно в такой ситуации крайне важен умелый управленец/администратор. Я согласен с тем, что безграмотный начальник просто убьёт любое полезное дело, но некая "центральная фигура" из учёных, инженеров, музыкантов в подавляющем большинстве случаев представляет из себя именно безграмотного администратора, просто потому, что для хорошего администрирования нужна такая важная деталь, как ОПЫТ, и именно опыт администраторской работы, работы с людьми, работы с тупыми начальниками сверху, работы со смежниками, работы по выбору реально ЭФФЕКТИВНЫХ вариантов и т.д. и т.п.

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

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

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

Попробую ответить на Ваши вопросы.

1. Ранее вроде представлялся - я аналитик, научный круг интересов -
общая теория систем (системология то есть). С применением в самых
разных областях от истории и культуры, до геополитики и ... (компьютеры
в том числе). Основной результат деятельности - пятикнижие "Свет
русской цивилизации" (каждый год книги дорабатываются и расширяются,
сейчас работаю над одним из параграфов).
По ВУЗовскому диплому (МЭИ) - инженер-радиофизик.
Аспирантура, тема "Распределенные системы информационного
обслуживания", направление ИИ, более конкретно (без комментариев).

2. Опыт нескольких лет программирования на Ассемблере х86, создание
и поддержанием довольно больших прикладных программ. Все это
в основном до 2000 года. Но я не программист, думается быстро,
а реализуется медленно, ассемблер здесь, так как были эксперименты
со всякими хитростями. Есть собственный язык программирования,
разрабатывал сам, заказывал, потом его использовал... продать бы
кому-нибудь.

3. Слово "инженер" в переводе означает "изобретатель", что собственно
и пытаемся как-то делать сообща в этой теме... в весьма вольной
форме.

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

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

6. И т.д.

Yoda, все же было бы очень интересно услышать Ваше мнение по существу
предложения. Есть еще и более конкретный вопрос - так как платформа
НОВАЯ, то нет смысла делать в ней навороты с загрузкой ОС, что мы
наблюдаем, например, на платформе х86, все можно будет сделать до
безобразия просто. Что скажете?

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


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


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


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

Так, всё, у меня нет ни желания, ни времени заниматься пустой болтовнёй.

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

Для Yoda

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

2. По поводу загрузки ОС. Вы улучшили те загрузки что были, честь Вам и
хвала. Вы это сделали под то железо, что есть. Мой же вопрос совсем
о другом - как грамотно (по современному) заточить железо (а объявлено
о создании новой платформы), чтобы загрузка была максимально удобной
и защищённой, и что нужно предусмотреть в построении ОС, чтобы достичь
того же, но уже со стороны операционки?
Если конечно есть что сказать.

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

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

5. Другие пункты тезисов статьи также можно будет в дальнейшем
детально обсудить.

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

Для Himikа

Разработка Нового процессора не входит в предлагаемый проект.
Если кто-то где-то что-то разработает, то можно рассмотреть
вариант его использования в Новой платформе. А вот использовать
имеющиеся (иначе чем сейчас) можно. Приведу один возможный
пример. Внутри ARM (насколько понимаю) кроме ядра (ядер)
существует и еще что-то (обвязка). Вот это "что-то" может быть
иным, под Новую платформу. Российские разработчики вполне
способны это при необходимости сделать. Но всё это в любом
случае не входит в описываемый проект. А производят пусть
те, кто умеет производить. Не стоит сбрасывать со счетов и
Эльбрус и даже Мультиклет (постараюсь в ближайшее время
вникнуть - что у них там, как и на какой стадии).

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

Так, к слову. В ARM-ах однажды пытались сделать нативную поддержку Java-байткода (jazelle). Как я понял, вышел epic fail, который сначала попытались переделать в универсальный ThumbEE, а в результате выдрали с корнем и выкинули из процессора.

Хотя возможно я чего-то недопонял по вике.
Но в любом случае, аппаратно выполнить java-байткод (как и почти любой другой) при адекватном количестве транзисторов просто невозможно, потому что эти виртуалки подразумевают сложные механизмы разрешения вызовов (всех этих наследников и интерфейсов) и выделения/освобождения памяти, которые так просто не разведешь лишним миллионом транзисторов. В jazelle это разрешалось, как я понял, установкой Callback-ов операционкой, что не есть хороший аппаратный механизм.

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

Хоть и не вышло заинтересовать Си-писателей сравнением скорости, но всё же я попробовал поиграться с гигабайтами на Java. Использовал древний по сегодняшним меркам процессор Core Duo на 2ГГц пятилетней давности выпуска. Запустил на нём в однопоточном режиме стандартный XML-парсер и померял скорость. Заняло это занятие где-то с пол-часа, что явно не так страшно, как наверняка подумали некоторые Си-разработчики. Собственно вот что получилось:

1. Скорость на JVM 1.6 = 69 мегабайт в секунду.
2. Скорость на JVM 1.8 = 78 мегабайт в секунду.
3. Скорость на JVM 1.8 при использовании оптимизации = 450 мегабайт в секунду.

Стоит заметить, что последний пункт, будучи выполненным на двух доступных ядрах, даёт нам 900 мегабайт в секунду - почти тот самый гигабайт, который рекламируют разработчики на С.

Но помимо гигабайтных скоростей на древнем процессоре всё же нужно пояснить суть эксперимента. А суть такая:

Во первых - JVM постоянно совершенствуется и мы видим рост производительности на 13% с переходом от версии 1.6 на версию 1.8.
Во вторых - указанная оптимизация заключалась в замене стандартного парсера на некий тривиальный код, который ищет вхождение подстроки с нужным XML-элементом. Думаю, что именно таким способом и Сишные "парсеры" достигают рекордных результатов. Но на самом деле это именно "парсеры", то есть настоящими парсерами такие программы назвать нельзя, ведь они не делают кучу необходимых шагов. В частности стандартный парсер всегда полностью разбирает XML-элемент на составляющие. При этом он вынужден выделять память под строки с названием элемента, под названия и значения атрибутов, а так же под текст между тэгами элемента. Кроме того стандартный парсер всегда производит преобразование потока байт в поток символов в определённой кодировке, когда на один символ приходится чаще всего более одного байта (например для русского языка в кодировке utf-8 предусмотрены только двухбайтные коды символов). Вот поэтому-то стандартный парсер и проиграл простейшей программулине, которая тупо ищет нужную подстроку, не заморачиваясь вообще ни на одну задачу из списка, поддерживаемого стандартным парсером. И именно об этом я говорил, когда пояснял pavia в ответ на его "покажи мне".