Персональные компьютеры Эльбрус-401 готовы к серийному производству

Ну тактовая частота она потому и тактовая, что про то, сколько тактов делает в секунду, а MIPS это миллион инструкций в секунду.

Атом (и старый кор 2 дуо «почти») как видно не могут жрать одну инструкцию за такт (видимо куча чтений из памяти), эльбрус и сендибридж показывают чуть больше MIPS чем их частота, что говорит о том что их ширины действительно хватает, однако четкая зависиимость видна как раз от тактовой частоты а не от ширины.

Всё жду от тебя, когда ты признаешь, что Эльбрусу не хватает тактовой частоты, чтобы конкурировать на задачах с низким ILP.

А к чему мне это отдельно признавать если это и так понятно?
И 7z и другие бенчмарки архивации как никто другой это подтверждают.

Ну тактовая частота она потому и тактовая, что про то, сколько тактов делает в секунду, а MIPS это миллион инструкций в секунду.

Если процессор в два раза шире, то он делает в 2 раза больше операций.

Если процессор работает на вдвое большей частоте, то он делает в 2 раза больше операций.

Атом (и старый кор 2 дуо «почти») как видно не могут жрать одну инструкцию за такт (видимо куча чтений из памяти), эльбрус и сендибридж показывают чуть больше MIPS чем их частота, что говорит о том что их ширины действительно хватает, однако четкая зависиимость видна как раз от тактовой частоты а не от ширины.

Так я же это и написал. =\

А к чему мне это отдельно признавать если это и так понятно? И 7z и другие бенчмарки архивации как никто другой это подтверждают.

К тому, что на задачах с более низким ILP чем в 7z, Эльбрус будет хуже чем D2500. Вот когда (если) Эльбрус будет сопоставим по частотам с i7-2600, он будет такой же быстрый на этих задачах, а на высоком ILP будет быстрее него.

Во первых правильнее было бы написать «дотянулись до ядрышка первого поколения кор2 на такой же частоте», во вторых другие тесты там нечестные, в криптографии там куча смешанных вычислений которые можно на всю ширину развернуть, а java/javascript там первый студенты за полгода собрали openjdk а второй интерпритатор меряют с jit ом.

А 7z это именно такого рода тест где эльбрус будет сосать из за своей частоты и ширина ему не поможет.

А 7z это именно такого рода тест где эльбрус будет сосать из за своей частоты и ширина ему не поможет.

Я рад, что ты прозрел. Трезвый взгляд на положение вещей, никому не повредит.

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

Можно. Китай это сделал только что. Им потребовалось желание и 30-40 лет, чтобы из страны с голой жопой превратиться (по крайней мере в городах) чуть ли не во вторую Японию. Они уже даже внутренний рынок начали осваивать, причём продукцией более высокого качества, что сами продают на сторону.

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

С точностью до наоборот. Догоняющий видит грабли, на которые наступал предшественник, может использовать более совершенное оборудование. В производстве микросхем это менее заметно, потому что оборудование очень дорогое и штучное. Во всём более динамичном это отлично видно. Начиная от сланцевой нефти (сравните компании, начавшие работать в 2000-2005 и в 2010-2015) и кончая телекомами. Не верите - гугл в зубы и вперде.

и на огромную гражданку раньше работало

Да не работало оно. Во времена NES у нас можно было лишь клон PONG купить. И то - хрен достанешь. К концу 80-х - клон спектрума в разборе. И тоже - ещё поискать нужно. Разве что «ну погоди» массово выпустить сумели. И то, когда у японцев уже gameboy пошли. СССР совершенно не использовал экономический потенциал гражданской электроники.

А ты предлагаешь теперь спустится еще на уровень ниже

Я предлагаю не страдать хуйнёй. Особенно всем. Тот же МСЦТ (С - знаете что там значит?) Всё равно склонировал SPARK. И всё равно топовые кристаллы свои делает не у нас. И не ясно, сумеют они поднять VLIW или нет. Т.е. это не компания, которая будет комерчески успешной и станет приносить деньги владельцам и стране, а компания, которая ещё десятки лет будет тянуть в себя деньги, как в чёрную дыру. И в конце скорее всего результата не будет.

какая нибудь молодая развивающаяся компания типа YotaDevice пускай так делает

Т.е. вы предлагаете нам пофапать на то, что компания «БабаянЪ и сыновья» такая древняя и развивает отечественную электронику аж «съ 1980 года»?

