В Москве «наладили» производство российских банкоматов на процессорах «Эльбрус» — им занялась группа BFS Статьи редакции
Устройства на 80% состоят из отечественных компонентов.
- Группа компаний BFS «наладила» производство отечественных банкоматов в индустриальном парке «Руднево», заявил мэр Москвы Сергей Собянин. Производственная мощность предприятия позволяет выпускать до 15 тысяч устройств в год и может быть увеличена в два раза, отметил он.
- Банкоматы работают на базе процессоров «Эльбрус» и на 80% состоят из отечественных компонентов. Они могут бесконтактно считывать банковские или транспортные карты, штрихкоды или QR-коды. Устройства также оснащены биометрической камерой, которая позволяет выполнять часть операций без использования карт. О каких операциях речь — не уточняется.
- BFS уже получила предзаказы на 7000 банкоматов, рассказал Собянин, но не раскрыл подробностей. В июне 2022 года РБК писало, что крупные российские банки изучают возможность использования отечественных банкоматов на процессорах «Эльбрус». В их числе издание называло ВТБ, «Сбер», «Росбанк» и «Русский стандарт».
- В декабре 2022 года банкоматы собственного производства представил «Тинькофф». В банке заявили, что устройства спроектированы и собраны в России, но состоят как из отечественных, так и из иностранных комплектующих.
27K
показов
19K
открытий
Не знаю, что это за "диванные" эксперты, которые принижают Эльбрусы, но они не так уж и плохи. Вот обзор, где запустили Atomic Heart - https://www.youtube.com/watch?v=-0t-5NWk_1o
Да и сделаны они не для игр, бекдоров неизвестных нет, а это очень важно, как минимум, для оборонной промышленности. Да и затраты на создание этого процесса несоизмеримо ниже, чем у конкурентов, т.к. дотаций в этом направлении практически нет. Выше цена одного произведенного процессора, но это проблема объемов.
Если будут реальные аргументы, то готов подискутировать на эту тему.
Ну игра не CPU-bound, и там тормоза в комнате с парой врагов. Здесь на месте эльбруса может быть любой копеечный RISC процессор.
но они не так уж и плохиОни плохи, VLIW — это тупик, от которого все давно отказались, и который за пределами DSP давно не существует из-за неэффективности. Условный x86, арм или RISC-V процессор всегда будет потенциально эффективнее эльбруса просто за счет возможности спекулятивного исполнения и реордеринга инструкций (причина, по которой на момент выхода, Итаниум оказался медленнее даже современных ему x86 процессоров, которые уже научились в пайплайны как у RISC).
VLIW максимум годится быстро вектор на вектор перемножить, и то он здесь не даст особых преимуществ, ибо во всяких армах для этого просто отдельные инструкции есть.
Запуск игр это демонстрация возможностей исполнения кода ЧУЖОЙ АРХИТЕКТУРЫ, которая транслируется на лету, а не предназначение Эльбруса, его делали не для игр с x86 кодом
и который за пределами DSP давно не существуетА для военки как раз сплав проца с DSP и нужен, у них задачи по обработки данных загоризонтных радаров и прочее
Условный x86, арм или RISC-V процессор всегда будет потенциально эффективнее эльбруса просто за счет возможности спекулятивного исполнения и реордеринга инструкцийЭто бред, на анализ и реордеринг тратятся ресурсы, поэтому все наоборот, VLIW всегда потенциально эффективнее, там эта нагрузка переложена на компилятор, где выполняется один раз, а не постоянно делается в процессоре. Что сейчас у них пока проблема с хорошимм компиляторами не отменяет что в теории VLIW эффективнее. Компилятор не ограничен в ресурсах и может хоть неделю анализировать код на суперкомпьютере, который потом на VLIW будет выполнятся на порядки быстрее чем на x86.
Но компилятора такого ещё нет, не все сразу.
Что сейчас у них пока проблема с хорошимм компиляторами не отменяет что в теории VLIW эффективнее
Компилятор в принципе не способен эффективно реордерить инструкции и предсказывать ветвление, потому что для этого требуется динамическая информация. Для того, чтобы это понять, достаточно заглянуть в любой опенсорсный ЦПУ с пайплайнами, и посмотреть, как происходит реордеринг и предсказание ветвления.
Но компилятора такого ещё нет, не все сразу.Ага, VLIW существует уже 40 лет, в него вкладывали лярды всякие Интелы и без толку, а фантазеры все фантазируют о волшебном компиляторе, который насчнет эффективно набивать широкие слова статически.
А для военки как раз сплав проца с DSP и нуженДля военки во сто крат будет проще и эффективнее какой-нить проц с fpga, а чаще даже просто с векторными инструкциями или GPU. Оно и проще для разработчика, и унифицированнее, и дешевле.
FPGA по определению не могут быть "во сто крат эффективнее", они всегда сольют специализированному процу
FPGA хороши для прототипирования, но для прода это решение самое дубовое
как например майнеры сначала сидели на FPGA, но как только смогли сделать ASIC, то перешли сразу на них, потому что это небо и земля по эффективности
Для того, чтобы это понять, достаточно заглянуть в любой опенсорсный ЦПУ с пайплайнами, и посмотреть, как происходит реордеринг и предсказание ветвления.вы же там выше агитировали за "копеечный" RISC) а в нем все это максимально упрощено,
по сути VLIW это развитие RISC идеологии, их нельзя противопоставлять, как делаете вы
и архитектура VLIW предусматривает и аппаратные блоки для оптимизации выполнения, не только компилятор
VLIW это не специализированный проц, это general-purpose проц с статическим пайплайном инструкций. И да, FPGA даже с сильно более низкими частотами уничтожат VLIW на любых задачах тип сортировочных сетей, параллельной арифметики и всем том, чем VLIW в теории может щеголять перед обычным суперскалярным процессором.
вы же там выше агитировали за "копеечный" RISC) а в нем все это максимально упрощеноГде упрощено? Сейчас хорошие пайплайны с реордерингом и спекулятивным исполнением есть в долларовых микроконтроллерах.
и архитектура VLIW предусматривает и аппаратные блоки для оптимизации выполненияНаоборот, VLIW практически исключает спекулятивное исполнение, потому что блок, умеющий откатывать широкие слова будет архисложным, а штраф за неправильное предсказание ветвления будет чрезмерный.
Поэтому VLIW выполняет инструкции как есть, сливая в производительности суперскалярным процессорам десятилетней давности с допотопным техпроцессом.
я в курсе, тем не менее на специальных задачах, типа векторных вычислений, обработке сигналов, работы с графикой, они с большим отрывом уделывают и FPGA и CISC
Наоборот, VLIW практически исключает спекулятивное исполнение, потому что блок, умеющий откатывать широкие слова будет архисложным, а штраф за неправильное предсказание ветвления будет чрезмерный.нет не исключает, это следующий этап их развития,
Поэтому VLIW выполняет инструкции как есть, сливая в производительности суперскалярным процессорам десятилетней давности с допотопным техпроцессом.зачатки спекулятивного выполнения уже были в итаниуме, еще 20 лет назад
сливает только там, где он и не должен использоваться - на десктопах
но учитывая, что на декстопах и не требуется высокая производительность, ничто не мешает и там использовать VLIW в режиме эмуляции
Что? Нет, конечно. DSP уже почти вымерли и вытеснены GPU и FPGA. Я последний раз DSP трогал лет десять назад, когда GPU и FPGA стоили кратно дороже. Сегодня практически весь эмбеддед давно съехал с DSP.
зачатки спекулятивного выполнения уже были в итаниумеВ итаниуме как раз не было спекулятивного исполнения ни в каком виде, он был абсолютно 100% in-order процессором. Поэтому он сходу сливал в производительности не только спаркам и альфам, которые уже сто лет как имели пайплайны, но даже x86 того же времени, которые к тому времени в пайплайны научились.
сливает только там, где он и не должен использоваться - на десктопахПо этой логике он вообще нигде не должен использоваться, потому что в embedded можно взять арм с гпу который уничтожит vliw на любых числодробильных операциях за цену на пару порядков ниже.
причем тут вымерли и вытеснены, если речь шла о производительности?
В итаниуме как раз не было спекулятивного исполнения ни в каком виде, он был абсолютно 100% in-order процессором.ты сравниваешь мягкое и теплое
из статьи 20 летней давности
Другой ключевой особенностью IA-64 является предварительная загрузка данных. Она позволяет не только загружать данные из памяти до того, как они понадобятся программе, но и генерировать исключение только в случае, если загрузка прошла неудачно. Цель предварительной загрузки — разделить собственно загрузку и использование данных, что позволяет избежать простоя процессора. Как и в технологии "отмеченных команд" здесь также сочетается оптимизация на этапе компиляции и на этапе выполнения.Сначала компилятор просматривает код программы, определяя команды, использующие данные из памяти. Везде, где это возможно, добавляется команда предварительной загрузки на достаточно большом расстоянии перед командой, использующей данные и команда проверки загрузки непосредственно перед командой, использующей данные.
На этапе выполнения процессор сначала обнаруживает команду предварительной загрузки и, соответственно, пытается загрузить данные из памяти. Иногда попытка оказывается неудачной - например, команда, требующая данные, находится после ветвления, условия которого ещё не вычислены. "Обычный" процессор тут же генерирует исключение. IA-64 откладывает генерацию исключения до того момента, когда встретит соответствующую команду проверки загрузки. Но к этому времени условия ветвления, вызывавшего исключение, уже будут вычислены. Если команда, инициировавшая предварительную загрузку, относится к неверному пути, загрузка признается неудачной и генерируется исключение. Если же путь верен, то исключение вообще не генерируется. Таким образом, предварительная загрузка в архитектуре IA-64 работает аналогично структуре типа TRY-CATCH.
По этой логике он вообще нигде не должен использоваться, потому что в embedded можно взять арм с гпу который уничтожит vliw на любых числодробильных операциях за цену на пару порядков ниже.
причем тут embeded?
давно суперкомпы стали embeded?
У FPGA и GPU производительность в разы если не на порядки выше, чем у VLIW. У современных Mali на ядро пиковых флопсов больше, чем у Эльбруса 8с целиком на в два раза больших частотах.
из статьи 20 летней давностиЕдинственное, что в свое время давало DSP какую-то нишу — высокие цены на FPGA и GPU решения.
Где здесь хоть слово про спекулятивное исполнение?
давно суперкомпы стали embeded?Ниша эльбруса — суперкомпы? В суперкомпах бал уже давно правит GPU, там у него вообще нет шансов.
ты бы еще с КР580ВМ80А сравнил
Где здесь хоть слово про спекулятивное исполнение?я написал про "зачатки спекулятивного выполнения",
предварительная загрузка данных для команд стоящих после ветвления, условия для которых еще не вычислены, к этому относится
В суперкомпах бал уже давно правит GPU, там у него вообще нет шансов.делают на том, что есть, или ты знаешь какие-то VLIW процессоры на современных тех нормах?)
GPU так-то не для суперкомпов разрабатывались, просто на таких задачах CISC совсем им сливают, и заменяют тем, что есть
и уж явно там не на FPGA делают, как ты предлагаешь)
Предлагаю тебе определиться уже, в какую нишу ты пытаешься определить это VLIW недоразумение.
предварительная загрузка данных для команд условия которых еще не вычислены к этому относитсяНет, конечно. Спекулятивное исполнение — это исключительно про исполнение условных команд до проверки условия, и про умение эти команды откатывать в случае миспредикшна.
Просто подгружать команды заранее — это не проблема и в этом нет никакой сложности (или выгоды по части производительности), сложность в том, что делать с тем, что наисполнял, когда бранч оказался неверным.
делают на том, что есть, или ты знаешь какие-то VLIW процессоры на современных тех нормах?Ммм, интересно, почему так, ведь, как ты утверждаешь, VLIW может посоперничать с ГПУ и ФПГА в производительности. Наверное, потому что VLIW — это тупик, и идустрия пошла по очевидно более эффективному пути: суперскалярный проц + векторные числодробилки при необходимости.
и уж явно там не на FPGA делаютНу вообще-то делают, интел делает процессоры для числодробления c fpga для серверов, датацентров и проч., и поддерживает их в своих OpenCL драйверах, так что OpenCL код может исполняться на их процах что с GPU, что с FPGA
для специализированных задач, под которые можно вылизать алгоритмы
VLIW это можно сказать просто максимальный простой процессор, у которого есть доступ к микрокоду, а он не зашит внутри, и при правильном ПО ты сможешь получить максимально возможную производительность из куска кремния при заданных технормах
Просто подгружать команды заранее — это не проблема и в этом нет никакой сложности (или выгоды по части производительности),я писал не про подгрузку команд, а про подгрузку ДАННЫХ для команд, которые еще может и не будут выполнятся
и конечно выгода от этого есть, изучай что такое кэш, их уровни и времена доступа к данным
Ммм, интересно, почему так, ведь, как ты утверждаешь, VLIW может посоперничать с ГПУ и ФПГА в производительностиэто не я утверждаю, это тупо факты, посмотри производительность например i860 в графических задачах и сравни с графическими процами того времени
что для мейнстрим это не зашло, ну бывает, тем не менее Итаниумы выпускали целых 20 лет, значит спрос на них был и задачи под них были
Ну вообще-то делают, интел делает процессорыв TOP 10 нет ни одного супер компа на FPGA, а ведь FPGA в 100 раз эффективнее, как ты утверждаешь)
даже не знаю кому верить, спекам Интела, или тебе
наверное все же Интелу, который говорит, что спекулятивное исполнение веток в итаниумах было)
как и спекулятивная загрузка данных
Инструкции на слайде не имеют отношения к спекулятивному исполнению, как оно понимается применительно к суперскалярным процессорам. ld.s и chk.s выполняются in-order и всегда. ld.s просто инициирует чтение, а chk.s его прерывает, либо дожидается выполнения.
Процессор с OOE пайплайном же может выполнить инструкции чтения под бранчем, а может и нет, и делает это он на основе динамических данных об исполнении (например, частоте перехода по бранчу в тайтлупе).
Более того, OOE процессор может выполнить несколько чтений, он может поменять их местами, если ему так удобнее, он может чередовать их с также спекулятивно исполняемыми арифметическими операциями и реордерить в зависимости от того, какое чтение выполнилось раньше (например из-за доступности значения в кэше).
На слайде литерали причина провала итаниума, потому что откуда компилятору неоткуда знать, в каком порядке и как начинать подгружать значения из памяти. Гцц по дефолту даже не использует эти инструкции.
ну да, в Интел же дурачки и просто так назвали это спекулятивным))
На слайде литерали причина провала итаниумаопять же, дурачки из Интела целых 20 лет не могли понять этого и все клепали итаниумы) которые почему-то покупали)
причины провала только в маркетинге и позиционировании как процессора общего назначения, а не для специализированных вычислений, где его ниша