Обновлены результаты 7zip bencmark для Эльбрусов

Но если уж ты сравниваешь результаты «адаптированного» под архитектуру Эльбруса кода, может сравним например с результатами оптимизированными под гетерогенные вычисления AMD? А то вы фанаты Эльбруса любите играть в одни ворота. Там вычислительная нагрузка переносится на GPU (тот же VLIW на старых AMD по сути). Там отрыв копеечных АМД от Эльбруса я думаю будет на несколько порядков.

Он не фанат эльбруса, он разработчик компилятора для него, почему он должен играть в чужие ворота? Ты повторяешь давно избитые тезисы про «если оптимизировать/распаралелить ничего нельзя» - нельзя так нельзя, поочередно будет исполнять. В реальных задачах максимальная скорость исполнения только на каких то вычислениях в приоритете и там уже обычной скоростью ядра не обойдшься приходится или руками упихивать алгоритмы под все вот эти симд-расширения, либо купить интеловский компилятор (который под амд правда не задействует серьезные оптимизации).

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

А есть ли где результаты 8СВ -mm=*

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

В общем сейчас в Эльбрусе предсказателей нет

А есть ли где результаты 8СВ -mm=*

Здесь

против 0.97

Откуда ты 0.97 берёшь? Опять делишь на 8, а не 4?

Только давай возьмём 1C+

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

А почему тогда i7-6900K (Broadwell) 16 года уделывает i7-1065G7 (Ice Lake) 19-ого года?

Может потому что он топовая десктопная печка о восьми ядрах с 20Мб кэша, а против него планшетный огрызок с 4 ядрами, урезаным кэшем 1го уровня, и 8МБ очень медленного L3? На задаче, которая любит ядра и кэш.

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

Поочередно это очень медленно. Очень это прям совсем оооооочень.

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

А что тогда в приоритете в реальных задачах? Если не скорость исполнения то i386 хватало бы и сейчас.

Спасибо, там только в файле с меткой 32 результаты для 64bit почему то. Ну да ладно

Вот сравнил по чесному свой QX9650 (AES нет, ssse3,sse4.1):

p7zip Version 16.02 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs x64)

CPU Freq:  2796  2973  2966  2971  2969  2971  2969  2970  2970

RAM size:    7950 MB,  # CPU hardware threads:   4

p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,8 CPUs LE)

CPU Freq:  1496  1498  1499  1499  1499  1499  1499  1499  1499

RAM size:  126924 MB,  # CPU hardware threads:   8
RAM usage:    901 MB,  # Benchmark threads:      4

Так в целом в LZMA ядро эльбруса процентов на 10-20% эффективней

RAM usage:    901 MB,  # Benchmark threads:      4

Method           Speed Usage    R/U Rating   E/U Effec
                 KiB/s     %   MIPS   MIPS     %     %

LZMA:x1          50635   395   4689  18511   161   637
                135653   395   2798  11047    96   380
LZMA:x5:mt1       8705   367   2961  10875   102   374
                120832   362   2814  10190    97   351
LZMA:x5:mt2       9306   383   3034  11626   104   400
                131565   391   2838  11095    98   382
-------------------------------------------------------
LZMA:x1          20463   398   1879   7481   125   499
                 81659   400   1663   6650   111   444
LZMA:x5:mt1       6142   398   1930   7673   129   512
                 80001   400   1687   6746   113   450
LZMA:x5:mt2       9035   673   1677  11288   112   753
                 79980   399   1690   6745   113   450

Deflate:x1      117558   368   4053  14927   140   514
                460294   393   3635  14301   125   492
Deflate:x5       38179   391   3758  14700   129   506
                458404   391   3636  14231   125   490
Deflate:x7       13100   379   3829  14515   132   500
                456621   388   3655  14170   126   488
Deflate64:x5     30661   333   3976  13250   137   456
                431192   370   3646  13488   126   464
-------------------------------------------------------
Deflate:x1       38935   396   1249   4944    83   330
                111448   399    867   3463    58   231
