» О вычислительной мощности и сложности решаемых задач : Берлога инженера - бесплатные программы - стереофото - справочные материалы - обои для рабочего стола


О вычислительной мощности и сложности решаемых задач

Я тут как-то недавно упоминал о программируемых калькуляторах и их вычислительных возможностях…

Последнее время возникает стойкое ощущение, что компьютерный мир движется в каком-то неправильном направлении. Программы, функционал которых не так уж и значительно вырос со времен Windows 95, а то и DOS, отъедают львиную долю ресурсов наших компьютеров. А они таковы, что пару-тройку десятков лет назад они могли бы обеспечить вычислительной мощностью крупный НИИ. Ещё и программистам в Тетрис бы осталось поиграть.

Поневоле возникает вопрос, куда всё катится? Понятно, что производители «железа» идут в одной упряжке с производителями ПО – новая операционная система непременно требует увеличения памяти, жесткого диска, скорости и разрядности процессора, а новые игрушки работают только с шейдерами, поддерживаемыми самой последней версией чипов для видеокарт. “Это бизнес, детка!” (с)

Однако не стоит всё валить на злых и жадных дядей. Давайте посмотрим на себя. Если ранее программирование считалось высоким искусством, то сейчас всякий, кто может создать в Дельфи форму с парой кнопок уже мнит себя серьёзным специалистом. Так и возникают приложения, в которых вся бизнес-логика выполняется в обработчике события нажатия на кнопку или вот такие перлы . Кнут с его искусством программирования тихо сходит с ума и сжигает ненаписанный четвертый том, в то время когда люди «изобретают» такое.

Тем не менее, высокое искусство осталось. Оно по-прежнему процветает там, где ресурсы ограничены, а время как никогда реально. Это программирование микроконтроллеров. Там иначе просто не выжить. Я сейчас с трудом могу представить человека, пишущего коммерческое ПО для Windows на ассемблере (специфические случаи я не беру), а в случае с микроконтроллерами – это самый естественный путь. Вот, кстати, отличное эссе на эту тему .

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

Одними из самых интересных и сложных вычислительных задач, решаемых при помощи ЭВМ были высадка американцев на Луну и автоматическая посадка нашего корабля Буран. Можно ещё упомянуть расчёты при создании (термо)ядерного оружия и прочих смертоносных штук, но они порыты мраком тайны, и мы не будем о них, космос гораздо интереснее.

Итак, посадка на Луну. Процедура, как вы понимаете, достаточно сложная. Параметры компьютера, которым оснащались корабли «Аполлон»:

  • ОЗУ - около 4 Кбайт (ферритовое ОЗУ на 2 048 15-битных слов)
  • ПЗУ - ферритовое на 36 864 15-битных слов
  • собран на 5000 микросхемах
  • вес 30 кг
  • стоимость 150 тысяч долларов

Лунный компьютер

Управляющая программа поддерживала многозадачность с установкой приоритетов.

Справедливости ради следует сказать, что самые сложные вычисления, требующие большого времени уже были проделаны на Земле на больших ЭВМ и загружены в ПЗУ. Тем не менее, не знаю, как вам, а мне всё это внушает уважение.

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

Вот какие ресурсы необходимы и достаточны для решения реальных задач. А мы тут всё окошки рисуем…

Далее был длинный, полный нравоучений вывод, но потом я подумал, а зачем? Статья не для того, чтобы учить программировать – для этого есть другие ресурсы. Это просто ещё один повод остановиться и подумать: «А правильным ли путем идём?».

 Рекомендуйте на news2.ru     Занесите в del.icio.us

Читайте также:
Создание стереофотоизображений. Сложности в сведении анаглифов (2). Форма
Создание стереофотоизображений. Сложности в сведении анаглифов (1). Цвет
Создание стереофотоизображений. Сложности в сведении анаглифов (3). Судный день





