Некоторые люди предпочитают пользоваться не только облачными сервисами, но и запускать LLM у себя дома. Например, так можно запустить дообученные модели без цензуры, или не посылать в облако свои личные документы. А то и запускать бесчеловечные эксперименты над LLM так, чтобы superintelligence/skynet потом это не припомнил.

Есть много моделей, оптимизированых для быстрой работы на устройствах с небольшой памятью. Но, к сожалению, веса самых продвинутых моделей, которые играют в одной лиге с лучшими онлайн моделями, занимают сотни гигабайт. Например, 8-битные веса Deepseek R1-671B занимают 700 гигабайт, квантованые q4 — 350 гигов. Можно квантовать и в 1 бит, размер тогда будет около 100 гигов, но такая модель почти бесполезна. Еще есть много качественных finetunes на основе Mistral-Large-instruct-130B, Qwen2.5-72B, llama3.3-70B, веса которых также не помещаются в память старших моделей видеокарт.

Помимо ChatGPT и многочисленных конкурентов в облаке с веб-мордами и/или API, существует огромная экосистема для запуска LLM на собственном железе. На Huggingface на любой бюджет найдется модель для скачивания, которая влезет в видеопамять (или в RAM, можно и на CPU запускать, если пользователь терпеливый). Вчера здесь на Хабре была очень неплохая обзорная статья.

Самые популярные open source тулы для локального запуска LLM — llama.cpp и vllm (и их многочисленные обертки). У них немного разные ниши, и дальше я буду писать о llama.cpp. Она поддерживает все возможные комбинации железа и ОС — Linux, MacOS, Windows; x86 CPU, Arm, Apple Silicon CPU & GPU, Nvidia, AMD,… Но автор и мейнтейнер — Георгий Герганов использует для разработки Mac Studio. Почему такой выбор железа?

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

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

Bitwise ternary logic that provides the capability to implement any three-operand binary function; the specific binary function is specified by value in imm8.

__m512i _mm512_mask_ternarylogic_epi32 (__m512i src, __mmask8 k, __m512i a, __m512i b, int imm8)
FOR j := 0 to 15
    i := j*32
    IF k[j]
        FOR h := 0 to 31
            index[2:0] := (src[i+h] << 2) OR (a[i+h] << 1) OR b[i+h]
            dst[i+h]   := imm8[index[2:0]]
        ENDFOR
    ELSE
        dst[i+31:i] := src[i+31:i]
    FI
ENDFOR
dst[MAX:512] := 0

ОК, допустим, мы разобрались, как она работает. Следующий уровень сложности — отладка кода, интенсивно использующего такие интринсики.

Архитекторы процессоров архитектуры x86 исторически были против предоставления программистам возможности непосредственного управления кэшем. Один как-то сказал мне в 2009 году — «никогда мы этого не сделаем, кэш всегда должен быть прозрачным для программиста». Некоторые RISC процессоры представляют архитектурную возможность управления данными/кодом, который окажется в кэше. И вот, наконец-то, нечто подобное появилось и в архитектуре x86 (начиная с Broadwell*).

Все знают и любят ассемблер x86. Большинство его инструкций современный процессор исполняет за единицы или доли наносекунд. Некоторые операции, которые декодируются в длинную последовательность микрокода, или ожидающие доступа к памяти могут исполняться намного дольше — до сотен наносекунд. Этот пост — о рекордсменах. Хит парад из четырех инструкций под катом, но для тех, кому лень читать весь текст, я напишу здесь, что главный злодей — [memory]++ при определенных условиях.



КПДВ взята из документа Агнера Фога, который, наряду с двумя документами от Intel (optimization guide и architecture software development manual) содержат много полезного и интересного по теме.

В феврале я писал о сборке Yocto для Galileo gen1, которая несколько облегчает разработку для Galileo. С тех пор прошел почти год, и у Galileo появились последователи — Galileo gen2, Edison. Про Edison (уже два месяца в продаже) надо писать отдельно, этот же пост об Intel IOT Development Kit.



Из железок на моем рабочем столе (извините за беспорядок) он совместим с Galileo gen1, gen2 и Edison.
С декабря 2013 по октябрь 2014 я был архитектором этого продукта, и сейчас я опишу, как продвигался проект, что уже получилось, и что запланировано.

На позапрошлой неделе на Mobile World Congress президент Intel Рене Джеймс анонсировала программу для разработчиков Internet Of Things. Всякие конкурсы-призы-хакатоны, короче — маркетинговая программа. Но были некоторые новости и по технической части. На MWC и Embedded World наша команда продемонстрировала некоторые новые возможности в разработке софта для IOT. Мы опубликовали два бинарных образа дисков (и соответствующие исходники для самостоятельной сборки), которые позволяют серьезно сократить время, необходимое для настройки системы для разработки софта для Galileo.

