Привет, Хабр!
Эта статья является неким сборником многих статей про все, что связано с параллелизмом в 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, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.
Привет, Хабр! Меня зовут Макс, я Go-разработчик в компании SimbirSoft. Язык Go (Golang) стремительно набирает популярность, он всё чаще внедряется в существующие программные решения, а также встречается в стеке новых проектов. Высокая производительность и скорость работы – его главные преимущества, поэтому для реализации бизнес-задач он подходит как нельзя кстати. Go легко поддерживается и отлично годится для создания MVP, из-за чего востребованность в нём растёт.
Но чтобы этот язык программирования был действительно производительным, разработчикам необходимо учитывать некоторые тонкости работы с ним. Иначе ваше приложение станет таким же медленным, как айтишник без чашки кофе :) В этой статье мы с вами на примерах разберём часто возникающие ситуации при работе с Go, а также рассмотрим приёмы, которые позволят повысить производительность кода. Надеюсь, разработчики уровня джуниор и мидл смогут почерпнуть для себя что-то полезное.
Мы начинаем!
Disclaimer. Данная работа не повлияла на мои взгляды на программирование, но повлекла достаточно радикальные изменения в подходах к проектированию автоматных объектов. Теперь, если процесс автономен и/или не предъявляет требований к синхронизации, он может использовать другие механизмы параллелизма, не переставая при этом быть автоматным по сути. А почему так случилось, что этому предшествовало и что это за изменения, вы прочтете далее.
Это не самая большая моя статья (так я думал, начиная ее), над которой я работал, пожалуй, дольше и больше, чем над другими. Но это точно первая моя статья, в которой автоматы и ВКПа не будут главной темой. Тема потоков для меня достаточно необычна, т.к. я совсем не фанат многопоточного программирования. Но, тем не менее, занимаясь параллельным программированием, время от времени возвращаюсь к теме многопоточности. И вот, чтобы добыть какие-то аргументы для критики и одновременно попробовать найти практическое применение потокам, я решил в этот очередной раз более плотно заняться потоками. А что из этого получилось, читайте далее.
Горутины виснут непонятно почему, случайная запись в закрытый канал вызывает panic, нормально протестировать приложение вообще невозможно.
Наверняка многие из вас сталкивались с такой проблемой: синтаксис языка Go вроде бы очень простой, можно сказать примитивный, да и горутины создаются элементарно, но при этом написать мало-мальски серьёзную программу, которая конкурентно что-то делает, внезапно оказывается не так-то просто.
Чтобы не запутаться, люди придумали концепцию structured concurrency, которую можно применять и в Go.
HttpClient так, чтобы не получать 429 Too Many Requests.
Проверка небольших чисел на простоту - популярная подзадача в спортивном программировании. И тест Миллера-Рабина, пожалуй, наиболее популярный из простых алгоритмов для этого.
У меня давно было желание с ним поиграться, стараясь оптимизировать различными способами. Например, векторизовать и посмотреть, станет ли быстрее.
Привет, habr! Предлагаю вашему вниманию статью о том, как я писал велосипед библиотеку для передачи сообщений между потоками с возможностью мультиплексирования.
