Added report by rmnsmnsk · Pull Request #14 · gsvgit/1_year_practice_2026_reports

rmnsmnsk · 2026-06-07T10:24:19Z

No description provided.

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

+
+\textbf{Целью работы является} сравнительный анализ производительности двух подходов к хранению и обработке разреженных матриц: собственной реализации на языке C с использованием формата COO (Coordinate List) и эталонной реализации на языке F\# с использованием иерархической структуры QuadTree (библиотека \texttt{QTreeFSharp}\footnote{URL: \url{https://github.com/Lamagraph/QTreeFSharp} (дата обращения: май 2026)}).
+
+Результаты работы необходимы для обоснования выбора архитектурных решений при разработке высокопроизводительных вычислительных систем. Для конечных пользователей (разработчиков численных методов, инженеров по оптимизации) это полезно пониманием компромиссов между простотой реализации и производительностью. В выполнении работы заинтересована кафедра системного программирования.


Ну, при сравнении F# и C Вы вряд ли что-то обосновать сможете....

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

+
+\section{Описание предлагаемого решения}
+
+Сравнение проводилось между двумя подходами к хранению разреженных матриц:


При таком оформлении тут точка в конце. Воообще, с точкой --- самый безопасный вариант.

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

+\begin{itemize}
+    \item \textbf{C (COO Format)}: собственная реализация на языке C, использующая формат (COO) с тремя плоскими массивами (индексы строк, индексы столбцов, значения). Управление памятью осуществляется вручную через \texttt{malloc}/\texttt{free}, аллокация производится единовременно при создании матрицы. Алгоритмы оптимизированы под последовательный доступ к памяти.
+
+    \item \textbf{F\# (QuadTree)}: эталонная библиотека \texttt{QTreeFSharp}, использующая иерархическую структуру QuadTree. Операции реализованы рекурсивно, управление памятью автоматическое (Garbage Collector), что приводит к созданию множества временных объектов в процессе вычислений.


Сам по себе GC (да и автоматическое управление в целом) к созданию множества объектов не приводит.

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

+    \item \textbf{F\# (QuadTree)}: эталонная библиотека \texttt{QTreeFSharp}, использующая иерархическую структуру QuadTree. Операции реализованы рекурсивно, управление памятью автоматическое (Garbage Collector), что приводит к созданию множества временных объектов в процессе вычислений.
+\end{itemize}
+
+Реализация решения осуществлялась с использованием языка C (стандарт C11, компилятор GCC 13), языка F\# (.NET 8.0), системы сборки CMake для C-части и .NET SDK для F\#-части. Для автоматизации бенчмарков использовались скрипты на Python 3.


Эээ. Ну на F# Вы же ничего не реализовывали.... Вроде...

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

+    \item \textbf{Инструменты замеров}:
+    \begin{itemize}
+        \item C: POSIX-таймер \texttt{gettimeofday()} с точностью до микросекунд, усреднение по 5 запускам.
+        \item F\#: для малых размеров (10--20) --- библиотека \texttt{BenchmarkDotNet} для получения статистики аллокаций и учёта влияния GC; для больших размеров (100--2000) --- \texttt{System.Diagnostics.Stopwatch}, так как код завершается с ошибкой до начала итераций BDN.


Хто такой BDN? Не надо странных сокращений.

gsvgit · 2026-06-12T06:25:37Z

+
+\begin{enumerate}
+    \item C-реализация опережает F\# в \textbf{5--2000 раз} на идентичных данных в зависимости от операции и размера матрицы.
+    \item Реализация на F\# создаёт тысячи временных объектов в куче (аллокации 62--403 КБ), что генерирует нагрузку на GC (Gen0: 10--65 на 1000 операций) и приводит к непредсказуемым паузам.


А непредсказуемые паузы точно бывают? Сборщики мусора разные встречаются...

gsvgit · 2026-06-12T06:30:52Z

+
+\section{Заключение}
+
+В ходе выполнения работы получены следующие результаты:


Точка.

gsvgit · 2026-06-12T06:31:10Z

+
+\begin{itemize}
+    \item Реализована собственная библиотека разреженной линейной алгебры на языке C в формате COO с операциями умножения матриц и матрицы на вектор.
+    \item Проведён сравнительный бенчмаркинг с эталонной реализацией на F\# (QuadTree) на синтетических и реальных матрицах.


Жаргон.

gsvgit · 2026-06-12T06:31:20Z

+\begin{itemize}
+    \item Реализована собственная библиотека разреженной линейной алгебры на языке C в формате COO с операциями умножения матриц и матрицы на вектор.
+    \item Проведён сравнительный бенчмаркинг с эталонной реализацией на F\# (QuadTree) на синтетических и реальных матрицах.
+    \item Продемонстрировано преимущество плоских форматов хранения: ускорение в 5--2000 раз, отсутствие проблем с переполнением стека, предсказуемое потребление памяти.


gsvgit · 2026-06-12T06:33:27Z

+    \item Исследована проблема Stack Overflow в эталонной библиотеке, даны рекомендации по диагностике различий в поведении кода в разных средах.
+\end{itemize}
+
+Материалы, иллюстрирующие выполнение работы, размещены по адресу: \url{https://github.com/rmnsmnsk/implementation-of-linear-algebra-primitives} (исходный код, скрипты бенчмарков, README).


CI сгенерированный нейронкой в порядок приведите. А то там там такого позора понаписано...

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

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

…26_reports

gsvgit

Ну и вёрска перечислений. Жду улучшения промта.

gsvgit · 2026-07-14T06:09:37Z

+
+Умножение матрицы на вектор выполняется с использованием плотного промежуточного массива: вектор разворачивается в плотную форму, затем выполняется накопление результатов в плотном массиве, который в конце преобразуется обратно в разреженный формат COO. Аналогичным образом реализовано умножение вектора-строки на матрицу.
+
+Такой подход обеспечивает простоту реализации и наглядность кода, однако сопровождается значительными накладными расходами: квадратичная сортировка, линейный поиск при добавлении элементов и многократные преобразования между разреженным и плотным представлениями создают дополнительную вычислительную нагрузку.


а за n logn не умеете сортировать?

А добавление в неупорядоченный что ли? Не понятно, откуда линейнй поиск. Может таки тогда словарь использовать?

gsvgit · 2026-07-14T06:13:33Z

+\label{tab:accel_vec}
+\begin{tabular}{lrrr}
+\toprule
+Матрица & NNZ & Плотность, \% & Ускорение, раз \\


А зачем столько таблиц с кучей дублирующейся информации?

gsvgit · 2026-07-14T06:14:13Z

+
+\begin{itemize}
+
+\item при умножении матриц в COO выполняется предварительная сортировка элементов для упорядочивания данных, что само по себе требует дополнительного времени. Затем происходит полный перебор всех пар ненулевых элементов обеих матриц. Для каждого совпадения индексов выполняется линейный поиск по уже накопленному массиву результата, чтобы проверить, не добавлялся ли уже элемент с такими координатами. По мере заполнения результата время этого поиска возрастает. CSparse использует специализированные алгоритмы, которые избегают таких линейных поисков за счёт эффективной структуры данных.


"эффективной структуры данных" Какой? А что Вам помешало её применить?

gsvgit · 2026-07-14T06:14:42Z

+
+\item при умножении матриц в COO выполняется предварительная сортировка элементов для упорядочивания данных, что само по себе требует дополнительного времени. Затем происходит полный перебор всех пар ненулевых элементов обеих матриц. Для каждого совпадения индексов выполняется линейный поиск по уже накопленному массиву результата, чтобы проверить, не добавлялся ли уже элемент с такими координатами. По мере заполнения результата время этого поиска возрастает. CSparse использует специализированные алгоритмы, которые избегают таких линейных поисков за счёт эффективной структуры данных.
+
+\item при умножении матрицы на вектор в COO разреженный вектор сначала разворачивается в плотный массив, затем создаётся временный массив для накопления результата, который в конце снова упаковывается в разреженный формат COO. Эти многократные преобразования создают существенные накладные расходы.


Так может стоит этого избежать?

gsvgit · 2026-07-14T06:15:27Z

+
+\begin{itemize}
+
+\item при умножении матриц в COO выполняется предварительная сортировка элементов для упорядочивания данных, что само по себе требует дополнительного времени. Затем происходит полный перебор всех пар ненулевых элементов обеих матриц. Для каждого совпадения индексов выполняется линейный поиск по уже накопленному массиву результата, чтобы проверить, не добавлялся ли уже элемент с такими координатами. По мере заполнения результата время этого поиска возрастает. CSparse использует специализированные алгоритмы, которые избегают таких линейных поисков за счёт эффективной структуры данных.


Зачем ещё раз описывать алгоритм?

rmnsmnsk and others added 2 commits June 7, 2026 13:21

Added report

39cdacd

Merge branch 'main' into main

b5c29cf

gsvgit requested changes Jun 12, 2026

View reviewed changes

rmnsmnsk and others added 13 commits June 13, 2026 17:35

Updated report

3f3d981

Merge branch 'main' into main

bb6eb06

Changed report

4cb3f5b

Another changes

c278122

Another changes

e0050f5

Misprint

538fa20

Merge branch 'main' into main

ddad114

Changed report

404bc28

Merge branch 'main' of https://github.com/rmnsmnsk/1_year_practice_20…

6147b11

…26_reports

Some changes

cd17614

Updated the report (added matrix-vector multiplication).

a8c6808

Updated report

1d46953

Added missing parts

c46439c

gsvgit requested changes Jul 14, 2026

View reviewed changes

rmnsmnsk added 2 commits July 14, 2026 14:44

Updated report

74e61ee

Updated graph

fcc7b3f


		\textbf{Целью работы является} сравнительный анализ производительности двух подходов к хранению и обработке разреженных матриц: собственной реализации на языке C с использованием формата COO (Coordinate List) и эталонной реализации на языке F\# с использованием иерархической структуры QuadTree (библиотека \texttt{QTreeFSharp}\footnote{URL: \url{https://github.com/Lamagraph/QTreeFSharp} (дата обращения: май 2026)}).

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


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

		Сравнение проводилось между двумя подходами к хранению разреженных матриц:


		\section{Заключение}

		В ходе выполнения работы получены следующие результаты:


		Умножение матрицы на вектор выполняется с использованием плотного промежуточного массива: вектор разворачивается в плотную форму, затем выполняется накопление результатов в плотном массиве, который в конце преобразуется обратно в разреженный формат COO. Аналогичным образом реализовано умножение вектора-строки на матрицу.

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


		\begin{itemize}

		\item при умножении матриц в COO выполняется предварительная сортировка элементов для упорядочивания данных, что само по себе требует дополнительного времени. Затем происходит полный перебор всех пар ненулевых элементов обеих матриц. Для каждого совпадения индексов выполняется линейный поиск по уже накопленному массиву результата, чтобы проверить, не добавлялся ли уже элемент с такими координатами. По мере заполнения результата время этого поиска возрастает. CSparse использует специализированные алгоритмы, которые избегают таких линейных поисков за счёт эффективной структуры данных.


		\item при умножении матриц в COO выполняется предварительная сортировка элементов для упорядочивания данных, что само по себе требует дополнительного времени. Затем происходит полный перебор всех пар ненулевых элементов обеих матриц. Для каждого совпадения индексов выполняется линейный поиск по уже накопленному массиву результата, чтобы проверить, не добавлялся ли уже элемент с такими координатами. По мере заполнения результата время этого поиска возрастает. CSparse использует специализированные алгоритмы, которые избегают таких линейных поисков за счёт эффективной структуры данных.

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

Conversation

rmnsmnsk commented Jun 7, 2026

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!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants