При выполнении параллельной программы, активно задействующей CPU, нам часто необходимо, чтобы пул потоков или процессов имел размер, сопоставимый с количеством ядер CPU на машине. Если потоков меньше, то вы будете использовать все преимущества ядер, если меньше, то программа начнёт работать медленнее, так как несколько потоков будет конкурировать за одно ядро. Ну, или такова ситуация в теории.

Как же проверить, сколько ядер есть у компьютера? И действительно ли это хороший совет?

Оказывается, на удивление сложно определить, сколько потоков выполнять:

- В стандартной библиотеке Python есть множество API для получения этой информации, но ни одного из них недостаточно.

- Хуже того, из-за таких функций CPU, как параллельность на уровне команд и одновременной многопоточности (Hyper-threading в CPU Intel), количество ядер, которое можно эффективно использовать, зависит от того кода, который напишете вы!

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

Просматривая недавно соцсети, я наткнулся на этот скриншот. Разумеется, его сопровождало множество злобных комментариев, критикующих попытку этого новичка в программировании решить классическую задачу computer science: операцию деления с остатком.

В современном мире, где ИИ постепенно заменяет программистов, отнимая у них работу и совершая переворот в том, как мы подходим к рассуждениям о коде, нам, возможно, следует быть более открытыми к мыслям людей, недавно пришедших в нашу отрасль? На самом деле, показанный выше код — идеальный пример компромисса между временем и задействованной памятью. Мы жертвуем временем и в то же время памятью и временем компьютера! Поистине чудесный алгоритм!

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

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных.

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

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

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

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

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

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

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

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

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

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

В этой статье мы опустимся на один уровень ниже и посмотрим, что же происходит внутри среды исполнения Python для выполнения простого действия a + b. Иными словами, мы узнаем о подробностях реализации типов, операторов и динамической диспетчеризации в CPython.

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

Введение

Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.

Чему нас учат в вузах

Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.

Вот один из карьерных путей в разработке ПО:

1. Проведите несколько первых лет в небольшой компании, не понимающей технологий. Теперь вы единственный программист или один из немногих.

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

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

4. Освойтесь в устранении неполадок и в возврате системы в строй. Получите несколько повышений в зарплате и должности, пока в ней не появится слово «Senior»; скорее всего, это произойдёт не позже чем спустя три года после того, как вы начнёте устранять неполадки системы.

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

6. Каждые несколько лет получайте ещё одно повышение и красивое дополнение к названию должности.

В этом посте я вкратце расскажу о внутреннем устройстве iMessage, изученном мной в процессе работы над pypush — опенсорсным проектом воссоздания реализации iMessage.

Ради краткости и понятности я не буду вдаваться в технические подробности. Если вы хотите узнать, как конкретно всё реализовано, то изучите репозиторий pypush.

За последние полгода я несколько раз писал о тонкой настройке (fine tuning). Fine tuning — очень соблазнительная технология, обещающая закрыть проблемы в функциях GPT-4, будучи при этом быстрее и дешевле. Однако как бы часто не обсуждали fine tuning, я нашёл на удивление мало контента о том, который бы помог мне понять, насколько эффективен fine tuning и насколько сложно встраивать новые возможности в языковые модели.

Поэтому я решил взять всё в свои руки, сдуть пыль с моих навыков ML и разобраться самостоятельно.

Выбор задачи

Меня особенно интересовала проверка возможностей модели рассуждать (то есть выполнять достаточно сложные задачи, требующие хорошего понимания контекста ) о данных вне распределения (то есть о тех, которые модель не видела). В конечном итоге я выбрал своё хобби: коллекционную карточную игру Magic the Gathering (и в частности, драфт).

Заявление о том, что большинство ИИ-стартапов обречено, может показаться довольно очевидным. В конце концов, большинство стартапов обречено, так уж сложилось.

Но я хочу донести нечто более провокативное. Почти все стартапы, возникшие после хайпа ChatGPT, и особенно те, которые называют себя «ИИ-стартапы», обреченыs.

Я венчурный капиталист, инвестировавший в ИИ уже долгое время; на самом деле, я даже ушёл и мира хедж-фондов, потому что увидел, насколько много всего интересного происходит в сфере ИИ. То есть я определённо не ИИ-скептик.

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

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

Позвольте мне выразить эту мысль более кратко:

мейнтейнер > автор

Я считаю, что такое мышление можно вывести за рамки написания кода и использовать как эмпирическое правило при выявлении проблем и принятии решений.

В этой статье я поделюсь с вами долгой историей, которая начинается с op.read() opendal, а заканчивается неожиданным поворотом. Это путешествие оказалось для меня достаточно поучительным, надеюсь, и для вас оно будет таким же. Я постараюсь максимально точно воссоздать свой опыт и дополню его выводами, которые сделал в процессе.

В этом месяце я решил узнать, как создать шрифт, который буду использовать в своём комиксе hakum. Раньше я рисовал текст в цифре на своём планшете. Результат оказывался хорошим, но иногда трудночитаемым (размер текста часто скакал на одной странице). Мне не хотелось использовать готовый шрифт, поэтому я решил создать собственный на основе своего рукописного текста. Шрифт повысит читаемость текста и сделает его однородным.

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

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

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

«640 КБ хватит всем», — предположительно Билл Гейтс, примерно 1981 год.

Мы решили, что в нашей системе управления финансовыми базами данных TigerBeetle для хранения всех финансовых сумм и балансов будут использоваться 128-битные числа, и что мы откажемся 64-битных целых чисел. Хотя кто-то может заявить, что 64-битного integer, способного хранить в себе целые числа от нуля до 2⁶⁴, достаточно для подсчёта всех песчинок на Земле, мы осознали, что для адекватного хранения всех транзакций нам нужно подняться выше того предела. И в статье мы расскажем, почему.

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

«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»

Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:

«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»

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

Однако моя статья будет немного о другом:

«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»

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

Как-то я изучал release notes новой версии Python 3.12, и в разделе о депрекациях моё внимание привлекла следующая фраза:

utcnow() и utcfromtimestamp() из datetime.datetime устарели и будут удалены в будущей версии.

Если вы следили за моими туториалами по веб-разработке, то видели, что я часто использую utcnow(); очевидно, мне придётся переучиваться и использовать альтернативу, готовясь к неизбежному удалению этой функции (вероятно, это произойдёт спустя несколько лет, так что причин для паники нет!).

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

Intel недавно раскрыла спецификацию AVX10 как средство консолидации подавляющего большинства расширений AVX-512 в единую спецификацию. Целью этого было решение нескольких проблем, в частности, поразительного количества конфигураций, целевых платформ и спагетти из реализаций AVX-512 с несогласованной поддержкой команд. Следует помнить о том, что в первую очередь она используется как средство для объединения всех любимых преимуществ AVX-512 в более мелкие реализации, целевые платформы для которых — это потребительские машины, micro-edge и встроенные системы, у которых нет или не будет 32 512-битных регистров, необходимых для AVX-512. 

После публикации спецификации я публично выразил свой энтузиазм, сделав доклад для сообществ разработчиков Easy Build/HPC с названием «AVX10 for HPC: a reasonable solution to the 7 levels of AVX-512 folly». Статья, которую вы читаете, изначально должна была стать частью доклада, но я решил написать её, чтобы ссылаться в дальнейшем (а ещё потому, что я уже с трудом могу урезать доклад до 90 минут, не говоря уже о предоставленных мне 60 минутах).

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

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

Всё это приятные бонусы, но никто не говорит им, что на самом деле им придётся делать на этой работе.

Имея большой опыт работы в этой отрасли, я смог показать им, какова жестокая реальность. Я рассказал им о хорошем, но также поделился и неприятными истинами.

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