Почему нужно отобрать мощные компы у разработчиков

http://morepypy.blogspot.ru/2011/02/pypy-faster-than-c-on-carefully-crafted.html искуственный пример, если совсем плохо с фантазией.

Может и делает — разные вещи. Иногда и автоматическое управление памятью может быть быстрее ручного. Случаев примерно столько же, сколько несоответствий между плюсами и си.

Откомпилируй линуксовое ядро с g++ и расскажи о результатах.

Как это ускорит GC и JIT?

Почему нужно отобрать мощные компы у разработчиков

Общепринятый в индустрии способ «быстрой разработки», когда надо в ограниченные сроки родить feature-rich программу, включает в себя такой момент: программу разрабатывают не вкладывая слишком много усилий в экономию памяти/проца/сети/диска. Затем, если при тестировании выясняется, что какого-то ресурса действительно не хватает, переходят к профилированию и оптимизации, насколько позволяет бюджет проекта. То есть программа тяжеловесна ровно настолько, насколько потенциальные пользователи готовы это стерпеть.

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

Так они щас и переписывают андрюшу на новую vm, чтобы та компилила java в машиные коды еще до выполнения.

Надо было FreeRunner-ы раздать :)

CrossFire> Жрет аккумулятор, это как? Грузит процессор на 100%?

Это уже критерии у яббла.

CrossFire> Выноси тяжелые вещи в отдельный поток, и все будет хорошо.

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

CrossFire> Очень интересно, а что же там есть?

Тебе лень прочитать информацию об архитектуре андроида?

CrossFire> Писал на каждом из них, кроме, собственно шарпа. Си — подмножество обоих языков.

Опять необоснованная чушь. Поддержка кода на C не делает из языка C.

CrossFire> Ява существует без GC?

Так ты про язык или про что?

CrossFire> JIT по определению медленнее, ведь тратит ресурсы процессора прямо во время выполнения программы.

Уходи.

А потом на ЛОРе пишут что «512 Мб - минимально необходимые системные требования для использования компьютера как печатную машинку».

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

Устройства с 512 МБ нужны, чтобы у программистов не было желания впасть в прокрастинацию. А то ты им «где тесты и графики?», а они тебе «завтра приходите!».

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

iOS ничерта не на C. Ничего?

iOS на C, ок?

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

Никто не может заставить программистов резко сменить приоритеты в разработке софта. А вот выдать ущербные устройства — это как два пальца, для гугла по крайней мере.

Никто не может заставить программистов резко сменить приоритеты в разработке софта. А вот выдать ущербные устройства — это как два пальца, для гугла по крайней мере.

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

Ещё один, считающий си, плюсы, ObjC и шарп одним языком.

Уважаемый дилетант,

Спешу сообщить вам, что на ObjC в iOS пишутся только приложения. А узкими местами в производительности являются библиотеки, которые пишутся на чистейшем C. Для приложений это выглядит как API на Objective-C, потому что между Objective-C и C есть мост, который позволяет работать с большинством классов Objective-C как с сишными структурами.

Если гугл их работодатель, то заставить их сменить приоритета ему как два пальца.

Т.е. работадатель может быстро менять приоритеты программиста? Что за бред?

Работодатель управляет рабочим процессом. Он может сказать, что без прогона тестов производительности фичу в репозиторий заливать нельзя (или в багтрекер ей не поставят статус done, т.е. не заплатят за нее).

жаба сравнима с си по производительности. 1 к 10 в типичных задачах. беда только с gc. все тормоза и пожирания памяти оттуда.

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

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

640Кб должно хватить всем

Я щитаю, что 128k достаточно.

JIT может компилировать на ходу ЭФФЕКТИВНЕЕ потому, что у него БОЛЬШЕ ИНФОРМАЦИИ, ЧЕМ В ТЕОРИИ МОЖЕТ БЫТЬ У КОМПИЛЯТОРА. Ты вообще владеешь матчастью?

И какая же у него информация, которой нет у gcc с profile-based optimizations? Выдай на-гора ещё порцию бреда.

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

1. JIT

2. В UI незаметно, сработала функция за 1 мкс или 5 мкс.

Нет там никакой криворукости, там есть лишнее ненужно от производителя жрущее память.

ну вот зачем вы пишете ерунду про «больше информации»?

Не пользуйся высерами говнокодеров

и всеми ее преимуществами для коммерсов

А не пошли ли они в одно место?

Спасибо, уже есть за что зацепиться

1. JIT

JIT сам по себе тратит время и при этом вынужден отказываться от хороших техник оптимизации просто потому что они долгие. При этом компилятор с profile-guided optimization знает о программе в разы больше и не тратит время в рантайме вообще. Кроме того, JIT ничего не может поделать с объектами. В лучшем случае вставит хаки на какие-нибудь известные ему объекты, также как компиляторы C умеют обнаруживать и заменять вызовы memcpy, strcpy и т.д.

2. В UI незаметно, сработала функция за 1 мкс или 5 мкс.

Недавно была новость про pypy, и там разработчики радовались, что паузы сборщика мусора теперь не превышают 5 миллисекунд. А 5 мс это совсем не 5 мкс, при скорости рендеринга в 60 кадров в секунду на рисование одного кадра есть 16,6 мс, и если кто-то в случайные моменты времени будет отжирать несколько миллисекунд на обход графа объектов и проверку их достижимости — лаги будут, причём труднообнаружимые для разработчика.

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

Надеюсь возражений о том, что скорость работы достигается именно из-за компилируемого языка не будет?

Тссс! Вы ещё на лоре скажите, что плохо писать приложения на скриптовых языках, и будет совсем «пичалька».

У яббла очень жёсткая банальная политика относительно разработки - если приложение жрёт аккумулятор, то делай что хочешь, ставь какие хочешь костыли, но чтобы пожиралова не было, иначе приложение не пустят в аппстор. Есть тормоза? Делай что хочешь, но чтобы пользователь их хотя бы не замечал, иначе фиг, а не аппстор

Это не так.

JIT сам по себе тратит время и при этом вынужден отказываться от хороших техник оптимизации просто потому что они долгие. При этом компилятор с profile-guided optimization знает о программе в разы больше и не тратит время в рантайме вообще.

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

Недавно была новость про pypy, и там разработчики радовались, что паузы сборщика мусора теперь не превышают 5 миллисекунд. А 5 мс это совсем не 5 мкс, при скорости рендеринга в 60 кадров в секунду на рисование одного кадра есть 16,6 мс, и если кто-то в случайные моменты времени будет отжирать несколько миллисекунд на обход графа объектов и проверку их достижимости — лаги будут, причём труднообнаружимые для разработчика.

pypy используют на нагруженных серверах, где 5 мс на одного пользователя в контексте 9000 юзеров в секунду важны. А мы говорим об андроид-приложениях, где всякие фейсбуки и твиттеры. И да, gc джавы быстрее, потому что подход другой. Ему не нужно работать при каждом _удалении_ объекта.

В UI незаметно, сработала функция за 1 мкс или 5 мкс.

Если открыть софт на яве — заметно. Проблема в том, что сборка длится больше чем 5 мкс, может и на порядок. Кроме ведроида можно привести в пример эклипс, который очевидно тормозит(даже просто открытие меню), причем на любом процессоре.

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

Ты не знаешь что такое profile-guided optimization. А я ведь написал этот ключевик.

И да, gc джавы быстрее, потому что подход другой

Докажи.

Ему не нужно работать при каждом _удалении_ объекта.

Я уже написал, почему в джаве создаются тучи объектов и как этого избегают в Objective-C. Так что этот аргумент мимо: с таким количеством объетов, как в java-приложениях, gc в любом случае захлебнётся.

И да, gc джавы быстрее, потому что подход другой. Ему не нужно работать при каждом _удалении_ объекта

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

Интересно, zram кто-нибудь под андроиды собирает? ;-)

И какая же у него информация, которой нет у gcc с profile-based optimizations?

Эмм. В PGO будем предсказывать каждый запуск?

С динамическими библиотеками что делать собираешься?

512 Мбайт оперативной памяти.

На смартфоне, ага.

Раньше, блин, некислый такой софт для пека работал на 64х МБайтах, а тут на смартфоне... Куда катится этот гребаный мир?

Эмм. В PGO будем предсказывать каждый запуск?

А зачем? В конкретном вызове функции ветвление может пройти вовсе не по наиболее вероятной ветке. Для наилучшей оптимизации надо найти наиболее вероятную ветвь исполнения, а не ту, которая была вызвана только что. И в этом плане JIT опять же ущербен в сравнении с компилятором, даже если компилятор без PGO.

С динамическими библиотеками что делать собираешься?

Уже оптимизированы тем же методом.

P.S. Может быть кто-то и не в курсе, но в PGO принято прогонять программы по наиболее вероятным или по стрессовым данным. JITу такое недоступно в принципе.

А гелекси нексус с 1 гб памяти обновлять не стали.

Скажите спасибо Ti.

А еще Nexux7 (2012) получил обновление без ART, поскольку последний глючит на говнопроцессоре от Nvidia.

Просто надо было писать на Си — айОсь вон не тормозит, хотя по железу там примерно то же, что дали разрабам.

Лагает это говно на iphone4. Причем откатиться на ios < 7 уже нельзя.

Пишу с нового айпад мини, ничего не тормозит.

Пишу со старого htc desire - ничего не тормозит.

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

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

Объясни мне, как JIT может быть быстрее УЖЕ СКОМПИЛИРОВАННОЙ ПРОГРАММЫ?

Оптимизация под хост.

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

Уже оптимизированы тем же методом.

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

Иногда автоматическое управление памятью быстрее ручного.

Ключевое слово «иногда».

И да, malloc() тоже не отрабатывает за константное время.

Зато это выделение произойдет тогда, когда это нужно разработчику/приложению.

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

У эпола актуальным считается только самый свежий девайс.

Сегодня: - ура, у меня новый iphone4
Завтра: - у меня iphone4s, а у тебя галимое тормозное говно.

А о чем спор, JIT может ее заинлайнить что ли?