Все-таки далеко зашел прогресс. Принтер формата А2 один человек может донести от машины до лифта, поднявшись на два пролета по лестнице. И никакой грыжи.
Понравилось:
Родные профили (для Epson-овских бумаг, естественно) - вполне приличного качества.
Печать ч-б фото выше всяких похвал: абсолютная нейтральность, отличное разделение теней (L=2 от L=1 отличается !)
размеры и вес: принтер встал на место Canon S9000 (который A3). Нет, он пошире сантиметров на 10 и повыше, полки в шкафу пришлось переставлять, ну и все.
Удивляет:
профили для разных бумаг (Premium Glossy и Semigloss; Archival Matte и Velvet) имеют одинаковый до копейки охват. Надо при случае перестроить.
Не нравится:
Видно, что экономили каждую копеечку. Скажем защелка передней панели - плохая, пришлось туда пару магнитиков приклеить на Моменте.
Ну и то, что переключение с Photo Black на Matte Black стоит примерно $2 - тоже нравится не может :)
Лемма: в любой, произвольно выбранный, момент времени 1-2% сайтов Рунета не отвечают на запросы. То же относится и к серверам DNS.
Следствие: даже со скриптами бесконечной скорости, нельзя провести очередной сбор данных черного квадрата за один день. Чтобы собрать все нужно начать в понедельник и повторять ежедневно до пятницы. При этом, 98% будет собрано в понедельник.
Опуская обычные охи "ну почему этому не учат на ВМК" - все в наших руках и я думаю, что через пару лет такие курсы будут и у нас, тема вкусная - хочу обратить внимание на слайды и транскрипты лекций, доступные вот тут. Читают приглашенные лекторы из NVidia, поэтому основное внимание уделено, сюрприз, NVidia 8800. Курс
включает в себя лабы, которые сделаны очень интересно: есть готовая рыба, делающая подготовительную работу (I/O, печать результаты) и студент должен только написать несколько десятков-сотен строк изучаемой функциональности. Что, конечно, экономит кучу
непроизводительного времени (смотреть тут)
Я успел посмотреть не все, из того что посмотрел - многое нравится, а многое
не нравится: Не нравится то, что танцы идут от предыдущего поколения видеокарт. Если говорить о программировании вообще (а все примеры - про это), а не про видеоигры, то надо забывать про шейдеры и текстурные буферы. Ведь студентов учат, которые, я надеюсь, всего этого ужаса не нюхали.
Нравится, как практику, подробный разбор аппаратуры. Вылезает множество подробностей, которые нигде не опубликованы.
Получается, что 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 тысяч. Ну не несколько процентов, а полпроцента. Но несколько тысяч.
В предыдущей части мы рассматривали чтение из глобальной памяти Geforce 8800 напрямую ("как из массива C"). При этом отсутствует кэширование, но при оптимальной схеме доступа получается (согласно указаниям NVidia) наибольшая производительность.
В то же время, скорость доступа при неоптимальном паттерне очень маленькая. Для решения этой проблемы (помимо оптимизации паттерна) NVidia CUDA предлагает доступ к памяти как к текстуре. При этом работает двумерное кэширование (оптимизированное под локальный доступ), пиковые скорости должны получаться меньше, а наихудшие варианты - наоборот лучше.
После чтения руководства по NVidia CUDA,
остается ощущение сложности модели программирования: треды, блоки тредов, warp-ы, иерархическая память.
Непонятно, какие параметры вычислительной задачи оптимальны и какие у них вообще допустимые значения.
Само руководство точных рекомендаций не дает, дает лишь приблизительные.
Из общих соображений, понятно что самая медленная часть суперкомпьютера - память. С одной стороны,
теоретическая пропускная способность (bandwidth) составляет 900MHz * 384 бита * 2 (DDR) = 86.4 GB/sec.
С другой стороны, раздел 6.1.1.3 руководства говорит о 200-300 циклах memory latency (при, по всей видимости,случайном доступе).
К счастью, проблема легко изучается: если взять достаточно много данных (скажем, полгигабайта) и, например,
сложить все 4-байтовые значения (как float), то основные затраты времени будут именно на чтение из памяти,
а всей прочей арифметикой можно пренебречь (или подсчитать ее отдельно).
На удивление мало жизни происходит по запросу 'NVidia CUDA' в поиске по блогам и новостям. Что у Яндекса, что у Google. Мне это сильно удивительно - штука многообещающая, первая версия SDK датирована ноябрем (появилась примерно 1-го декабря), публичный SDK появился практически месяц назад, а большинство упоминаний в духе "вот вышло", в крайнем случае "читал доку". Таких текстов - навалом, маркетинг NVidia работает. Но скучно.
Помимо форумов NVidia, где заводится по 5-6 новых топиков в день, интересных публикаций немного.
Для начала: Beyond3D опубликовал большой текст про CUDA. Более подробный, чем все что я видел до сих пор (ну, кроме собственно документации).
Экспериментально выяснилось, что содержимое shared memory не сохраняется между запусками кода на G80. Всякий раз оно инициализировано, причем значения разные, то 10 (float), то 125.
Плакала идея синхронизации между мультипроцессорами путем завершения kernel. Нет, синхронизироваться можно, конечно, но если хочется сохранить результат, то надо писать в глобальную память.