x86 против arm, power, sparc, gpu, cell и других. (часть 4)
(Продолжение темы здесь)

Версия для печати (стр. 10)

Конференция: Конференция iXBT.com (http://forum.ixbt.com/)
Форум: Процессоры (http://forum.ixbt.com/?id=8)
URL: http://forum.ixbt.com/topic.cgi?id=8:23952

Время GMT +03. Даты в формате dd.mm.yyyy.

Страницы: назад · 1 2 3 5 6 7 8 9 10 11 12 13 14 15 49 50 51 · далее / все сообщения темы на одной странице

904. T-5000, 03.11.2012 07:21
ABR
вот это фейл а15) армофилы писают кипятком наверное

А феил-то где? В Google Octane и в Mozilla Kraken Exynos @ 1,7 GHz вздул Атом @ 2 GHz на 30-34%

905. -=GunFighter=-, 03.11.2012 10:08
T-5000
А феил-то где?
В том, что битва идёт на поле ARM.

906. T-5000, 03.11.2012 11:21
XSol
Бедный йорик Атом, порвали как грелку. Вот они, разы на одном потоке
Да он его просто покрыл как бык овцу
Сейчас у интелофилов случится разрыв шаблона.

907. ABR, 03.11.2012 12:39
ну армофилы так сильно писают кипятком, что даже фейла не могут заметить, http://www.engadget.com/2012/11/02/nexus-10-review/, гляньте на таблицу результатов, и заметить какой слабый прирост а15 дал по сравнению к а9, зато какое какое эноргопотребление!!!!!!!!! сожрать 40ват*час за 7.5 часов это надо уметь, не смотря на экран, это уже говорит о том, что с небольшим ростом производительности, энергопотребление, растет гораздо быстрее, и чем дальше-хуже, , а если смотреть на квад краит, то волосы встают дыбом.
Сам по себе RISC вещь очень спорная, помню где-то была статья о том что интел смесь CISC и RISC? и этот симбиоз гораздо лучше чем чистая RISC

Про сервера HPC говорил не я вам, так что я не в курсе .

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

Про видео вы наверное толком не смотрели, в реальном времени атом быстрей работает эксииноса 4412, и таких примеров можно найти на ютубе уйма.

908. derek_keiz, 03.11.2012 12:50
ABR
Эта песня хороша начинай сначала
XSol
Пожалел бы бедных.
А то на ананде дальше санспайдера не смотрел. Когда у одних результат теста - 1450, а у других 1200... Смотреть на 1450 как то не интересно.

909. Gull, 03.11.2012 12:55
цитата:
XSol:
http://browser.primatelabs.com/geekbench2/compare/1232504/1192984
Бедный йорик Атом, порвали как грелку. Вот они, разы на одном потоке
Nexus 10 vs Bobcat AMD E-350 1600MHz (http://browser.primatelabs.com/geekbench2/compare/1232504/521846)

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

910. nenin, 03.11.2012 14:02
цитата:
XSol:
http://browser.primatelabs.com/geekbench2/compare/1232504/1192984
Бедный йорик Атом, порвали как грелку. Вот они, разы на одном потоке
Nexus 10 vs Bobcat AMD E-350 1600MHz (http://browser.primatelabs.com/geekbench2/compare/1232504/521846)
цитата:
AMD E-350 @ 1.60 GHz 1 processor, 2 threads
Intel Atom Z2480 @ 2.00 GHz 1 processor, 2 cores
- как бы все ясно.

911. XSol, 03.11.2012 14:33
nenin
Как бы да - http://www.ixbt.com/cpu/amd-zacate-vs-atom.shtml
Е350 - кол-во ядер/потоков вычисления 2/2
Откуда бы у Е350 взялись двукратные приросты без НТ и другого ядра на многопоточных бенчах? К тому же в браузере Гикбенча можно найти более свежие двух ядерные АМДешные процессоры на равной частоте все-равно проигрывающие пятому Эксиносу

912. T-5000, 03.11.2012 14:43
ABR
помню где-то была статья о том что интел смесь CISC и RISC? и этот симбиоз гораздо лучше чем чистая RISC

Автор, не пиши больше, а то я умру со смеху.

913. Boris Usievich, 03.11.2012 15:15
ABR
гораздо лучше чем чистая RISC
чистых RISC давно не осталось

914. nenin, 03.11.2012 15:24
цитата:
XSol:
nenin
Как бы да - http://www.ixbt.com/cpu/amd-zacate-vs-atom.shtml
К тому же в браузере Гикбенча можно найти
Я так думаю, что в местах, где ядра сосчитать не могут, можно найти все что угодно. Спасибо за ссылку, некоторое время тому я типа нетбука на закате окучивал и что это такое, представляю как наяву. Win7 Home 64, Office, Mathematica, Origin - не шустрит, но работать можно. Ну и Радеон... сами понимаете.

915. ABR, 03.11.2012 15:42
T-5000 смотрите не умрите, а то мне с кого сметься-то, как раз таки клоуните вы здесь, типо SPECint многопоточный, ваши же мысли, да и если поискать в данной теме в третьей ее части где-то давали ссылку и факты, что интел ядра сложно назвать чистыми CISC.

Да кстати сам тест гикбенч один из голимейших тестов синтетических, которые совершенно не отражают реальной картины, чего стоит разница между коре 2500к и 3570к в 2 раза
http://browser.primatelabs.com/geekbench2/1236834
http://browser.primatelabs.com/geekbench2/1236791

да и еще огромная зависимость от самой ОС, например под OS X резалты примерно на 3000 тыс выше чем на винде, на одном и том же железе, а сравнивать с разными ОС так вобще бред. Не верите так покопайтесь в базе сами.
Даже обзорщики его не применяют для тестирования.

В этом смысле SPECint 2000 ГОРАЗДО показательнее, и скольк армофилам не объясняй они все равно в первую очередь хватаются именно за этот тест. НУ XSol похоже хоть тыкай видео, где реал-тайм видно что атом быстрей арм, им пофиг))

А теперь смотрю армофилы про энеропотребление замолчали))) действительно, ведь , как я уже писал, сожрать батарею 40ват*час за 7.5 часов надо постараться, если брать в расчет эксинос 5250

916. Mumie01, 03.11.2012 16:00
XSol
Вы смешной(с), уж не вы ли этот серьезный "дядя", или чего еще лучше ABR? Где вы нашли в моих словах упоминания "покупающих HPC сервера"? Или результаты мобильных Атомов в SPEC2K Интел публикует для "покупающих HPC сервера"?

А где вы говорили про "мобильный атом"? В вашем посте (http://forum.ixbt.com/topic.cgi?id=8:23952:883#883) я вижу только обобщения.

Намек, там есть еще HTC OneX AT&T с тем же Квалкомовским чипом
Дермецо это ваш HTC OneX AT&T по работе от батареи.
600x300, 55.5Kb
600x300, 88.6Kb

917. T-5000, 03.11.2012 17:22
Mumie01
Дермецо это ваш HTC OneX AT&T по работе от батареи.

2000 mAh у Моторолы против 1800 у HTC ?

Да и на счет "3G Talk time" тоже есть огромные сомнения, что криворукие "тестеры" тестили OneX именно в режиме WCDMA, а не скажем в LTE.
Да и разрешение экрана у OneX несколько поболее будет.

В общем вы ногами в жир попали с таким сравнением.

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

918. Mumie01, 03.11.2012 17:37
T-5000
В общем вы ногами в жир попали с таким сравнением.
Собственно интелофилы по другому сравнивать и не умеют.


Видимо армофилы читать не умеют. Если вам не нравится сравнение - обращайтесь к XSol (http://forum.ixbt.com/topic.cgi?id=8:23952:903#903) - это он пожелал сравнивать с HTC. Ему не понравилось сравнение с Razr M (у которого батарея и экран идентичны Razr i).

Добавление от 03.11.2012 17:50:

Кстати, по поводу geekbench. Вот такая интересная дискуссия (http://support.primatelabs.com/discussions/geekbench/641-image-processing-tests-on-windows) :

- what is wrong with the four image processing tests on windows?

- Visual Studio 2010 (the compiler used to build Geekbench for Windows) has some issues generating efficient code for the image processing tests for modern Intel processors. Unfortunately there's no way to address this in Geekbench 2 without invalidating all previous benchmark results.

- can you use a different compiler?

- Geekbench uses the standard compiler on each platform (Visual Studio on Windows, Xcode on Mac OS X and iOS, GCC on Linux and Android). Switching to the same compiler across all platforms would ignore the important effect that the compiler has on processor performance on each platform.


Ну и о каком межплатформенном сравнении можно говорить (учитывая, что первая х86 была скомпилированна лет 6 назад с gcc 4.0 и даже неизвестно или arm версия использует те же флаги оптимизации).

919. XSol, 03.11.2012 17:51
Mumie01
А где вы говорили про "мобильный атом"? В вашем посте я вижу только обобщения.
Помоему мы здесь уже которую страницу говорим только о мобильных чипах

Если вам не нравится сравнение - обращайтесь к XSol - это он пожелал сравнивать с HTC. Ему не понравилось сравнение с Razr M (у которого батарея и экран идентичны Razr i).
Выискивать результаты под свои теории - бред, что ж вы тогда постеснялись привести результаты gsmaren'ы для того же Razr M
http://st.gsmarena.com/vv/reviewsimg/motorola-droid-razr-m/gsmarena_001.jpg - 600x300, 79.0Kb
Вам не понравилось, что они намеряли большее время браузинга и воспроизведения видео для Razr M?

920. nenin, 03.11.2012 18:05
цитата:
Mumie01:
Кстати, по поводу geekbench. Вот такая интересная дискуссия (http://support.primatelabs.com/discussions/geekbench/641-image-processing-tests-on-windows) :
Знатные попугайщики.

921. Chocky, 03.11.2012 20:55
цитата:
ABR:
T-5000 смотрите не умрите, а то мне с кого сметься-то, как раз таки клоуните вы здесь, типо SPECint многопоточный, ваши же мысли, да и если поискать в данной теме в третьей ее части где-то давали ссылку и факты, что интел ядра сложно назвать чистыми CISC.
Проблема в том, мусью, что сама по себе классификация RISC-CISC практически неприменима к этим процессорам.
Что такое CISC? Небольшое количество регистров, регистры неравноправные, куча инструкций "на все случаи жизни". x86-64 с 16 равноправными регистрами общего назначения и ещё 16 SIMD-регистров (если не больше, не в курсе про AVX), многие особые команды объявлены устаревшими или вообще выкинуты. В общем-то из CISC остаётся только разная длина инструкций.
Что такое RISC? Много равноправных регистров, минимум команд, простые команды 1-к-1, постоянная длина инструкции, дополнительные архитектурные ограничения созданные для упрощения реализации. И смотрим на современный арм, с декодером, внеочередным исполнением, кучей дополнительных специализированных сопроцессоров, таким же количеством регистров как и x86, невыравненым доступом к памяти. Где тут RISC?
Обе эти архитектуры занимают промежуточное положение между RISC и CISC, разница только в том, что одна жрёт чуток побольше и работает чуток быстрее, а другая наоборот, но, подозреваю, это определяется не архитектурой.

922. ssvb, 03.11.2012 21:22
Chocky
http://ru.wikipedia.org/wiki/RISC - "Позднее было отмечено, что наиболее значимая характеристика RISC в разделении инструкций для обработки данных и обращения к памяти — обращение к памяти идёт только через инструкции load и store, а все прочие инструкции ограничены внутренними регистрами. Это упростило архитектуру процессоров: позволило инструкциям иметь фиксированную длину, упростило конвейеры и изолировало логику, имеющую дело с задержками при доступе к памяти, только в двух инструкциях. В результате RISC-архитектуры стали называть также архитектурами load/store."

У ARM используются отдельные инструкции для load/store и отдельные для трехоперандной арифметики. У x86 мухи и котлеты вместе - двухоперандная арифметика, один из операндов может быть значением из памяти. Что касается переменной длины инструкций, то у ARM она сейчас тоже переменная (2 или 4 байта в thumb2 режиме).

923. XSol, 03.11.2012 21:23
Mumie01
Ну и о каком межплатформенном сравнении можно говорить
И что же мешает сравнивать с Атомом на Андроиде хотелось бы знать?

924. ABR, 03.11.2012 22:36
XSol
А тем что происходит перекомпиляция кода для x86, поэтому и низкий резалт, так как версия бенча под андроид была изначальна написана на арм. И хватит уже приводить гикбенч в пример, т.к эта самая убогая синтетика, я приводил пример где разница между кор 2500 и 3570 аж два раза)))))))
Вы все ну никак не угомонитесь. Когда вышел атом с 2.3.6 андроидом то он работал через какие-то костыли, и долго думал даже когда просто путешествуешь по ОС, сейчас же версия 4.0 без костылей, и я уже приводил видео где невооруженным глазом видно что атом работает быстрее арм, да и видео такое не едничное, на ютубе этих примеров куча.

