В пределах управляемого окружения — может и делает. Я же кидал линк.

Большинство андройд-погроммистов как-то с трудом осиливают интенты и FutureTask. Если кастрация RAM подтолкнёт обезьян к искривлению извилин спинного мозга, то я только за.

я с тобой абсолютно согласен. в реальных приложениях где активно работает gc жаба не может сравниться с си. но вот если взять кусок кода с большими вычислениями (впринципе это и есть «найти простые числа от 1 до 1000»), то жаба будет всего в 10 раз медленнее си.

похоже у них получилось, на 4.4 sgs2 работает визуально лучше.

Эклипса тормозит потому что говно, а не потому что ява. Идея вот тоже на яве, но не тормозит почему-то.

Как ты заинлайнишь функцию из внешней динамической библиотеки?

Функции типа strcpy инлайнятся спокойно самим компилятором. Более сложные функции инлайнить нет смысла.

Эмм. Из внешней библиотеки? А если она меняется?

Жаба сравнима с си только на бенчмарках

А давай-ка начнём с реальности. У тебя есть телефон, на телефоне - приложения. Почти все приложения ориентированы на мобильник, следовательно завязаны на интернет, звонки и т.д. Все эти задачи — это, грубо говоря, отдача команды, её ожидание неопределенное время и реакция на результат. При этом интерфейс должен быть отзывчивым несмотря на кажущуюся блокировку в потоке программы.

В случае жабы получается, что есть gc и можно поставить задачу в очередь на выполнение, подцепив к какому-то событию. Особенно удобно это в скале (scaloid):
[code]request("http://site.com/lol") onComplete { ... }[/code]
И никакой блокировки нет вообще, и всё работает, пишется просто и тривиально.

С другой стороны, смотрим на айфон: там нет инструментов для асинхронного программирования, ибо нет gc, который подметёт за программой. Хочешь чтобы интерфейс не блокировался, и всё летало? Пишешь пачку потоков, которые как-то друг с другом контачат, все они жрут ресурсы ибо 99% времени висят без дела, но при этом регулярно опустошают процессорные кеши из-за беспорядочного переключения контекстов. Но зато С (obj-c), блджад!

Жаба сравнима с си только на бенчмарках уровня «найти простые числа от 1 до 1000». Речь-то о приложениях.

На приложениях, как раз, разница меньше.

Жаба выполняется на виртуальной машине и имеет сборщик мусора (что уже означает непредсказуемые паузы длинной по несколько миллисекунд и повышенное потребление памяти).

Вполне предсказуемые. На L2J серверах тысячи народа играли в онлайне, не имея никаких затыков во время работы GC.

Так каким образом она может хоть как-то сравниться с C?

Как только в Си сложность объектов не позволит уложить их в стек и потребует выделения/освобождения памяти, как скорости сразу становятся сравнимыми.

Объективный минус у Java не в производительности, а в запросах на память и долгом стартапе.

То-то в документации написано, что создавать временные объекты в часто работающих методах (measure/layout, onDraw) крайне не рекомендуется.

Вот тут сравнение частого создания удаления объектов: https://github.com/Balancer/benchmarks-fib-obj/wiki/Результат-теста:-i3-2.2ГГц

то жаба будет всего в 10 раз медленнее си.

Толсто: http://benchmarksgame.alioth.debian.org/u64/java.php

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

С другой стороны, смотрим на айфон: там нет инструментов для асинхронного программирования,

man libdispatch

Пишешь пачку потоков

4.2, man libdispatch

Вот что бывает, когда человек пытается говорить про iOS, ничего не зная о ней.

На приложениях, как раз, разница меньше.

Голословно

Вполне предсказуемые. На L2J серверах тысячи народа играли в онлайне, не имея никаких затыков во время работы GC.

Вы вообще понимаете разницу между скриптом на сервере (которому мусор вообще незачем собирать, итак умрёт через секунду) и приложением для мобильного устройства? Да, GC нормально себя чувствует на сервере. Когда будут серверы под андроидом — тогда засчитаем это за аргумент.

Как только в Си сложность объектов не позволит уложить их в стек и потребует выделения/освобождения памяти, как скорости сразу становятся сравнимыми.

Я так понимаю это намёк на то, что GC якобы выделяет память быстрее, чем malloc. Во-первых ничего подобного, во-вторых оверхед на объекты и GC состоит вовсе не в выделении памяти.

Объективный минус у Java не в производительности, а в запросах на память и долгом стартапе.

Это опять про сервера, а не про смартфоны и планшеты.

Точно удалялись? На десктопе до GC могло дело и не дойти.

В любом случае, эмпирически доказано: сборка мусора на андроиде иногда проявляется в виде лагов интерфейса.

они жрут ресурсы

ибо 99% времени висят без дела

Я так понимаю, с программированием у Вас на уровне лабораторных по Паскалю?

Последний и предпоследний. 4с пока неплохо держится, хотя видно, что на него практически забили.

