Часовой пояс: UTC + 3 часа




Форум закрыт Новая тема / Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней. Закрыто  Сообщений: 277 • Страница 11 из 14<  1 ... 8  9  10  11  12  13  14  >
  Пред. тема | След. тема 
В случае проблем с отображением форума, отключите блокировщик рекламы
Автор Сообщение
 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
NiTr0 писал(а):
Но зато находится куча желающих сравнивать производительность в линпаке/суперпи/прочих тестах, показывающих на деле производительность в весьма узком кругу задач

Круг узкий, а вот числа все ПО считает :) Это просто более специализированные алгоритмы.
NiTr0 писал(а):
То, что haswell быстрее nehalem в линпаке почти в 4 раза на одинаковой частоте - на самом деле совершенно не значит, что он сможет в 4 раза быстрее отрисовать html страничку, или открыть документ

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

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



Партнер
 

Member
Статус: Не в сети
Регистрация: 20.05.2007
Откуда: Россия
Alexsandr писал(а):
Но в ыелом это показывает в каких задачах можно ждать прироста.

:facepalm:


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
Подсказать может что-то если непонятно? грубо если кодировалось виде за счет "сопроцессора", пот потом за счет блоков SSE... и сейчас за счет аппаратных блоков. Скорость растет при этом. Сейчас огромная зависимость скорости в зависимости от конкретной реализации алгоритмов.


 

Member
Статус: Не в сети
Регистрация: 04.06.2004
Alexsandr писал(а):
Есть еще скорость памяти, движок браузера, которые очень сильно отличаются по скорости, скорость интернета, задачи которые нужно решить, какой набор команд можно использовать и и какой используется... Но в ыелом это показывает в каких задачах можно ждать прироста.

Угу, в задачах тупого умножения со сложением огромных массивов float чисел, и не более того :) в остальных задачах - прирост эдак на порядок меньше. Просто потому, что SSE/AVX в них нафиг не нужны и от того производительность этих блоков (собссно и измеряемая линпаком) там никого не волнует.

Alexsandr писал(а):
А что дадут циферки вашеотеста? Тоже ведь ничего.

Ну для того, для кого названия тестов просто набор букв - то да, ничего не дадут :) Для всех остальных - вполне себе показывают реальную производительность процессора в реальных классах задач.

Alexsandr писал(а):
грубо если кодировалось виде за счет "сопроцессора", пот потом за счет блоков SSE... и сейчас за счет аппаратных блоков.

Открою секрет: изначально, еще лет 20 назад, кодирование видео было на аппаратных блоках. Потом - ушли на ЦП банально из-за лучшего качества и роста производительности ЦП. Сейчас - опять возвращаются аппаратные блоки для пользовательского нищебродского сегмента, но о каком-либо серьезном их использовании речи не идет (не считая переконвертации сотен потоков для DVB-C/IPTV - там на качество плевать). В то время как серьезные кодеки/конверторы продолжают юзать программное кодирование.


 

Member
Статус: Не в сети
Регистрация: 19.05.2013
Alexsandr писал(а):
Да ну? Может мобильный чип занимается ускорением видео за счет голой производительности ЦП?


Это на ваших Core i7 видео кодируется на встройке Intel, а я кодировал на самих ядрах CPU !!! Сколько вам еще это нужно повторять?

Alexsandr писал(а):
В процессоре куча блоков, блоки предсказания, выборки, кеши, SSE... можно попытаться только посчитать по разным методикам и посмотреть на результат. Но вот от того как будет написано ПО будет зависеть скорость расчетов. Бывает что при замене алгоритма на другие команды скорость растет/падает на порядок.


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


Alexsandr писал(а):
Цифры то те которые ничего не показывают показывают как раз возможность вычислительную с определенным набором данных.


Если бы это было правдой, то процессор Intel в любых приложениях был быстрее и выполнял любые задачи на скорости калькулятора!!!

Alexsandr писал(а):
Есть где-то обзоры с сравнение скорости работы?


Что вам мешает сделать тесты самому? Я все тесты делал сам без оглядки на результаты бенчей. Берите любой проц на Cortex, ставьте Root права, устанавливайте любые проги и тестируйте..

А что касается мифического Linpack, то вот что пишет сама википедия:
(тот же LINPACK) с усреднением результатов, но со временем возможности компьютеров «перерастают» рамки принятого теста и он начинает давать искусственно заниженные результаты, поскольку не задействует новейшие возможности вычислительных устройств. А к некоторым системам общепринятые тесты вообще не могут быть применены, в результате чего вопрос об их производительности остаётся открытым.

