Про вычислительную мощность

Развитие нынешней вычислительной техники идет по пути наращивания вычислительных возможностей в рамках существующей архитектуры – больше гигагерц тактовой частоты, больше операций в секунду, больше гигабайт памяти… Для чего нужны такие мощности применительно к «домашнему» персональному компьютеру? Для того, чтобы отрисовывать «окошки» Windows или просчитывать несложную логику в играх, вполне достаточно чего-нибудь наподобие первого «Пентиума», а то «четыреста восемьдесят шестого».

Будем считать, что все программы написаны «хорошо», никто не пытается производить сложные вычисления только по причине криворукости программиста (луч анального поноса посылается фирме Lotus). Тогда все задачи, требующие большого количества вычислений, разбиваются на две категории – «мультимедиа», то есть работа с графикой, видео, цифровым звуком, синтез 3D-графики и «действительно сложные задачи» — например, расчет индекса Доу-Джонса или цены на бананы в Гондурасе.

«Мультимедийные» задачи, можно сказать, естественны для домашнего компьютера. Конечно, я ни разу не сторонник той мысли, что домашний компьютер должен быть гибридом медиацентра и игровой приставки с выходом в Интернет, но возьмем это в качестве примера. Мало кто рассчитывает дома атомные бомбы, а вот посмотреть фильм или поиграть в Doom – милое дело. Давайте оценим сложность, к примеру, декодирования JPEG. Предположим, что все вычисления выполняются на обычном «универсальном» процессоре. Тогда достаточно оценить скорость выполнения двух наиболее сложных операций – «деквантизации», представляющей собой 64 умножения и обратного косинус-преобразования. Если косинус-преобразование ускорить тем же способом, что и в случае быстрого дискретного преобразования Фурье, то в конечном итоге для декодирования каждого блока 8×8 понадобится 106 мультипликативных и 42 аддитивных операции. Точно так же оценивается и количество операций при кодировании JPEG. Заметьте, что я намеренно считаю сложения и умножения «порознь» — умножение зачастую — гораздо более сложная операция, обычно занимающая намного больше тактов процессора.

Все широко используемые видеокодеки основаны на той же идее дискретного косинус-преобразования и «квантизации», поэтому оценки скорости этих операций дают нам представление о числе операций, необходимом для просмотра видео на компьютере. Понятно, что это – довольно требовательная к ресурсам задача. Например, на стоящем в моем ноутбуке Pentium M с частотой 1,7 ГГц просмотр DVD-фильма требует 30-50% процессорного времени. Стоимость «минимального» процессора, способного в реальном времени декодировать MPEG-2 (какой-нибудь Pentium III), получается довольно высокой (а если учитывать и «обвязку» в виде памяти и контролеров привода – очень и очень существенной). При этом кажется непонятным, почему китайский DVD-плеер может стоить менее 30$, а микросхема, используемая в нем в качестве процессора, стоит около 10$.

Дело в том, что совершенно необязательно считать «элементарными» операциями обычные арифметические операции. Если рассмотреть все то же косинус-преобразование с квантизацией как функцию, «входом» которой являются 512 бит (таблица 8×8 байт), и с теми же 512 битами на выходе, то можно составить ее таблицу значений. Можно составить, например, схему из функциональных элементов И, ИЛИ и НЕ, которая будет реализовывать эту функцию. Есть даже методы автоматического синтеза таких схем, например, асимптотически оптимальный (то есть строящий схему с довольно близким к минимальному числом элементов) метод Лупанова. Реализовав такую схему «в железе», например, как модуль процессора, получим возможность вычислить заданную функцию за один такт.

Конечно, пример выше – своего рода жульничество. Нам никто не разрешит использовать такое количество элементов, которое возникнет в рассмотренной выше схеме – ее сложность будет сопоставима с «полноценным» процессором. Практическая ценность его близка к нулю, и сравнима с таковой, например, у программы для машины Тьюринга или чего-нибудь Brainfuck-подобного. В реальности поступают проще. Достаточно легко, к примеру, реализовать любой конечный автомат. Кроме этого, можно разбить задачу на более простые операции с более простыми схемами. Таким образом можно упростить схему. При этом скорость ее работы все равно останется очень высокой. Например, сделанный «на скорую руку» JPEG-кодер на довольно простой и «медленной» ПЛИС фирмы Xilinx способен обработать в секунду порядка 3 мегапикселей (тактовая частота – всего 50 МГц), при этом он состоит примерно из 7000 элементов. Для сравнения, «универсальный» процессор Zilog Z80 состоял из 3500 элементов, но ни о каком JPEG-кодировании на нем речь даже не идет. Если же вместо ПЛИС использовать специально разработанную микросхему, то скорость повысится на порядок. JPEG-кодер (какой-нибудь Zoran COACH или Ambarella) в любом современном цифровом фотоаппарате-мыльнице способен за одну секунду обработать не менее 20-30 мегапикселей. Это сравнимо с производительностью Pentium IV, но на порядок выгоднее и с точки зрения стоимости (напрямую зависящей от числа элементов), и с точки зрения энергопотребления.

