LINUX.ORG.RU
ФорумTalks

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

 , ,


1

4

В октябре во время анонса Android 4.4 KitKat поисковый гигант Google заявил, что платформа оптимизирована для плавной работы на устройствах с 512 Мбайт оперативной памяти. Этот шаг Google нельзя не приветствовать — он не только позволяет надеяться на снижение фрагментации устройств, но также окажет большую пользу в деле продвижения носимых устройств вроде часов или очков.

Всем инженерам, работавшим над проектом, были розданы смартфоны Nexus 4, модифицированные с тем, чтобы использовать только 512 Мбайт оперативной памяти — весьма оригинальный способ простимулировать разработчиков ускорить работу операционной системы. Но на этом дело не ограничилось.

http://www.3dnews.ru/782764

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

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

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

И да, man pypy хотя бы.

Ну, и не будем забывать про GC

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

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

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

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

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

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

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

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

ckotinko ☆☆☆
()
Ответ на: комментарий от quiet_readonly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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