Внутренняя модель nVidia GPU – ключевой момент в понимании GPGPU с использованием CUDA. В этот раз я постараюсь наиболее детально рассказать о программном устройстве GPUs.

Перед тем как начать переносить реализацию вычислительного алгоритма на видеокарту стоит задуматься — получим ли мы желаемый прирост производительности или только потеряем время. И несмотря на обещания производителей о сотнях GFLOPS, у современного поколения карт есть свои проблемы, о которых лучше знать заранее. Я не буду глубоко уходить в теорию и рассмотрю несколько существенных практических моментов и сформулирую некоторые полезные выводы.

Компьютеры, даже персональные, становятся все сложнее. Не так уж давно в гудящем на столе ящике все было просто — чем больше частота, тем больше производительность. Теперь же системы стали многоядерными, многопроцессорными, в них появились специализированные ускорители, компьютеры все чаще объединяются в кластеры.
Зачем? Как во всем этом многообразии разобраться?
Что значит SIMD, SMP, GPGPU и другие страшные слова, которые встречаются все чаще?
Каковы границы применимости существующих технологий повышения производительности?

Введение

Откуда такие сложности?

Компьютерные мощности быстро растут и все время кажется, что все, существующей скорости хватит на все.
Но нет — растущая производительность позволяет решать проблемы, к которым раньше нельзя было подступиться. Даже на бытовом уровне есть задачи, которые загрузят ваш компьютер надолго, например кодирование домашнего видео. В промышленности и науке таких задач еще больше: огромные базы данных, молекулярно-динамические расчеты, моделирование сложных механизмов — автомобилей, реактивных двигателей, все это требует возрастающей мощности вычислений.
В предыдущие годы основной рост производительности обеспечивался достаточно просто, с помощью уменьшения размеров элементов микропроцессоров. При этом падало энергопотребление и росли частоты работы, компьютеры становились все быстрее, сохраняя, в общих чертах, свою архитектуру. Менялся техпроцесс производства микросхем и мегагерцы вырастали в гигагерцы, радуя пользователей возросшей производительностью, ведь если «мега» это миллион, то «гига» это уже миллиард операций в секунду.
Но, как известно, рай бывает либо не навсегда, либо не для всех, и не так давно он в компьютерном мире закончился. Оказалось, частоту дальше повышать нельзя — растут токи утечки, процессоры перегреваются и обойти это не получается. Можно, конечно, развивать системы охлаждения, применять водные радиаторы или совсем уж жидким азотом охлаждать — но это не для каждого пользователя доступно, только для суперкомпьютеров или техноманьяков. Да и при любом охлаждении возможность роста была небольшой, где-то раза в два максимум, что для пользователей, привыкших к геометрической прогрессии, было неприемлемо.
Казалось, что закон Мура, по которому число транзисторов и связанная с ним производительность компьютеров удваивалась каждые полтора-два года, перестанет действовать.
Пришло время думать и экспериментировать, вспоминая все возможные способы увеличения скорости вычислений.

В Google как всегда высоко поднимают планку. Они уже давно заявляют, что все сайты, время открытия которых больше 2 секунд, работают медленно. Мы решили оценить какие российские порталы взяли эту высоту.

В исследовании были рассмотрены сайты 3 сфер: банки (ТОП 50 по активам), страховые (ТОП 50 по активам) и интернет-магазины большой телекомовской тройки и крупных цифровых ритейлеров (всего 9 сайтов). Для всех этих компаний очень важно повышать лояльность пользователей к сайту, большой вклад в которую вносит снижение времени открытия страниц.

К примеру Amazon.com (оборот за 2010 г. – $34,2 млрд, +40% за год) заявлял, что увеличение времени открытия сайта пользователем всего на 0,1 секунды приводит к потере 1% объема продаж [ссылка]. А исследование Akamai и Phocuswright показало, что 43% людей не готовы ждать открытие сайта больше 4 секунд.

Против компании Dropbox подана жалоба (PDF) в Федеральную торговую комиссию с требованием разбирательства по поводу обмана 25 млн пользователей этого хостинга. С момента начала своей деятельности Dropbox заявляла, что их сотрудники не имеют возможности получить доступ к зашифрованным файлам пользователей. В справочном разделе было написано, что «все файлы зашифрованы AES-256 и не могут быть расшифрованы без вашего пароля».

Недавно выяснилось, что это не так. Оказалось, что сотрудники Dropbox могут расшифровывать файлы, если сочтут это необходимым. 13 апреля 2011 года вторая часть предложения (выделена курсивом) была удалена из справочного раздела.

