feat: add Egor Makukhin’s report on styding practice and images of graphics by ioughy · Pull Request #15 · gsvgit/1_year_practice_2026_reports

ioughy · 2026-06-07T21:34:14Z

-Added my initial version of report
-Added all the PNG's with graphics

gsvgit · 2026-06-12T05:44:25Z

+
+\textbf{Целью работы является} освоение стека FPGA-симуляции проекта Vortex, проведение параметрического синтеза конфигураций и оценка эффективности масштабирования вычислительных ядер и кэш-иерархии с точки зрения производительности и потребления ресурсов ПЛИС.
+
+Результаты работы необходимы для понимания архитектурных узких мест (bottlenecks) архитектуры Vortex при решении memory-bound задач. Для конечных пользователей (разработчиков FPGA-ускорителей и исследователей архитектур) это полезно тем, что позволяет избежать неэффективного расходования ресурсов кремния (LUT, BRAM) при конфигурации GPU под потоковую обработку данных. В выполнении работы заинтересована лаборатория/кафедра для формирования рекомендаций по настройке экземпляров Vortex под различные классы задач.


"расходования ресурсов кремния (LUT, BRAM) при конфигурации GPU под потоковую обработку данных" Великолепно всё.

до кремния Vortex-у ещё далеко

Вот прям уже потоковая обработка данных исследуется?

Заменил эти утверждения.

gsvgit · 2026-06-12T05:47:31Z

+
+\section{Описание предлагаемого решения}
+
+Для достижения цели был предложен подход, основанный на автоматизированном прогоночном тестировании RTL-модели Vortex с последующим сбором метрик производительности и аналитической оценкой ресурсов ПЛИС. Идея решения заключается в варьировании двух главных архитектурных осей --- количества ядер и размера кэш-иерархии --- на двух классах задач: \enquote{memory-bound} (векторное сложение, \texttt{vecadd}) и \enquote{compute-bound} (умножение матриц, \texttt{sgemm}). В отличие от реальных ПЛИС или высокоуровневых симуляторов, использование RTL-симулятора обеспечивает цикл-точную достоверность результатов без затрат на FPGA-синтез и аппаратное развертывание.


Неразрывный продел перед тире (~---)

Правда ли, что векторное сложение memory-bound?

Правда ли, что умножение именно compute-bound?

Она потактово точная

Так-то конфигурация одного ядра критически важна. Какую Вы взяли?

Все тире были заменены, формулировки про ...-bound заменил, про точность поменял (переехало чуть дальше), конфигурацию уточнил.

gsvgit · 2026-06-12T05:48:01Z

+
+Для достижения цели был предложен подход, основанный на автоматизированном прогоночном тестировании RTL-модели Vortex с последующим сбором метрик производительности и аналитической оценкой ресурсов ПЛИС. Идея решения заключается в варьировании двух главных архитектурных осей --- количества ядер и размера кэш-иерархии --- на двух классах задач: \enquote{memory-bound} (векторное сложение, \texttt{vecadd}) и \enquote{compute-bound} (умножение матриц, \texttt{sgemm}). В отличие от реальных ПЛИС или высокоуровневых симуляторов, использование RTL-симулятора обеспечивает цикл-точную достоверность результатов без затрат на FPGA-синтез и аппаратное развертывание.
+
+Реализация решения осуществлялась с использованием RTL-симулятора \texttt{simx} из состава Vortex, скриптов сборки Bash, языка Python для парсинга логов и визуализации данных (pandas, matplotlib), а также аналитической модели оценки ресурсов ПЛИС Xilinx (расчет использования блочной памяти BRAM на основе объемов кэшей L1/L2/L3). Для обеспечения воспроизводимости результатов был разработан пайплайн автоматизации, позволяющий запускать серию экспериментов одной командой.


Если что, simx не потактово точный.

парсинг --- жаргон

Уточнил про simx, парсинг здесь и далее убрал.

gsvgit · 2026-06-12T05:50:06Z

+
+Экспериментальное исследование проводилось в три этапа: Strong Scaling (фиксированный объем данных, рост ядер), Cache Scaling (фиксированное число ядер, рост кэша) и Weak Scaling (пропорциональный рост данных и ядер). 
+
+Ввиду детерминированности RTL-симуляции (отсутствие системных прерываний и аппаратных задержек, присущих физическому железу), статистическая погрешность замеров отсутствует: математическое ожидание времени выполнения равно результату единичного замера, среднеквадратичное отклонение (СКО) равно нулю. Для оценки ресурсов ПЛИС применялась аналитическая модель: 1 блок BRAM = 4 КБ.