А тем временем http://www.mobiset.ru/news/text/?id=22464 Lava Mobile XOLO X700 - недорогой Android-смартфон на платформе Intel z2420 1.2GHz

Уже седьмой на интел что весьма не плохо на рынке, на который ты опоздал на полтора года. На арм то тоже есть сервера, но только ниодного в коммерческих продажах, тестово есть.

Всем понятно почему интел лезит на рынок смартов/планшетов. Да здесь прибыль с одного чипа невелика, зато кол-во большое. А почему же производители арм лезут на рынок с арм чипами? Вот тут армофилы думают что из-за их превосходной производительности и низкого потребления. А как раз и нет. Дело в том что интел в месяц получает 1.1млрд долларов в месяц чистой прибылью. Да и на рынке серверов нет такой конкуренции и прибыль с одного процессора можно больше получить. Вот и лезут, облизываясь на доход интел. Но когда calxeda продемонстрировала свое УГ, которое не смогло загрузить жесткий диск даже запросами(или что то другое, непомню) тут то и стало видно, что это за шлак.

925. XSol, 03.11.2012 22:59
ABR
А тем что происходит перекомпиляция кода для x86, поэтому и низкий резалт, так как версия бенча под андроид была изначальна написана на арм
Лол, какая перекомпиляция, все там под Х86 изначально, сами тесты появились значительно раньше на Винде, писали их под Х86, после чего уже допиливали интерфейс для Андроидовской версии и компилировали тесты под Х86 и АРМ

т.к эта самая убогая синтетика, я приводил пример где разница между кор 2500 и 3570 аж два раза)))))))
Это не пример, это чушь, подобные "примеры" я могу подобрать для любого бенчмарка, а что вы хотели, что бы бенчмарк мог угадать любую конфигурацию с любыми твиками?

Уже седьмой на интел что весьма не плохо на рынке, на который ты опоздал на полтора года
Очередная поделка на убогом референсном дизайне. Дело не в кол-ве "дизайнов", а в том каким тиражом они разойдутся, Интел променяли бы сотню таких "дизайнов" на один с популярностью GSIII

926. ssvb, 03.11.2012 23:05
Chromebook XE303 приехал (Exynos5250, dual Cortex-A15 @1.7GHz)

код:

$ gcc -O2 -fprefetch-loop-arrays -fopenmp -mcpu=cortex-a15 -o stream stream.c && ./stream

Function Rate (MB/s) Avg time Min time Max time
Copy: 6037.6846 0.0053 0.0053 0.0053
Scale: 6377.0479 0.0050 0.0050 0.0050
Add: 5338.6702 0.0091 0.0090 0.0091
Triad: 5273.0904 0.0091 0.0091 0.0092

Ну и простые тесты дают результаты: memcpy - ~3GB/s, memset - ~6GB/s. Т.е. из теоретических 12.8GB/s ПСП для ARM процессора реально доступна уже где-то половина. Это примерно трехкратное улучшение по сравнению с Exynos4412, и двухкратное улучшение по сравнению с моим стареньким Atom N450. Латентность памяти и L2 кэша осталась приблизительно такая же, как и у Exynos4412.

Бенчмарк 7-zip (http://www.7-cpu.com/) даёт следующие результаты:
код:

$ ./7za b -mmt=1

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 902 MB, # CPU hardware threads: 2
RAM usage: 419 MB, # Benchmark threads: 1

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 1317 100 1280 1281 | 20603 100 1861 1860
23: 1272 100 1296 1296 | 20186 100 1848 1848
24: 1232 100 1324 1324 | 19828 100 1839 1840
25: 1182 100 1350 1350 | 19497 100 1838 1833
----------------------------------------------------------------
Avr: 100 1312 1313 100 1846 1845
Tot: 100 1579 1579

$ ./7za b -mmt=2

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 902 MB, # CPU hardware threads: 2
RAM usage: 425 MB, # Benchmark threads: 2

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 2075 164 1233 2018 | 40220 199 1824 3631
23: 2046 166 1255 2084 | 39469 199 1814 3613
24: 2020 170 1278 2172 | 38587 198 1806 3580
25: 1988 174 1305 2270 | 37871 198 1798 3562
----------------------------------------------------------------
Avr: 168 1268 2136 199 1810 3597
Tot: 184 1539 2867

$ ./7za b -mmt=4

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 902 MB, # CPU hardware threads: 2
RAM usage: 850 MB, # Benchmark threads: 4

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 2420 199 1181 2354 | 40086 200 1810 3616
23: 2347 199 1204 2392 | 39361 200 1804 3602
24: 2255 199 1221 2425 | 38563 200 1790 3577
25: 2149 197 1248 2454 | 37690 200 1776 3544
----------------------------------------------------------------
Avr: 198 1213 2406 200 1795 3585
Tot: 199 1504 2995

Т.е. как минимум быстрее, чем bobcat из http://www.7-cpu.com/
За это сообщение сказали спасибо: deadlock

927. ABR, 03.11.2012 23:20
как раз таки писался гикбенч под андроид для арм отдельно, там происходит перекомпиляция для х86, если же брать виндовс версию то там gcc-оптимизации какие-то старые.
Ага разница: 7000 и 15000 вот же правда чушь на кор 2500 и 3570, правда для любого можете подобрать, не порите "чушь".
На интел хоть седьмой, на арм вобще ниодного коммерческого сервака.

А насчет calxeda-единственная компания, которая что-то продемонстрировала на арм, ну хотела показать красиво, и сама лоханулась, после этого все затихло.
Короче у АРМофилов щас видимо руки самопроизвольно рвут волосы на голове)

Да кстати насчет софта под арм, его там обещают написать, так только закон на рынке серверов для ПО такой, пока бабок не дашь, ПО не получишь.

928. XSol, 03.11.2012 23:54
ABR
как раз таки писался гикбенч под андроид для арм отдельно, там происходит перекомпиляция для х86
Почти во всех Андроидовских бенчах с С/С++ кодом есть Х86 code path, в том числе есть таковой в Гикбенче, AnTuTu и прочих, в режиме эмуляции Х86 проигрывает в значительно больших масштабах, нежели 2 раза

Ага разница: 7000 и 15000 вот же правда чушь на кор 2500 и 3570, правда для любого можете подобрать, не порите "чушь".
Еще раз, чушь выдает не бенчмарк, который вы столь неуклюже пытаетесь дискредитировать, подсовывая максимально разнящиеся результаты - http://browser.primatelabs.com/geekbench2/1236834 и http://browser.primatelabs.com/geekbench2/1236791 (бенчмарк, к примеру, может быть не в курсе о паре отключенных пользователем ядер и оттого рапортить то что ему скажет вызов или собственная база данных), тогда как в действительности на одинаковой ОСИ и ее версиях результаты ноздря в ноздрю - http://browser.primatelabs.com/geekbench2/1237243 vs http://browser.primatelabs.com/geekbench2/1055144 , хотя вы, конечно, судя по предыдущим отжигам (http://forum.ixbt.com/topic.cgi?id=8:23952:901#901) , предпочитаете сравнивать что угодно, только не производительность процессоров

929. Pshooter, 04.11.2012 02:33
Подолью масла в огонь

Очень интересная статейка о будущих техпроцессах у Intel и конкуренции в мобильном сегменте.
Преимущество Intel в техпроцессе как-бы будет уже не такое и большое (если даже не наоборот).

А самое интересное было сказано в конце..

Цитирую на английском:



Asked about the effects of finfets on ARM-based SOCs, East replies: "There'ss no rocket science in what you get out of it. The question is does it deliver the benefits at an acceptable cost? You don't get something for nothing. How much does it cost to manufacture? How good is the yield? And that, of course, affects cost."

And so on goes Intel beating its head against the wall to get into the low-margin mobile business.

Recently Intel said it expected its Q4 gross margin to drop 6% from Q3's 63% to 57%. Shock, horror said the analysts

But if Intel succeeds in the mobile business, its gross margin will drop a lot more than that.

It's a funny old world.




Вся статья:

http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2012/10/intel-has-no-process-advantage.html

930. deadlock, 04.11.2012 02:48
Boris Usievich:
чистых RISC давно не осталось
Перестаньте копировать всякий бред из интернетов.
Я вот каждый день занимаюсь разработкой на чистейшем RISC процессоре - SPU.
Там нет ни микрокода, ни разбиения инструкций, ни сложных команд.

931. Mumie01, 04.11.2012 02:55
XSol
Помоему мы здесь уже которую страницу говорим только о мобильных чипах
Ага, а упомянутые вами "бульдозеры", "пентиумы" и "коры" все как есть телефонные процессоры.

Выискивать результаты под свои теории - бред
Чья бы корова мычала (ц)... После ваших манипуляций с тестами (spec Булдозера, geekbench) вы меня будете жизни учить?

Вам не понравилось, что они намеряли большее время браузинга и воспроизведения видео для Razr M?
Ну вам же не понравились резултаты Razr M у Ананда. Впрочем ваш скриншот ещё раз подтвердил, что Razr i более экономичен при типичном использовании, чем множество топовых арм-поделок.

И что же мешает сравнивать с Атомом на Андроиде хотелось бы знать?
Мешает отсутствие какой либо информации по тесту (версии компайлеров, флаги оптимизации и т.д.). Тест "написан" любителем, скомпилировавшим несколько простейших алгоритмов. Я могу таких пару сотен накомпилировать.

ssvb
Бенчмарк 7-zip даёт следующие результаты:

Atom N455:
7-Zip (A) [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_CA.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

RAM size: 1994 MB, # CPU hardware threads: 2
RAM usage: 425 MB, # Benchmark threads: 2

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 1103 159 675 1073 | 17647 197 810 1593
23: 1076 160 686 1096 | 17471 197 812 1599
24: 1057 164 694 1136 | 17216 197 811 1597
25: 1037 168 705 1184 | 17054 198 809 1604
----------------------------------------------------------------
Avr: 163 690 1122 197 811 1598
Tot: 180 750 1360
Похоже будет на уровне z2760 (1.7W) в многопотоке. Да и в том же хромобуке не должен быть сильно быстрее N570 (в многопотоке).
Кстати, почему у вас RAM size 902 MB. Там же вроде 2 Гб должно быть?

932. ssvb, 04.11.2012 03:25
Mumie01
Кстати, почему у вас RAM size 902 MB. Там же вроде 2 Гб должно быть?

Не обращайте внимания. Я просто запустил на chromebook старый "универсальный" статический бинарь. У меня на 7-zip наложен небольшой патч, иначе он пытается излишне оптимистично выделять память в android, изрядная часть которой обычно занята системой:
код:

diff --git a/CPP/Windows/System.cpp b/CPP/Windows/System.cpp
index b63ebec..c239be2 100644
--- a/CPP/Windows/System.cpp
+++ b/CPP/Windows/System.cpp
@@ -118,6 +118,10 @@ namespace NWindows
/* new style /proc/meminfo ... */
if (sscanf(buffer, "MemTotal: %lu", &total))
ullTotalPhys = ((UInt64)total)*1024;
+
+ /* subtract active memory in order not to kill android */
+ if (sscanf(buffer, "Active: %lu", &total))
+ ullTotalPhys -= ((UInt64)total)*1024;
}
fclose( f );
}

933. deadlock, 04.11.2012 03:28
Pshooter
But if Intel succeeds in the mobile business, its gross margin will drop a lot more than that.
Это кстати интересный момент. Чтобы конкурировать в мобильном сегменте Интелу нужно привыкнуть получать меньше и затянуть потуже пояса =)

Вот тут интересные циферки:
http://investorvillage.com/mbthread.asp?mb=476&t…150&showall=1

Q211 (K_Units) 2Q11 | ASP | 2Q11 Rev_K$

Itanium (Server) 25 $1,350.00 $34,373
Xeon MP (Server) 183 $1,113.04 $204,047
Xeon DP (Server) 3,024 $603.56 $1,824,966
Xeon UP (Server) 685 $251.83 $172,432
Total Server 3,917 $570.77 $2,235,818

Performance Desktop 14,522 $126.82 $1,841,627
Value Desktop 14,477 $57.92 $838,500
Basic Desktop 1,489 $25.00 $37,234
Total Desktop 30,489 $89.13 $2,717,361

Performance Mobile 33,953 $118.03 $4,007,340
Value Mobile 2,597 $42.08 $109,272
Basic Mobile 8,227 $27.36 $225,058
Total Mobile 44,777 $96.96 $4,341,669

Total 79,183 $117.38 $9,294,848

ssvb
Chromebook XE303 приехал (Exynos5250, dual Cortex-A15 @1.7GHz)
Amazon вроде еще не шлёт за пределы US. Через какую-то службу / друзей?

934. T-5000, 04.11.2012 05:30
Mumie01
Ага, а упомянутые вами "бульдозеры", "пентиумы" и "коры" все как есть телефонные процессоры.

А с ними сравнивался А57, а не А15. Что тут непонятного?

935. Gull, 04.11.2012 07:05
цитата:
ssvb:
Не обращайте внимания. Я просто запустил на chromebook старый "универсальный" статический бинарь. У меня на 7-zip наложен небольшой патч...

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

936. tolyanIzNska, 04.11.2012 08:14
ABR
Уже седьмой на интел что весьма не плохо на рынке,

Это один и тот же аппарат под разными наклейками

937. ABR, 04.11.2012 09:11
ssvb
Не обращайте внимания. Я просто запустил на chromebook старый "универсальный" статический бинарь. У меня на 7-zip наложен небольшой патч, иначе он пытается излишне оптимистично выделять память в android, изрядная часть которой обычно занята системой:
По-моему без этого патча результаты будут ниже, я так понимаю, армофилы опять читерят)

Добавление от 04.11.2012 09:26:

www.phoronix.com/scan.php?page=article&item=calx…00_atom&num=2 да кстати тестирование calxeda energycore quad-core 1.1GHz(TDP 4 watt) quad-core 1.4GHz(6Watt). quad-core 1.4GHz(6Watt) равен intel atom d525(tdp 13watt). Ну calxeda(блин че у процев на арм за названия: CALxeda, KAL-el, уже о многом говорит ) 32nm а атом 45, ну тогда возьмем интел фтом н2800(6 ватт) ну он быстрей д525 на 10%, не пойдет, возьмем интел атом н2600(3.5 ватт) равент д 525, вот и разница 3.5 и 6 у арм.
энергопотребление http://www.phoronix.com/scan.php? page=news_item&px=MTIwOTk - очень и очень немало для арм

938. lkj, 04.11.2012 10:08
ssvb

Для теста 7-Zip на ARM можно еще подкрутить файл C\CpuArch.h, чтобы 7-Zip использовал оптимизацию для Little-Endian процессора (MY_CPU_LE) в коде подсчета CRC-32. Значение "Decompression speed" должно немного подрасти. 7-Zip под x86 всегда использует оптимизацию для кода CRC-32.

Скорость кода CRC-32 можно тестировать отдельно:
7za b -mm=crc

Как насчет тестов memlat?

939. Chocky, 04.11.2012 11:12
цитата:
ssvb:
"Позднее было отмечено, что наиболее значимая характеристика RISC в разделении инструкций для обработки данных и обращения к памяти — обращение к памяти идёт только через инструкции load и store, а все прочие инструкции ограничены внутренними регистрами. Это упростило архитектуру процессоров: позволило инструкциям иметь фиксированную длину, упростило конвейеры и изолировало логику, имеющую дело с задержками при доступе к памяти, только в двух инструкциях. В результате RISC-архитектуры стали называть также архитектурами load/store."
Это чисто вопрос классификации. Когда разделение CISC/RISC стало трещать по швам из-за того что чистые архитектуры вдруг начали мутировать во что-то гибридное, пришлось подправить определение, чтоб всё-таки можно было формально чётко разделить. Практического значения не имеет, современные декодеры могут и CISC-команду разделить на 2-3 инструкции для разных блоков, которые, благодаря OoO будут выполнены совсем не последовательно, могут и 2 последовательные инструкции слить в одну.

С другой стороны, если отвлечься от формализма, для "CISC" x86 в инструкциях по оптимизации советуют сильно не выпендриваться и использовать RISC-подобные команды. Если не ошибаюсь, всевозможные loop и rep/repne объявлены устаревшими, в то время как "RISC" архитектура ARM включает в себя условное исполнение обычных инструкций. Так какая из этих архитектур "сложная", та, у которой есть инструкция типа "добавить к одному регистру содержимое другого если установлен определённый флаг" или та, у которой условное исполнение присутствует только для операций перехода?

цитата:
Что касается переменной длины инструкций, то у ARM она сейчас тоже переменная (2 или 4 байта в thumb2 режиме).
Ну, это было бы очередным доказательством, что ARM совсем не похож на чистый RISC, но, вроде как, в 64битном обновлении этот режим отменили.

940. T-5000, 04.11.2012 14:15
Chocky
Так какая из этих архитектур "сложная", та, у которой есть инструкция типа "добавить к одному регистру содержимое другого если установлен определённый флаг" или та, у которой условное исполнение присутствует только для операций перехода?

Исполнение команд под предикатами это характерная черта RISC-архитектур.

IA-32-64 декодирующая CISC иснтрукции в RISC микрооперации всегда будет проигрывать чистым RISC архитектурам.

941. Boris Usievich, 04.11.2012 14:30
T-5000
IA-32-64 декодирующая CISC иснтрукции в RISC микрооперации всегда будет проигрывать чистым RISC архитектурам.
да неужели? покажите проигрыш в тестах spec.

942. ABR, 04.11.2012 14:50
вы что как вы разговариваете с армофилами, они впадают в панику даже при виде слова SPEC.
Я не могу понять вин8 вышла, но ниодного теста устройства на нем я не видел, хотя писали что продажи начнутся в день выхода ос, так когда же будут обзоры? Кто нить знает?

943. nenin, 04.11.2012 15:19
цитата:
deadlock:
Я вот каждый день занимаюсь разработкой на чистейшем RISC процессоре - SPU.
Это который кусок Cell?

944. lvqcl, 04.11.2012 15:44
nenin
Это который кусок Cell?

цитата:
The Cell Broadband Engine architecture defines a single-chip multiprocessor consisting of one or more Power Processor Elements (PPEs) and multiple high-performance Synergistic Processor Elements (SPEs). The Synergistic Processor Unit (SPU) is part of the SPE in the Cell Broadband Engine Processor.

Что-то IBM не называет SPU цельным процессором...