Вот так, ваш LINPACK - просто пшик ! Единственной единицей, которая сегодня показывает реальную производительность и быстродействие самих ядер CPU - это MIPS. Зная количество операций/на такт в MIPS, сегодня это единственный достоверный способ сравнить точное время выполнения задач на разных архитектурах. Как я уже говорил, если бы FPU вычисления реально помогли ускорить задачи кодирования в 50 раз, то современные процессоры Intel i7 легко перекодировали и видео в 50 быстрее, и в играх бы загрузка была в 50 раз быстрее и т.д.. А на данном этапе именно от IPS зависит быстродействие работы процессора. Попробуйте конвертировать на Cortex A9, а потом на Cortex A15? Тогда вы поймете, что все дело только в IPS ! Именно в IPS'ах производители и наращивают свои новые архитектуры.
Выходит, что и Geekbench ничего не врет и показывает честные результаты, и ARM говорит правду, и AnandTech, Apple..
Если бы Geekbench опускал в своих тестах производительность процессоров Intel, это плохо кончилось бы для его создателей в суде, а саму программу тут же прикрыли.

P.S. Ваши "флопы'' - это сферический конь в вакууме, от которого нет никакой пользы ни в одном приложении. Причем даже если сравнивать между процессорами Intel i7 разных поколений, то и там разница будет до 20%. Возьмите старенький Core i7 930 - по LINPACK'у он 49.5 GFLOPS и сравните его с современными i7, у которых 250 GFLOPS. Разница между ними в "флопах" будет до 500% !!! Но ведь это же бред? Реальная разница в производительность между их ядрами около 10-15%! В более поздних архитектурах i7 просто сделали более быстрый кэш, который смог работать на равной частоте самих ядер, добавили поддержку более быстрой памяти ну и другие мелочи.. Все это и дало в общем приросте производительности до 20%.
НО НИ В ОДНОМ ИЗ ПРИЛОЖЕНИЙ ЭТО НЕ ДАЛО ПРИРОСТА В 500%, КАК ЭТО ПОКАЗЫВАЕТ LINPACK !!! Это еще раз доказывает всю абсурдность теста LINPACK.

Кстати, я вам уже давал ссылку на разоблачение результатов в бенчах Clovertrail Intel Atom, который так восхвалял "ваш" тестер из обзора? Так вот, теперь внимательно здесь почитайте и посмотрите видео, как древний Cortex A9 надругался над этим самым Clovertrail+ Intel Atom. И не забудьте это показать вашему тестеру пропагандисту-обзорщику из корпорации поддельных тестов Intel?


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
NiTr0 писал(а):
Угу, в задачах тупого умножения со сложением огромных массивов float чисел, и не более того в остальных задачах - прирост эдак на порядок меньше. Просто потому, что SSE/AVX в них нафиг не нужны

Все зависит от типа задачи. Задач разных очень много.
NiTr0 писал(а):
Ну для того, для кого названия тестов просто набор букв - то да, ничего не дадут Для всех остальных - вполне себе показывают реальную производительность процессора в реальных классах задач.

Реальные задачи это когда алгоритм, а то и код известен. Реализация и оптимизация под платформу тоже играют значение.
Вот смотри по аиде скорость процессора в AES 365 мб/с, по гикбенчу 293мб/с. т.е. погрешность составляет уже только на одном тесте 20% в сторону снижения на х86 результатов.

Jeter писал(а):
Так вот, теперь внимательно здесь почитайте и посмотрите видео, как древний Cortex A9 надругался над этим самым Clovertrail+ Intel Atom.

Сами хоть смотрели вашу ссылку? Два ядра против 4-х, не считая неизвестных памяти и скорости флешки, чатсота процуессорана совести тех кто заявил (можно разогнать ведь) +чужая территория для х86. Еще что интересно, задача ресурсоемкая для видео карты, а сравниваете вроде бы как процессора? Так видео сравниваете или нет? Сравнения в играх упираются в скорость флешки когда читались данные (а нам даже имя планшета не известно, тем более скоростные данные флешки и памяти) И все же до начала загрузки уровня отставание на секунды идет.
А вот отзыв владельца х86 планшета

