Комментарии 70
Огромное спасибо за интересную статью!
Для меня сейчас, вы — самый интересный автор на хабре )
Для меня сейчас, вы — самый интересный автор на хабре )
а где бы про это можно подробней почитать??
желательно с простыми примерами и с самого начала…
пишу ресурсоемкие приложения на c++ (имидж процессинг), знаю что можно ускорить, но не знаю как ö(
желательно с простыми примерами и с самого начала…
пишу ресурсоемкие приложения на c++ (имидж процессинг), знаю что можно ускорить, но не знаю как ö(
Линк из предыдущего коммента очень хороший, начинать читать надо там ( lwn.net/Articles/250967/ )
Если Image Processing — еще обязательно мануалы по SSE.
Классические от Интела (http://www.intel.com/products/processor/manuals/), документацию из MSDN, и пару любых туториалов из гугла.
Ну там, вот
Если Image Processing — еще обязательно мануалы по SSE.
Классические от Интела (http://www.intel.com/products/processor/manuals/), документацию из MSDN, и пару любых туториалов из гугла.
Ну там, вот
Использовать IPP, там уже все ускорено за вас.
Очень познавательно. Я еще в университете забросил C++ из-за постоянной борьбы с компиляторами и проблемами выполнения кода на разных компьютерах. Ваша статья, отчасти, помогла понять чать проблем и то, почему многие программисты ругают современный подход Intel к проектированию процессоров.
Впечатлило. Так вот оказывается почему консоли могут выдавать прекрасную графику на сравнительно средней аппаратной начинке.
А вот вопрос к специалисту — а как с этим обстоят дела на больших компьютерах? Ну всяких спарках сановских, креях и прочих мегадолларовых устройствах?
А я не специалист ни разу по серверному железу. В Спарках вроде бы тот же DDR, так что проблемы все на месте. На сервере попроще, реалтайм-перформанс не так критичен.
За Креи совсем не знаю.
За Креи совсем не знаю.
реалтайм-перфомансе важен в oltp, так-что там все тоже самое, только помноженное на промышленную эксплуатацию. :(
Я скорее в том смысле, что мне казалось, там важен bandwidth — сколько удается обработать запросов в секунду, а не latency — сколько занимает один запрос. В таком случае, проблемы в крайнем случае можно решать деньгами — увеличивать количество серверов и т.д., временем программиста, соответственно, только если оно оказывается дешевле серверов. Чем дальше ужимаешь — тем больше нужно усилий, в пределе — design for performance, войны за такты и прочее.
В реалтайме же такого размена вообще нет — критично время работы одной задачи на одной машине прямо здесь и сейчас. Становится веселее.
Впрочем, это я патриот низкоуровнего перформанса.
Оффтоп: интересно, как бы железную загрузку процессора показательно померять, чтобы сравнить…
В реалтайме же такого размена вообще нет — критично время работы одной задачи на одной машине прямо здесь и сейчас. Становится веселее.
Впрочем, это я патриот низкоуровнего перформанса.
Оффтоп: интересно, как бы железную загрузку процессора показательно померять, чтобы сравнить…
Чуствую себя лохом :(
Засиделся в пхп, пожалуй надо опуститься на low-level, хотя бы ненадолго.
Засиделся в пхп, пожалуй надо опуститься на low-level, хотя бы ненадолго.
Random Memory Access: ~200 cycles — это хорошо или плохо? А сколько у вас цикл? Чтобы не было таких глупых вопросов Latency измеряется не в циклах чего-то там, а в секундах — наносекундах. Поэтому у автора и такие бредовые результаты с ухудшением латентности в 150 раз по сравнению с 1980.
Только всё равно процессор простаивает 200 циклов, а мог бы делать полезную работу. Конечно, иногда out of order исполнение спасает, но не так часто, как хотелось бы.
Кто вам сказал что он простаивает эти 200 тактов? 200 таковый LLC miss+DTLB miss — это надо постараться так писать программы, чтобы у вас при каждом обращении в память такие простои были. А если промах один-два, то эти промахи скрадываются Out-Of-Order выполнением других инструкций.
С трудом себе представляю внеочередное выполнение сотни независимых, например, двухтактовых комманд. Если повезёт, выполнится две-три командны, остальные 190 тактов процессор будет крутится вхолостую.
Что же до промахов, любой список указателей на данные в куче потенциальный источник таких катаклизмов с высокой вероятностью.
Что же до промахов, любой список указателей на данные в куче потенциальный источник таких катаклизмов с высокой вероятностью.
точнее говоря, тут не только в программе дело
компилятор (статический оптимизатор) + железо (динамический out-of-order) делают свои дела. Причем на ILP (instruction level parallelism), то бишь железо, приходится основная доля распараллеливания в самом (самих) пайплаине (пайплаинах).
Кроме того не стоит забывать о MOB, L2 и victim cache.
компилятор (статический оптимизатор) + железо (динамический out-of-order) делают свои дела. Причем на ILP (instruction level parallelism), то бишь железо, приходится основная доля распараллеливания в самом (самих) пайплаине (пайплаинах).
Кроме того не стоит забывать о MOB, L2 и victim cache.
НЛО прилетело и опубликовало эту надпись здесь
FFT кстати отлично переписывается на регулярные доступы. Матричное умножение отдельными локальными блоками порядка размера кеша.
Вот тут показательный пример — lwn.net/Articles/255364/
Вот тут показательный пример — lwn.net/Articles/255364/
Два кеш-мисса — это значит out of order должен предоставить инструкций на 400 тактов, то есть сотни. Это очень немало, их вполне может не найтись.
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
Вычислительная операция как была такт, так и осталась тактом (с учетом SIMD-операций и multicore, еще меньше). В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
Вычислительная операция — это абстрактное понятие. SSE делает 2 дабловых умножения за такт. 1 дабловое умножение при этом занимает 0.5 такта. Сингловое умножение, соответственно 0.25 тактов. А сейчас в Блумфилдах будет плавающий множитель и режим турбо, и такт у вас будет такой, чтобы влезать в TDP.
>>В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
Это как раз не меняет. Как раньше хреново было, так и сейчас. Ничего нового. А вот ООО, кэш, префетч, предсказание переходов — это да, это — меняет.
>>В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
Это как раз не меняет. Как раньше хреново было, так и сейчас. Ничего нового. А вот ООО, кэш, префетч, предсказание переходов — это да, это — меняет.
Дык нет же. Раньше было совсем не так, вычисления были сравнимы с доступом в память. Ну комон, если раньше люди для того чтобы программа работала быстрее чаще пытались делать на сложение меньше, то теперь надо смотреть и думать о локальности памяти. Когда скорость доступа к памяти сравнима с обычной инструкций — вообще проблемы локальности не стоит.
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».
«Поставить поставить два процессора» — исправьте пожалуйста.
Отличная статья.
По поводу latency vs bandwidth говорят: «Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed – you can’t bribe God.»
По поводу latency vs bandwidth говорят: «Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed – you can’t bribe God.»
Практический вопрос: для скриптовых языков типа php или perl, c огромным расходом памяти, лучше использовать два медленных процессора вместо одного быстрого, получается? Есть ли конкретные рекомендации на эту тему — например, несколько бакэндов + фронтэнд vs один бакэнд+фронтэнд? И какое влияние многоядерности на доступ к памяти — будут ли двухядерные процессоры в сумме иметь меньшие потери производительности из-за латентности, чем одноядерный большей частоты в два раза?
Многоядерность она разная бывает. В исполнении с общей FSB многоядерность ухудшает доступ к памяти, поскольку вводятся дополнительные затраты на синхронизацию кэшей (снупинг). В исполнении NUMA все хорошо, когда каждое ядро вделяет память симметрично. Но как только одно ядро залезло в память другого — все, опять тормозим.
Я честно скажу — не занимался профилированием скриптов, но на первый взгляд — высокая частота+оч большой кэш — вот что для них нужно. А какие-то вычислительные задачи лучше писать на С-подобных языках с жесткой оптимизацией под платформу — компилятором и/или руками.
Я честно скажу — не занимался профилированием скриптов, но на первый взгляд — высокая частота+оч большой кэш — вот что для них нужно. А какие-то вычислительные задачи лучше писать на С-подобных языках с жесткой оптимизацией под платформу — компилятором и/или руками.
Извините, но Александреску… Как-то странно видеть написание его фамилии через «О».
А статья правда интересная! Спасибо!
А статья правда интересная! Спасибо!
Можно ли считать процессоры без MMU/TLB более простыми, но и прогрессивными в архитектурном плане? (типа ARM'ов, как в сотовых телефонах и микроконтроллёрах)
Будущее за простотой! Долой многоуровневую эмуляцию?
Будущее за простотой! Долой многоуровневую эмуляцию?
с 64-битовой адресацией без MMU можно без проблем жить, наверное. Но ведь виртуальная память — это не только эмуляция, но и изоляция.
Хотя было бы здорово иметь одну абстракцию на дисковую память и физическую :) Соответственно, и механизмы защиты позаимствовать.
Хотя было бы здорово иметь одну абстракцию на дисковую память и физическую :) Соответственно, и механизмы защиты позаимствовать.
Все, как всегда, сложно. Процессорам на открытах платформах с обратной совместимостью — боюсь, придется играть в эти игры. Потому что а) людям не хочется шибко много думать, когда они пишут код и б) есть очень много уже написанного кода, который хочется запускать быстрее.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
Вот, наконец-то поднимают эту тему! Сегодня проблемой десктопных приложений еще и становится то, что лентяи-программисты используют либо языки вроде явы/дотнета, либо библиотеки вроде Qt, которые, кроме всего прочего, отличаются непомерным большим потреблением памяти, в результате чего (я подозреваю) происходит намоного больше обращений к RAM так как эти монстры просто физически не могут поместиться в кеш.
Кроме, того в ООП-библиотеках использутся многократное наследование, на каждом этапе в класс добавляются новые поля, в результате чего экземпляр класса занимает достаточно много места в памяти, и если многие поля не используются, то они все равно вытягиваются в кеш и отнимают там местло, так как все хранятся рядом.
Кроме, того в ООП-библиотеках использутся многократное наследование, на каждом этапе в класс добавляются новые поля, в результате чего экземпляр класса занимает достаточно много места в памяти, и если многие поля не используются, то они все равно вытягиваются в кеш и отнимают там местло, так как все хранятся рядом.
НЛО прилетело и опубликовало эту надпись здесь
Java и NET (пока что) место на сервере, а не на десктопе.
Множество программ, начаная с классических winRAR/winAMP/foobar2000 и так далее написаны без всего этого и замечательно работали/работают.
А тенденция использовать упомянутые технологии меня, как пользователя, не радует (а линусоидам еще хуже, там вообще пытаются к скриптовым языкам прикручивать Gtk, надеюсь вы и сами понимаете, какой ужас в результате полуается).
Множество программ, начаная с классических winRAR/winAMP/foobar2000 и так далее написаны без всего этого и замечательно работали/работают.
А тенденция использовать упомянутые технологии меня, как пользователя, не радует (а линусоидам еще хуже, там вообще пытаются к скриптовым языкам прикручивать Gtk, надеюсь вы и сами понимаете, какой ужас в результате полуается).
Лентяи говоришь?
А головой подумать?
Вы же, наверное, не лентяйничаете и не ездите в транспорте, а идёте пешком?
Всегда есть 2 стороны медали.
Скорость и минимальность нужна не везде и не всегда. Да, к тому же, за неё приходится платить.
А головой подумать?
Вы же, наверное, не лентяйничаете и не ездите в транспорте, а идёте пешком?
Всегда есть 2 стороны медали.
Скорость и минимальность нужна не везде и не всегда. Да, к тому же, за неё приходится платить.
Ну хорошо, лентяи, я немного перегнул, тут скорее рыночные обстоятельства, то есть разработчику/программистам нужно реализовать выполнение программой каких-то задач к какому-то сроку, а уж насколько качественно это будет сделано — дело десятое, наверно писать исключительно хорошие программы невыгодно, где-то я читал… не помню, может у Споэльски.
НЛО прилетело и опубликовало эту надпись здесь
Боюсь, вы неправильно меня поняли. Я говорю о производительности языков для десктопных приложений, а не серверных. Согласен, на сервере можно хоть на Руби писать, так как всегда можно обеспечить нужную производительность покупкой хорошего железа, настройкой ОС, кешированием, масштабированием и прочим.
Пользователю важно, чтобы у него все работало быстро, и никто не будет против, если вы напишете скрипт, делающий хоть 1000 запросов к бд, если сможете обеспечить производительность.
Но десктопные приложения — другая область, здесь перед разработчиком другой уровень требований, и писать надо программы, эффективно использующие ресурсы компьютера (а не вести себя так, как будто пользователь будет запускать только вашу программу и больше ничего параллельно). Перечисленные мной технологии этим требованиям отвечают плохо.
Другой вопрос, что с экономической точки зрения это не очень выгодно, выгоднее делать как придется. Но это извечный вопрос — сделать кое-как или качественно.
А в веб-технологии соотверственно внимание стоит уделять производительности client-side технологий, например js (многие приложения Гугла, например, на мой взгляд в этом плане сделаны так себе, авторы увлеклись созданием сложных интерфейсов на языке, который для этого не очень подходит).
Что касается вопроса про язык для десктопа — очевидно, нужно что-то вроде С++, только было бы замечательно, если б его кто-то подпилил, решив проблемы, начиная с классической проблемы исключений в конструкторе, и придумав нативные и производительные масивы и строки. Ну и мне. как человеку ленивому хотелось бы писать поменьше, то есть сделать автогенерацию заголовочных файлов, убрать необходимость описывать всякие структуры (автогенерация описания структуры, почему бы нет) и типы данных там, где они очевидны. ах, да, и include_once сделайте пожалуйста (или вообще уберите нафик заголовочные файлы) (не понимаю. почему никто до этого не додумался).
Ну и касательно библиотек (Gtk, Qt), они действительно неэффективны, соравните производительность наитивных Win приложений вроде notepad с такими же, написанными на этих библиотеках. Как говорится, разница видна невооруженным глазом. Ну и то, что имитировать ООП на Си — явное извращение, не стоит забывать (я читал про причины, побудившие это сделать, тем не менее это слабое и неэффективное решение).
Пользователю важно, чтобы у него все работало быстро, и никто не будет против, если вы напишете скрипт, делающий хоть 1000 запросов к бд, если сможете обеспечить производительность.
Но десктопные приложения — другая область, здесь перед разработчиком другой уровень требований, и писать надо программы, эффективно использующие ресурсы компьютера (а не вести себя так, как будто пользователь будет запускать только вашу программу и больше ничего параллельно). Перечисленные мной технологии этим требованиям отвечают плохо.
Другой вопрос, что с экономической точки зрения это не очень выгодно, выгоднее делать как придется. Но это извечный вопрос — сделать кое-как или качественно.
А в веб-технологии соотверственно внимание стоит уделять производительности client-side технологий, например js (многие приложения Гугла, например, на мой взгляд в этом плане сделаны так себе, авторы увлеклись созданием сложных интерфейсов на языке, который для этого не очень подходит).
Что касается вопроса про язык для десктопа — очевидно, нужно что-то вроде С++, только было бы замечательно, если б его кто-то подпилил, решив проблемы, начиная с классической проблемы исключений в конструкторе, и придумав нативные и производительные масивы и строки. Ну и мне. как человеку ленивому хотелось бы писать поменьше, то есть сделать автогенерацию заголовочных файлов, убрать необходимость описывать всякие структуры (автогенерация описания структуры, почему бы нет) и типы данных там, где они очевидны. ах, да, и include_once сделайте пожалуйста (или вообще уберите нафик заголовочные файлы) (не понимаю. почему никто до этого не додумался).
Ну и касательно библиотек (Gtk, Qt), они действительно неэффективны, соравните производительность наитивных Win приложений вроде notepad с такими же, написанными на этих библиотеках. Как говорится, разница видна невооруженным глазом. Ну и то, что имитировать ООП на Си — явное извращение, не стоит забывать (я читал про причины, побудившие это сделать, тем не менее это слабое и неэффективное решение).
Качество тут не при чём. Хотя что именно Вы имеете в виду говоря «качество»?
Для меня качество — это точность в решении поставленной задачи. Насколько хорошо решена задача? Вот что главное.
На шарпе пишут и хорошие, качественные программы, хотя жуют они больше чем жевал бы аналог но на С/С++
А ведь часто скорость в решении — не главное. Программа не обязательно должна быть «ультра» быстрой она должна быть достаточно быстрой для своей задачи. Тут важно соблюдать баланс. Разработчики часто перестают проверять perfomence вообще, а вот это уже плохо. Хотя крайности — обычно всегда плохо…
Для меня качество — это точность в решении поставленной задачи. Насколько хорошо решена задача? Вот что главное.
На шарпе пишут и хорошие, качественные программы, хотя жуют они больше чем жевал бы аналог но на С/С++
А ведь часто скорость в решении — не главное. Программа не обязательно должна быть «ультра» быстрой она должна быть достаточно быстрой для своей задачи. Тут важно соблюдать баланс. Разработчики часто перестают проверять perfomence вообще, а вот это уже плохо. Хотя крайности — обычно всегда плохо…
Если кратко: компьютер не должен реагировать медленнее мысли, человеческого мозга. Иначе пользователю приходится ждать, а это некомфортно.
> Для меня качество — это точность в решении
> поставленной задачи. Насколько хорошо
> решена задача? Вот что главное.
Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты. Одно дело — скрипт, который гудит где-то в недрах сервера, часами обрбатывая большой объем данных, железке пофиг, другое дело, то, что у меня, живого человека)) на экране.
Десктопное приложение (которым пользуются повседневно, а не 1 раз, посмотрел — снес) не должно потреблять неадекватное количество памяти, не должно медленно запускаться (сплеш-заставка — это анахронизм 95 годов), интерфейс не должен вызывать заметных глазу задержек, и тем более, «замерзать».
Когда чувствуешь при каждом клике, как событие медленно проваливается сквозь толщу компонентов и обработчиков, или когда на глазах прорисовываются элементы интерфейса, это подрывает весь user-experience.
Сравните для примера Chrome и Firefox. Первый ест больше памяти (издержки технологии, надеюсь исправят), но запускается почти мгновенно. Что хорошего в браузере, который запускается с такой же скоростью, как последний 3Д Макс?(да и работает не быстрее). Ну и естественно, идею реализациии интерфейса на XUL/JS нельзя назвать грамотной, как и идею выполнять обработку событий интерфейса и JS-скрипты в одном потоке, тут просто сказать нечего. Хотя это и можно объяснить ограниченностью ресурсов у разработчиков (не так богаты, как Гугл все же) и «больной» историей (большое число команд учавствовало в разработке, в таких случаях архитектура страдает).
Какой смысл тогда подключаться к многомегабитному интернету, если страницы прорисовываются дольше, чем приходит очередная порция данных из сети?
> Для меня качество — это точность в решении
> поставленной задачи. Насколько хорошо
> решена задача? Вот что главное.
Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты. Одно дело — скрипт, который гудит где-то в недрах сервера, часами обрбатывая большой объем данных, железке пофиг, другое дело, то, что у меня, живого человека)) на экране.
Десктопное приложение (которым пользуются повседневно, а не 1 раз, посмотрел — снес) не должно потреблять неадекватное количество памяти, не должно медленно запускаться (сплеш-заставка — это анахронизм 95 годов), интерфейс не должен вызывать заметных глазу задержек, и тем более, «замерзать».
Когда чувствуешь при каждом клике, как событие медленно проваливается сквозь толщу компонентов и обработчиков, или когда на глазах прорисовываются элементы интерфейса, это подрывает весь user-experience.
Сравните для примера Chrome и Firefox. Первый ест больше памяти (издержки технологии, надеюсь исправят), но запускается почти мгновенно. Что хорошего в браузере, который запускается с такой же скоростью, как последний 3Д Макс?(да и работает не быстрее). Ну и естественно, идею реализациии интерфейса на XUL/JS нельзя назвать грамотной, как и идею выполнять обработку событий интерфейса и JS-скрипты в одном потоке, тут просто сказать нечего. Хотя это и можно объяснить ограниченностью ресурсов у разработчиков (не так богаты, как Гугл все же) и «больной» историей (большое число команд учавствовало в разработке, в таких случаях архитектура страдает).
Какой смысл тогда подключаться к многомегабитному интернету, если страницы прорисовываются дольше, чем приходит очередная порция данных из сети?
>компьютер не должен реагировать медленнее мысли
Это в идеале. А в жизни всё сложнее.
>Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты
Я не путаю. Когда я говорил про достаточную скорость я имел в виду все программы, вне зависимости от применения.
>но запускается почти мгновенно
Вот когда к нему прикрутят весь тот плагинный функционал что есть у фф тогда и будем сравнивать.
Вы приписываете мне свои мысли.
Скорость должна быть достаточной. Для любой программы.
Это в идеале. А в жизни всё сложнее.
>Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты
Я не путаю. Когда я говорил про достаточную скорость я имел в виду все программы, вне зависимости от применения.
>но запускается почти мгновенно
Вот когда к нему прикрутят весь тот плагинный функционал что есть у фф тогда и будем сравнивать.
Вы приписываете мне свои мысли.
Скорость должна быть достаточной. Для любой программы.
> Вот когда к нему прикрутят весь тот
> плагинный функционал что есть у фф
> тогда и будем сравнивать.
Тормознутость браузера перечеркивает все преимущества плагинов. И эту тормознутость ничем не исправить, надо только подождать пару лет, когда железо станет помощнее. Если конечно программеры FireFox не придумают еще какуб-нибудь ресурсоемкую хрень.
Что касается скорости работы программ — это непосредственно связано с юзабилити, удобством использования. Хотя возможно, улучшение юзабилити не является для кого-то приоритетом.
>компьютер не должен реагировать медленнее мысли
> Это в идеале. А в жизни всё сложнее.
Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду. Если программа делает что-то мега слодное — выведите градусник, но томрозов тем не менее быть не должно. Пользователь мог бы ввести поисковый запрос и сидеть смотреть результаты, делать выводы, а вместо этого он должен ждать пока загрузится браузер, тратя свое время. Какой смысл в быстром интернете с медленным браузером, объясните?
> плагинный функционал что есть у фф
> тогда и будем сравнивать.
Тормознутость браузера перечеркивает все преимущества плагинов. И эту тормознутость ничем не исправить, надо только подождать пару лет, когда железо станет помощнее. Если конечно программеры FireFox не придумают еще какуб-нибудь ресурсоемкую хрень.
Что касается скорости работы программ — это непосредственно связано с юзабилити, удобством использования. Хотя возможно, улучшение юзабилити не является для кого-то приоритетом.
>компьютер не должен реагировать медленнее мысли
> Это в идеале. А в жизни всё сложнее.
Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду. Если программа делает что-то мега слодное — выведите градусник, но томрозов тем не менее быть не должно. Пользователь мог бы ввести поисковый запрос и сидеть смотреть результаты, делать выводы, а вместо этого он должен ждать пока загрузится браузер, тратя свое время. Какой смысл в быстром интернете с медленным браузером, объясните?
>Какой смысл в быстром интернете с медленным браузером, объясните?
Видео смотреть удобнее.
>Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду.
Вы никогда не задумывались почему производители браузеров — огромные компании с миллионными оборотами? С большим штатом программистов? Даже целые войны были.
Неужели Вы действительно умаете что всё так просто?
Видео смотреть удобнее.
>Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду.
Вы никогда не задумывались почему производители браузеров — огромные компании с миллионными оборотами? С большим штатом программистов? Даже целые войны были.
Неужели Вы действительно умаете что всё так просто?
НЛО прилетело и опубликовало эту надпись здесь
Если кратко — в общем, вы правы. Я абсолютно не против использования библиотек, конечно, не писать же свою функцию printf() ))) Более того, нет наверно никакого смысла писать все самому, то, что уже написано и отлажено до тебя тысячей человек. Но почему люди просто тупо статически линкуют библиотеку целиком, даже если используют меньшую часть функций? (подозреваю, в опенсорсе это связано с тем, что gcc не умеет function-level linking)
Другой вопрос, что библиотеки бывают разные. Упомянутые мной Gtk и Qt (мое имхо) потебляют неадекватное количество ресурсов, посмотрите, сколько времени будет выполняться HelloWorld. Другой вопрос, что они дают чот-то вроде кроссплатформенности, но не дорогая ли выходит плата за кроссплатформенность? Особенно учитывая крошечный процент пользователей не-Win систем. Получается, что 97% человек платят за то, чтобы у оставшихся 3% эта программа тоже работала.
Другой пример. Есть такая замечательная программа DropBox. У нее очень классная задумка, а вот реализация — подкачала (именно десктопного клиента, к веб-инетрфейсу претензий нет). Эта программа, даже ничего не делая, сидя в трее потребляет под 50Мб памяти, как вы думаете, почему? А загляните-ка в папку программы и увидите там во-первых, Python25.dll, значит минимум часть программы написана на питоне, уже понятно, куда девается память и возможно скорость работы. Теперь заглянем в 24 мегабайтный екзешник, который представляет собой мало того, что debug-версию (руки бы поотрывать), так еще и является архивом. да-да, не ослышались, это архив, видимо во время запуска он куда-то распаковывается, на диск или в память. В архиве — тонна файлов и папок, ощущение, что это пакет с исходниками ядра Линукса)) Но нет, там куча (слава богу, откомпилированных) Питоновских файлов и библиотек. Ах да, еще несколько внушительного размера библиотек вроде wxmsw28uh_core_vc.dll (3 мб, нехилый размер для core). Вот и обяъяснение памятежоркости — Питон + WxWidgets. Нафига им сдался питон и WxWidgets — не пойму. неужели нет на С++ хороших библиотек. что творится-то? Или они денег все стоят? И почему, блин, Питон, если уж его использовать, не компилируется в машинный код.а превращается в какую-то хрень, помесь архива и exe-файла? По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Вот такие вот печальные дела(
Другой вопрос, что библиотеки бывают разные. Упомянутые мной Gtk и Qt (мое имхо) потебляют неадекватное количество ресурсов, посмотрите, сколько времени будет выполняться HelloWorld. Другой вопрос, что они дают чот-то вроде кроссплатформенности, но не дорогая ли выходит плата за кроссплатформенность? Особенно учитывая крошечный процент пользователей не-Win систем. Получается, что 97% человек платят за то, чтобы у оставшихся 3% эта программа тоже работала.
Другой пример. Есть такая замечательная программа DropBox. У нее очень классная задумка, а вот реализация — подкачала (именно десктопного клиента, к веб-инетрфейсу претензий нет). Эта программа, даже ничего не делая, сидя в трее потребляет под 50Мб памяти, как вы думаете, почему? А загляните-ка в папку программы и увидите там во-первых, Python25.dll, значит минимум часть программы написана на питоне, уже понятно, куда девается память и возможно скорость работы. Теперь заглянем в 24 мегабайтный екзешник, который представляет собой мало того, что debug-версию (руки бы поотрывать), так еще и является архивом. да-да, не ослышались, это архив, видимо во время запуска он куда-то распаковывается, на диск или в память. В архиве — тонна файлов и папок, ощущение, что это пакет с исходниками ядра Линукса)) Но нет, там куча (слава богу, откомпилированных) Питоновских файлов и библиотек. Ах да, еще несколько внушительного размера библиотек вроде wxmsw28uh_core_vc.dll (3 мб, нехилый размер для core). Вот и обяъяснение памятежоркости — Питон + WxWidgets. Нафига им сдался питон и WxWidgets — не пойму. неужели нет на С++ хороших библиотек. что творится-то? Или они денег все стоят? И почему, блин, Питон, если уж его использовать, не компилируется в машинный код.а превращается в какую-то хрень, помесь архива и exe-файла? По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Вот такие вот печальные дела(
>Особенно учитывая крошечный процент пользователей не-Win систем. Получается, что 97% человек платят за то, чтобы у оставшихся 3% эта программа тоже работала.
Ага.
>debug-версию
А как Вы это узнали, если это архив?
>на С++ хороших библиотек. что творится-то?
Это называется прогресс. Кроме С++ в мире есть ещё много хороших языков программирования.
>И почему, блин, Питон, если уж его использовать, не компилируется в машинный код
>По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Потому что он — интерпретатор. Вы бы для начала почитали что это такое, а потом уже критиковали.
Если он вам не нужен — это ещё не значит что не нужен никому.
Я уже не говорю о том что без этих «медленных и не нужных» (Python, C#, Java, Tcl ...) языков не появилось бы куча программ. Просто потому что их сложнее было бы делать.
Ага.
>debug-версию
А как Вы это узнали, если это архив?
>на С++ хороших библиотек. что творится-то?
Это называется прогресс. Кроме С++ в мире есть ещё много хороших языков программирования.
>И почему, блин, Питон, если уж его использовать, не компилируется в машинный код
>По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Потому что он — интерпретатор. Вы бы для начала почитали что это такое, а потом уже критиковали.
Если он вам не нужен — это ещё не значит что не нужен никому.
Я уже не говорю о том что без этих «медленных и не нужных» (Python, C#, Java, Tcl ...) языков не появилось бы куча программ. Просто потому что их сложнее было бы делать.
> А как Вы это узнали, если это архив?
PEiD пишет MS VC 7.0 [ZIP SFX][Debug], а Тотал коммандер открывает содержимое (да-да, он и такое умеет)).
> Потому что он — интерпретатор. Вы бы
> для начала почитали что это такое, а
> потом уже критиковали.
Конечному пользователю не нужен интерпретатор, ему нужна программа)) А если вдру понадобится — он его скачает и установит. Тупо свалить файлы и интерпретатор в самораспакавывающийся архив — это путь наименьшего сопротивления.
> Я уже не говорю о том что без этих
> «медленных и не нужных» (Python, C#,
> Java, Tcl ...) языков не появилось бы куча
> программ. Просто потому что их сложнее > было бы делать.
На сервере — пожалуйста. Там за железо платит разработчик, а не пользователь)
PEiD пишет MS VC 7.0 [ZIP SFX][Debug], а Тотал коммандер открывает содержимое (да-да, он и такое умеет)).
> Потому что он — интерпретатор. Вы бы
> для начала почитали что это такое, а
> потом уже критиковали.
Конечному пользователю не нужен интерпретатор, ему нужна программа)) А если вдру понадобится — он его скачает и установит. Тупо свалить файлы и интерпретатор в самораспакавывающийся архив — это путь наименьшего сопротивления.
> Я уже не говорю о том что без этих
> «медленных и не нужных» (Python, C#,
> Java, Tcl ...) языков не появилось бы куча
> программ. Просто потому что их сложнее > было бы делать.
На сервере — пожалуйста. Там за железо платит разработчик, а не пользователь)
Разве не об этом Кнут не так давно говорил?
PC, конечно, изрядно нагружен обратной совместимостью, его тормозит эта самая latency, но процесс геймдева на консолях тормозят гораздо больше высокоуровневых вещей: закрытость и коммерческий характер платформы, отсутствие «любительского» движения разработчиков (моддеров и т. п.), не успевающие за законом Мура маркетинговые циклы… поэтому я спокоен за ПК и даже не собираюсь покупать какую-либо консоль. (Давно что-то у нас не было холиваров на эту тему...:))
Вводная статья (обзорная) в архитектуру железок и проблему производительности приложений. Если автор хотел раскрыть тему производительности, то, думаю, этого не получилось. Только масса вопросов и домыслов родилась у всех… надо либо раскрыть до конца, либо не соваться в эту тему.
Статья породила в комментариях (мне кажется) холи вар среди сторонников managed и unmanaged языков программирования. Одни ругают их за «обжорство» и говорят «ай да низкоуровневое программирование», другие — отстаивают, хвалят их за скорость разработки приложений. По мне так надо всегда выбирать между оптимизированным, вылизанным, быстрым приложением и скоростью его разработки. В первую очередь заказчику (в конечном счёте мы все пишем для какого-то заказчика) надо работающее (корректно, без багов) приложение и в срок. А уж во вторую очередь приложение оптимизированное. Сразу поймать двух зайцев не удастся, уж поверьте. И лучше получит сначала первое, потом второе.
Кому действительно интересна тема низкоуровневой оптимизации тем рекомендую почитать вот эти вещи:
The Software Optimization Cookbook
The Software Optimization Cookbook, Second Edition
The Software Vectorization Handbook
Для оптимизации на многоядерных железках:
Multi-Core Programming
Optimizing Applications for Multi-Core Processors
Это, так сказать, отправная точка для тех, кому интересно. А вот «клубничка» — Code Optimization: Effective Memory Usage от Криса Касперского.
Статья породила в комментариях (мне кажется) холи вар среди сторонников managed и unmanaged языков программирования. Одни ругают их за «обжорство» и говорят «ай да низкоуровневое программирование», другие — отстаивают, хвалят их за скорость разработки приложений. По мне так надо всегда выбирать между оптимизированным, вылизанным, быстрым приложением и скоростью его разработки. В первую очередь заказчику (в конечном счёте мы все пишем для какого-то заказчика) надо работающее (корректно, без багов) приложение и в срок. А уж во вторую очередь приложение оптимизированное. Сразу поймать двух зайцев не удастся, уж поверьте. И лучше получит сначала первое, потом второе.
Кому действительно интересна тема низкоуровневой оптимизации тем рекомендую почитать вот эти вещи:
The Software Optimization Cookbook
The Software Optimization Cookbook, Second Edition
The Software Vectorization Handbook
Для оптимизации на многоядерных железках:
Multi-Core Programming
Optimizing Applications for Multi-Core Processors
Это, так сказать, отправная точка для тех, кому интересно. А вот «клубничка» — Code Optimization: Effective Memory Usage от Криса Касперского.
Холивора не видел. Что все зависит от требований и не всегда производительность приоритет — ну, в десятитысячный повторять не хочется, понимание читателя подразумевается.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
Очень интересная статья, с другой стороны жить как-то расхотелось сразу )
На самом деле out-of-order весьма фигово борется с memory wall, особенно в многозадачных и многопроцессорных системах. Предсказатели ветвлений не идеальны, если код не тупо потоковый (считаем сумму элементов массива), а логический (типа анализа того, куда юнит наступил), то они ошибаются очень часто, генерируют ложные обращения к памяти, к TLB, синхронизация кэшей. И вообще прочий ужас.
Кроме того, никуда нам не уйти от зависимостей. Код, в котором нет зависимостей — это тривиальные примеры, в чём-то более или менее сложных не бывает цепочек независимого кода длиной больше 100 инструкций. И P4 оказался провалом именно поэтому, потому что нет такого когда, который хорошо бы ложился на эти длинные конвейеры… Ну… Или этот код просто бы моделировал сферического коня в вакууме. В реальных программах не так уж и много микропараллелизма (независимостей, скажем, в анализе поведения персонажа в игрушке), зато много параллелизма уровня среднего (несколько моделей можно обсчитывать независимости), который out-of-order cpu просто не видит.
Поэтому, гораздо более мощное средство борьбы за сокрытие задержек — это SMT. Собственно, отчасти именно поэтому GPU такую звериную пиковую производительность имеют.
Ну. А борьба за локальность, конечно, актуальна при любой архитектуре.
Кроме того, никуда нам не уйти от зависимостей. Код, в котором нет зависимостей — это тривиальные примеры, в чём-то более или менее сложных не бывает цепочек независимого кода длиной больше 100 инструкций. И P4 оказался провалом именно поэтому, потому что нет такого когда, который хорошо бы ложился на эти длинные конвейеры… Ну… Или этот код просто бы моделировал сферического коня в вакууме. В реальных программах не так уж и много микропараллелизма (независимостей, скажем, в анализе поведения персонажа в игрушке), зато много параллелизма уровня среднего (несколько моделей можно обсчитывать независимости), который out-of-order cpu просто не видит.
Поэтому, гораздо более мощное средство борьбы за сокрытие задержек — это SMT. Собственно, отчасти именно поэтому GPU такую звериную пиковую производительность имеют.
Ну. А борьба за локальность, конечно, актуальна при любой архитектуре.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Разработка на PC и производительность — Memory Latency