Не расслабляться!

Надо было вообще 256 МБ оставить, чтобы потом плавно подойти к заветным 64 МБ и экрану с 800x600 пикселей. Должно хватить всем. В конце 1990-х-начале 2000-х, помнится, хватало с головой.

Сразу после старта на ней съедается 650Мб. Такая вот эта Java.

Так эта ваша Java работает на том, что написано на C++. Когда JVM перепишут на Java и отАОТят на целевой системе, то будет жраться минимум, так как байткод будет выполнятся нативно, а не интерпретироваться.

Я так понимаю это намёк на то, что GC якобы выделяет память быстрее, чем malloc. Во-первых ничего подобного, во-вторых оверхед на объекты и GC состоит вовсе не в выделении памяти.

Ты это про какой GC говоришь?

В любом случае, эмпирически доказано: сборка мусора на андроиде иногда проявляется в виде лагов интерфейса.

На моих девайсах лаги интерфейса вылезают на интенсивном IO. Тут, походу, генетическая болезнь. Если фоновых приложений нет и флешками никто активно в фоне не занят, то летает даже интерфейс на древнем HTC Wildfire S с 800МГц процессором и 512Мб оперативки. Никаких лагов в интерфейсе.

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

Ты хотел сказать «врукопашную». ;)

В Java такого нет в принципе, и авторы библиотек фигачат всё прямо на Java. В результате любая операция создаёт целые кучи объектов и на корню рубит возможность всё перегнать через JIT. У разработчика приложения просто нет запаса производительности, который он мог бы использовать.

В десктопной JRE 7 сейчас можно включить сборщик мусора G1, но если памяти мало, то CMS. В Android будет AOT.

Много раз здесь обсуждалось, понятие о лагах у всех разное. В 4.3 появилась опция «On-screen GPU profiling», которая выглядит так: ссылка
Все, что выскакивает за зеленую линию, — тормоза.

В Android будет AOT.

Это как-то ускорит сборку мусора? В Obj-C всегда был «AOT», но как-то отказались в пользу подсчета ссылок (по-моему самый оптимальный вариант).

Много раз здесь обсуждалось, понятие о лагах у всех разное

Угу. И я из тех, кто в этом плане очень капризен. Если что, интерфейс Firefox'а для меня сильно тормозной. А Compiz тормозит по сравнению с Beryl :)

Так каким образом она может хоть как-то сравниться с C? Перечисли эти способы, и тогда можно будет обсудить, работают ли эти фишки в android-приложениях.

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

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

но вот если взять кусок кода с большими вычислениями (впринципе это и есть «найти простые числа от 1 до 1000»), то жаба будет всего в 10 раз медленнее си.

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

ну погоди, давайка начнём с реальности (с). Вот сейчас у меня в руках ipad и андроид. оба более-менее последние. чисто по ощущениям ipad как минимум не тормознее андроида (у андроида тегра 4, у ipad не знаю). и аккамулятор жрёт меньше. т.е. может ты и прав насчёт скалы и прочего, но

1) явапрограммисты не знают про onComplete, а сколько там програм на скале под андроидом? 1%? а явщики юзают примерно то же что и сишники, т.е. потоки.

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

так оно и есть. судя по тестам лучше говорить «производительность жабы находится на том же порядке, что и си\си++» т.е. отношение производительностей <= 10.

Повторяю для особо тупых: в ведроиде нет и никогда не было жабы.

Особо тупой Quasar, смею заверить твоё величество, что джава там есть. Так что кончай петросяничать!

Тоесть теперь можно будет запустить аж целых 2 программы на телефоне с 512 мб и они не будут тормозить, не будут вытесняться из памяти при сворачивании? И кстати кто покупал телефон с 512 мб озу, у вас реально 512-490 мб доступно?

в реальных приложениях где активно работает gc жаба не может сравниться с си.

это в каких реальных приложениях у вас объекты создаются в диком количестве?

В десктопной JRE 7 сейчас можно включить сборщик мусора G1

будет жрать больше, но STW реже(и по 200 миллисекунд). Ну и нафиг нам такое на десктопе?

В Android будет AOT.

Изя, ты, кстати, не в курсе, там рантаймовые оптимизации то оставят(если они вообще в дальвике были)?

То-то в документации написано, что создавать временные объекты в часто работающих методах (measure/layout, onDraw) крайне не рекомендуется.

что-то не вижу связи. GC явы действительно не собирает все объекты, а твои маложивущие действительно приходится молотить чаще, потому как они и из Eden'а не выползают, и чистятся на каждой минорной сборке.

libdispatch

Поделие. Даже C++11 promise/future pattern выглядит лучше.

ipad как минимум не тормознее андроида

Там нечему тормозить при мощном процессоре. Рекламу резать умеет? Нет. Аддоны в браузер ставятся? Тоже нет. Tor работает? pgp минимально умеет в почте? Нет, нет, нет. Всё, что умеет развлекушно-потреблядский ipad, умел и мой старый se k700i с оперой-мини на борту купленый в переходе.

