IT в России и мире в реалиях мирового кризиса

Цитата: Senya от 17.12.2016 15:56:19В 80-х словосочетание "система реального времени" было наверное так же популярно, как сегодня "нанотехнологии". На самом деле таких систем полно, большинство промышленных обеспечивают время реакции в миллисекунды, специализированные в микросекунды при сотнях запросов (если не ошибаюсь, у нас на форуме кто-то хвастался). Но вот такое чтобы ОС, чтобы ставилось на любое популярное железо и обеспечивало подключение пользовательских модулей без потери характеристик - и правда не знаю. Может и есть конечно, но никогда сталкиваться не приходилось.

Цитата: DarkRaider от 18.12.2016 02:32:05Давайте, для начала попробуем найти на просторах России коммерцию, которую беспокоит "информационная безопасность", от наших "партнёров"?

ЦитатаИдут длинным путём.

Цитата: DarkRaider от 18.12.2016 02:32:051) Коллега, не будьте столь пессимистичны, уверяю Вас, никто не будет производить процессор, для "фич" которого ещё не продуманы механизмы управления и программирования. Платформа разрабатывалась вполне правильная, документация тоже готовилась правильно. Просто её не собираются "распространять" в непрофильные учреждения ближайшие лет...  ндцать. Я понимаю, что "дух повсеместной свободы" свил крепкое гнездо в ваших суждениях, Вы, в упор, не желаете признавать того факта, что не все вещи в этом мире должны быть "открыты мировому сообществу".

Цитата: DarkRaider от 18.12.2016 02:32:05Не в основе САПР, а в основе НАШИХ РАСЧЁТНЫХ МОДУЛЕЙ для САПР, действительно лежат библиотеки с правильными математическими моделями, эти модели действительно разрабатываются уже очень давно и серьёзно.

Цитата: DarkRaider от 18.12.2016 12:43:36Доклады Вам будут продолжать делать потому, что это часть информационной политики, всем хочется побольше "политических плюсов"

Цитата: Поверонов от 17.12.2016 15:24:32Ощущается настоятельная необходимость в операционной системе реального времени для управления реальными процессами, чтоб работала без зависаний. Поле применений растет на глазах - и роботы, и транспорт, и станки, да даже и старые десктопы или тачпэды - зависания  и там случаются нередко, и ОС РВ наверное была б уместна и на рабочих местах. К сожалению о таковых новых разработках не слышно. Все летают в "облаках", но там лишь управление ресурсами и конфигурациями - а новых ОС идей нет.

Цитата: adolfus от 18.12.2016 12:07:12Отмазка. Гнилая отмазка... 
останется мелкосерийным нишевым процессором для подводных лодок и золотых винтелов для верхней чиновничьей братии. Но тогда не понятно, какого МПХ о нем так трубят на всех углах

Цитата: Yuri__1964 от 18.12.2016 21:11:07Если ставить задачу сделать ради принципа то так сможет сделать любая развитая страна.

Цитата: DarkRaider от 18.12.2016 13:10:39Вы, коллега, сами то застали эти времена?  ходили по такому залу?  Работали за "терминалом" (да да...   самостоятельным терминалом, коих могло быть не один десяток на 1 "компьютер", в современном понимании этого слова).  Смогли бы сейчас "на гора" написать программу расчёта бюджета какого нибудь небольшого завода уложившись в 64 Килобайта доступной оперативки?

Цитата: Поверонов от 19.12.2016 08:46:07там даже СУБД была ingres - "папа" нынешней postrgres 

Цитата: ЦитатаPostgres (Post Ingres; позже развился в PostgreSQL), несмотря на своё название, не основан на Ingres.

Цитата: DarkRaider от 19.12.2016 09:45:40Это очень распространённая иллюзия.  Во первых сам компилятор ничего никому не должен, потому как логика распараллеливания процессов, зачастую превышает доступный набор "первоначальных шаблонов", которыми он может оперировать. Вообще, на что только не возлагали почётную обязанность управления ходом процессов и на аппаратные средства, и на операционки и на волшебные "блоки предсказания" в камнях. Теперь вот - оказывается это компилятор должен решить. Может для начала стоит задуматься, все ли задачи стоит "распиливать"?  Стоит ли их распиливать между ядрами или интереснее  чтобы каждое ядро просто эффективно выполняло свой код (да, придётся аппаратно решать проблемы совместного доступа к аппаратным ресурсам  - но это уже далеко не новая задача, и в общем уже хватает инструментов и механизмов). Ещё раз задумайтесь над областями применения и попробуйте мысленно присовокупить сюда понятие мажоритирования. А если заглянуть в учебник по теории управления процессами, можно выяснить что далеко не каждая вычислительная задача вообще решается с помощью параллельных вычислений.   Можете глянуть на современные игрушки, уж сколько лет в игровом сегменте прижились многоядерные процы, а использовать все доступные ядра по нормальному - могут единицы.

  Не понимаю, почему то эта тема про vliw  так будоражит умы страждущих. То что каждый вечер, под пивко в вашем мониторе графическая карта рисует какой нибудь WOT  - никого не смущает.  Просвещённые вспомнят всякие CUDA и OpenCL  и ничего... "компиляторы как то справляются"? Не так давно в этой ветке даже всякие стойки и фермы упоминались....  Вычисления на GPU,  пуперкомпьютеры там всякие...  алгоритмы в 2000 потоков...    Принципы те же, аппаратная реализация - это вопрос технарей, а не программистов. К слову даже, видеокарточки были некоторые построены на этой же архитектуре.

Цитата: adolfus от 17.12.2016 01:12:53Эльбрус -- это VLIW
Эта архитектура никогда не взлетит, как x86_64. Она требует совершено другого подхода в программировании. Все алгоритмы нужно пересматривать с учетом параллелизма и переписывать заново и полностью. Насколько я знаю, в команде нет людей, которые фамильярны с фортраном настолько, что могут написать оптимизирующий компилятор для Эльбруса. А это тот самый язык-гигант, на котором стоит вся вычислительная математика. И пока они этого не сделают, все их попытки взлететь ни к чему не приведут.
Вся эта эмуляция x86, обезьянничанье с южным мостом, с присобачиванием игровых ГПУ -- это просто блуждание в трех соснах. Никому не нужна графика, если нет нормальной поддержки вычислений. Сливать вычислительные мощности в картинку -- нет ничего тупее.
Итаниум загнулся потому, что все хотели просто взять написанное давно уволенными программистами, пересобрать под новую архитектуру -- для этого даже таблицу умножения и дроби знать не надо -- и получить нахаляву заявляемый выигрыш в производительности. А не тут то было -- чтобы получить этот самый выигрыш в требуемой мере на прикладных программах, нужно иметь компиляторы, загружающие конвейеры на все сто процентов. Причем компиляторы не с говноязыков, типа крестов, диеза или жавы, а в первую очередь с кобола и фортрана, потому что на крестах, диезе и жаве ничего кроме говноинтерфейсов и хелловордов не написано. В основе всех САПР лежат библиотеки, написанные сорок лет назад на фортране и до сих пор не нашлось никого, кто бы взялся переписать хотя бы линейную алгебру с фортрана и не обосрался.
Так что если МЦСТ не найдет сил собрать команду людей, способных переплюнуть интеловскую параллельную фортран-студию, у них ничего с Эльбрусом не получится -- народ предпочтет за те же деньги купить полдюжины x86_64 и не париться с проблемами. Каждый год на НСКФ их представителей спрашивают об этом и каждый год они мычат на сей счет нечто невразумительное. Люди просто пилят бабки -- ставят чиновникам на столы золотые эмуляторы винтела на волне импортозамещения. При том, что архитектура очень перспективная.
Второе -- до сих пор недоступна детальная информация ни об архитектуре, ни о применении. Никто не знает ни архитектры, ни как работает планировщик --только презентации для эффективных менеджеров. когда-то случайно посетивших лекции по архитектуре и помнящих, что такое стек и что в байте восемь бит.  Каждый год говорится, что "мы почти готовы выложить пятнадцать тысяч страниц мелким шрифтом", но воз и ныне там.
Чтобы взлетел Эльбрус, МЦСТ должен:
1) выложить все, что может понадобиться разработчикам системных плат, операционных систем, компиляторов и прикладного софта. Просто взять и выложить в интернет все, что у них есть полезного для разработчиков, как это делают интел и амд -- бери кто хочет.
2) сделать несколько простых дешевых системных плат, имеющих на борту два процессора, APIC, вменяемый набор интерфейсов, и предоставить их на льготных условиях университетам и колледжам, чтобы те могли использовать это в учебном процессе.
3) влиться в проект к Торвальдсу и выпускать под ним ядро под свою архитектуру -- фактически они должны отдать ядро сообществу и обеспечить ему возможность его разрабатывать и тестировать.
4) открыть и отдать сообществу планировщик загрузки конвейеров и генератор кода для gcc. Это отчасти снимет проблему с фортраном, адой и с доверием к архитектуре -- никому не усралась архитектура за несколько штук баксов, для которой нет элементарного, пусть даже референсного утилитария.

И тут промедление смерти подобно -- интел купил альтерру и собирается производить мультиядерные системы, оптимально конфигурируемые под конкретную задачу -- время конфигурирования ПЛИС сейчас на порядок меньше, чем загрузка и связывание программы. Для справки -- около 97% площади кристалла нанимают кеши и система управления. Остальные 3% приходится на АЛУ и регистры, из которых опять же в каждый момент используется менее 5%.

Цитата: DarkRaider от 19.12.2016 16:52:41Позвольте, какие же мне нужно сделать из этого выводы?
 Как работает и5?
 Как крут АРМ?
 Как Вы написали видеокодер?
 
 Давайте уж  "взлетим на метр над уборной" и обсудим "параллельную" реализацию онлайн-видеокодека?  (тот который кодирует поток в режиме приближённом к режиму реального времени).  А с процессорами можно таки вообще не мелочится - может сразу Spartan 7 от Xilinx?

Цитата: михайло потапыч от 19.12.2016 17:10:38Вывод такой.
Факторов, влияющих на производительность программы множество.
Но архитектура процессора очень важна для способности компилятора оптимизировать код.
Грубо говоря, чем меньше инструкций знает процессор, тем проще оптимизировать под него.
В этом смысле архитектура x86 самая громоздкая.

Цитата: Senya от 19.12.2016 17:14:42Можно и с точностью до наоборот интерпретировать. Без оптимизации Интел теряет 2/3 производительности, а АРМ все 90%. И у кого хуже архитектура?
Или ещё - базовые настройки компилятора больше соответствуют архитектуре Интел, чем АРМ.
Вобщем, сам по себе этот пример ни о чём.

Цитата: михайло потапыч от 19.12.2016 18:46:28Более простые архитектуры типа АРМ легче поддаются при оптимизации кода (более предсказуемы).

Цитата: adolfus от 17.12.2016 01:12:53Эльбрус -- это VLIW.... Насколько я знаю, в команде нет людей, которые фамильярны с фортраном настолько, что могут написать оптимизирующий компилятор для Эльбруса ...

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

Цитата: ps_ от 19.12.2016 20:45:17Изначально дискуссия была о том, как внедрять Эльбрус для ОБЫЧНОГО пользователя. И было утверждение , о том, что он, на данный момент времени по соотношению цена/производительность, которая определяется его архитектурой,  обычным пользователям не нужен.

Цитата: Senya от 19.12.2016 20:53:58Не совсем так. Или совсем не так, смотря с какой стороны смотреть
Я понял изначальный вопрос как то, нужен ли Эльбрусу для развития обычный пользователь. С выводом, что не нужен. Его задачи - защита государственной информационной инфраструктуры.