Возможно, что качество возрастет, если иначе получить 1 бит из каждого отсчета, например, принимая за 0 отклонение значения в данном отсчете от среднего значения в данном окне/фрейме в меньшую сторону, и за 1 — отклонение значения отсчета от среднего значения для окна/фрейма в большую сторону.
Идея интересная, но не в таком виде. Глобальное мнение произвольных людей о странице не интересно, если эта страница мало-мальски популярная — это будет спам и флейм. Интересно мнение определенной категории людей, например, специалистов в данной области. Или еще какой-то выделенной группы. Поэтому люди и пользуются тематическими форумами, устоявшимися community в социальных сетях и т.п. Чтобы читать не мнения рандомных людей, а мнения вполне конкретной группы людей.
К тому же известно, что многие пользователи используют один и тот же пароль на большинстве сайтов. Если сайт хранит у себя пароли, то его взлом позволит злоумышленникам получить доступ к данным пользователей на куче других сайтов, вполне вероятно — откроет доступ к e-mail этих пользователей.
Зачем пользователю знать:
— местоположение хостинга,
— разработчика сайта.
И много ли сайтов, у которых отличаются владелец домена и собственно владелец сайта? Если речь идет о поддоменах каких-нибудь больших платформ типа LJ, то в этом случае владелец домена очевиден.
Основной браузер — это вообще полный п-ц, сайты не должны быть заточены под конкретный браузер. Разумней указать просто минимальную версию для разных браузеров не выделяя среди них один.
Время загрузки страниц — с локальной машины что ли? Оно же разное из разных частей света, в разное время суток и года… :)
Объем сайта — как поддерживать актуальность этой информации и чему равен объем сайта, использующего СУБД с данными на отдельных томах?
Количество гиперссылок, файлов — кого это вообще интересует? И как подсчитаете количество гиперссылок на каком-нибудь facebook.com или myspace.com?
Согласен, что при таких скоростях куча проблем. Например, при попытках создать схемы работающие на реально огромных частотах уже приходится учитывать эффекты, связанные с волновой природой электромагнитного излучения. Раньше можно было это игнорировать.
Да, для раздачи IP обычным потребителям необходимость разделения на много потоков не принципиальна. Но возможность коммутации высокоскоростных потоков прямо на уровне оптики помогла бы для организации шин в суперкомпьютерах и в тех же router/switch.
Можно даже сказать от какой именно частоты это пошло — от пресловутых 8KHz и G.711, которые в сумме дают 64000 битов в секунду (bearer channel), которыми, в свою очередь, перемерены практически все магистральные каналы.
Интересные новые результаты! Если я правильно понимаю — они добились передачи данных на терабитной скорости без WDM (потому, что системы со спектральным уплотнением уже давно достигли этой скорости).
Кстати, в этой области есть много интересных направлений для дальнейшей работы.
Одна важная и еще полностью не решенная проблема — роутинг данных идущих на таких скоростях. Эта проблема сдерживает широкое внедрение высокоскоростных оптических каналов. В основном они используются для агрегации кучи намного более медленных каналов и последующей переброски их всех вместе из одной фиксированной точки в другую фиксированную точку, где медленные каналы снова расщепляются на низкоскоростные и раздаются обычным потребителям. Было бы хорошо, если бы появилась практическая возможность маршрутизации пакетов в оптической сети на полной ее скорости.
Вторая известная проблема — это дороговизна и экзотичность решений, позволяющих процессорному блоку обмениваться данными с оптической сетью на полной скорости. Intel, AMD, IBM и другие вкладывают очень большие средства в разработку дешевых решений для того, чтобы вывести по оптике данные из CPU — но пока что эти технологии еще плохо отработаны и дороги для массового внедрения. Однако за ними будущее, интерконнект через медные провода достиг своего предела.
Если сайта еще нет, то лучше написать его на том языке, на котором вашей команде удобней работать, а затем уже поэтапно решать проблемы производительности. Исключение из этого правила — случай, когда в обработке огромной нагрузки вся соль вашего проекта или если у вас изначально есть серьезная уверенность, что сразу же будет ОГРОМНЫЙ наплыв посетителей.
Если вам удобнее писать на C[++] — пишите на нем, таково мое мнение. Неудобно — пишите изначальную версию сайта («прототип») на скриптовых языках.
Если это не учебная задача, а реальный коммерческий проект, то при выборе языка определяющую роль играет, по моему мнению, команда программистов или перспективы по ее найму. Я не думаю, что имеющимся в вашем распоряжении программистам абсолютно пофик на чем писать — на C++ или на PHP (для примера). За редким исключением это люди с разной квалификацией (которую не стоит сравнивать напрямую, так как это разные типы языков и подходы к программированию). Это, как правило, люди с разным подходом к решению задач, с разными взглядами на “правильное” программирование. Если говорить о сформировавшихся специалистах. И поэтому, если проект делает не один человек (вы сами), то у вас вряд ли будет возможность свободно выбирать язык программирования — не задумываясь о возможностях имеющихся программистов или о перспективах по их найму (и о зарплатах для них).
Так же я уверен, что полностью тупиковый путь пытаться отдать часть работ по сайту, разрабатываемому на C++, фрилансерам или аутсорсить часть проекта внешней команде. В случае же использования «стандартных» для web подходов и скриптовых языков программирования можно часть работы отдать другой команде.
А теперь предположим, что поддержка очень высокой нагрузки с самого начала — это критическое условие для проекта. В этом случае нужно разбираться конкретно и индивидуально для каждого конкретного проекта, где именно в нем «бутылочное горло» и как его можно устранить. Не факт, что тут поможет смена языка программирования.
Например, если у вас главная сложность в содержательно высокой нагрузке на СУБД, то какая, собственно, разница, сколько микросекунд уйдет на компоновку страницы в C-программе, пока основное время теряется в глубинах СУБД? Тут проблема не на чем писать обработчики страниц/динамических запросов, а как можно ускорить базу. Можно, конечно, и от «стандартной» СУБД отказаться, всю работу перенеся в свой engine. Но это уже получается очень нетривиальный проект. Мне лично такие проекты нравятся, но только когда в них есть реальная потребность. И я понимаю, что это стоит ОЧЕНЬ больших денег и главное — потребует уйму времени.
Если же дело не в пропускной способности СУБД или TCP/IP стека, а именно в компоновке страниц, всяком парсинге, возможности “легковесного” кэширования (для которого есть возможность) и т.п., то тогда, конечно, использовать C[++] разумная идея. Можно использовать какой-то легковесный сервер (не apache) или «заготовку» сервера, которая принимает HTTP-запросы и отдает их вашей программе. Для того, чтобы не писать самим и не отлаживать высокопроизводительный модуль приема/раздачи данных по TCP и парсер HTTP. Но, конечно, если есть время, то можно заняться и этим, глядя на исходники лучших open source серверов как на пример хорошей и вылизанной годами реализации.
Согласен, что без отсылки к существующей реальности и конкретному процессору (типа x86) этот пример не может быть разобран по существу и согласен с тем, что абстрактно (без жесткой необходимости выжать последние такты и без учета специфики железа) такой стиль программирования вообще некорректен и логическим образом ведет к разнообразным ловушкам. Но, как я понимаю, автор примера хотел бы получить конкретное объяснение причины некорректного поведения программы конкретно на x86.
По Вашим комментариям:
1. Обращения к переменным, объявленным как volatile, не должны переставляться за пределами sequence point по стандарту языка C. В этом примере все важные переменные описаны как volatile.
2. Просто чтение или запись volatile на всех существующих mainstream процессорах это действительно одна команда. Не путать с операциями типа x++.
Отдаю должное тщательности подбора примера. Будь там хоть одна lock-операция между записью и чтением — и ошибка исчезла бы. А так получился пример, к которому не подкопаться ссылкой на компилятор. На x86 чтение/запись volatile переменной происходит одной командой и поэтому проблема не в компиляторе, а именно в логической перестановке записи и чтения на SMP.
На x86 проблемы возможны с любым реальным компилятором, так как они идут от возможности reorder-а команды записи и команды чтения на SMP/при нескольких ядрах.
Задача тривиальна для тех, кто знает про memory barriers, как тут уже сказали многие люди выше. Народу просто лень разбираться в деталях, что именно там происходит. И это понятно — ошибка уже в самом факте написания подобного кода.
Но, так как я много раз сталкивался с проблемой memory barriers, то скажу, в чем тут конкретно дело. Дело в том, что на x86 в SMP-режиме отсутствует (на современных вариантах процессоров) один-единственный, но очень важный «классический» барьер — между записью и последующим чтением. WR-барьер, не путать с RW-барьером (хотя не люблю вообще эту терминологию «барьеров» a-la Linux Kernel, так как она не отражает всего многообразия современных средств синхронизации в CPU).
В результате чтение aa[tt] и bb[tt] в операторах test_aa[tt] = aa[tt] и test_bb[tt] = bb[tt] может быть выполнено раньше записи bb[tt] = 1 и aa[tt] = 1 (соответственно). Фактически команда записи может формально выполниться раньше (на уровне очередей в ядре CPU), но записанные данные не уйдут в реальную память, задержавшись в буфере записи или в кэше. Поэтому и возникает ситуация, что оба элемента test_aa[tt] и test_bb[tt] равны нулю.
Эта ситуация действительно принципиальна и не зависит от компилятора.
Вам повезло, что Вы имеете дело с процессорами x86, на которых нет конфликтов вида RR, WW, RW (если не брать старые процессоры типа Pentium Pro или варианты программирования памяти в out-of-order stores режиме). Для PowerPC, например, можно придумать гораздо более сложные ситуации. Там все еще более запущено, например:
int volatile a = 0;
int volatile sync = 0;
Thread1:
a = 1;
sync = 1;
Thread2:
while (sync == 0) {};
printf(“a = %u\n”, a);
К реальной жизни гораздо ближе обратная задача — вычислить что-то подобное без использования сравнений и команд перехода (на арифметике, сдвигах и логических операциях).
— местоположение хостинга,
— разработчика сайта.
И много ли сайтов, у которых отличаются владелец домена и собственно владелец сайта? Если речь идет о поддоменах каких-нибудь больших платформ типа LJ, то в этом случае владелец домена очевиден.
Основной браузер — это вообще полный п-ц, сайты не должны быть заточены под конкретный браузер. Разумней указать просто минимальную версию для разных браузеров не выделяя среди них один.
Время загрузки страниц — с локальной машины что ли? Оно же разное из разных частей света, в разное время суток и года… :)
Объем сайта — как поддерживать актуальность этой информации и чему равен объем сайта, использующего СУБД с данными на отдельных томах?
Количество гиперссылок, файлов — кого это вообще интересует? И как подсчитаете количество гиперссылок на каком-нибудь facebook.com или myspace.com?
Кстати, в этой области есть много интересных направлений для дальнейшей работы.
Одна важная и еще полностью не решенная проблема — роутинг данных идущих на таких скоростях. Эта проблема сдерживает широкое внедрение высокоскоростных оптических каналов. В основном они используются для агрегации кучи намного более медленных каналов и последующей переброски их всех вместе из одной фиксированной точки в другую фиксированную точку, где медленные каналы снова расщепляются на низкоскоростные и раздаются обычным потребителям. Было бы хорошо, если бы появилась практическая возможность маршрутизации пакетов в оптической сети на полной ее скорости.
Вторая известная проблема — это дороговизна и экзотичность решений, позволяющих процессорному блоку обмениваться данными с оптической сетью на полной скорости. Intel, AMD, IBM и другие вкладывают очень большие средства в разработку дешевых решений для того, чтобы вывести по оптике данные из CPU — но пока что эти технологии еще плохо отработаны и дороги для массового внедрения. Однако за ними будущее, интерконнект через медные провода достиг своего предела.
Если вам удобнее писать на C[++] — пишите на нем, таково мое мнение. Неудобно — пишите изначальную версию сайта («прототип») на скриптовых языках.
Если это не учебная задача, а реальный коммерческий проект, то при выборе языка определяющую роль играет, по моему мнению, команда программистов или перспективы по ее найму. Я не думаю, что имеющимся в вашем распоряжении программистам абсолютно пофик на чем писать — на C++ или на PHP (для примера). За редким исключением это люди с разной квалификацией (которую не стоит сравнивать напрямую, так как это разные типы языков и подходы к программированию). Это, как правило, люди с разным подходом к решению задач, с разными взглядами на “правильное” программирование. Если говорить о сформировавшихся специалистах. И поэтому, если проект делает не один человек (вы сами), то у вас вряд ли будет возможность свободно выбирать язык программирования — не задумываясь о возможностях имеющихся программистов или о перспективах по их найму (и о зарплатах для них).
Так же я уверен, что полностью тупиковый путь пытаться отдать часть работ по сайту, разрабатываемому на C++, фрилансерам или аутсорсить часть проекта внешней команде. В случае же использования «стандартных» для web подходов и скриптовых языков программирования можно часть работы отдать другой команде.
А теперь предположим, что поддержка очень высокой нагрузки с самого начала — это критическое условие для проекта. В этом случае нужно разбираться конкретно и индивидуально для каждого конкретного проекта, где именно в нем «бутылочное горло» и как его можно устранить. Не факт, что тут поможет смена языка программирования.
Например, если у вас главная сложность в содержательно высокой нагрузке на СУБД, то какая, собственно, разница, сколько микросекунд уйдет на компоновку страницы в C-программе, пока основное время теряется в глубинах СУБД? Тут проблема не на чем писать обработчики страниц/динамических запросов, а как можно ускорить базу. Можно, конечно, и от «стандартной» СУБД отказаться, всю работу перенеся в свой engine. Но это уже получается очень нетривиальный проект. Мне лично такие проекты нравятся, но только когда в них есть реальная потребность. И я понимаю, что это стоит ОЧЕНЬ больших денег и главное — потребует уйму времени.
Если же дело не в пропускной способности СУБД или TCP/IP стека, а именно в компоновке страниц, всяком парсинге, возможности “легковесного” кэширования (для которого есть возможность) и т.п., то тогда, конечно, использовать C[++] разумная идея. Можно использовать какой-то легковесный сервер (не apache) или «заготовку» сервера, которая принимает HTTP-запросы и отдает их вашей программе. Для того, чтобы не писать самим и не отлаживать высокопроизводительный модуль приема/раздачи данных по TCP и парсер HTTP. Но, конечно, если есть время, то можно заняться и этим, глядя на исходники лучших open source серверов как на пример хорошей и вылизанной годами реализации.
По Вашим комментариям:
1. Обращения к переменным, объявленным как volatile, не должны переставляться за пределами sequence point по стандарту языка C. В этом примере все важные переменные описаны как volatile.
2. Просто чтение или запись volatile на всех существующих mainstream процессорах это действительно одна команда. Не путать с операциями типа x++.
Но, так как я много раз сталкивался с проблемой memory barriers, то скажу, в чем тут конкретно дело. Дело в том, что на x86 в SMP-режиме отсутствует (на современных вариантах процессоров) один-единственный, но очень важный «классический» барьер — между записью и последующим чтением. WR-барьер, не путать с RW-барьером (хотя не люблю вообще эту терминологию «барьеров» a-la Linux Kernel, так как она не отражает всего многообразия современных средств синхронизации в CPU).
В результате чтение aa[tt] и bb[tt] в операторах test_aa[tt] = aa[tt] и test_bb[tt] = bb[tt] может быть выполнено раньше записи bb[tt] = 1 и aa[tt] = 1 (соответственно). Фактически команда записи может формально выполниться раньше (на уровне очередей в ядре CPU), но записанные данные не уйдут в реальную память, задержавшись в буфере записи или в кэше. Поэтому и возникает ситуация, что оба элемента test_aa[tt] и test_bb[tt] равны нулю.
Эта ситуация действительно принципиальна и не зависит от компилятора.
Вам повезло, что Вы имеете дело с процессорами x86, на которых нет конфликтов вида RR, WW, RW (если не брать старые процессоры типа Pentium Pro или варианты программирования памяти в out-of-order stores режиме). Для PowerPC, например, можно придумать гораздо более сложные ситуации. Там все еще более запущено, например:
иногда напечатает a = 0.