А вот и первый свидетель AVX'a 
вопросы/предложения по ветке обсуждаются в привате -
http://forum.ixbt.com/topic.cgi?id=0:70167
подключает (просьбы подключить к привату) - Romaker
Главная iXBT.com Конференция Блоги Games Видео Market Prosound ПроБизнес РегистрацияВойти | |
t0st0 Member 1022/15933 ответов17 лет на iXBT, с июня 2007 Чаще Р С—Р СвЂВшет Р Р†"Консоли" (46%) | А вот и первый свидетель AVX'a |
VLev Expert 7738/15041 ответов, #2 врейтРСвЂВР Р…Р С–Р Вµ 23 года на iXBT, с января 2002 6 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (64%) Россия, Moscow | bess_temporary: А на самом деле не благодаря, а вопреки. эта тенденция продолжается уже три десятилетия. Я тут в тематической ветке сравнил програсс суперов за 10 лет: High Performance Computing - TESLA vs Intel MIC vs AMD FirePro, #2927 и там допустил очень характерную ошибку |
Boris Usievich Member 14363/38886 ответов, #6 врейтРСвЂВР Р…Р С–Р Вµ 22 года на iXBT, с октября 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (44%) | deadlock Плохо видно? повторим везде вам никто не обещал |
bess_temporary Member 86/86 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | deadlock Стало быть, за базар отвечать не хотите ? Добавление от 08.05.2018 14:19: VLevВы слишком тезисно излагаете. Можно понять с точностью до наоборот |
deadlock Advanced Member Куратор теРСВВР РЋРІР‚в„– 2405/2626 ответов19 лет на iXBT, с января 2006 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (92%) Россия, Москва | bess_temporary Стало быть, за базар отвечать не хотите Почитайте посты что писал matik про Cloudfare. Программа типа является неоптимизированной если не использует AVX-512 |
bess_temporary Member 87/87 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | deadlock > Почитайте посты что писал matik про Cloudfare. И что будет ? В общем, какдый сам решает, какую ему иметь репутацию > Программа типа является неоптимизированной если не использует AVX-512 Терминологически он не прав. Это не оптимизация. Оптимизация - это способ уменьшить расходы. А использование упакованных инструкций - это способ увеличить доходы. Ну а по сути - я же не знаю, о каких алгоритмах он говорит. Для одних это нужно, для других нет. И вообще, надо научить людей компилировать с ключом "-xhost" (или явно "-xcore-avx2" etc.). |
deadlock Advanced Member Куратор теРСВВР РЋРІР‚в„– 2406/2627 ответов19 лет на iXBT, с января 2006 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (92%) Россия, Москва | bess_temporary И что будет ? Отвечаю за базар(с) В общем, какдый сам решает, какую ему иметь репутацию Да мне всё равно Добавление от 08.05.2018 14:49: Boris Usievichвезде вам никто не обещал Ну вот уже начинаете оправдываться |
TheJudge Advanced Member 1583/4052 ответов, #22 врейтРСвЂВР Р…Р С–Р Вµ 20 лет на iXBT, с марта 2004 52 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (46%) Россия, Саров |
t0st0 Member 1023/15934 ответов17 лет на iXBT, с июня 2007 Чаще Р С—Р СвЂВшет Р Р†"Консоли" (46%) | Плохо, выше конкуренция для нас (покупателей) лучше |
Boris Usievich Member 14364/38887 ответов, #6 врейтРСвЂВР Р…Р С–Р Вµ 22 года на iXBT, с октября 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (44%) | deadlock вы выдумали какую-то хрень и решили с ней бороться? Добавление от 08.05.2018 16:06: bess_temporaryИ вообще, надо научить людей компилировать с ключом "-xhost" лучше сразу -fast |
deadlock Advanced Member Куратор теРСВВР РЋРІР‚в„– 2407/2628 ответов19 лет на iXBT, с января 2006 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (92%) Россия, Москва | Boris Usievich смайлик в моём посте должен намекать |
bess_temporary Member 88/88 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | Boris Usievich > лучше сразу -fast Отнюдь. Во-парвых, "-fast" - "-x" ортогональны (см. выше про оптимизацию vs. новые инструкции). А во-вторых, "-fast" использует неточное деление, что не всегда хорошо. А остальные элементы от "-fast" (типа "-O3" и "-fp-model") нужно проверять отдельно - помогают не всегда. |
Boris Usievich Member 14365/38888 ответов, #6 врейтРСвЂВР Р…Р С–Р Вµ 22 года на iXBT, с октября 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (44%) | bess_temporary В среднем -fast дает хорошие результаты и является хорошей точкой для старта (там еще и -ipo есть и -xHost само собой). А разбираться с ключиками, конечно, надо всегда, если производительность волнует. |
Felid iXBT.com CPU analyst 7715/12059 ответов19 лет на iXBT, с февраля 2006 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (64%) Web-странРСвЂВца | Zveri2 ради практически косметических изменений, ставить x86 в позу — какие же они косметические, когда вводится куча вещей, в т.ч. ранее не виданных ни в одной архитектуре? Вы мой списочек несколько страниц назад внимательно читали? Это может быть и доказательством совершенства — целакант не изменился за сотни миллионов лет, но и (каким-то чудом) не вымер — это доказательство его совершенства? bess_temporary нам мешает уважение к родному языку — по-вашему, уважение состоит в том, что вы добровольно отказываетесь от его использования, не переводя иностранные слова, которые притом запросто переводимы? С показом исходного архитектурного состояния — а зачем оно нужно именно в исходном состоянии? Кому нужен отладчик, который не отлаживает ? — а вы собираетесь отлаживать программу без доступа к её исходному коду? Вы можете эти стадии сделать параллельными в суперскаляре? — Легко — и как же? Только не вспоминайте матричную структуру длиномера — это как раз пример цепного срабатывания. Зачем это делать декодеру ? У него своих дел достаточно. Вдобавок ни разу не совершаемые переходы никого не интересуют и спят, пока не будут совершены — это верно, но в случае своего совершения кто-то должен сообщить предсказателю, что́ именно сработало, а не только по какому адресу. доступ к РФ стоит больше одного такта — Это как раз не факт — это очень даже факт. В частности АМДшники подтверждали это в описании Ягуара (в сравнении с Бобкэтом там пришлось сделать векторный РФ 2-тактным, чтоб не упереться в частотный потолок единственной стадией). 2-тактные РФы у них были и до того. Часто кодов содержит таблицы символов, которые могут понадобиться в случае сбоя — а разве они кладутся компилятором не по давно известному общему шаблону? Есть коды, откомпилированные в отладочном режиме, и для них использование отладочных средств есть штатное поведение — есть, но вряд ли в распространённых и давно отлаженных массовых программах. VLev Мало того, что несовместимость на пустом месте, но и надежды на ускорение испаряются сразу — ну, у меня есть возможность переключиться на новую кодировку — в текущей вложены резервные префиксы Ближайшее развитие CPU должно преодолеть планку 10 команд за такт, и дойти до ~100 — даже если это и произойдёт, то совершенно не обязательно запихивать все 10-100 к/т в один поток. А вот если потоков будет 8-16, то уже куда веселее. Но главное — ничего не надо менять на уровне ISA! очень большой запас даже для существующих кодов. Были исследования на наборе SPEC — при условии полной раскрутки циклов и с бесконечным ФРФ? Ещё бы! расплата --- низкая производительность однопотока — а кого это волнует, когда для получения желанных петафлопсов этих потоков уже нужен миллион? Частоты выше не станут, а что ещё осталось для ускорения из моего списка? — http://www.ixbt.com/cpu/cpuspeed.shtml если все эти потоки решают одну и ту же задачу, то бОльшая часть регистров будет содержать одни и те же данные — только переменные данные (в т.ч. вспомогательные типа адресов). Константы можно сделать общими. Надо делать многобанковый регистровый файл — тогда банки надо переключать — именно так это делалось в Z80 и старом Арме. Это сильно неудобно. И сейчас нет быстрого переключения контекста (кроме HT), и раньше не было, с 8ю РОН-ами — быстрое — это не более чем сотни тактов, а не сотни тысяч. Кому жемчуг мелкий Для обычного кода надо включать в сигнатуру функции число требуемых регистров — это хорошая идея, но недостаточная, потому что подпрограмма не сможет узнать, какие именно регистры допустимо испортить при вызове с такого адреса. компилятор знает имена этих данных. В бинарном коде этой информации уже нет — а зачем они нужны для перевода в др. маш.код? Только для работы с косвенными переходами? для переходи от ЯВУ к AST есть формальные правила, а для перехода от бинарного кода к AST --- нет — а нам очень нужен AST для рекомпиляции? почему бы не сделать регистровый файл виртуальным? — с ТЛБ и промахами в нём? в физическом регистровом файле хранить только вершину - те регистры, что используются в текущем и паре предыдущих контекстов. А всё остальное сбрасывать в кэш/память — всё это давно уже было ещё в 70-х (а то и ранее). И сдохло. Помнится, был такой замечательный и компактный TI9940, один из первых 16-битных ЦП. У него вообще все РОНы были в памяти и читались по ссылке. Внутри же самого ЦП было всего 3 аппаратных регистра. И хотя РОНов было 16, но при вызове можно было сдвигать окно, получая новый набор. Стековые ЦП потом это сильно развили с «переливами и заполнениями» (spill+refill). Дальше DSP дело не пошло. проблема осталась --- называть это "моделью покатой крыши" или оставить RoofLine-ом — просто «модель крыши». Придумывайте краткие названия, иначе их вытеснит оригинал, если он более короткий. пропустили новые тренды — какие «новые» тренды в параметрах кэша? заставит что-то кардинально поменять в архитектуре (у меня, кстати, есть очевидные предложения — ну, делитесь изменение обычного соотношения размеров L2:L3 --- недеюсь, шаги в правильном направлении — это не само по себе, а вдобавок к удалению исключительности L3 и переходу к (судя по всему) жертвенности от L2. гуглил статейки, в которых пишут, что LLC потребляет 20-30%% от всего чипа — вот, полюбуйтесь на теплофото Ллано: https://www.ixbt.com/cpu/images/amd-llano/llano-power-gating.jpg . L2 видно? А они есть! Последнее, где я это встречал, было про Эльбрус — о, тогда можно это исследование выкинуть. Потому что они за операцию считают совсем не то, что в х86. Например, «add [m],r» по-эльбрусовски будет означать аж 5 операций. Ну и никаких векторов наверняка… mafik For instance, based on program input — вы предполагаете, что юзверь лично будет вводить с клавы адреса для переходов? Такую программу пишут не программисты, а садисты дизассемблеры "пилят" уже десятки лет, а они всё равно путают код и данные — а почему и при каких обстоятельствах? Ладно бы в ручном коде запутались, особенно если там жуткий SMC… Но ведь вполне точно известно, как генерируют код компиляторы. mcvla Если при написании алгоритма программист применяет мозг интересуется скоростью выполнения, он приложит максимум усилий, чтобы наиболее часто потребные данные оказались в _локальных_ кэшах ядра — нет, потому что там свёрточная функция, наиболее случайно разбрасывающая строки по всем банкам L3 (если вы имели ввиду их, а не местные L1-L2). формула дает примерно правильный ответ на следующий бессмысленный вопрос: Какова вероятность того, что ни одному ядру N-ядерного процессора не потребуется обратиться к чужому L3? — совершенно верно. Именно такую невероятную ситуацию я и представил как теоретический пик нагрузки на L3. данные размазаны по L3 всех ядер без дублирования, и чтение/запись происходит по случайным адресам — именно так. (Не считая CCX в Зенах — там каждый шмат по 8 МБ может иметь копию данных. Но сляпана эта часть явно наспех.) Какова вероятность, что _конкретное_ ядро найдет данные в _своем_ L3, если данные закешированы, но их нет в своем L0-L2? В среднем по больнице эта вероятность превышает 90% — откуда такие фантастические цифры? Пожалуй, даже для несуществующего 1-ядерного ЦП с единственным банком L3 90% попаданий в него можно достичь далеко не в каждом коде. ассоциатвность значима для потребления кэша? — весьма. Она определяет, сколько адресов надо одновременно проверять в тегах для каждого обращения. matik вычисляет адреса — Ну наконец-то. И как он это сделает без каких-либо начальных данных? — почему это без? Если это код — посмотрит в файле размер секции. Если данные — получит от самой программы, сколько ей надо. А карта размещения в ФП и подкачке у него и так под рукой. каждый раз (!). Каждую строку — не каждую, а читаемую. ЕСС не работает для спящих строк. Любые (!) обращения к кэшу вызывают срабатывание усилителей — верно, поэтому я и написал — «нет» (т.е. потребляют относительно много). ваши капризы переросли в "х86 ЦП" (кстати, они существуют) — они = многопортовые L2? И у кого же? Даже больше может быть: запрос от ФУ не обязательно единичный — если их больше, то они все в очереди и исполняются последовательно. Сколько на самом деле будет жрать ваш декодер, и будет ли СРЕДНЯЯ длина команды меньше - пока совершенно неизвестно — качественно можно точно определить, что меньше. И число команд тоже будет меньше. на две неравные (сообразно нагрузке, например) — здрасьте, так это уже не статическое, а динамическое разделение — ведь нагрузка меняется. я и утверждаю, что вы базируете ваши рассказы на дополнительных допущениях, которые сами по себе тоже не доказаны — допущения, помимо прочего, говорят, что все статически делимые структуры делятся именно пополам, даже если конкретно о кэше мопов у Зена так и не сказано. х86 внедрил, и захватил мир. Остальные не внедрили, и не захватили. Видите, предположение подтверждается фактами — вижу, что «позже не значит вследствие». Иначе — «99% людей, кто ели огурцы в 20-м веке — позже умерли; вывод: огурцы смертельно опасны для здоровья». Только ли из-за 80 бит х86 захватил мир? Конечно, нет, не только — точнее, «совсем не потому». Кстати, если уж говорить о гипотетических преимуществах некоего формата вещественных вычислений — у меня есть что предложить и по этому пункту безо всяких лишних битов. Зря вы не обратили внимание на «улучшенный IEEE-754» он дешевле других, он производительнее других, и при прочих равных он еще и точнее остальных — на тот момент он был не дешевле всех прочих и не производительнее всех. Что касается точности, то она и тогда, когда всё было скалярное, для EP доставалась большим числом тактов, чем для DP. А сегодня (с векторами) и подавно. для 80 бит производительность не будет отличаться от DP — вы категорически ошибаетесь. Почитайте хотя бы таблицы у Фога. На тот момент "нишмагли", да. Да и не знали, какой вариант будет мейнстримом. А сейчас смогли — где? 80 битные х86 будут ВЧЕТВЕРО быстрее, чем 64 битные. Потому что 64 битным железкам придется работать 128 битных данных, дабы догнать х86 — ха! Даже если бы точность была такой линейной, всё равно AVX+FMA намного быстрее (и даже точнее — при 128 битах). только-только отлаживаете физическую модель. Какие 16 векторов? Какие FMA? — а такие — автовекторизуемые ключами компилятора! Ценой более широкого умножителя — и не только его, а ещё кучи других структур + усложнение РФ. поставьте себе процессор без х87, посмеемся вместе — а он у меня и стоит. И у вас есть. И вообще, их во всём мире миллиарды — это все прочие ЦП, кроме х86. На них все Андроиды и Эплы Подозреваю, что расходы тепла на переключение при падении геометрических норм в 10 раз может составить и 100 раз, и 1000 раз — зря подозреваете. Вот примерные цифры на рисунке 1а: https://arxiv.org/ftp/arxiv/papers/1003/1003.4058.pdf . Хотя темпы укорочения длины затвора снизились, но 100-кратное уменьшение джоулей со времён 130-нм-ТП таки есть. И это не 1 пико, а 10 атто, что в 100'000 меньше. Реальная цифра, правда, куда больше. на помощь приходит процессор Skуlake-X, у которого при задействовании AVX-512 (и некотором разгоне, правда) тепловыделение в районе полукиловатта обнаружили — дааа? еще ни один человек не объяснил, зачем в процессоры закладывать существенное количество логики, которое бы "редко использовалось" — если не ошибаюсь, этот «ещё ни один» — вы Вы только забыли посмотреть, что мы с ним обсуждали ядро процессора. А на L3 он перескочил сам, ему так явно удобнее — так я и для L2 пересчитал, вы не видели? Одно срабатывание на 8192 такта. (Если 1 порт и 256 КБ.) Зачем переводить (!) профессиональные термины? — потому что: 1) надо согласовывать члены предложений; 2) надо понимать говоримое,не заглядывая в словари; 3) надо говорить на родном языке, чтобы он не перестал быть родным. |
Creed_md Member 7/1292 ответов, #141 врейтРСвЂВР Р…Р С–Р Вµ 10 лет на iXBT, с декабря 2014 Чаще Р С—Р СвЂВшет Р Р†"Видеосистема" (69%) Россия, Зеленоград | Felid А то мне оченно интересно, как это произошло, если даже СЖО не может отвести 500 Вт тепла с такой площади. Ну, допустим даже это было в течение 10 мс — но и для того надо, чтобы ВРМы подали на разъём 400+ ампер! Там FIVR и vccin 2 вольта. |
bess_temporary Member 89/89 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | Felid > по-вашему, уважение состоит в том, что вы добровольно отказываетесь от его использования, не переводя иностранные слова, которые притом запросто переводимы? Мое уважение к русскому языку заключается в том, что я не издеваюсь над ним. Как это делаете вы Насчет "добровольно отказываетесь от его использования" - это вранье. >> С показом исходного архитектурного состояния > — а зачем оно нужно именно в исходном состоянии? >> Кому нужен отладчик, который не отлаживает ? > — а вы собираетесь отлаживать программу без доступа к её исходному коду? Какой смысл обсуждать с вами тривиальные вещи ? Вы не программист и поэтому несете всякую ересь. Кроме того, эти вопросы уже затрагивались (в период вашего молчания), можете глянуть. >>> Вы можете эти стадии сделать параллельными в суперскаляре? >> — Легко > — и как же? Там не очень много сочетаний. И по сути нет никаких последовательных зависимостей. Тем более не надо ничего последовательно разбирать, как в предекодере. По сути все можно определить таблично. В планировщике сделаны намного более сложные вещи, но они вас почему-то не смущают. > Только не вспоминайте матричную структуру длиномера Матричную в каком смысле ? Что там есть несколько элементарных мини-декодеров ?? > это верно, но в случае своего совершения кто-то должен сообщить предсказателю, что́ именно сработало, а не только по какому адресу. Деодер этого все равно не знает. А сообщает ФУ - кто же еще ? > В частности АМДшники подтверждали это в описании Ягуара Кого волнует какой-то $раный "Ягуар" ? Да, два такта было - в K7/K8. Из-за этого минимальная латентность в FPU тоже составляла два такта. В P4/P4E было больше - в результате понадобился реплей. Что сейчас, непонятно. > а разве они кладутся компилятором не по давно известному общему шаблону? Наверное, сто компиляторов/линкеров кладут в сто мест, заведомо им известных. И сто отладчиков знают, где найти. Чем это поможет ? > вряд ли в распространённых и давно отлаженных массовых программах Ах, вы делаете архитектуру не для всех программ, а только для распространенных ! > не обязательно запихивать все 10-100 к/т в один поток. А вот если потоков будет 8-16, то уже куда веселее. Потоки можно сделать уже сейчас. Это совсем не то, что нужно. >> расплата --- низкая производительность однопотока > — а кого это волнует, когда для получения желанных петафлопсов этих потоков уже нужен миллион? Петафлопсы - это фетиш. Мало кому нужный. > свёрточная функция, наиболее случайно разбрасывающая строки по всем банкам L3 Наверное, вы все-таки имели в виду "наиболее равномерно". > надо говорить на родном языке, чтобы он не перестал быть родным. На фоне того, что бы наблюдаем вокруг (например, в рекламе), русскому языку грозит совсем другое. Уж никак не редкие технические термины. Каковые грамотны и неизвращенным человеком могут быть тривиально переведены (примеры можете найти в моей канонической статье, которая из трех частей)/ |
lkj Member 1435/1531 ответов22 года на iXBT, с июня 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (97%) | bess_temporary То есть вы согласны, что в статье наврано ? Согласен. И даже написал свое предположение о природе этой ошибки. Cavium рекламирует свой процессор, сравнивая его с Xeon Gold/Platinum. А если написать, что TX2 отстает в 3-4 раза по флопсам от прошлогоднего xeon, тогда возникают вопросы насчет этих флопсов и реальной производительности. И поэтому автор ошибочно преувеличил в два раза флопсы TX2 в статье. Он сделал в уме какой-то подсчет и выбрал ответ из двух вариантов, который показался более правдоподобным. Вдобавок два Epyc-а представляют собой восемь независимых кристаллов (можно сказать, процессоров), что немного помогает при выполнении независимых процессов. Xeon'ы в spec тестируют в режиме SNC. Это уже почти 4 независимых процессора. |
bess_temporary Member 90/90 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | lkj > А если написать, что TX2 отстает в 3-4 раза по флопсам от прошлогоднего xeon, тогда возникают вопросы насчет этих флопсов и реальной производительности. Как я уже ответил, не возникают. Ибо SPEC FP флопсов не замеряет. > Он сделал в уме какой-то подсчет и выбрал ответ из двух вариантов, который показался более правдоподобным. Он просто недостаточно компетентен, как и все авторы. > Xeon'ы в spec тестируют в режиме SNC. Это уже почти 4 независимых процессора. Да, примерно так. Но они все же не совсем независимые. Хотя процент или два могли выиграть. |
lkj Member 1436/1532 ответов22 года на iXBT, с июня 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (97%) | Тесты Spec 2017: https://www.hpcwire.com/2018/05/07/cavium-announces-…outs-oem-support/ Хорошие результаты для TX2, если подтвердятся. TX2 выигрывает по производительности int-rate у Centriq примерно в 1.2 раза. И ICC уже мощно натаскали на spec2017. |
deadlock Advanced Member Куратор теРСВВР РЋРІР‚в„– 2408/2629 ответов19 лет на iXBT, с января 2006 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (92%) Россия, Москва | lkj И ICC уже мощно натаскали на spec2017. Поэтому интересны результаты ARM HPC компилятора. Обещают +15% |
lkj Member 1437/1533 ответов22 года на iXBT, с июня 2002 Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (97%) | deadlock Поэтому интересны результаты ARM HPC компилятора. Обещают +15% Даже AMD свой компилятор натаскала сильнее для spec2017. У них там до 30% разницы от GCC или больше. Поэтому +15% в spec на "стероидах" для ARM не помогут сравнивать объективно со "стероидными" результатами intel/amd. Проще всех сравнить в GCC. Это лучше для оценки реального соотношения производительности, если смотреть тесты spec. Или нужно смотреть другие тесты, где нет такого натаскивания со стороны amd/intel. |
bess_temporary Member 91/91 ответов, #1 врейтРСвЂВР Р…Р С–Р Вµ 7 лет на iXBT, с января 2018 1 фото Р Р…Р В° iXBT.photo Чаще Р С—Р СвЂВшет Р Р†"Процессоры" (98%) Россия, iXBT.com c 1997 г. | lkj > 8180 GCC - 206 - моя оценка > 8180 GCC - 172 - моя оценка То есть просто так, занизили в полтора раза - и глазом не моргнули ? Какой смысл вы вкладываете в свои бредовые расчеты - или, правильнее сказать, фальсификации ? 6148 ICC - 216 - тесты cavium 6148 GCC - 146 - тесты cavium Или вы хотите сказать, что фальсификациями занимается Cavium, а вы - просто соучастник ? |