| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > JavaScript: Общие вопросы > Побочные результаты замеров перегрузки процессоров |
| Автор: 12345c 26.12.2006, 09:37 |
| Динамические свойства и характеристики браузеров были измерены на примере скрипта падающего снега. За показатель перегрузки принимался процент отставания таймера, который крутился в непрерывном цикле по setInterval( ..., 70); (70 мсек.). Имея http://forum.vingrad.ru/topic-129011.html, первым делом понадобилось посмотреть, как ведут себя показатели перегрузки в разных браузерах, чтобы впоследствии при разных перегрузках представлять, в какой точке характеристики мы находимся, насколько надо уменьшить нагрузку процессора, чтобы анимация пришла в норму. Измерения велись на странице http://js2.ru/example/xmp002/falling-snow-2.htm . Получились интересные и разнообразные по поведению результаты, которые показывают как особенности браузеров, так и то, что стратегии измерения и выбора нагрузки у них должны быть разные. По крайней мере, коэффициенты расчёта в формулах будут зависеть от браузеров. Интересно посмотреть, как ведут себя браузеры при повышении нагрузки. Сразу оговорим условия опыта. Замечено, что в IE6 отисовка летающих букв была намного медленнее, чем в IE7. Чтобы не портить картину случайным выбором букв, в эксперименте участвовали только рисунки (снежинок). При этом условии результаты IE почти не отличались. Опера 7-8 работатла очень быстро, но надо учесть, что она не поддерживает прозрачность, а это отображать традиционно труднее. Опера 9 догнала по быстродействию 7-ю и была примерно в 1.3 раза лучше IE. FF1.07 представлял довольно жалкое зрелище на фоне остальных, но в пределах своей нормы с работой справлялся. В FF заметна интересная методика работы таймера: если он сначала запаздывает по внешним причинам (даже на протяжении 3-4 секунд), то затем интервалы его обязательно сокращаются и догоняют часы (если смогут)! Такой особенности в остальных браузерах нет. В Опере-9 виден радикально иной подход к отсчёту таймеров, чем в прежних - она ухитряется соблюдать правильность хода таймера, насколько может, но при этом не видно периодов уменьшения интервалов с целью догнать часы. В Операх также видна другая особенность работы таймера или данного скрипта - забор процессорного времени происходит "квантами", примерно равными 10% мощности процессора. Из-за этого наблюдается некоторая ступенчатость характеристики реальной загрузки процессора. Но в скрипте нет такой особености и в других бр-рах она не проявляется. Наконец, у IE и Оперы видна особая "методика запаздывания" таймера: если нагрузка начинает превышать 50%, запаздывание таймера выходит на "плато" - величину 14-15%, которое продолжается довольно долго - до 80-85% нагрузки. И это надо считать работоспособной областью скрипта, поскольку до перегрузки процессора далеко. В следующем списке приведены предельные количества снежинок при заданных условиях опыта. Предел нагрузки (числа снежинок) в данном опыте (c 17%-перегрузкой/100% нагрузкой процессора): IE7: 55/110 IE6: 45/90 FF1.07: 40/35 FF2: 80/70 Op7.54: 70/150 Op8.01: 150/300? Op9.10: 90/100 Условия опыта соблюдались во всём одинаковые - объём программ в ОЗУ, размер окна браузера, активность окна. Усреднялись показания при устоявшемся процессе за период 10-20 сек. . Все результаты - в таблице (Excel), процент загрузки процессора (Athlon-2000+, ОЗУ DDR-266) и показания отладочного монитора, которое означает процент отставания таймера. Процент отставания, в свою очередь, считался как среднее между максимальным и минимальным значениями отставания за несколько (22) измерений в течение 1.6 секунды. И приблизительное среднее за период 10-20 с бралось от этой полусуммы. Дополнительные измерения. Интересно было узнать, насколько нагружают процессор скрипты в фоновом режиме. Взяты нагрузки примерно в 80% при открытом окне, затем окно свёрнуто и снова измерен процент нагрузки. Отношение загрузки развёрнутого/минимизированного окна (%). FF2: 85/30 Op8.01: 80/40 Ie6: 85:35 В приложенном файле можно найти таблицу Excel c диаграммой перегрузок в зависимости от числа снежинок для 7 браузеров и, для тех, кому затруднительно посмотреть её в Экселе, рисунок (PNG) всего содержимого листа. Добавление: к таблицам нагрузки добавил диаграмму "загрузка (процессора)-перегрузка (скриптом процессора)". Комментарии в 12-м по счёту сообщении. |
| Автор: dstorm81 26.12.2006, 10:57 |
мда 12345c чувствую тебе на праздники отдохнуть хорошо надо...  нет я конечно понимаю статистика к примеру по innerHTMLvsDOM при создании select а вот использование анимации на странице c ее автоподстройкой под камешек, это имхо немного не того. браузер ведь это покачто просто браузер искренне надеюсь что не огорчил тебя, а отдохнуть тебе надо, |
| Автор: smartov 26.12.2006, 13:44 | ||
12345c,
Ничего не понял При меньшем количестве снежинок нагрузка больше? Или что значит 17% перегрузка? Проц летит вниз со скоростью 1.17g? |
| Автор: Nicholas_S 26.12.2006, 15:07 |
| 12345c, что-то как-то... Смогешь оценить реальную загруженность процессора при всех вышеописанных нюансах? Есть еще такой нюанс: я не мог загрузить свой процессор на 100% в одном браузере при любом количестве снижинок, максимально, что показывает диспетчер, это значение 50%. Не знаю, может быть сказывается HT. |
| Автор: Sardar 26.12.2006, 16:00 |
| Core Duo (T2050) двух ядерник с 1Гб оперативы, загружаеться только одно ядро под 90% на 150 снежинках как в ИЕ6, так и в ФФ2. 12345c, это всё интересно, но главное ты не сказал, а что точно означает "среднее" и "разность"? Я так понял из текста "отставание таймера" в процентах? P.S. разработка интересная, но ИМХО скрипт не юзабелен если загружает проц более чем на 10%, следовательно практическое применение такому монитору найти сложно... |
| Автор: Nicholas_S 26.12.2006, 17:44 | ||
Sardar,
Разработка вообще занимательная, однако слишком все шатко-валко. У меня при 1000 снежинках процесс загружен на 50%... странно все это. Но я как-то упомянул в соседней теме, что реальную производительность машины мы не знаем, поэтому "отставание таймера" здесь дает только далеко приблизительную оценку. |
| Автор: 12345c 26.12.2006, 20:41 | ||||||||||||
Сразу скажу, что вычисление перегрузки процессора я ещё не получил, но она прямо следует из этих графиков. На пути к решению я сделал такой алгоритм (в http://js2.ru/example/xmp002/falling-snow-2.htm ). Вычисляем отставание таймера от часов за несколько периодов. В исследуемом скрипте это число периодов определяет время усреднения - переменная tDebug=1600 , которую затем делим на stepTime (=70) - шаг таймера. Поэтому в эксперименте был период усреднения в 22 периода таймера (если он запаздывал, то время было больше, но это детали). Далее, в программе организовали массив aDTimeN, в который пишем среднюю разность показаний часов за tDebug/stepTime (=22) периодов. Это даёт возможность сгладить всплески задержек за короткие промежутки времени. Но этого мало - надо отсечь нестабильности. Для этого вычисляем 2 числа по массиву (именно для этого понадобился массив, а не просто очередь): максимальное отставание таймера и минимальное.
smartov, поясняю на вышеизложенном дальше, что такое "17%-перегрузка". На опытах я обнаружил, что не-гекко-браузеры имеют плато на графиках перегруженности, имеющее величину примерно 16%. (Таймер запаздывает от часов на 16%.) Момент дальнейшего роста перегруженности я предложил считать точкой полной загрузки процессора (на самом деле это 70-85%. Что-то ведь надо же считать точкой загруженности? Загруженность на 100% для IE, судя по графикам, происходит в области больших отставаний таймера и никак характерно не выражается. И вот я привёл 2 числа: число снежинок, когда перегрузка - 17%, и число снежинок, когда CPU Usage=100% (для FF оно меньше). И вообще, зачем я это объясняю, ты график смотрел?  )
|
| Автор: Sardar 26.12.2006, 21:10 |
 12345c, ты бы лучше в геймдев или в разработку симуляторов подался, уж больно твои интересы чужды в мире JS'a и вообще вебтехнологий... |
| Автор: smartov 26.12.2006, 22:10 | ||
До меня просто не доходит каким макаром можно больше тормозить на меньшем количестве объектов %) |
| Автор: 12345c 26.12.2006, 22:14 |
| 17% и 100% - это к разным переменным относятся. Первое - к проценту перегруза, который вычисляется скриптом (dTimeMin+dTimeMax)*50-100, а значит, легко получим), второй - процент системной загрузки процессора, недоступный из скрипта. Написал их рядом, чтобы можно было видеть, как они соотносятся для разных бр. . |
| Автор: Nicholas_S 26.12.2006, 23:17 |
| 12345c, процессор 1-ядерный, но с технологией HT, сколько бы не увеличивал количество объектов - все равно 50%. А ты пробовал расчитывать нагрузку с отставанием таймера при мат. вычислениях, не касаясь отрисовки объектов? Если будет время+желание, посмотри, мне интересно узнать твои результаты в данном вопросе и одновременно оценить корректность в своих. |
| Автор: 12345c 27.12.2006, 18:53 |
| Nicholas_S, если подумать, то эта загрузка 50% ведёт себя как 100%, и никак не сможем определить реальное число. И не надо - интересует только способность показывать перегрузку. 2. Проверить процесс выполнения скрипта без отрисовки достаточно просто, отменив скриптовую анимацию и оставив вычисления. Только хорошо бы сначала с одной задачей разобраться, а потом "растекаться мыслью". Применить вычисления перегрузки к реальному управлению скриптом - отдельная многоплановая задача, которая на очереди. Sardar: интересно, попробуй запустить скрипт в 2 разных окнах на 2-ядерном процессоре - будет ли больше 50% загрузки. Если нет, то в 2 разных бр-рах с той же целью. Добавил к Экселю диаграмму "загрузка - перегрузка" (изв. за каламбур). Она хорошо показывает, чётко ли работает скрипт с перегрузкой. Упомянутая особенность Гекко приводит к тому, что он отрабатывает режим перегрузки идеально - диаграммы имеют вид буквы "Г". Остальные начинают запаздывание таймеров задолго до перегруженности системы, с характерными "плато". Опера-9 героически стремится к букве "Г", у неё это почти получается. ;) Итого, в не-Гекко придётся искать точку достаточной загруженности скрипта, следя за 17%-перегрузкой, наверное. |
| Автор: 12345c 28.12.2006, 20:53 | ||
| Nicholas_S, сделал эксперименты по работе скрипта изменения перегрузок только с математическими рассчётами. Заодно, оценил, какая доля работы в браузере для данного скрипта занята рассчётами, а какая - выводом изображений. Здесь особо интересных результатов нет - просто скрипт подтверждает, что анимация происходит в паузы, а рассчёты - между паузами. Поэтому в промежутках между занятостью машины рассчётами видим пустую паузу на CPU Usage, ничем не занятую. Загрузка стремится к 100%, но не достигает их. Из этого несложно оценить долю рассчётов и анимации, подобрав такое количество "виртуальных" снежинок, чтобы нагрузка стала 50%. Приведу эти цифры для разных браузеров. (Вычисления были на другой машине примерно такой же мощности и скорости памяти (Athlon 2ГГц, DDR333), но 2-мониторная, с другой видеокартой. Вероятно, поэтому, или по другой причине, Опера и IE имели особенность, что всегда имели процент отставания таймера 10% при малых нагрузках. Примерно как Опера-7 на прежних графиках, но даже при 1 "снежинке" (несуществующей) - всё равно. Как переделан скрипт. Убраны все обращения к объектам, связанным с DOM, а вместо них поставлены переменные (c,d). Таким образом, математические операторы сохранились. Образец для просмотра и экспериментов - http://js2.ru/example/xmp002/falling-snow-21a.htm . Вот основной цикл:
Таблица 50%-загрузки системы. (при числе "виртуальных" снежинок). При этом "Среднее" (процент отставания таймера) - 100, как и должно быть по описанной модели. IE6 - 480 IE7 - 2100 (вычисления значительно быстрее) Op7.54 - 2200 (но процент отставания таймера - 65. Корректирует?) Op9.01 - 1500 (при проценте отставания - 37. Её поведение на этом графике при других процентах загрузки заслуживает внимания.) FF1.07 - 1200 (процент отставания - 0. Этот точно корректно корректирует запаздывание таймера.) (Интересно, если перейти с setInterval на setTimeout, коррекция сохранится?) Смотрим на прежние графики, когда была 50%-загрузка. IE6 - 27 IE7 - 30 Op7.54 - 170 Op9.01 - 135 FF1.07 - 18 Значит, отрисовка снежинок медленнее вычислений для отрисовки (с массивами и синусами) во столько раз: IE6 - 34 IE7 - 140 Op7.54 - 24 Op9.01 - 20 FF1.07 - 130 Интереснее, конечно, 1-я таблица с реальной скоростью вычислений и 2-я с реальной скоростью отрисовки. Добавление: на 1-й (упомянутой в теме) системе замеры 50%-й загрузки показали (условных снежинок): IE6 - 750 Ie7 - 1750 Op7.54 - 1200 (из того же дистрибутива) Op8.01 - 3100 Op9.10 - 1900 FF1.07 - 1100 FF2 - 1250 |
| Автор: JSman 29.12.2006, 01:51 |
| ...мда.. вопрос не актуален.. sorry анимация сейчас лежит только на flash, редко на Java.. а скрипты уже давно не в теме.. |
| Автор: 12345c 29.12.2006, 18:26 |
| ...я так считал лет 5 назад . С ростом призводительности скриптов они могут занять скромное место в анимации. У них есть плюсы в доступности. Если отключить гиф- и флеш-анимацию, теряется только реклама и 1% непредусмотрительных флеш-деятелей. Если отключить скрипты, потеряются больше сайтов, на что немногие пойдут. Добавлено @ 18:28 (И Джаву, естественно, тоже отключают из-за глючности.) |
| Автор: JSman 31.12.2006, 19:23 |
ты совершенно прав. но в чем проблема - проблема только в дизайне сайта. анимация, которую дает флеш или java, на несколько порядков выше javascript. а если оставят лишь графику, то с помощью скриптов можно делать только примитивные некрасивые вещи  .. (то есть элементы, имеющие только практическое использование, а не дизайнерская фишка ). а анимация, которую дает javascript, используется в основном в создании многоуровнего меню или перемещении какого-либо элемента в зависимости от прокрутки страницы. а снежинки - детство..)) кстати, с Наступающим))) |
