• Уязвимость к hash flooding.
• В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее.
• При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки.
• Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping.
• Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными.

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

Звание «сениор», когда-то бывшее признаком большого опыта и знаний, обесценилось больше всего. Сегодня разработчиков начинают величать «сениорами» невероятно быстро, часто всего спустя три-четыре года работы. Как будто путь к «сениорству», бывший когда-то марафоном нарабатывания навыков и разнопланового опыта, превратился в спринтерский забег.

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

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

Но он ошибочен по многим причинам.

Во-первых, std::tolower — это неадресуемая функция. Среди прочего, это значит, что мы не можем брать адрес функции, как мы делаем это здесь, когда передаём указатель на функцию std::transform. То есть нам нужно использовать лямбду.

Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос.

Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд.

К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.

Введение

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

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

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

• Точка контакта мяча с ракеткой определяет угол отражения
• У ракеток нет ограничений по скорости
• Мяч отскакивает от верха и низа экрана

Опенсорсные модели становятся всё объёмнее, поэтому потребность в надёжной инфраструктуре для выполнения крупномасштабного обучения ИИ сегодня как никогда высока. Недавно наша компания выполнила fine-tuning модели LLaMA 3.1 405B на GPU AMD, доказав их способность эффективно справляться с крупномасштабными задачами ИИ. Наш опыт был крайне положительным, и мы с радостью выложили всю свою работу на GitHub в опенсорс.

GPU AMD, и в особенности серия MI300X — это серьёзная альтернатива ИИ-оборудованию NVIDIA, обеспечивающая больше производительности на вложенный доллар. Наша система состояла из одного узла с 8 GPU AMD MI300x, а для fine-tuning мы использовали JAX. В этой статье мы расскажем всю историю fine-tuning LLaMA 405B, в том числе и подробности шардинга параметров и реализации LoRA.

Qualcomm — не новичок в мире интегрированной графики. Её линейка Adreno GPU использовалась во многих поколениях SoC Snapdragon для сотовых телефонов. Но компании Qualcomm всегда было тесно в рамках телефонного рынка, она таила амбиции расширить свою мощь и выйти на другой уровень производительности. Сегодня её Snapdragon X Elite выпускается с прицелом на рынок ноутбуков. Adreno тоже переносится на рынок более высокой производительности, на котором есть такие конкуренты, как iGPU Intel Xe-LPG в Meteor Lake и iGPU AMD RDNA 3 в Phoenix.

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

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

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

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

e|-----------------|-----------------|-----------------|-----------------|
B|-----------------|-----------------|-----------------|-----------------|
G|-----3---5-------|---3---6-5-------|-----3---5-----3-|-----------------|
D|-5---3---5-----5-|---3---6-5-------|-5---3---5-----3-|---5-------------|
A|-5-------------5-|-----------------|-5---------------|---5-------------|
E|-----------------|-----------------|-----------------|-----------------| <- верх

Что такое One Million Checkboxes?

В чём состоит проблема​

Из всех последних изменений, которые будут внедрены в ECMAScript, моим любимым с большим отрывом от остальных стало предложение Temporal. Это предложение очень прогрессивное, мы уже можем воспользоваться этим API при помощи полифила, разработанного командой FullCalendar.

Этот API настолько невероятен, что я, наверно, посвящу несколько постов описанию его основных возможностей. Однако в первом посте я расскажу об одном из его главных преимуществ: у нас наконец появился нативный объект, описывающий Zoned Date Time.

Но что же такое Zoned Date Time?

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

«В общем случае, когда исходная строка умещается в конечный буфер, strlcpy будет обходить строку только один раз, а strlen + memcpy будут обходить её дважды».

Под этим аргументом скрывается допущение о том, что однократный обход строки выполняется быстрее. И, честно говоря, это вполне разумное допущение. Но справедливо ли оно? Об этом мы и поговорим в статье.

Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:

«Возьмём для примера этот код в локальной области видимости функции:

int a;

a = 5;

Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".

Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.

Можете ли вы сказать, какая строка считается инициализацией?»

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

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

Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»

В декабре 2023 года я выпустил 175 Pixel Font Megapack, за которым вскоре последовали 42 отдельных пака для каждого из семейства шрифтов. Я создал собственный тулчейн для генерации, тестирования и развёртывания этих шрифтов... на Rust! В посте я расскажу об этом процессе.

Примерно полгода назад математическое сообщество услышало новость о том, что исследователи DeepMind создали ИИ-систему, решающую геометрические задачи с Международной математической олимпиады на уровне, близком к золотым медалистам ММО. (Эту новость обсуждали в сабреддите \math, см., например, здесь и здесь.) За этими новостями, как часто бывает с новостями о прогрессе ИИ, последовала волна страха и ужаса, усиленная множеством громких газетных статей с картинками (разумеется, сгенерированными ИИ), на которых искусственные мозги решают ужасно сложные уравнения. По коллективной спине математического сообщества побежали мурашки, снова всплыли на поверхность обычные экзистенциальные вопросы о будущем человеческого интеллекта, а Интернет заполнили мемы о грядущем восстании машин.

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

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