add report from Taranukha Leonid by LeoN192 · Pull Request #19 · gsvgit/1_year_practice_2026_reports

LeoN192 · 2026-06-12T10:26:00Z

No description provided.

gsvgit

Подобно чуть позже гляну, но графики лучше готовыми в чем-то типа matplotlib сделать.

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

+    {\Large \textbf{Реализация типа \enquote{Множество} на основе АВЛ-дерева на языке F\#}}\\[1.5cm]
+
+    \begin{flushright}
+    \begin{tabular}{rl}


Мне кажется, в шаблоне шапка иначе устроена?

gsvgit · 2026-06-13T06:28:24Z

+\begin{document}
+
+\begin{center}
+    {\large САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ}\\[0.3cm]


Что? Следуйте шаблону.

gsvgit · 2026-06-13T06:28:42Z

+
+\section{Постановка задачи}
+
+Данная работа посвящена реализации неизменяемой структуры данных \enquote{Множество} на основе АВЛ-дерева на языке F\#. Проект выполняется в рамках открытого исследовательского сообщества Lamagraph и интегрируется в репозиторий QTreeFSharp --- прототип сетей взаимодействия для анализа данных методами линейной алгебры.


Неразрывные пробелы перед тире.

"прототип сетей взаимодействия для анализа данных методами линейной алгебры" --- вообще нет.

gsvgit · 2026-06-13T06:29:44Z

+
+Данная работа посвящена реализации неизменяемой структуры данных \enquote{Множество} на основе АВЛ-дерева на языке F\#. Проект выполняется в рамках открытого исследовательского сообщества Lamagraph и интегрируется в репозиторий QTreeFSharp --- прототип сетей взаимодействия для анализа данных методами линейной алгебры.
+
+Фундаментальные графовые алгоритмы требуют эффективных структур для хранения уникальных элементов и выполнения теоретико-множественных операций. 


Они "алгоритмы анализа графов".

gsvgit · 2026-06-13T06:30:06Z

+
+Фундаментальные графовые алгоритмы требуют эффективных структур для хранения уникальных элементов и выполнения теоретико-множественных операций. 
+
+\textbf{Целью работы является} реализация структуры данных \enquote{Множество} с автоматической балансировкой и оценка ее производительности.


Само множество не балансируется.

gsvgit · 2026-06-13T06:35:38Z

+Профилирование выполнялось с помощью библиотеки \verb|BenchmarkDotNet| (ОС Ubuntu 24.04.4 LTS, .NET 10.0.7, процессор Intel Core i5-12450H). Размер базового множества $A$ варьировался от $100$ до $100\,000$ элементов. Размер вторичного множества $B$ составлял $100$ и $10\,000$ элементов.
+
+\subsection{Одиночные операции}
+Результаты замеров для одиночных операций показывают сложность $O(\log N)$. Увеличение количества узлов на три порядка (со 100 до 100\,000) приводит к росту времени выполнения вставки с 582~нс до 1376~нс. Объем выделяемой памяти изменяется логарифмически от 840 до 2080 байт на операцию.


Результаты практических замеров крайне редко показывают теоретическую оценку.

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

gsvgit · 2026-06-13T06:38:06Z

+    \item Реализована структура данных АВЛ-Множества на языке F\#.
+    \item Разработаны алгоритмы теоретико-множественных операций в трех вариантах (последовательный, обход, многопоточный).
+    \item Написаны модульные и property-based тесты.
+    \item Проведено профилирование, на основе которого выявлены условия применимости параллельного метода и метода обхода дерева.


Таки профилирование было?

gsvgit · 2026-06-13T06:38:15Z

+    \item Проведено профилирование, на основе которого выявлены условия применимости параллельного метода и метода обхода дерева.
+\end{itemize}
+
+Кодовая база и результаты тестов размещены в открытом доступе:


Точка.

gsvgit · 2026-06-13T06:38:51Z

+
+\newpage
+\appendix
+\section{Приложение: Результаты профилирования}


Либо это ценно и в остновном тексте, либо нафиг удпалить.

gsvgit · 2026-06-13T06:39:14Z

+    \item Pull Request: \url{https://github.com/Lamagraph/QTreeFSharp/pull/17}
+\end{itemize}
+
+\section*{Литература}


В шаблоне были примеры оформления литературы.

gsvgit · 2026-06-14T06:08:40Z

+
+\section{Эксперименты}
+
+Бенчмаркинг выполнялся с помощью библиотеки \verb|BenchmarkDotNet| (ОС Ubuntu 24.04.4 LTS, .NET 10.0.7, процессор Intel Core i5-12450H). Размер базового множества $A$ варьировался от $100$ до $100\,000$ элементов. Размер вторичного множества $B$ составлял $100$, $10\,000$ и $100\,000$ элементов для оценки производительности алгоритмов при различных масштабах данных. 


бенчмаркинг --- жаргон.

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

+
+Бенчмаркинг выполнялся с помощью библиотеки \verb|BenchmarkDotNet| (ОС Ubuntu 24.04.4 LTS, .NET 10.0.7, процессор Intel Core i5-12450H). Размер базового множества $A$ варьировался от $100$ до $100\,000$ элементов. Размер вторичного множества $B$ составлял $100$, $10\,000$ и $100\,000$ элементов для оценки производительности алгоритмов при различных масштабах данных. 
+
+В таблице~\ref{tab:summary} представлены замеры, демонстрирующие крайние случаи алгоритмического поведения.


"крайние случаи алгоритмического поведения" -- чо?

gsvgit · 2026-06-14T06:09:41Z

+\end{table}
+
+\subsection{Одиночные операции}
+Результаты замеров для одиночных операций соотносятся с предполагаемой сложностью $O(\log N)$. Увеличение количества узлов на три порядка (со 100 до 100\,000) приводит к росту времени выполнения вставки с 582~нс до 1376~нс. Объем выделяемой памяти изменяется логарифмически от 840 до 2080 байт на операцию.


gsvgit · 2026-06-14T06:10:56Z

+\label{fig:parallel}
+\end{figure}
+
+Многопоточная реализация уступает последовательной во всех рассмотренных сценариях. При пересечении множеств $10\,000 \times 100\,000$ последовательный алгоритм выполняется за $15,4$~мс, в то время как параллельный на четырех потоках~--- за $354,3$~мс. Снижение производительности обусловлено накладными расходами пула потоков на планирование множества микрозадач и интенсивной работой сборщика мусора.


Как выяснили, в чём именно проблема с парарллельностью? Может она у Вас просто неправильно сделана.

gsvgit · 2026-06-15T06:42:04Z

+\label{fig:parallel}
+\end{figure}
+
+Многопоточная реализация уступает последовательной во всех рассмотренных сценариях. При пересечении множеств $10\,000 \times 100\,000$ последовательный алгоритм выполняется за $15,4$~мс, в то время как параллельный на четырех потоках~--- за $354,3$~мс. Снижение производительности обусловлено отсутствием порога отсечения\footnote{\textbf{Порог отсечения} --- размер задачи, ниже которого накладные расходы на создание и планирование новых потоков начинают снижать производительность. По достижении этого порога необходимо начать последовательное выполнение.} для \verb|Async.Parallel| в данной реализации. Накладные расходы на планирование тысяч микрозадач и паузы сборщика мусора из-за возросшего потребления памяти (с 18 до 100,2~МБ) многократно увеличивают время выполнения.


Пробел. Тире.

Сделано

gsvgit · 2026-06-15T06:44:42Z

+Добавление & $100 \times \text{---}$ & Sequential & 582 нс & 880 Б & 1.00 (Эталон) \\
+Добавление & $100\,000 \times \text{---}$ & Sequential & 1376 нс & 2080 Б & $\approx 2.3\times$ \\
+\midrule
+Пересечение & $100\,000 \times 100$ & Sequential & 318 мкс & 447 КБ & 1.00 (Эталон) \\


Лучше всё в одинаковых единицах указывать. Ещё и с одинаковой точностью. Проще анализировать и сравнивать. А то переводи нано в микро и обратоно.

Мкс перевел в нс, но мс оставил

gsvgit · 2026-06-15T06:45:10Z

+\end{table}
+
+\subsection{Одиночные операции}
+Анализ результатов замеров показывает логарифмический характер роста времени выполнения базовых операций. Отношение максимальных высот АВЛ-деревьев (возможных) для $N=100\,000$ и $N=100$ составляет $\approx 2,5$ ($\log_2 10^5 / \log_2 10^2$). На практике время выполнения операции добавления выросло с 582~нс до 1376~нс (коэффициент роста $\approx 2,36$), что согласуется с ожидаемым поведением деревьев и их высотами. Объем выделяемой памяти изменяется от 840 до 2080 байт на операцию.


"логарифмический характер" --- почему?

Если что, "$\approx 2,5$" --- не пояснение.

Переделал формулировку

gsvgit · 2026-06-15T06:47:03Z

+\label{fig:parallel}
+\end{figure}
+
+Многопоточная реализация уступает последовательной во всех рассмотренных сценариях. При пересечении множеств $10\,000 \times 100\,000$ последовательный алгоритм выполняется за $15,4$~мс, в то время как параллельный на четырех потоках~--- за $354,3$~мс. Снижение производительности обусловлено отсутствием порога отсечения\footnote{\textbf{Порог отсечения} --- размер задачи, ниже которого накладные расходы на создание и планирование новых потоков начинают снижать производительность. По достижении этого порога необходимо начать последовательное выполнение.} для \verb|Async.Parallel| в данной реализации. Накладные расходы на планирование тысяч микрозадач и паузы сборщика мусора из-за возросшего потребления памяти (с 18 до 100,2~МБ) многократно увеличивают время выполнения.


Так может стоит сделать порог? А то "я сделал фигню, даже знаю, как сделать не фигню, но делать, конечно же, не буду".

Я добавил порог, теперь параллельный стал быстрее
Сейчас буду пушить это в основной репозиторий

Быстрее не просто в общем, а именно последовательной реализации

gsvgit · 2026-06-15T06:47:35Z

 {Ekaterina_Arzamaszeva/Ekaterina_Arzamaszeva_report.pdf}
-\end{document}
+\includepdf[pages=-,
+    addtotoc={1, section, 1, {Тарануха Леонид Антонович, Реализация типа "Множество" на основе АВЛ-дерева на языке F\#}, taranukha_leonid}]


Это неправильные кавычки.

Исправил

gsvgit · 2026-06-15T13:37:06Z

+Реализовано три подхода к операциям над множествами.
+
+\begin{enumerate}
+    \item \textbf{Последовательный (Sequential):} Базовый алгоритм рекурсивного слияния. Использует функции \verb|split| (разделение дерева по ключу) и \verb|join| (слияние). Является эталоном производительности.


Ай. Ну откуда тут двоеточие?

gsvgit · 2026-06-15T13:39:44Z

+\toprule
+\textbf{Операция} & \textbf{Размеры ($A \times B$)} & \textbf{Метод} & \textbf{Время} & \textbf{Память} & \textbf{Отношение} \\
+\midrule
+Добавление & $100 \times \text{---}$ & Sequential & 582 нс & 880 Б & 1.00 (Эталон) \\


А с памятью?

Ну зачееем. Во-первых, единицы не надо писать в каждой ячейке. Во-вторых, выберите что-то, что позволит в одном масштабе всё записать. Может секунды с двумя-тремя знаками после запятой. Если проблема, может дело в том, что эксперименты странно поставлены? В чём цель эксперимента.

gsvgit · 2026-06-15T13:42:42Z

+\label{fig:parallel}
+\end{figure}
+
+Введение порога отсечения (granularity threshold) позволило многопоточной реализации продемонстрировать высокую эффективность. Алгоритм прекращает создание асинхронных задач и переключается на последовательное выполнение для поддеревьев с высотой $h < 10$. 


А это точно лучшее решение? Может стоило ограничиения привязать к доступным ядрам/потокам?

LeoN192 added 6 commits June 10, 2026 14:08

add report from Taranukha Leonid

d445ae7

fix main.tex

e6f6f81

fix report

7cea992

change report

6ae99f9

change report #2

176410c

resolve conflicts

91ea8d0

gsvgit requested changes Jun 12, 2026

View reviewed changes

fix compilation error

86f3471

gsvgit requested changes Jun 13, 2026

View reviewed changes

LeoN192 added 3 commits June 13, 2026 19:40

fix report #3

1f9dc9b

fix sentence in report

5b87001

improve report

bfe6149

gsvgit requested changes Jun 14, 2026

View reviewed changes

LeoN192 added 2 commits June 14, 2026 13:49

fix report #4

96541fd

resolve conflicts

6cdcf04

gsvgit requested changes Jun 15, 2026

View reviewed changes

LeoN192 added 4 commits June 15, 2026 13:58

fix report gsvgit#5

169d357

resolve conflicts #2

1aeebc0

fix graph

5805a70

fix comp err

cb39f21

gsvgit requested changes Jun 15, 2026

View reviewed changes


		\section{Постановка задачи}

		Данная работа посвящена реализации неизменяемой структуры данных \enquote{Множество} на основе АВЛ-дерева на языке F\#. Проект выполняется в рамках открытого исследовательского сообщества Lamagraph и интегрируется в репозиторий QTreeFSharp --- прототип сетей взаимодействия для анализа данных методами линейной алгебры.


		Данная работа посвящена реализации неизменяемой структуры данных \enquote{Множество} на основе АВЛ-дерева на языке F\#. Проект выполняется в рамках открытого исследовательского сообщества Lamagraph и интегрируется в репозиторий QTreeFSharp --- прототип сетей взаимодействия для анализа данных методами линейной алгебры.

		Фундаментальные графовые алгоритмы требуют эффективных структур для хранения уникальных элементов и выполнения теоретико-множественных операций.


		Фундаментальные графовые алгоритмы требуют эффективных структур для хранения уникальных элементов и выполнения теоретико-множественных операций.

		\textbf{Целью работы является} реализация структуры данных \enquote{Множество} с автоматической балансировкой и оценка ее производительности.


		\section{Эксперименты}

		Бенчмаркинг выполнялся с помощью библиотеки \verb\|BenchmarkDotNet\| (ОС Ubuntu 24.04.4 LTS, .NET 10.0.7, процессор Intel Core i5-12450H). Размер базового множества $A$ варьировался от $100$ до $100\,000$ элементов. Размер вторичного множества $B$ составлял $100$, $10\,000$ и $100\,000$ элементов для оценки производительности алгоритмов при различных масштабах данных.


		Бенчмаркинг выполнялся с помощью библиотеки \verb\|BenchmarkDotNet\| (ОС Ubuntu 24.04.4 LTS, .NET 10.0.7, процессор Intel Core i5-12450H). Размер базового множества $A$ варьировался от $100$ до $100\,000$ элементов. Размер вторичного множества $B$ составлял $100$, $10\,000$ и $100\,000$ элементов для оценки производительности алгоритмов при различных масштабах данных.

		В таблице~\ref{tab:summary} представлены замеры, демонстрирующие крайние случаи алгоритмического поведения.

Conversation

LeoN192 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!

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!

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!

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