немного о современном программировании

[nepilsonis]

http://www.linux.org.ru/jump-message.jsp?msgid=2128708

Martin Ankerl протестировал производительность отображения большогообъема текста в популярных эмуляторах терминала: xterm, gnome-terminal,konsole, wterm, aterm, rxvt, urxvt и т.д.

Наиболее производительными оказались gnome-terminal и konsole,опередив по скорости скроллинга даже стандартную linux консоль.Обратной стороной медали стало излишнее потребление памяти, так при буферизации 10000 строк процесс konsole увеличился на 38Мб, аgnome-terminal на 16Мб.

Не будем буквоедами, примем мегабайт за миллион байт.
итак, строка состоит из символов. Отображаемый символ текстового ascii файла — байт.

Буферизация 10 строк нуждается в 16–38 килобайтах. Одна строка — 1.6 — 3.8 КБ
строка в используемом файле не длиннее 80 знаков. То есть для буферизации каждого байта нужно от 20 до 35 байт.

Накладные расходы в IT стали весьма высоки.

Comments

[hansabanka.livejournal.com]

ну и?

[nepilsonis.livejournal.com]

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

Раньше люди писали программы, которые на машине с 16-32КБ ОЗУ и с дисками могли, скажем, редактировать текстовый файл, или картинку, в 100КБ размером. При том, что виртуальной памяти у системы небыло. А теперь текстовый редактор падает при редактировании файла размером 60 МБ на компьютере с 1 ГБ ОЗУ, да ещё и с виртуальной памятью.

MultiEdit на компьютере с 1 МБ ОЗУ очень шустро искал и заменял подстроки в нескольких сотнях файлов объёмом порядка 20 МБ. А вот глядя на нынешний Eclipse с проектом сопоставимого размера, но на компе с процессором и памятью в 1000 раз большими, понимаешь, какую сложную задачу взвалил на свой маленький компик.

[cu6apum.livejournal.com]

+1024

[kolloid.livejournal.com]

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

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

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

[nepilsonis.livejournal.com]

Да я понимаю :(
Но, оглядываясь назад, сомневаюсь - а стоило ли оно того?
И кажется мне, что если сопоставить увеличение производительности с увеличением полезной функциональности, то окажется, что КПД прогресса окажется не то десятыми, не то сотыми долями процента.

Потому что результат той работы, которую и делают программисты, для потребителя изменился только визуально.
Не вижу, чем принципиально нынешний офисный АРМ на каком-нибудь Domino или Exchange лучше АРМа неизвестного мне названия на СМ-4(?) в 1987 году.

На мой взгляд, видимые (и используемые потребителями) изменения в программах за последние ~ 20 лет таковы:
1. Типографика, шрифты. И, на мой взгляд, вреда от этого больше, чем пользы.
2. Картинки
3. Видео и звук
4. Фотореалистичная синтезированная графика в реальном времени
5. Связь с большими хранилищами данных
6. Обмен сообщениями с другими пользователями

В общем, конечно, хорошо. Но для утилизации роста ресурсов на 3-4 порядка, на мой взгляд, всё же маловато.
Компы по прежнему не могут ничего делать сами.
Даже машинный перевод и восприятие речи не далеко ушли от 1996 года.

[singalen]

Раньше программировали сотни, теперь - десятки миллионов.
И кому нафиг нужен терминал, в который можно выплюнуть 100М текста? Есть другие инструменты. Стоит оно усилий хотя бы одного из этих сотен?
Брюзжите.

[nepilsonis.livejournal.com]

Брюзжу, конечно.

Но где, где это «нечто», ради чего все эти жрущие ресурсы оборудования инструменты?

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

Где всепланетная система мгновенных рассчётов с 0 накладными расходами?
Где системы навигации, которые обходят пробки и замечающие новые дорожные знаки?
Где автоматические транспортёры?
Где распознавание письменной речи?
Где распознавание устной речи?
Где системы, способные к диалогу на естественном языке?
Где поиск изображений и звуков?
Где автоматические переводчики?

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

Я уж не говорю о возможности сказать компьютеру «посмотри на меня, и сшей мне костюм этой модели», или «возьми проект грузоперевалочной базы БГП-3341ф, и адаптируй его для расположения в квадрате хххххххххххх. Дай расчёт затрат и список изменений».
Не говоря уж о «выявлен вирус структуры ……. разработать блокатор, методику его применения, и технологический процесс для его производства»

И не говорите мне, что всё это есть, ибо то, что есть, соотносится с тем, что должно быть, как домик из песка в песочнице с нормальным современным большим домом.

Человечеству интереснее ловить педофилов, террористов и наркоманов, а также нарушителей правил парковки и нарушителей законов об авторском праве.
Лечить болезни и искоренить нищету не интересно.

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

Да. Резонёрствую :(
Что-то накатило.

[singalen]

Esse homo. Это не техническая проблема. Money make the world go round.
Вот бы каждый из нас задал себе вопрос - а что я сделал для развития разумного-доброго-вечного, хотя бы в технике?

Хотя по сути ты прав, но ...

[tapir1812.livejournal.com]

... в данном случае буферизуют не только код символа, но и информацию об "экранной типографике". Так что не удивительно. Кстати, поэтому и скорость, наверняка.

[k001.livejournal.com]

Отображаемый символ текстового ascii файла — байт.

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

Однако, да -- у меня (Terminal из XFCE, использует тот же терминальный виджет, что и гном-терминал, то есть vte) получилось 11М на 10К строк (открываем терминал, открываем второй таб, смотрим rss, делаем cat, снова смотрим rss, вычисляем разницу), то есть при длине строки в 80 символов по 14 байт на символ. Учитывая предыдущий параграф, не так уж и много.

Конечно, можно было бы использовать какой-нибудь тупейший алгоритм типа RLE для "схлапывания" строк пробелов -- но получить падение производительности как при выводе (которое, впрочем, можно победить, используя отложенную архивацию), так и при скроллбеке (что совсем неприятно).

[k001.livejournal.com]

Посмотрел vte, там 4 байта на символ (UCS-32), 4 байта на атрибуты (упакованная битовая структура из десятка полей). Меньше никак не получится.

[nepilsonis.livejournal.com]

Однако.

[k001.livejournal.com]

Собственно, вот:

/* The structure we use to hold characters we're supposed to display -- this
 * includes any supported visible attributes. */
struct vte_charcell {
        gunichar c;             /* The Unicode character. */

        struct vte_charcell_attr {
                guint32 columns: 2;     /* Number of visible columns
                                           (as determined
                                           by g_unicode_iswide(c)). */
                guint32 fore: 9;        /* Index into color palette */
                guint32 back: 9;        /* Index into color palette. */

                guint32 fragment: 1;    /* A continuation cell. */
                guint32 standout: 1;    /* Single-bit attributes. */
                guint32 underline: 1;
                guint32 strikethrough: 1;

                guint32 reverse: 1;
                guint32 blink: 1;
                guint32 half: 1;
                guint32 bold: 1;

                guint32 invisible: 1;
                guint32 protect: 1;
                guint32 alternate: 1;

                /* 31 bits */
        } attr;
};

[nepilsonis.livejournal.com]

Спасибо