вставлю свои пять копеек в это холивар, как владелец К900 на Clovertrail+ :
1) в зависимости от установленной версии Need For Speed ​​Most Wanted, имеем разное поведение игры на смарте: лично наблюдал у себя тормоза, как на видео, играть просто невозможно.
2) после установки последней версии с максимальной графикой с 4pda, тормоза пропали, игровой процесс соответствует показанному на видео от АРМ. никакого дискомфорта в игре не наблюдается.
3) это видео - тупая подтасовка фактов.

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


 

Member
Статус: Не в сети
Регистрация: 04.06.2004
Alexsandr писал(а):
Все зависит от типа задачи. Задач разных очень много.

Ок, в каких реальных задачах используется перемножение со сложением огромных массивов данных? :) А какие из этих задач не ускоряются на GPGPU, который на порядки более эфективен? Ну т.е. какому % аудитории эти попугаи линпака на самом деле будут интересны - можете ответить? :)

Alexsandr писал(а):
Реальные задачи это когда алгоритм, а то и код известен.

bzip2 - и алгоритм, и код известен. Алгоритм Дейкстры - опять же известен. Как и вычисление SHA. И т.п.

Alexsandr писал(а):
Реализация и оптимизация под платформу тоже играют значение.
Вот смотри по аиде скорость процессора в AES 365 мб/с, по гикбенчу 293мб/с. т.е. погрешность составляет уже только на одном тесте 20% в сторону снижения на х86 результатов.

Т.е. вы предлагаете брать заточенный под х86 код из аиды, и сравнивать его скорость с обычным кодом без спец.оптимизаций (ну кроме внесенных компилятором - версия которого одна и та же под все архитектуры, и параметры компиляции - тоже) из гикбенча? :) Умно, чо.


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
NiTr0 писал(а):
А какие из этих задач не ускоряются на GPGPU, который на порядки более эфективен? Ну т.е. какому % аудитории эти попугаи линпака на самом деле будут интересны - можете ответить?

Какому проценту аудитории интересно шифрование данных, или постоянное пережатие в png? Используется все вперемежку. Ну а судя по GPGPU, пережатие видео картой вновь в строю. что там по пережатию на АРМ и х86? про тесты выяснили, минимум на 20% тормозит универсальный тест.

NiTr0 писал(а):
bzip2 - и алгоритм, и код известен. Алгоритм Дейкстры - опять же известен. Как и вычисление SHA. И т.п.

Это не то. Можно написать по этим алгоритмам в разы отличающийся по скорости код. Сейчас на первом месте оптимизация кода.

NiTr0 писал(а):
Т.е. вы предлагаете брать заточенный под х86 код из аиды, и сравнивать его скорость с обычным кодом без спец.оптимизаций

А зачем на АРМ оптимизированный код сравнивать с не оптимизированным под х86? Вы хотите знать на что способен процессор? Тогда и тесты должны показать на что способен, а не показывать криворукость программистов. Тесты должны выжимать все до капли.

NiTr0 писал(а):
ну кроме внесенных компилятором - версия которого одна и та же под все архитектуры, и параметры компиляции - тоже) из гикбенча? Умно, чо.

Это проблемы любимого теста. Мы или тестируем возможности процессора или показываем насколько плохо написан код.


 

Member
Статус: Не в сети
Регистрация: 19.05.2013
Alexsandr писал(а):
Сами хоть смотрели вашу ссылку? Два ядра против 4-х


1. У меня даже в игре Real Racing 3 в смарте LG Optimus 4X HD загрузка шла до старта - НА ОДНОМ ЯДРЕ !!! Если вы не в курсе, там Tegra 3 с такими же ядрами Cortex A9. Даже в наши дни используется не более 2 ядер, а уж в те далёкие времена.. (см.скрин)
Загрузка ядер HTC One X Cortex A9 в NFS
Вложение:
HTC One X_NFS M.W.jpg

2. Процессор Intel Clovertrail не двухъядерный, в нём 2 физических + 2 виртуальных ядра! Как вы могли наблюдать на скрине, Cortex A9 загружает все данные в один поток на одном ядре ! А вот у Intel Clovertrail есть преимущество благодаря возможностям загрузки в 2 потока!

3. Процессор ARM работает на 20% более низкой частоте, чем Clovertrail !

4. Cortex A9 загрузил игру до старта за 48 сек, а Intel Clovertrail за 85 сек ! Иными словами, дохлый Cortex A9 почти в 2 раза быстрее! Так что про какие "считанные секунды" в разнице загрузке данных вы говорите ???

Кстати говоря, если в Geekbench прогнать топовый Haswell i7-4770 при равных частотах с Intel Clovertrail (2 ГГц), то последний будет слабее всего в 3-4 раза максимум. Вот только и новое ядро Cortex A72 производительнее старого Cortex A9 в те же несколько раз.
Из всего этого можно сделать вывод, что и будущий Cortex A72 сможет нагнуть мощный Haswell Core i7-4770. А если это случится, вы и дальше будете всё валить на алгоритмы, ПО, ОС и неверные бенчи? Если вам ARM говорит, что её процессоры лучше в любых приложениях, значит так оно и есть. Для чего ARM подделывать тесты в бенчах, подделывать быстродействие своих ядер в загрузке данных на видео? Если бы всё это было подделкой, то Intel за 3 сек уничтожила эту ARM вместе со всеми бенчиписателями! Ну а пока на подделках ловят Intel. ;)


У вас нет необходимых прав для просмотра вложений в этом сообщении.


 

Member
Статус: Не в сети
Регистрация: 20.06.2013
Jeter писал(а):
не двухъядерный, в нём 2 физических + 2 виртуальных ядра!

Пора лечить.


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
Jeter писал(а):
У меня даже в игре Real Racing 3 в смарте LG Optimus 4X HD загрузка шла до старта - НА ОДНОМ ЯДРЕ !!!

И? На чем сравнивали там вообще неизвестно, что был в памяти и сколько её тоже не ведомо, скорость флешки.... Впрочем слова владельца атома, где он писал, что все нормально на другой версии игры тоже пропустили.
Jeter писал(а):
Процессор Intel Clovertrail не двухъядерный, в нём 2 физических + 2 виртуальных ядра!

Там два ядра. И3 не называть же 4-х ядерным. виртуальные ядра иной раз несут замедление работы, что тоже нужно учитывать.
Jeter писал(а):
Cortex A9 загружает все данные в один поток на одном ядре ! А вот у Intel Clovertrail есть преимущество благодаря возможностям загрузки в 2 потока!

Загружает не процессор, а ПО, если игра не видит ядер, то не важно сколько там каких и чего.
На скриншоте не то место где атом застрял.
Jeter писал(а):
Процессор ARM работает на 20% более низкой частоте, чем Clovertrail !

там не были показаны частоты. Только подписи, что для маркетологов оставляет кучу свободного места. Процессора можно разогнать, можно уменьшить частоты.
Jeter писал(а):
Cortex A9 загрузил игру до старта за 48 сек, а Intel Clovertrail за 85 сек ! Иными словами, дохлый Cortex A9 почти в 2 раза быстрее!

Ошибка ПО показывает дохлость? Где на видео поверх экрана загрузка потоков и частота? До начала загрузки игры отставание 7сек, причем у АРМ 4-ре полноценных ядра, что нивелирует частоты с хорошим запасом. Почему не взяли 2-х ядреный проц? Результаты хуже? Почему не взяли другую версию игры без таких проблем?, а она ведь существует. Почему не прогнали тесты предварительно и не показали где какое железо стоит?
Jeter писал(а):
Из всего этого можно сделать вывод, что и будущий Cortex A72 сможет нагнуть мощный Haswell Core i7-4770.

Из всего этого можно сделать выводы, что в ARM хорошие маркетологи. Было бы чем хвастать, уже давно бы хвастали в открытую, а не скрывали данные тестов.

Вот вроде бы нормальные тесты, но архитектура А8. Впрочем интерполировать на А9 можно. http://www.vrworld.com/2011/05/19/the-c ... ersus-x86/


 

Member
Статус: Не в сети
Регистрация: 20.05.2007
Откуда: Россия
Alexsandr писал(а):
Вот вроде бы нормальные тесты, но архитектура А8. Впрочем интерполировать на А9 можно. http://www.vrworld.com/2011/05/19/the-c ... ersus-x86/

A8 очень древнее ядро, давно снятое с производства, впрочем как и другие участники этого теста.


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
Я в курсе, но это самое адекватное что нашел. С более современными ядрами тестов нет просто.


 

Member
Статус: Не в сети
Регистрация: 04.06.2004
Alexsandr писал(а):
Какому проценту аудитории интересно шифрование данных, или постоянное пережатие в png?

Шифрование интересно эдак 90% (HTTPS/HTTP2.0 весь шифрованный). Остальные задачи - целочисленные сложные нелинейные алгоритмы с большим кол-вом ветвей кода - позволяют судить о производительности процов в прочих подобных задачах. Всяко показательнее попугаев линпака, абсолютно бесполезных в реальном мире.

