The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Разработчики Mozilla столкнулись с проблемой производительно..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от opennews on 26-Июн-10, 00:46 
Разработчики проекта Mozilla опубликовали (http://gcc.gnu.org/ml/gcc/2010-06/msg00715.html) уведомление, в котором приводятся факты значительного падения производительности Firefox при его сборке в GCC 4.5. Проблемы были обнаружены после попытки перехода для сборки Linux-версии браузера с GCC 4.3 на GCC 4.5, после чего автоматизированные тесты выявили падение производительности браузера на 4-19%, как в 32-разрядном, так и в 64-разрядном варианте.


Убедиться в справедливости заявления может любой желающий, достаточно проверить скорость прохождения JavaScript-теста Sunspider, при сборке Firefox в GCC 4.5, тест показывает на 8% более низкие показатели при прочих равных условиях. Переход на GCC 4.5 был связан с плагинами и возможностью сборки с PGO (profile-guided optimization) . После обнаружения регрессии, разработчики Mozilla отменили свое решение о переходе на сборку с использованием GCC 4.5.


В ответ на заявление, один из разработчиков GCC подчеркнул (http://gcc.gnu.org/ml/gcc/2...

URL: http://www.phoronix.com/scan.php?page=news_item&px=ODM2NQ
Новость: http://www.opennet.me/opennews/art.shtml?num=27104

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Разработчики Mozilla столкнулись с проблемой производительно..."  +4 +/
Сообщение от qwerty44 on 26-Июн-10, 00:46 
настоящие индейцы и так собирают firefox с -O3
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от User294 (ok) on 27-Июн-10, 15:24 
А это не они потом оглашают прерии воплями по поводу грабель которых больше ни у кого нет? :)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

52. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Taliban on 30-Июн-10, 10:47 
в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Разработчики Mozilla столкнулись с проблемой производительно..."  +16 +/
Сообщение от Аноним (??) on 26-Июн-10, 00:58 
Новость ни о чём.

P.S. Ну пусть сделают ключ --please-use-inline-functions-even-with-dash-Os.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

43. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Alex (??) on 27-Июн-10, 16:49 
-use-inlining-in-Os-for-mozilla-braindead-distmakers

Fixed.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

49. "Разработчики Mozilla столкнулись с проблемой производительно..."  +3 +/
Сообщение от God on 28-Июн-10, 11:32 
--God-please-make-may-program-very-fast
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от FPGA (ok) on 26-Июн-10, 01:24 
Ха! Впервые вижу чтобы жаловались на скорость когда юзают -Os, просто смех!..
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от Michael Shigorin random on 26-Июн-10, 10:23 
"Ах, сколько нам открытий чудных"... ;)
Просто Вы ещё тоже многого не видели, довод про кэш справедлив.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Аноним (??) on 26-Июн-10, 02:17 
Скажите им, чтобы попробовали clang
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от Аноним (??) on 26-Июн-10, 03:49 
OMG. Классный довод, про кеш. Ну пусть попробуют -O3, -O2, -flto там. :)
Написать чтоль им об этом.:)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Разработчики Mozilla столкнулись с проблемой производительно..."  +10 +/
Сообщение от iZEN (ok) on 26-Июн-10, 15:14 
"120 миллионов точно знают, как играть в футбол, в отличие от тех 22-х на футбольном поле" ©
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

48. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Аноним (??) on 28-Июн-10, 10:44 
Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от Vladimir (??) on 26-Июн-10, 05:00 
Уважаемые участники

есть ли у кого-нибудь конкретные примеры программ, скомпилированными с GCC 4.5, но которые не могли после этого работать?

(У меня только два примера: emacs и dvisvgm, со вторым совсем глухо, для первого есть "обходной" манёвр).

Похоже разработчики mozilla открыли ещё одну новую "фичу" GCC серии 4.5

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от Аноним email(??) on 26-Июн-10, 09:50 
> emacs

несколько месяцев собираю emacs из bzr (trunk) с помощью gcc45 + -flto + gold на freebsd. Не замечал никаких проблем в runtime'е.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Aquarius (ok) on 26-Июн-10, 15:00 
такого рода "фич" полно в каждой ветке GCC
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от аноним on 26-Июн-10, 16:14 
Нету, у меня все собирается gcc45, никаких проблем.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от Аноним (??) on 26-Июн-10, 16:52 
У меня qt-webkit, собранный gcc-4.5, приводит к краху Arora, qutim, и даже qt-creator при просмотре документации.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от DFX (ok) on 26-Июн-10, 07:12 
а собирать с "-Os -finline-functions" не катит ? или оно прямо-таки сопротивляется и забивает ?