Все современные процессоры представляют собой, грубо говоря, калькуляторы. Конечно, и у них существуют инструкции, позволяющие быстро выполнять некоторые характерные для «мультимедиа» операции, например, набор инструкций MMX в процессорах персоналок. Тем не менее, крайне важно сохранить универсальность центрального процессора, не превращая его в начинку для фотоаппарата или DVD-плеера. Для таких вычислений, как матричные операции для 3D-графики или преобразование Фурье для кодирования графики, уже давно применяют и более специализированные процессоры – соответственно, видеоускорители или аппаратные MPEG-декодеры. Даже первые «Pentium», снабженные аппаратным декодером MPEG, были способны показывать фильмы с DVD или VideoCD. Стоит упомянуть и компьютеры Amiga, которые в начале 90-х были единственными «персоналками», способными обрабатывать видео – благодаря специализированным сопроцессорам. Тактовая же частота центрального процессора составляла всего лишь 14 МГц. Конечно, никто не запрещает использовать для тех же вычислений центральный процессор, но специализированные справятся с ними гораздо быстрее.

Собственно, использование сопроцессоров для некоторых сложных операций – давно не новость. Гораздо интереснее может выглядеть другая, менее очевидная вещь. Уже достаточно давно выпускаются ПЛИС – программируемые логические интегральные схемы, специальные микросхемы, состоящие из отдельных «кирпичиков», каждый из которых может быть элементом И, ИЛИ и НЕ. Связи между этими модулями задаются «прошивкой» микросхемы. Именно с использованием ПЛИС моделируются «заказные» микросхемы (тут передаю горячий привет [info]corvus_bkgk). В зависимости от «прошивки» ПЛИС может реализовывать самые различные функции.

Удивительно, но до использования перепрограммируемых ПЛИС в персональном компьютере «дошли» только у нас в России. Многие «спектрумисты» слышали про «клон» ZX Spectrum под названием Sprinter. На самом деле Sprinter – в корне отличающийся от Spectrum компьютер, способный только эмулировать последний. Более того, Sprinter может имитировать поведение несовместимых между собой «клонов», и может работать в «своем» режиме, превосходящем по возможностям любой другой Spectrum или его клон. Это достигается путем использования в качестве системной логики в этом компьютере нескольких ПЛИС, «прошивка» которых может заменяться «на лету», во время работы компьютера.

Довольно «объемистая» ПЛИС может выполнять функции, например, видеоускорителя, или декодера MPEG, и даже сопроцессора для любых других операций, например, криптографических. Конечно, использование ПЛИС в «персоналках» потребовало бы специальных библиотек, наподобие DirectX, но могло бы дать немалый выигрыш в вычислительно сложных операциях.

Не буду говорить об общей «кривости» архитектуры современного PC, состоящей преимущественно из тяжелого наследия уродца фирмы IBM и ночного кошмара фирмы Intel, не буду издеваться над тем, что самые современные процессоры состоят в основном из «костылей и подпорок» ради совместимости с Intel 8086, но замечу, что сейчас увеличение параметров процессоров происходит с большим трудом. Тактовая частота уже не увеличивается, растет лишь количество процессорных ядер на одном кристалле. Боюсь, что привычные нам «пни» уже достигли предела в своем развитии. Вполне возможно, что уже в недалеком будущем появятся первые «реконфигурируемые» вычислительные модули.

Кстати, на ПЛИС можно эмулировать и «обычные» процессоры. Например, уже существует несколько Open Source (!) реализаций все того же Z80. Интересно, чем будут мериться школьники на форумах, когда «апгрейд» процессора превратится в простое «скачивание» новой прошивки из Интернета?

Про стереовидео и AviSynth

Оценил возможности AviSynth по обработке видео. Например, вот так можно сделать анаглиф из интерлейсного стереоролика (с чередованием строк — левая-правая, левая-правая).

Clip=DirectShowSource("D:\My Downloads\The_French_Line_3D\VIDEO_TS\MJPEGexample.avi")

w=Width(Clip)
H=Height(Clip)

AssumeFrameBased(Clip)

Separated=Clip.SeparateFields()

Even=SelectEven(Separated)
Odd=SelectOdd(Separated)

Merge(ConvertToRGB(Even).RGBAdjust(0, 1.0, 1.0, 1.0), ConvertToRGB(Odd).RGBAdjust(1.0, 0, 0, 1.0))