Deflate:x5       15474   396   1504   5958   100   398
                111603   400    866   3465    58   231
Deflate:x7        4555   394   1280   5047    85   337
                112075   400    870   3478    58   232
Deflate64:x5     14869   396   1624   6425   108   429
                110977   400    869   3471    58   232

BZip2:x1         20351   387   3178  12295   109   423
                108322   382   3073  11743   106   404
BZip2:x5         15484   378   3416  12923   118   445
                 83401   378   4335  16370   149   564
BZip2:x5:mt2     14271   377   3156  11910   109   410
                 87067   382   4475  17090   154   588
BZip2:x7          5301   392   3507  13734   121   473
                 86509   383   4432  16965   153   584
-------------------------------------------------------
BZip2:x1          6170   397    939   3728    63   249
                 37172   398   1012   4030    68   269
BZip2:x5          4996   400   1043   4170    70   278
                 31603   394   1573   6203   105   414
BZip2:x5:mt2      8829   776    950   7369    63   492
                 46561   597   1531   9139   102   610
BZip2:x7          1804   400   1169   4676    78   312
                 31800   393   1587   6236   106   416

PPMD:x1          13610   379   3713  14076   128   485
                 12566   392   3771  14799   130   509
PPMD:x5           9561   389   4169  16204   144   558
                  8502   390   4081  15933   140   549
Delta:4        2427359   359   4153  14914   143   513
               2320048   361   3944  14254   136   491
BCJ            3956561   389   4167  16206   143   558
               3834400   378   4152  15706   143   541
------------------------------------------------------
PPMD:x1           5065   399   1314   5239    88   350
                  5518   399   1628   6499   109   434
PPMD:x5           3611   399   1534   6120   102   408
                  4112   399   1934   7707   129   514
Delta:4         430173   400    661   2643    44   176
                328841   400    505   2020    34   135
BCJ             802793   399    823   3288    55   219
                802965   400    823   3289    55   220

AES256CBC:1     564029   382   3625  13862   125   477
                516432   366   3465  12692   119   437
AES256CBC:2 

CRC32:1        1415258   382   2696  10303    93   355
CRC32:4        3798455   387   2191   8478    75   292
CRC32:8        6206075   393   2139   8415    74   290
CRC64          3889712   389   2046   7966    70   274
SHA256          534160   392   2779  10897    96   375
SHA1           1506794   394   3583  14104   123   486
BLAKE2sp        895432   391   5043  19700   174   678
------------------------------------------------------
AES256CBC:1     290453   399   1790   7138   119   476
                319654   400   1962   7856   131   524
AES256CBC:2 

CRC32:1         632731   400   1152   4606    77   307
CRC32:4        1800213   400   1006   4018    67   268
CRC32:8        3113795   399   1059   4222    71   282
CRC64          1672097   400    857   3424    57   229
SHA256          620484   399   3171  12658   212   845
SHA1            512652   399   1202   4798    80   320
BLAKE2sp    

Вот поэтому я общий итоговый и не люблю из него ничего не видно.

А что тогда в приоритете в реальных задачах? Если не скорость исполнения то i386 хватало бы и сейчас.

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

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

Допускается ли у вас в системе команд вот такое содержание например:

{
   fmuld,0 %dr1,%dr0,%dr1
   faddd,1 %dr2,%dg1,%dr2
   fmuld,3 %dr3,%dr0,%dr3
   faddd,4 %dr4,%dg1,%dr4
}

там где на этапе компиляции невозможно предугадать и распараллелить все на 8 или 16 равных потоков. Так нигде такого нет, вы мифами живете. Не умеют процессоры сами оптимизовать внутри себя на 8-16-кучу потоков, это бред.

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

Эльбрусу порядок исполнения и планирование прям по алу и регистрам готовит компилятор, (кстати готовит очень шаблонно), интелу компилятор подготавливает порядок декодирования потому что там все равно фронтенд есть очень неоднородный, а вот уже пройдя через фронтенд внутри уже процессор свое внутреннее представление выстраивает так же параллельное исполнение и распределяет регистры. У него тоже внутри 8 портов исполнения 180 регистров, разница в том что у него порты неоднородные и регистры отдельно целочисленные отдельно вещественные.

