LINUX.ORG.RU
ФорумTalks

Эффективный компилятор под Android

 , , ,


1

3

Кажется, я понял почему современным девайсам под ведром нужно всё больше памяти и ядер.
Разбирая в дизассемблере код закрытых дров наткнулся на такие чудесные экземпляры, как:

MOV R2, #0xFF0
MOV R8, R0
MOV R9, R1
ORR R2, R2, #0xF

Вместо 1 и 4 команд надо было MOV R2, #0xFFF

MOV R6, #0
MOV R1, #0
STR R6,[SP,#0x1070]

Первая команда совем не нужна

И так весь код. У другого нативного ПО также. Около трети команд можно вообще выкинуть. Отсальная часть крайне неоптимальна.

Что это было ? Заговор производителей с разрабами ? Может, я туплю и так надо ?


А ты уверен, что они писали на асме, а не на си например? Ну а там компилятор собрал как умеет.

vurdalak ★★★★★
()

надо было

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

buddhist ★★★★★
()

тоже видел такое в дизасме. подтверждаю, что если весь мусор выкинуть и/или поменять на правильные инструкции — все продолжает работать, и ускоряется. но насчет причины общей тормознутости ты не прав. все дело в жабе и напрочь кривой архитектуре. ибо даже с -O0 сишный код (даже вот так криво откомпилированный) типично в разы быстрее жабы.

waker ★★★★★
()
Ответ на: комментарий от waker

ибо даже с -O0 сишный код (даже вот так криво откомпилированный) типично в разы быстрее жабы.

«Разы» как-то не набегают: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

Даже на сильно оптимизированных задачах.

KRoN73 ★★★★★
()
Последнее исправление: KRoN73 (всего исправлений: 1)
Ответ на: комментарий от true_admin

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

Другое дело, что этого может быть мало.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)

Есть нормальный компилятор - IAR. Но никому ведь не надо это. Нам халявы надо, и побооольше.

lenin386 ★★★★
()
Ответ на: комментарий от KivApple

Если из кода убрать часть команд не меняя логику, он станет работать быстрее в любом случае

Не в любом. Возможны тормоза на отсутствии выравнивания. Компиляторы нередко NOP подсовывают для оптимизации скорости выборки.

KRoN73 ★★★★★
()
Ответ на: комментарий от vurdalak

Скорее всего на си и писали. Меня это удивляет на фоне заявлений, что C/C++ компилторы генерируют код эффективней, чем мог бы это сделать человек на асме.

pinus
() автор топика
Ответ на: комментарий от KRoN73

А если C++ использует

А, вы драйверы на С++ пишете. Понимаю. Да нет проблем, только зачем вы стебаетесь над кодом Линукс дров ?

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Не в любом. Возможны тормоза на отсутствии выравнивания

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от KivApple

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

Весь мир делится на тех кто уже пытался перехитрить компилятор руками и на тех кто пишет посты на лоре :)

true_admin ★★★★★
()
Ответ на: комментарий от pinus

Меня это удивляет на фоне заявлений, что C/C++ компилторы генерируют код эффективней, чем мог бы это сделать человек на асме.

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

zz ★★★★
()
Ответ на: комментарий от vurdalak

Почему?

Потому что все люди разные. Компиляторы разрабатывают умные дядьки. А вот оптимизацией занимаются все кому не лень.

Впрочем, конкретно с arm я не удивлюсь если компилеры серьёзно косячат. А вот с x86 можно почитать очень много историй как люди пытались превзойти компилер. Получается редко. Да, tailgunner?

true_admin ★★★★★
()
Ответ на: комментарий от zz

Я говорил не конкретно о компиляторах, а вообще о применении техники.

vurdalak ★★★★★
()
Ответ на: комментарий от pinus

в первом случае работает за счет barrel shift. 12 бит много, должно быть 8.

AptGet ★★★
()

«Неоптимальна» это чем-то материальным типа тестов подтверждается ? Армовский асм не знаю, но для 86-го

xor ax,ax
dec ax
вместо
mov ax,FFFFh
очень даже оптимально.

ilovewindows ★★★★★
()

Посадили JAVA-мартышек за C и вот что вышло.

Lavos ★★★★★
()
Ответ на: комментарий от vurdalak

