Я выложил на Github новый проект A Simple GPU Hash Table.

Это простая хэш-таблица для GPU, способная обрабатывать в секунду сотни миллионов вставок. На моём ноутбуке с NVIDIA GTX 1060 код вставляет 64 миллиона случайно сгенерированных пар ключ-значение примерно за 210 мс и удаляет 32 миллиона пар примерно за 64 мс.

То есть скорость на ноутбуке составляет примерно 300 млн вставок/сек и 500 млн удалений/сек.

Таблица написана на CUDA, хотя ту же методику можно применить к HLSL или GLSL. У реализации есть несколько ограничений, обеспечивающих высокую производительность на видеокарте:

• Обрабатываются только 32-битные ключи и такие же значения.
• Хэш-таблица имеет фиксированный размер.
• И этот размер должен быть равен двум в степени.

Для ключей и значений нужно зарезервировать простой разграничивающий маркер (в приведённом коде это 0xffffffff).

Наверняка многие из вас хотя бы однажды пользовались хабраконвертером, который официально рекомендован администрацией Хабра — https://shirixae.github.io/habraconverter-v2/. Несколько лет назад его создал хабравчанин meta4, а потом доработал Shirixae. Принцип простой: открываете гуглодок с постом, Ctrl-A, Ctrl-C и вставляете в окно конвертера. Нажимаете кнопку «Конвертировать» и получаете готовый код вёрстки, который можно вставлять в редактор Хабра и публиковать. Только перед этим нужно пройтись и поправить кое-какие мелочи.

И всё бы хорошо, если верстать приходится не слишком часто. Или посты небольшие, несложные. Но если вы верстаете помногу, и в постах есть и картинки, и таблицы, и куски кода, то из раза в раз приходится делать рутину: вставлять нужные пустые строки и убирать лишние, заменять теги <sоurce> на <cоde>, и т.д. и т.п. Мы решили потратить день, чтобы потом долетать за час, и допилили конвертер.

Новая версия лежит тут, а под катом — перечисление доработок.

Мне давно было интересно, как сжимаются данные, в том числе в Zip-файлах. Однажды я решил удовлетворить своё любопытство: узнать, как работает сжатие, и написать собственную Zip-программу. Реализация превратилась в захватывающее упражнение в программировании. Получаешь огромное удовольствие от создания отлаженной машины, которая берёт данные, перекладывает их биты в более эффективное представление, а затем собирает обратно. Надеюсь, вам тоже будет интересно об этом читать.

В статье очень подробно объясняется, как работают Zip-файлы и схема сжатия: LZ77-сжатие, алгоритм Хаффмана, алгоритм Deflate и прочее. Вы узнаете историю развития технологии и посмотрите довольно эффективные примеры реализации, написанные с нуля на С. Исходный код лежит тут: hwzip-1.0.zip.

Оценивая свою работу, я недавно много размышлял о том, как мне писать хороший код. Учитывая, что никто не интересуется тем, как писать плохой код, возникает вопрос: как узнать, что ты написал на Go хороший код? Если есть какая-то шкала между хорошо и плохо, то как понять, какие части шкалы относятся к хорошему? Каковы его свойства, атрибуты, отличительные признаки, паттерны и идиомы?

Оригинал: статья «What I learned as a developer from accidents in space», Андрея Ситника, из блога Evil Martians «Martian Chronicles»

Андрей Ситник, автор PostCSS и Автопрефиксера, сделал подборку историй, связанных с освоением космоса Советским Союзом. Вы узнаете, какие уроки из них извлёк Андрей, чтобы вырасти как разработчик и участник опенсорс-движения. Неудачная стыковка, драматический вход в атмосферу и уникальный переход вдоль поручня между космическими кораблями — какое отношение всё это имеет к современной веб-разработке? Обо все этом читайте в посте!

Исследования космоса интересовали меня, сколько я себя помню. Люди, знавшие меня лично, слышали рассказов о космосе больше, чем им хотелось бы. До того, как присоединиться к Evil Martians, я администрировал русскоязычную версию Википедии, и одним из моих любимых увлечений была редактура связанных с космосом статей. Я ездил наблюдать за запусками на Байконуре и мысе Канаверал, и чем больше я узнавал об усилиях по покорению космоса, тем сильнее эти знания влияли на меня как на разработчика. 

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

