О среднем downtime рунета

Лемма: в любой, произвольно выбранный, момент времени 1-2% сайтов Рунета не отвечают на запросы. То же относится и к серверам DNS.

Следствие: даже со скриптами бесконечной скорости, нельзя провести очередной сбор данных черного квадрата за один день. Чтобы собрать все нужно начать в понедельник и повторять ежедневно до пятницы. При этом, 98% будет собрано в понедельник.

Рунет в марте 2007 года

Выпустил в свет статью Рунет в марте 2007 года: домены, хостинг, география сайтов.

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

Краткие выводы:

  • никаких резких движений не произошло
  • сайты все больше перемещаются на хостинги с in-house
Из интересных фактов:
  • 22.7% Web-серверов - nginx
  • Мастерхост за год нарастил клиентскую базу почти втрое (остальные лидеры росли в лучшем случае чуть-чуть быстрее рынка)

Ссылочное ранжирование в Рунете

Написал очередную нетленную статью о ссылочном ранжировании в Рунете, включая покупку и продажу ссылок.

Рассмотрены:

  • общее состояние и динамика ссылочного ранжирования с главных страниц в Рунете за 2006 — начало 2007 года;
  • критерии, по которым можно отличить сайты с естественными ссылками от сайтов с платными ссылками;
  • оценена доля сайтов, занимающихся продажей ссылок, и общий оборот этого рынка.
Обсуждение лучше всего вести в комментариях к этой записи.

Программирование NVidia 8800: вести с веба

В University of Illinois at Urbana, куда я чуть было не уехал заниматься геологией 15 лет назад, в настоящее время читается курс ECE 498 AL : Programming Massively Parallel Microprocessors.

Опуская обычные охи "ну почему этому не учат на ВМК" - все в наших руках и я думаю, что через пару лет такие курсы будут и у нас, тема вкусная - хочу обратить внимание на слайды и транскрипты лекций, доступные вот тут. Читают приглашенные лекторы из NVidia, поэтому основное внимание уделено, сюрприз, NVidia 8800. Курс включает в себя лабы, которые сделаны очень интересно: есть готовая рыба, делающая подготовительную работу (I/O, печать результаты) и студент должен только написать несколько десятков-сотен строк изучаемой функциональности. Что, конечно, экономит кучу непроизводительного времени (смотреть тут)

Я успел посмотреть не все, из того что посмотрел - многое нравится, а многое не нравится:
Не нравится то, что танцы идут от предыдущего поколения видеокарт. Если говорить о программировании вообще (а все примеры - про это), а не про видеоигры, то надо забывать про шейдеры и текстурные буферы. Ведь студентов учат, которые, я надеюсь, всего этого ужаса не нюхали.

Нравится, как практику, подробный разбор аппаратуры. Вылезает множество подробностей, которые нигде не опубликованы.

Вот о подробностях - ниже.

Поисковый трафик в рунете

Берем, значит, статистику LiveInternet по всем сайтам и по пользователям из России. Для удобства, будем оперировать среднесуточными значениями за февраль.

Что мы видим:

  • Среднесуточное количество просмотров страниц: 32.7 миллиона.
  • Среднесуточная аудитория: 4.5 млн. человек.
  • Среднесуточное количество сессий: 12 млн.
Смотрим теперь статистику по переходам с поисков: количество переходов (строчка всего): 12 млн.

Получается, что 36% всех просмотров страниц - это переходы с поисковиков. Что-то много.

Считать сессии наверное неправильно: насколько я понимаю логику LiveInternet, сессией внутри раздела считается переходы между сайтами раздела. Другими словами, для сайта "все сайты" сессией будет вообще пользовательская сессия в интернете.

Понятно, что общая статистика - смещенная: там нет самых крупных сайтов Рунета (самих поисковиков, mail.ru), для ряда сайтов LiveInternet дает довольно странные цифры общей посещаемости (например, для rabota.ru: среднесуточная посещаемость по Рамблеру за февраль 620 тысяч просмотров страниц, а по LiveInternet втрое выше).

Вопрос к сообществу: верна ли оценка. А если неверна, то что я упустил ?

Рунет: растет, растет и растет.....

По результатам сбора данных для очередного выпуска черного квадрата, живых сайтов в рунете* уже более 600 тысяч**.

Полмиллиона отмечали в ноябре, значит за 4 месяца рост на 20% (т.е. более 70% годовых). Но если посмотреть на данные прошлого марта, то увидим реальный рост примерно на 60% (точно будет известно через неделю). Откуда следует, что в последние месяцы рост ускорился.

*как и всегда в черном квадрате, когда я пишу в рунете я имею в виду длинную формулировку сайты domain.tld или www.domain.tld, где domain.tld — домен 2-го уровня в .RU и .SU.

**на самом деле, в понедельник наскребется еще несколько тысяч, в выходные лежит обычно пара процентов сайтов.

Upd: Как и обещал, к вечеру понедельника их стало 605 тысяч. Ну не несколько процентов, а полпроцента. Но несколько тысяч.

NVidia 8800GTX: скорость чтения текстур

В предыдущей части мы рассматривали чтение из глобальной памяти Geforce 8800 напрямую ("как из массива C"). При этом отсутствует кэширование, но при оптимальной схеме доступа получается (согласно указаниям NVidia) наибольшая производительность.

В то же время, скорость доступа при неоптимальном паттерне очень маленькая. Для решения этой проблемы (помимо оптимизации паттерна) NVidia CUDA предлагает доступ к памяти как к текстуре. При этом работает двумерное кэширование (оптимизированное под локальный доступ), пиковые скорости должны получаться меньше, а наихудшие варианты - наоборот лучше.

Все это, как обычно, нуждается в изучении.

NVidia 8800GTX: пропускная способность памяти (при использовании CUDA)

После чтения руководства по NVidia CUDA, остается ощущение сложности модели программирования: треды, блоки тредов, warp-ы, иерархическая память. Непонятно, какие параметры вычислительной задачи оптимальны и какие у них вообще допустимые значения. Само руководство точных рекомендаций не дает, дает лишь приблизительные.

Из общих соображений, понятно что самая медленная часть суперкомпьютера - память. С одной стороны, теоретическая пропускная способность (bandwidth) составляет 900MHz * 384 бита * 2 (DDR) = 86.4 GB/sec. С другой стороны, раздел 6.1.1.3 руководства говорит о 200-300 циклах memory latency (при, по всей видимости,случайном доступе).

К счастью, проблема легко изучается: если взять достаточно много данных (скажем, полгигабайта) и, например, сложить все 4-байтовые значения (как float), то основные затраты времени будут именно на чтение из памяти, а всей прочей арифметикой можно пренебречь (или подсчитать ее отдельно).

Читая веб и блоги: CUDA и прочее программирование на NVidia 8800

На удивление мало жизни происходит по запросу 'NVidia CUDA' в поиске по блогам и новостям. Что у Яндекса, что у Google. Мне это сильно удивительно - штука многообещающая, первая версия SDK датирована ноябрем (появилась примерно 1-го декабря), публичный SDK появился практически месяц назад, а большинство упоминаний в духе "вот вышло", в крайнем случае "читал доку". Таких текстов - навалом, маркетинг NVidia работает. Но скучно.

Помимо форумов NVidia, где заводится по 5-6 новых топиков в день, интересных публикаций немного.

Для начала: Beyond3D опубликовал большой текст про CUDA. Более подробный, чем все что я видел до сих пор (ну, кроме собственно документации).

NVidia CUDA: синхронизация и shared memory

Экспериментально выяснилось, что содержимое shared memory не сохраняется между запусками кода на G80. Всякий раз оно инициализировано, причем значения разные, то 10 (float), то 125.

Плакала идея синхронизации между мультипроцессорами путем завершения kernel. Нет, синхронизироваться можно, конечно, но если хочется сохранить результат, то надо писать в глобальную память.

Класса люкс

Второй год хожу мимо, наконец сподобился сфотографировать.

_MG_1084-1.jpg

Читая форумы: NVidia 8800GTX гигафлопсы, консистентность памяти и прочие тараканы

Третий день читаю форумы про NVidia CUDA и радуюсь сырости технологии.

  • Для начала, объявленные 520 GFLOP/s оказались обычным маркетингом The 520 GFLOPS number quoted in the technical brief includes some graphics-specific operations that are not directly accessible from CUDA. С точки зрения вычислений, гигафлопсов там 345 (считая Multiply-Add за две операции). Тоже неплохо. В реальности будет разика в два поменьше, но тоже ничего.
    Для сравнения, гипотетический (пока) 3Ghz 4-ядерный Core2Duo умеет 8 операций на такт * 4 ядра * 3Ghz = 96 GFLOP/s, а получить удастся процентов 70 от этого.
  • Отсутствие атомарных операций сильно усложняет жизнь. Предлагается в цикле писать значение в global memory, до тех пор пока не убедишься в успехе.
  • На текущий момент все вызовы - блокирующие. Т.е. нет возможности
    • Запустить счет и одновременно заливать/выливать данные для следующего/предыдущего счета.
    • Использовать две (и более) карт
    Обещают починить.
  • The performance gain you'll get by using CUDA over the graphics API largely depends on how much your application can take advantage of the shared memory. В-общем, идея понятная, но полностью противоречит всей прошлой истории GPGPU. Может оно и хорошо

Pages

Subscribe to blog.lexa.ru: все статьи