Alexsandr писал(а):
Ну а судя по GPGPU, пережатие видео картой вновь в строю. что там по пережатию на АРМ и х86?

На ура на арме все жмется аппаратными конверторами. FullHD 60fps армы научились жать в реалтайме намного раньше х86.

Alexsandr писал(а):
Это не то. Можно написать по этим алгоритмам в разы отличающийся по скорости код. Сейчас на первом месте оптимизация кода.

Повторяюсь: bzip2 - и алгоритм, и код известны. Стандарт де-факто, никто велосипед не изобретал.

Alexsandr писал(а):
А зачем на АРМ оптимизированный код сравнивать с не оптимизированным под х86?

А с чего вы взяли, что сравнивается разный код? Сравнивается один и тот же код, скомпилированный gcc под разные архитектуры. И эдак половина этого кода - стандартные библиотеки, которые писались изначально под х86.

Alexsandr писал(а):
Тесты должны выжимать все до капли.

С какой такой радости? Тестируется производительность на одной и той же задаче, одного и того же кода (скомпилированного под разные архитектуры), с одним и тем же результатом на выходе. И именно этот результат будет самым объективным.

Alexsandr писал(а):
Мы или тестируем возможности процессора или показываем насколько плохо написан код.

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


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
NiTr0 писал(а):
Шифрование интересно эдак 90% (HTTPS/HTTP2.0 весь шифрованный).

И конечно его обработка у ЦП занимает 80% времени? что с поддержка блока шифрования, что без, интернет быстрее не работает.
NiTr0 писал(а):
Остальные задачи - целочисленные сложные нелинейные алгоритмы с большим кол-вом ветвей кода - позволяют судить о производительности процов в прочих подобных задачах.

подобных? Боюсь там классы разных задач подходящих под этот алгоритм.
NiTr0 писал(а):
На ура на арме все жмется аппаратными конверторами. FullHD 60fps армы научились жать в реалтайме намного раньше х86.

т..е "внешние" блоки ЦП таки считаются самим ЦП.

NiTr0 писал(а):
Повторяюсь: bzip2 - и алгоритм, и код известны.

Если известны и других вариантов нет, то почему разная скорость? Реализация разная алгоритма?

NiTr0 писал(а):
А с чего вы взяли, что сравнивается разный код? Сравнивается один и тот же код, скомпилированный gcc под разные архитектуры.

блин, я уже устал. Один и тот же автомобиль на разных сборка дает разныйрезультат. А у нас разное оборудование для сборки, разные конвеера... Под каждую архитектуру/компилятор есть свои нюансы существенно влияющие на скорость. Даже банально помнится были галочки компилировать для скорости или для экономии места. Не считая других "авто" настроек. Но главное, не факт, что одинаковый бква в букву алгоритм будет оптимален для другой архитектуры.

NiTr0 писал(а):
С какой такой радости? Тестируется производительность на одной и той же задаче,

Давайте тогда тестить на коде для 286 процессора. ЗАчем нам улучшения и расширения? Если мы хотим показать на что способен процессор, то будьте добры оптимизировать код и очень тщательно оптимизировать. Это как раз и будет показателем на что способен процессор. А без оптимизации мы может смотреть на то, насколько коряво можно писать код, что бы он выполнялся в разы медленнее возможного.
NiTr0 писал(а):
Вот именно - потому, что тестируем процессор, а не реализации алгоритмов

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

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


 

Member
Статус: Не в сети
Регистрация: 04.06.2004
Alexsandr писал(а):
И конечно его обработка у ЦП занимает 80% времени?

Видеопоток 20-30 мбит довольно-

Alexsandr писал(а):
что с поддержка блока шифрования, что без, интернет быстрее не работает.

Какой брауер юзает блок шифрования? :) И где блок шифрования на атомах/целеронах ULV?

Alexsandr писал(а):
подобных? Боюсь там классы разных задач подходящих под этот алгоритм.

Если процессор А быстрее процессора Б в архивации/алгоритме Дейкстры/прочем подобном в 2 раза - с достаточной уверенностью можно утверждать, что и в обработке сложных макросов ворда-экселя, и в компиляции он будет примерно в 2 раза быстрее. В отличие от линпака, для которого разность между нехалемом и хасвеллом в 10 раз на той же частоте, при этом в реальных задачах прирост нужно искать под микроскопом.

Alexsandr писал(а):
т..е "внешние" блоки ЦП таки считаются самим ЦП.

С какой радости? Это вы почему-то постоянно хотите сравнить как не DSP довесок к процессору, так размещенный на кристалле видеокодек :)

Alexsandr писал(а):
Если известны и других вариантов нет, то почему разная скорость? Реализация разная алгоритма?

Где разная скорость?

Alexsandr писал(а):
блин, я уже устал. Один и тот же автомобиль на разных сборка дает разныйрезультат. А у нас разное оборудование для сборки, разные конвеера... Под каждую архитектуру/компилятор есть свои нюансы существенно влияющие на скорость. Даже банально помнится были галочки компилировать для скорости или для экономии места. Не считая других "авто" настроек. Но главное, не факт, что одинаковый бква в букву алгоритм будет оптимален для другой архитектуры.

Глобальные настройки оптимизации (оптимизация по размеру/по скорости) - те же. Или вы считаете, что автор geekbench ввиду своих садистских наклонностей собирает код под x86 с -Os, а под ARM - с -O3?

Alexsandr писал(а):
Давайте тогда тестить на коде для 286 процессора. ЗАчем нам улучшения и расширения? Если мы хотим показать на что способен процессор, то будьте добры оптимизировать код и очень тщательно оптимизировать. Это как раз и будет показателем на что способен процессор. А без оптимизации мы может смотреть на то, насколько коряво можно писать код, что бы он выполнялся в разы медленнее возможного.

Ну гоняют же сегодня некрофилы SuperPI - и ничо. Вон, одному из них SuperPI вообще эталоном измерения производительности процессоров кажется - и пофиг что классический FPU сейчас особо никого не волнует :)
И да, разница в быстродействии между сборкой под пентиум 2 и сборкой под распоследний core обычного кода (будь то компилятор, или архиватор, или еще что) - едва ли % 10 наберется. Не верите - можете сами собрать тот же 7zip и проверить.

Alexsandr писал(а):
блин, я уже устал. Один и тот же автомобиль на разных сборка дает разныйрезультат. А у нас разное оборудование для сборки, разные конвеера... Под каждую архитектуру/компилятор есть свои нюансы существенно влияющие на скорость. Даже банально помнится были галочки компилировать для скорости или для экономии места.

Очевидно же - устанавливаются флаги для сборки/оптимизации под определенную архитектуру.

Alexsandr писал(а):
Если мы хотим показать на что способен процессор, то будьте добры оптимизировать код и очень тщательно оптимизировать.

Ну-ну пример оптимизации в студию. Можете взять тот же ffmpeg к примеру, и найти в его коде те самые волшебные оптимизации. А еще лучше - 7zip/gzip/bzip2/lzma. Ссылки на репозитории дать, или сами найдете? :)

Alexsandr писал(а):
т.е. для пережатия видео нужно тестить на х386 коде ПО, а в то время как реальные программы будут использовать все возможности и работать на порядки быстрее.

bzip2 - реальная программа. А не работает на порядки быстрее.
И с чего у вас уверенность, что код собран именно под i386?


 

Member
Статус: Не в сети
Регистрация: 19.05.2013
Alexsandr писал(а):
На чем сравнивали там вообще неизвестно


А какая разница? Все ядра Cortex A9 загружают игру NFS до старта за 48 сек! Видео можете глянуть на YouTube..

Alexsandr писал(а):
Впрочем слова владельца атома, где он писал, что все нормально


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

Alexsandr писал(а):
Загружает не процессор, а ПО


Нет! Загружает именно процессор, а ПО лишь управляет!

Alexsandr писал(а):
На скриншоте не то место где атом застрял.


На скрине не Atom, там Cortex A9 загружает игру NFS на одном ядре! Повторяю ещё раз, у других владельцев игра NFS на ядре Cortex A9 загружается за те-же 48 сек, как и на видео от ARM ! Так что все ваши нападки в адрес ARM на подтасовку результатов безосновательны !

Alexsandr писал(а):
До начала загрузки игры отставание 7сек.


Посмотрите видео ещё раз внимательно! На видео Cortex A9 загрузил игру до старта всего за 48 сек, а Intel Clovertrail загружал данные 85 сек !

Alexsandr писал(а):
Почему не взяли 2-х ядреный проц?


А какой смысл в 2, 4 или 8 ядрах? Когда до вас дойдёт, что игра грузилась на одном ядре ! Я же вам фотку скинул? Там чётко видно, что 3 из 4 ядер во время загрузки спят ! Так каких ещё доказательств вам нужно ?


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
Jeter писал(а):
А какая разница? Все ядра Cortex A9 загружают игру NFS до старта за 48 сек!