всегда можно найти человека глупее машины.

Вот что мне в тебе не нравится так это периодические перегибы. Ты даешь какие-то очень странные ответы. Вот и сейчас ты пишешь что «при желании можно найти дурака». А речь-то идёт об одной из сложнейших областей — оптимизации компиляторов. Тут дураками будет 99.9% лора. Причём, для каждого проца свои оптимизации. То что работает для Intel может затупить на AMD, например. Поэтому и существуют всякие -march и куча других флагов. И надо быть Сильвией чтобы хотя бы приблизительно понимать как это всё вместе работает.

true_admin ★★★★★
()
Ответ на: комментарий от KRoN73

«Разы» как-то не набегают

1/2 это как раз набежавшие округлённые «разы» - средне один к двум. Для С vs Java на том-же сайте типичное отношение 1/3 в пользу С.

впрочем, это к теме не относится.

а к теме - если из asm листинга для arm, выкинуть или заменить на первый взгляд бессмысленные команды, то может или перестать работать или начать тормозить. На то он и arm :)

MKuznetsov ★★★★★
()
Ответ на: комментарий от KivApple

Если из кода убрать часть команд не меняя логику, он станет работать быстрее в любом случае

4.2, наглейшее

buddhist ★★★★★
()
Последнее исправление: buddhist (всего исправлений: 1)

Это все проблемы gcc, увы. У шланга говорят на выхлопе лучше, но не намного.

ncrmnt ★★★★★
()
Ответ на: комментарий от true_admin

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

vurdalak ★★★★★
()
Ответ на: комментарий от ilovewindows

xor ax,ax
dec ax
вместо mov ax,FFFFh
очень даже оптимально.

Было 25 лет назад. Прикинь, на дворе 2013-й год. 1993-й год, когда выпустили Pentium, давно прошёл. Прошёл.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)

Как уже выше сказали, 0xfff не является допустимой константой. А 0xf000000f, например, вполне.

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

По оптимизации IAR на ARM-ах или эквивалентен GCC или часто проигрывает.

alexru ★★★★
()
Ответ на: комментарий от lenin386

Было 25 лет назад. Прикинь, на дворе 2013-й год.

А точно на x86 сегодня загрузка константы — это два такта (или один такт на распараллеливании)?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Ты посмотри ещё код Linux-дров!

Те которые стороние или те которые в самом ядре?

splinter ★★★★★
()
Ответ на: комментарий от true_admin

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

*fixed

splinter ★★★★★
()
Ответ на: комментарий от vurdalak

Машина умеет только повторять заданную программу. Она не адаптивна

Как там в начале 20-го века у вас дела? Первые работы по нейросетям опубликовали уже, или пока нет?

Машина в принципе не работает эффективнее человека.

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

kranky ★★★★★
()
Последнее исправление: kranky (всего исправлений: 1)
Ответ на: комментарий от KRoN73

А точно на x86 сегодня загрузка константы — это два такта

На x86 сегодня команды потактово считают только съехавшие с катушек полностью ретрограды и нахватавшиеся интернета идиоты. Суперскалярная архитектура. Подъём ! Нет ни одного справочника с растактовкой на процессор выше Пентиума и не может быть.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от AptGet

не может быть такой команды, операнд слишком длинный

О! Я даже не обратил внимание :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Не знаю, что такое куча в бытовом смысле. Я знаю что такое «множество». Два ореха - это множество.

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

Elapsed secs Code

C++ g++ 5.98 6.00 185,560 648 0% 1% 1% 100%

Java 7 23.29 23.30 557,404 1284 0% 0% 0% 100%

И это при: 648 байт кода на плюсах против 1284 байт кода на Яве.

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

next_time ★★★★★
()
Ответ на: комментарий от lenin386

Суперскалярная архитектура.

Она ещё на Pentium появилась. И там xor&dec был всё ещё выгоднее прямой загрузки констант. Кстати, было это не 25 лет назад, а 15.

Как я понимаю, по сегодняшним растактовкам (суперскалярная архитектура ни разу от них не избавляет) у тебя данных нет, одна вера?

KRoN73 ★★★★★
()
Ответ на: комментарий от kranky

Первые работы по нейросетям опубликовали уже, или пока нет?

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

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.