Особенности программирования БВК АМС

[bs]

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

Векторный код на С++:

    Matrix A = ( B * C ).T() * V;

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

[Artemkad]

Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров.

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

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

[goran d]

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

Векторный код на С++:

    Matrix A = ( B * C ).T() * V;

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

Ну если изпользовать библиотеку , можно ето делать и на ассемблере. Будет просто передача адресов в реестры и вызов подпрограмы.

[Artemkad]

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

Векторный код на С++:

    Matrix A = ( B * C ).T() * V;

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

А ты поиграйся с разными типами матриц и полюбуйся НАСКОЛЬКО разный код будет получен. Причем скорость будет часто разная на порядки.
ЗЫ. А еще попробуй скомпилировать это добро "специальной библиотекой" для 8-разрядного AVR-а. :twisted:

[bs]

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

Ну это вас жестоко развели! :wink:

Теперь представьте, что в ФГ нашли ошибку за 10 минут до сеанса, а средства создания образа, который нужно срочно загрузить в ФГ, смогут сгенерировать этот образ через полчаса. Или вариант, когда нужно загрузить очень короткий код, без всяких ОС, страниц памяти и прочего, просто код, который сразу, без всяких долгих инициализаций, запустит двигатели. Остается только один путь  - править сам образ или создать этот короткий машинный код. Так что коды есть и будут присутствовать в таких системах, пока процессоры не научатся исполнять язык высокого уровня напрямую  

Да в текущей ситуации я скорее поверю, что им надо будет сначала загрузить туда 4Мб более свежей виртуальной машины  :lol:

[Unispace]

. Разобраться в таком коде на порядки проще, чем в куче спец инструкций. Сделать ошибку - на порядки сложнее.

Не в защиту асма, но такое ощущение, что вы не в курсе, что такое макроассемблер и библиотека функций  

[Unispace]

.
Ну это вас жестоко развели! :wink:

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

[Вадим Семенов]

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

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

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

Можно конечно взять в скобки try-catch каждое место, где потенциально может быть эксепшен, а так же перехватывать его на всех вышележащих уровнях вложенности вызовов подпрограмм, но это практически то же самое, что передача и анализ кода ошибки.

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

[Not]

А вот скажи, 128 битное суммирование на 8 битной машине в Си - исполнении не пробовал? А многобитную криптографию на циклических сдвигах? Но ведь это все простейшие операции при возможности работы с битами состояния процессора (на Асме)!

А зачем нам рассматривать 8-битные машины, когда давно летают 32-битные? Тенденция такова, что ресурсов становится больше, а программирование на аппаратном уровне - сложнее.

Если же ну очень нужно выжать все из архитектуры конкретного контроллера - ну пожалуйста, используйте вставку _asm_ . Но зачем всё корячить на ассемблерной коленке?  

[bs]

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

Вот именно, а компилятор сделает и сэкономит 1-2% в объеме исполняемого кода.

[Вадим Семенов]

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

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

[bs]

Не в защиту асма, но такое ощущение, что вы не в курсе, что такое макроассемблер и библиотека функций  

Знаю даже слишком хорошо. Неужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее.

Глупость просто какую-то сказали Вы просто не знаете специфики, иначе все встало бы на свои места.

Да я понял. Это была шутка.

[Вадим Семенов]

- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.

Ну уж прям.   Некоторые подпрограммы там наверняка на ассемблере. А возможно и ассемблерные вставки в самом коде на модуле-2

[Unispace]

Точность результата при арифметических операциях легко определяется статически компилятором исходя из точности операндов.

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

[zyxman]

В общем, все это не имеет прямого отношения к БВК АМС.

Экономика и управление ресурсами страны имеют САМОЕ прямое отношение к АМС. Потому что АМС это проекты, находящиеся на САМОМ переднем крае возможностей научной и технологической инфраструктуры страны, а также АМС ПРЕДЕЛЬНО зависят от качества управления и чуть меньше от финансовых возможностей страны.