Есть сервис passwordcard который позволяет генерировать и распечатывать такие вот карточки паролей.



Суть заключается в том, чтобы запоминать только картинки и длину, например вертикаль «О» запоминаем только вертикаль, получается JQ3xqZkE

Карточку можно распечатать и положить в удобное место.
Хорошая альтернатива менеджерам и проч. программ.

UPD: Для особо умных ребят уточню, что комбинаций здесь гораздо больше и facepalm писать не следует, потому как пароль можно как по диагонали брать, по змейке, зиг-загом, в обратном порядке, через один и так далее

UPD2: судя по всему сервер упал под хабраддосом (:

Представляю вашему вниманию перевод статьи под названием "Context Menu design" от Hagan Rivers. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Two Rivers Consulting Corporation.

Что такое контекстное меню?

Контекстное меню это меню, которое содержит команды, относящиеся к объекту, на который в данный момент указывает курсор. Это меню еще часто называют меню правого клика — из-за того, что исторически оно вызывалось правым кликом мыши в Windows.



Контекстное меню сообщения в Apple Mail (слева) и Windows Mail (справа).

Произошло то, чего многие ждали давно и, фактически, уже имели: музыку теперь можно слушать бесплатно, но при этом абсолютно легально.
В рамках комплексного обновления старейшего легального магазина www.Fidel.ru появился новый тариф «Открытый». Теперь каждый зарегистрированный пользователь может абсолютно бесплатно, легально и всегда слушать любое количество музыки с битрейтом 320 кб/сек без рекламы и чего-либо надоедливого!

Если кратко, мы сделали веб-сервис, избавляющий от скучных дел. Причем клиенты выбирают сами, сколько платить:


Клиенты — наши начальники. Они сами оценивают работу и назначают оплату. Иллюстрация — Michael Dashow.

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

• искал жестянщиков вытащить сосульку из крыши Пассата
• делал визу в Польшу на 86 дней
• в общем, скрашивал быт.

Рассчитываю, что заключительный пост серии — в отличие от трёх предыдущих, оказавшихся, по-видимому, чересчур хардкорными — вызовет у хабрапублики не только филологический интерес.

Один из комментаторов серии постов Чена про безблокировочные алгоритмы поинтересовался, в каких условиях эти более сложные алгоритмы существенно превосходят по производительности такие простые примитивы блокировки, как критические секции.

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

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

Следуя совету хабрапублики, пробую новый вариант перевода термина "lock-free"

В прошлый раз мы видели «беззахватный по духу» алгоритм, где захват был реализован так, что поток, обращающийся к захваченным данным, не ждёт их освобождения, а отправляется «обходным путём» (вычисляет требуемый результат, не пользуясь услугами кэша). В своём следующем посте Реймонд объясняет, как данный алгоритм можно усовершенствовать на случай, когда «обходного пути» нет. Алгоритм, однако, остаётся беззахватным: каждый поток продолжает работать, не дожидаясь освобождения захваченных данных.

В общей переменной теперь нужны два служебных бита: вдобавок к флагу захвата, как в прошлом примере, — флаг «поручена новая работа»; а если порученная работа сложная, то кроме флага, нужно будет где-то хранить ещё и её параметры. Например, в общей переменной можно хранить указатель на (выравненный в памяти) объект с параметрами, а в свободных младших битах указателя — два названных флага.

Перед выполнением действия над объектом, первым делом мы его захватываем, атомарно устанавливая соответствующий флаг. Если окажется, что объект уже был захвачен, — поручим выполнение нашего действия захватившему потоку, установив второй флаг.

Если же объект удалось захватить, то после завершения работы с ним снимаем флаг захвата и одновременно проверяем, не поручили ли нам новую работу. (Т.е. не было ли обращений к объекту за то время, пока мы его держали захваченным.) Если есть работа, то мы выполним и её; и так далее, пока однажды при разблокировке объекта отложенной работы не окажется. Мы не вправе оставить объект в состоянии «не захвачен, но есть работа».

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

Облачные хранилища данных, несомненно, одно из самых интересных и актуальных направлений в IT. Достаточно сказать, что за лидерство здесь идет активная борьба между такими гигантами как Microsoft, Google, Amazon. Интерес к этому активно подогревается также сторонними разработками, активно использующими эти сервисы. Например, менеджер Dropbox, который, как теперь уже кажется, был всегда. Уже не верится, что каких то 2 года назад он почти не был известен.

Со временем я «оброс» различными хранилищами, хранилища в свою очередь обросли сервисами. И недавнее гугление по названию Gladinet при чтении комментариев здесь, на Хабре (извиняюсь, не смог найти комментарий), привело на сайт разработчиков desktop приложения Gladinet, вполне достойного пристального внимания.

Установив бесплатную версию приложения, обнаружил, что к вновь созданному устройству могу подключить практически все облака, которыми раньше пользовался. Все данные при первом запуске подключаются как ссылки. Загрузка происходит уже при фактическом обращении к файлам.

Приложение встраивается в проводник и другие файл-менеджеры (в моем случае Total Comander) как дополнительный диск, в котором собираются все виртуальные устройства.

Для того, чтобы писать операционку, нужно разбираться во многих деталях. Вот давайте я вас немного просвещу, (но давайте договоримся, что маны вы будете читать сами, чтобы было о чём побеседовать).
Честно говоря, на просторах сети есть туча тучная материалов по PM, да и ileyи pehat несколько рассказали об этом режиме, но меня попросили всё равно описать в общих рамках его. Сейчас кратко выдам теорию (вообще то специально для этого Intel маны писала), потом начнём писать код.

   На днях компания Intel совершила очередной прорыв в процессоростроении, а точнее, в эволюции транзисторов — логических элементах современных процессоров. Если последние 50 лет в электронике использовались исключительно планарные структуры, то отныне в массовом производстве применяемая структура станет трехмерной. Технология, позволившая и дальше следовать закону Мура, получила название Tri-Gate. По значимости этот шаг сопоставим, разве что, с изобретением интегральной схемы транзисторов.

В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.

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

В большинстве простых интернет-проектов «упрощение» классических процессов разработки работало хорошо, гибкость помогала, но в относительно больших и сложных наблюдались «искры высокого напряжения» с частичным летальным исходом.

Поехали.

Гибкие и «жесткие»

Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.

Гибкие методологии убеждают нас «поверить», что из-за того, что требования постоянно меняются, можно к черту отказаться от многолетнего опыта разработки программного обеспечения, впитанного классическими методологиями, тем же «водопадом», все решительно упростить и броситься в объятья «коммунистической» свободы, честности и равенства.

А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.

Так вот, «упрощение», предлагаемое гибкими методологиями, очень условное и коварное. «Расслабились» с одной стороны, придется хорошенько поднатужиться с другой.

Яков Сироткин, известный блогер и опытный разработчик любит раскрывать глаза молодых программистов на порой нелицеприятные стороны работодателей, объясняя при этом природу этих фактов.

Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.

• Как успешно разрабатывать программное обеспечение вопреки трудностям?
• Понравится ли это начальству?
• Что за это будет?
• Как жить дальше?

Хабраюзер burdakovd задал в Q&A задачку про C++, vector и запись в чужую память. Задачка, кроме всего прочего, хороша тем, что на ней можно удобно продемонстрировать, как пользоваться инструментом Application Verifier и находить, кто же портит память.

Application Verifier — очень мощный инструмент, кроме диагностики работы с хипом он умеет уйму всего другого, например определять неправильную работу с хендлами, ошибки реализации многопоточности, эмулировать нехватку ресурсов, чтобы проверить корректную работу программы в таких условиях, но об этом как-нибудь в другой раз.

Введение | Tor | Tarzan и MorphMix| Малозатратная атака | Малозатратная атака на Tarzan и Morphmix | Принципы построения безопасных систем (заключение)

Tarzan

Tarzan — это еще одна анонимизирующая система с малыми задержками. Она тоже базируется на идеях Чаума и, как и другие, создана для обеспечения анонимности при использовании веб-приложений и мессенджеров. В отличии от Tor, Tarzan основан на peer-to-peer архитектуре. Каждый Tarzan-узел может быть как клиентом так и передаточным узлом. Благодаря этому устраняются timing-атаки анализа трафика между входными и выходными узлами. Ведь, в любой момент кто угодно может присоединиться или выйти из сети, и любой узел может быть потенциальным инициатором потока (клиентом). Для распространения информации об имеющихся в сети узлах используется протокол основанный на механизме сплетен (gossip-based mechanism) похожий на описанный в работе (Harchol-Balter, Leighton & Lewin 1999). Из-за особенностей peer-to-peer архитектуры, нападающий может изобразить из себя столько Tarzan-узлов сколько захочет. Поэтому, в Tarzan предусмотрен механизм для уменьшения вероятности выбора вредоносного узла. Механизм предполагает категоризирование узлов на основе хешей их IP адресов.