Да чо им там выгодно? Гляньте на фото системной платы этого "Ыльбруза": кроме процессора и отечественных (может быть) разъемов там еще хренова туча транзисторов и периферийных микросхем западно-китайского производства. Даже беглый вгляд легко читает логотип "Марвел" на сетевом чипе, к примеру. Заипуцца в МЦСТ организовывать производство аналогов всех этих компонентов и технологий.

(Reply to this) (Thread)

Закупят через Кампучию, если что. И впарят за цену, какую захотят.

хехе

(Reply to this) (Parent) (Thread)

Северо-корейская модель развития(?). Чучхе. Извините - это я чихнул: холодно сегодня что-то.

(Reply to this) (Parent) (Thread)

:)

(Reply to this) (Parent)

а зачем? те-же пиндосы всё в кетае закупают. кетай - базис мировой микроэлектроники. не нравица надпись марвел - говно вопрос! какая нравица?

(Reply to this) (Parent)

ПК "Эльбрус" я бы купил. Стопудово. Если бы были такие деньги под рукой.

(Reply to this) (Thread)

Это буржуазный эстетизм.
хехе

(Reply to this) (Parent) (Thread)

Да! Эстетизм! Но не буржуазный а как раз пролетарский!
Это памятник который правнуки моим праправнукам показывали бы!

(Reply to this) (Parent)

Для Кунсткамеры?

(Reply to this) (Parent)

Интересно что МЦСТ похоже избегает указывать производительность своих вундервафель в MIPSах, везде даются только FLOPSы, если вы понимаете о чем я говорю... =)

(Reply to this) (Thread)

А можно пояснить нубам? :)

(Reply to this) (Parent) (Thread)

Э ты давай в патриотичный угар впадай!

(Reply to this) (Parent) (Thread)

тьфу на тебя! я правда нуб :((

(Reply to this) (Parent) (Thread)

Стоять! Казачий кибер-патруль! Младший Инспектор Чебурнет Троехуев!

(Reply to this) (Parent)

FLOPS - floating point operations, каждый раз когда Вы на калькуляторе нажимаете на кнопку РАВНО, Вы совершаете подобную операцию. Большинство компьютерных программ содержат то или иное количество таких операций. Математические программы (модели погоды, обработка экспериментальных данных, навигация) содержат их много, другие программы (обработка текстов, музыки и, как не странно, проигрывание видео и аудио) содержат таких операций мало.

MIPS - million instructions per second, каждый раз когда микропроцессор делает шаг по программе, он исполняет инструкцию. Этот шаг может быть floating point operation, а может и не быть (см. выше). На простых архитектурах, где каждый шаг занимает один такт (MIPS, ARM), значение MIPS примерно соответствует тактовой частоте (1GHz => ~1000MIPS). На суперскалярных архитектурах (x86) MIPS может превышать тактовую частоту в 2-4 раза.

Так вот, МЦСТ чудесным образом избегает говорить нам сколько настоящих инструкций их изделие исполняет в секунду. Нам рассказывают лишь о том, сколько чисел с запятой может вычислить их "калькулятор".

(Reply to this) (Parent) (Thread)

На простых архитектурах, где каждый шаг занимает один такт (MIPS, ARM),

Чито?

(Reply to this) (Parent) (Thread)

да просто кривая и сильно упрощенная формулировка я думаю

а так то если один поток, то за один такт - одна команда, хотя есть команды которые выполняются за несколько тактов.

(Reply to this) (Parent)

Вы всерьез самый умный и хотите углубиться в детали команд LDR, MULL или количества циклов ожидания при чтении из разных видов памяти?

Или попиздеть пришли?

(Reply to this) (Parent) (Thread)

Я призываю Вас к точности.
Например, так: "Соотношение производительности программ и MIPS сильно зависит от архитектуры процессора, в частности, от степени и способа параллелизации вычислений"

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Вы знаете, я долго проработал с людьми, разрабатывавшими проект Эльбрус, и этот аргумент слышал неоднократно. Они пиздят.

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

(Reply to this) (Parent) (Thread)

Вы знаете, я долго проработал с людьми, разрабатывавшими проект Эльбрус, и этот аргумент слышал неоднократно. Они пиздят.

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

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

Зависит от data locality, однако. Но для широкого класса программ верно.

(Reply to this) (Parent) (Thread)

Существует такой компилятор, например у Интела (тоже VLIW архитектура, хотя и не такого размаха). Просто если распараллелить код нельзя, то ни один компилятор его не распараллелит. И выясняется что в реальной жизни (за пределами специальных тестовых случаев) распараллелить обычно удается немного. Именно поэтому чудесный VLIW x86 исполняет в среднем 1-2 инструкции за такт, а не 4, как рекламируется.

Но все это снова за пределами дискуссии. В рамках дискуссии, интересно было бы узнать, исполняет ли тот Эльбрус хотя бы одну инструкцию за такт =)

(Reply to this) (Parent) (Thread)

. Просто если распараллелить код нельзя, то ни один компилятор его не распараллелит.

А на это сторонник Эльбруса ответил бы Вам что, хотя возможности распараллеливания програм написанных на C/C++, ограничена частично самим языком, а частично сложившимися традициями кодирования, будущее за языками вроде Эрланга и Хаскеля, допускающими глубокую параллелизацию. После чего беседа плавно переместилась бы в область научной фантастики ближного прицела.

В рамках дискуссии, интересно было бы узнать, исполняет ли тот Эльбрус хотя бы одну инструкцию за такт =)

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

(Reply to this) (Parent) (Thread)

Я уже давно научился не обращать внимания на полоумных адептов мертвых языков. Но если это так важно, то data dependency graph никак не зависит от языка программирования. Если в нем для вычисления A надо знать B и C, то хоть на арамейском пиши.

(Reply to this) (Parent) (Thread)

Благодарю за интересный тред дискуссии. Эх, чому я не программист... :(

(Reply to this) (Parent) (Thread)

Лайк

хехе

(Reply to this) (Parent)

(Reply to this) (Parent)

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

Что дальше?

А дальше создадут четвертое поколение Эльбруса.

Если отсчитать назад от современного.

(Reply to this) (Thread)

В этом и главный вопрос: успеем ли?
хехе

(Reply to this) (Parent)