Lanczos4Resize(W, H)

Levels(0, 2, 255, 0, 255)

На очереди — аналогичные скрипты для других форматов стереовидео.

И еще про GNU-лицензию

Я не раз упоминал, что нормально существовать может лишь тот свободный софт, разработчики которого сами им пользуются. Так как разработчики свободного софта — поголовно программисты, то и выдаваемый ими софт может нормально использовать только программист. Хотите пример? Пожалуйста.

Существует такая замечательная GNU-программа, как AviSynth. Она позволяет манипулировать с видеофайлами при помощи не очень сложного скриптового языка. Например, вот так:

clip1 = AVISource("video1.avi")
clip2 = AVISource("video2.avi")

return interlaced_dissolve(clip1,clip2,30) # dissolve from clip1 to clip2 over 30 frames

function interlaced_dissolve(clip clip1, clip clip2, int iter)
{
clip1 = clip1.SeparateFields()
evn1 = clip1.SelectEven()
odd1 = clip1.SelectOdd()
clip2 = clip2.SeparateFields()
evn2 = clip2.SelectEven()
odd2 = clip2.SelectOdd()
evn = Dissolve(evn1,evn2,iter)
odd = Dissolve(odd1,odd2,iter)
return Interleave(evn,odd).Weave().DoubleWeave.SelectOdd()
}

Насколько богат возможностями такой «видеоредактор»? Наверное, в нем можно сделать с видео буквально все, что угодно — то есть он намного превосходит в этом плане обычные программы вроде Adobe Premiere. Удобно ли пользоваться таким «видеоредактором»? Для программиста — да, для видеорежиссера — нет.

Каким может быть выход? Достаточно написать «frontend», который позволил бы «программировать мышкой» — то есть среду наподобие того же Premiere, оперирующую с AviSynth-овскими скриптами. Но ни один программист, то есть GNU-разработчик, делать этого не будет — зачем извращаться с GUI, когда все можно описать в скриптах?

Собственно, эта «ориентированность на программиста» и губит немалую часть опенсорсных программ.

Новости вордпрессоводства

А как вам нравится показанная в ролике тема P2 для WordPress?

Лично у меня возникло ощущение, что это — попытка соорудить на вордпрессовском движке некое подобие «древовидного» форума. И лишний раз хочу заметить, что технически и блоги, и форумы, и социальные сети строятся очень похоже.

Наверное, уже года через три мы увидим первый «конструктор» движков для сайтов, позволяющий при минимальных навыках программирования «сделать» несколькими кликами мышки форум, дейтинг, интернет-магазин — и вообще любой движок для более-менее типового сайта (или не очень типового — как гибрид дейтинга с интернет-магазином :) ). Фактически, нужна лишь методика «конструирования» структуры базы данных и некоторое количество «типовых» скриптов, которые объединяет в единое целое какой-нибудь очень визуальный редактор.

Решаем дифуры на PHP

Достаточно достать из коробки какой-нибудь Asus EEE PC, написать такой код в «блокноте»:

<?php
function f1($x, $y1, $y2){
return $y2;
}

function f2($x, $y1, $y2){
return (1-$y1*$y1)*$y2-$y1;
}

header("Content-type: image/png");

$st = microtime();

$image = imagecreate(640, 480);

$colorBack = imageColorAllocate($image, 0, 0, 0);
$colorFore = imageColorAllocate($image, 255, 255, 255);

imageFilledRectangle($image, 0, 0, 639, 479, $colorBack);

$x0 = 0;
$y01 = 0;
$y02 = 0.0001;

$h = 0.1;

while($x0 < 64){
$p11 = $h*f1($x0, $y01, $y02);
$p12 = $h*f2($x0, $y01, $y02);

$p21 = $h*f1($x0 + $h/2, $y01 + $p11/2, $y02 + $p12/2);
$p22 = $h*f2($x0 + $h/2, $y01 + $p11/2, $y02 + $p12/2);

$p31 = $h*f1($x0 + $h/2, $y01 + $p21/2, $y02 + $p22/2);
$p32 = $h*f2($x0 + $h/2, $y01 + $p21/2, $y02 + $p22/2);

$p41 = $h*f1($x0 + $h, $y01 + $p31, $y02 + $p32);
$p42 = $h*f2($x0 + $h, $y01 + $p31, $y02 + $p32);

$x1 = $x0 + $h;
$y11 = $y01 + ($p11 + 2*$p21 + 2*$p31 + $p41) / 6;
$y12 = $y02 + ($p12 + 2*$p22 + 2*$p32 + $p42) / 6;

$x0e = $x0*10;
$y0e = 240 - $y01*100;

$x1e = $x1*10;
$y1e = 240 - $y11*100;

imageLine($image, $x0e, $y0e, $x1e, $y1e, $colorFore);

$x0 = $x1;
$y01 = $y11;
$y02 = $y12;
}