смотрим на айфон: там нет инструментов для асинхронного программирования

Учись, чтобы дураком не помереть.

Там нечему тормозить при мощном процессоре. Рекламу резать умеет? Нет. Аддоны в браузер ставятся? Тоже нет. Tor работает? pgp минимально умеет в почте? Нет, нет, нет. Всё, что умеет развлекушно-потреблядский ipad, умел и мой старый se k700i с оперой-мини на борту купленый в переходе.

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

чисто по ощущениям ipad как минимум не тормознее андроида

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

хотеть чтобы андроид так тоже делал. и если правда и если не правда.

рекламу не режу, аддоны в браузер не ставлю, тор не юзаю, pgp не юзаю. ipad всё равно как минимум не медленнее.. и батарею раз в 5 меньше жрёт, хотя надо ещё сравнить ёмкости батарей конечно...

будет жрать больше, но STW реже(и по 200 миллисекунд). Ну и нафиг нам такое на десктопе?

G1 даёт управляемые и предсказуемые задержки.

Центральная идея, лежащая в основе G1, называется «желательная пауза» (pause goal). Этот параметр показывает, на какое время программа может прервать работу во время исполнения ради сборки мусора (например, на 20 мс один раз в 5 минут). G1 будет делать все возможное, чтобы работать с заданными желательными паузами. Это коренным образом отличает его от всех сборщиков мусора, с которыми мы сталкивались раньше. Вооружившись G1, разработчик может гораздо полнее контролировать процесс сборки мусора.

G1 не из тех сборщиков мусора, которые работают с учетом поколений (хотя в нем и используется алгоритм отслеживания и очистки). При работе G1 делит кучу на области равного размера (например, по 1 Мбайт), не различая молодых и старых областей. Во время паузы объекты эвакуируются в другую область (подобно тому как объекты из Эдема переходят в область уцелевших), а освобожденная область помещается в список пустых областей.

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

-XX:+UseG1GC Включает сборку G1
-XX:MaxGCPauseMillis=50 Указывает G1, что в ходе отдельно взятой сборки необходимо избегать пауз дольше 50 мс
-XX:GCPauseIntervalMillis=200 Указывает G1, что между сборками мусора должно проходить не менее 200 мс

Переключатели можно комбинировать: например, установить максимальную желательную паузу 50 мс и указать, что паузы должны отстоять друг от друга не менее чем на 200 мс. Разумеется, у системы G1 есть предел скорости. Пауза должна быть достаточно длительной, чтобы G1 успел убрать мусор. Если задать желательную паузу длительностью 1 мс один раз в 100 лет, это будет недостижимое и неграмотное требование.

Из книги: Эванс Б., Вербург М. Java. Новое поколение разработки. — СПб.: Питер, 2014.

Изя

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

не в курсе, там рантаймовые оптимизации то оставят(если они вообще в дальвике были)?

Слышал, что в новом Android 4.4 KitKat машина Dalvik вместо JIT использует ART (Android Runtime) с AOT. Отсюда и низкие требования к объёму оперативной памяти.

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

не обессудь, не в первый раз так тебя называю, претензий не было. Впредь не буду искажать твой ник.

Слышал, что в новом Android 4.4 KitKat машина Dalvik вместо JIT использует ART (Android Runtime) с AOT.

Еще не использует. Только есть возможность.

Но вот вопрос: AOT же позволяет делать runtime оптимизации, оставили ли тов. из гугла их?

Судя по этому сообщению: http://4pda.ru/2013/11/9/123502/ запуск приложений в режиме ART требует примерно на 10-20% больше памяти. Но я думаю, что это издержки технологии из-за неготового состояния.

AOT же позволяет делать runtime оптимизации, оставили ли тов. из гугла их?

Какие могут быть рантайм-оптимизации, если в «шитом» коде статистика во время выполнения не ведётся? JIT может собирать информацию, так как она ему и приложению жизненно необходима, чтобы не забивать кучу временными объектами. А AOT'у для статически типизированных языков это зачем? Там всё ясно, как божий день.

Когда в Java для Android появится возможность использовать инструкцию invokedynamic, вот тогда потребуется оптимизация времени выполнения, и это должно быть сделано в AOT.

Какие могут быть рантайм-оптимизации, если в «шитом» коде статистика во время выполнения не ведётся?

что мешает её вести?

некоторые вендоры впилят свои лаунчеры с сенсом и тачвизом, которые будут жрать овер 2Гб оперативи. Так, что гугл молодец, но конечный пользователь, все равно, в скором будущем, будет вынужден купить тел равный по мощности топовому(и не очень) компу, что бы «андроед» работал быстро.

что мешает её вести?

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

Производительность Nexus 7 снизилась после обновления до Android 4.4
http://4pda.ru/2013/12/01/127183/