945. Ксандр, 04.11.2012 15:45
ABR
RT-шек то есть обзоры, Microsoft Surface Review (http://www.anandtech.com/show/6385/microsoft-surface-review) , х86 планшеты, говорили начнут поставлять где-то с 12го - конец ноября, обзоры могут и раньше..

946. XSol, 04.11.2012 16:20
Mumie01
Ага, а упомянутые вами "бульдозеры", "пентиумы" и "коры" все как есть телефонные процессоры.
О как, оказывается коры и пентиумы серверные, а Зеоны, Оптероны и иже с ними стало быть домашние

После ваших манипуляций с тестами (spec Булдозера, geekbench) вы меня будете жизни учить?
Манипуляций? Ну-ну, не знал, что нынче сравнить пару процессоров в одном бенчмарке(Гикбенче) на одной ОС - манипуляции

Ну вам же не понравились резултаты Razr M у Ананда. Впрочем ваш скриншот ещё раз подтвердил, что Razr i более экономичен при типичном использовании, чем множество топовых арм-поделок.
Эммм, проблема в том, что топовые "поделки" берут как раз для просмотра видео, браузинга, игр и т.д., где Razr M демонстрирует лучшие результаты, а те, кому необходимы часы разговоров обычно берут Xenium'ы рядом с которыми никакой Атом не валялся, кроме того продолжительное время разговора заслуга модема, а не самого Атома

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

947. ABR, 04.11.2012 17:36
ну я больше склонен доверять ананду и энгаджет, чем джиэсэмарене, тем более атом выиграл на 2 ресурсах из 3, так что XSol опять пытается уцепиться за веточку
а по делу хотелось бы посмотреть сколько проживет планшет на вин8 на ивб ULV, так же интересно сколько будет он жить haswell 10 watt tdp

948. Clippy, 04.11.2012 19:38
ABR
хотелось бы посмотреть сколько проживет планшет на вин8 на ивб ULV
Чего там смотреть - берете ультрабук и смотрите: 10-11 минут WiFi браузинга на 1 Whr батарейки.
В 11" ультрабук влезает обычно 30 Whr батарея, т.е около 5 часов.
Удастся запихать более толстую батарею - будет больше.

949. deadlock, 04.11.2012 19:56
lvqcl
Что-то IBM не называет SPU цельным процессором...
Разумеется, потому что это лишь ядро входящее в состав "гетерогенного" чипа.
Если выкинуть Power - получится SpursEngine.

950. Boris Usievich, 04.11.2012 20:14
deadlock
это "ядро" умеете программу само из памяти получить?

951. deadlock, 04.11.2012 23:30
Boris Usievich:
это "ядро" умеете программу само из памяти получить?
Разумеется, а в чём проблема? MMU таблицы зашарены - можно хоть из свопа доставать ровно как и управлять железом.

Will ARM become more powerful than Intel by using less power? (interview) (http://venturebeat.com/2012/11/03/will-arm-become-more-powerful-than-intel-by-using-less-power-interview/)

цитата:
A lot of the PC manufacturers are on low margins, and the original device manufacturers [ODMs] are on even thinner margins than that. The world is ready for a change.
We have a different business model. It’s much more distributed and collegiate and so on. But that means everybody has a more equitable share of the profit. Companies like that.

952. Boris Usievich, 05.11.2012 00:06
deadlock
можно хоть из свопа доставать ровно как и управлять железом.
доставать программу из памяти по DMA - забавно. а откуда там возьмется та программа, что этим DMA управляет, не PPU ли ее туда грузит?

953. deadlock, 05.11.2012 01:29
Boris Usievich
доставать программу из памяти по DMA - забавно.
Памяти всё равно кто её читает. DMA запрос SPU ничем не отличается от чтения кеш линии на PPU.

а откуда там возьмется та программа, что этим DMA управляет, не PPU ли ее туда грузит?
Да, а что это собственно меняет? Грузится job manager и всё - дальше он сам себе хозяин (один из способов).
Или это опять попытки упрекать SPU в "неполноценности"?
С точки зрения EIB, SPU мало чем отличается от PPU.
Дело SPU - обрабатывать данные и делать это быстро, а не HDD крутить.

Добавление от 05.11.2012 01:36:

"Разбор" Apple A6X (http://www.3dnews.ru/news/637526)

954. T-5000, 05.11.2012 04:55
Boris Usievich
да неужели? покажите проигрыш в тестах spec.

Читайте про мэинфрейм IBM zEnterprise EC12 с самым быстрым в мире процессором: 6 ядер, частота 5,5 ГГц.
Он просто разрывает интелей как тузик грелку и является чистым RISC-процессором.
цитата:
It is
powered by 120 of the world’s most powerful microprocessors
running at 5.5 GHz and is capable of executing more than
78,000 millions of instructions per second (MIPS).

Так что я бы на вашем месте про Интел вообще больше не заикался.
Пацаны они по сравнению с IBM.

955. ssvb, 05.11.2012 05:13
Вынес нафиг на хромобуке хромоось и поставил нормальный линукс (https://plus.google.com/u/0/109993695638569781190/posts/b2fazijJppZ) , теперь намного проще тестировать любой софт
цитата:
lkj:
Для теста 7-Zip на ARM можно еще подкрутить файл C\CpuArch.h, чтобы 7-Zip использовал оптимизацию для Little-Endian процессора (MY_CPU_LE) в коде подсчета CRC-32. Значение "Decompression speed" должно немного подрасти. 7-Zip под x86 всегда использует оптимизацию для кода CRC-32.
Судя по всему, эта оптимизация уже и так давно используется (определяется по #ifdef __ARMEL__).
цитата:
Скорость кода CRC-32 можно тестировать отдельно:
7za b -mm=crc
Подсчет CRC-32 занимает меньше 5% от времени декодирования:
код:

# perf record 7z t test.7z && perf report
[...]
93.53% 7z 7z.so [.] LzmaDec_DecodeReal2
4.45% 7z 7z.so [.] CrcUpdateT4
0.51% 7z [kernel.kallsyms] [k] __copy_to_user_std
0.43% 7z [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.13% 7z ld-2.15.so [.] do_lookup_x
0.12% 7z [kernel.kallsyms] [k] kmap_atomic
0.10% 7z 7z [.] COpenCallbackImp::GetStream(wchar_t const*, IInStream**)
0.08% 7z [kernel.kallsyms] [k] __memzero
0.08% 7z [kernel.kallsyms] [k] get_page_from_freelist
0.05% 7z [kernel.kallsyms] [k] do_page_fault
0.05% 7z [kernel.kallsyms] [k] __wake_up_bit
0.05% 7z [kernel.kallsyms] [k] handle_mm_fault

Саму функцию для подсчета CRC-32, конечно, можно ещё оптимизировать (в том числе и с использованием ассемблера). Но даже в C коде zlib разворачивает этот цикл: https://github.com/madler/zlib/blob/v1.2.7/crc32.c#L240
цитата:
Как насчет тестов memlat?
Результаты приаттачены.https://rapidshare.com/files/2590199859/memlat-cortex-a15.7z

Дополнение: греется процессор где-то до ~76 градусов при многопоточной нагрузке с использованием NEON ("cat /sys/class/thermal/thermal_zone0/temp"), throttling теоретически должен активироваться при достижении 85 градусов ("cat /sys/class/thermal/thermal_zone0/trip_point_0_temp"). При более обычной многопоточной нагрузке вроде компиляции, температура ещё градусов на 10 меньше. Судя по cpufreq stats, в throttling он пока так и не уходил ни при каких тестах и всё время оставался на 1.7GHz (я специально для тестов включил performance governor). Может быть летом в тридцатиградусную жару или в каких индиях у Chromebook получится и перегреться

956. deadlock, 05.11.2012 05:30
T-5000
Он просто разрывает интелей как тузик грелку и является чистым RISC-процессором.
А вот и нет
z12 это "чистый" CISC процессор (http://en.wikipedia.org/wiki/IBM_zEC12_%28microprocessor%29) .

Если же говорить про Power, то архитектура слишком нафарширована в плане наличия сложных команд чтобы именоваться "чистым" RISC - в частности режимы адресации с апдейтом, переменная длина команд, невыравненный доступ и т.д.
Ровно как и в ARM имеются "примеси". Т.е. само разделение довольно условно.
За эталон чистого RISC-а можно принять референсные дизайны Berkley RISC (http://en.wikipedia.org/wiki/Berkeley_RISC)
и подобные процессоры MIPS, SPARC, ALPHA, CELL/SPU, Epiphany и т.д.

957. ssvb, 05.11.2012 05:39
Mumie01
Похоже будет на уровне z2760 (1.7W) в многопотоке. Да и в том же хромобуке не должен быть сильно быстрее N570 (в многопотоке).

Для многопотока из ARM железа всё равно сейчас лучше использовать quad Cortex-A9 (если задача явно не упирается в ПСП памяти). Тем более, что самсунг не дремлет и уже раскочегарил его до 1.7GHz - http://odroid.foros-phpbb.com/t1609-odroid-x2
Мой оригинальный ODROID-X (с номиналом 1.4GHz) тоже легко разгоняется до 1.7GHz с поднятием напряжения, но пассивный радиатор не справляется с охлаждением под нагрузкой при использовании более двух ядер.

958. T-5000, 05.11.2012 05:50
deadlock
А вот и нет
z12 это чистый CISC процессор.


Чистый RISC, а вот для обратной программной совместимости со всяким старьем в дополнение к RISC-командам используется CISC.
Если совместимость не нужна, процесор может исполнять любой код в RISC-командах не привлекая CISC.

Добавление от 05.11.2012 05:54:

deadlock
Если же говорить про Power, то архитектура слишком нафарширована в плане наличия сложных команд чтобы именоваться "чистым" RISC...
Сама IBM называет архитектуру POWER как RISC. Им видней.

959. ssvb, 05.11.2012 06:56
цитата:
deadlock:
ssvb
Chromebook XE303 приехал (Exynos5250, dual Cortex-A15 @1.7GHz)
Amazon вроде еще не шлёт за пределы US. Через какую-то службу / друзей?
Amazon UK. Оттуда его рассылают в Европе, хотя ценник и прилично выше штатовского.

Что касается самого Chromebook. Если планируется покупка именно для установки на нём Linux, то я бы не рекомендовал. На клавиатуре нет ряда необходимых клавиш ("del", "pgup", "pgdown", ...). Также вставленная SD карточка наполовину торчит из слота, что делает её малопригодной для установки основной OS (стрёмновато бросать chromebook в рюкзак/портфель в таком состоянии). Хотя может быть умельцы подберут юзабельный ремап раскладки клавиатуры. Может быть также можно подобрать какой адаптер для microsd, чтобы оно туда вставлялось и ничего не выпирало. Или уже ставить систему на 16GB встроенной eMMC, тем более оно должно быть побыстрее внешней SD карточки:
код:

# hdparm -t /dev/mmcblk0
Timing buffered disk reads: 114 MB in 3.03 seconds = 37.62 MB/sec

# hdparm -t /dev/mmcblk1
Timing buffered disk reads: 62 MB in 3.05 seconds = 20.33 MB/sec

Единственный заметный плюс для меня - это первое устройство с Cortex-A15 Но может быть со временем появятся нетбуки и попристойнее.
За это сообщение сказали спасибо: Ксандр

960. grafsoft, 05.11.2012 11:27
а чего никто не пишет
Подробности о новых процессорах SPARC T5
Новые процессоры базируются на ядре "S3", которое было спроектировано и внедрено в SPARC T4, но в котором удвоено количество ядер - до 16 на процессор, совершен переход на технологию производства 28нм, что также позволило увеличить частоту до 3,6 ГГц. В SPARC T5 интегрированы PCI Express Rev 3 и четыре контроллера памяти DDR3, что и позволило увеличить пропускную способность памяти и ввода/вывода.

Добавлена возможность масштабирования до 8 сокетов на сервер, что при 16 ядрах на процессор даёт 128 ядер на сервер. Каждое отдельное ядро при этом может поддерживать до 8 независимых потоков, и в результате получается 1024 потока на сервер, которые для операционной системы выглядят как 1024 процессора. При передаче этой функции операционной системе Solaris возможно как ручное, так и автоматическое назначение количества используемых потоков.

Система поддерживает несколько терабайт оперативной памяти с суммарной пропускной способностью 0.5 терабайта в секунду. Важным новшеством в данном продукте вице-президент назвал переход от "snoopy-based coherence protocol" к "directory-based protocol", что и позволило, по его словам, добиться почти линейной масштабируемости до 8 сокетов. Для управления потребляемой мощностью добавлены такие улучшенные функции, как динамическое изменение напряжения и частоты процессора, что в комбинации оборудования и прошивок позволит задавать политики и лимиты потребления электроэнергии. Каждое ядро имеет встроенные аппаратные ускорители шифрования AES/DES, обмена ключами RSA, хеширования SHA/MD5, а также аппаратный генератор случайных чисел.

961. Boris Usievich, 05.11.2012 11:40
T-5000
Пацаны они по сравнению с IBM.
Во-первых, вот тут (x86 против arm, power, sparc, gpu, cell и других. (часть 4), #940 (http://forum.ixbt.com/topic.cgi?id=8:23952:940#940)
) вы делали весьма сильное утверждение про "RISC" и "CISC" вообще, так что все еще ждем результаты ARM, как видного представителя RISC

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

В-третьих, повторю: "чистые" RISC давно померли.

deadlock
Да, а что это собственно меняет?
многое

Или это опять попытки упрекать SPU в "неполноценности"?
Это не "попытки", это факт

962. -=GunFighter=-, 05.11.2012 11:58
grafsoft
а чего никто не пишет
Подробности о новых процессорах SPARC T5

Результаты в SPEC у него имеются?

963. lkj, 05.11.2012 12:04
Результаты тестов ARM Cortex-A15 (Samsung Exynos 5250):

L1 Data Cache Latency: 4 cycles
L2 Cache Latency: 21 cycles
RAM Latency: 63 cycles + 110 ns (L2 cache miss, TLB miss)
L2 Read B/W: 13.6 GB/s
RAM Read B/W: 4.2 GB/s
RAM Write B/W: 6 GB/s

http://www.7-cpu.com/cpu/Cortex-A15.html

Недостатки:
- Низкая скорость случайного доступа к L2 и к памяти (как и у Сortex-A9).
- L1 Data cache по спецификации только 2-Way. Есть подозрение, что это может сказываться в реальных приложениях.

ssvb

Результаты memlat получились не очень четкие.
Можно попробовать запустить тест сразу после System Reboot, чтобы уменьшить фрагментацию памяти.
Нужны только эти тесты:
8 c
8 b
8 b w
1536 p6 d
1536 p12 d
1536 p d
1536 c1040h

Насчет кода CRC.
Если бы __ARMEL__ не сработал, то код CRC мог занять до 10% для LZMA decompression.
Разворачивать тот цикл выгодно для In-Order процессора.
Out-of-Order процессор может и сам эффективно развернуть цикл во время исполнения.

964. ssvb, 05.11.2012 14:38
lkj
Низкая скорость случайного доступа к L2 и к памяти (как и у Сortex-A9).

Да, я на это тоже обратил внимание. Хотя на всех слайдах рисовали "быстрый интегрированный L2 кэш" для Cortex-A15. Да и в видео про big.LITTLE (http://www.youtube.com/watch?v=NeZmswRL-Y4) на 8:44 они там распинаются на тему как удалось сэкономить 2 такта при доступе к L2 (пожертвовав возможностью работы ядер на разной частоте внутри кластера) и насколько это важно.

Подозреваю, что эта проблема может быть связана с ранней сырой ревизией Cortex-A15 (r0p4). Ошибок в первых ревизиях новых ядер ARM всегда было много. Задав поиск по "Cortex-a15 r0p4 errata" уже можно найти https://gerrit.chromium.org/gerrit/#/c/33607/ ("This patch adds the workaround of Errata 773022 that disables loop buffer for cortex-A15 r0p4"). Возможно у них глючила какая-то оптимизация, связанная с L2 кэшем и её просто отключили? Например, в ранних Cortex-A8 (r1pX) была отключена оптимизация прямого доступа к L2 кэшу минуя L1 для NEON, в последних ревизиях её починили.

Out-of-Order процессор может и сам эффективно развернуть цикл во время исполнения.

Насчет "эффективно" я не соглашусь. У Cortex-A9 out-of-order был немного недоделанный. Например, если взять следующий код и запустить его в цикле:
код:

ldr r0, [sp, #0]
add r0, r0, r1
str r0, [sp, #0]

ldr r0, [sp, #4]
add r0, r0, r1
str r0, [sp, #4]

ldr r0, [sp, #8]
add r0, r0, r1
str r0, [sp, #8]

ldr r0, [sp, #12]
add r0, r0, r1
str r0, [sp, #12]

ldr r0, [sp, #16]
add r0, r0, r1
str r0, [sp, #16]

Cortex-A8 эта последовательность выполняется 15 тактов (IPC=1), на Cortex-A9 - ~11.7 тактов (IPC=1.28), на Cortex-A15 - 5 тактов (IPC=3). Почему у Cortex-A9 там IPC 1.28 вместо 1.5? Вроде как load/store инструкции должны быть узким местом и задавать скорость исполнения кода, т.е. ожидалось 10 тактов. В общем, у Cortex-A9 out-of-order несколько странноват. Хорошо хоть Cortex-A15 ведёт себя куда более предсказуемо.

Однако если ради прикола поменять код таким образом, чтобы значение r1 всегда прибавлялось к одной и той же переменной в памяти (например "[sp, #0]"), то переупорядочивание уже не работает и получается у Cortex-A8 - 15 тактов, у Cortex-A9 - 30 тактов, у Cortex-A15 - 40 тактов.

Добавление от 05.11.2012 14:46:

Ещё из любопытных наблюдений: теперь примитивная NEON арифметика (например, VADD.U8) имеет латентность 3 (!) такта у Cortex-A15. У Cortex-A8/A9 латентность 2 такта, что тоже было многовато. "В среднем по больнице" производительность на NEON коде получается у Cortex-A15 всё равно выше, но надо будет с каждым случаем разбираться индивидуально. Интересно, каков в этом отношении Krait?

965. Boris Usievich, 05.11.2012 14:57
ssvb
Например, если взять следующий код и запустить его в цикле:
А если аналогичный код на x86?

966. ssvb, 05.11.2012 16:03
ssvb
Хорошо хоть Cortex-A15 ведёт себя куда более предсказуемо

Ха, не тут-то было. Если внимательно посмотреть, то получается, что код:
код:

ldr r0, [sp, #0]
add r0, r0, r1
str r0, [sp, #0]

ldr r0, [sp, #4]
add r0, r0, r1
str r0, [sp, #4]

ldr r0, [sp, #8]
add r0, r0, r1
str r0, [sp, #8]

ldr r0, [sp, #12]
add r0, r0, r1
str r0, [sp, #12]

ldr r0, [sp, #16]
add r0, r0, r1
str r0, [sp, #16]

выполняется 5 тактов (в хорошо развёрнутом цикле), в то время как всего лишь 3 инструкции
код:

ldr r0, [sp, #0]
add r0, r0, r1
str r0, [sp, #0]

выполняются 8 тактов (тоже в хорошо развёрнутом цикле). Т.е. выбрасываем целую кучу инструкций и получаем в итоге более медленное выполнение Могу только предположить, что каким-то образом могут быть причастны проблемы, связанные со store forwarding. Ясно, что out-of-order дело тёмное.

upd: Или можно предположить, что на следующей последовательности инструкций процессор просто пытается оптимистично переупорядочить инструкции и выполнить 4. перед 3.
код:

1. ldr r0, [sp, #0]
2. add r0, r0, r1
3. str r0, [sp, #0]
4. ldr r0, [sp, #0]
5. add r0, r0, r1
6. str r0, [sp, #0]

А затем чуть позже обнаруживает, что это на самом деле один и тот же адрес. Как результат - некий штраф в 3 такта и реплей. Надо будет посмотреть, есть ли какое интересное событие в performance counters.

967. Mumie01, 05.11.2012 16:11
ssvb
Т.е. выбрасываем целую кучу инструкций и получаем в итоге более медленное выполнение
Хм... Странно. Может ошибка в методике? Как вы измеряете время выполнения (в тактах)?

968. lkj, 05.11.2012 16:19
ssvb

Однако если ради прикола поменять код таким образом, чтобы значение r1 всегда прибавлялось к одной и той же переменной в памяти (например "[sp, #0]"), то переупорядочивание уже не работает и получается у Cortex-A8 - 15 тактов, у Cortex-A9 - 30 тактов, у Cortex-A15 - 40 тактов.

Но ведь код на C часто попадает в такие ситуации, когда не хватает регистров для всех переменных. Если я правильно помню, OoO в Intel P6 всегда работал хорошо в таких случаях. Там регистров было мало. И им не хотелось терять производительность из-за этого.

969. Boris Usievich, 05.11.2012 16:46
lkj
Но ведь код на C часто попадает в такие ситуации, когда не хватает регистров для всех переменных. Если я правильно помню, OoO в Intel P6 всегда работал хорошо в таких случаях. Там регистров было мало.
логических мало, физических - заметно больше.

970. lkj, 05.11.2012 17:53
Boris Usievich

логических мало, физических - заметно больше.

Тут суть в другом. Мало логических регистров -> большое использование стека для локальных переменных -> хорошая оптимизация чтений/записи по известным адресам в L1-кэш в процессорах Intel/AMD. Там весь L1-кэш работает как большой и достаточно быстрый регистровый файл.

971. Boris Usievich, 05.11.2012 18:17
lkj
Мало логических регистров -> большое использование стека для локальных переменных
не обязательно. цикл использующий в каждой итерации одни и те же регистры может быть развернут OoO по куче разных физических регистров.

Там весь L1-кэш работает как большой и достаточно быстрый регистровый файл.
И это тоже есть, кэши в x86 получше будут. А если учесть наличие prefetch ....

972. lkj, 05.11.2012 19:09
Boris Usievich

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

До OoO дело доходит в момент исполнения кода. А использование стека определяется в момент компиляции. OoO в хороших процессорах AMD/Intel за счет store-to-load forwarding, store queue и быстрого кэша L1 скрывает возможные издержки от нехватки логических регистров в x86-32. Поэтому часто и не наблюдают большой разницы от перехода на x86-64, хотя там компилятор и заменяет многие обращения к стеку на обращения к дополнительным регистрам (R8-R15).

На ARM'е логических регистров больше, чем на x86-32. Поэтому там эта проблема стоит менее остро. Вопрос в том, сделали ли они качественно эту подсистему обращений к стеку в Cortex-A9 / Cortex-A15.

973. Boris Usievich, 05.11.2012 19:39
lkj
А использование стека определяется в момент компиляции.
ну само-собой, и хороший компилятор может прикинуть где потом OoO поможет

974. ssvb, 05.11.2012 21:46
Boris Usievich
А если аналогичный код на x86?

Аналогичный код для x86 (пришлось увеличить количество рабочих переменных в памяти до 6, поскольку на Core i7 инкремент одной переменной в памяти занимает как раз 6 тактов):
код:

/* For example, on Intel Atom 1.66GHz use this code as:
* gcc -m32 -DCPU_CLOCK_FREQUENCY=1660000000 bench.S && time ./a.out
* or
* gcc -m32 -DCPU_CLOCK_FREQUENCY=1660000000 bench.S && perf stat ./a.out
*
* Add -DRISC_STYLE to replace "add mem, reg" with "mov reg, mem ; add reg, reg ; mov mem, reg"
* Add -DUSE_SAME_ADDR to use the same variable in memory instead of 6 different ones
*/

.intel_syntax noprefix
.text
.global main

#ifndef CPU_CLOCK_FREQUENCY
#error CPU_CLOCK_FREQUENCY must be defined
#endif

#define LOOP_UNROLL_FACTOR 30

#ifdef USE_SAME_ADDR
# define OFFS1 0
# define OFFS2 0
# define OFFS3 0
# define OFFS4 0
# define OFFS5 0
# define OFFS6 0
#else
# define OFFS1 0
# define OFFS2 4
# define OFFS3 8
# define OFFS4 12
# define OFFS5 16
# define OFFS6 20
#endif

main:
mov ecx, (CPU_CLOCK_FREQUENCY / LOOP_UNROLL_FACTOR)
sub esp, 128
jmp 1f

.balign 64
1:
.rept LOOP_UNROLL_FACTOR
#ifdef RISC_STYLE
mov edx, dword ptr [esp + OFFS1]
add edx, eax
mov dword ptr [esp + OFFS1], edx

mov edx, dword ptr [esp + OFFS2]
add edx, eax
mov dword ptr [esp + OFFS2], edx

mov edx, dword ptr [esp + OFFS3]
add edx, eax
mov dword ptr [esp + OFFS3], edx

mov edx, dword ptr [esp + OFFS4]
add edx, eax
mov dword ptr [esp + OFFS4], edx

mov edx, dword ptr [esp + OFFS5]
add edx, eax
mov dword ptr [esp + OFFS5], edx

mov edx, dword ptr [esp + OFFS6]
add edx, eax
mov dword ptr [esp + OFFS6], edx
#else /* CISC_STYLE */
add dword ptr [esp + OFFS1], eax
add dword ptr [esp + OFFS2], eax
add dword ptr [esp + OFFS3], eax
add dword ptr [esp + OFFS4], eax
add dword ptr [esp + OFFS5], eax
add dword ptr [esp + OFFS6], eax
#endif
.endr
dec ecx
jnz 1b

add esp, 128
mov eax, 0
ret


Запускать примерно так (для 2.8GHz процессора):
код:

export FREQ=2800000000
gcc -m32 -DCPU_CLOCK_FREQUENCY=$FREQ bench.S -DCISC_STYLE && /usr/sbin/perf stat ./a.out
gcc -m32 -DCPU_CLOCK_FREQUENCY=$FREQ bench.S -DRISC_STYLE && /usr/sbin/perf stat ./a.out
gcc -m32 -DCPU_CLOCK_FREQUENCY=$FREQ bench.S -DCISC_STYLE -DUSE_SAME_ADDR && /usr/sbin/perf stat ./a.out
gcc -m32 -DCPU_CLOCK_FREQUENCY=$FREQ bench.S -DRISC_STYLE -DUSE_SAME_ADDR && /usr/sbin/perf stat ./a.out

Intel Core-i7 860:
CISC_STYLE: 6 cycles (IPC=1)
RISC_STYLE: 6 cycles (IPC=3)
CISC_STYLE & USE_SAME_ADDR: 36 cycles (IPC=0.17)
RISC_STYLE & USE_SAME_ADDR: 36 cycles (IPC=0.5)

Intel Atom N450:
CISC_STYLE: 6 cycles (IPC=1)
RISC_STYLE: 18 cycles (IPC=1)
CISC_STYLE & USE_SAME_ADDR: 6 cycles (IPC=1)
RISC_STYLE & USE_SAME_ADDR: 18 cycles (IPC=1)

ARM Cortex-A8:
RISC_STYLE: 18 cycles (IPC=1)
RISC_STYLE & USE_SAME_ADDR: 18 cycles (IPC=1)

ARM Cortex-A9:
RISC_STYLE: 14 cycles (IPC=1.28)
RISC_STYLE & USE_SAME_ADDR: 36 cycles (IPC=0.5)

ARM Cortex-A15:
RISC_STYLE: 6 cycles (IPC=3)
RISC_STYLE & USE_SAME_ADDR: 48 cycles (IPC=0.38)

Тут надо понимать, что всё это - чистая синтетика. Мне больше было интересно посмотреть, насколько эффективно Cortex-A9 и Cortex-A15 могут переупорядочивать инструкции. По факту у Cortex-A9 есть проблемы с достижением теоретического IPC (14 тактов вместо теоретических 12 в RISC_STYLE конфигурации). У Cortex-A15 есть проблемы с RISC_STYLE & USE_SAME_ADDR конфигурацией (48 тактов вместо 30), поскольку реально на инкремент одной переменной в памяти нужно только 5 тактов, но при попытке загрузить переменную сразу после сохранения появляются какие-то дополнительные штрафы.
За это сообщение сказали спасибо: deadlock

975. Boris Usievich, 05.11.2012 21:51
ssvb
ну собственно я примерно это и ожидал. только для x86 есть еще вариант с SSE2 , который будет 4 переменные за раз прибавлять

если не лень, подкиньте exe, я его на работе на SB посмотрю. там вроде что-то с работой с памятью улучшали. gcc там нету, только vc и icc только константа времени компиляции это не гуд

976. ssvb, 05.11.2012 23:33
Boris Usievich
ну собственно я примерно это и ожидал. только для x86 есть еще вариант с SSE2 , который будет 4 переменные за раз прибавлять

У ARM тоже есть NEON, который в Cortex-A15 потенциально вдвое быстрее (выполняет до двух NEON инструкций за такт), но имеет более высокую латентность по сравнению со старыми ARM ядрами. Возможно его тоже нужно уметь "правильно готовить" для достижения максимальной производительности.

Но куда более интересно узнать, сможет ли Cortex-A15 порвать своих x86 конкурентов на чём-то более практически полезном, вроде вычисления CRC-32? Любопытно посмотреть на код вычисления CRC-32 (http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/check/crc32_fast.c;h=94da85592d8adbd90ca35ce7b80c38ab727ced0e;hb=HEAD#l23) из xz компрессора (реализация lzma для tar архивов в linux/unix). Во-первых, там используется slice-by-eight алгоритм, описанный в Intel'овском документе (http://www.intel.com/technology/comms/perfnet/download/CRC_generators.pdf) . Для slice-by-eight Intel даёт оценку быстродействия 2.19 тактов на байт на Pentium-M процессоре. Во-вторых, что касается C имплементации CRC-32 в xz, там присутствует занятный комментарий "If you make any changes, do some bench marking! Seemingly unrelated changes can very easily ruin the performance (and very probably is very compiler dependent)", который намекает, что генерацию кода для вычисления CRC-32 нельзя доверять компилятору. Там же у них есть и ассемблерный вариант для x86 (http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/check/crc32_x86.S;h=67f68a4145f8bdd8b90883401ffbc11f67122b65;hb=HEAD) .

если не лень, подкиньте exe, я его на работе на SB посмотрю. там вроде что-то с работой с памятью улучшали. gcc там нету, только vc и icc только константа времени компиляции это не гуд

Тест полагается на то, что имеется gcc, а также утилиты time и/или perf. Это позволяет не писать код для обработки параметров командной строки, замеров и печати результатов. Т.е. никаких излишеств. При наличии утилиты perf, в принципе даже не обязательно знать тактовую частоту процессора и избавляться от эффектов turbo boost (поскольку perf умеет считать количество выполненных инструкций и IPC).

Добавление от 06.11.2012 00:05:

lkj
Можно попробовать запустить тест сразу после System Reboot, чтобы уменьшить фрагментацию памяти.

OK, попробую запустить его на ночь.

PS. Жалко, что нет вменяемых данных по AMD E-450 (bobcat). Интересно, какая у него на практике латентность и ПСП памяти? E-450 выглядит как система примерно сопоставимого класса с Exynos 5250.

977. nenin, 06.11.2012 00:15
цитата:
ssvb:
PS. Жалко, что нет вменяемых данных по AMD E-450 (bobcat). Интересно, какая у него на практике латентность и ПСП памяти? E-450 выглядит как система примерно сопоставимого класса с Exynos 5250.
Имею С60.

978. lkj, 06.11.2012 00:35
ssvb

Но куда более интересно узнать, сможет ли Cortex-A15 порвать своих x86 конкурентов на чём-то более практически полезном, вроде вычисления CRC-32

Не сможет. Для рекорда там нужно делать два чтения за такт и иметь низкую латентность L1. Поэтому обойти по скорости AMD K8/K10 там пока не смогут.

Чтобы A15 обошел x86 хоть где-нибудь, надо найти хоть одну подсистему, которая реализована лучше. Но таких подсистем там не видно. Потенциально ARM мог выиграть где-нибудь за счет длины конвейера, но он все-таки вырос до 13-15 стадий после Сortex-A9. Еще могли выигрывать за счет условного выполнения инструкций. Но OoO-процессору это условное исполнение может и мешать. И от него отказались уже в ARM-64.

Добавление от 06.11.2012 00:54:

nenin

Имею С60.

Тесты memlat:
http://sourceforge.net/projects/sevenmax/files/7-Ben…1100.zip/download
Если там Windows, то нужно запустить m32.bat или m64.bat и PipeLen.exe > pipelen.txt, и выложить результаты куда-нибудь одним архивом. Если Linux, можно запускать под wine.
Перед запуском тестов лучше перезагрузить систему, чтобы дефрагментировать память. И что-нибудь сделать с Turbo-Mode, чтобы частота не менялась в процессе тестов.

979. Pshooter, 06.11.2012 03:12
Появился (не в первый раз) вот такой вот слух:

http://www.engadget.com/2012/11/05/apple-considering…oomberg/#comments

980. T-5000, 06.11.2012 06:18
lkj
Чтобы A15 обошел x86 хоть где-нибудь, надо найти хоть одну подсистему, которая реализована лучше.
Вы тесты А15 под Андроидом в сравнении с Атомом видели? Он там обошел его практически везде.

981. Mumie01, 06.11.2012 06:39
ssvb

Кстати, к вопросу "Зачем Атому branch predictor":

код:
$ gcc -m32 -DCPU_CLOCK_FREQUENCY=1600000000 -DLOOP_UNROLL_FACTOR=1 bench.S -DCISC_STYLE && perf stat -e cycles,instructions ./a.out

Performance counter stats for './a.out':

9,839,314,053 cycles
12,810,893,002 instructions # 1.302 IPC

5.941042992 seconds time elapsed

$ gcc -m32 -DCPU_CLOCK_FREQUENCY=1600000000 -DLOOP_UNROLL_FACTOR=30 bench.S -DCISC_STYLE && perf stat -e cycles,instructions ./a.out

Performance counter stats for './a.out':

9,760,575,144 cycles
9,715,883,313 instructions # 0.995 IPC

5.884739533 seconds time elapsed

982. TOTGEBOREN, 06.11.2012 10:01
nenin
Имею С60.

Есть Z01 с win 8.

983. Mumie01, 06.11.2012 18:39
Кролики грызутся... ARM и Imagination поделили между собой MIPS.

http://www.computerworld.com/s/article/print/9233300…y_chip_maker_MIPS

984. nenin, 06.11.2012 19:38
цитата:
TOTGEBOREN:
nenin
Имею С60.

Есть Z01 с win 8.
C60- не предмет для гордости, а повод тестануть заката. А win8... Честно говоря, со времен Win2 я такого колхозного дизайна не видел. Даже Gem и Geoworks и те были как-то эстетичнее. Отдел ноутбуков стал смотреться как кладбище банкоматов.

Добавление от 06.11.2012 19:40:

цитата:
lkj:
И что-нибудь сделать с Turbo-Mode, чтобы частота не менялась в процессе тестов.
А как?

Добавление от 06.11.2012 20:08:

Виснет на 10214 p6

985. lkj, 06.11.2012 20:32
nenin

Отключение Turbo-Mode поискать в BIOS, или в настройках питания. Но можно и не отключать. В тестах всегда работает один поток. Причин смены частоты у процессора быть не должно.

Виснет на 10214 p6

А памяти сколько?

Добавление от 06.11.2012 20:39:

Можно для начала запустить просто один быстрый тест
MemLat64.exe 4 p6 > p6
В колонке 1 должны быть видны четкие значения латентности L1: ~3.00.
Если там другие значения, надо как-то отключать Turbo-Mode.

986. Boris Usievich, 06.11.2012 20:40
nenin
А как?
вроде вот эта тулза умеет на лету вырубать turbo
http://www.xtremesystems.org/forums/showthread.php?2…-Turbo-throttling

987. nenin, 06.11.2012 21:42
цитата:
lkj:
nenin

Отключение Turbo-Mode поискать в BIOS, или в настройках питания. Но можно и не отключать. В тестах всегда работает один поток. Причин смены частоты у процессора быть не должно.

Виснет на 10214 p6

А памяти сколько?
4G.
цитата:



Добавление от 06.11.2012 20:39:

Можно для начала запустить просто один быстрый тест
Посчитало только с1040.
там
код:

MemLat 11.00 : Igor Pavlov : Public domain : 2011-05-12
Size Linear

4-K 0.00
5-K 3.01
6-K 3.01
7-K 3.01
8-K 3.01
10-K 3.01
12-K 3.01
14-K 3.01
16-K 3.01
20-K 3.01
24-K 3.01
28-K 3.01
32-K 3.01
40-K 3.01
48-K 3.01
56-K 4.01
64-K 3.01
80-K 3.01
96-K 3.01
112-K 3.01
128-K 3.02
160-K 4.81
192-K 5.53
224-K 6.14
256-K 6.45
320-K 7.30
384-K 7.45
448-K 9.33
512-K 7.69
640-K 8.13
768-K 8.33
896-K 8.44
1024-K 8.42
1280-K 8.60
1536-K 8.67
1792-K 8.70
2048-K 8.81
2560-K 31.71
3072-K 34.56
3584-K 36.37
4-M 37.75
5-M 39.39
6-M 39.19
7-M 39.41
8-M 39.85
10-M 40.28
12-M 40.50
14-M 40.49
16-M 40.63
20-M 40.32
24-M 40.69
28-M 76.52
32-M 104.06
40-M 150.71
48-M 152.26
56-M 151.72
64-M 151.29

BW- 26

Seq Step

Timer frequency = 974814 Hz
CPU frequency = 998.21 MHz


В остальных пишет что памяти не хватает.

988. lkj, 06.11.2012 21:54
nenin

Там два вида тестов:
1) Тесты для 4 KB страниц (res\64). Они должны работать.
2) Тесты для 2 MB страниц (res\64L). Для этих тестов нужна дополнительная настройка системы. Можно пока пропустить их.

989. nenin, 06.11.2012 22:38
цитата:
lkj:
nenin

Там два вида тестов:
1) Тесты для 4 KB страниц (res\64). Они должны работать.
2) Тесты для 2 MB страниц (res\64L). Для этих тестов нужна дополнительная настройка системы. Можно пока пропустить их.

Пока их придется отложить.

990. ssvb, 06.11.2012 22:50
цитата:
lkj:
Результаты memlat получились не очень четкие.
Можно попробовать запустить тест сразу после System Reboot, чтобы уменьшить фрагментацию памяти.
Нужны только эти тесты:
8 c
8 b
8 b w
1536 p6 d
1536 p12 d
1536 p d
1536 c1040h
https://rapidshare.com/files/4062433743/memlat-cortex-a15-try2.7z

Добавление от 07.11.2012 00:16:

цитата:
lkj:
ssvb

Но куда более интересно узнать, сможет ли Cortex-A15 порвать своих x86 конкурентов на чём-то более практически полезном, вроде вычисления CRC-32

Не сможет. Для рекорда там нужно делать два чтения за такт и иметь низкую латентность L1. Поэтому обойти по скорости AMD K8/K10 там пока не смогут.

Для slice-by-four действительно важна низкая латентность инструкций, поскольку данное вычисление CRC-32 ни что иное, как вариация на тему pointer chasing ("extract indexes from crc value" -> "table lookups" -> "xor all lookups with crc value" -> ...). И out-of-order там циклы разворачивать не может. Вариант slice-by-eight заметно лучше для "широких" процессоров, поскольку большее количество операций (2+8 чтений из памяти с сопутствующей арифметикой вместо 1+4 чтений) могут выполняться параллельно до точки синхронизации "xor all lookups with crc value".

Компилировал простую тестовую программу с помощью gcc-4.7.2, CFLAGS="-O3 -mcpu/-mtune={cortex-a8|cortex-a9|cortex-a15|core2|atom}" и получил следующие результаты:

slice-by-four из 7-zip:
код:


CPU | ASM (32-bit) | C (32-bit) | C (64-bit)
--------------+-------------------+-----------------+-----------------
Cortex-A8 | 2.0 cycles/byte | 3.3 cycles/byte | -
Cortex-A9 | 2.7 cycles/byte | 3.5 cycles/byte | -
Cortex-A15 | 2.5 cycles/byte | 2.9 cycles/byte | -
Core i7 | - | 2.1 cycles/byte | 2.6 cycles/byte
Atom | - | 4.2 cycles/byte | 4.2 cycles/byte


В результате тут побеждает Cortex-A8 именно за счет наименьшей латентности операций Обработка четырех байт реализуется с помощью 13 инструкций и выполняется 8 тактов (IPC=~1.6). Причем 8 тактов - это как раз длина dependency chain без лишних задержек, так что это теоретический предел для данного процессора без изменения алгоритма. Код основного цикла на ARM ассемблере:
код:

ldr TMP, [BUF], #4
and X0, CRC, #0xFF

uxtb X1, CRC, ror #8
uxtb X2, CRC, ror #16

ldr X0, [TABLE3, X0, lsl #2]
uxtb X3, CRC, ror #24

ldr X1, [TABLE2, X1, lsl #2]

ldr X2, [TABLE1, X2, lsl #2]
eor CRC, TMP, X0

ldr X3, [TABLE0, X3, lsl #2]
eor CRC, CRC, X1

eor CRC, CRC, X2

eor CRC, CRC, X3


slice-by-eight из xz (C (http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/check/crc32_fast.c;h=94da85592d8adbd90ca35ce7b80c38ab727ced0e;hb=20778053a07eb90c159c1377ca8dc05a90fd530b) и 32-bit ассемблер (http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/check/crc32_x86.S;h=67f68a4145f8bdd8b90883401ffbc11f67122b65;hb=20778053a07eb90c159c1377ca8dc05a90fd530b) ):
код:

CPU | ASM (32-bit) | C (32-bit) | C (64-bit)
--------------+-------------------+-----------------+------------------
Cortex-A8 | - | 2.6 cycles/byte |
Cortex-A9 | - | 2.8 cycles/byte |
Cortex-A15 | - | 1.9 cycles/byte |
Core i7 | 1.0 cycles/byte | 1.3 cycles/byte | 1.7 cycles/byte
Atom | 5.0 cycles/byte | 4.3 cycles/byte | 4.3 cycles/byte

Надо будет ещё будет дописать ассемблерную реализацию slice-by-eight для ARM. Cortex-A15 должен получить хорошее ускорение

991. lkj, 07.11.2012 01:03
ssvb

А можно в ту табличку добавить еще результаты Asm/arm/7zCrcOpt.asm из LZMA SDK?

slice-by-8 увеличивает нагрузку на кэш c 4 KB до 8 KB. И на слабых процессорах может быть замедление. Поэтому 7-Zip использует slice-by-8 только для OoO процессоров x86. Для всех остальных - slice-by-4.

992. ssvb, 07.11.2012 02:12
lkj
А можно в ту табличку добавить еще результаты Asm/arm/7zCrcOpt.asm из LZMA SDK?

Там используется какой-то нестандартный ассемблер, поэтому весь файл я не компилировал и на корректность не проверял. Но основной цикл (13 инструкций) вынес в отдельную тестовую программу, которая позволяет легко оценить быстродействие (на linux или android железе):
код:

.text
.arch armv7-a
.global main

#ifndef CPU_CLOCK_FREQUENCY
#error CPU_CLOCK_FREQUENCY must be defined
#endif

#define LOOP_UNROLL_FACTOR 30
#define STREAM_WORD r10

.type main, %function
main:
push {r4-r12, lr}
ldr ip, =(CPU_CLOCK_FREQUENCY / LOOP_UNROLL_FACTOR)
mov r1, sp
sub sp, sp, #(1024 * 4)

add r6, sp, #(1024 * 0)
add r5, sp, #(1024 * 1)
add r4, sp, #(1024 * 2)
add r3, sp, #(1024 * 3)

1:
.rept LOOP_UNROLL_FACTOR
/* main loop of the arm optimized crc32 code from lzma sdk 9.22 */
eor r7, r7, r8
eor r7, r7, r9
eor r0, r0, r7
eor r0, r0, STREAM_WORD
ldr STREAM_WORD, [r1] /* , #4 */

and r7, r0, #0xFF
and r8, r0, #0xFF00
and r9, r0, #0xFF0000
and r0, r0, #0xFF000000

ldr r7, [r6, +r7, lsl #2]
ldr r8, [r5, +r8, lsr #6]
ldr r9, [r4, +r9, lsr #14]
ldr r0, [r3, +r0, lsr #22]
.endr
subs ip, ip, #1
bne 1b

add sp, sp, #(1024 * 4)
mov r0, #0
pop {r4-r12, pc}


Cortex-A9 (~15.5 тактов на 13 инструкций, обрабатывающих 4 байта):
код:

# gcc -DCPU_CLOCK_FREQUENCY=1700000000 bench-lzma-crc.S && perf stat ./a.out

Performance counter stats for './a.out':

15460.000000 task-clock # 1.000 CPUs utilized
20 context-switches # 0.001 K/sec
2 CPU-migrations # 0.000 K/sec
98 page-faults # 0.006 K/sec
26345778539 cycles # 1.704 GHz
1301714 stalled-cycles-frontend # 0.00% frontend cycles idle
11035416769 stalled-cycles-backend # 41.89% backend cycles idle
22228600463 instructions # 0.84 insns per cycle
# 0.50 stalled cycles per insn
58271070 branches # 3.769 M/sec
432808 branch-misses # 0.74% of all branches

15.467304101 seconds time elapsed


Cortex-A15 (~12 тактов на 13 инструкций, обрабатывающих 4 байта):
код:

$ gcc -DCPU_CLOCK_FREQUENCY=1700000000 bench-lzma-crc.S && perf stat ./a.out

Performance counter stats for './a.out':

12056.545332 task-clock # 1.000 CPUs utilized
18 context-switches # 0.001 K/sec
0 CPU-migrations # 0.000 K/sec
84 page-faults # 0.007 K/sec
20495993036 cycles # 1.700 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
22227561076 instructions # 1.08 insns per cycle
59338625 branches # 4.922 M/sec
152468 branch-misses # 0.26% of all branches

12.057604921 seconds time elapsed


Cortex-A8 (~12 тактов на 13 инструкций, обрабатывающих 4 байта):
код:

$ gcc -DCPU_CLOCK_FREQUENCY=1000000000 bench-lzma-crc.S && time ./a.out

real 0m12.058s
user 0m12.047s
sys 0m0.000s


В итоге, обновленная табличка будет выглядеть примерно так:
код:

CPU | LZMA ASM (32-bit) | ASM (32-bit) | C (32-bit) | C (64-bit)
------------+-------------------+-----------------+-----------------+----------------
Cortex-A8 | 3.0 cycles/byte | 2.0 cycles/byte | 3.3 cycles/byte | -
Cortex-A9 | 3.9 cycles/byte | 2.7 cycles/byte | 3.5 cycles/byte | -
Cortex-A15 | 3.0 cycles/byte | 2.5 cycles/byte | 2.9 cycles/byte | -
Core i7 | ? | - | 2.1 cycles/byte | 2.6 cycles/byte
Atom | ? | - | 4.2 cycles/byte | 4.2 cycles/byte

Добавление от 07.11.2012 02:22:

lkj
slice-by-8 увеличивает нагрузку на кэш c 4 KB до 8 KB. И на слабых процессорах может быть замедление. Поэтому 7-Zip использует slice-by-8 только для OoO процессоров x86. Для всех остальных - slice-by-4.

Судя по всему, слабых процессоров больше нет. Разве что Atom слегка просел на slice-by-8, но скорее всего это немного подгадил компилятор.

993. deadlock, 07.11.2012 02:52
ssvb
У Krait L0 - 4КБ (http://www.anandtech.com/show/4940/qualcomm-new-snapdragon-s4-msm8960-krait-architecture/2) но вроде там без разницы что L0 что L1

994. TOTGEBOREN, 07.11.2012 11:59
nenin
C60- не предмет для гордости, а повод тестануть заката.

Так и я о том чтоб потестить.

995. lkj, 07.11.2012 12:41
ssvb

В линуксе для Cortex-A15 есть поддержка для альтернативных размеров страниц?
Можно проверить два варианта:
1) заменить обычные 4 KB на 64KB.
2) выделить отдельный пул Huge Pages для 1 MB / 16 MB секций.

Прирост скорости для 7-Zip Compression должен быть
10-20%.

Добавление от 07.11.2012 13:24:

ssvb

Судя по всему, слабых процессоров больше нет.

Нет среди новых процессоров. Но есть сотни миллионов ARM9/ARM11, где этот код тоже могут запускать.

Там используется какой-то нестандартный ассемблер

Это ассемблер для Windows CE.
Кстати, тесты на XScale показывали, что если размер блока превышает размер L1 Cache, то лучше делать префетч (pld) +64.
Для Cortex-A8/A9/A15 уже нет смысла делать pld в этом коде?
Есть какое-нибудь падение скорости на границах размеров L1 и L2?
Увидеть можно в тесте 7z b -mm=crc

996. ssvb, 07.11.2012 17:09
lkj
цитата:
В линуксе для Cortex-A15 есть поддержка для альтернативных размеров страниц?
пока нет, но пилят - http://lwn.net/Articles/478097/
цитата:
Нет среди новых процессоров. Но есть сотни миллионов ARM9/ARM11, где этот код тоже могут запускать.
И действительно, на ARM11 есть эффект замедления от лукапов даже в 4K таблицу, на остальных процессорах практически без разницы. Тут "zero mem" - это подсчет CRC32 по большому блоку памяти, заполненному нулями при начальном CRC32=0xFFFFFFFF (а этом случае все лукапы попадают на нулевые элементы таблиц и нагрузка на кэш снижается):

=== ARM11 700MHz ===
l1 cache cycles per byte = 3.36
rand mem cycles per byte = 4.25
zero mem cycles per byte = 3.67
=== Cortex-A8 1GHz ===
l1 cache cycles per byte = 2.02
rand mem cycles per byte = 2.31
zero mem cycles per byte = 2.25
=== Cortex-A9 1.7GHz ===
l1 cache cycles per byte = 2.74
rand mem cycles per byte = 2.86
zero mem cycles per byte = 2.75
=== Cortex-A15 1.7GHz ===
l1 cache cycles per byte = 2.51
rand mem cycles per byte = 2.54
zero mem cycles per byte = 2.62

цитата:
Для Cortex-A8/A9/A15 уже нет смысла делать pld в этом коде?
Если убрать использование PLD, то получается:

=== ARM11 700MHz ===
l1 cache cycles per byte = 3.37
rand mem cycles per byte = 7.16
zero mem cycles per byte = 6.88
=== Cortex-A8 1GHz ===
l1 cache cycles per byte = 2.01
rand mem cycles per byte = 4.11
zero mem cycles per byte = 4.10
=== Cortex-A9 1.7GHz ===
l1 cache cycles per byte = 2.69
rand mem cycles per byte = 3.36
zero mem cycles per byte = 3.28
=== Cortex-A15 1.7GHz ===
l1 cache cycles per byte = 2.53
rand mem cycles per byte = 2.59
zero mem cycles per byte = 2.58

Т.е. на практике PLD совсем не нужен только на Cortex-A15.
цитата:
Есть какое-нибудь падение скорости на границах размеров L1 и L2?
У Cortex-A8 нет аппаратного префетча, а PLD предзагружает данные только в L2. Соответственно, на каждые 64 байта обработанных данных есть промах в L1 с блокировкой конвейера на ~10 тактов до получения данных из L2.
цитата:
Увидеть можно в тесте 7z b -mm=crc
IMHO мой тест лучше и показывает намного более интересную информацию

997. Marat Dukhan, 07.11.2012 21:44
ssvb
Если не трудно, замерьте throughput VMLA.F64 и VFMA.F64 на Cortex-A15.

998. ssvb, 08.11.2012 02:48
Marat Dukhan
Я не смог найти никакой разницы на Cortex-A15 в скорости выполнения между VMLA.F64 и VFMA.F64. Надо полагать, что всё отличие только в отсутствии промежуточного округления и точности вычислений. Throughput - 1 инструкция за такт. Latency - 4 такта, если результат используется как аккумулятор для следующей VMLA.F64/VFMA.F64 инструкции и 10 тактов в остальных случаях.

Улучшения плавающей точки по сравнению с Cortex-A9 (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/ch02s03s02.html) : выше throughput для double precision умножений (одна инструкция за такт вместо одной инструкции за 2 такта), out-of-order, возможность выполнения FP арифметики одновременно с FP load/store. Однако сама скалярная FP арифметика выполняется с темпом не более одной инструкции за такт (хотя я проверил далеко не все варианты).

Что касается NEON арифметики на Cortex-A15, то там может выполняться одна 128-битная VMLA.F32/VFMA.F32 инструкция за такт. Похоже, что две 128-битные NEON инструкции за такт достижимы только для целочисленных вычислений. При этом всё же возможно одновременное выполнение двух 64-битных NEON инструкций с FP арифметикой за такт. Хмм, похоже на самом деле всё не настолько симметрично, и за 1 такт NEON кластер может выполнять:
1. одну 128-бит FP инструкцию
2. две 64-бит FP инструкции
3. одну 64-бит FP инструкцию и одну 128-бит INT инструкцию
4. одну 128-bit INT и одну 64-бит INT инструкцию
5. две 64-бит INT инструкции
Если в потоке кода используются только целочисленные 128-битные NEON инструкции, то время выполнения примерно такое же, как если бы каждая вторая из них была просто разбита на пару из 64-бит INT инструкций.

Т.е. получается, что ширина NEON в Cortex-A15 условно равна 128-бит для плавающей точки и 192-бита для целочисленых вычислений? Соответственно, для сравнения, у Cortex-A8/Cortex-A9 ширина NEON была 64-бита для плавающей точки и 128-бит для целочисленки.

999. lkj, 08.11.2012 10:34
ssvb

Т.е. на практике PLD совсем не нужен только на Cortex-A15.

Совсем не нужен всегда?
Какую максимальную скорость чтения из памяти можно получить с PLD и без PLD?

код:

int s = 0;
int *p = malloc(...);

s += p[0];
pld(p + x);

s += p[16];
pld(p + 16 + x);

....

1000. Marat Dukhan, 08.11.2012 15:39
ssvb
Спасибо. Печально, что нельзя сделать 128-бит MOV + 64-бит FMA, рассчёт полиномов упирается в декодер.

1001. ssvb, 08.11.2012 17:37
Marat Dukhan
Прошу прощения за неточность, 64-бит FP + 128-бит INT (в том числе и MOV) тоже могут выполняться параллельно за один такт. Исправил своё предыдущее сообщение.

Учитывая, что load/store на Cortex-A15 выполняются в отдельном кластере, можно получить темп выполнения более двух инструкций за такт. Например, выполнение одной итерации следующего кода в цикле занимает 7.1 тактов (IPC=2.12):
код:

vldr.f64 d0, [sp, #0]
vadd.f64 d2, d2, d0
vmov.f64 q11, q1

vldr.f64 d0, [sp, #8]
vadd.f64 d4, d4, d0
vmov.f64 q12, q2

vldr.f64 d0, [sp, #16]
vadd.f64 d6, d6, d0
vmov.f64 q13, q3

vldr.f64 d0, [sp, #24]
vadd.f64 d8, d8, d0
vmov.f64 q14, q4

vldr.f64 d0, [sp, #24]
vadd.f64 d10, d10, d0
vmov.f64 q15, q5

Если не надеяться на out-of-order исполнение и вручную переупорядочить инструкции, то IPC для данного кода вырастает до 2.25 (к сожалению, не до трёх инструкций за такт).

Добавление от 08.11.2012 18:05:

В общем, теоретический предел производительности для вычислений с плавающей точкой на dual-core Cortex-A15 1.7GHz будет равен 6.8 GFLOPS при использовании VMLA.F64/VFMA.F64, при этом ряд других инструкций (load/store/mov) могут исполняться параллельно и "подносить снаряды". Чуть позже попробую собрать blas-atlas и получить реальные флопсы для linpack.

Добавление от 09.11.2012 00:18:

Бенчмарк hpl (high performance linpack), проведённый таким же образом, как и в x86 против arm, power, sparc, gpu, cell и других. (часть 2), #4332 (http://forum.ixbt.com/topic.cgi?id=8:23098:4332#4332)
Cortex-A15 по сравнению со старыми результатами для Cortex-A9:

код:

=== ARM Cortex-A9 @1.2GHz (dualcore) ===
gcc 4.5.3, CFLAGS="-O3 -mcpu=cortex-a9 -mfpu=neon -pipe"

atlas : 0.765 Gflops
atlas-threads : 1.307 Gflops

=== ARM Cortex-A15 @1.7GHz (dualcore) ===
gcc 4.7.2, CFLAGS="-O3 -mcpu=cortex-a15 -mfpu=neon-vfpv4 -pipe"

atlas : 2.378 Gflops
atlas-threads : 4.324 Gflops

Добавление от 09.11.2012 00:35:

Да, и "perf stat mpirun -np 1 xhpl" выдаёт следующую статистику для работы этого linpack (hpl + blas-atlas-3.9.23) на Cortex-A15:

код:

35456370549 instructions # 1.25 insns per cycle
1395701890 branches # 83.501 M/sec
31282066 branch-misses # 2.24% of all branches

1002. RainMan90, 09.11.2012 20:42
Вот вы всё ARM, ARM. Итаниум (http://www.overclockers.ru/hardnews/50539/Intel_predstavila_processory_Itanium_9500.html) наше всё!

1003. screen_237, 09.11.2012 21:27
Подымите руку у кого стоит или кто планирует поставить

Страницы: назад · 1 2 3 5 6 7 8 9 10 11 12 13 14 15 49 50 51 · далее / все сообщения темы на одной странице


URL: http://forum.ixbt.com/topic.cgi?id=8:23952

Время GMT +03. Даты в формате dd.mm.yyyy.