Ууу.... А Вы прям время замеряли?

Поменял неудачную формулировку. Указал, что метрикой производительности является «количество тактов симулятора», а не физическое время.

gsvgit · 2026-06-12T05:50:25Z

+Ввиду детерминированности RTL-симуляции (отсутствие системных прерываний и аппаратных задержек, присущих физическому железу), статистическая погрешность замеров отсутствует: математическое ожидание времени выполнения равно результату единичного замера, среднеквадратичное отклонение (СКО) равно нулю. Для оценки ресурсов ПЛИС применялась аналитическая модель: 1 блок BRAM = 4 КБ.
+
+\textbf{Результаты Strong Scaling:}
+Увеличение числа ядер с 1 до 4 на потоковой задаче \texttt{vecadd} (16K элементов) дало ускорение всего 1.05x. IPC каждого ядра упало с 0.79 до 0.21. Как видно на Рисунке 1, реальное ускорение далеко от идеального --- это классический эффект \enquote{Стены памяти}, при котором ядра простаивают в ожидании данных из RAM.


Что такое "потоковая задача"?

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

Заменил термин "потоковая задача" в тексте.

Учёл. Добавил раздел "Угрозы нарушения корректности", указал в Strong Scalling, что могли влиять параметры запуска, уточнил конфигурацию ядра.

gsvgit · 2026-06-12T06:01:26Z

+
+\begin{itemize}
+    \item Освоен стек RTL-симуляции и сборки проекта Vortex GPGPU.
+    \item Разработан автоматизированный пайплайн (Bash + Python) для проведения параметрических экспериментов, парсинга логов и визуализации результатов, обеспечивающий полную воспроизводимость исследования.


Парсинг

Убрал.

gsvgit · 2026-06-12T06:02:02Z

+\begin{itemize}
+    \item Освоен стек RTL-симуляции и сборки проекта Vortex GPGPU.
+    \item Разработан автоматизированный пайплайн (Bash + Python) для проведения параметрических экспериментов, парсинга логов и визуализации результатов, обеспечивающий полную воспроизводимость исследования.
+    \item Экспериментально доказано наличие \enquote{Стены памяти} в архитектуре Vortex: масштабирование вычислительных ядер эффективно для compute-bound задач (\texttt{sgemm}, ускорение 1.51x на 4 ядрах), но упирается в пропускную способность памяти для потоковых задач (\texttt{vecadd}, ускорение всего 1.05x на 4 ядрах).


Ммм.. Нет. Вы пронаблюдали какой-то странный эффект при криво поставленном эксперименте.

Категоричное утверждение «Экспериментально доказано наличие "Стены памяти"» удалил. Заменил формулировки на сильно более осторожные + добавил раздел "Угрозы нарушения корректности".

gsvgit · 2026-06-12T06:02:17Z

+    \item Освоен стек RTL-симуляции и сборки проекта Vortex GPGPU.
+    \item Разработан автоматизированный пайплайн (Bash + Python) для проведения параметрических экспериментов, парсинга логов и визуализации результатов, обеспечивающий полную воспроизводимость исследования.
+    \item Экспериментально доказано наличие \enquote{Стены памяти} в архитектуре Vortex: масштабирование вычислительных ядер эффективно для compute-bound задач (\texttt{sgemm}, ускорение 1.51x на 4 ядрах), но упирается в пропускную способность памяти для потоковых задач (\texttt{vecadd}, ускорение всего 1.05x на 4 ядрах).
+    \item Обоснована неэффективность наращивания объема кэш-памяти (L2/L3) для memory-bound задач: L3-кэш не дает прироста, а L2-кэш вызывает деградацию из-за конфликтов при многопоточном доступе (Cache Thrashing).


Нет. См. выше

В текущей версии отчёта раздел «Заключение» полностью переработан.

gsvgit · 2026-06-12T06:02:34Z

+    \item Экспериментально доказано наличие \enquote{Стены памяти} в архитектуре Vortex: масштабирование вычислительных ядер эффективно для compute-bound задач (\texttt{sgemm}, ускорение 1.51x на 4 ядрах), но упирается в пропускную способность памяти для потоковых задач (\texttt{vecadd}, ускорение всего 1.05x на 4 ядрах).
+    \item Обоснована неэффективность наращивания объема кэш-памяти (L2/L3) для memory-bound задач: L3-кэш не дает прироста, а L2-кэш вызывает деградацию из-за конфликтов при многопоточном доступе (Cache Thrashing).
+    \item На основе экспериментов Weak Scaling подтверждено, что общая шина памяти является узким местом архитектуры: при пропорциональном росте объема данных и ядер время выполнения растет линейно, что исключает эффективный параллелизм независимых потоков.
+    \item Выполнена аналитическая оценка потребления ресурсов ПЛИС (BRAM), показавшая низкий аппаратный ROI (Return on Investment) конфигураций с большими кэшами для потоковых задач.