$st = microtime()-$st;

imageString($image, 3, 10, 10, "Calculation time " . $st . " ms", $colorFore);

imagePNG($image);
?>

загрузить все это на какой-нибудь бесплатный хостинг, пользуясь стандартным консольным ftp-клиентом, встроенным в Windows — и наблюдать вот такую картинку (обратите внимание, что выдает ее php-скрипт):

Можно, конечно, порешать и более «крутыми» методами, например, добавить в программу автоматический выбор длины шага, а для расчетов использовать формулы более высокого порядка — но за это может найти и линчевать хостер.

А вот ZX Spectrum

Еще один график, на этот раз — построенный программой на Sinclair Basic.

Из-за ограниченных вычислительных возможностей ZX Spectrum пришлось обойтись построением графика «по точкам», но даже так на расчеты ушло около 3 минут. Сколько пишется программа — считайте сами, для меня наибольшей сложностью было работать с эмулятором, не имея под рукой раскладки «оригинальной» клавиатуры.

10 DEF FN F(X,Y,Z)=Z
20 DEF FN G(X,Y,Z)=(1-Y*Y)*Z-Y
30 LET X0=0
40 LET Y0=0
50 LET Z0=0.0001
60 LET H=0.1
70 INK 7
80 PAPER 0
90 IF X0 >= 64 THEN GO TO 280
100 LET P11=H* FN F(X0,Y0,Z0)
110 LET P12=H* FN G(X0,Y0,ZO)
120 LET P21=H* FN F (X0+H/2,Y0+P11/2,Z0+P12/2)
130 LET P22=H* FN G (X0+H/2,Y0+P11/2,Z0+P12/2)
140 LET P31=H* FN F (X0+H/2,Y0+P21/2,Z0+P22/2)
150 LET P32=H* FN G (X0+H/2,Y0+P21/2,Z0+P22/2)
160 LET P41=H* FN F (X0+H,Y0+P31,Z0+P32)
170 LET P42=H* FN G (X0+H,Y0+P31,Z0+P32)
180 LET X1=X0+H
190 LET Y1=Y0+(P11+2*P21+2*P31+P41)/6
200 LET Z1=Z0+(P12+2*P22+2*P32+P42)/6
210 LET X0E=X0*4
220 LET Y0E=88+40*Y0
230 PLOT X0E,Y0E
240 LET X0=X1
250 LET Y0=Y1
260 LET Z0=Z1
270 GO TO 90
280 BEEP 1,2

График более-менее совпадает с построенными в Qbasic и на ECMAScript:

spectrum-graph

Еще одно решение

На этот раз [info]soonts продемонстрировал, как можно строить графики и рисовать картинки, когда по рукой нет ничего, кроме приличного браузера. Windows с Internet Explorer «из коробки» не подходит, а вот, например, дистрибутивы Linux с KDE 4 и Konqueror должны будут показать вот такую картинку:

800x600, кликабельно
800x600, кликабельно

Кстати, придумалось еще одно «решение». Программа на PHP с использованием библиотеки GD пишется за 10-15 минут, затем ищется хостинг, все заливается туда и выполняется уже на сервере. Текстовый редактор и консольный FTP-клиент в Windows XP или Vista точно есть.

Решаем уравнения

Первым справился [info]stepanishchev, естественно, с использованием МК-152. Время составления программы — порядка получаса, время счета — 2 минуты 15 секунд. График бодро выводится по мере расчетов :)

На сайте НПП «Семико» выложен пример программы: http://mk.semico.ru/dr_info25.htm, снабженный комментариями. Если кому-нибудь вдруг потребуется решать на МК-152/161 системы дифференциальных уравнений — путем небольших поправок можно «научить» калькулятор делать это.

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

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

semiko_graph

graph

Это не удивительно. Вспомним, какое малое возмущение начальных данных приводило к возникновению генерации. Такое же малое возмущение повлияло и на поведение численного решения. Приведу эпиграф к параграфу, посвященному уравнению Ван-дер-Поля, из книги Хайрера, Нёрсетта и Ваннера «Решение обыкновенных дифференциальных уравнений»:

У меня есть теория: если вы хотите какой-то метод скомпрометировать — ищите решение уравнения Ван-дер-Поля
(П. Э. Задунайский, 1982)

Для подавляющего большинства «реальных» задач рассмотренный метод работает намного лучше.

С графиком в МК-152 все нормально, просто в первом варианте программы не было учтено, что ось Y направлена вниз. Если картинку перевернуть — все будет OK.

Решаем уравнение бурбулятора

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