но государственные деньги выливать сюда преступление и глупо.

Действительно, давайте выливать их в компанию, которая делает сомнительный по перспективности продукт, которая даже не делает толком вид, что когда-нибудь станет самостоятельной и перестанет зависеть от госзаказа, которая производит суперзащищённый продукт, который всё равно на 80-90 процентов состоит и иностранных компонентов, но стоит, как макбук. Да, давайте. На х@й! Нет, вот на х@й!

Можно. Китай это сделал только что. Им потребовалось желание и 30-40 лет

Ну давай, продолжай - ещё им потребовалось наличие кучи готовых фабрик под руками (построенных не на деньги китайцев), гора денег на R&D, доступ до технологий в стиле «кладём на копирайт» и законодательство, позволяющее открыть фирму по производству чего-то за срок до одной недели.

У нас такое не взлетит, но перечисление причин этого улетит по 5.1, 5.3 и нацполу.

Тот же МСЦТ (С - знаете что там значит?) Всё равно склонировал SPARK.

МЦСТ, SPARC.

У нас такое не взлетит

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

МЦСТ, SPARC.

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

Забыл добавить:

И не ясно, сумеют они поднять VLIW или нет.

Аппаратно - может быть.
Но у VLIW (точнее даже EPIC) есть родовая травма:
1. Он хочет офигенски умный компилятор
2. Он в гробу видал существующий код и под него надо вручную оптимизировать (поэтому МЦСТ сейчас и не гоняет реальные задачи - провал гарантирован).

Цена на ПК модификации «Б» с (SIC!) тактовой частотой процессора 750 МГц!!!

За все потроха: 10к
За принципиально новую сборку: 180к
На чай в поддержку отечественного производителя: 9к
Итого к оплате:

199 000 рублей (включая НДС).

https://img.ytapi.club/vi/a9fffxOe0t4/maxresdefault.jpg

в криптографии там куча смешанных вычислений которые можно на всю ширину развернуть

да-да, вручную все на ассемблере переписать - и будет счастье :) делов-то :)

Ну да, а теперь посчитай накладные расходы и ущербность ООО в аппаратуре.

всяко меньше JIT.

JIT — эффективно периодически.

угу, в отдельных синтетических тестах, высосанных из пальца :)

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

примеры хоть одной VM с JIT, которая бы обеспечила быстродействие сравнимое с нативным, есть?

Опять, ты не понимаешь то, о чём я говорю. GC скрывает от ЯП модель памяти. Работа с памятью становится менее эффективной.

то есть по вашему у явы вся проблема только с GC?...

Интересно, дотянет ли тема до 2000 постов?

примеры хоть одной VM с JIT, которая бы обеспечила быстродействие сравнимое с нативным, есть?

Java. Думаю, .NET тоже.

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

всяко меньше JIT.

Всяко меньше, это примерно 30% от площади ядра (не считая кешей)?

угу, в отдельных синтетических тестах, высосанных из пальца :)

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

примеры хоть одной VM с JIT, которая бы обеспечила быстродействие сравнимое с нативным, есть?

Любой VM которые транслирует байткод в машкод (именно с помощью JIT), делает инлайны, подсказки предсказателю, мономорфизацию, упраздняет двойные указатели, прочее. К примеру сравнение Java на x86 и Эльбрусе в том тесте, который ты мне кидал. Итоге, Эльбрус сокрушительно проиграл, потому, что нет JIT.

то есть по вашему у явы вся проблема только с GC?...

Нет, у Java большая проблема с моделью работы с памятью из-за встроенного и не отключаемого GC.

да-да, вручную все на ассемблере переписать - и будет счастье :) делов-то :)

Теперь скажи это тем программистам, которые вынуждены писать на x86 asm чтобы выжать все соки из аппаратуры.

VLIW — пропагандирует другой подход, оставить оптимизацию компилятору из-за сложности программирования на VLIW asm.

Ты реально думаешь что я майор))))? Ты клоун)))). С изнасилованной психикой).

Будет ли выигрыш от тасовки нативных команд - очень большой вопрос.

Что мешает прогнать цикл, а потом сделать PGO компиляцию? Что мешает проверить статистику на горячих циклах, а потом, если понадобится, сделать PGO компиляцию? Можно делать компиляцию параллельно с работой цикла, а когда она завершится просто продолжить с нужного места.

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

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

А с чего ему не быть? Представь себе ситуацию, программа работает 200 часов, предположим 1 час мы потратили на JIT, после чего программа загружается из кеша. Это тоже самое, как компиляция с march=native + PGO, эффективность каоторых неоспорима. Ты хочешь сказать, что march=native и PGO не оправдывают себя? Из HotSpot тоже надо выбросить PGO?

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

А с чего ему не быть?

Веско.

Представь себе ситуацию, программа работает 200 часов, предположим 1 час мы потратили на JIT

Ты забыл сказать, насколько ускорил программу 1 час работы JIT-компилятора %)

Ну и почему бы не предположить, что компилятор проработал 20 часов и ускорил программу на 9%?

после чего программа загружается из кеша.

Когда-то так планировалось запускать x86-код на e2k. Сейчас об этом никто не вспоминает.

Ты хочешь сказать, что march=native и PGO не оправдывают себя?

Я хочу сказать ровно то, что сказал - ты не привел никаких доводов за то, что JIT e2k -> e2k даст суммарный выигрыш.

Когда-то так планировалось запускать x86-код на e2k. Сейчас об этом никто не вспоминает.

Я хочу сказать ровно то, что сказал - ты не привел никаких доводов за то, что JIT e2k -> e2k даст суммарный выигрыш.

Ты влез в беседу и не ознакомился, о чём говорят? Почитай ветку.

Ты забыл сказать, насколько ускорил программу 1 час работы JIT-компилятора %)

Ну и почему бы не предположить, что компилятор проработал 20 часов и ускорил программу на 9%?

Тут как повезёт, может на 9%, а может в 8 раз. Зависит от программы.

Ты влез в беседу

Я не тебе отвечал.

Почитай ветку.

Дай конкретную ссылку.

Тут как повезёт, может на 9%, а может в 8 раз. Зависит от программы.

И ты считаешь, что будет постоянно везти?

Я не тебе отвечал.

Что не отменяет факта.

Почитай ветку.

Вот

А вот выдержка.

numas13

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

И ты считаешь, что будет постоянно везти?

Я же говорю, зависит от задачи. Выше я приводил пример.

numas13

Представь себе цикл на С++/Rust. Где-то в середине необходимо вызвать пару вирт. методов (через двойной указатель). В JIT можно заложить оптимизацию, которая сделает инлайн такого метода. После инлайна, можно даже попытаться векторизировать такой цикл. В итоге выигрышь может достигать 8+ раз (зависит от деталей). Конечно из-за специфики SIMD, там не должно быть ветвлений, но всё же, после инлайна, мы будем щелкать цикл как орех.

Я имею ввиду универсальное представление алгоритма, с которым удобно работать компилятору.

Если же ты хочешь воскресить старую идею slim binaries или сделать очередной LLVM bitcode - скажи об этом прямо.

А после этого можно будет порассуждать, почему эти идеи (которым 20-30 лет) не использованы в текущей инкарнации Эльбруса.

Выше я приводил пример.
Представь себе цикл на С++/Rust.

Нет никакого «цикла на Си++/Rust». Есть бинарный код, который по сравнению с исходником искажен до неузнаваемости (качественным оптимизирующим компилятором).

Годов мне достаточно чтобы понимать что на данный момент пытаются съехать с темы. Мне на самом деле сторо пофиг в каком корпусе материнка с эльбрусом, задачи расчётов можно выполнять и на midtower, так же как от большой безысходности можно и 1u сервак использовать в качестве рабочей машинки.

Мне интересно узнать, при прочих равных(дисковая подсистема, количество ОЗУ, дискретная видеокарта или её отсутствие) есть ли задачи/бенчмарки, в которых, пусть с оптимизированным софтом, чипы эльбрус значимо лучше современных решений «потенциального противника». Я потому и привёл одним из примеров расчёт жёсткости какой-нибудь здоровой конструкции, типа моста. Это как раз та задача на которой теоретически эльбрус может быть эффективнее нежели xeon какой-нибудь средний(мы же говорим про серверное применение, да?)

Про эффективность в десктопном применении судя по тому видео, говорить не приходится.

Если же ты хочешь воскресить старую идею slim binaries или сделать очередной LLVM bitcode - скажи об этом прямо.

А после этого можно будет порассуждать, почему эти идеи (которым 20-30 лет) не использованы в текущей инкарнации Эльбруса.

Это вопрос не ко мне, а к МЦСТ.

Нет никакого «цикла на Си++/Rust». Есть бинарный код, который по сравнению с исходником искажен до неузнаваемости (качественным оптимизирующим компилятором).