В текущей версии отчёта раздел «Заключение» полностью переработан.

gsvgit · 2026-06-12T06:07:41Z

+
+Репозиторий с пайплайном автоматизации и исходными скриптами: \url{https://github.com/Makuhin-Egor/Vortex-experiments-styding-practice}.
+
+Техническая документация (README с описанием архитектуры и запуска): \url{https://github.com/Makuhin-Egor/Vortex-experiments-styding-practice/blob/main/README.md}.


Это позор.

Лицензии нет

CI нет (да, хотя бы чеки, линты на Ваши скрипты)

Менеджером для Python пользуйтесь. UV, там, не знаю.

Ну и да. Один коммит 4 дня назад намекает на качество работы и хороший инженерный подход к ней.

Репозиторий доработал по всем критериям, также поменял readme под новую версию отчёта.

gsvgit · 2026-06-12T06:08:13Z

И да. Конфликты разрешите.

gsvgit

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

gsvgit · 2026-06-15T07:01:16Z

+
+\section{Обзор используемых технологий}
+
+Исследование проводится на базе открытой GPGPU-архитектуры Vortex~\cite{vortex_repo}, реализованной на базе RISC-V ISA~\cite{riscv_isa}. В отличие от проприетарных решений (NVIDIA CUDA, AMD ROCm), Vortex предоставляет полностью открытый RTL-код, что делает его удобной платформой для архитектурных исследований.


А какая часть ROCm треюует RTL кода?

Неудачная формулировка. Поправил.

gsvgit · 2026-06-15T07:01:58Z

+\end{itemize}
+
+\textbf{Результаты Strong Scaling:}
+Увеличение числа ядер с~1 до~4 на задаче \texttt{vecadd} (16K~элементов) дало ускорение всего 1{,}05x. IPC каждого ядра упал с~0{,}79 до~0{,}21. Как видно на Рисунке~\ref{fig:vecadd_strong}, реальное ускорение далеко от идеального. Ядра значительную часть времени простаивают в ожидании данных, что характерно для ситуаций, когда производительность ограничена подсистемой памяти. Данный эффект может быть связан как с аппаратными ограничениями пропускной способности памяти, так и с неоптимизированным размером рабочих групп (\enquote{work-group size}) при запуске OpenCL-ядра, что препятствует объединению запросов к памяти (\enquote{memory coalescing}).


А может быть корова.

Убрал недоказанные утверждения.

- Updated report file according to initial demands - Converted graphics format from PNG to PDF for LaTeX - Removed deprecated memory-bound/compute-bound terms from plots - Added research questions, tasks, and threats to validity per university template

…fixes - Added introduction section - Removed one incorrect goal from the report - Replaced links to sources of information and added new ones - Applied extensive cosmetic changes: * Turned 'е' into 'ё' where needed * Added \enquote{}, non-breaking spaces (~), and \hyphenation{} * Replaced dates with \DTMdate{} and fixed decimal separators (1{,}05x) * Turned Research Questions (RQs) into statements - Clarified that BRAM36 size is an approximate value - Edited the list of sources - Updated the Weak Scaling paragraph

ioughy force-pushed the main branch 3 times, most recently from d616b64 to cb49dc9 Compare June 8, 2026 17:45

ioughy changed the title ~~feat: add report on styding practice and images of graphics~~ feat: add Egor Makukhin’s report on styding practice and images of graphics Jun 11, 2026

gsvgit requested changes Jun 12, 2026

View reviewed changes

ioughy requested a review from gsvgit June 14, 2026 12:31

ioughy force-pushed the main branch 5 times, most recently from 9a44270 to 1d96a69 Compare June 14, 2026 18:55

gsvgit requested changes Jun 15, 2026

View reviewed changes

ioughy requested a review from gsvgit June 15, 2026 08:00

ioughy force-pushed the main branch 2 times, most recently from 18e2578 to fddd182 Compare June 15, 2026 15:15

ioughy added 7 commits July 13, 2026 23:54

feat: add report on styding practice and images of graphics

0361b9c

docs: update report (Revision of technologies)

c74350b

fix: update itemization in report

9fdf78f

docs: remove unproved statements from the report

2858f96

chore: update report according to the demands

7bd9689

ioughy force-pushed the main branch 2 times, most recently from 5d5dbff to b311366 Compare July 14, 2026 09:23

chore: update report

474a060

ioughy force-pushed the main branch from b311366 to 474a060 Compare July 14, 2026 09:43

ioughy added 3 commits July 20, 2026 10:57

chore: update report (remove part about BRAM)

a37452a

chore: update report

03e37b8

chore: update README

5954a06

chore: update report

37fd6b6


		\textbf{Целью работы является} освоение стека FPGA-симуляции проекта Vortex, проведение параметрического синтеза конфигураций и оценка эффективности масштабирования вычислительных ядер и кэш-иерархии с точки зрения производительности и потребления ресурсов ПЛИС.

		Результаты работы необходимы для понимания архитектурных узких мест (bottlenecks) архитектуры Vortex при решении memory-bound задач. Для конечных пользователей (разработчиков FPGA-ускорителей и исследователей архитектур) это полезно тем, что позволяет избежать неэффективного расходования ресурсов кремния (LUT, BRAM) при конфигурации GPU под потоковую обработку данных. В выполнении работы заинтересована лаборатория/кафедра для формирования рекомендаций по настройке экземпляров Vortex под различные классы задач.


		\section{Описание предлагаемого решения}

		Для достижения цели был предложен подход, основанный на автоматизированном прогоночном тестировании RTL-модели Vortex с последующим сбором метрик производительности и аналитической оценкой ресурсов ПЛИС. Идея решения заключается в варьировании двух главных архитектурных осей --- количества ядер и размера кэш-иерархии --- на двух классах задач: \enquote{memory-bound} (векторное сложение, \texttt{vecadd}) и \enquote{compute-bound} (умножение матриц, \texttt{sgemm}). В отличие от реальных ПЛИС или высокоуровневых симуляторов, использование RTL-симулятора обеспечивает цикл-точную достоверность результатов без затрат на FPGA-синтез и аппаратное развертывание.


		Для достижения цели был предложен подход, основанный на автоматизированном прогоночном тестировании RTL-модели Vortex с последующим сбором метрик производительности и аналитической оценкой ресурсов ПЛИС. Идея решения заключается в варьировании двух главных архитектурных осей --- количества ядер и размера кэш-иерархии --- на двух классах задач: \enquote{memory-bound} (векторное сложение, \texttt{vecadd}) и \enquote{compute-bound} (умножение матриц, \texttt{sgemm}). В отличие от реальных ПЛИС или высокоуровневых симуляторов, использование RTL-симулятора обеспечивает цикл-точную достоверность результатов без затрат на FPGA-синтез и аппаратное развертывание.

		Реализация решения осуществлялась с использованием RTL-симулятора \texttt{simx} из состава Vortex, скриптов сборки Bash, языка Python для парсинга логов и визуализации данных (pandas, matplotlib), а также аналитической модели оценки ресурсов ПЛИС Xilinx (расчет использования блочной памяти BRAM на основе объемов кэшей L1/L2/L3). Для обеспечения воспроизводимости результатов был разработан пайплайн автоматизации, позволяющий запускать серию экспериментов одной командой.


		Экспериментальное исследование проводилось в три этапа: Strong Scaling (фиксированный объем данных, рост ядер), Cache Scaling (фиксированное число ядер, рост кэша) и Weak Scaling (пропорциональный рост данных и ядер).

		Ввиду детерминированности RTL-симуляции (отсутствие системных прерываний и аппаратных задержек, присущих физическому железу), статистическая погрешность замеров отсутствует: математическое ожидание времени выполнения равно результату единичного замера, среднеквадратичное отклонение (СКО) равно нулю. Для оценки ресурсов ПЛИС применялась аналитическая модель: 1 блок BRAM = 4 КБ.


		Репозиторий с пайплайном автоматизации и исходными скриптами: \url{https://github.com/Makuhin-Egor/Vortex-experiments-styding-practice}.

		Техническая документация (README с описанием архитектуры и запуска): \url{https://github.com/Makuhin-Egor/Vortex-experiments-styding-practice/blob/main/README.md}.


		\section{Обзор используемых технологий}

		Исследование проводится на базе открытой GPGPU-архитектуры Vortex~\cite{vortex_repo}, реализованной на базе RISC-V ISA~\cite{riscv_isa}. В отличие от проприетарных решений (NVIDIA CUDA, AMD ROCm), Vortex предоставляет полностью открытый RTL-код, что делает его удобной платформой для архитектурных исследований.

Conversation

ioughy commented Jun 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gsvgit commented Jun 12, 2026

Uh oh!

gsvgit left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioughy Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 14, 2026 •

edited

Loading

ioughy Jun 15, 2026 •

edited

Loading