В экосистеме PHP существует много инструментов, обеспечивающих удобное тестирование на PHP. Одним из самых известных является PHPUnit, это почти синоним тестирования на этом языке. Однако о хороших методиках тестирования пишут не так много. Есть много вариантов, для чего и когда писать тесты, какого рода тесты, и так далее. Но, честно говоря, не имеет смысла писать тест, если позднее вы не сможете его прочесть.

Тесты — это особая разновидность документации. Как я ранее писал о TDD на PHP, тест всегда будет (или хотя бы должен) ясно говорить о том, в чём заключается задача конкретной части кода.

Если один тест не может выразить эту идею, то тест плохой.

Я подготовил набор методик, которые станут подспорьем для PHP-разработчиков в написании хороших, удобочитаемых и полезных тестов.

Правила работы с динамическими массивами и пользовательскими классами коллекций
Здесь представлены правила, которых я придерживаюсь при работе с динамическими массивами. По сути, это руководство по проектированию массивов, но я не захотел помещать его в руководство по проектированию объектов, потому что не в каждом объектно-ориентированном языке есть динамические массивы. Примеры написаны на PHP, потому что он похож на Java (с которым вы, возможно, уже знакомы), однако с динамическими массивами вместо встроенных классов коллекций и интерфейсов.

Переходя от проекта к проекту, мы сталкиваемся, к сожалению, с отсутствием единообразных стандартов проектирования баз данных, несмотря на то, что SQL существует уже несколько десятилетий. Подозреваю, причина отчасти в том, что большинство разработчиков не понимают архитектуру БД. За годы моей работы по найму разработчиков, я лишь несколько раз встречал тех, кто мог корректно нормализовать базу данных. Честно говоря, это бывает сложной задачей, но многие разработчики, которых я собеседовал, даже прекрасно владеющие SQL, не имели навыков проектирования БД.

Эта статья не про нормализацию БД. Если хотите этому научиться, то здесь я вкратце рассказал основы.

Если у вас есть рабочая БД, то нужно ответить себе на вопрос: «какие стандарты можно применить для облегчения использования этой базы данных?». Если эти стандарты применялись широко, то вам будет легко пользоваться БД, потому что не придётся изучать и запоминать новые наборы стандартов каждый раз, начиная работу с новой БД.

Используете для создания приложений Vue, React, Angular или Svelte? Я использую, и если вы тоже, и уверен, что вам уже давно не приходилось писать приложение, которое выводит информацию без этих прекрасных инструментов.

Когда-то многие из нас писали веб-приложения только с помощью тех средств, что были встроены в браузер. И хотя современные инструменты помогают нам абстрагироваться от этого (и имеют много других преимуществ), всё ещё полезно знать, что происходит у них под капотом.

При выводе небольшого количества информации вам может потребоваться использовать HTML, JavaScript и DOM без каких-либо инструментов. Недавно я написал несколько базовых примеров, которые иллюстрируют основы веб-разработки и помогают в изучении DOM, HTML, JavaScript и принципов работы браузера. Этот опыт позволил мне понять, что другие разработчики — возможно, вы, — будут рады вспомнить, как выводить информацию без использования библиотек.

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

Давайте рассмотрим разные способы вывода информации. И держите под рукой эту документацию!

Близится десятая годовщина моего присутствия на Stack Overflow. За эти годы мой подход к использованию сайта и его восприятие сильно изменилось, и я хочу поделиться с вами своим опытом. И пишу я об этом с точки зрения среднестатистического пользователя, который не сильно вовлечён в жизнь сообщества сайта или его культуру. В последние дни я отвечаю лишь на вопросы, относящиеся к VS Code — продукту, над которым я работаю. Однако раньше я активно участвовал в обсуждении широкого набора тем. За 10 лет я задал около 50 вопросов и дал 575 ответов, просмотрел несметное количество чужих комментариев.

