283 ГБ/с на AMD Ryzen 9 7700X.
Сборка (протестирована с GCC 13):
g++ fizzbuzz.cc -march=native -o fizzbuzz -O3 -Wall -std=c++20 -fno-tree-vectorize -fno-exceptions
На сборку уходит несколько минут. В зависимости от CPU можно добиться повышенной производительности с -fno-tree-vectorize или без этого ключа.
Приветствую всех читателей! Меня зовут Артем Топоров, и сегодня я хочу поделиться с вами своим опытом участия в соревновании по распознаванию жестового языка, организованном компанией Google. На этом соревновании, собравшем 1139 команд со всего мира, нам удалось занять 2 место. Расскажу как мы вместе с Николаем Форратом и Xun Zhao разработали ML алгоритм для мобильных устройств, едва не заняли первое место и при чем тут спектрограммы. Вы можете использовать наш код, так как он распространяется под лицензией Apache 2.0.
Леонид Маркович Скворцов. Широко известный в узких кругах математик, профессионально занимающийся математическими проблемами автоматического управления. Например, его авторские методы использованы в SimInTech. Данный текст, еще готовится к публикации. Но с разрешения автора, читатели Хабр будут первыми кто сможет оценить. Первая часть здесь...
Приветствую!
Stan - это библиотека на C++, предназначенная для байесовского моделирования и вывода. Она использует сэмплер NUTS, чтобы создавать апостериорные симуляции модели, основываясь на заданных пользователем моделях и данных. Так же Stan может использовать алгоритм оптимизации LBFGS для максимизации целевой функции, к примеру как логарифмическое правдоподобие.
Для облегчения работы с Stan из языка программирования R доступен пакет rstan, который предоставляет интерфейс R для Stan.
Сегодня мы и рассмотрим этот пакет.
Это история про то, как не довести дело до конца, но получить уйму опыта, и вообще ни разу не обломаться.
Итак, у нас был один программист, один художник, абсолютное непонимание рабочего процесса, незнакомый нам игровой движок и желание что-то намутить. Если вам интересно, как в одном месте сошлись карта Вороного, частный случай расстояния Минковского, преобразования над полигонами, процедурная генерация и шумы — и все это в красивой стилизованной обертке, то вам под кат.
Осторожно, очень много картинок!
Тех кто ожидает наукоёмкости от чтения - сразу прошу не читать, тут нет ничего на что можно было-бы сослаться кроме собственнных работ, а значит и наукоёмкости публикации не содержит - прошу простить заранее за такую дерзость, и заметить что предупреждение мной всё же об этом было.
На самом деле, ввиду прошлой публикации (последствия которой я постараюсь исправить, так как наверное многие решили что это плод воображения - новая архитектура) - препроцессора, так как рассматриваю процессор и пост процессор. Для того, чтобы понять ход мыслей лучше, и то, что всё это не фантазии, а результат работы - стоит ознакомится с этой предыдущей публикацией, она не сильно длинная - но время отнимет, хоть и не сильно сложная.
Ознакомившись с ней станет понятно что имеется ввиду под модификациями кода (смена формул и выключение строк кода в рантайме), под модификациями кода подразумевается просто включение и выключение исполняемых команд, кода. Изначально мной предполагалось, что кэш мостов будет состоять из параллельных частей, и скорее всего в такой архитектуре конвейера он должен будет и обеспечивать работу меток и указателей (но сейчас не про них). В каких-то публикациях мне сделали замечания что мало графики и рисунков (вроде как про поляризацию для машинного зрения), но как можно увидеть из публикации по ссылке выше - оказалось достаточно одной блок-схемы чтобы отполировать и видоизменить весь код, и даже до той степени, чтобы задуматься о новой архитектуре.
Вопрос из области ненормального программирования: насколько сложные программы вы сможете написать на питоне, не пользуясь в принципе переменными (а также агрументами функций), за исключением пары глобальных массивов? Правильный ответ: да любой сложности. Если что-то можно сделать на ассемблере, то уж на питоне и подавно! Правда, пусть лучше код вместо меня сгенерирует машина :)
Продолжаем разговор о минималистичном компиляторе, который вполне реально написать за выходные. Задачей стоит транслировать код из придуманного мной языка в x86 ассемблер. Мой компилятор состоит из 611 строк кода, при этом не имеет ни единой зависимости:
ssloy@khronos:~/tinycompiler$ cat *.py|wc -l
611
Несмотря на то, что мой компилятор выдаёт ассемблер, я не мазохист, и пришёл к этому постепенно, сначала я транслировал код в питон, и постепенно урезал функционал целевого языка, пока не остался голый ассемблер, см. обложку публикации.
Итак, тема сегодняшнего разговора: генерация кода на питоне без использования переменных.
Хочу поделиться своим взглядом на вопрос, зачем стоит или не стоит прокачивать знание алгоритмов. Попробую взвешенно посмотреть на алгоритмическую задачу, как способ проверки нужных в практической работе навыков.
Не приходил ли вам когда-нибудь в голову вопрос о том, как устроены слои нейронных сетей под капотом? Задумавшись над этим вопросом, я перерыл интернет в поисках полноценной реализации слоёв, но находил лишь отдельные куски кода или слишком упрощенные примеры, где чаще всего использовался лишь один слой с одним нейронном для наглядности. В данной статье я реализовал полноценную многослойную нейронную сеть прямого распространения с неограниченным количеством нейронов.
В результате поиска в Интернете выяснилось, что термин «закон парадокса» в научной литературе практически не встречается. Исключением в настоящее время является статья по литературоведению, моя статья в Хабре и статья, которая в данный момент находится в стадии рецензирования в одном научном журнале.
Закон парадокса, по-видимому, можно считать недавно сформулированным и доказанным законом алгебры множеств. В данной статье приведены его формулировка и обоснование, а также показаны некоторые области его применения, в частности, выявление с его помощью одного из часто используемых приемов манипуляции сознанием. В заключительной части статьи приводится объяснение на его основе парадокса Рассела.
Вы когда-нибудь задумывались, как действуют клетки — элементарные единицы живой материи? Я программист, но одновременно увлекаюсь клеточной биологией. Поэтому я решил смоделировать работу простейшей клетки на TypeScript. Вообще, клетки невероятно сложны; по оценкам учёных, человеческая клетка в среднем содержит 100 триллионов атомов. По-прежнему очень мало известно о том, как все эти биомолекулы взаимодействуют в клетке, поэтому в точности смоделировать работу клетки невозможно.
Размышляя на эту тему, я нашёл статью Fundamental behaviors emerge from simulations of a living minimal cell (Фундаментальные виды поведения возникают на основе моделирования простейшей живой клетки). Опираясь на кинетические параметры, авторы статьи создали модель взаимодействия молекул и химических реакций между ними в простейшей известной клетке. Затем эта симуляция запускается, и на её основе можно наблюдать такие процессы как репликация ДНК, метаболизм и синтез белков.
Я обучил небольшой (порядка 10 миллионов параметров) трансформер по превосходному туториалу Let’s build GPT: from scratch, in code, spelled out Андрея Карпати. После того, как он заработал, я захотел максимально глубоко понять, как он устроен внутри и как создаёт свои результаты.
В исходной научной статье, как и во всех туториалах по трансформерам упор в основном делается на многоголовом самовнимании, — механизме, при помощи которого трансформеры обучаются множественным взаимосвязям между токенами, не используя рекурретности или свёртку. Ни в одной из этих статей или туториалов я не нашёл удовлетворительного объяснения того, что происходит после внимания: как конкретно результаты вычисления внимания превращаются в точные прогнозы следующего токена?
Я подумал, что могу пропустить несколько примеров промтов через обученный мной небольшой, но работающий трансформер, изучить внутренние состояния и разобраться в них. То, что казалось мне быстрым исследованием, оказалось полугодовым погружением, но дало результаты, которыми стоит поделиться. В частности, у меня появилась рабочая теория, объясняющая, как трансформер создаёт свои прогнозы, и эмпирические свидетельства того, что это объяснение, по крайней мере, правдоподобно.
Если вы знакомы с трансформерами и хотите сразу узнать вывод, то он таков: каждый блок трансформера (содержащий слой многоголового внимания и сеть с прямой связью) изучает веса, связывающие конкретный промт с классом строк, найденных в обучающем корпусе. Распределение токенов, соответствующее этим строкам в обучающем корпусе, и есть приблизительно то, что блок выводит как прогноз для следующего токена. Каждый блок может ассоциировать один и тот же промт со своим классом строк обучающего корпуса, что приводит к другому распределению следующих токенов, а значит, и к другим прогнозам. Окончательный результат работы трансформера — это линейное сочетание прогнозов каждого блока.
Кто такой YOLO? 🤔
Когда пытаешься разобраться в работе YOLO по статьям в интернете, постоянно натыкаешься на примерно такое объяснение: «Алгоритм делит изображение сеткой SxS, где каждому элементу этой сетки соответствует N ббоксов с координатами, предсказаниями классов и тд...». Но лично мне становилось только непонятнее от такого высокоуровнего описания.. Ведь в исследованиях часто всё происходит примерно так: перебирают гипотезы, пока не получат приемлемый результат, а потом уже придумывают красивое описание. Поэтому для ясности хочется в данной статье рассказать, как вообще приходили к идеям, которые ложились в основу YOLOv1 и последующих версий.
В настоящее время, благодаря передовым обсерваториям, космическим телескопам и миссиям, включающим (но не ограничивающимся) Hubble, Kepler, Gaia, возможности для изучения звезд и их скоплений вышли на новый уровень. Технологии позволяют не только проникнуть в глубины космоса, но и наблюдать реальность с невиданной ранее детализацией. Благодаря им и обнаруживаются "звёзды-родственники" (т.е. звёзды, образовавшиеся из одного облака). Эти объекты обладают схожими характеристиками, включая химический состав, возраст и скорость движения.
Выявление звезд общего происхождения имеет важное значение для наших попыток понять устройство мира на глобальном уровне.
В данной статье представлены возможности, которые открываются перед нами при исследовании звёзд общего происхождения, дан код и доступ к алгоритму, который позволит попробовать себя в роли астрофизика. Приведена информация для интерпретации результатов работы программы и предоставлена ссылка на все необходимые для погружения материалы, включая реальные данные аппарата Gaia (Европейское космическое агентство).
Здравствуйте. В прошлой тематической (не касающейся биографических отступлений) публикации может я ничего особо интересного и не написал, впрочем - возможно я вообще ничего интересного не пишу, но у меня свой путь и прошу меня за это не судить - каждый имеет право выбора. Можно было-бы написать много чего интересного, но всё-же предпочитаю серии одной темы, от одного аккаунта, пока нет на портале функции нескольких галерей одного автора.
Не рассчитываю собрать много плюсов, рассчитываю собрать вычислительную машину своей архитектуры, с своей ОС и процессорами собственной архитектуры. Многие наверное задались-бы вопросом - в чём логика, когда IT отрасль так развита. Давайте посмотрим кому она развита..., хотя нет, скажу только что решил что будет так тогда, когда в общем-то думал как конвейеры своего GPU пристраивать к вычислительной машине, и хотел назвать конвейеры эти - препроцессорами. Проверил термин и обнаружил, что термин пропроцессор занят под название программы. Подумал - ну хорошо, раз одни уже называют чёрное белым, то самое время создавать другое пространство, где такой необходимости попробовать избежать и создать что-то такое, где граблей валяться под ногами будет поменьше.
В 1978 году вышел третий том монографии Дональда Кнута «Искусство программирования», где автор рассматривает алгоритмы сортировки и поиска. Помимо самих алгоритмов описаны аппаратные характеристики компьютера и их влияние на производительность при работе с алгоритмами.
В 2024 году мы с вами возьмём классические алгоритмы сортировки и посмотрим, как работает современный многоядерный процессор при сортировке нескольких массивов на одном и нескольких логических ядрах. Мы напишем приложение с графическим интерфейсом (GUI) на фреймворке Qt, обойдем глобальную блокировку интерпретатора (GIL), воспользуемся несколькими потоками, на один из которых переложим выполнение асинхронного цикла событий, и распараллелим этот поток для реализации параллельных вычислений.
Процессоры архитектуры сверхдлинного машинного слова (VLIW - Very Long Instruction Word) относятся к специфическим классам архитектур, прямо нацеленным на использование внутреннего параллелизма в алгоритмах (программах), причём параллелизм этот анализируется и планируется к рациональному использованию при вычислениях на программном уровне; собственно аппаратная часть освобождается от процедур распараллеливания (и поэтому должна стать проще и экономичнее использующих внутреннее распараллеливание).
VLIW-подход основан на идее загрузки во входной буфер процессора одновременно набора (bundle) допускающих параллельное выполнение машинных команд и исполнения этого ряда команд аналогично единой команде в процессорах классической архитектуры. VLIW-процессоры реализуют параллелизм уровня ILP (Instruction-Level Parallelizm, параллелизм уровня машинных инструкций) и SMP (Symmetric MultiProcessing, системы с общей памятью) идеологему работы с оперативной памятью. Несмотря на выпуклое преимущество (программным путём дешевле реализовать сложные процедуры параллелизации), работа VLIW-процессоров сопряжена с известными проблемами. Среди них называют статичность полученных планов параллельного выполнения и проблемы с излишней неравномерностью времени доступа к оперативной памяти разных вычислительных ядер (временна́я антиплотность кода, следствием является резкое снижение производительности из-за неизбежности определять время выполнения всей связки команд сверхдлинного слова по продолжительности наиболее длинной из них).
Метод конечных элементов (МКЭ) применяют в задачах упругости, теплопередачи, гидродинамики — всюду, где нужно как-то дискретизировать и решить уравнения сплошной среды или поля. На Хабре было множество статей с красивыми картинками о том, в каких отраслях и с помощью каких программ этот метод приносит пользу. Однако мало кто пытался объяснить МКЭ от самых основ, с простенькой учебной реализацией, желательно без упоминания частных производных через каждое слово.
Мы напишем МКЭ для расчёта упругой двумерной пластины на прочность и жёсткость. Код займёт 1200 строк. Туда войдёт всё: интерактивный редактор, разбиение модели на треугольные элементы, вычисление напряжений и деформаций, визуализация результата. Ни одна часть алгоритма не спрячется от нас в недрах MATLAB или NumPy. Код будет ужасно неоптимальным, но максимально ясным.
Размышление над задачей и написание кода заняли у меня неделю. Будь у меня перед глазами такая статья, как эта, — справился бы быстрее. У меня её не было. Зато теперь она есть у вас.
В сентябре я устроился на должность поискового дата-саентиста и с тех пор часть моих обязанностей заключается в работе с Solr — опенсорсным поисковым движком на основе Lucene. Я знал основы работы поискового движка, но мне хотелось понять его ещё лучше. Поэтому я закатал рукава и решил создать его с нуля.
Давайте поговорим о целях. Слышали когда-нибудь о «кризисе сложности обнаружения маленьких веб-сайтов»? Проблема в том. что маленькие веб-сайты наподобие моего невозможно найти при помощи Google или любого другого поискового движка. Какова же моя миссия? Сделать эти крошечные веб-сайты снова великими. Я верю в возвращение славы этих малышей вдали от SEO-безумия Google.
В этом посте я подробно расскажу о процессе создания поискового движка с нуля на Python. Как обычно, весь написанный мной код можно найти в моём GitHub (репозиторий microsearch). Эта реализация не будет притворяться готовым к продакшену поисковым движком, это лишь полезный пример, демонстрирующий внутреннюю работу поискового движка.
Кроме того, мне стоит признаться, что в заголовке поста я слегка преувеличил. Да, поисковый движок действительно реализован примерно в 80 строках Python, но я ещё и писал вспомогательный код (краулер данных, API, HTML-шаблоны и так далее), из-за которого весь проект становится немного больше. Однако я считаю, что интересная часть проекта находится в поисковом движке, который состоит из менее чем 80 строк.
P.S. Написав этот пост и microsearch, я осознал, что пару лет назад нечто похожее написал Барт де Гёде. Моя реализация очень похожа на работу Барта, но я считаю что кое-что улучшил, в частности: (1) мой краулер асинхронный, что сильно ускоряет работу, (2) я реализовал пользовательский интерфейс, позволяющий взаимодействовать с поисковым движком.
Недавно на Хабре была опубликована статья Разбираем самый маленький PNG в мире. Интересно, а какой самый маленький файл JPEG? В ответах на StackOverflow и Reddit можно встретить размеры 107, 119, 125, 134, 141, 160 байтов. Все они представляют серый прямоугольник 1 на 1. И кто прав? Все правы, просто такая разница объясняется различными режимами кодирования и степенью строгости соответствия стандарту. Описание всех нюансов разрослось до целой статьи cо всеми необходимыми подробностями для более-менее хорошего знакомства с самыми маленькими jpeg-ами. После краткой теории разберем 159-байтный файл на КДПВ, а затем рассмотрим способы его уменьшения.
