Соавтор: Святослав Размыслов SvyatoslavMC.

В рекламных целях мы решили попробовать проверить ядро Linux с помощью нашего статического анализатора кода. Эта задача интересна своей сложностью. Исходные коды Linux чем только не проверялись и проверяются. Поэтому найти хоть что-то новое, весьма сложная задача. Но если получится, то это будет хорошая рекламная заметка о возможностях анализатора PVS-Studio.

Maciej Czyzewski собрал на Github коллекцию исходных кодов различных алгоритмов хеширования: для вычисления контрольных сумм, некриптографических и криптографических.

В репозитории можно найти, к примеру, реализации CRC/MD5/ГОСТ 34.311-95/SHA-3. Каждая хеш-функция представлена исходником на языке С и make-файлом для его сборки. Алгоритмы предполагается использовать в целях обучения — в реальных проектах рекомендуется в целях безопасности использовать существующие библиотеки (например, Crypto++ для C++, BouncyCastle для Java и т.д.), список которых есть в репозитории.

Над репозиторием продолжается активная работа, поэтому в перспективе стоит ждать пополнения коллекции.

Github

Если у человека, далекого от компьютерной индустрии, спросить, что находится внутри процессора, ответ, скорее всего, ограничится словами «мозг компьютера». Те, кому эта тема ближе, назовут примерно десяток различных блоков (например, кэш, ядра и контроллер памяти). Но вот как эти блоки соединены друг с другом, ответить, скорее всего, затруднятся или ответят неверно. А ведь кому-то наверняка хочется это знать! Давайте удовлетворим здоровое любопытство уважаемых хаброжителей.

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

Каждые несколько лет Intel анонсирует переход на новый технологический процесс. Если сюда добавить новости от других полупроводниковых компаний, то и года не проходит, чтобы та или иная из них не заявила о новом прорыве. Имена этих компаний хорошо известны и у всех на слуху. Но в их тени (совершенно незаслуженно) затерялась одна компания, труд которой незримо стоит едва ли не за каждым из технологических достижений в полупроводниковых технологиях. «Страна должна знать своих героев»…

КДПВ: одна из попыток Intel создать демотиватор :)

Почти 10 лет назад Intel сообщил о закрытии проектов Tejas и Jayhawk – продолжателей архитектуры NetBurst (Pentium 4) в направлении увеличения тактовой частоты. Это событие фактически ознаменовало переход в эпоху многоядерных процессоров. Давайте попробуем разобраться чем это было обусловлено, и какие принесло результаты.

Многие, наверное, помнят, какими темпами увеличивалась тактовая частота микропроцессора в 90-х и начале 2000-х годов. Десятки мегагерц стремительно переросли в сотни, сотни мегагерц почти мгновенно сменились цельным гигагерцем, затем гигагерцем с долями, двумя гигагерцами и т.д.
Но последние несколько лет частота уже не растет так быстро. От десятка гигагерц мы сейчас почти так же далеки, как и 5 лет назад. Так куда же исчез прежний темп? Что препятствует, как и раньше, «задирать» частоту вверх?

Текст ниже ориентирован на людей, не знакомых или слабо знакомых с архитектурой микропроцессора. Для подкованных читателей рекомендуются соответствующие посты yurav

Предлагаю вашему вниманию очередную заметку посвященную знакомству с технологией параллельного программирования OpenMP. Рассмотрим директивы: atomic, reduction.

В любом устройстве всегда найдется слабое звено – bottle neck (бутылочное горлышко), самый слабый компонент, который будет лимитировать производительность остальных частей. Долгое время в настольных компьютерах главными “тормозами перестройки” были жёсткие диски, и ни 7200, ни 10000, ни даже 15000 оборотов в минуту, не меняли ситуацию кардинально. С появлением твердотельных накопителей дело сдвинулось с мёртвой точки. Но прогресс не щадит и это быстрое решение. Интерфейс SATA не способен удовлетворить запросы пользователей, поэтому стали появляться новые стандарты и интерфейсы.

Не так давно наткнулся на статью о том, как Michael Kozakov не смог решить алгоритмическую задачу на собеседовании в Twitter. Решение этой задачи — почти в чистом виде один из самых стандартных алгоритмов на графах, а именно, алгоритм Дейкстры.
В этой статье я постараюсь рассказать алгоритм Дейкстры на примере решения этой задачи в несколько усложненном виде. Всех, кому интересно, прошу под кат.

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

Всем привет! С сегодняшнего дня компания OCZ Storage Solutions начинает вести свой блог на Geektimes. Удивлены? Возможно, ведь в одном из последних постов про OCZ на Geektimes говорится о банкротсве компании. Но как вы знаете, мы нашли выход из ситуации – на протяжении 2014 года товары OCZ не только не пропали с полок магазинов, но и более того ассортимент стал увеличиваться. Огромный японский концерн Toshiba с помощью несложных процедур получил в свое распоряжение компанию OCZ и вдохнул в неё новую жизнь.

Каждый раз при покупке батареек у меня возникало много вопросов:

Насколько дорогие батарейки лучше дешёвых?
Насколько ёмкость литиевых батареек больше обычных?
Насколько ёмкость солевых батареек меньше, чем у щелочных?
Отличаются ли батарейки для цифровых устройств от обычных?
Какие из батареек, стоящих одинаково, лучше покупать?

Чтобы получить ответы на эти вопросы я решил протестировать все батарейки АА и ААА, которые удастся найти в Москве. Я собрал 58 видов батареек АА и 35 видов ААА. Всего было протестировано 255 батареек — 170 АА и 85 ААА.

Перевод статьи из книги Practical Typography, автор которой — дизайнер из Лос Анджелеса Matthew Butterick. Оригинал статьи на practicaltypography.com.

Как выпускник юридического вуза, я прошел несколько интервью. На одном из них первый комментарий интервьюера был следующий: «Необычно видеть резюме без единой ошибки.»

«Вы серьезно?» — спросил я.

Группа ученых из Университета Вашингтона в Сент-Луисе (WUSTL) создала, пожалуй, одну из самых быстрых камер в мире. Система способна делать 100 миллиардов снимков в секунду. А это означает, что на снимке можно зафиксировать даже луч света «в полете». То, что изображено на анонсной фотографии — отраженный от зеркала свет.

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

Изображения, передаваемые космическими аппаратами: межпланетными станциями, роверами, зондами, восхищают многих людей. Конечно, в первую очередь, снимки предназначены для проведения анализа учеными — по фотографиям специалист может провести детальное исследование региона или объекта. В Сети уже десятки тысяч фотографий космоса, планет, самих устройств.

Но почему нет видео? Ведь как бы было интересно просмотреть часовой фильм, где бы демонстрировался Плутон, например (станция New Horizons уже проснулась). Но нет, есть только фотографии, и видео в ближайшее время не появится (кроме анимационных роликов). Это объясняется тремя основными причинами.

Захотелось как-то исполнить команду find в ftp-пространстве, но любой нормальный ftp сервер этого не даст сделать, а решение ну очень хотелось найти.

I saw a book entitled «Die GNU Autotools» and I thought «My feelings exactly». Turns out the book was in German¹. ©

Можно долго рассуждать о несовершенстве сего инструментария, о превосходстве CMake/QMake/подставьте_вашу_любимую систему сборки, но проекты, использующие autotools, окружают нас повсюду, и стоит как минимум знать, что это за зверь и с чем его едят, чтобы при попытке сделать, а то и отправить разработчикам патч, не править автосгенерированные файлы, чем я не так давно занимался.

Так же следует понимать, что именно autoconf системой сборки не является вообще, это система конфигурации перед сборкой. autoconf почему-то многие считают неким монстром, «проверяющим 15 давно несуществующих версий компилятора Fortran, а потом поддержку ключей этими компиляторами», что не совсем верно, ибо оно делает ровно то, что ему скажут. Другое дело, что многие просто копипастят его конфиг из проекта в проект, в итоге результат получается ужасающим.

В данной статье (планируется всё же осилить цикл) я хотел бы рассказать про autoconf, зачем он нужен и как его использовать.

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

Компилировать проект ручками — занятие весьма утомительное, особенно когда исходных файлов становится больше одного, и для каждого из них надо каждый раз набивать команды компиляции и линковки. Но не все так плохо. Сейчас мы будем учиться создавать и использовать Мейкфайлы. Makefile — это набор инструкций для программы make, которая помогает собирать программный проект буквально в одно касание.

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.

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

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.