В этой статье мы собираемся разобрать архитектуру Tensor Streaming Processor TSP и его компилятора, а затем увидим, как Groq построили надежный и высокопроизводительный распределенный механизм инференса искусственного интеллекта с использованием этих TSP.
Я являюсь автором проекта по математическому моделированию прикладной механики и в работе моей программы до 90% вычислительного времени уходит на решение системы линейных уравнений. Цель этой статьи сугубо практическая - найти оптимальный метод решения системы линейных уравнений с точки зрения производительность/трудозатрат для небольшого проекта и рассказать о результате.
В прошлом я уже несколько раз обращал внимание на вычисления на GPU, но всегда что-то останавливало. И вот у меня накопился достаточный практический опыт программирования на C/C++ и наконец дошли руки, чтобы протестировать OpenCL.
Зачем нужны потоки, если есть параллелизм ВКПа? Поговорим об этом подробнее. По существу мы тем самым продолжим тему статьи[1], рассмотрев только более сложный пример, чем простые и абстрактные счетчики. Рассмотрим по ходу сначала пример, а уж потом и его реализацию на потоке. Поехали?!
Мы используем Go для создания Dolt, первая в мире БД SQL с контролем версий. Как и большинство кодовых баз, основанных Go, мы используем каналы и горутины(от переводчика, автора этой статьи на Хабре: у меня есть хорошая статья на тему параллелизма в Go) для реализации параллелизма. Как правило мы используем эти конструкции очень скучным и обычным путем, ведь параллелизм и так сложен без всяких выдумок. Но в одном месте мы все-таки взяли маленький кусочек кода из другого open-source проекта, который использует каналы очень интересным способом...
Читаем предыдущую статью. Борьба за реализацию мечты продолжается.
Вячеслав ответил и все в мгновение ока стало ясно. Или, точнее, почти все.
А теперь подробнее...
Действительно, я дал в штангу - промазал с параметрами 2-го фазификатора. Не установил нужные значения. Мой косяк. Сбило то, что, во-первых, результаты совпадали (так уж получилось и теперь понятно почему) и, во-вторых, сравнивался код. В первую очередь на С++, как первый кандидат на ошибку. А он совпадал.
Сами же параметры скрыты - в свойствах блока и я как-то в суете забыл про них. Что тоже объяснимо (хотя и не оправдывает). Просто на С++ параметры в явном виде в тексте программы, а в SimInTech в неявном - настройках, а я фазификатор размножил копированием. Верхний работал и, вроде, верно, а потому какие могли быть вопросы к скопированному? Это я так думал. Действительно, к нему вопросов нет (пока), но были (есть?) ко мне. Но я уже покаялся...
Все это безобразие, невнимательность и далее по списку. Но это мой грех, про который я знаю, но преодолеть не в силах :( И потом я не какой-нибудь ChatGPT XXX, который не ошибается. Я же поднял "хайп", народ взбаламутил!? Гнать таких программистов! Заменить на ИИ!... И это уже происходит. И кто-то даже верит, что это поправит дело. Наивный...
Но давайте серьезно. Итак, я установил нужные параметры фазификатору, и результат не заставил себя ждать (см. рис. 1). Но, чтобы он устраивал, так тоже нет. Видна перерегулировка. Опять что-то не так с параметрами? Тьфу-тьфу. Я уже прямо боюсь... :) Но , вроде, с ними разобрались и не должно быть подвоха. Код? Проверено многократно. Глаз "замылился"? Может. Но, если честно, я его/их настолько "замылил", что смотреть на код уже сил просто нет... Тоже обычное дело ;)
Есть задача, а для кого-то почти мечта - реализовать нечеткую математику в ВКПа. И здесь отдельное спасибо Вячеславу Петухову за материал, ставший основой похода в нечеткую логику на базе автоматов. Правда, сам Вячеслав высказался отрицательно о реальности подобного "блицкрига", но, ведь, когда есть цель и неистребимое желание ее достичь, то, порой, даже невозможное становится возможным. Мне же, что там скрывать, очень захотелось в ВКПа создавать объекты на основе нечеткой логики, аналогичные объектам в SimInTech. Тем более, что когда-то теория нечетких множеств привлекала мое внимание, а понятие нечеткого регулятора и сейчас, если честно, бередит мои мысли...
Чтобы от чего-то оттолкнуться, был выбран проект из каталога демо-примеров платформы SimInTech из подкаталога "Автоматика и математика\Нечёткая Логика\Система поддержания уровня воды в баке". И на момент начала написания данной статьи мною уже были успешно реализованы некоторые из типовых блоков библиотеки "Нечеткая логика" платформы SimInTech (см. рис. 1). Заметим, что дополнительную информацию о нечеткой логике можно почерпнуть из справки платформы SimInTech, зайдя в раздел "Лабораторные работы по ВУЗам", затем в "Московский Политех" и в завершение - "Разработка системы нечеткого вывода".
Привет, Хабр!
Эта статья является неким сборником многих статей про все, что связано с параллелизмом в Go, например: горутины, каналы, select и многое другое.
Я хотел углубиться в тему горутин с параллелизмом и, слушая на фоне "The Doors", поглощал информацию и выделял интересные мысли из статей
Надеюсь, Вы найдете для себя то, что искали.
Вернемся к одному из проектов дистрибутива программной платформы SimInTeh, который был рассмотрен в двух статьях(см. [1, 2]). Он же под именем "Управление водонагревательным котлом" включен в раздел "Лабораторные работы по библиотекам" справочной системы SimInTech. Последнее должно предъявлять к нему повышенные требования, как к примеру, поясняющему, рекламирующему те или иные стороны и возможности программной платформы. Одним словом, он должен быть идеальным ...
Только недавно одна из найденных в нем ошибок была устранена. Но не это знаменательное событие было причиной вернуться к данной теме, а пришедшая примерно в это же время рассылка, рекламирующая возможности "новейшей российской инженерной платформы Engee". В числе прочих ее достоинств описывались включенные в платформу конечные автоматы (КА)[3], а в видео по ссылке прослеживалась явная любовь к светофорам. Но нагреватель в этом смысле ни чуть не хуже, а даже предпочтительнее.
Но "спусковым крючком" стал эмоциональный всплеск не самой положительной оценки данной конечным автоматам (подробнее см. [4]). Примечательно, что прозвучал он со стороны тех, кто ранее ввел этот инструментарий в свою платформу и, как можно предполагать, использует. Видимо, они лучше знают возможности своих автоматов? Но, если серьезно, то это, скорее всего, результат отмеченного "всплеска", который за истину воспринимать не стоит. Тем не менее, необходимо что-то уточнить, чтобы учесть и такое мнение о КА.
Итак, перед нами проект "Нагреватель" или "Управление водонагревательным котлом". Я не смог сразу найти проект в ВКПа к тем еще статьям, но, если честно, не сильно его и искал, т.к. решил, что проще создать новый. Хотелось проверить, что получится, если повторить в ВКПа автоматы, полностью аналогичные ранее созданным программным автоматам на внутреннем языке платформы SimInTech. А поскольку они были спроектированы согласно концепциям автоматного программирования, то препятствий не предполагалось. Но ... воистину - "не было этого никогда и вот опять".
* 21 и более параллельным запросом в определённых условиях :)
Привет, сегодня поговорим о подводных камнях использования виртуальных потоков в написанных на Java веб-приложениях. В статье описан случай из жизни, сперва поставивший в тупик, но оказавшийся не столь уж и запутанным, а причина и вовсе была известна и документирована.
Привет! В команде ВКонтакте мы переписываем рантайм движков баз данных — они становятся быстрее, надёжнее, а ещё с новым рантаймом проще писать код. Однако есть нюанс: в новом рантайме много конкурентных структур данных, в том числе нужных для работы с корутинами из С++20. Появляется интересная задача — проверять корректность этих конкурентных структур данных до выхода кода в продакшен.
Для решения этой задачи команда ВКонтакте вместе со студентами из университетов ИТМО и СПбГУ работала над научно-исследовательским проектом — верификацией конкурентных структур данных на языке C++. В этой статье подробно расскажем, как мы в рамках проекта проверяли корректность наших конкурентных структур данных и заодно исправили найденную в нашем новом рантайме ошибку.
loom, поэтому о нём стоит написать. Моя цель — не научить вас тому, что нужно использовать на практике (если вы хотите этого, то почитайте документацию loom), а, скорее, вывести пару идей из фундаментальных принципов.
Многие из вас когда‑то поступали (или будут поступать) в вузы. Это происходит обычно 1 раз в жизни, поэтому абитуриенты часто не понимают всей специфики работы приёмной комиссии, построения списков, сроков зачисления и т. п. Часто этим просто лень заниматься. Да плюс ещё эти правила приёма меняются каждый год (более того скажу — чаще чем раз в год) и уследить за этим обычному человеку не представляется возможным.
В этой статье я попробую заглянуть за пределы возможностей языка JavaScript и оценить, как производительность может существенно различаться при написании выразительного, декларативного и лаконичного кода по сравнению с оптимизированным. На примере функции, определяющей, является ли строка палиндромом, я покажу несколько вариантов решения задачи с замерами времени на исполнение. Затем напишу модуль на C, который буду вызывать наряду с методами на JavaScript для замера скорости. Проведу низкоуровневые оптимизации. Все это стало возможно благодаря развитию ИИ.
Ниже представлен код, который удовлетворит требованиям большинства интервью. К стыду своему, я забыл, как писать регулярные выражения, чтобы удалить все, кроме букв и чисел. ссылка на репозиторий.
Недавно я реализовал очень необычную задумку — демонстрацию Minecraft-подобного движка с игровой логикой, выполняющейся полностью на GPU.
Как и зачем я это сделал, и как дошёл до жизни такой, я поведаю в этой статье.
Внимание, в статье есть много скриншотов!
Ниже приведен вопрос, заданный искусственному интеллекту (ИИ). Поскольку был использован сайт Chad AI, который использует Chat GPT, то с последним и будем идентифицировать "личность" нашего ИИ. Какие преследовались цели, затевая общение с ИИ? Любопытно было узнать о его просвещенности в автоматном программировании (АП)? Если ему о нем что-то известно, то хотелось бы понимать меру этого знания и какое его определение он приведет? А тут возможны варианты. Определение может совпадать с авторским пониманием АП[1], но может быть и другим. А это особенно интересно: как трактуется понятие АП в мире вообще и/или "интеллектом" в частности? Ведь ИИ по умолчанию должен быть более информированным, чем любой "натурал" - натуральный интеллект (НИ). Последний сосредоточен часто только на своей идее и, кроме того, ему по больше части не доступен столь же огромный объем информации, который "подсунули" во время обучения ИИ.
Итак, вопрос ИИ:
Сформулировать, что собой представляет автоматное программирование, дав его 1) формальное определение и 2) примеры практической реализации, 3) пусть, немножко хотя бы, коснется истории его развития (если оно и эта история есть, конечно).
Был получен следующий ответ (орфография и пунктуация сохранены):
1. Автоматное программирование представляет собой методологию построения программного обеспечения, основанную на использовании автоматов, то есть моделей, которые принимают входные данные, выполняют определенные действия и возвращают результат. Основная идея заключается в том, что программа описывается как последовательность состояний и переходов между ними, что позволяет представить ее как автомат.
В данной статье я опишу свои самые свежие и яркие впечатления от многопоточного программирования. Это мои впечатления, мой опыт и я буду рад, если он будет полезен другим программистам.
В крайней статье я утверждал, что более серьезные проблемы их поджидают в случае взаимодействующих потоков. Но одно эти проблемы предполагать или даже предсказывать, а другое - столкнуться с ними непосредственно.
Предсказанное сбылось, как говорится, по полной программе. Думаю, что озвученные далее проблемы для кого-то не станут новостью, но будут и те, кто о них не подозревает, как не подозревал и я. А потому захотелось их зафиксировать и поделиться, с чем пришлось столкнуться. Ну, и рассказать, как я выкрутился, попав в не совсем привычные для меня ситуации (в автоматном программировании, подчеркну, они не возникли бы в принципе).
Итак, создав ранее тест потоков (о нем подробнее см. [1]), гоняя его многократно и в разных режимах, я заметил, что пусть редко, но выскакивают некорректные результаты. В подобных случаях я грешу обычно на себя. А в данном случае тем более, т.к., что там скрывать, имею весьма небольшой опыт использования потоков.
Но в процессе экспериментов обнажились проблемы, которые сложно списать на недостаток опыты. Что-то при этом удалось преодолеть сразу, с чем-то пришлось повозиться, но были и те проблемы, которые не удалось поправить, даже при наличии достаточно большого опыте в программировании вообще. О последнем, не об опыте, конечно, а о проблемах, и пойдет далее речь... И даже не о проблемах, а о довольно нежданных и негаданных "засадах", возникших на пути освоения многопоточности.
Фракталы — это бесконечные самоподобные фигуры. Они определяются простыми математическими формулами, которые создают удивительную красоту!
В этой статье мы рассмотрим алгоритм визуализации одного из самых известных фракталов на языке Rust с аппаратным ускорением NVIDIA, масштабированием, сглаживанием и многопоточностью.
А что если окажется, что простые знания на самом деле более нюансированные, а старые знакомые, такие как Double-checked locking, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.