Другое отличие что в интеле постоянно добавляют какие-то расширения и предлагают их заюзать через интринсики или через их фирменный компилятор который сам может через опции попытаться заюзать все взможности в процессоре. Это уже фактически как VLIW только в виде набора неуниверсальных дополнений которые можно и нужно использовать если хочется чтоб было быстро, потому что стандартная обычная ISA уже ничего продемонстрировать не может.

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

Эльбрусу порядок исполнения и планирование прям по алу и регистрам готовит компилятор

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

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

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

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

Что касается джаваскрипта в браузере, то все абсолютно тоже самое - скрипты так или иначе компилятся в статичные куски программного кода, потом могут перекомпилироваться получше что то выкидывать например, оптимизоваться для работы с одним типом данных итд итп. Это для эльбруса даже было бы лучше в каком то смысле еслиб не одно НО (даже два) - архитектура современных джитов и интерпритаторов динамических и vm языков сделана тупо в парадигме x86/risk. То есть там или макароны из байткода push int8 getVal setVal call push int32 которые можно конечно в ШК объеденять, но так, локально - что рядом стояло то и впихнул. Либо (как вот в джаваскрипте) получают AST и превращают его в неоптимизированный код в котором будет куча проверок на типы на то на се, и потом уже попроцедурно оптимизовать какие то часто вызываемые функции например. Для VLIW (и эльбруса в часности), после получения AST надо всю программу растеребить на графы и расфасовать по ШК. Потом уже так же после нескольких прогонов и получения профиля исполнения бинарий выкинуть перекомпилять код или какие то отдельные части/функции частоиспользуемые с агрессивными оптимизациями. Вот так вливу динамические языки зайдут хорошо, весь вопрос только в том кто это будет писать и потом поддерживать этот отдельный jit и стоит ли вообще заморачиваться с этим, если будет хватать простого портирования того что сейчас у всех работает, так как скриптовые языки не используются для чего то такого серьезного и требовательного.

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

Ну влив концептуально не годится в качестве коммон процессора. Зато офигенно подходит на роль числодробилки, т.е. для преобразования/обработки больших массивов однотипных данных. Т.е. там где и используется в основной своей массе - DSP.

Ну так я о том же, да.

так вот я не понимаю зачем ельбрус нужен. зачем они его с циском риском сравнивают?

А в какой реальной задаче они могут раскрыться?

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

Кстати, 7-зип поддерживает многопоточность и на моём компе грузит все ядра.

Ты вообще в курсе как работает многопоточность у архиваторов? Чем больше потоков тем ниже степень сжатия, так как фактически архив нарезается на несколько независимых частей.

Числодробилки это не только DSP. uin верно подметил что динамические языки и vliw потенциально можно хорошо подружить. А уж какой-нибудь numpy под это дело оптимизировать сам ТНБ велел.

Забавно ;)

Но вы попробуйте не фантазировать а эксперимент провести и убедитесь что вы ошибаетесь.

Я к тому что многопоточность у архиваторов вовсе не показатель оптимизации под процессор. Но канадским грузчкам, думаю, виднее.

Судя по тому, что вы как всегда уходите от ответа и плюетесь дерьмом в собеседника, вы признали что вы слились ;)

Т.е. архиватор жмет одинаково в однопоточном и многопоточном режимах.

Побитовые сравнения архивов делал?

Я вот сделал. В случае солидных архивов 7z/lzma разница есть, пусть и небольшая, в случае обычных - нет. А теперь вспоминай Фигурнова и думай над причиной.

В случае солидных архивов 7z/lzma разница есть

В размере или в битах?

Если в размере, то хотелось бы доказательств.

Иначе буду считаь что вы как всегда ;)

в случае обычных - нет.

Что и требовалось доказать ;)

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

Да, есть определённые ограничения. Например на операции LD/ST. Необходимо чтобы а конкретном канале была реализована конкретная инструкция.

То есть сочетание вещественного сложения и умножения в одном кластере с разными регистрами но с одним и тем же операндом допустим- можно такое?

С точки зрения СК - да, допускается. В некоторых случаях возможны задержки из-за работы в разных кластерах. Что будет в конкретном случае - не скажу.

PS. спасибо за подробный анализ результатов, интересно было почитать. На сколько я помню, в итоговой таблице результат только по lzma алгоритму.

Откуда ты 0.97 берёшь? Опять делишь на 8, а не 4?

Я по одному ядру результат смотрю 3800 Попугаев / 3900 Гц = 0.97 Попугаев / Гц

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

Тебе может и неудобненько, мне норм.

Может потому что он топовая десктопная печка о восьми ядрах с 20Мб кэша, а против него планшетный огрызок с 4 ядрами, урезаным кэшем 1го уровня, и 8МБ очень медленного L3? На задаче, которая любит ядра и кэш.

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

Кстати, 7-зип поддерживает многопоточность и на моём компе грузит все ядра.

Более того на сайте указана прозводительность при нагрузке на 8 ядер ;)

Это к чему и какие выводы из этого следуют?

И без этой «адаптации» Эльбрус и показывает свои истинные результаты

Ты ошибочно считаешь что для Интелов не было адаптации, хотя задача изначально написана под интелы. Если бы задача изначально писалась под Эльбрусами, результат был бы другим. А так - даже IBM’овские камни показывают не лучший результат, хотя казалось бы.

может сравним например с результатами оптимизированными под гетерогенные вычисления AMD

С гетерогенными вычислениями под Эльбрус? Может и можно, только вот что именно ты хочешь этим замерить?

Из этого следует что он работает в многопоточном режиме.

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

Из этого следует что он работает в многопоточном режиме.

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

Работает. Нет, я пенял что у теста низкий IPC by-design. Это распараллеливание на уровне потока данных в рамках одного ядра.

Так я ою этом и псал, помотрите результы.

Многоядерная верися в разы быстрее обноядерной.

И разве у Интелов не было-бы той-же проблемы?

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

Так я ою этом и псал, помотрите результы.

Многоядерная верися в разы быстрее обноядерной.

Ещё раз. Это вообще перпендикулярные штуки. Ускорение на нескольких ядрах есть везде.

И разве у Интелов не было-бы той-же проблемы?

А у них она и есть. У них IPC ниже. Т.е. на той же частоте они бы показывали худший результат.

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

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

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

Ты ошибочно считаешь что для Интелов не было адаптации, хотя задача изначально написана под интелы. Если бы задача изначально писалась под Эльбрусами, результат был бы другим.

Во-первых я никогда не утверждал что не было оптимизации под Интел, или что код не был написан под архитектуру x64 изначально. Так почти весь софт под нее написан, вы что для Эльбруса осилите написание ОС вместе с прикладным софтом? Очевидно нет, так к чему вообще упоминать что код написан под x86? Другого нет и не будет. Во-вторых то что если бы он был написан изначально для Эльбруса результаты были бы другими - ну на несколько процентов наверное да. А с чего результатам быть принципиально другим? С архитектурой vliw много игрались и в Интел в том числе, и переписывали и оптимизировали, в результате поняли что это тупик ничего из этого не получается, и выбросили в мусор. С чего ты решил что с очередной попыткой воскресить эту архитектуру будет иначе? Опять же, продвигающие Эльбрусы всегда вместо доказательств говорят «можно», «было бы» и т.д. Ну так если ты считаешь что результат может быть другим перепиши код под Эльбрус тогда и приходи. А пока никто результаты на vliw показать не смог, одни пустые разговоры. Точно также я могу утверждать что деревянные счёты будут быстрее, точно также доказательств ноль и все тесты будут разумеется свидетельствовать об обратном и даже теоретически непонятно как этого можно достичь с такой архаичной технологией. Вот с Эльбрусом также, одни ничем не подкрепленные утверждения, хотя все тесты и даже сам здравый смысл говорит об обратном.