На Хабре публиковалось много отчетов о посещении основных выставок IT индустрии — CeBIT, CES, MWC. Я решил написать пост о SPS IPC Drives 2013, прошедшей недавно в Нюрнберге. Тоже большая выставка, 60000 посетителей — почти как на MWC. Я езжу на SPS/IPC/Drives уже третий год (живу недалеко, и по работе полезно), и в этом посте попытаюсь описать, на какие тенденции развития отрасли я обратил внимание в этот раз. У Intel нет на этой выставке своего стенда, поэтому лично мне эта выставка нравится больше всех остальных — не надо стоять на стенде несколько дней подряд, изучая окрестности во время коротких вылазок, когда подменяет коллега, а можно вдумчиво все обойти пофотографировать и пообщаться с участниками.

Название выставки — SPS/IPC/Drives на русский переводится как «Программируемые логические контроллеры, индустриальные ПК, и cервоприводы.» Эти три категории продуктов, и все с ними связанное и составляют большую часть продуктов и сервисов, которые демонстрируют полторы тысячи компаний-участников.

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

То ли дело настоящие промышленные роботы:

Недавно я выложил в сеть под BSD лицензией небольшой проект на 8 килострочек C кода. Официально это коллекция бенчмарков для моих клиентов — вендоров промавтоматики. Код очень специфический, и, на первый взгляд, малоприменим за пределами узкой области PLC и motion control. Но есть небольшая изюминка, на которой я не очень акцентировал внимание в статье на IDZ. В поставку бенчмарков включена baremetal среда для их исполнения. В этом посте я опишу, что это такое, и как ее можно использовать.

В предыдущем топике я обещал подробнее описать особенности программирования промышленных PLC, и почему такое программирование все больше напоминает разработку обычного софта. О языке IEC61131-3 ST (промышленном диалекте Паскаля) я уже писал, также хорошим вступлением можно считать вот этот хабратопик. Этот пост — о компиляторах PLC, средах разработки, особенностях программирования и эволюции языка и экосистемы.

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

• Появление промышленности. Первая промышленная революция произошла в начале XIX века и была связана с массовым переходом от использования мускульной силы к энергии парового двигателя. Ключевые технологии — паровой двигатель, фабрика. Появилась возможность массового производства, но его продукты стоили дорого.
• Массовое производство. Вторая революция случилась в начале 20 века, и ознаменовала начало дешевого массового производства. Ключевые технологии — конвейер и Тейлоризм. Продукты массового производства подешевели на порядок.
  
• Автоматизация. Третий переворот в промышленности произошел в 80-е годы. Станки с ЧПУ и роботы сделали современные фабрики практически безлюдными. (Аутсорсинг ручного труда в развивающиеся страны сгладил эту тенденцию.) Продукты массового производства подешевели еще на порядок (стало дешевле выкинуть, чем чинить).
• Децентрализация. Революция четыре точка ноль происходит сейчас. Ключевая технология — конвергенция промышленности и IT, 3д принтеры. Появляется возможность производства мелкой серии или уникального продукта по цене, приближающейся к стоимости того же самого в крупной серии.

Это немецкий взгляд на 4 четыре фазы развития промышленности. Существует еще и американский, который не разделяет третью и четвертую фазы.

Мне кажется, во вступлении я написал слишком много общих фраз и слишком мало технического хардкора. Исправлю это под катом, описав некоторые технические детали о промышленных сетях и продуктах Intel, связанных с ними (+ еще одна картинка с роботом).

У современных процессоров архитектуры Core i7 существует очевидный, документированный, но отчего-то не очень известный даже среди многих специалистов сценарий priority inversion. Его я опишу в этом посте. В нем есть код на С, три диаграммы, и некоторые подробности работы кэшей в процессорах архитектуры Core i7. Никаких покровов не срывается, вся информация давно общедоступна.

Priority inversion – ситуация, когда низкоприоритетный процесс может блокировать или замедлять высокоприоритетный. Обычно имеется в виду очередность доступа к исполнению на ядре для высокоприоритетного кода относительно низкоприоритетного. С этим должно неплохо справляться ядро ОС. Однако помимо вычислительных ядер, которые несложно распределять посредством affinity и MSI-X, в процессоре есть ресурсы, общие для всех задач – контроллер памяти, QPI, общий кэш третьего уровня, PCIe устройства. В вопросы PCIe я углубляться не буду, т.к. не являюсь экспертом в данной теме. Priority inversion на почве доступа к памяти и QPI я давно не наблюдал – пропускной способности современного многоканального контроллера как правило хватает и высокоприоритетным, и низкоприоритетным задачам. Остановлюсь на кэшах.

Есть такой не очень корректный термин: PC based industrial automation. Я думаю, что он не совсем точен, так как никто, конечно, не подсоединяет станок к обычному персональному компьютеру. А то вдруг зависнет, и станок отрежет что-нибудь ненужное. Но рациональное зерно в этом термине есть — уже много лет среди управляющих устройств промышленной автоматизации встречаются устройства, напоминающие ПК.

Напоминающие, конечно, не внешне.

Как и в вашем ноутбуке, в контроллере может стоять процессор Core i5, обыкновенная DRAM (только обычно с ECC), SSD диск, обычный Ethernet. Процесс загрузки тоже не отличается — BIOS загружает операционку. Как правило, операционка — RTOS. Однако иногда бывает даже Windows. Причем не всегда это Windows Embedded Compact (бывшая CE). Используется даже Windows Embedded 7, а это полноценная семерка. (Линуксы тоже встречаются)