жаль вот с gcc 4.5 куча софта в мире генты, когда с флагом -flto/-fwhopr, не связывается после сборки :(
без него, правда, только два вышенаписанных примера выделываются, и то несчастное брошенное чудо, вроде ksquirrel и openastromenace, что с 4.4 или 4.3 не собиралось.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Аноним (??) on 26-Июн-10, 07:35 
Друзья, кто-нибудь может разъяснить, почему в релизной сборке Мозиллой не используется -O3? И почему даже разработчик GCC посоветовал -O2?

Я кроме увеличения времени сборки (одноразового, к тому же) проблем не вижу. Наверное, я чего-то не понимаю?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от anonymous (??) on 26-Июн-10, 08:39 
при -O3 размер исполняемого кода получается больше.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Аноним (??) on 26-Июн-10, 09:54 
> при -O3 размер исполняемого кода получается больше.

не намного больше чем по сравнению с -funroll-loops. Скорее всего боятся -ftree-vectorize.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от ws (ok) on 26-Июн-10, 10:22 
Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
с -02 - к работе замечаний нет, но по сравнению с -Os субъективно работает медленее, хотя должно наоборот.
ИМХО, объясняется это меньшим требованием к памяти (кеш цпу в том числе). Ведь скорость выполнения команд процессора сейчас увеличилось намного больше (особенно если кусок исполняемого кода сидит в кеше), чем скорость доступа к ячейки памяти по сравнению с предыдущими поколениями...

p/s: Тестировал года 1,5-2 назад на E6750, RAM 2G, HDD Hitachi 500G на текущем срезе генты.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от bircoph on 26-Июн-10, 12:49 
> Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
> с -02 - к работе замечаний нет

x86, по-видимому?
Добавь -fno-tree-vectorize это известный баг gcc:
https://bugs.gentoo.org/show_bug.cgi?id=270120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156

У меня так три мира собрано, проблем нет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от ws (ok) on 26-Июн-10, 16:57 
>> Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
>> с -02 - к работе замечаний нет
>
>x86, по-видимому?

да

>Добавь -fno-tree-vectorize это известный баг gcc:
>https://bugs.gentoo.org/show_bug.cgi?id=270120
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156

Возможно такого рода и был баг (я сильно не вникал в эту проблему), но я пробовал еще на 4.3 или даже 4.1 ветке (я пользуюсь стабильной веткой для toolchains).
Но я остановился на -Os. Т.к. главное в десктопном компе не быстродействие ЦПУ, а доступность большего объема памяти. А в итоге скорость работы с программами оказалась выше для -Os чем для -O2 или -O3.

Вот мои опции ключики для gcc
CFLAGS="-pipe -march=core2 -Os -mfpmath=sse,387 -frename-registers -ftree-vectorize -finline-functions -Wno-error "
CXXFLAGS="${CFLAGS} -finline-limit=1000 -fpermissive"
LDFLAGS="-Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-O1"

Кстати еще одно объяснение быстрого выполнения программ для -Os это время считывания ее с HDD.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "Разработчики Mozilla столкнулись с проблемой производительно..."  –1 +/
Сообщение от аноним on 26-Июн-10, 16:15 
>субъективно работает медленее, хотя должно наоборот

Субъективно своё знаете куда можете?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от ws (ok) on 26-Июн-10, 19:42 
>>субъективно работает медленее, хотя должно наоборот
>
>Субъективно своё знаете куда можете?

Моя субъективность очень совпадает с реальностью Mozilla Team...  :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Разработчики Mozilla столкнулись с проблемой производительно..."  –1 +/
Сообщение от Аноним (??) on 26-Июн-10, 08:06 
>режим оптимизации по размеру исполняемого кода в ущерб скорости

Интересная опция. Какая же это оптимизация тогда? В чем она заключается? в падении скорости? :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от Alen (??) on 26-Июн-10, 08:20 
Вот сразу видно, что человек писатель, а не читатель :)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от anonymous (??) on 26-Июн-10, 08:23 
>Какая же это оптимизация тогда? В чем она заключается?

русским языком же написано: "оптимизация по размеру". оптимизируют не только скорость.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