Если в размере, то хотелось бы доказательств.

В размере. Запусти сам 7z с параметром -mmt=1 -ms=on и -mmt=8 -ms=on

Что и требовалось доказать ;)

Что требовалось доказать? Что архив по дефолту разрезан на кучу независимых частей? Кстати, слышал краем уха что 7-зиповский lzma больше двух потоков на один файл не умеет.

Размер действительно отличается.

7z a -mmt8 -mx9 файл 82,012,899

7z a -mmt1 -mx9 файл 82,035,998

Т.е. многопоточное сжатие лучше. Очень интересно.

Ещё раз. Это вообще перпендикулярные штуки. Ускорение на нескольких ядрах есть везде.

Вы что-то гоните. Я начнаю сомневаться в вашем понимании основ программмирования и процессоров.

Дискуссия стремительно теряет интерес.

мск, ростелеком
7-cpu.com и 7-zip.org заблокированы

Дискуссия стремительно теряет интерес.

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

Во-первых я никогда не утверждал что не было оптимизации под Интел, или что код не был написан под архитектуру x64 изначально.

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

вы что для Эльбруса осилите написание ОС вместе с прикладным софтом?

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

Во-вторых то что если бы он был написан изначально для Эльбруса результаты были бы другими - ну на несколько процентов наверное да. А с чего результатам быть принципиально другим?

Постепенно начинаем подходить к самому интересному. Не несколько процентов. Для примера: в среднем разница между работой тестов, собранных при -O0 и -O3 у меня была более 10 раз. Т.е. если человек не слишком думая писал под Интел, то мог получить сильную упущенную производительность под Эльбрус. И это не несколько процентов. Есть и обратная сторона: можно писать по Эльбрус так что это будет на нём работать быстро, а на Интеле тормозить.

В итоге производительность сильно зависит от изначального целевого процессора и количества допиливаний под него.

С архитектурой vliw много игрались и в Интел в том числе, и переписывали и оптимизировали, в результате поняли что это тупик ничего из этого не получается, и выбросили в мусор.

Уверен что было именно так и выбросили её по техническим причинам? А не потому что продолбались со сроками, провалили маркетинг, а к этому времени конкуренты подоспели?

А пока никто результаты на vliw показать не смог, одни пустые разговоры.

Это в треде про результаты с дополнительными ссылками :) Но да, я уже понял что нужно не просто их выкладывать а рассказывать как эти результаты интерпретировать.

достаточно портировать существующее и при необходимости поправить, чем мы успешно занимаемся

Да где успехи то? Что именно вы успешно портировали и поправили? Во всех тестах ваш Эльбрус сливает очень древним бюджетным процессорам. В реальных приложениях работает на уровне уже упомянутого Атома в лучшем случае. Это факты, результаты тестов и обзоров. И опять повторю - в том же Интеле игрались с vliw, и их возможности и ресурсы на порядки больше Ваших. Результат - выкинули в мусор и забыли. Ну ничему вас чужой опыт не учит.

Да где успехи то? Что именно вы успешно портировали и поправили?

Ну как бы ты много контор можешь назвать, способных делать 28 нм процессоры общего назначения? Особенно в России?

Во всех тестах ваш Эльбрус сливает очень древним бюджетным процессорам. Это факты, результаты тестов и обзоров.

Я привёл публикацию от независимых людей, где Эльбрус быстрее амд и показывает очень хорошие результаты по отношению к Интелу. Ты эти результаты изучил, так что сейчас ты просто врёшь.

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

Опыт тут очень простой. В России разрабатывается широкий спектр процессоров на разных архитектурах: ARM, MIPS, SPARC, RISC-V, собственные, возможно что-то ещё. А быстрее Эльбурса пока что никто ничего не показал. И в обозримом будущем не покажет.

ты много контор можешь назвать, способных делать 28 нм процессоры общего назначения? Особенно в России?

делать 28 нм процессоры

в России

Ну как бы ты много контор можешь назвать, способных делать 28 нм процессоры общего назначения? Особенно в России?

А при чем тут Эльбрусы? Их же на Тайване делают.

Я привёл публикацию от независимых людей, где Эльбрус быстрее амд и показывает очень хорошие результаты по отношению к Интелу

Ничего подобного ты не приводил. В приведенной тобой ссылке без оптимизации кода Эльбрус в разы сливает древним днищенским процессорам даже в специально отобранных для него тестах. А оптимизация эта возможна для узкого круга тестов где на этапе компиляции можно все распараллелить на 8 потоков. В реальных задачах это невозможно, я могу это легко доказать - ни у кого не получилось. И никто ОС и все приложения переписывать разумеется не будет. Считаешь иначе? Ну так докажи тестами. Пока ты только несёшь бездоказательную чушь, ни одного доказательства ты не предоставил.

FYI:

На уровне асемблера цикл это ветвление

;)

Т.к. мне уже довольно лениво рассказывать Вам основы, я все лишь одно вещь хочу уточнить: где Вы обучались программированию (в частности курс компиляторов, если был)?

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

Ну как бы ты много контор можешь назвать, способных делать 28 нм процессоры общего назначения? Особенно в России?

А при чем тут Эльбрусы? Их же на Тайване делают.

А причём тут завод по выпеканию когда вся интеллектуальная часть разработана в России?

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

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

Далее. Так и запишем что серверный проц от АМД на 2.3 ГГц - днище, поэтому и местами почти до двух раз сливает Эльбрусу на 1.3 ГГц. Далее запишем что Skylake, который «быстрее в разы» на одно ядро быстрее всего лишь на 34%. С частотой 2.1 ГГц, с более тонким техпроцессом. Наверное тоже днище какое-то. В тесте на 8 ядер он, конечно, в отрыв ушёл и теперь это целых 2 раза («разы», лол), но что-то мне подсказывает что связано это с DDR4 у интела и DDR3 у Эльбруса.

Ты, конечно, мог бы сказать «да кого это интересует, давайте смотреть по всем ядрам». Ну ок. Ой, что это? AMD снова сливает, хотя ядер у него в 2 раза больше ну точно «днище». «В разы» здесь получается только у интелов, у которых и ядер «в разы» больше.

А оптимизация эта возможна для узкого круга тестов где на этапе компиляции можно все распараллелить на 8 потоков. В реальных задачах это невозможно, я могу это легко доказать - ни у кого не получилось.

Какая оптимизация и какие потоки? А то я нить повествования теряю.

И никто ОС и все приложения переписывать разумеется не будет. Считаешь иначе? Ну так докажи тестами. Пока ты только несёшь бездоказательную чушь, ни одного доказательства ты не предоставил.

И снова врёшь, я уже задолбался расписывать. Ну а ОС GNU/Linux (и ещё парочка менее известных) с несколькими тысячами пакетов почему-то работает на Эльбрусах независимо от твоего мнения (даже оффтопик работает), приложения портируются, причём далеко не только opensource.

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

Ты идиот? Результаты Эльбрус 8С в бенчмарке 7zip - 9625 и 12857, а результаты Intel Atom C2750 на древнем ядре Silvermont - 13500. Это Атом! Старый тормозной Атом на древнем Silvermont! Вот как обгонит Эльбрус это днище приходи, а пока прекращай втирать нам эту дичь. И это опять таки в бенчмарке 7zip который будто создан чтобы раскрыть потенциал Эльбрусов, в большинстве других тестов Эльбрус сливает не только Атомам но зачастую и Pentium II и более слабым процессорам. Видя эти цифры (ты читать то умеешь?) о чем тут вообще дальше можно говорить? Поэтому дискуссия прекращаю, ты немного поднадоел мне своей тупостью.

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

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

Процессор лучше когда он дешев, удобен, доступен, эффективен

Полностью согласен.

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

Это до тех пор пока дяди из штеуда не проплатят кому надо за использование их продукции ;)

Если же для его продвижения нужны госзаказы и конкурсы из одного - он пока однозначно хуже.

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

если его не начнут использовать.

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