На атоме по словам владельцев тоже самое, но на другой версии игры. затык на видео произошел когда стал сам уровень грузиться.
Jeter писал(а):
Пусть он сделает видео, на котором во время загрузки игры NFS будет наглядно видна загрузка ядер?

Загрузку с просмотром частоты и ядер и нагрузки на ядра должны были сделать в ARM.
Jeter писал(а):
Нет! Загружает именно процессор, а ПО лишь управляет!

процессор не будет делать 1 ил 2 или больше потока если ПО не поддерживает этого.
Jeter писал(а):
На скрине не Atom, там Cortex A9 загружает игру NFS на одном ядре!

Уточню, именно в том месте, из всех этапов загрузки было занято 1 ядро, но не факт что везде так было. Видео нет.
Jeter писал(а):
Повторяю ещё раз, у других владельцев игра NFS на ядре Cortex A9 загружается за те-же 48 сек, как и на видео от ARM

Повторяю на другой версии игры атом грузится сравнимо.
Jeter писал(а):
А какой смысл в 2, 4 или 8 ядрах? Когда до вас дойдёт, что игра грузилась на одном ядре !

По видео не видно сколько ядер грузит, и это одна из странных недоработок ARM.

NiTr0 писал(а):
Видеопоток 20-30 мбит довольно-

довольно для чего? Для загрузки декодировщика видео или для загрузки расшифровкой?
NiTr0 писал(а):
Если процессор А быстрее процессора Б в архивации/алгоритме Дейкстры/прочем подобном в 2 раза - с достаточной уверенностью можно утверждать, что и в обработке сложных макросов ворда-экселя, и в компиляции он будет примерно в 2 раза быстрее.

посмотрите на скорость винрар в разных версиях, прогресс медленно но идет.
NiTr0 писал(а):
С какой радости? Это вы почему-то постоянно хотите сравнить как не DSP довесок к процессору, так размещенный на кристалле видеокодек

Потому, что сейчас по другому не получается. ARM тоже далеко не только процессор на чипе.
NiTr0 писал(а):
Где разная скорость?

в AES в разном ПО скорость отличается на 20%.
NiTr0 писал(а):
Или вы считаете, что автор geekbench ввиду своих садистских наклонностей собирает код под x86 с -Os, а под ARM - с -O3?

В виду своих наклонностей код под х86 не оптимален.
NiTr0 писал(а):
И да, разница в быстродействии между сборкой под пентиум 2 и сборкой под распоследний core обычного кода (будь то компилятор, или архиватор, или еще что) - едва ли % 10 наберется.

прогнал кучку версий супер пи. Результаты интересны, от 13сек. до 10сек. (хвосты я не беру) % посчитаете сами прирост от изменения кода на одном и том же алгоритме? Даже если алгоритм такой простой и разницы не будет в скорости?

NiTr0 писал(а):
Не верите - можете сами собрать тот же 7zip и проверить.

Блин, еще раз пишу, важно не только собрать, важно иной раз поменять команды на другие. Смысл будет тот же, а вот скорость нет. Грубо алгоритм если-то можно делать как минимум двумя вариантами, и разница может достигать не один десяток процентов. Все связано, а сам компилятор не справится переводить все на оптимальный язык команд.

NiTr0 писал(а):
И с чего у вас уверенность, что код собран именно под i386?

Смотря на 20% отставание только в одном тесте видно что что-то не так в королевстве.


 

Member
Статус: Не в сети
Регистрация: 04.06.2004
Alexsandr писал(а):
довольно для чего? Для загрузки декодировщика видео или для загрузки расшифровкой?

Расшифровкой. Декодировка аппаратная.

Alexsandr писал(а):
посмотрите на скорость винрар в разных версиях, прогресс медленно но идет.

Т.е. вы предлагаете поставить на одной машине винрар 3, и сравнить производительность с винраром 5 на другой машине? А смысл от этого? :)

Alexsandr писал(а):
Потому, что сейчас по другому не получается.

Религия не позволяет что ли? :)

Alexsandr писал(а):
ARM тоже далеко не только процессор на чипе.

Вас кто-то заставляет использовать дополнительные ускорители в сравнении производительности процессорных ядер? Или х86 в чисто вычислительной производительности для вас слишком тускло смотрится на фоне арма? :)

Alexsandr писал(а):
в AES в разном ПО скорость отличается на 20%.

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

Alexsandr писал(а):
В виду своих наклонностей код под х86 не оптимален.

С какой такой радости? Потому то вам не нравится низкая производительность х86 на фоне арма? :)

Alexsandr писал(а):
прогнал кучку версий супер пи. Результаты интересны, от 13сек. до 10сек. (хвосты я не беру) % посчитаете сами прирост от изменения кода на одном и том же алгоритме? Даже если алгоритм такой простой и разницы не будет в скорости?

А с чего вы взяли что реализация алгоритма одна и та же?
Прогоните все версии на пентиуме 1 - увидите примерно ту же разницу производительности. Потому что разные реализации алгоритма, а может - и разные компиляторы вносят свою долю (так, MSC по сравнению с GCC может и двукратно ухудшить производительность). Но мы же кажется сравниваем производительность процессоров, а не качество компиляторов/особенности реализации алгоритмов?

Alexsandr писал(а):
Блин, еще раз пишу, важно не только собрать, важно иной раз поменять команды на другие. Смысл будет тот же, а вот скорость нет. Грубо алгоритм если-то можно делать как минимум двумя вариантами, и разница может достигать не один десяток процентов. Все связано, а сам компилятор не справится переводить все на оптимальный язык команд.

Хорошо, где и как вы предлагаете "поменять команды на другие"? Примеры в студию.

Alexsandr писал(а):
Все связано, а сам компилятор не справится переводить все на оптимальный язык команд.

Т.е. в вашем воображаемом мире до сих пор все массово программируют на ассемблере ради "оптимизации", так?
Хочу вас разочаровать - ваш мир не имеет никакого отношения к реальности...

Alexsandr писал(а):
Смотря на 20% отставание только в одном тесте видно что что-то не так в королевстве.

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

P.S. Глупо пытаться спорить о том, в чем вы не имеете даже базовых понятий...


 

Member
Статус: Не в сети
Регистрация: 02.02.2004
Откуда: Украина.
NiTr0 писал(а):
Т.е. вы предлагаете поставить на одной машине винрар 3, и сравнить производительность с винраром 5 на другой машине? А смысл от этого?

Смыл увидеть на что способна новая машина. Если она способна работать с новой версией ПО, которая быстрее, то зачем использовать старое ПО?

NiTr0 писал(а):
Вас кто-то заставляет использовать дополнительные ускорители в сравнении производительности процессорных ядер? Или х86 в чисто вычислительной производительности для вас слишком тускло смотрится на фоне арма?

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

Зачем? Зачем использовать алгоритм 1-го пентиума, ели можно использовать алгоритм с SSE + многопоточность? Мы хотим показать на что способен процессор или на что способна программа на разных процессорах без оптимизаций? Второе похоже, но какое отношение имеет к этому тест который должен показать что можно выжать с процессора?

NiTr0 писал(а):
С какой такой радости? Потому то вам не нравится низкая производительность х86 на фоне арма?

Приведите примеры тестов,не видео где версия ПО не подошла и неизвестно ничего, а нормальные тесты, как для ядра А8.

NiTr0 писал(а):
А с чего вы взяли что реализация алгоритма одна и та же?
Прогоните все версии на пентиуме 1 - увидите примерно ту же разницу производительности.

На пентиуме нет SSE, просто не запустится программа. И да, код версии 1.1, изменение было в других версиях. А если совместить изменение кода+SSE, то полагаю скорость возрастет еще больше.

NiTr0 писал(а):
Т.е. в вашем воображаемом мире до сих пор все массово программируют на ассемблере ради "оптимизации", так?

я про ассемблер не писал, это уже ваше воображение. Алгоритм пока-то и если-то во многом взаимозаменимы, а скорость выполнения может отличать довольно сильно. Это только один пример.
NiTr0 писал(а):
Опять вы сравниваете разные реализации алгоритма...

Я сравниваю производительность, если какое-то ПО не показывает его в нормально, то мне все равно насколько там корявый алгоритм реализован. Важна производительность, а не как выполняет один и тот же код на разных платформах. Это уже отдельный тест эффективности платформ при определенном алгоритме.

Ну и жду теста на со сравнением АРМ-х86. Не видео, где даже железо не опознать, а нормального тестов.


Показать сообщения за:  Поле сортировки  
Форум закрыт Новая тема / Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней. Закрыто  Сообщений: 277 • Страница 11 из 14<  1 ... 8  9  10  11  12  13  14  >
-

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB | Kolobok smiles © Aiwan