Теперь что такое я называю нормальными странами.
Буквально я называю нормальными страны где достаточно сильный капитализм.

Капитали
зм — экономическая система производства и распределения, основанная на частной собственности, всеобщем юридическом равенстве и свободе предпринимательства.

Более конкретно я предпочитаю такое: в капитализме действует свободное движение капитала - КАЖДЫЙ может СВОБОДНО заработать капитал, а также СВОБОДНО его продать/обменять/сдать в аренду итд.
И вот стран где достаточно большой процент СВОБОДНОГО капитала и являются нормальными, и таких стран в мире совсем мало - это буквально ТОЛЬКО G7 список примерно 1990 года.
Достаточно большой процент начинается где-то от 20%.

Строго говоря, абсолютной свободы капитала нет нигде в мире, тк очевидно космос пока вне рассмотрения, а в нейтральных водах законы действуют недостаточно надежно, а на территории государств всегда есть ограничения.
Например, практически везде есть очень большие ограничения по работе с радиоактивными материалами и прочими опасными технологиями.
НО конкретно механизмы самых ключевых вещей - земля+недвижимость (ДА ОНИ ОБЯЗАТЕЛЬНО ВМЕСТЕ!!!), а также производство материальных и нематериальных товаров, и управление ресурсами страны в нормальных странах действуют предельно эффективно.

Конкретно у нас сейчас не капитализм, а НЕОФЕОДАЛИЗМ.

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

Отличие неофеодализма от простого феодализма в наличии ФОРМАЛЬНО ЗАДЕКЛАРИРОВАННЫХ, НО НЕ РАБОТАЮЩИХ частной собственности, свободы и равенства. Таким образом оказывается что государственные чиновники становятся феодалами, потому что они могут решать вопросы, которые законным путем не решаются и поэтому они находятся над законом.

[dmdimon]

Неужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее

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

[dmdimon]

извините, был дубль

[Not]

Неужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее

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

Profiler вам в помощь  :wink:

[bs]

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

Нет, это просто прекрасно!

Вы мне напомнили мой давний диалог с одним очень бородатым и очень умудренным опытом программистом на FoxPro, который руководил отделом ИТ в Русславбанке и в частности был отцом их системы банк-клиент по состоянию на 2006-й год. Я тогда регистрировался как ИП и подбирал банк для расчетных счетов. Будучи человеком не далеким от ИТ я естественно расчитывал никак не меньше, чем на нормальную систему управления счетами по инету. Так вот, когда я засыпал операционистку вопросами по банк-клиенту, она просто отвела меня в ИТ отдел и отдала его мне на растерзание. Там мне с ярким пламенем в глазах рассказали про их уникальную систему. Клиент на FoxPro, работавший в dos-box'е, все распоряжения сгружал в папку в виде email, подтверждения операций также приходили обратно по email. Далее в работу вступал замечательный почтовый клиент The Bat!, который требовалось запустить, потом импортировать в него сгенерированную банк-клиентом почту, отправить ее, дождаться ответной почты, экспортировать ее в папку банк-клиента и выполнить синхронизацию в последнем, чтобы увидеть, что же там в итоге получилось. Оценив невероятный успех коллектива, я задал всего два вопроса: "Что за х@#я?" и "Где нормальный веб-клиент?" Если бы у меня была с собой хотя бы отвертка, я бы высек ответ в гранитном полу прямо у них в ИТ-отделе. Потому что поучительным тоном бородатый начальник сообщил мне: "Молодой человек, если бы вы хоть немного бы разбирались в теме, то вы бы знали, что страницы в интернете не позволяют записывать данные". 2006-й год :shock:

В общем блестящий пример, как один страшный порок рождает другой, еще более страшный, асболютно незаметно для жертвы :lol:

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

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

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

[dmdimon]

Profiler вам в помощь  :wink:

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

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