Комментарии 70
Огромное спасибо за интересную статью!
Для меня сейчас, вы — самый интересный автор на хабре )
Для меня сейчас, вы — самый интересный автор на хабре )
0
а где бы про это можно подробней почитать??
желательно с простыми примерами и с самого начала…
пишу ресурсоемкие приложения на c++ (имидж процессинг), знаю что можно ускорить, но не знаю как ö(
желательно с простыми примерами и с самого начала…
пишу ресурсоемкие приложения на c++ (имидж процессинг), знаю что можно ускорить, но не знаю как ö(
0
Линк из предыдущего коммента очень хороший, начинать читать надо там ( 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, и пару любых туториалов из гугла.
Ну там, вот
+1
Использовать IPP, там уже все ускорено за вас.
0
Очень познавательно. Я еще в университете забросил C++ из-за постоянной борьбы с компиляторами и проблемами выполнения кода на разных компьютерах. Ваша статья, отчасти, помогла понять чать проблем и то, почему многие программисты ругают современный подход Intel к проектированию процессоров.
-4
Какой такой подход? x86 в отличие от любых других современных процессоров может выполнять неоптимизированное мясо, коим являются 90% программ, с хорошей скоростью.
+2
Впечатлило. Так вот оказывается почему консоли могут выдавать прекрасную графику на сравнительно средней аппаратной начинке.
+14
А вот вопрос к специалисту — а как с этим обстоят дела на больших компьютерах? Ну всяких спарках сановских, креях и прочих мегадолларовых устройствах?
0
А я не специалист ни разу по серверному железу. В Спарках вроде бы тот же DDR, так что проблемы все на месте. На сервере попроще, реалтайм-перформанс не так критичен.
За Креи совсем не знаю.
За Креи совсем не знаю.
0
реалтайм-перфомансе важен в oltp, так-что там все тоже самое, только помноженное на промышленную эксплуатацию. :(
0
Я скорее в том смысле, что мне казалось, там важен bandwidth — сколько удается обработать запросов в секунду, а не latency — сколько занимает один запрос. В таком случае, проблемы в крайнем случае можно решать деньгами — увеличивать количество серверов и т.д., временем программиста, соответственно, только если оно оказывается дешевле серверов. Чем дальше ужимаешь — тем больше нужно усилий, в пределе — design for performance, войны за такты и прочее.
В реалтайме же такого размена вообще нет — критично время работы одной задачи на одной машине прямо здесь и сейчас. Становится веселее.
Впрочем, это я патриот низкоуровнего перформанса.
Оффтоп: интересно, как бы железную загрузку процессора показательно померять, чтобы сравнить…
В реалтайме же такого размена вообще нет — критично время работы одной задачи на одной машине прямо здесь и сейчас. Становится веселее.
Впрочем, это я патриот низкоуровнего перформанса.
Оффтоп: интересно, как бы железную загрузку процессора показательно померять, чтобы сравнить…
0
Чуствую себя лохом :(
Засиделся в пхп, пожалуй надо опуститься на low-level, хотя бы ненадолго.
Засиделся в пхп, пожалуй надо опуститься на low-level, хотя бы ненадолго.
+8
Random Memory Access: ~200 cycles — это хорошо или плохо? А сколько у вас цикл? Чтобы не было таких глупых вопросов Latency измеряется не в циклах чего-то там, а в секундах — наносекундах. Поэтому у автора и такие бредовые результаты с ухудшением латентности в 150 раз по сравнению с 1980.
-2
Только всё равно процессор простаивает 200 циклов, а мог бы делать полезную работу. Конечно, иногда out of order исполнение спасает, но не так часто, как хотелось бы.
+3
Кто вам сказал что он простаивает эти 200 тактов? 200 таковый LLC miss+DTLB miss — это надо постараться так писать программы, чтобы у вас при каждом обращении в память такие простои были. А если промах один-два, то эти промахи скрадываются Out-Of-Order выполнением других инструкций.
0
С трудом себе представляю внеочередное выполнение сотни независимых, например, двухтактовых комманд. Если повезёт, выполнится две-три командны, остальные 190 тактов процессор будет крутится вхолостую.
Что же до промахов, любой список указателей на данные в куче потенциальный источник таких катаклизмов с высокой вероятностью.
Что же до промахов, любой список указателей на данные в куче потенциальный источник таких катаклизмов с высокой вероятностью.
+1
точнее говоря, тут не только в программе дело
компилятор (статический оптимизатор) + железо (динамический out-of-order) делают свои дела. Причем на ILP (instruction level parallelism), то бишь железо, приходится основная доля распараллеливания в самом (самих) пайплаине (пайплаинах).
Кроме того не стоит забывать о MOB, L2 и victim cache.
компилятор (статический оптимизатор) + железо (динамический out-of-order) делают свои дела. Причем на ILP (instruction level parallelism), то бишь железо, приходится основная доля распараллеливания в самом (самих) пайплаине (пайплаинах).
Кроме того не стоит забывать о MOB, L2 и victim cache.
0
НЛО прилетело и опубликовало эту надпись здесь
FFT кстати отлично переписывается на регулярные доступы. Матричное умножение отдельными локальными блоками порядка размера кеша.
Вот тут показательный пример — lwn.net/Articles/255364/
Вот тут показательный пример — lwn.net/Articles/255364/
0
Два кеш-мисса — это значит out of order должен предоставить инструкций на 400 тактов, то есть сотни. Это очень немало, их вполне может не найтись.
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
0
Вычислительная операция как была такт, так и осталась тактом (с учетом SIMD-операций и multicore, еще меньше). В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
+2
Вычислительная операция — это абстрактное понятие. SSE делает 2 дабловых умножения за такт. 1 дабловое умножение при этом занимает 0.5 такта. Сингловое умножение, соответственно 0.25 тактов. А сейчас в Блумфилдах будет плавающий множитель и режим турбо, и такт у вас будет такой, чтобы влезать в TDP.
>>В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
Это как раз не меняет. Как раньше хреново было, так и сейчас. Ничего нового. А вот ООО, кэш, префетч, предсказание переходов — это да, это — меняет.
>>В 150 раз ухудшилось соотношение скорости памяти к скорости процессора. Это принципиально меняет факторы, влияющие на производительность приложения.
Это как раз не меняет. Как раньше хреново было, так и сейчас. Ничего нового. А вот ООО, кэш, префетч, предсказание переходов — это да, это — меняет.
0
Дык нет же. Раньше было совсем не так, вычисления были сравнимы с доступом в память. Ну комон, если раньше люди для того чтобы программа работала быстрее чаще пытались делать на сложение меньше, то теперь надо смотреть и думать о локальности памяти. Когда скорость доступа к памяти сравнима с обычной инструкций — вообще проблемы локальности не стоит.
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».
0
«Поставить поставить два процессора» — исправьте пожалуйста.
0
Отличная статья.
По поводу 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.»
+7
Практический вопрос: для скриптовых языков типа php или perl, c огромным расходом памяти, лучше использовать два медленных процессора вместо одного быстрого, получается? Есть ли конкретные рекомендации на эту тему — например, несколько бакэндов + фронтэнд vs один бакэнд+фронтэнд? И какое влияние многоядерности на доступ к памяти — будут ли двухядерные процессоры в сумме иметь меньшие потери производительности из-за латентности, чем одноядерный большей частоты в два раза?
0
Многоядерность она разная бывает. В исполнении с общей FSB многоядерность ухудшает доступ к памяти, поскольку вводятся дополнительные затраты на синхронизацию кэшей (снупинг). В исполнении NUMA все хорошо, когда каждое ядро вделяет память симметрично. Но как только одно ядро залезло в память другого — все, опять тормозим.
Я честно скажу — не занимался профилированием скриптов, но на первый взгляд — высокая частота+оч большой кэш — вот что для них нужно. А какие-то вычислительные задачи лучше писать на С-подобных языках с жесткой оптимизацией под платформу — компилятором и/или руками.
Я честно скажу — не занимался профилированием скриптов, но на первый взгляд — высокая частота+оч большой кэш — вот что для них нужно. А какие-то вычислительные задачи лучше писать на С-подобных языках с жесткой оптимизацией под платформу — компилятором и/или руками.
+1
Извините, но Александреску… Как-то странно видеть написание его фамилии через «О».
А статья правда интересная! Спасибо!
А статья правда интересная! Спасибо!
+2
Можно ли считать процессоры без MMU/TLB более простыми, но и прогрессивными в архитектурном плане? (типа ARM'ов, как в сотовых телефонах и микроконтроллёрах)
Будущее за простотой! Долой многоуровневую эмуляцию?
Будущее за простотой! Долой многоуровневую эмуляцию?
0
с 64-битовой адресацией без MMU можно без проблем жить, наверное. Но ведь виртуальная память — это не только эмуляция, но и изоляция.
Хотя было бы здорово иметь одну абстракцию на дисковую память и физическую :) Соответственно, и механизмы защиты позаимствовать.
Хотя было бы здорово иметь одну абстракцию на дисковую память и физическую :) Соответственно, и механизмы защиты позаимствовать.
0
Все, как всегда, сложно. Процессорам на открытах платформах с обратной совместимостью — боюсь, придется играть в эти игры. Потому что а) людям не хочется шибко много думать, когда они пишут код и б) есть очень много уже написанного кода, который хочется запускать быстрее.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
0
Вот, наконец-то поднимают эту тему! Сегодня проблемой десктопных приложений еще и становится то, что лентяи-программисты используют либо языки вроде явы/дотнета, либо библиотеки вроде Qt, которые, кроме всего прочего, отличаются непомерным большим потреблением памяти, в результате чего (я подозреваю) происходит намоного больше обращений к RAM так как эти монстры просто физически не могут поместиться в кеш.
Кроме, того в ООП-библиотеках использутся многократное наследование, на каждом этапе в класс добавляются новые поля, в результате чего экземпляр класса занимает достаточно много места в памяти, и если многие поля не используются, то они все равно вытягиваются в кеш и отнимают там местло, так как все хранятся рядом.
Кроме, того в ООП-библиотеках использутся многократное наследование, на каждом этапе в класс добавляются новые поля, в результате чего экземпляр класса занимает достаточно много места в памяти, и если многие поля не используются, то они все равно вытягиваются в кеш и отнимают там местло, так как все хранятся рядом.
-2
НЛО прилетело и опубликовало эту надпись здесь
Java и NET (пока что) место на сервере, а не на десктопе.
Множество программ, начаная с классических winRAR/winAMP/foobar2000 и так далее написаны без всего этого и замечательно работали/работают.
А тенденция использовать упомянутые технологии меня, как пользователя, не радует (а линусоидам еще хуже, там вообще пытаются к скриптовым языкам прикручивать Gtk, надеюсь вы и сами понимаете, какой ужас в результате полуается).
Множество программ, начаная с классических winRAR/winAMP/foobar2000 и так далее написаны без всего этого и замечательно работали/работают.
А тенденция использовать упомянутые технологии меня, как пользователя, не радует (а линусоидам еще хуже, там вообще пытаются к скриптовым языкам прикручивать Gtk, надеюсь вы и сами понимаете, какой ужас в результате полуается).
-2
Лентяи говоришь?
А головой подумать?
Вы же, наверное, не лентяйничаете и не ездите в транспорте, а идёте пешком?
Всегда есть 2 стороны медали.
Скорость и минимальность нужна не везде и не всегда. Да, к тому же, за неё приходится платить.
А головой подумать?
Вы же, наверное, не лентяйничаете и не ездите в транспорте, а идёте пешком?
Всегда есть 2 стороны медали.
Скорость и минимальность нужна не везде и не всегда. Да, к тому же, за неё приходится платить.
-1
Ну хорошо, лентяи, я немного перегнул, тут скорее рыночные обстоятельства, то есть разработчику/программистам нужно реализовать выполнение программой каких-то задач к какому-то сроку, а уж насколько качественно это будет сделано — дело десятое, наверно писать исключительно хорошие программы невыгодно, где-то я читал… не помню, может у Споэльски.
-2
НЛО прилетело и опубликовало эту надпись здесь
Боюсь, вы неправильно меня поняли. Я говорю о производительности языков для десктопных приложений, а не серверных. Согласен, на сервере можно хоть на Руби писать, так как всегда можно обеспечить нужную производительность покупкой хорошего железа, настройкой ОС, кешированием, масштабированием и прочим.
Пользователю важно, чтобы у него все работало быстро, и никто не будет против, если вы напишете скрипт, делающий хоть 1000 запросов к бд, если сможете обеспечить производительность.
Но десктопные приложения — другая область, здесь перед разработчиком другой уровень требований, и писать надо программы, эффективно использующие ресурсы компьютера (а не вести себя так, как будто пользователь будет запускать только вашу программу и больше ничего параллельно). Перечисленные мной технологии этим требованиям отвечают плохо.
Другой вопрос, что с экономической точки зрения это не очень выгодно, выгоднее делать как придется. Но это извечный вопрос — сделать кое-как или качественно.
А в веб-технологии соотверственно внимание стоит уделять производительности client-side технологий, например js (многие приложения Гугла, например, на мой взгляд в этом плане сделаны так себе, авторы увлеклись созданием сложных интерфейсов на языке, который для этого не очень подходит).
Что касается вопроса про язык для десктопа — очевидно, нужно что-то вроде С++, только было бы замечательно, если б его кто-то подпилил, решив проблемы, начиная с классической проблемы исключений в конструкторе, и придумав нативные и производительные масивы и строки. Ну и мне. как человеку ленивому хотелось бы писать поменьше, то есть сделать автогенерацию заголовочных файлов, убрать необходимость описывать всякие структуры (автогенерация описания структуры, почему бы нет) и типы данных там, где они очевидны. ах, да, и include_once сделайте пожалуйста (или вообще уберите нафик заголовочные файлы) (не понимаю. почему никто до этого не додумался).
Ну и касательно библиотек (Gtk, Qt), они действительно неэффективны, соравните производительность наитивных Win приложений вроде notepad с такими же, написанными на этих библиотеках. Как говорится, разница видна невооруженным глазом. Ну и то, что имитировать ООП на Си — явное извращение, не стоит забывать (я читал про причины, побудившие это сделать, тем не менее это слабое и неэффективное решение).
Пользователю важно, чтобы у него все работало быстро, и никто не будет против, если вы напишете скрипт, делающий хоть 1000 запросов к бд, если сможете обеспечить производительность.
Но десктопные приложения — другая область, здесь перед разработчиком другой уровень требований, и писать надо программы, эффективно использующие ресурсы компьютера (а не вести себя так, как будто пользователь будет запускать только вашу программу и больше ничего параллельно). Перечисленные мной технологии этим требованиям отвечают плохо.
Другой вопрос, что с экономической точки зрения это не очень выгодно, выгоднее делать как придется. Но это извечный вопрос — сделать кое-как или качественно.
А в веб-технологии соотверственно внимание стоит уделять производительности client-side технологий, например js (многие приложения Гугла, например, на мой взгляд в этом плане сделаны так себе, авторы увлеклись созданием сложных интерфейсов на языке, который для этого не очень подходит).
Что касается вопроса про язык для десктопа — очевидно, нужно что-то вроде С++, только было бы замечательно, если б его кто-то подпилил, решив проблемы, начиная с классической проблемы исключений в конструкторе, и придумав нативные и производительные масивы и строки. Ну и мне. как человеку ленивому хотелось бы писать поменьше, то есть сделать автогенерацию заголовочных файлов, убрать необходимость описывать всякие структуры (автогенерация описания структуры, почему бы нет) и типы данных там, где они очевидны. ах, да, и include_once сделайте пожалуйста (или вообще уберите нафик заголовочные файлы) (не понимаю. почему никто до этого не додумался).
Ну и касательно библиотек (Gtk, Qt), они действительно неэффективны, соравните производительность наитивных Win приложений вроде notepad с такими же, написанными на этих библиотеках. Как говорится, разница видна невооруженным глазом. Ну и то, что имитировать ООП на Си — явное извращение, не стоит забывать (я читал про причины, побудившие это сделать, тем не менее это слабое и неэффективное решение).
0
Качество тут не при чём. Хотя что именно Вы имеете в виду говоря «качество»?
Для меня качество — это точность в решении поставленной задачи. Насколько хорошо решена задача? Вот что главное.
На шарпе пишут и хорошие, качественные программы, хотя жуют они больше чем жевал бы аналог но на С/С++
А ведь часто скорость в решении — не главное. Программа не обязательно должна быть «ультра» быстрой она должна быть достаточно быстрой для своей задачи. Тут важно соблюдать баланс. Разработчики часто перестают проверять perfomence вообще, а вот это уже плохо. Хотя крайности — обычно всегда плохо…
Для меня качество — это точность в решении поставленной задачи. Насколько хорошо решена задача? Вот что главное.
На шарпе пишут и хорошие, качественные программы, хотя жуют они больше чем жевал бы аналог но на С/С++
А ведь часто скорость в решении — не главное. Программа не обязательно должна быть «ультра» быстрой она должна быть достаточно быстрой для своей задачи. Тут важно соблюдать баланс. Разработчики часто перестают проверять perfomence вообще, а вот это уже плохо. Хотя крайности — обычно всегда плохо…
0
Если кратко: компьютер не должен реагировать медленнее мысли, человеческого мозга. Иначе пользователю приходится ждать, а это некомфортно.
> Для меня качество — это точность в решении
> поставленной задачи. Насколько хорошо
> решена задача? Вот что главное.
Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты. Одно дело — скрипт, который гудит где-то в недрах сервера, часами обрбатывая большой объем данных, железке пофиг, другое дело, то, что у меня, живого человека)) на экране.
Десктопное приложение (которым пользуются повседневно, а не 1 раз, посмотрел — снес) не должно потреблять неадекватное количество памяти, не должно медленно запускаться (сплеш-заставка — это анахронизм 95 годов), интерфейс не должен вызывать заметных глазу задержек, и тем более, «замерзать».
Когда чувствуешь при каждом клике, как событие медленно проваливается сквозь толщу компонентов и обработчиков, или когда на глазах прорисовываются элементы интерфейса, это подрывает весь user-experience.
Сравните для примера Chrome и Firefox. Первый ест больше памяти (издержки технологии, надеюсь исправят), но запускается почти мгновенно. Что хорошего в браузере, который запускается с такой же скоростью, как последний 3Д Макс?(да и работает не быстрее). Ну и естественно, идею реализациии интерфейса на XUL/JS нельзя назвать грамотной, как и идею выполнять обработку событий интерфейса и JS-скрипты в одном потоке, тут просто сказать нечего. Хотя это и можно объяснить ограниченностью ресурсов у разработчиков (не так богаты, как Гугл все же) и «больной» историей (большое число команд учавствовало в разработке, в таких случаях архитектура страдает).
Какой смысл тогда подключаться к многомегабитному интернету, если страницы прорисовываются дольше, чем приходит очередная порция данных из сети?
> Для меня качество — это точность в решении
> поставленной задачи. Насколько хорошо
> решена задача? Вот что главное.
Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты. Одно дело — скрипт, который гудит где-то в недрах сервера, часами обрбатывая большой объем данных, железке пофиг, другое дело, то, что у меня, живого человека)) на экране.
Десктопное приложение (которым пользуются повседневно, а не 1 раз, посмотрел — снес) не должно потреблять неадекватное количество памяти, не должно медленно запускаться (сплеш-заставка — это анахронизм 95 годов), интерфейс не должен вызывать заметных глазу задержек, и тем более, «замерзать».
Когда чувствуешь при каждом клике, как событие медленно проваливается сквозь толщу компонентов и обработчиков, или когда на глазах прорисовываются элементы интерфейса, это подрывает весь user-experience.
Сравните для примера Chrome и Firefox. Первый ест больше памяти (издержки технологии, надеюсь исправят), но запускается почти мгновенно. Что хорошего в браузере, который запускается с такой же скоростью, как последний 3Д Макс?(да и работает не быстрее). Ну и естественно, идею реализациии интерфейса на XUL/JS нельзя назвать грамотной, как и идею выполнять обработку событий интерфейса и JS-скрипты в одном потоке, тут просто сказать нечего. Хотя это и можно объяснить ограниченностью ресурсов у разработчиков (не так богаты, как Гугл все же) и «больной» историей (большое число команд учавствовало в разработке, в таких случаях архитектура страдает).
Какой смысл тогда подключаться к многомегабитному интернету, если страницы прорисовываются дольше, чем приходит очередная порция данных из сети?
0
>компьютер не должен реагировать медленнее мысли
Это в идеале. А в жизни всё сложнее.
>Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты
Я не путаю. Когда я говорил про достаточную скорость я имел в виду все программы, вне зависимости от применения.
>но запускается почти мгновенно
Вот когда к нему прикрутят весь тот плагинный функционал что есть у фф тогда и будем сравнивать.
Вы приписываете мне свои мысли.
Скорость должна быть достаточной. Для любой программы.
Это в идеале. А в жизни всё сложнее.
>Не путайте, повторю еще раз, десктопные приложения и серверные или командно-строчные скрипты
Я не путаю. Когда я говорил про достаточную скорость я имел в виду все программы, вне зависимости от применения.
>но запускается почти мгновенно
Вот когда к нему прикрутят весь тот плагинный функционал что есть у фф тогда и будем сравнивать.
Вы приписываете мне свои мысли.
Скорость должна быть достаточной. Для любой программы.
-1
> Вот когда к нему прикрутят весь тот
> плагинный функционал что есть у фф
> тогда и будем сравнивать.
Тормознутость браузера перечеркивает все преимущества плагинов. И эту тормознутость ничем не исправить, надо только подождать пару лет, когда железо станет помощнее. Если конечно программеры FireFox не придумают еще какуб-нибудь ресурсоемкую хрень.
Что касается скорости работы программ — это непосредственно связано с юзабилити, удобством использования. Хотя возможно, улучшение юзабилити не является для кого-то приоритетом.
>компьютер не должен реагировать медленнее мысли
> Это в идеале. А в жизни всё сложнее.
Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду. Если программа делает что-то мега слодное — выведите градусник, но томрозов тем не менее быть не должно. Пользователь мог бы ввести поисковый запрос и сидеть смотреть результаты, делать выводы, а вместо этого он должен ждать пока загрузится браузер, тратя свое время. Какой смысл в быстром интернете с медленным браузером, объясните?
> плагинный функционал что есть у фф
> тогда и будем сравнивать.
Тормознутость браузера перечеркивает все преимущества плагинов. И эту тормознутость ничем не исправить, надо только подождать пару лет, когда железо станет помощнее. Если конечно программеры FireFox не придумают еще какуб-нибудь ресурсоемкую хрень.
Что касается скорости работы программ — это непосредственно связано с юзабилити, удобством использования. Хотя возможно, улучшение юзабилити не является для кого-то приоритетом.
>компьютер не должен реагировать медленнее мысли
> Это в идеале. А в жизни всё сложнее.
Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду. Если программа делает что-то мега слодное — выведите градусник, но томрозов тем не менее быть не должно. Пользователь мог бы ввести поисковый запрос и сидеть смотреть результаты, делать выводы, а вместо этого он должен ждать пока загрузится браузер, тратя свое время. Какой смысл в быстром интернете с медленным браузером, объясните?
0
>Какой смысл в быстром интернете с медленным браузером, объясните?
Видео смотреть удобнее.
>Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду.
Вы никогда не задумывались почему производители браузеров — огромные компании с миллионными оборотами? С большим штатом программистов? Даже целые войны были.
Неужели Вы действительно умаете что всё так просто?
Видео смотреть удобнее.
>Не вижу ни одной убедительной причины, по которой программа может притормаживать на процессоре, выполняющем больше миллиарда (!) операций в секунду.
Вы никогда не задумывались почему производители браузеров — огромные компании с миллионными оборотами? С большим штатом программистов? Даже целые войны были.
Неужели Вы действительно умаете что всё так просто?
-1
НЛО прилетело и опубликовало эту надпись здесь
Если кратко — в общем, вы правы. Я абсолютно не против использования библиотек, конечно, не писать же свою функцию 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 никому особо не нужен, вот все на его оптимизацию и забивают.
Вот такие вот печальные дела(
0
>Особенно учитывая крошечный процент пользователей не-Win систем. Получается, что 97% человек платят за то, чтобы у оставшихся 3% эта программа тоже работала.
Ага.
>debug-версию
А как Вы это узнали, если это архив?
>на С++ хороших библиотек. что творится-то?
Это называется прогресс. Кроме С++ в мире есть ещё много хороших языков программирования.
>И почему, блин, Питон, если уж его использовать, не компилируется в машинный код
>По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Потому что он — интерпретатор. Вы бы для начала почитали что это такое, а потом уже критиковали.
Если он вам не нужен — это ещё не значит что не нужен никому.
Я уже не говорю о том что без этих «медленных и не нужных» (Python, C#, Java, Tcl ...) языков не появилось бы куча программ. Просто потому что их сложнее было бы делать.
Ага.
>debug-версию
А как Вы это узнали, если это архив?
>на С++ хороших библиотек. что творится-то?
Это называется прогресс. Кроме С++ в мире есть ещё много хороших языков программирования.
>И почему, блин, Питон, если уж его использовать, не компилируется в машинный код
>По моему, так просто Питон под windows никому особо не нужен, вот все на его оптимизацию и забивают.
Потому что он — интерпретатор. Вы бы для начала почитали что это такое, а потом уже критиковали.
Если он вам не нужен — это ещё не значит что не нужен никому.
Я уже не говорю о том что без этих «медленных и не нужных» (Python, C#, Java, Tcl ...) языков не появилось бы куча программ. Просто потому что их сложнее было бы делать.
-1
> А как Вы это узнали, если это архив?
PEiD пишет MS VC 7.0 [ZIP SFX][Debug], а Тотал коммандер открывает содержимое (да-да, он и такое умеет)).
> Потому что он — интерпретатор. Вы бы
> для начала почитали что это такое, а
> потом уже критиковали.
Конечному пользователю не нужен интерпретатор, ему нужна программа)) А если вдру понадобится — он его скачает и установит. Тупо свалить файлы и интерпретатор в самораспакавывающийся архив — это путь наименьшего сопротивления.
> Я уже не говорю о том что без этих
> «медленных и не нужных» (Python, C#,
> Java, Tcl ...) языков не появилось бы куча
> программ. Просто потому что их сложнее > было бы делать.
На сервере — пожалуйста. Там за железо платит разработчик, а не пользователь)
PEiD пишет MS VC 7.0 [ZIP SFX][Debug], а Тотал коммандер открывает содержимое (да-да, он и такое умеет)).
> Потому что он — интерпретатор. Вы бы
> для начала почитали что это такое, а
> потом уже критиковали.
Конечному пользователю не нужен интерпретатор, ему нужна программа)) А если вдру понадобится — он его скачает и установит. Тупо свалить файлы и интерпретатор в самораспакавывающийся архив — это путь наименьшего сопротивления.
> Я уже не говорю о том что без этих
> «медленных и не нужных» (Python, C#,
> Java, Tcl ...) языков не появилось бы куча
> программ. Просто потому что их сложнее > было бы делать.
На сервере — пожалуйста. Там за железо платит разработчик, а не пользователь)
0
Разве не об этом Кнут не так давно говорил?
-1
PC, конечно, изрядно нагружен обратной совместимостью, его тормозит эта самая latency, но процесс геймдева на консолях тормозят гораздо больше высокоуровневых вещей: закрытость и коммерческий характер платформы, отсутствие «любительского» движения разработчиков (моддеров и т. п.), не успевающие за законом Мура маркетинговые циклы… поэтому я спокоен за ПК и даже не собираюсь покупать какую-либо консоль. (Давно что-то у нас не было холиваров на эту тему...:))
0
Вводная статья (обзорная) в архитектуру железок и проблему производительности приложений. Если автор хотел раскрыть тему производительности, то, думаю, этого не получилось. Только масса вопросов и домыслов родилась у всех… надо либо раскрыть до конца, либо не соваться в эту тему.
Статья породила в комментариях (мне кажется) холи вар среди сторонников 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 от Криса Касперского.
-1
Холивора не видел. Что все зависит от требований и не всегда производительность приоритет — ну, в десятитысячный повторять не хочется, понимание читателя подразумевается.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
0
Очень интересная статья, с другой стороны жить как-то расхотелось сразу )
0
На самом деле out-of-order весьма фигово борется с memory wall, особенно в многозадачных и многопроцессорных системах. Предсказатели ветвлений не идеальны, если код не тупо потоковый (считаем сумму элементов массива), а логический (типа анализа того, куда юнит наступил), то они ошибаются очень часто, генерируют ложные обращения к памяти, к TLB, синхронизация кэшей. И вообще прочий ужас.
Кроме того, никуда нам не уйти от зависимостей. Код, в котором нет зависимостей — это тривиальные примеры, в чём-то более или менее сложных не бывает цепочек независимого кода длиной больше 100 инструкций. И P4 оказался провалом именно поэтому, потому что нет такого когда, который хорошо бы ложился на эти длинные конвейеры… Ну… Или этот код просто бы моделировал сферического коня в вакууме. В реальных программах не так уж и много микропараллелизма (независимостей, скажем, в анализе поведения персонажа в игрушке), зато много параллелизма уровня среднего (несколько моделей можно обсчитывать независимости), который out-of-order cpu просто не видит.
Поэтому, гораздо более мощное средство борьбы за сокрытие задержек — это SMT. Собственно, отчасти именно поэтому GPU такую звериную пиковую производительность имеют.
Ну. А борьба за локальность, конечно, актуальна при любой архитектуре.
Кроме того, никуда нам не уйти от зависимостей. Код, в котором нет зависимостей — это тривиальные примеры, в чём-то более или менее сложных не бывает цепочек независимого кода длиной больше 100 инструкций. И P4 оказался провалом именно поэтому, потому что нет такого когда, который хорошо бы ложился на эти длинные конвейеры… Ну… Или этот код просто бы моделировал сферического коня в вакууме. В реальных программах не так уж и много микропараллелизма (независимостей, скажем, в анализе поведения персонажа в игрушке), зато много параллелизма уровня среднего (несколько моделей можно обсчитывать независимости), который out-of-order cpu просто не видит.
Поэтому, гораздо более мощное средство борьбы за сокрытие задержек — это SMT. Собственно, отчасти именно поэтому GPU такую звериную пиковую производительность имеют.
Ну. А борьба за локальность, конечно, актуальна при любой архитектуре.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка на PC и производительность — Memory Latency