Чтобы не извращаться, возьмем возникающее из физики уравнение Ван-дер-Поля. Речь идет о «модификации» уравнения осциллятора

y» + ay’ + y = 0.

Как легко показать (ну-ка, кто умеет решать дифференциальные уравнения?) при a>0 колебания будут затухающими, а при a<0 - неустойчивыми, то есть система пойдет вразнос. При a=0 получится малоинтересное уравнение идеального колебательного контура, которого в природе не бывает. Параметр a играет здесь роль сопротивления. Теперь подставим вместо константы a изменяющуюся величину (например, включив в цепь триод). В качестве простого "идеализированного" триода выберем a = y2 — 1. Тогда уравнение превратится в

y» + (y2-1)y’ + y = 0,

или, после стандартного понижения порядка — в систему двух уравнений:

y’1=y2
y’2=(1 — y12)y2 — y1

Как показал в 1920-1926 году Ван-дер-Поль, у такой системы сущеcтвует устойчивое периодическое решение, к которому сходятся все остальные решения. Это не может не радовать, так как система возникла из математического описания генератора незатухающих колебаний на триоде (кстати, для 20-х — вполне себе чудо техники).

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

y’1=f1(x, y1, y2)
y’2=f2(x, y1, y2),

мы умеем вычислять функции f1 и f2 в любой точке, и нам известны значения y1, y2 в точке x0. Тогда мы можем приближенно вычислить их значения в точке x1 = x0 + h, где h достаточно мало, по следующим формулам (в «Кратком физико-математическом справочнике» Аленицына, Бутикова и Кондратьева 1990 года издания они приведены, как «формулы Рунге-Кутта»):

p11 = hf1(x0, y1, y2)
p12 = hf2(x0, y1, y2)

p21 = hf1(x0 + h/2, y1 + p11/2, y2 + p12/2)
p22 = hf2(x0 + h/2, y1 + p11/2, y2 + p12/2)

p31 = hf1(x0 + h/2, y1 + p21/2, y2 + p22/2)
p32 = hf2(x0 + h/2, y1 + p21/2, y2 + p22/2)

p41 = hf1(x0 + h, y1 + p31, y2 + p32)
p42 = hf2(x0 + h, y1 + p31, y2 + p32)

x1 = x0 + h
y1(x1) ≈ y01 + (p11 + 2 p21 + 2 p31 + p41) / 6
y2(x1) ≈ y02 + (p12 + 2 p22 + 2 p32 + p42) / 6

Конечно, в современной вычислительной практике применяются гораздо более сложные варианты метода Рунге-Кутта, например, формулы Дормана-Принса, но для грубых расчетов хватит и этого. Не будем усложнять задачу такими «бонусами», как автоматический выбор длины шага, а ограничимся этими формулами. Для упрощения написания программы я «раскрыл» вектор (y1, y2). Для вычисления y1(x1) и y2(x1) достаточно лишь применить эти формулы в том порядке, в котором они выписаны. Вычисления надо повторять, пока не исчерпается отрезок, на котором нас интересуют значения y(x).

Теперь для расчетов требуются лишь начальные условия — известные в нулевой момент времени y1 и y2, а также величина шага и длина отрезка интегрирования. Предлагаю выбрать такие начальные условия:

x0 = 0,
y1(0) = 0,
y2(0) = 0,0001

Очень небольшое значение y2 — необходимый для запуска генератора «толчок». Я утверждаю, что при таких условиях y1(x) довольно быстро «стабилизируется» и колебания станут незатухающими, с постоянной частотой. Для того, чтобы убедиться в этом, предлагаю проделать вычисления с шагом 0,1 вплоть до x = 64. Получим довольно симпатичный график (масштаб по y — в десять раз меньше, чем по x):

graph

Предлагаю всем желающим попробовать построить такой же график любыми доступными с компьютером «из коробки» средствами. К таковым, например, можно причислить Excel — офисный пакет довольно часто является предустановленным, Matlab же к «коробочным» не относится. Разнообразные варианты Basic — от Sinclair Basic до VBScript, Javascript, различные варианты интерпретатора командной строки — только приветствуются. Интересно было бы взглянуть на программу для какого-нибудь программируемого калькулятора (при отсутствии графического экрана достаточно просто «распечатки» значений). Сомневаюсь, что «старинные» МК-52 или МК-61 «потянут» это, памяти у них маловато (хотя метод Ньютона для них реализовывали), а вот для МК-152 такая задача — в самый раз.

PS Я свой график строил на QBasic из комплекта MS-DOS 6.22

К вопросу о легкости программирования

Вчера в комментариях два раза прозвучала точка зрения, совпадающая с популярным в среде программистов и сочувствующих заблуждением, что языки высокого уровня, типа VBScript, Java, C# или VB.NET — это идеальные языки для «не-программистов» — простые в освоении и «безопасные», то есть не дающие совершить ошибку. Но… Давайте вспомним задачу об определении резонансной частоты. Предлагается следующий код на VBScript (немного исправленный для большей реалистичности единиц измерения):

strL = InputBox("Enter the inductance, uH")
strC = InputBox("Enter the capacitance, pF")
WScript.Echo "Resonance frequency in kHz is " & ( 1.0 / Sqr( CDbl(strL) * CDbl(strC) ) )

Казалось бы, все очень просто. Но давайте сравним его с вот такой программой на QBasic:

DIM L AS DOUBLE, C AS DOUBLE
INPUT "Enter the inductance in uH and capacitance in pF", L, C
PRINT "Resonance frequency is "; 1.0/SQR(L * C); " kHz"

В чем разница? Программа на «классическом» Basic записывается с использованием простых операторов — здесь это DIM, INPUT и PRINT. Согласитесь, что PRINT — намного более очевидная запись для оператора вывода, чем «заклинание» WScript.Echo, а INPUT — более естественная форма записи оператора ввода, чем InputBox. Функция CDbl — это вообще «по ту сторону добра и зла».

Изложение основ Basic в объеме, достаточном для простых «вычислительных» программ, занимает всего лищь десяток страниц. Конечно, можно на том же десятке страниц рассказать и об аналогичных возможностях, к примеру, VBScript. В чем разница полученных знаний? Если изучающий «классический» Basic получит полное изложение основных возможностей языка, то его собрат по несчастью, вынужденный разбирать нюансы VBScript, будет воспринимать команды вроде WScript.Echo как «заклинания». Это еще не самое страшное. Если десятистраничное изложение основ VBScript — это начало книги по этому языку программирования, то, естественно, будет упомянут и «объект» WScript. Что такое «объект» — разъяснить человеку, не знакомому с программированием вообще, невозможно. Можно сколько угодно говорить, например, о прелестях использования библиотеки классов MFC, но если вы ни разу не писали с использованием «голого» WinAPI — вы никогда не поймете, что объектно-ориентированное программирование по своей сути — это удобный способ записи некоторых реально возникающих конструкций. Не увидев того, как эти конструкции возникают, невозможно представить себе, что такое «объект».

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

bool IsNumber (string str){return (str.Replace ("0", "").Replace ("1", "").Replace ("2", "").Replace ("3", "").Replace ("4", "").Replace ("5", "").Replace ("6", "").Replace ("7", "").Replace ("8", "").Replace ("9", "").Length == 0);}

В чем мораль? Не надо считать пользователя идиотом, подсовывая ему усложненный ради какой-то мифической «безопасности» язык. В том же «классическом» Basic были команды PEEK и POKE, осуществлявшие прямой доступ к памяти. Естественно, никто в здравом уме ими не пользовался, пока речь не заходила о каких-то специфических операциях, типа «взлома» ресурсов игр на том же Спектруме. Что же мы получили в разнообразных вариантах «визуального Бейсика»? По сути — ничего, кроме отказа от старых интуитивно понятных команд в угоду ООП. Вместе с заменой PRINT на «заклинания» вроде WScript.Echo, были выброшены, как устаревшие, многие полезные конструкции, работа с файлами и графикой превратилась в дикий кошмар.

Замечу, что один из лучших языков для «не-программистов» — встроенный язык Matlab — за все время своего существования не переиначивался в рамках модных тенденций. Я бы сказал, что для определенных задач он подходит намного лучше, чем Basic, и намного превосходит многие языки в простоте освоения.

Все же заявления относительно «простоты» современных объектно-ориентированных языков относятся к простоте их использования низкоквалифицированными программистами. Объектно-ориентированные возможности позволяют писать код так, что ошибки в одном из модулей можно исправить, не затрагивая всю остальную программу. При работе над проектом нескольких человек и соблюдении ими определенного стиля программирования, определяемого самим языком, изменения в одном из модулей не должны вызывать ошибок в других, своего рода «принцип открытой архитектуры». Это и надо понимать под «безопасностью».

По поводу необходимости программирования

На вчерашнюю запись [info]soonts оставил вот такой комментарий:

>можно заменить почти все специализированные электронные устройства достаточно мощным “стандартным” компьютером
И заменяют. В том числе в приложениях, исключительно критичных к надёжности. Те же американские марсоходы: PowerPC CPU + VxWorks OS.

Во-первых много людей уже умеют хорошо программировать стандартные компьютеры.
Во-вторых, как ни странно мощные стандартные компьютеры дешевле нестандартных.
Например материнская плата с вмонтированным процом intel atom 1.6GHz размером 17×17cm стоит как половина того калькулятора. Шоб сделать из неё полный аналог калькулятора, надо добавить RAM (200р за 256MB), USB флешку для загрузки какой-нить ОС реального времени и хранения данных (300p за 1GB), БП, дисплей и клавиатуру, и ессно написать софт.

>надежность такой системы будет довольно низкой. Сравните, например, мультивибратор на двух транзисторах и “мигающую лампочкой” программу для Windows

Если эта “мигающая лампочка” на дисплее, то всё упирается вовсе не в windows и не в надёжность аппаратной части, а в частоту обновления экрана.
Шоб мигать лампочкой на экране строго раз в секунду, всего-то надо не накосячить при реализации, а именно поднять приоритет процессу и использовать Direct3D для рисования.

Если же “мигающая лампочка” прицеплена например к выходу звуковой карты уровня m-audio audiophile, то даже под windows, при некотором умении программировать можно добиться при частотах от 0 до 20KHz надёжности и стабильности _существенно_ выше чем у двух транзисторов. А кроме универсальной windows, есть ещё системы реального времени.

Я не был в числе критиков МК-152, не считаю цену завышенной, но скорее согласен с теми, кто считает девайс бесполезным.
Точнее, я считаю что рынок очень-очень маленький.
Очень мало кто умеет этот странный МК.
В то же время куча людей, и у нас и в остальном мире, умеют пользоваться matlab на PC, и программировать PIC, Intel MSC, и прочие контроллеры.

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

За последние 20 лет вычислительная техника шагнула далеко вперед. Если 20 лет назад, к примеру, задача обращения большой квадратной матрицы (то есть решения системы многих уравнений, например, пары тысяч) даже сравнительно мощным компьютером (конечно, не Cray, а скорее что-нибудь из больших ЕС) занимала около часа, то сегодня любая персоналка делает это за пять-десять минут, а то и меньше. Теперь любому доступны вычислительные возможности, например, крупного НИИ образца 1989 года. Любая блондинка с гуманитарным складом мышления носит в сумочке (!) ноутбук, способный, к примеру, произвести расчет траектории баллистической ракеты за несколько минут.

Казалось бы, наступил «золотой век» в представлении писателей-фантастов. На каждого жителя Земли приходится такая вычислительная мощность, что все расчеты, необходимые, например, для полета на Марс, могут быть выполнены практически моментально. Думаю, если бы сейчас подготовкой к марсианской экспедиции занимались бы действительно эффективные менеджеры, то не возникло бы никакой необходимости в «распараллеливании» расчетов, как это было сделано при разработке первой советской термоядерной бомбы. Все прекрасно посчиталось бы на паре «самых мощных компьютеров Савеловского рынка».

marshalberia

Но, думаю, если бы кто-нибудь сказал, что при запуске программы для работы с электронной почтой объем производимых вычислений сравним с вычислением, например, траектории спутника (я не шучу, Lotus Notes действительно при запуске «отжирает» 100% загрузки не самого слабого Intel Pentium M на пару-тройку минут), то разработчики программы отправились бы валить лес далеко за Урал.

Такой непроизводительный расход вычислительной мощности просто поражает. Более того, скорость расчетов для пользователя остается неприлично низкой. Современные компьютеры уступают в этом плане даже «Синклерам».

В самом деле, даже на самом паршивом персональном компьютере 80-х был интерпретатор Бейсика. Сейчас даже в самой навороченной Windows 7 встроен довольно сомнительный калькулятор, по удобству значительно уступающий своему настольному собрату за 100 рублей. Казалось бы, что это дает, когда есть все необходимые программы? К сожалению, последний тезис просто неверен.

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

lc

С другой стороны, считать на калькуляторе, например, индуктивность, зная частоту и емкость, не очень приятно. Особенно — когда делаешь это много раз. «Программа» на Бейсике займет три строчки, и пишется за 5 минут — даже меньше. То есть, имея в распоряжении древний «Спектрум», и зная базовые конструкции Бейсика, мы можем ловольно сильно облегчить себе жизнь. Что же нам предлагает платформа Windows+Intel? Калькулятор в Windows? Это даже не смешно. Excel? Простите, но мазохизм — это извращение. Как это не удивительно, но в «стандартном комплекте» не найдется ни одной программы, которая позволила бы ускорить простейшие расчеты. Монструозный Matlab — вот, пожалуй, единственный программный продукт, предлагающий схожую функциональность (и даже больше — но эти возможности будут лежать мертвым грузом).

Итак, внезапно выяснилось, что пользователь просто не может задействовать имеющуюся у него вычислительную мощность для выполнения даже простейших расчетов. Природа не терпит пустоты, и многие (в основном — осваивающие Delphi или Visual Basic студенты) пишут свои программы для таких расчетов. Казалось бы, нет ничего проще. Накидал на форму мышкой компоненты, написал пару строк кода — готово! К сожалению, нет…

