The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Опубликована свободная книга про производительность открытых приложений

08.10.2013 19:46

Авторы проекта "Архитектура открытых приложений" опубликовали новую книгу - "The Performance of Open Source Application", которая посвящена исключительно вопросам оптимизации и достижения высокой производительности в открытых проектах. В книге рассказано о способах достижения высокой производительности в таких проектах, как Chromium, Firefox, EtherCalc, Ninja, pugixml, Infinispan, Talos, Zotonic, Warp, Khmer. Отдельная глава посвящена оптимизации мобильных приложений. Текст книги распространяется в рамках лицензии Creative Commons Attribution 3.0 Unported.

  1. Главная ссылка к новости (http://aosabook.org/blog/2013/...)
Лицензия: CC-BY
Тип: английский / Обобщение
Ключевые слова: performance, optimization
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (34) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 20:07, 08/10/2013 [ответить] [показать ветку] [····]    [к модератору]
  • –2 +/
    >В книге рассказано о способах достижения высокой производительности

    Понятнее кто-нибудь может объяснить?

     
     
  • 2.2, анон (?), 20:12, 08/10/2013 [^] [ответить]    [к модератору]
  • +3 +/
    >>В книге рассказано о способах достижения высокой производительности
    > Понятнее кто-нибудь может объяснить?

    Чтобы файрфокс запускался через 4 секунды, а не через 6, надо отключить Adblock Plus.

     
     
  • 3.20, Аноним (-), 11:26, 09/10/2013 [^] [ответить]    [к модератору]
  • +/
    А у меня мгновенно стартует. Conkeror
     
  • 3.24, Анончик (?), 13:22, 09/10/2013 [^] [ответить]    [к модератору]
  • +4 +/
    какой хитрый рекламщик пошел
    нет, я не попадусь на твои уловки
     
  • 2.4, Аноним (-), 21:12, 08/10/2013 [^] [ответить]    [к модератору]
  • +3 +/
    Какое слово тебе непонятно?
     
     
  • 3.5, Gsh (?), 21:23, 08/10/2013 [^] [ответить]    [к модератору]  
  • +1 +/
    Хехе, это любимая фраза моего препода по метрологии.
     
  • 3.6, Аноним (-), 21:58, 08/10/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    Какой производительности? "Тюнинг" настроечек в /etc/?
     
     
  • 4.8, Константавр (ok), 22:14, 08/10/2013 [^] [ответить]    [к модератору]  
  • +/
    Эх ты, анонимус... Там говорится о том как программировать правильно, чтобы твоё приложение не просто работало, а быстро работало.
     
     
  • 5.11, pavlinux (ok), 23:19, 08/10/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    Пишите на С, даже с багами, криво и убого, с гигабайтными массивами,...,
    всё равно быстрее всех работать будет. (на асме можно немного подрочить).
     
     
  • 6.13, Ведро (ok), 00:16, 09/10/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    > (на асме можно немного подрочить)

    )


     
  • 6.14, Карбофос (ok), 00:37, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    приходилось перетаскивать в своё время программки с фортрана на си. интересно, конечно, наблюдать было обработку многомерных массивов на сишный манер: внешний цикл - столбцы, внутренний - построчно. для сей - самое то, но для фортрана... жесть. чудовищные потери. так что на любом языке нужно знать, как данные в памяти располагаться будуть ;) асм уже дело такое, в хроническом запущении - как мёртвому примочки. ;)
     
     
  • 7.15, клоун Стаканчик (?), 03:50, 09/10/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    Переписывание на асм - последний этап оптимизации. Если выбран неоптимальный алгоритм, неоптимальная структура хранения данных и ещё десяток "неоптимально", то никакой язык программирования, даже ассемблер, не поможет достичь оптимальной производительности.
     
     
  • 8.27, pavlinux (ok), 14:38, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    > Переписывание на асм - последний этап оптимизации. Если выбран неоптимальный алгоритм,
    > неоптимальная структура хранения данных и ещё десяток "неоптимально", то никакой язык
    > программирования, даже ассемблер, не поможет достичь оптимальной производительности.

    А вот прикинь, написали враппер для кодека,... корявый, грузит по 10 сек. части VOB файлов,
    open/lseek/malloc/realloc/..., память течёт... Зато кодек на aсме, декодирует данные за 30 сек.,...
    В итоге имеем 3 минуты на кодирование DVD из них 1 минуту на работу с файлами.    

     
     
  • 9.28, serg1224 (ok), 20:31, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    > Зато кодек на aсме, декодирует

    Ага, а декодер кодирует :-)

    Никакой ASM не спасает от кривой постановки задачи. Если с человеческим языком проблемы, то они наследуются и усугубляются на этапах планирования и реализации ПО.

    А костыли можно изготавливать на чём угодно: хоть на ASM, хоть на VBA.

     
     
  • 10.32, pavlinux (ok), 00:27, 10/10/2013 [^] [ответить]    [к модератору]  
  • +/
    >> Зато кодек на aсме, декодирует
    > Ага, а декодер кодирует :-)

    А прикинь переводчики - переводят, а не депереводят, разпереводят и перепереводят.

     
     
  • 11.35, клоун Стаканчик (?), 05:29, 10/10/2013 [^] [ответить]    [к модератору]  
  • +/
    А прикинь, в английском "look TV" и "watch TV" означают разное, хотя на русский дословно переводятся одинаково.

    [сообщение отредактировано модератором]

     
  • 8.31, Карбофос (ok), 00:03, 10/10/2013 [^] [ответить]    [к модератору]  
  • +/
    спасибо, кэп!
     
  • 7.26, pavlinux (ok), 14:32, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    > внешний цикл - столбцы, внутренний - построчно. для сей - самое то,
    > но для фортрана... жесть.

    Как это реализовано в Фортране? (без сторонних библиотек)
    Например приведение матрицы к верхней треугольной, самым баянистым алгоритмом Гаусса?
    ---

    Мож меня проглючило, но по моему в C11 появилась фича умножение массива на число.
    В GCC есть __attribute__ ((vector_size (N)));

     
     
  • 8.29, Карбофос (ok), 22:36, 09/10/2013 [^] [ответить]    [к модератору]  
  • +1 +/
    там даже речь не шла о каких-то математических обработках матриц, не мультипликация матриц и пр. это один сюрприз был. ну да хрен с ними, алгоритмы были уж сильно специфичными.
    второе - в фортране данные массива сохнаряются в памяти совсем иначе: не построчно, как в сях и пр., а постолбично. то есть, представлешь, какие тормоза будут, если в сях два матричных цикла поменять местами ;) сплошные кэш-промахи в мегабайтных массивах данных.
     
     
  • 9.33, pavlinux (ok), 00:29, 10/10/2013 [^] [ответить]    [к модератору]  
  • +/
    > второе - в фортране данные массива сохнаряются в памяти совсем иначе: не
    > построчно, как в сях и пр., а постолбично.

    транспонирование и вперед.

     
     
  • 10.34, Карбофос (ok), 00:53, 10/10/2013 [^] [ответить]    [к модератору]  
  • +/
    вот знали бы про сие те писатели фортрановских программ...
     
  • 2.9, YetAnotherOnanym (ok), 22:20, 08/10/2013 [^] [ответить]    [к модератору]  
  • +2 +/
    > Понятнее кто-нибудь может объяснить?

    Скачай, прочти ;)

     
  • 1.3, 123 (??), 20:54, 08/10/2013 [ответить] [показать ветку] [····]    [к модератору]  
  • +/
    Я им лучше покажу - http://www.ozon.ru/context/detail/id/1335648/
     
  • 1.7, Inome (ok), 22:02, 08/10/2013 [ответить] [показать ветку] [····]    [к модератору]  
  • +/
    Где здесь Nginx ?
     
     
  • 2.10, Аноним (-), 22:21, 08/10/2013 [^] [ответить]    [к модератору]  
  • +/
    Про nginx в прошлом томе было: http://aosabook.org/en/nginx.html
     
  • 2.12, pavlinux (ok), 23:20, 08/10/2013 [^] [ответить]    [к модератору]  
  • +2 +/
    > Где здесь Nginx ?

    Его заоптимизировали на столько, что не помнят где.

     
  • 1.16, медведдд (ok), 05:22, 09/10/2013 [ответить] [показать ветку] [····]    [к модератору]  
  • +1 +/
    Уж у Хромиума-то высокая производительность, аж кусты трещат.
    В системе с 4ГБ запросто 1-1.5ГБ отжирает на несчастные 10 вкладок, в итоге полные тормоза, т.к. остальные проги вынуждены в файл подкачки нырять...
     
     
  • 2.18, сергей (??), 10:15, 09/10/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    > Уж у Хромиума-то высокая производительность, аж кусты трещат.
    > В системе с 4ГБ запросто 1-1.5ГБ отжирает на несчастные 10 вкладок, в
    > итоге полные тормоза, т.к. остальные проги вынуждены в файл подкачки нырять...

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

     
     
  • 3.19, медведдд (ok), 10:20, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    Материнке 4 года, больше 4ГБ чипсет не умеет. Теперь для того, чтобы в Инете полазить нужен так называемый "игровой комп"?! Ну и ну. И эти люди пишут книжки про мегаоптимизацию своего софта?!
     
     
  • 4.21, сергей (??), 11:53, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    > Материнке 4 года, больше 4ГБ чипсет не умеет. Теперь для того, чтобы
    > в Инете полазить нужен так называемый "игровой комп"?! Ну и ну.
    > И эти люди пишут книжки про мегаоптимизацию своего софта?!

    у меня на 4-х летнем компьютере можно одновременно запустить 3 HD видео, и при этом интернетом пользоваться. процессор 4500 2 ядра, видео 9600 с 1 Гб, 2 Гб озу. такие дела.

     
     
  • 5.22, медведдд (ok), 12:04, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    Вот именно, mplayer обрабатывая такие объемы информации ест по 20-30 мебагайт ОЗУ на приложение. А Хром с 15 закладками (без флэша и js) жрёт 1-2 гига. Т.е. если какие-то другие программы имеют наглость хотеть РАМу больше чем десяток мегабайт, Хром начинает с ними драться за своп. Невыносимо оптимизированная программка :)
     
     
  • 6.23, Аноним (-), 12:43, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    Был свидетелем при мажорном обновлении софта, этот самый софт стал есть память как не в себя - потребление с 3-4 гигов выросло на 6-7. Но зато операции стали выполнятся (время обсчёта) примерно на 30% быстрей. И это неплохо, учитывая что специфика работы с этим софтом такова, что зарядил параметры на вход - ушёл считать на 3-4 минуты. А вот сколько потребуется итераций с изменением входным параметров и повторного пересчёта - уж как повезёт (в среднем 5-6 раз). Уж пускай стоит лишняя планка памяти, чем потеря моего времени (и нервов). А с хромом давно известная история - порождает много процессов, и blink хоть и самый быстрый, но опять-таки самый жручий.
     
     
  • 7.30, Карбофос (ok), 23:38, 09/10/2013 [^] [ответить]    [к модератору]  
  • +/
    дуплицируют матрицы, одну из них переворачивают, обе обрабатывают построчно. вуаля!
     
  • 1.17, Омский линуксоид (ok), 06:35, 09/10/2013 [ответить] [показать ветку] [····]    [к модератору]  
  • +/
    Для LibreOffice:
    1. включить его предварительную загрузку
    2. в /etc/libreoffice/sofficerc Logo=0
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor