docs: add GPGPU, CUDA, OpenCL historical section with references

main.typ

@@ -1,10 +1,14 @@
+#let text-indentation = 1.25cm
+#let text-size = 14pt
+#let leading = 1em
+
 #set text(
   font: "Times New Roman",
-  size: 14pt,
+  size: text-size,
   lang: "ru"
 )
 
-#show heading: set text(size: 14pt)
+#show heading: set text(size: text-size)
 
 #set page(
   paper: "a4",
@@ -14,25 +18,28 @@
     left: 3cm,
     right: 1cm
   ),
-
   numbering: "1"
 )
 
 #set heading(
   numbering: "1.1.1.1",
 )
-#show heading.where(level: 1): set block(below: 2em)
+#show heading.where(level: 1): set block(below: leading*2)
+#show heading.where(level: 2): set block(above: leading*2, below: leading*2)
+#show heading.where(level: 3): set block(above: leading*2, below: leading*2)
+#show heading: it => pad(left: text-indentation, it)
+#show figure: it => pad(top: leading, bottom: leading, it)
 
 #set par(
   justify: true,
-  leading: 1em,
+  leading: leading,
   first-line-indent: (
-    amount: 1.25cm, 
+    amount: text-indentation, 
     all: true
   ),
 )
 
-#show "〜": h(1.25cm)
+#show "〜": h(text-indentation)
 
 #align(
   center, 
@@ -45,11 +52,14 @@
 
 #align(
   center,
+  pad(
+    left: -text-indentation,
     heading(
       numbering: none,
       "Введение"
     )
   )
+)
 
 *Актуальность темы*: развитие технологий тесно связано с ростом объёмов обрабатываемых данных, особенно в сфере искусственного интеллекта. В связи с этим история высокопроизводительных вычислений становится как никогда актуальной. Рост массивов данных, развитие ИИ и необходимость ускорения вычислений делают историю языков и моделей программирования для HPC особенно важной. Эволюция подходов позволяет оптимизировать параллельные вычисления на суперкомпьютерах и ускорителях вроде GPU. Ограничения аппаратного обеспечения и растая сложность задач, требующих распределённой обработки, ведут к появлению новых вычислительных моделей.
 
@@ -63,13 +73,232 @@
 
 #pagebreak()
 
+= Ранние языки для научных расчётов
+
+== Fortran -- первый язык для научных вычислений
+
+Fortran (аббревиатура от *FOR*-mula *TRAN*-slation, "транслятор формул") разработан командой IBM под руководством Джона Бэкуса в 1954–1957 годах. Первая версия (Fortran I) выпущена в 1957 для компьютера IBM 704@noauthor_fortran_nodate. Проект начался из-за того, что написание программ в машинных кодах было крайне трудоёмким, как характеризовал этот процесс сам Бэкус: "Рукопашный бой с машиной@noauthor_fortran_nodate."
+
+Ключевой проблемой был разрыв между мышлением учёных и инженеров -- формулами -- и тем, что понимала машина -- машинные коды. Fortran был сделан так, что код на этом языке был довольно близок к математической нотации (@listing-1).
+
+#figure(
+  ```f90
+  Y = A*X**2 + B*X + C
+  ```,
+  caption: [Пример кода на языке Fortran]
+) <listing-1>
+
+Такой подход позволил уменьшить как объёмы кода, так и снизить количество ошибок при его написании.
+
+Компиляторы Fortran принесли новые виды оптимизации кода: развёртку циклов, распределение регистров, оптимизация повторяющихся подвыражений и другие. Что особенно важно -- генерируемый код был сопоставим по эффективности с ассемблерным кодом, написанным вручную, а иногда даже быстрее. 
+
+Таким образом, Fortran стал фундаментом для высокопроизводительных вычислений:
+
+#list(
+  [
+    стандартизация научных расчётов: общий язык для численного программирования;
+  ],
+  [
+    библиотеки: BLAS, LINPACK/LAPACK и другие фундаментальные библиотеки написаны на Fortran;
+  ],
+  [
+    портируемость: код можно было переносить между разными компьютерами, для которых был доступен компилятор Fortran;
+  ],
+  [
+    долголетие: современные версии до сих пор используются в суперкомпьютерных центрах.
+  ],
+  marker: "-",
+  indent: text-indentation,
+)
+
+При этом разработка и улучшение Fortran не остановилась, отдельные его модули и библиотеки до сих пор используются для высокопроизводительных вычислений, а последняя версия языка была выпущена в 2023 году.
+
+== Алгол, Лисп и компиляторы
+
+Но не Фортраном единым замыкается разработка программ. 
+
+=== Algol
+
+В 1958 году комитетом европейских и американских учёных на съезде в институте ETH в Цюрихе был разработан язык программирования ALGOL (аббревиатура от *ALGO*-rithmic *L*-anguage, "алгоритмический язык"), точнее его вариант ALGOL 58 @noauthor_why_nodate.
+
+В ходе разработки языка были выведены его ключевые концепции:
+
+#list(
+  [ блочная структура программ; ],
+  [ разрешение рекурсии; ],
+  [ формальное описание синтаксиса в форме BNF-нотации. ],
+  marker: "-",
+  indent: text-indentation,
+)
+
+Многи последующие императивные языки программирования позаимствовали синтаксис Алгола -- но стоит отметить, что сам язык широкого распространения за пределами научных вычислений не получил.
+
+=== Lisp
+
+В 1985 году Джон Маккарти представил миру Lisp (аббревиатура от *Lis*-t *P*-rocessing) -- язык программирования для символьных вычислений и ИИ @wexelblat_history_1978.
+
+Особенностями языка можно назвать:
+
+#list(
+  [ "функции первого класса" -- их можно передавать, возвращать и проводить композицию; ],
+  [ каррирование -- преобразование функции множества аргументов в набор вложенных функций; ],
+  [ отсутсвие циклов -- их заменили рекурсией; ],
+  [ универсальная структура данных -- список; ],
+  [ символьное дифференцирование; ],
+  marker: "-",
+  indent: text-indentation,
+)
+
+Lisp позже повлияли на Python (list comprehensions), JavaScript (функции высшего порядка), языки типа Haskell, Scala и другие.
+
+Также этот язык является прародителем функционального программирования, хотя он и является мультипарадигменным.
+
+=== Оптимизирующая компиляция
+
+Как уже было сказано ранее, компилторы стали применять систематические оптимизации.
+
+Ключевые достижения:
+
+#list(
+  [ компилятор Fortran мог генерировать более эффективный ассемблерный код, по сравнению с человеком; ],
+  [ анализ потока данных @hecht_flow_1977; ],
+  [ алгоритмы оптимизации графов (например, "алгоритм Хайтина" для раскраски графов и последующего распределения регистров); ],
+  marker: "-",
+  indent: text-indentation,
+)
+
+Для HPC оптимизирующие компиляторы стали критическим звеном между абстрактным кодом и эффективным использованием железа. Современные компиляторы (GCC, LLVM, Intel ICC) применяют сотни проходов оптимизации: векторизацию, предсказание переходов, межпроцедурную оптимизацию, полиэдрическую оптимизацию для вложенных циклов, однако база была заложена давно.
+
+#pagebreak()
+
+= Векторные- и суперкомпьютеры
+
+== Концепция векторных вычислений
+
+Векторные вычисления представляют собой фундаментальную ступень развития высокопроизводительных вычислительных систем, которая позволила достичь качественного скачка в производительности при решении задач, требующих обработки больших однородных массивов данных.
+
+=== Суперкомпьютеры Cray и становление векторной обработки
+
+Компания Cray Research, основанная Сеймуром Креем в 1972 году, стала пионером в области векторных суперкомпьютеров. Первая машина серии Cray-1, представленная в 1976 году, продемонстрировала революционный подход к организации вычислений@noauthor__nodate. Архитектура системы была построена на принципе конвейерной обработки векторных данных, что позволяло выполнять одну операцию над множеством элементов данных одновременно. Главная память машины состояла из 16 независимых блоков по 64 тысячи машинных слов каждый, а 12 функциональных модулей позволяли выполнять логические, скалярные и векторные операции над этими данными с высокой степенью параллелизма.
+
+Ключевое преимущество векторной архитектуры заключалось в том, что одна векторная инструкция заменяла целый цикл скалярных операций. Это сокращало количество необходимых к исполнению команд и устраняло накладные расходы на управление циклами. Для научных и инженерных расчетов, где типичными являются операции с матрицами и массивами данных, такой подход обеспечивал многократное ускорение по сравнению со скалярными процессорами того времени.
+
+=== Модель SIMD как основа векторизации
+
+Концептуальной основой векторных вычислений стала модель SIMD, сформулированная в таксономии Флинна@flynn_very_1966. В своей ранней реализации эта модель предполагала, что один поток команд управляет обработкой множества потоков данных параллельно. Векторный процессор фактически реализовывал данную парадигму аппаратно: единственная векторная инструкция запускала идентичную операцию над всеми элементами векторного регистра.
+
+Важно отметить, что ранняя форма SIMD в векторных суперкомпьютерах и современные векторные расширения процессоров существенно отличаются. Векторные машины работали с векторами переменной длины и обладали специализированными конвейерами для различных типов операций, а SIMD-расширения современных процессоров оперируют фиксированными по размеру векторами для исполнения этих операций ничего кроме самого процессора не требуется.
+
+=== Векторные расширения в языке Fortran
+
+Параллельно с развитием аппаратных векторных систем происходила эволюция программных средств, позволяющих эффективно использовать возможности векторной обработки@chang_support_2004. Язык Fortran в стандарте Fortran 90 получил расширение в виде конструкции для работы с массивами как с едиными объектами, что позволяло программистам того времени выражать векторные операции в знакомой математической нотации.
+
+Компиляторы Fortran получили возможность автоматической векторизации циклов, распознавая паттерны кода, которые могли быть преобразованы в векторные инструкции@allen_automatic_1987. Это означало, что существующий код мог быть оптимизирован для векторных архитектур без полного переписывания, хотя наибольшая эффективность достигалась при использовании явных векторных конструкций языка. Появление директив компилятора также позволило программистам явно управлять процессом векторизации, указывая компилятору на возможности параллелизма в коде.
+
+Развитие векторных вычислений заложило основу для современных параллельных архитектур и продолжает оставаться актуальным в контексте современных процессоров с SIMD-расширениями и графических ускорителей, использующих сходные принципы обработки данных.
+
+== Новые компиляторные оптимизации
+
+Параллельно с развитием векторных архитектур происходила модернизация в технологиях компиляции, направленная на максимальное использование возможностей современного оборудования. Компиляторы превращались из простых трансляторов высокоуровневого кода в машинный в сложные системы оптимизации, способные радикально трансформировать программу для достижения максимальной производительности.
+
+Центральной задачей стала векторизация циклов. Компиляторы научились анализировать структуру циклов и определять, можно ли безопасно преобразовать последовательные итерации в единую векторную операцию. Для успешной векторизации цикла компилятору необходимо доказать, что между итерациями отсутствуют зависимости, так как в обратном случае применение векторных оперций приведёт к некорректным результатам вычисления.
+
+Неполное разворачивание циклов стало одной из ключевых техник оптимизации -- компилятор мог группировать несколько итераций цикла, что давало ему возможность переупорядочить инструкции и уже затем, возможно, заменить их векторными операциями. Цикл всё ещё присутствует, но он может быть значительно меньше оригинального варианта.
+
+Компиляторы, такие как для TI ASC и Cray Fortran, анализировали циклы на отсутствие зависимостей данных между итерациями, чтобы преобразовать последовательный код в векторные операции@morgan_compiling_2018. Это обеспечивало безопасность параллелизма без изменения результатов программы. Методы включали решение систем диофантовых уравнений для доказательства независимости.
+
+Программисты использовали директивы (например, Cray VECTOR directives@noauthor_vectorization_nodate) для подсказок компилятору о безопасной векторизации при неполном статическом анализе. Межпроцедурный анализ учитывал вызовы функций для глобальной векторизации, как в Convex Application Compiler. Эти нововведения легли в основу современных компиляторов.
+
+#pagebreak()
+
+= Эра массового параллелизма и распределённых систем
+
+== Переход к архитектуре MIMD
+
+Сдвиг в сторону MIMD@flynn_very_1966 означал отход от прежних парадигм векторной обработки и одиночных инструкций. Этот переход был обусловлен как технологической осуществимостью, так и признанием того факта, что многие реальные вычислительные задачи требовали гибкости в том, как различные элементы конвейера обработки могли работать независимо друг от друга.
+
+В этот период начали появляться многоядерные системы, хотя по сравнению с современными реализациями они были еще в зачаточном состоянии. Ранние кластеры собирались из стандартных рабочих станций, объединяемых сетевой инфраструктурой. Оказалось, что не обязательно нужны специализированные монолитные суперкомпьютеры для получения больших вычислительных мощностей. Первые такие кластерные системы заложили основу для современных архитектур центров обработки данных и инфраструктуры облачных вычислений.
+
+== Языки программирования и параллельные вычисления
+
+С расширением возможностей аппаратного обеспечения все более актуальной становилась задача выражения параллельных вычислений в языках программирования. Появилось несколько подходов, каждый из которых отражал различные философские представления о том, как программисты должны концептуализировать параллельное выполнение кода.
+
+=== Occam и модель CSP
+
+Occam, разработанный в начале 1980-х годов группой учёных из Оксфордского университета, являлся реализацией модели CSP (Communicating Sequential Processes, Теория Взаимодействующих Последовательных Процессов) -- сформулированной Тони Хоаром в нескольких работах@hoare_communicating_1978.
+
+В Occam процессы считаются фундаментальными единицами, коммуницирующими друг с другом посредством "передачи сообщений", что предоставляет сильную теоретическую основу для рассуждений о параллельном поведении программ.
+
+Однако CSP, в разрезе параллельного программирования, повлияла не только на Occam, но и заложила концепции, применяемые в параллельном программировании по сей день: такие как синхронная передача сообщений через каналы и отсутствие общих переменных между процессами. Эти идеи активно применяются в современных языках, включая Go (горутины и каналы), Erlang, Limbo и `core.async` в Clojure.
+
+=== High Performance Fortran (HPF) и его ограничения
+
+HPF стал попыткой расширения языка программирования Fortran путём добавления директив, позволяющих компиляторам автоматически разделять код для последующего его исполнения на распределённых системах. И хотя в проект были вложены немалые ресурсы, он столкнулся с проблемой чистой компиляторной оптимизации.
+
+Оказалось, что автоматически распределять векторные операции по несколькуим хостам -- не такая простая задача, что привело к ограниченному использованию HPF, по сравнению с другими, более "ручными" вариантами.
+
+=== Message Passing Interface (MPI)
+
+В 1994 году появился стандарт MPI, который вместо попыток автоматической параллелизации или создания нового языка программирования предоставлял стандартизированную библиотеку обмена сообщениями между процессами. Такой подход, в противопоставление HPF, предоставлял разработчикам полный прямой контроль над межпроцессорным взаимодействием, оставляя, однако, сложные механизмы передачи сообщений "за кадром" разработки. Такой подход также упростил переносимость кода между платформами. В общем и целом, всё вышеобозначенное привело к большой популярности и всеобщему признанию MPI.
+
+=== OpenMP
+
+OpenMP появился как дополнение к MPI -- в этой библиотеки реализовывался параллелизм через общую память с помощью директив для компилятора, вставляемых в код программы. Такой подход OpenMP снижал сложность внедрения многопоточного выполнения в рамках одной машины. При этом различия между моделью распределённых вычислений MPI и подходом OpenMP позволяло использовать их вместе для ещё большего ускорения вычислений. 
+
+== Философская проблема: что считать "естественной" моделью параллелизма?
+
+Распространение подходов к параллельному программированию отражало более глубокие, неразрешённые вопросы о фундаментальной природе параллельных вычислений. Исследователи и практики вели -- и продолжают вести -- длительные дискуссии о том, следует ли выражать параллелизм в алгоритме или же стоит полагаться на аппаратно-ориентированные подходы.  
+
+Сторонники алгоритмического подхода утверждают, что параллельные вычисления представляют собой принципиально иную логику, требующую явного выражения в моделях программирования. Полагается, что программист должен понимать и контролировать стратегии декомпозиции, обмен данными и требования к синхронизации. Эта точка зрения проявляется в системах, подобных MPI, где параллелизм выражается явно, в коде.  
+
+Аппаратно-ориентированный подход стремится сделать параллелизм более неявным, перекладывая распараллеливание на "плечи" компилятора и среды исполнения. Эта философия лежала, например, в HPF. Сторонники такого подхода считают, что отделение алгоритмической корректности от производительности параллельного исполнения сделает параллельные вычисления более доступными для широкого круга разработчиков.   
+
+Эти философские различия были не просто академическими спорами, но действительно отражали неопределённость относительно того, как будет развиваться параллельная вычислительная парадигма. Эти вопросы -- об уровнях абстракции, ответственности программиста и взаимосвязи между алгоритмами и архитектурой, -- продолжают находить отклик в современных обсуждениях проектирования параллельных и распределённых систем.
+
+#pagebreak()
+
+= Появление GPGPU и ломка парадигм
+
+== Исторические предпосылки
+
+К началу 2000-х годов графические процессоры превратились в высокоспециализированные устройства, предназначенные исключительно для обработки графики и визуализации. Их архитектура развивалась по траектории, радикально отличавшейся от центральных процессоров: вместо сложных систем предсказания ветвлений и многоуровневых кэшей GPU делали ставку на массовый параллелизм. Типичный графический процессор того времени содержал десятки -- затем и сотни -- простых вычислительных ядер, способных одновременно обрабатывать множество пикселей или вершин геометрии.
+
+Ключевой концепцией стала модель SIMT (Single Instruction, Multiple Threads), которая представляла собой эволюцию классической SIMD-архитектуры. Ключевым различием между SIMD и SIMT является "строгое исполнение" (lockstep execution) -- что означает выполнение одного и того же выражения (инструкции) всеми процессорами одновременно. Эта модель идеально подходила для графических задач, где миллионы пикселей требовали одинаковой обработки с разными входными данными.
+
+Исследовательское сообщество увидело потенциал использования GPU для неграфических вычислений еще в начале 2000-х. Первые работы демонстрировали, что с помощью графических API, такие как OpenGL и DirectX, можно производить произвольные вычислений через манипуляции с текстурами и шейдерными программами. Однако этот подход требовал глубокой переработки алгоритмов вычислительных задач, дабы их можно было "уложить" в графические примитивы, что создавало значительный концептуальный барьер для программистов.
+
+== Появление CUDA
+
+В ноябре 2006 года NVIDIA представила CUDA, которая изменила подход к программированию графических процессоров для неграфических нужд. CUDA обеспечила прямой доступ к вычислительным ресурсам GPU через расширение языка C, освободив разработчиков от необходимости работать через графические API. Появление CUDA обозначило переход от косвенного использования графического конвейера к явной вычислительной модели@nickolls_gpu_2010@garland_parallel_2008.
+
+Архитектура CUDA ввела иерархическую модель организации вычислений, которая отражала аппаратную структуру GPU. Программист организовывал вычисления в виде сетки блоков, где каждый блок содержал группу потоков, способных взаимодействовать через быструю разделяемую память@nickolls_scalable_2008. Варп (warp) -- группы из 32 потоков, выполняющихся синхронно на одном мультипроцессоре -- стал основной единицей выполнения. Эффективное программирование требовало понимания того, как варпы выполняют инструкции и как расхождение потоков ветвлений внутри варпа может снизить производительность.
+
+NVIDIA приняла решение создать закрытую экосистему вокруг CUDA. Технология работала исключительно на GPU их производства, в то же время компания инвестировала значительные ресурсы в развитие библиотек, инструментов разработки и образовательных программ. Этот подход отражал убеждение, что вертикальная интеграция аппаратного обеспечения и программного стека позволит достичь максимальной производительности и ускорить внедрение новых возможностей. NVIDIA развивала богатую экосистему специализированных библиотек, таких как cuBLAS для линейной алгебры и cuFFT для преобразований Фурье, которые обеспечивали оптимизированные реализации распространенных алгоритмов.
+
+Согласно исследованиям начала эры CUDA, производительность GPU для определенных классов задач могла превышать производительность центральных процессоров на порядки величины, что стимулировало стремительное принятие технологии в научных вычислениях и машинном обучении.
+
+== OpenCL как альтернативная модель
+
+В ответ на доминирование CUDA консорциум Khronos Group в 2008 году представил OpenCL (Open Computing Language) как открытый стандарт для гетерогенных параллельных вычислений@munshi_opencl_2009. OpenCL воплощал в себе переносимость и универсальность, позволяя одному и тому же коду выполняться на GPU различных производителей, центральных процессорах, и других ускорителях. Стандарт поддерживался коалицией компаний, включая AMD, Intel, Apple и даже NVIDIA.
+
+Архитектура OpenCL строилась вокруг абстрактной модели выполнения, которая не привязывалась к специфике конкретного оборудования. Программисты описывали вычисления в терминах "рабочих групп" и "рабочих элементов", которые затем выполнялись на аппаратном обеспечении драйвером и компилятором. Эта модель обеспечивала гибкость и создавала дополнительные уровни абстракции между программой и железом.
+
+Конкуренция между CUDA и OpenCL отражала противоречие в индустрии высокопроизводительных вычислений. CUDA предлагала более тесную интеграцию с аппаратным обеспечением NVIDIA, что часто приводило к превосходной производительности и более удобным инструментам разработки, а библиотеки CUDA были глубоко оптимизированы под конкретные архитектуры GPU -- поэтому компания могла быстро внедрять поддержку новых аппаратных функций. В то же время OpenCL обещала переносимость кода между различными платформами, что было критически важно для организаций, использующих гетерогенную инфраструктуру или стремящихся избежать привязки к одному поставщику.
+
+Практический опыт показал, что достижение сопоставимой производительности на OpenCL часто требовало куда больших усилий по оптимизации под каждую конкретную платформу, что частично нивелировало преимущества переносимости. Тем не менее OpenCL сохранила свою нишу в приложениях, где важна поддержка широкого спектра оборудования, таких как системы компьютерного зрения или графических приложениях, работающих на различных платформах.
+
+#pagebreak()
+
 #align(
   center,
+  pad(
+    left: -text-indentation,
     heading(
       numbering: none,
       "СПИСОК СОКРАЩЕНИЙ"
     )
   )
+)
 
 ИИ -- искуственный интеллект
 
@@ -77,15 +306,24 @@ HPC (High-Performance Computing) -- высокопроизводительные
 
 GPU (Graphics Processing Unit) -- графический процессор
 
+SIMD (Single Instruction, Multiple Data) -- вычислительный подход, когда одна инструкция исполняется над некоторым массивом данных в один проход
+
+MIMD (Multiple Instruction, Multiple Data) -- вычислительный подход, когда множество инструкций исполняется над множеством потоков данных
+
+CUDA (Compute Unified Device Architecture) -- программно-аппаратная архитектура параллельных вычислений, которая позволяет существенно увеличить вычислительную производительность благодаря использованию графических процессоров фирмы NVIDIA
+
 #pagebreak()
 
 #align(
   center,
+  pad(
+    left: -text-indentation,
     heading(
       numbering: none,
       "СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ"
     )
   )
+)
 
 #bibliography(
   "references.bib",

references.bib

@@ -18,7 +18,7 @@
 	urldate = {2025-12-08},
 }
 
-@misc{@noauthor_mpi_nodate,
+@misc{noauthor_parallel_nodate,
 	title = {Parallel {Programming} - {HPC} {Wiki}},
 	url = {https://hpc-wiki.info/hpc/Parallel_Programming},
 	urldate = {2025-12-08},
@@ -53,3 +53,228 @@
 	doi = {10.7551/mitpress/9486.003.0008},
 	pages = {129--160},
 }
+
+@misc{noauthor_fortran_nodate,
+	title = {Fortran {\textbar} {IBM}},
+	url = {https://www.ibm.com/history/fortran},
+	abstract = {The world’s first programming language standard opened the door to modern computing.},
+	language = {en},
+	urldate = {2025-12-08},
+}
+
+@misc{noauthor_why_nodate,
+	title = {Why {ALGOL} was an important programming language?},
+	url = {https://bulldogjob.com/readme/why-algol-was-an-important-programming-language},
+	abstract = {ALGOL is a more interesting language than you think, both in terms of its story and legacy.},
+	language = {en},
+	urldate = {2025-12-08},
+}
+
+@incollection{wexelblat_history_1978,
+	address = {New York, NY, USA},
+	title = {History of {LISP}},
+	copyright = {https://www.acm.org/publications/policies/copyright\_policy\#Background},
+	isbn = {9780127450407},
+	url = {http://dl.acm.org/doi/10.1145/800025.1198360},
+	language = {en},
+	urldate = {2025-12-08},
+	booktitle = {History of programming languages},
+	publisher = {ACM},
+	author = {McCarthy, John},
+	editor = {Wexelblat, Richard L.},
+	month = jun,
+	year = {1978},
+	doi = {10.1145/800025.1198360},
+	pages = {173--185},
+}
+
+@book{hecht_flow_1977,
+	address = {New York, NY},
+	series = {Programming languages series},
+	title = {Flow analysis of computer programs},
+	isbn = {9780444002105 9780444002167},
+	language = {eng},
+	number = {5},
+	publisher = {North-Holland},
+	author = {Hecht, Matthew S.},
+	year = {1977},
+}
+
+@misc{noauthor__nodate,
+	title = {Архитектура {Cray}-1 {\textbar} {PARALLEL}.{RU} - Информационно-аналитический центр по параллельным вычислениям},
+	url = {https://parallel.ru/history/cray1.html},
+	urldate = {2025-12-08},
+}
+
+@article{flynn_very_1966,
+	title = {Very high-speed computing systems},
+	volume = {54},
+	copyright = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html},
+	issn = {0018-9219},
+	url = {http://ieeexplore.ieee.org/document/1447203/},
+	doi = {10.1109/PROC.1966.5273},
+	number = {12},
+	urldate = {2025-12-08},
+	journal = {Proceedings of the IEEE},
+	author = {Flynn, M.J.},
+	year = {1966},
+	pages = {1901--1909},
+}
+
+@article{chang_support_2004,
+	title = {Support and optimization for parallel sparse programs with array intrinsics of {Fortran} 90},
+	volume = {30},
+	copyright = {https://www.elsevier.com/tdm/userlicense/1.0/},
+	issn = {01678191},
+	url = {https://linkinghub.elsevier.com/retrieve/pii/S0167819104000286},
+	doi = {10.1016/j.parco.2004.02.004},
+	language = {en},
+	number = {4},
+	urldate = {2025-12-08},
+	journal = {Parallel Computing},
+	author = {Chang, Rong-Guey and Chuang, Tyng-Ruey and Lee, Jenq Kuen},
+	month = apr,
+	year = {2004},
+	pages = {527--550},
+}
+
+@article{allen_automatic_1987,
+	title = {Automatic translation of {FORTRAN} programs to vector form},
+	volume = {9},
+	issn = {0164-0925, 1558-4593},
+	url = {https://dl.acm.org/doi/10.1145/29873.29875},
+	doi = {10.1145/29873.29875},
+	abstract = {The recent success of vector computers such as the Cray-1 and array processors such as those manufactured by Floating Point Systems has increased interest in making vector operations available to the FORTRAN programmer. The FORTRAN standards committee is currently considering a successor to FORTRAN 77, usually called FORTRAN 8x, that will permit the programmer to explicitly specify vector and array operations.
+            Although FORTRAN 8x will make it convenient to specify explicit vector operations in new programs, it does little for existing code. In order to benefit from the power of vector hardware, existing programs will need to be rewritten in some language (presumably FORTRAN 8x) that permits the explicit specification of vector operations. One way to avoid a massive manual recoding effort is to provide a translator that discovers the parallelism implicit in a FORTRAN program and automatically rewrites that program in FORTRAN 8x.
+            
+              Such a translation from FORTRAN to FORTRAN 8x is not straightforward because FORTRAN DO loops are not always semantically equivalent to the corresponding FORTRAN 8x parallel operation. The semantic difference between these two constructs is precisely captured by the concept of
+              dependence
+              . A translation from FORTRAN to FORTRAN 8x preserves the semantics of the original program if it preserves the dependences in that program.
+            
+            The theoretical background is developed here for employing data dependence to convert FORTRAN programs to parallel form. Dependence is defined and characterized in terms of the conditions that give rise to it; accurate tests to determine dependence are presented; and transformations that use dependence to uncover additional parallelism are discussed.},
+	language = {en},
+	number = {4},
+	urldate = {2025-12-08},
+	journal = {ACM Transactions on Programming Languages and Systems},
+	author = {Allen, Randy and Kennedy, Ken},
+	month = oct,
+	year = {1987},
+	pages = {491--542},
+}
+
+@inproceedings{mowry_design_1992,
+	address = {Boston Massachusetts USA},
+	title = {Design and evaluation of a compiler algorithm for prefetching},
+	isbn = {9780897915342},
+	url = {https://dl.acm.org/doi/10.1145/143365.143488},
+	doi = {10.1145/143365.143488},
+	language = {en},
+	urldate = {2025-12-08},
+	booktitle = {Proceedings of the fifth international conference on {Architectural} support for programming languages and operating systems},
+	publisher = {ACM},
+	author = {Mowry, Todd C. and Lam, Monica S. and Gupta, Anoop},
+	month = sep,
+	year = {1992},
+	pages = {62--73},
+}
+
+@misc{morgan_compiling_2018,
+	title = {Compiling {History} {To} {Understand} {The} {Future}},
+	url = {https://www.nextplatform.com/2018/11/02/compiling-history-to-understand-the-future/},
+	abstract = {If you want to understand where we are going with computer architectures and the compilers that drive them, it is instructive to look at how compilers},
+	language = {en-US},
+	urldate = {2025-12-08},
+	journal = {The Next Platform},
+	author = {Morgan, Timothy Prickett},
+	month = nov,
+	year = {2018},
+}
+
+@misc{noauthor_vectorization_nodate,
+	title = {Vectorization {Directives} {\textbar} {Cray} {Fortran} {Reference} {Manual} 8.{7A} {S}-3901},
+	url = {https://support.hpe.com/hpesc/public/docDisplay?docId=a00113909en_us&page=Vectorization_Directives.html&docLocale=en_US},
+	urldate = {2025-12-08},
+}
+
+@article{hoare_communicating_1978,
+	title = {Communicating sequential processes},
+	volume = {21},
+	issn = {0001-0782, 1557-7317},
+	url = {https://dl.acm.org/doi/10.1145/359576.359585},
+	doi = {10.1145/359576.359585},
+	abstract = {This paper suggests that input and output are basic primitives of programming and that parallel composition of communicating sequential processes is a fundamental program structuring method. When combined with a development of Dijkstra's guarded command, these concepts are surprisingly versatile. Their use is illustrated by sample solutions of a variety of a familiar programming exercises.},
+	language = {en},
+	number = {8},
+	urldate = {2025-12-08},
+	journal = {Communications of the ACM},
+	author = {Hoare, C. A. R.},
+	month = aug,
+	year = {1978},
+	pages = {666--677},
+}
+
+@article{nickolls_gpu_2010,
+	title = {The {GPU} {Computing} {Era}},
+	volume = {30},
+	copyright = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html},
+	issn = {0272-1732},
+	url = {http://ieeexplore.ieee.org/document/5446251/},
+	doi = {10.1109/MM.2010.41},
+	number = {2},
+	urldate = {2025-12-08},
+	journal = {IEEE Micro},
+	author = {Nickolls, John and Dally, William J},
+	month = mar,
+	year = {2010},
+	pages = {56--69},
+}
+
+@article{nickolls_scalable_2008,
+	title = {Scalable {Parallel} {Programming} with {CUDA}: {Is} {CUDA} the parallel programming model that application developers have been waiting for?},
+	volume = {6},
+	issn = {1542-7730, 1542-7749},
+	shorttitle = {Scalable {Parallel} {Programming} with {CUDA}},
+	url = {https://dl.acm.org/doi/10.1145/1365490.1365500},
+	doi = {10.1145/1365490.1365500},
+	abstract = {The advent of multicore CPUs and manycore GPUs means that mainstream processor chips are now parallel systems. Furthermore, their parallelism continues to scale with Moore’s law. The challenge is to develop mainstream application software that transparently scales its parallelism to leverage the increasing number of processor cores, much as 3D graphics applications transparently scale their parallelism to manycore GPUs with widely varying numbers of cores.},
+	language = {en},
+	number = {2},
+	urldate = {2025-12-08},
+	journal = {Queue},
+	author = {Nickolls, John and Buck, Ian and Garland, Michael and Skadron, Kevin},
+	month = mar,
+	year = {2008},
+	pages = {40--53},
+}
+
+@article{garland_parallel_2008,
+	title = {Parallel {Computing} {Experiences} with {CUDA}},
+	volume = {28},
+	copyright = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html},
+	issn = {0272-1732},
+	url = {http://ieeexplore.ieee.org/document/4626815/},
+	doi = {10.1109/MM.2008.57},
+	number = {4},
+	urldate = {2025-12-08},
+	journal = {IEEE Micro},
+	author = {Garland, Michael and Le Grand, Scott and Nickolls, John and Anderson, Joshua and Hardwick, Jim and Morton, Scott and Phillips, Everett and Zhang, Yao and Volkov, Vasily},
+	month = jul,
+	year = {2008},
+	pages = {13--27},
+}
+
+@inproceedings{munshi_opencl_2009,
+	address = {Stanford, CA, USA},
+	title = {The {OpenCL} specification},
+	copyright = {https://doi.org/10.15223/policy-029},
+	isbn = {9781467388733},
+	url = {https://ieeexplore.ieee.org/document/7478342/},
+	doi = {10.1109/HOTCHIPS.2009.7478342},
+	urldate = {2025-12-08},
+	booktitle = {2009 {IEEE} {Hot} {Chips} 21 {Symposium} ({HCS})},
+	publisher = {IEEE},
+	author = {Munshi, Aaftab},
+	month = aug,
+	year = {2009},
+	pages = {1--314},
+}