26 комментария to “О вычислительной мощности и сложности решаемых задач”

  1. e1vin :

    Да, я с Вами полностью согласен… Не сказать, что я такой уж великий программист, сам толком ничего не умею (точнее будет сказано - все, но по чуть-чуть), но все эти современные тенденции с drag-and-drop “программированием” меня совершенно не радуют. Ужас какой-то.

    Сам стремлюсь освоить именно низкоуровневое программирование, хотя приходится делать, как я и написал выше, все подряд своими руками, от сайта и скриптов к нему до логотипов в CorelDraw и сведения собственных песен :) Но это, наверное, и к лучшему.

    Хочется пожелать всем кодерам в новом году свежих идей, незамутненных пивом мозгов и побольше красивого и читаемого кода :) Чтоб глаз радовался! ;)

  2. Ivan A-R :

    Как программист микроконтроллеров полностью согласен.

    А ссылочки на гениальные решения порадовали =)

  3. jwb :

    Был у меня раньше компьютер: ZX-Spectrum … 48 (128) кб. И игры были интересные, и программы толковые … BASIC - и все на 48 кб -х. ;) Понастальгировать можно тут: http://www.worldofspectrum.org :). Море программ и эмуляторов для запуска на PC (рекомендую SpecEmu ).

  4. Vladimir :

    Выражаю своё восхищение интересной злободневной темой. Очень хорошо описана, с великолепными примерами. Спасибо! :)

    Увы, сейчас “мышиное программирование” проникает даже в самые что ни на есть “железные” темы - программирование FPGA. Представляете, можно реализовать USB, UART или даже PCI вообще не прикасаясь к клавиатуре! Но… лёгких путей не бывает. Лёгкий путь приводит как раз к тому, что описано в статье.

    Сейчас почитываю некоторые материалы по программированию. Наши старшие братья в 70-х и начале 80-х запихивали в 1к ПЗУ целую систему с поддержкой терминала и дисков, с компилятором и интерпретатором и проч., проч. Каково?!?!?!

    Действительно, легче заплатить лишних денежек за Мега(Гига)Герцы и за Мега(Гига)Байты, чем вложиться в аккуратно написанный код.

    Вот и получается, что какая-нибудь ATMega (не самая мощная) обставит гигагерцовый последний-распоследний навороченный Intel (под Win или Lin) в работе с парой UART портов…

    Или DSP, который стоит не больше $10 на частоте 600МГц справится с компрессией видео в реальном времени, а несколькоГигагерцовый опять же intel, стоящий больше $1000, который теоретически заткнёт за пояс несколько таких DSP, под Win или Lin с подобной задачей не справится, или справится, но с ОЧЕНЬ большими ухищрениями…

    Эххххх!!!!! Наболело.

  5. Vladimir :

    А вообще, думаю, виновата глобализация.

    Раньше создатель ЭВМ на ней же и программировал, и обслуживал её. Сейчас программы пишут люди, даже незнакомые друг с другом. На чём легче писать такую программу? На ASMе? ;)

    Конечно же, на более “высоком” языке. Так нагляднее, понятнее, меньше ошибок, более легко “читаемее”.

    Посмотрите “Ретинг языков программирования”:
    http://beta.delta-z.com/index.php/archives/177/

    Популярность языка находится в обратной зависимости от производительности. И дальше будет БОЛЬШЕ.

    Думаю, лет 20-30 назад было всё наоборот - “по правильному” - более эффективный инструмент был более популярным.

    Сейчас же эффективность, как видим, в основном определяется возможностью ГРУППОВОЙ разработки, ибо программы/системы стали настолько сложны, что один человек это не поднимет, а группа не поднимет низкоуровневый язык.

    Так что всё закономерно. Мы платим за прогресс, за увеличение сложности…

    Может быть процесс “наращивания мускулов” скоро замедлится. Тогда инвестиции потекут как раз в эффективный код, и “золотой век” ещё наступит. ;)

    Поживём - увидим.

  6. Камашев Максим :

    Вспоминая свою молодость, и то, как я играл в Unreal Tournament на своей карточке в 8 метров…

    И смотря на современные игры, которым моих 128 метров просто мало, то я сам удивляюсь, куда же катится мир.. :(

    А вспоминая виртуальную машину, компилятор и интерпритетор ФОРТ, который уложился всего в семь кило, можно выпадать в осадок от всех тех мегабайтов, что несут в себе современные программы!!!

  7. Ivan A-R :

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

  8. Max :

    Думаю, что в связи с бурным переходом на СИ Ассемблер тоже постигнет участь сравнимая со спектрумом)))))Почитайте тут http://arvresearch.nm.ru/text/51.dhtml

  9. Ivan A-R :

    Max, вот когда у Вас программа написанная на C не влезет в 1K памяти, тогда поговорим какая участь постигнет ассемблер… Или два такта лишние будут на С =)

  10. Max :

    Вы меня просто неправильно поняли я за асм)))))

  11. Ivan A-R :

    Max, пардон, коли так.. Хотя смысл моей фразы не меняется =)

    А статья плохая. Автор привык писать под х51 на ассемблере и всё остальное он считает злом.
    А недостатки можно найти в любом железе… В х51 их тоже выше крыши. Только об этом в статье скромно умалчивается ;-)
    Автор совершенно не отдаёт отчёт, что к примеру AVR построен по RISC архитектуре, и от этого имеет необычную по сравнению с 51ми систему команд. PICи создавались нацеленные на микропотребление, и в то время когда они создавались достичь этого можно было только с помощью соответствующей архитектуры.
    В общем статью можно брать, разбивать на предложения и расписывать по каждому косяки =)

  12. Max :

    Я почему про СИ вспомнил, как-то с одним человеком разговаривал, мол говорю хочу мк научиться программмировать, асм немного знаю, а он мне в ответ:”Срочно бросай Асм и давай учи СИ, мол сейчас у мк памяти и так много, а асм раньше нужен был когда ее мало было, а сейчас все на СИ пишут!” Вот такой вот вышел разговор!
    Для начинающих MCS-51 может быть и пойдет?
    Ivan A-R, а Вы на каких еще форумах бываете, поговорить хотел насчет мк и их программироания!

  13. Алексей :

    Ребята, заходите поговорить на наш форум. - и нам веселее, и вам далеко ходить не надо :)

  14. Ivan A-R :

    Max, просто надо аппаратуру и язык подбирать под задачу, а не наоборот. Для PICов вообще вот BASIC есть с компиляцией в байткод, и ничего, и на нём вполне полезные вещи пишут =)

  15. Max :

    Ну, что пойдем в другую песочницу?.. )))))))))

  16. Max :

    Ivan A-R, спорить с Вами даже не берусь, потому что Вы человек более искушенный в этом вопросе!
    Вы можете какую-нибудь литературу посоветовать фундаментальную по микроконтроллерам для начинающих!

  17. ARV :

    Немного обидно, что некоторые граждане так резко и неверно раскритиковали мою статейку и меня самого. Прямо-таки хочется оправдаться: я в своей статье на своем сайте (выше есть на нее ссылка) вовсе не считаю злом все, кроме 51-ых контроллеров и прекрасно отдаю себе отчет о системе команд AVR и нацеленности PIC-ов. Я пытался на примере “забвения” 51-ых показать, как многие, не понимая сути, слепо хватаются за “килобайты, мегагерцы и такты”, а ведь это путь в тупик… Да, лично я люблю 51-ое семейство, прекрасно вижу его достоинства и недостатки, но при этом очень активно применяю AVR и ценю это семейство (хоть и не очень рад системе команд), не гнушаюсь и прочим (в основном, только цена меня останавливает, не архитектура). Так что если можно, возьмите часть критики обратно :)

  18. Степанищев Михаил :

    С автором статьи полностью согласен. Тоже наболело. Хотя можно еще многое добавить.

    Для ARV. Я прочитал Вашу статью. Вполне дельно и по существу. В нашей конторе применяются как 51 ядро, так и AVR (PIC-и не пошли - не те задачи, да и просто не нравятся :) ). Опять же, можно было добавить о существовании явных ошибок в AVR серии, которые приходится обходить всевозможными способами. На их фоне 51 ядро выглядит весьма надежно и стабильно. Да и количество наработанного и отлаженного кода под эту серию весьма велико.

    Не так давно тоже пришлось участвовать в дискуссии на близкую тему. Единственным реальным доводом оппонентов против нашей новой разработки было: “Фи-и, Вы используете устаревшее ядро”. Разбился, доказывая очевидное :(

  19. _Andrey_ :

    2рекомендую SpecEmu:
    На мой взгляд, лучший эмулятор Speccy для платформы Windows все же Unreal.
    Для линукса, увы, нет хороших эмуляторов. Лучшим наверное будет FUSE (не путать с file system in user space).

  20. dmitriy :

    Автор явно является “програмером в кострюле”, не видя ничего за пределами последней. Печальный пример, человека прекратившего работать над собой, и оставшегося в золотых “80-х”. Ех, где оно, славное время передирания микросхем IBM…. А сколько таких наверное и сейчас студентам нервы трепают

  21. Алексей :

    2dmitry:
    Вы это на кофейной гуще нагадали? Идите уже сдавать зачет по Visual Basic.

  22. dmitriy :

    to Алексей:
    читаем первый абзац:
    (Последнее время возникает стойкое ощущение, что компьютерный мир движется в каком-то неправильном направлении. Программы, функционал которых не так уж и значительно вырос со времен Windows 95, а то и DOS, отъедают львиную долю ресурсов наших компьютеров. А они таковы, что пару-тройку десятков лет назад они могли бы обеспечить вычислительной мощностью крупный НИИ. Ещё и программистам в Тетрис бы осталось поиграть).

    автор явно неимеет никакого представлении о сложности програмого обеспечения, и мало знаком с разработками в друих областях.
    Читаем:
    (Тем не менее, высокое искусство осталось. Оно по-прежнему процветает там, где ресурсы ограничены, а время как никогда реально.)

    А грубить некрасиво, мой пост не касался ни зачетов, ни Visual Basic-а

  23. Алексей :

    2dmitry:
    Хорошо, помахали шашками и ладно. Извините, если обидел, но Ваши выводы в комментариях тоже не совсем корректны.
    Предлагаю пойти поспорить предметно на наш форум, дабы не забивать комменты.

  24. Alex :

    Когда-то разрабатывал программу на ассемблере для дорожного контроллера (управление светофорами). Программа росла, росла, росла… Приходилось то подключать новое оборудование, то закладывать новые настройки, то еще чего нибудь… вобщем когда я увольнялся после семи лет работы, объем программы достиг ПОЛМИЛЛИОНА строк. Я сам уже не в состоянии был в ней разобраться, а с моим уходом им осталось только тупо программировать контроллеры несколькими заготовленными прошивками.

    Второй контроллер и почти все последующие устройства (еще на той же работе) писал на Си. Выходило намного быстрее и проще сопровождать. Объем занимаемый программой в микросхеме рос гораздо быстрее чем в ассемблере, но за то объем текста программы был на порядок меньше.

    Почти все - лишь из-за необходимости работать совместно со старыми программистами (если быть точным - программистками), которые Си так и не сумели освоить.

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

  25. Vladimir :

    2Alex :
    На Си, готов с Вами поспорить, проект не только легче читается-разрабатывается, но ещё и занимает меньше места (если по-умному писать, оптимизировать).

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

  26. Alex :

    ну так зачем же спорить - это как раз еще аргумент в пользу отказа от ассемблера ;)
    Вполне возможно что хороший компилятор так умеет. Мне к сожалению приходилось пользоваться тем что удавалось найти. От предложения купить нормальную среду разработки с компилятором Си у директора случился нервный тик, когда он услышал сумму 2000$ :)

Оставить комментарий

или