Мои потребности в анализе производительности софта на x86 покрывают три тула. Один из них — Vtune XE знаком, наверное, всем, кто сталкивался с оптимизацией.

Второй тул, к сожалению, не столь широко известнен. Он уже упоминался на Хабре в контексте оптимизации AVX кода, но область его применения несколько шире.

Иногда после того, как Vtune нашел самый главный хотспот (а зачастую, разработчик и так его знает), возникает потребность приложить некоторые усилия для уменьшения числа тактов, которые тратятся на его исполнение. Уже почти три года я использую для анализа производительности таких небольших, но критичных участков кода Intel Architecture Code Analyzer.

Пользоваться им просто, вот рекурсивный алгоритм всего лишь из 6 шагов:
1. В соответствующем .c/.cpp файле включается
#include «iacaMarks.h»,
2. dll/so библиотеки IACA кладутся в доступное системе место,
3. в исходник добавляются макросы
IACA_START, IACA_END
соответственно, перед началом и после окончания оптимизируемого кода. Например,

Haswell будет очень инновационным Tock'ом. Еще в прошлом году стало доступно описание новых операций с целыми в AVX. А на этой неделе было опубликовано очередное расширение архитектуры X86. В Haswell появится аппаратная поддержка транзакционной памяти! На англоязычных сайтах обсуждение кипит. ISN Arstechnica LWN Engadget

Я думаю, что это самое нетривиальное расширение архитектуры X86 за много-много лет. Фича называется Transactional Synchronization Extensions (далее TSX), и состоит из двух частей — Hardware Lock Elision (HLE) и Restricted Transactional Memory (RTM). Обратите внимание на слово «Restricted». Все верно, есть некоторые ограничения по объему, гранулярности и уровню вложенности транзакций.

Об этих ограничениях и как это все будет работать подробнее под катом. (Никаких картинок, скучный технический текст)

void * memcpy ( void * destination, const void * source, size_t num );
Казалось бы, что там сложного? А о реализациях этой функции можно написать целую историю.

Когда я смотрю на окно своего любимого рабочего инструмента — профилировщика Vtune XE, очень часто вижу, что он в очередной раз обнаружил, что значительное время потратилось на копирование памяти. Так и обычно и написано: clock ticks spent in libgcc/[g]libc/kernel memcpy — XX%.

Наверное, поэтому memcpy часто переписывался, например в lkml частенько появляются подобные треды. (Больше реализаций, скорее всего, есть только у сортировок). Казалось бы, в отличие от сортировки, где есть много вариантов и алгоритмов с копированием памяти все просто. На самом деле, даже если говорить о корректности, а не производительности, возможны варианты. (В подтверждение тому — обсуждение эпического бага с участием Линуса Торвальдса и Ульриха Дреппера).

Еще во времена 8086, то есть тридцать четыре года назад, внутри реализации memcpy был следующий код:
mov [E]SI, src
mov [E]DI, ptr_dst
mov [E]CX, len
rep movsb
(все проверки и т.д. здесь и далее опущены для простоты)

Что же изменилось с тех пор? Под катом ассемблерный код и ни одной картинки.

В продолжение постов об использовании железа с х86 архитектурой в системах реального времени. Там я вкраце описал, насколько x86 удовлетворяют realtime требованиям, и что этому мешает.

Небольшое лирическое отступление. Системы реального времени — один из наименее известных двигателей компьютерного прогресса. Например, первый портативный компьютер был создан благодаря им. Сейчас почему-то считается, что первым серийным портативным компьютером был Osborn. На самом деле устройство на картинке выше было создано в Сименсе как cредство управления и программирования промышленной автоматизации за два года до Osborn. Переносные компьютеры этого семейства (Siemens Simatic) выпускаются и сейчас, хотя, конечно, железо много раз менялось.

Но перейдем к делу. В этом топике я подробнее остановлюсь на одном из факторов, который мешает предсказуемости времени выполнения realtime кода. Под катом будет не длинный, но нудноватый текст.

Почти 2 года как мы с женой переехали в Германию из Новой Зеландии. Хочу описать впечатления и несколько лайфхаков, полезных первое время. Все это можно найти в интернете, но редко в одном месте. Возможно, отчасти все будет слишком специфично для Мюнхена/Баварии. Текст длинный!

В прошлом посте я описал, как и зачем измеряется interrupt latency на платформе Atom.

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

После того, как архитектура Atom проявила себя в нетбуках, некоторые компании стали использовать Atom для Embedded Realtime применений. Делают промышленные контроллеры, гоняют на них PLC код.

Те же чипы, что и в нетбуке обычно на заводах не используют. Есть специальный платформы. Сначала был Crown Beach, сейчас начинает использоваться в дизайнах Queens Bay. Для IVI (автомобильный компьютер) есть своя платформа.

Естественно, удовлетворение realtime требований — необходимое условие. Об этом подробнее под катом.