34. "Разработчики Mozilla столкнулись с проблемой производительно..."  –1 +/
Сообщение от Zenitur email on 26-Июн-10, 17:01 
Если все оптимизации убрать, то собираться будет быстро, а работать - медленно.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от User294 (ok) on 28-Июн-10, 12:46 
> Интересная опция. Какая же это оптимизация тогда? В чем она заключается?
> в падении скорости? :)

Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. В случае реального процессора - как видим не все так просто: более компактный код имеет больше шансов целиком влезть в кеш, и невзирая на то что в сумме будет выполнено как бы больше инструкций (N раз отработает не только тело цикла но и переходы на начало оного и анализ условий), они будут подтянуты не из тормозной в плане латентности оперативы, а из резвого кеша и ... можно даже и выиграть, как видим. Лишь бы код в кеш лез. По факту - соотношение сил еще и определяется соотношением латентностей и бандвиза кеша и оперативы. Что наверняка доставляет авторам компилеров и просто тем кому надо тотальный максимум скорости любой ценой, т.к. все это еще и нихрена не константа и в камне не выбито :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 04-Июл-10, 13:42 
В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

56. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от User294 (ok) on 07-Июл-10, 15:18 
Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от Роман (??) on 26-Июн-10, 12:54 
>Представители Mozilla ответили, что сборка с опцией "-Os" производится, так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"

Нда... а почему ж тогда отошли от "исторических" традиций использования gcc 4.3?
Непоследовательно как-то...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Роман (??) on 26-Июн-10, 12:56 
>так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"

Если так, то это был исторический _баг_ в старых gcc, исправленный в 4.5. А они  ещё жалуются.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от Sem (??) on 27-Июн-10, 01:57 
Включите мозг наконец! Это не баг. Что включать в -Os, а что нет, это мнение разработчиков gcc. Для таких крупных проектов как Mozilla, разница в размере с -Os и -O2 может быть очень существенной. А вот то, что, похоже, -Os -finline-functions не срабатывает, это не хорошо, это гораздо больше похоже на баг.

Лучше бы PGO обсудили )

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Разработчики Mozilla столкнулись с проблемой производительно..."  –1 +/
Сообщение от аноним on 26-Июн-10, 16:13 
Это идиотизм, как и -Os в принципе - нужно это разве что для всякого embedded и никакой производительности не гарантирует и не должно.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Sem (??) on 27-Июн-10, 02:15 
>Это идиотизм, как и -Os в принципе - нужно это разве что
>для всякого embedded и никакой производительности не гарантирует и не должно.
>

Идиотизм - это делать опальные заявления.
В идеале, это конечно так и есть, но когда у тебя проект больше чем на 7 млн. строк, то тут уж крутишься как получится.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от аноним on 26-Июн-10, 16:17 
Нормальным системам (FreeBSD как минимум) пофиг - там все собирается с теми флагами, которые я сказал, а не с тем что исторически сложилось у криворуких разработчиков.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

46. "Разработчики Mozilla столкнулись с проблемой производительно..."  +2 +/
Сообщение от i (??) on 28-Июн-10, 10:23 
причем здесь вы и разработчики мозиллы? и когда это фрибсд стала нормальной/по сравнению с чем, системой?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от User294 (ok) on 28-Июн-10, 21:43 
> Нормальным системам (FreeBSD как минимум) пофиг

В "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Имя123321 on 26-Июн-10, 16:42 
> В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии,

в чём же регрессия, если стало только лучше? с -Os стало меньше памяти, как и планировали

в Мозиле всё больше и больше вендо-маразма.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от kramer (??) on 27-Июн-10, 11:55 
gcc is dead
use clang\llvm - true free BSDL
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Alex (??) on 27-Июн-10, 16:52 
>gcc is dead
>use clang\llvm - true free BSDL

your brain is dead. use calc - true helper for those without brain

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от Аноним (??) on 28-Июн-10, 05:22 
> В итоге, проблема оказалась связана с прекращением в GCC 4.5 inline-развертывания кода в режиме "-Os", что и приводит к замедлению выполнения. В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии

Глупость какая-то несусветная, как я же это регрессия? Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "Разработчики Mozilla столкнулись с проблемой производительно..."  +/
Сообщение от const86 (ok) on 28-Июн-10, 10:24 
> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.

Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если встраиваемая функция совсем маленькая, то может получиться и без общего увеличения кода.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

55. "Разработчики Mozilla столкнулись с проблемой производительно..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 04-Июл-10, 13:45 
>> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
>
>Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если
>встраиваемая функция совсем маленькая, то может получиться и без общего увеличения
>кода.

Более того, при встраивании оптимизация прогоняется по всей результирующей функции, и там могут вылезти очевидные лишь для компилятора закономерности, которые он тоже сможет сократить (например, убрав лишние проверки или присваивания).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

53. "Разработчики Mozilla столкнулись с проблемой производительно..."  –1 +/
Сообщение от Alex (??) on 03-Июл-10, 10:16 
У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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