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]

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

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

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


Ответ на: комментарий от kranky

Да и отрицание обычно проявляется в подростковом возрасте, дети же обычно прислушиваются к тому, что говорят им (или друг другу) взрослые.

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

так что, возможно, дело таки в ней.

Если честно, думаю, да.

Я бы не сказал, что обходятся они прекрасно. Со средней продолжительностью жизни в 25 лет то.

Странно. А передачи по дискавери вполне себе показывают и 60-летних индейских стариков. Врут?

Как что, массовая гибель лекарствозависимых.

Эволюция.

Ох как сомнительна мне эта воспитательная ценность. Если забыть про басни и плакаты «Не влезай - убьёт!», всё серьёзное искусство в большинстве своём бессмысленно и беспощадно.

По-моему, вы хороших книг не читали.

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

Вы не правы.
Java не работает с системной кучей а использует custom allocator.

Сделайте то-же и для С++ иначе ваш тест совершенно не корректен.

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

При компиляции под размер — неоптимальны, да. А вот под скорость — ещё в конце 1990-х стали конкурентоспособны.

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

И в итоге, если стоит задача ужать по максимуму, компилятор дает результат хуже

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от grim

Сделайте то-же и для С++ иначе ваш тест совершенно не корректен.

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

Там же, кстати, есть тест в boost. Вполне себе custom. Всё равно оказалось медленнее Java. Хотя уже и не в разы. Но это, как раз, уже не корректное сравнение. Т.к. встроенный механизм одного языка сравнивается со специализированной библиотекой другого.

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

Как я заметил, gcc-avr при компиляции вычислений очень любит заносить начальные данные в какие-то определенные регистры.

Ну, GCC генерирует не самый оптимальный код. Во времена, когда я сидел под Windows, он на x86 заметно проигрывал тому же MS VC. А под Linux (опять же, x86) заметно проигрывает ICC.

Некоторые программы, собранные ICC, у меня на треть быстрее работали, чем собранные GCC. Даже gzip на 13% шустрее получался: [ЖЖ] Updates. (комментарий)

Другое дело, что едва ли треть софта под под ICC работала :) Половина вообще не собиралась, а многое из того, что собиралось, не работало или глючило.

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

Другое дело, что едва ли треть софта под под ICC работала :)

ну чтож поделать, коль не все любят работать по стандартам.

cvs-255 ★★★★★
()

Хороший компилятор сравнительно сложного языка написать не так просто.

Quasar ★★★★★
()
Ответ на: комментарий от cvs-255

Мой опыт программирования под AVR

AVR это абсолютно другой случай. Там ПО выполняется напрямую из памяти, нет out-of-order execution, нет многоуровневой системы кэшей, нет векторных вычислений, объём программ сильно ограничен, набор инструкций сильно проще.

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

Прикинь, ничего не изменилось, обращение к памяти осталось обращение к памяти, а обращение к регистру осталось обращением к регистру. Эта «память», кстати, может быть и не в памяти.

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

Это всё фигня, главный затык на мелких архитектурах - размер, число регистров и их специализированность. Компилятор просто не может «развернуться» и топчется на месте гоняя впустую данные в/из памяти.

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

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

PS буду честен, под avr писал буквально пару hello world, потом взял avr-gcc :)

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

А если C++ использует объекты, и не в стеке, а в хипе, то Java будет в разы быстрее

это измерение скорости glibc-го malloc/free (а есть и более быстрые реализации), используя же свой аллокатор, можно добиться скорости варианта на стеке

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

А вот с x86 можно почитать очень много историй как люди пытались превзойти компилер.

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

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

Со средней продолжительностью жизни в 25 лет то.

Странно. А передачи по дискавери вполне себе показывают и 60-летних индейских стариков. Врут?

Средняя продолжительность жизни во многом определяется высокой детской смертностью.

tailgunner ★★★★★
()

Ты уверен что это оптимально? То что меньше команд ещё не значит что быстрей.

ranka-lee
()
Ответ на: комментарий от lenin386

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

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

Кстати, в свете последних российских событий… Должен ли адепт ЛММ писать спагетти-код?

wtf is «последние российские события» и «ЛММ»?

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

типично в разы быстрее жабы.

Смоешь доказать в цифрах?
ЗЫ. Еще один желает на ящик коньяка попасть :)

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

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

Руки прочь от святого!!!!

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

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

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

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

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

если говорить про dalvik:

http://lh5.ggpht.com/_EW60jqE5_B0/SjOyPJJR4SI/AAAAAAAAAEk/gQ97Q9WuZdY/s800/qu...

если про sun(oracle):

http://lh5.ggpht.com/_EW60jqE5_B0/SjOyPFoV2SI/AAAAAAAAAEo/ZF2DkcBFI30/s800/qu...

но в обоих случаях используется С с qsort, С++ с std::sort будет еще раза в два быстрее, за счет отсутствия оверхеда на коллбэк

П.С. мой пост не про Java в целом, а про то, что dalvik отдельная история с отдельной производительностью

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

за счет отсутствия оверхеда на коллбэк

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

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

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

вот как раз в случае С++ он так и сделает, т.к. там std::sort - шаблон, а не библиотечная функция

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

1/2? 1/3? Предлагаю не считать что производительность «отличается», если разница хотя бы порядок

3 часа и 9 часов, разница не на порядок, давайте её не считать:) Но в первом случае утром запустил к обеду получил результат, во втором рабочий день (сутки) мимо

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

во втором случае кстати батарейка Андроида (раз уж тема про arm и андроид) успеет сесть, так что результата не будет вовсе :)

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

А в каком месте Си на iPhone? o_O

В играх, к примеру.

Я думал там Objective C.

А еще C++

andreyu ★★★★★
()

Это они писали на самодельном компиляторе, мой тот еще гоанокод выдает.

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

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

А нормальный компилятор умеет C11/C++11?

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

Ха!
Массивы совершенно штатное средство С++
Вся разница только в том, что в вашем случае Java их использует неявно.

Т.е. тест совершенно некорректен, пока не перейдете к массивам в C++

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

Смоешь доказать в цифрах?

не испытываю такой необходимости.

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

если говорить про dalvik:

Нормальной VJM и в подметки не годится по скорости. У dalvik оптимизация по памяти. Шняга в общем.

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