Но ты сам выше написал про slim binaries?

Смотри. У разработчика компилятор, который производит некий AST-IR (аналогия LLVM bytecode, JVM bytecode). На клиентской машине есть интерпритатор/компилятор/JIT/VM (называй как захочешь), далее исполнитель. Он запускает программу, которая привязана исключительно к операционной системе (рабочему окружению), но с универсальной архитектурой. Исполнитель, по мере исполнения кода, генерирует машкод (зависимый для конкретной x86, arm, elbrus, etc). Если какой-то участок кода запускается N раз, то исполнитель производит оптимизацию данного участка. Если участок запускается M раз (при M > N), то он производит адаптивную оптимизацию. Результат работы сохраняется в кеш. После некоторого времени работы получается оптимизированный машкод для конкретного потребителя.

Если же ты хочешь воскресить старую идею slim binaries или сделать очередной LLVM bitcode - скажи об этом прямо.
А после этого можно будет порассуждать, почему эти идеи (которым 20-30 лет) не использованы в текущей инкарнации Эльбруса.

Это вопрос не ко мне, а к МЦСТ.

Вопрос «хочешь ли» - именно к тебе. А потом тебе же будет вопрос «не считаешь ли ты, что этот подход был рассмотрен и отвергнут?».

Но ты сам выше написал про slim binaries?

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

Смотри [...]

Это совершенно не тот подход, который принят на Эльбрус сегодня. Ну а завтра... посмотрим, что получится из их Java - там всё будет, как ты хочешь.

Вопрос «хочешь ли» - именно к тебе. А потом тебе же будет вопрос «не считаешь ли ты, что этот подход был рассмотрен и отвергнут?».

Хочу. Почему? Программа не привязана к архитектуре, как Java. LLVM не подходит, он платформозависимый, но может его можно доработать.

Я считаю, что они его просто не рассмотрели. Если рассмотри, то я очень хотел бы выслушать их аргументацию. Адаптивная оптимизация же не мешает JVM, почему бы не внедрить её для VLIW, у которого беда с динамикой?

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

Боюсь мне нужно просветиться на их счёт более углублённо, после чего смогу дать окончательный ответ.

Это совершенно не тот подход, который принят на Эльбрус сегодня. Ну а завтра... посмотрим, что получится из их Java - там всё будет, как ты хочешь.

Но я не хочу Java, я хочу С/С++/Rust так же. (:

LLVM не подходит, он платформозависимый

Хотя стой. Тут тоже надо более углублённо изучить тему.

Но я не хочу Java, я хочу С/С++/Rust так же. (:

Если не получится для Java, тем более не получится C/C++/Rust.

Отвечу тут.

Если же ты хочешь воскресить старую идею slim binaries

Если я правильно понял, что это такое (трансляция ast налету), то нет, это не то, что я имею ввиду.

Всё же пример ближе к JVM, только вместо Java работает C/C++/Rust.

Если не получится для Java, тем более не получится C/C++/Rust.

Надежда умирает последней! Кто-то верит в зелёных человечков, кто-то в Бога, а я в это. (:

LLVM подходит на эту роль. Осталось разобраться с утверждением, что в нём плохо выражается VLIW. По сути всё почти готово.

Адаптивная оптимизация же не мешает JVM, почему бы не внедрить её для VLIW, у которого беда с динамикой?
я не хочу Java, я хочу С/С++/Rust так же.

Прикинь они то же об этом думают (по крайней мере их специалист по архитектуре)

Только не говори, что ты разобрал там хоть что-то %)

Ооо, а вот и ответ на вопрос tailgunner'a.

Вот, смотри адаптивная компиляция для статических языков, всё же в МЦСТ не дураки.

Да, я знаю, я рукожоп (:

Java.

зачем тогда в андроиде нативные либы в 99% аппок?

примеры хоть одной VM с JIT, которая бы обеспечила быстродействие сравнимое с нативным, есть?

Java.

зачем тогда в андроиде нативные либы в 99% аппок?

Почему нет? У нативного кода быстродействие сравнимо с Java.

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

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

Всяко меньше, это примерно 30% от площади ядра (не считая кешей)?

15% от площади кристалла (а для современных интелов - порядка 7% от площади, учитывая видеоядро) против падения производительности в несколько раз на JIT - что для быстродействия целесообразнее? :)

Любой VM которые транслирует байткод в машкод (именно с помощью JIT), делает инлайны, подсказки предсказателю, мономорфизацию, упраздняет двойные указатели, прочее. К примеру сравнение Java на x86 и Эльбрусе в том тесте, который ты мне кидал. Итоге, Эльбрус сокрушительно проиграл, потому, что нет JIT.

https://pdfs.semanticscholar.org/b6bf/69dc278748af12e449997f1e45b2014f2829.pdf - для явы (самой что ни на есть вылизанной на арме) слив по сравнению с нативным кодом 2-кратный. в классической числодробильной FFT, без каких-либо множественных выделений/освобождений памяти.

https://pdfs.semanticscholar.org/b6bf/69dc278748af12e449997f1e45b2014f2829.pdf - для явы (самой что ни на есть вылизанной на арме) слив по сравнению с нативным кодом 2-кратный.

Какого года статья? В списке литературы нет ничего позднее 2012. Статье 3-4 года, тогда Java для ARM еще не была такой уж вылизанной. Кроме того, сравнение с FFTW - это несколько нечестно.

Адаптивная оптимизация же не мешает JVM

мешает. ява-код в 2 раза медленнее нативного. даже на андроиде, где вроде как байткод дальвика нестандартный, «не-явовский», немного перепиленный для ускорения его интерпретации на арме (оракл/сан помнится из-за этого на гугл наезжала)

15% от площади кристалла (а для современных интелов - порядка 7% от площади, учитывая видеоядро) против падения производительности в несколько раз на JIT - что для быстродействия целесообразнее? :)

Ядра (которых 4), а не весь кристалл. Я же говорил, разница между ООО и VLIW в отсутствии аппаратного планироващика, а всё остальное такое же (ALU, FPU, кеши).

https://pdfs.semanticscholar.org/b6bf/69dc278748af12e449997f1e45b2014f2829.pdf - для явы (самой что ни на есть вылизанной на арме) слив по сравнению с нативным кодом 2-кратный. в классической числодробильной FFT, без каких-либо множественных выделений/освобождений памяти.

Я тебе уже говорил про GC, ты и сам указывал, что это не единственная проблема. Покажи мне сравнение не с Си, а с таким статическим ЯП, у которого будут все проблемы Java.

на андроиде 4.х ява была уже вполне себе вылизана.

литература - 2013 года последняя.

FFTW - а почему нет? яркий пример обычной вычислительной задачи, чтобы показать ущербность идеи «JIT во все поля».

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

не сравнимо. намного хуже. для того и JNI.

Ядра (которых 4), а не весь кристалл.

которые занимают 25% современного кристалла...

Покажи мне сравнение не с Си, а с таким статическим ЯП, у которого будут все проблемы Java.

то есть изобрести язык с проблемами явы, и сделать на нем бенчи?...

литература - 2013 года последняя.

Эта статья опубликована на конференции, которая прошла 11-14 января 2013 - я бы отнес ее к 2012.

на андроиде 4.х ява была уже вполне себе вылизана.

Нет. Андроид 4 - это доморощенная реализация Гугла, оптимизированная на быструю компиляцию.

FFTW - а почему нет?

Да пусть будет FFTW. Но надо помнить, что это по сути специальный компилятор^Wкодогенератор, рассчитанный на разные FFTW, который соревнуется с JIT общего назначения.

которые занимают 25% современного кристалла...

И 7 от 25 это 30%, но это с кешем. Да ты прав, планировщик занимает больше площади ядра.

то есть изобрести язык с проблемами явы, и сделать на нем бенчи?...

Ты приводишь сравнение не только JIT со статической компиляцией (разница между ними только в том, когда эта компиляция произойдёт, заранее, или во время исполнения, компилятор может быть один и тот же), а GC языка с Си (в котором полный контроль за всем и вся). Это разные весовые категории. Если хочешь объективного сравнения, бери какой-нибудь GC ЯП со статической компиляцией. Потом, прогревай JIT, и делай замер.

Собственно, Ч.И.Т.Д. Ни одной оригинальной разработки.

Были - M-20, Сетунь. Почему не продолжали ? Потому что НИОКР дорогой, и кадровый дефицит был всегда. Однако клонирование западных технологий сыграло злую игру в советским ИТ, остатки грамотных спецов уехали опять таки на запад. Увы но те же замечательные идеи Глушкова - основной целью ставили улучшение государства, а не качества жизни его граждан. А последнее мало кому было интересно.