Джон Скит описал культуру Stack Overflow гораздо лучше и авторитетнее, чем я когда-либо смогу сделать. Его публикация повлияла на некоторые главы этой статьи, хотя в целом это мои собственные откровенные размышления о моём опыте пребывания на Stack Overflow, что на этом сайте хорошо и что плохо, и как его можно сегодня использовать. Это обсуждение будет довольно поверхностным, без глубокого погружения в работу сайта или его историю.

Итак, вот чему я научился за 10 лет использования Stack Overflow.

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

Сегодня солнечный день. Вы едете по дороге в вашу деревню, в которой живут все ваши друзья, ваша семья и ваша любимая собака. Прекрасный день! Неожиданно вы слышите ужасный, кошмарный вопль, разрывающий окрестности. Огромная отвратительная Гидра приближается к деревне, чтобы её уничтожить! Вы хватаете меч (конечно, у вас есть меч!) и стараетесь защитить всех, кого любите. Но есть небольшая проблема: у чудовища много голов, и когда вы отрубаете одну из них, быстро вырастает новая!

Кажется, что вы не можете победить в этой битве. Возможно, вы сможете играть с Гидрой достаточно долго, так чтобы вся деревня успела улететь от ужасной угрозы? Наконец, вы станете настоящий героем всего мира! Кому этого не хочется?

В роли Гидры выступает энтропия в ПО: это ваш враг, он вас измотает, но вы никогда не сможете полностью от него избавиться. Но с ним всё равно нужно бороться, чтобы ваши приложения (и коллеги) оставались здоровыми и вменяемыми.

Мы узнаем:

1. Что такое энтропия в ПО и как заметить её в своём коде.
   
2. Что является её возможными причинами и как сохранить энтропию на низком уровне.
   

Хватит болтовни, к делу!

Применение зашифрованных данных для машинного обучения без их расшифровки
В этой статье обсуждаются передовые криптографические методики. Это лишь обзор исследований, проводимых в Julia Computing. Не используйте приведённые здесь примеры в коммерческих приложениях. Всегда консультируйтесь с криптографами, прежде чем применять криптографию.

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

Оптимизирующие компиляторы — основа современного ПО: они позволяют программистам писать код на понятном для них языке, затем преобразуя его в код, который сможет эффективно исполняться оборудованием. Задача оптимизирующих компиляторов заключается в том, чтобы понять, что делает написанная вами входная программа, и создать выходную программу, которая делает всё то же самое, только быстрее.

В этой статье мы рассмотрим некоторые из основных методик приведения (inference techniques) в оптимизирующих компиляторах: как спроектировать программу, с которой компилятору будет легко работать; какие приведения можно сделать в вашей программе и как использовать их для её уменьшения и ускорения.

«Думаю, я смело могу сказать, что квантовую механику никто не понимает», — Ричард Фейнман

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

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

Поигравшись с профессиональными балансировщиками наподобие NGINX, я попробовал ради веселья создать простенький балансировщик. Написал я его на Go, это современный язык, поддерживающий полноценный параллелизм. Стандартная библиотека в Go имеет широкие возможности и позволяет писать высокопроизводительные приложения с меньшим количеством кода. К тому же для простоты распространения она генерирует единственный статически скомпонованный бинарник.

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

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

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

XML — это язык разметки. Это не формат данных. В большинстве схем XML это разграничение явно не учитывали, путая XML с форматом данных, что в итоге означало ошибку в самом выборе XML, поскольку на самом деле нужен был именно формат данных.

Несмотря на то, что в последние семь лет я пишу на JavaScript почти каждый рабочий день, должен признаться, что уделяю мало внимания сообщениям о нововведениях от ES. Главные возможности вроде async/await и прокси — это одно, но ещё каждый год идёт поток мелких поэтапных изменений, которые не попадают в моё поле зрения, поскольку всегда находится что-то более важное для изучения.

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

В последнее десятилетие мы успешно пользовались тем, что Go обрабатывает ошибки как значения. Хотя в стандартной библиотеке была минимальная поддержка ошибок: лишь функции errors.New и fmt.Errorf, которые генерируют ошибку, содержащую только сообщение — встроенный интерфейс позволяет Go-программистам добавлять любую информацию. Нужен лишь тип, реализующий метод Error:

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }