Авторы проекта "Архитектура открытых приложений (http://aosabook.org/)" опубликовали (http://aosabook.org/blog/2013/10/the-performance-of-open-sou.../) новую книгу - "The Performance of Open Source Application (http://aosabook.org/en/index.html)", которая посвящена исключительно вопросам оптимизации и достижения высокой производительности в открытых проектах. В книге рассказано о способах достижения высокой производительности в таких проектах, как Chromium, Firefox, EtherCalc, Ninja, pugixml, Infinispan, Talos, Zotonic, Warp, Khmer. Отдельная глава (http://aosabook.org/en/posa/secrets-of-mobile-network-perfor...) посвящена оптимизации мобильных приложений. Текст книги распространяется в рамках лицензии Creative Commons Attribution 3.0 Unported.
URL: http://aosabook.org/blog/2013/10/the-performance-of-open-sou.../
Новость: http://www.opennet.me/opennews/art.shtml?num=38106
>В книге рассказано о способах достижения высокой производительностиПонятнее кто-нибудь может объяснить?
>>В книге рассказано о способах достижения высокой производительности
> Понятнее кто-нибудь может объяснить?Чтобы файрфокс запускался через 4 секунды, а не через 6, надо отключить Adblock Plus.
А у меня мгновенно стартует. Conkeror
какой хитрый рекламщик пошел
нет, я не попадусь на твои уловки
Какое слово тебе непонятно?
Хехе, это любимая фраза моего препода по метрологии.
Какой производительности? "Тюнинг" настроечек в /etc/?
Эх ты, анонимус... Там говорится о том как программировать правильно, чтобы твоё приложение не просто работало, а быстро работало.
Пишите на С, даже с багами, криво и убого, с гигабайтными массивами,...,
всё равно быстрее всех работать будет. (на асме можно немного подрочить).
> (на асме можно немного подрочить))
приходилось перетаскивать в своё время программки с фортрана на си. интересно, конечно, наблюдать было обработку многомерных массивов на сишный манер: внешний цикл - столбцы, внутренний - построчно. для сей - самое то, но для фортрана... жесть. чудовищные потери. так что на любом языке нужно знать, как данные в памяти располагаться будуть ;) асм уже дело такое, в хроническом запущении - как мёртвому примочки. ;)
Переписывание на асм - последний этап оптимизации. Если выбран неоптимальный алгоритм, неоптимальная структура хранения данных и ещё десяток "неоптимально", то никакой язык программирования, даже ассемблер, не поможет достичь оптимальной производительности.
> Переписывание на асм - последний этап оптимизации. Если выбран неоптимальный алгоритм,
> неоптимальная структура хранения данных и ещё десяток "неоптимально", то никакой язык
> программирования, даже ассемблер, не поможет достичь оптимальной производительности.А вот прикинь, написали враппер для кодека,... корявый, грузит по 10 сек. части VOB файлов,
open/lseek/malloc/realloc/..., память течёт... Зато кодек на aсме, декодирует данные за 30 сек.,...
В итоге имеем 3 минуты на кодирование DVD из них 1 минуту на работу с файлами.
> Зато кодек на aсме, декодируетАга, а декодер кодирует :-)
Никакой ASM не спасает от кривой постановки задачи. Если с человеческим языком проблемы, то они наследуются и усугубляются на этапах планирования и реализации ПО.
А костыли можно изготавливать на чём угодно: хоть на ASM, хоть на VBA.
>> Зато кодек на aсме, декодирует
> Ага, а декодер кодирует :-)А прикинь переводчики - переводят, а не депереводят, разпереводят и перепереводят.
А прикинь, в английском "look TV" и "watch TV" означают разное, хотя на русский дословно переводятся одинаково.[сообщение отредактировано модератором]
спасибо, кэп!
> внешний цикл - столбцы, внутренний - построчно. для сей - самое то,
> но для фортрана... жесть.Как это реализовано в Фортране? (без сторонних библиотек)
Например приведение матрицы к верхней треугольной, самым баянистым алгоритмом Гаусса?
---Мож меня проглючило, но по моему в C11 появилась фича умножение массива на число.
В GCC есть __attribute__ ((vector_size (N)));
там даже речь не шла о каких-то математических обработках матриц, не мультипликация матриц и пр. это один сюрприз был. ну да хрен с ними, алгоритмы были уж сильно специфичными.
второе - в фортране данные массива сохнаряются в памяти совсем иначе: не построчно, как в сях и пр., а постолбично. то есть, представлешь, какие тормоза будут, если в сях два матричных цикла поменять местами ;) сплошные кэш-промахи в мегабайтных массивах данных.
> второе - в фортране данные массива сохнаряются в памяти совсем иначе: не
> построчно, как в сях и пр., а постолбично.транспонирование и вперед.
вот знали бы про сие те писатели фортрановских программ...
> Понятнее кто-нибудь может объяснить?Скачай, прочти ;)
Я им лучше покажу - http://www.ozon.ru/context/detail/id/1335648/
Где здесь Nginx ?
Про nginx в прошлом томе было: http://aosabook.org/en/nginx.html
> Где здесь Nginx ?Его заоптимизировали на столько, что не помнят где.
Уж у Хромиума-то высокая производительность, аж кусты трещат.
В системе с 4ГБ запросто 1-1.5ГБ отжирает на несчастные 10 вкладок, в итоге полные тормоза, т.к. остальные проги вынуждены в файл подкачки нырять...
> Уж у Хромиума-то высокая производительность, аж кусты трещат.
> В системе с 4ГБ запросто 1-1.5ГБ отжирает на несчастные 10 вкладок, в
> итоге полные тормоза, т.к. остальные проги вынуждены в файл подкачки нырять...какая максимально возможная величина памяти на плате? зачем ставить меньше памяти чем позволяет железо? ставьте больше памяти и используйте все возможности по расширению аппаратных средств. сейчас это не так дорого.
Материнке 4 года, больше 4ГБ чипсет не умеет. Теперь для того, чтобы в Инете полазить нужен так называемый "игровой комп"?! Ну и ну. И эти люди пишут книжки про мегаоптимизацию своего софта?!
> Материнке 4 года, больше 4ГБ чипсет не умеет. Теперь для того, чтобы
> в Инете полазить нужен так называемый "игровой комп"?! Ну и ну.
> И эти люди пишут книжки про мегаоптимизацию своего софта?!у меня на 4-х летнем компьютере можно одновременно запустить 3 HD видео, и при этом интернетом пользоваться. процессор 4500 2 ядра, видео 9600 с 1 Гб, 2 Гб озу. такие дела.
Вот именно, mplayer обрабатывая такие объемы информации ест по 20-30 мебагайт ОЗУ на приложение. А Хром с 15 закладками (без флэша и js) жрёт 1-2 гига. Т.е. если какие-то другие программы имеют наглость хотеть РАМу больше чем десяток мегабайт, Хром начинает с ними драться за своп. Невыносимо оптимизированная программка :)
Был свидетелем при мажорном обновлении софта, этот самый софт стал есть память как не в себя - потребление с 3-4 гигов выросло на 6-7. Но зато операции стали выполнятся (время обсчёта) примерно на 30% быстрей. И это неплохо, учитывая что специфика работы с этим софтом такова, что зарядил параметры на вход - ушёл считать на 3-4 минуты. А вот сколько потребуется итераций с изменением входным параметров и повторного пересчёта - уж как повезёт (в среднем 5-6 раз). Уж пускай стоит лишняя планка памяти, чем потеря моего времени (и нервов). А с хромом давно известная история - порождает много процессов, и blink хоть и самый быстрый, но опять-таки самый жручий.
дуплицируют матрицы, одну из них переворачивают, обе обрабатывают построчно. вуаля!
Для LibreOffice:
1. включить его предварительную загрузку
2. в /etc/libreoffice/sofficerc Logo=0