Вернемся к расчету емкости. Устав от Excel, зайдем на любую софтопомойку и наберем в поиске «колебательный контур». Ура! Нашлась программа, написанная каким-то студентом N-ского технического университета. Скачиваем, запускаем. Видим приятный интерфейс, где достаточно ввести два значения, чтобы посчиталось выбранное третье. Выбираем интересующую нас индуктивность, затем кликаем мышкой на поле ввода частоты и начинаем стирать имеющееся там значение. Красота! Значение индуктивности пересчитывается автоматически всякий раз, когда меняется введенная частота или емкость! Ничтоже сумнящеся, крепко давим на Backspace и стираем всю частоту, чтбы ввести свою. В недрах программы происходит страшное. Обработчик события «изменилось значение поля с частотой» считывает из поля текстовое значение — пустую строку, преобразует его в число — 0 и… делит, вызывая ошибку с вылетом всей программы.

Любой профессиональный программист всего лишь посмеется. Но автор программы по специальности — не программист, и он не обязан знать многих тонкостей. Может быть, он сначала вводит новое значение перед старым, а затем стирает «хвост» кнопкой Delete. Тогда программа работает. В принципе, автор может освоить программирование в необходимом для инженерных расчетов объеме — вычисления, ветвления и циклы, простейший ввод-вывод. Если бы программа писалась на Turbo Pascal или Quick Basic, то «вылет» происходил бы лишь при недопустимых входных данных, что более-менее нормально и допустимо. Любое же программирование под Windows требует знания всяческих тонкостей.

Давайте опустим завесу жалости над концом этой печальной сцены. Не буду переходить, например, к решению дифференциальных уравнений, когда вытащенный из коробки Спектрум довольно бодро начинает рисовать на экране график решения, получаемого методом Рунге-Кутта (10-15 строчек на Бейсике), а «свежий» Asus EEE PC пасует перед такой задачей.

Конечно, при наличии навыков, времени и достойной среды разработки можно написать программу, рисующую тот же график, но со значительно лучшей точностью, и на персоналке с Windows. Но все упирается в то, что все современные среды программирования рассчитаны на профессиональных программистов. Можно сколько угодно обсуждать преимущества C перед Бейсиком, но забыть о главном — в 80-х для программирования на Бейсике не требовалось ничего, любой компьютер имел его интерпретатор (кстати, в состав DOS вплоть до 6.22 тоже входил QBasic). Сейчас же доступных для пользователя технологий программирования просто нет, вместо них — 3D-ускоренный интерфейс Aero и картинки из Висты, своими названиями приводящие в изумление.

Между прочим, программируемые калькуляторы типа МК-52 или МК-61 предназначались в том числе и для инженерных расчетов. Для них, например, выпускались модули расширения памяти, содержавшие различные математические и инженерные подпрограммы. На Западе до сих пор применяют программируемые микрокалькуляторы Texas Instruments и других производителей. Появление МК-152 в 2008 году выглядит странно лишь потому, что подобная техника у нас не выпускалась и не использовалась почти 20 лет. А ведь для многократного повторения одних и тех же, пусть и несложных, вычислений программируемый калькулятор оказывается на порядок удобнее современного компьютера.

Возвращаясь к нашим Delphi и Quick Basic. В свое время много писали о необходимости преподавания в школах основ информатики и вычислительной техники, затем развернулись дискуссии о том, кого следует готовить — пользователей готовых программных продуктов (Windows, Word, Excel, Photoshop) или «программистов». Конечно, победила первая точка зрения. Но и в обучении азам программирования все же есть смысл. Но это оправдано лишь тогда, когда учат не «накидыванию компонентов на форму», а основам вычислений с использованием компьютера — то есть, как я уже говорил, конструкциям алгоритмического языка, операциям ввода-вывода, возможно — простейшим «общим» и вычислительным алгоритмам. Главное — это дать возможность самому произвести какие-либо расчеты, не дожидаясь появления специализированного софта. Кстати, про специализированный софт я хотел бы написать еще один пост, на этот раз — про аргумент начинающих линуксистов «у любой программы есть свободный аналог».

К сожалению, в мире нет нигде не занятой «кучи людей, которые умеют пользоваться Matlab или программировать стандартные компьютеры». Работа программиста стоит довольно дорого, так что большинство «программируемых пользователем» устройств, типа тех же калькуляторов или станков с ЧПУ — это одна из немногих возможностей дать не-программисту возможность вводить и выполнять какие-то алгоритмы. К сожалению, любые более богатые по возможностям устройства требуют уже наличия квалификации программиста, а ее-то у большинства работающих с техникой нет, каким бы странным это не казалось всезнающим «компьютерным энтузиастам».