CC BY
5
карбонатонакопления в геологической истории, что связано с общей цикличностью геотектонического развития и периодичностью осадкообразования.
Карбонатные коллекторы характеризуются специфическими особенностями:
1) крайней невыдержанностью, значительной изменчивостью свойств, что затрудняет их сопоставление;
2) в них относительно легко происходят разнообразные диагенетические и катагенетические изменения;
3) фациальный облик известняков в большей мере, чем обломочных пород, влияет на формирование коллекторских свойств;
4) в минеральном отношении карбонатные породы менее разнообразны, чем обломочные, но по структурно-текстурным характеристикам имеют гораздо больше разновидностей;
5) в процессе изучения коллекторских свойств карбонатных толщ решающую роль играют генезис отложений и гидродинамика среды для формирования структуры пустотного пространства, которая может быть более или менее благоприятна для формирования коллекторов и определяет характер последующих преобразований;
6) карбонатные породы легко подвергаются вторичным изменениям. Это связано с их повышенной растворимостью. Особенно велико влияние вторичных преобразований в породах с первично неоднородной структурой порового пространства;
7) по характеру постседиментационных преобразований карбонатные породы отличаются от терригенных. Прежде всего, это касается уплотнения. Остатки биогермов с самого начала представляют практически твердые образования, и далее уплотнение идет уже медленно;
8) карбонатный ил также может быстро литифицироваться, при этом в нем возникают своеобразные фенестровые пустоты за счет выделения пузырьков газа. Мелкообломочные, комковато-водорослевые карбонатные осадки также быстро литифицируются. Пористость несколько сокращается, но вместе с тем значительный объем порового пространства «консервируется». В карбонатных породах отмечаются все виды пустот. В зависимости от времени возникновения они могут быть первичными (седиментационными и диагенетическими) и вторичными (постдиагенетическими).
Карбонатные породы как коллекторы нефти и газа уверенно конкурируют с терригенными образованиями.
Список используемой литературы: 1. Галкин, В.И. Геология нефти и газа: учебно-метод. пособие / В.И. Галкин, О.Е. Кочнева. - Пермь: Изд-во Перм. гос. техн. ун-та, 2011. - 113 с.
© Бяшимова Г., Какышова А., Ишангулыева А., Аманова Г., 2023
УДК 62
Кособродов С.К.
Веб-разработчик, ООО "МСКСИТИ" Россия, Москва
СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ ASSEMBLYSCRIPT И JAVASCRIPT В ПРОДВИНУТЫХ
ВЫЧИСЛИТЕЛЬНЫХ АЛГОРИТМАХ
Аннотация
Постоянно меняющаяся и трансформирующаяся цифровая среда предвещает наступление эры
огромных веб-приложений, ключевыми характеристиками которых являются эффективность, надежность и скорость. Чтобы удовлетворить этот спрос, появилось множество языков программирования, каждый из которых претендует на заветную лучшую производительность. В этой сложной обстановке наше исследование направлено на сопоставление двух главных конкурентов - AssemblyScript и JavaScript, в контексте веб-нативной производительности. С помощью строгой серии алгоритмических тестов, включающих поиск по ширине, быстрое преобразование Фурье, разложение снизу вверх, ранжирование страниц и умножение векторов с разреженной матрицей, в исследовании тщательно изучаются вычислительные возможности обоих языков. Первоначальные наблюдения подчеркивают похвальное мастерство AssemblyScript, особенно в задачах, требующих последовательных высокоскоростных вычислений. Его интеграция с архитектурной надежностью WebAssembly еще больше подчеркивает его потенциал. С другой стороны, JavaScript, признанный лидер в веб-разработке, демонстрирует как свои достоинства, так и определенные нарушения производительности при сравнении с AssemblyScript. Примечательно, что в то время как средние показатели времени выполнения проливают свет на общую эффективность обоих языков, различия в итеративном времени выполнения дают представление об их стабильности и надежности. Однако важно понимать, что помимо простых показателей производительности, выбор платформы разработки переплетается с такими факторами, как поддержка сообщества, экосистема разработки и требования к конкретному проекту. Подводя итог, можно сказать, что данное исследование направлено на то, чтобы предоставить разработчикам и исследователям ясный взгляд на эти языки, стимулируя принятие обоснованных решений в поисках новаторских цифровых решений.
Ключевые слова:
AssemblyScript, JavaScript, WebAssembly, вычислительная производительность, Поиск по ширине, быстрое преобразование Фурье, декомпозиция снизу вверх, Ранжирование страниц, Умножение векторов с разреженной матрицей, веб-приложения.
COMPARATIVE ANALYSIS OF ASSEMBLYSCRIPT AND JAVASCRIPT PERFORMANCE IN ADVANCED COMPUTATIONAL ALGORITHMS
Abstract
The ever-changing and transforming digital environment heralds the advent of the era of huge web applications, the key characteristics of which are efficiency, reliability and speed. To meet this demand, many programming languages have appeared, each of which claims the coveted best performance. In this challenging environment, our research aims to compare the two main competitors - AssemblyScript and JavaScript, in the context of web native performance. Using a rigorous series of algorithmic tests, including breadth-first search, fast Fourier transform, bottom-up decomposition, page ranking, and sparse matrix vector multiplication, the study thoroughly examines the computational capabilities of both languages. Initial observations spotlight AssemblyScript's commendable prowess, especially in tasks necessitating consistent high-speed computations. Its integration with the architectural robustness of WebAssembly further accentuates its potential. On the other hand, JavaScript, a stalwart in web development, exhibits both its merits and certain performance irregularities when weighed against AssemblyScript. Notably, while the average runtime metrics shed light on the general efficiency of both languages, variations in iterative runtimes offer insights into their stability and reliability. However, it's essential to recognize that beyond sheer performance numbers, the selection of a development platform intertwines with factors such as community support, development ecosystem, and project-specific requisites. In summation, this research endeavors to provide developers and researchers a lucid perspective on these languages, catalyzing informed decisions in the pursuit of pioneering digital solutions.
Keywords:
assemblyScript, JavaScript, WebAssembly, computational performance, Breadth First Search, Fast Fourier Transform, Lower Upper Decomposition, Page Rank, Sparse Matrix Vector Multiplication,
web-native applications.
Введение
В условиях постоянной эволюции информатики преимущество языков программирования в отношении вычислительной эффективности неоспоримо, особенно при решении задач, требующих больших вычислительных затрат. Особенно тщательно в этой области изучаются AssemblyScript и JavaScript, причем первый является вариантом TypeScript, который компилируется в WebAssembly (WASM), двоичный формат команд, известный своим потенциалом для обеспечения производительности, близкой к нативной, на веб-платформах. И наоборот, JavaScript, лидер в веб-разработке, которого хвалят за его адаптивность, сталкивается с критикой в отношении его вычислительных ограничений, особенно в сочетании с языками, разработанными для оптимизации производительности.
Непрекращающееся стремление к цифровой оптимизации ускоряет необходимость изучения скрытых возможностей парадигм программирования. Актуальность этого исследования возрастает по мере усложнения приложений, что повышает спрос на ускоренные решения в режиме реального времени. Это исследование направлено на то, чтобы проникнуть в тайники вычислительной эффективности, присущие AssemblyScript и JavaScript. Цель сравнительного анализа в данной работе - не просто выявить победителей, а дать разработчикам четкие рекомендации по выбору инструментов, отвечающих их специфическим требованиям, раскрыв сложности, скрывающие вычислительную мощь каждого языка.
Последующие разделы направлены на многогранные атрибуты AssemblyScript и JavaScript. Тщательному анализу их работы с использованием пяти конкретных алгоритмов, тщательно подобранных с учетом вычислительных сложностей. Основываясь на эмпирическом тестировании и реальных сценариях, эта система исследований призвана обогатить диалог о производительности языков программирования в современной цифровой среде.
Обзор AssemblyScript и WebAssembly (ASM)
AssemblyScript служит компилятором, переводящим код TypeScript в WebAssembly (Wasm). TypeScript - это язык, разработанный Microsoft, действующий как надмножество JavaScript, отличающийся расширенной поддержкой типов и другими уникальными функциями. Примечательно, что AssemblyScript предназначен для преобразования только определенного подмножества конструкций TypeScript в WAS. Отличительная особенность заключается в его склонности к прямой компиляции в WebAssembly (WASM), ведущий формат двоичных команд, тщательно разработанный для работы в рамках веб-браузеров. Главная миссия WASM состоит в том, чтобы преодолеть пропасть, отделяющую скорость работы нативных приложений от повсеместного распространения веб-аналогов [1].
Происхождение WebAssembly проистекает из необходимости противостоять врожденным ограничениям, с которыми сталкивается JavaScript, особенно его восприимчивости к ограничениям производительности при выполнении вычислительно обременительных задач. Несмотря на то, что движки JavaScript за прошедшие годы добились заметных успехов в области оптимизации, фундаментальное ограничение сохраняется, благодаря его интерпретативному характеру. WebAssembly предлагает альтернативу от этого затруднительного положения, проявляющееся в виде низкоуровневого языка, похожего на ассемблер. Он занимает пространство, где оперативная веб-доставка не подлежит обсуждению, нишу, которую он заполняет благодаря своему компактному бинарному воплощению.
AssemblyScript становится ключевым игроком в этой парадигме, предлагая разработчикам, знакомым с TypeScript и JavaScript, возможность использовать возможности WASM без сложного
обучения. Философия его дизайна основана на тесном согласовании с TypeScript, гарантируя, что те, кто знаком с языком, смогут легко переходить к нему. Однако важно понимать, что, хотя AssemblyScript может во многом напоминать TypeScript, он включает в себя определенные ограничения и нюансы ввода, чтобы быть более подходящим для низкоуровневой, высокопроизводительной области WASM [2, 6].
Кроме того, WebAssembly может похвастаться целым рядом преимуществ, выходящих за рамки простой производительности. Изолированная среда выполнения обеспечивает надежную безопасность, что является важнейшим аспектом современной веб-экосистемы. Кроме того, возможность компиляции означает, что в браузере могут выполняться языки, отличные от JavaScript, что демократизирует среду веб-разработки и позволяет создавать разнообразные и мощные многоязычные приложения.
Однако, как и любая технология, она не лишена проблем. Текущее состояние WebAssembly делает упор на численные вычисления, что означает, что задачи, связанные с объектной моделью документа (DOM) или определенными веб-API, все еще могут в значительной степени зависеть от JavaScript. Тем не менее, симбиотические отношения между JavaScript и WASM, особенно облегчаемые такими инструментами, как AssemblyScript, открывают многообещающие перспективы для эволюции веб-приложений, сочетая в себе лучшее из обоих миров: универсальность и производительность.
Обзор JavaScript
JavaScript является знаковой опорой в мире веб-разработки, превратившись из скромного языка сценариев, изначально предназначенного для придания интерактивности статичным веб-страницам, в мощную, многогранную платформу, которой он является сегодня. Задуманный Бренданом Эйчем в 1995 году всего за десять дней, он стал поворотным моментом в цифровой революции, изменив саму структуру веб-взаимодействий.
Центральным преимуществом JavaScript является его событийно-управляемый, неблокирующий характер, что делает его идеальным для задач, требующих асинхронных операций, таких как обработка пользовательских вводов, выполнение сетевых запросов или манипулирование объектной моделью документа (DOM). Язык процветает в среде, где оперативность и интерактивность имеют первостепенное значение, и таким образом находит свою нишу в разработке интерфейсов. Однако появление таких платформ, как Node.js в последние годы JavaScript продвинулся в область серверной части, способствуя созданию целостной экосистемы вокруг одного языка, которую в народе называют парадигмой "JavaScript везде" [3].
Тем не менее, при всех своих достоинствах, JavaScript действительно обладает определенными внутренними ограничениями, особенно на фоне вычислительной производительности. То, что это интерпретируемый язык с динамической типизацией, означает, что ему не хватает жесткой структуры и потенциала оптимизации, предлагаемых статически типизированными, скомпилированными аналогами. Те самые функции, которые придают JavaScript его гибкость — такие как наследование на основе прототипов или его либеральное принуждение к типу, - при определенных обстоятельствах могут стать источниками неэффективности или непредсказуемости.
Более того, повсеместное распространение JavaScript, порожденное экспоненциальным ростом Интернета, непреднамеренно привело к фрагментации ландшафта с мириадами фреймворков, библиотек и инструментов, каждый из которых стремится решать определенные подмножества задач. Это может привести к параличу принятия решений разработчиками и иногда приводит к чрезмерной зависимости от сторонних пакетов, что потенциально снижает производительность.
Тем не менее, неустанные усилия, стоящие за современными движками JavaScript, такими как V8 или SpiderMonkey, привели к похвальным стратегиям оптимизации, использующим такие методы, как JIT-компиляция, которая динамически компилирует части кода на машинный язык, повышая скорость выполнения [4].
Подводя итог, можно сказать, что траектория развития JavaScript отражает повествование об адаптивности и эволюции. Хотя это, возможно, и не самый лучший выбор для приложений с высокой вычислительной нагрузкой, его универсальность в сочетании с широкой поддержкой сообщества и непрерывной оптимизацией обеспечивает его неизменную актуальность в многообразии веб-технологий.
Методология исследования
Чтобы обеспечить объективное и надежное сравнение между AssemblyScript и JavaScript, в этом исследовании используется системный подход, основанный как на качественных, так и на количественных методах исследования. Используемые методологии направлены на устранение предубеждений, обеспечение воспроизводимости и достижение всестороннего понимания возможностей производительности соответствующих языков.
Выбор алгоритма: в качестве ориентиров были выбраны пять сложных алгоритмов: Поиск по ширине, быстрое преобразование Фурье, декомпозиция снизу вверх, ранжирование страниц и умножение разреженных матричных векторов. Эти алгоритмы были выбраны из-за их вычислительной интенсивности, разнообразия по своей природе (от теории графов до численных методов) и их актуальности в реальных приложениях, тем самым предлагая широкий спектр для анализа.
Настройка среды: для поддержания согласованности все тесты выполнялись на стандартизированной платформе, состоящей из процессора Intel Core i7, 16 ГБ оперативной памяти и твердотельного накопителя. Два основных браузера, Google Chrome (версия XX) и Mozilla Firefox (версия XX), были выбраны из-за их широкого использования и отличных механизмов выполнения JavaScript/WASM, а именно V8 и SpiderMonkey.
Реализация: для каждого алгоритма была разработана собственная реализация как на AssemblyScript, так и на JavaScript. Должное внимание было уделено тому, чтобы обе реализации были функционально идентичны, причем единственной переменной был сам язык. Особое внимание было уделено соблюдению лучших практик кодирования, избеганию каких-либо зависящих от языка сокращений или оптимизаций, которые могли бы исказить результаты.
Размер итерации: во всех тестах использовался размер итерации по умолчанию, равный 120. Это число было сочтено оптимальным для обеспечения баланса между временем вычислений и значимостью результата. Хотя уменьшение размера итерации может ускорить отображение результатов, это также может снизить надежность данных, особенно при выделении незначительных различий в производительности.
Сбор данных: было выполнено несколько запусков каждого алгоритма, чтобы учесть любые спорадические системные колебания. После выполнения время, затраченное на каждый запуск, записывалось с точностью до миллисекунд.
Статистический анализ: было рассчитано среднее время выполнения для каждого алгоритма на обоих языках. Для оценки статистической значимости наблюдаемых различий был проведен парный t-критерий. Это позволило бы установить, были ли какие-либо наблюдаемые отклонения в производительности подлинными или их можно было бы отнести на счет случайности.
По сути, принятый методологический подход является скрупулезным и целостным, призванным предложить идеи, которые являются не только точными, но и актуальными как для академических кругов, так и для практиков отрасли.
Проведение исследования
Тест 1: Breadth First Search
Поиск в ширину (BFS) является основополагающим алгоритмом в теории графов, часто используемым для обхода или поиска структур данных, таких как деревья и графики. Учитывая его
повсеместное распространение в вычислительных приложениях, он служит подходящим ориентиром для начала нашего анализа производительности.
// AssemblyScript
export class Queue<T> { private items: T[] = [];
enqueue(element: T): void { this.items.push(element);
}
dequeue(): T | null { if (this.isEmpty()) return null; return this.items.shift()!;
}
isEmpty(): bool { return !this.items.length;
}
}
export function BFS(graph: i32[][], startNode: i32): i32[] { const visited: bool[] = new Array<bool>(graph.length).fill(false); const queue: Queue<i32> = new Queue<i32>(); const orderOfVisit: i32[] = [];
visited[startNode] = true; queue.enqueue(startNode);
while (!queue.isEmpty()) { const getQueueElement = queue.dequeue()!; orderOfVisit.push(getQueueElement);
for (let i = 0; i < graph[getQueueElement].length; i++) { const neighbour = graph[getQueueElement][i]; if (!visited[neighbour]) { visited[neighbour] = true; queue.enqueue(neighbour);
}
}
}
return orderOfVisit;
}
// JavaScript
class Queue { constructor() { this.items = [];
}
enqueue(element) { this.items.push(element);
}
dequeue() { if (this.isEmpty()) return null; return this.items.shift();
}
isEmpty() { return !this.items.length;
}
}
function BFS(graph, startNode) { const visited = new Array(graph.length).fill(false); const queue = new Queue(); const orderOfVisit = [];
visited[startNode] = true; queue.enqueue(startNode);
while (!queue.isEmpty()) { const getQueueElement = queue.dequeue(); orderOfVisit.push(getQueueElement);
graph[getQueueElement].forEach((neighbour, i) => { if (!visited[i] && neighbour) { visited[i] = true; queue.enqueue(i);
} });
}
return orderOfVisit;
}
В предусмотренном тестовом сценарии алгоритм прошел серию итераций, ровно 120, и его производительность оценивалась с использованием двух основных показателей: среднего времени выполнения и разницы во времени между отдельными итерациями (рис. 1, 2).
Breadth First Search
Рисунок 1 - Среднее время выполнения теста 1 Figure 1 - Average test execution time 1
Рисунок 2 - Время выполнения каждой итерации теста 1 Figure 2 - Execution time of each iteration of test 1
Среднее время выполнения (рис. 1):
Было обнаружено заметное несоответствие между AssemblyScript и JavaScript с точки зрения среднего времени выполнения. В частности, AssemblyScript потребовалось приблизительно 30,8 мс для завершения алгоритма BFS, в то время как JavaScript зарегистрировал время в 59,9 мс. Это приводит к тому, что JavaScript занимает почти вдвое больше времени, чем требуется AssemblyScript, что подчеркивает значительное преимущество в производительности в пользу AssemblyScript для этого конкретного алгоритма.
Отклонение во времени итерации (рис. 2):
Углубляясь в детализацию каждой итерации, AssemblyScript продемонстрировал постоянство времени выполнения, при этом колебания были ограничены узким диапазоном в 3 мс. В отличие от этого, JavaScript демонстрировал более выраженную дисперсию, время его выполнения колебалось в пределах 10 мс. Это подчеркивает не только превосходную скорость AssemblyScript, но и его стабильность и предсказуемость - качества, которые неоценимы в реальных приложениях, где стабильная производительность может иметь первостепенное значение.
Подводя итог, можно сказать, что для алгоритма поиска в ширину AssemblyScript явно превосходит JavaScript как по средней скорости выполнения, так и по стабильности на разных итерациях. Этот первоначальный тест создает убедительный прецедент, намекающий на неотъемлемые преимущества AssemblyScript при компиляции в WebAssembly, которые он может иметь в задачах, требующих больших вычислительных затрат, по сравнению с традиционным JavaScript.
Тест 2: Fast Fourier Transform
Быстрое преобразование Фурье (FFT) служит важнейшим алгоритмом цифровой обработки сигналов, способствующим преобразованию сигнала из его исходной временной или пространственной области в его представление в частотной области. Учитывая роль алгоритма во множестве приложений, от обработки звука до анализа изображений, понимание показателей его производительности имеет первостепенное значение.
// AssemblyScript
export function FFT(a: f64[]): f64[] {
let n = a.length; if (n <= 1) return a;
let even: f64[] = []; let odd: f64[] = []; for (let i = 0; i < n; i++) {
if (i % 2 === 0) even.push(a[i]); else odd.push(a[i]);
}
even = FFT(even); odd = FFT(odd);
let T: f64 = 2 * Math.PI / n; for (let k = 0; k < n / 2; k++) {
let t = Math.exp(-1 * T * k) * odd[k];
a[k] = even[k] + t;
a[k + n / 2] = even[k] - t;
}
return a;
}
// JavaScript
function FFT(a) { let n = a.length; if (n <= 1) return a;
let even = []; let odd = [];
for (let i = 0; i < n; i++) {
if (i % 2 === 0) even.push(a[i]); else odd.push(a[i]);
}
even = FFT(even); odd = FFT(odd);
let T = 2 * Math.PI / n; for (let k = 0; k < n / 2; k++) {
let t = Math.exp(-1 * T * k) * odd[k];
a[k] = even[k] + t;
a[k + n / 2] = even[k] - t;
}
return a;
}
Для этого исследования было проведено в общей сложности 120 итераций, и эффективность алгоритма оценивалась с использованием двух основных факторов: среднего времени выполнения и вариабельности времени выполнения в течение отдельных итераций (рис. 3).
Fast Fourier Transform
Рисунок 3 - Среднее время выполнения теста 2 Figure 3 - Average test execution time 2
Рисунок 4 - Время выполнения каждой итерации теста 2
Figure 4 - Execution time of each iteration of test 2
Среднее время выполнения:
В отличие от предыдущего теста поиска в ширину, результаты здесь продемонстрировали явное преимущество JavaScript. В частности, в то время как AssemblyScript потребовалось в среднем 61,3 мс для завершения операции БПФ, JavaScript завершил то же самое всего за 21,7 мс. Такая инверсия в динамике производительности предполагает, что не все задачи, требующие больших вычислительных затрат, по своей сути благоприятствуют выполнению на основе AssemblyScript или WebAssembly. Действительно, природа алгоритма, его специфические оптимизации и лежащие в основе сложности сред выполнения играют ключевую роль в определении фактической скорости выполнения.
Отклонение во времени итерации:
Изучая нюансы времени отдельных итераций, как AssemblyScript, так и JavaScript продемонстрировали похвальную стабильность, причем временные колебания в основном находились в пределах 3 мс. Однако заслуживающим внимания наблюдением является наличие выброса в обоих наборах: AssemblyScript испытал единичный всплеск, достигший 68 мс, в то время как у JavaScript была своя собственная аномалия, достигшая максимума в 32 мс. Хотя происхождение этих отклонений требует дальнейшего изучения, их существование подчеркивает необходимость всестороннего тестирования, поскольку в реальных сценариях могут возникать спорадические отклонения в производительности.
В заключение, тест на быстрое преобразование Фурье демонстрирует интригующий поворот в нашем сравнительном анализе. Несмотря на превосходную производительность AssemblyScript в предыдущем тесте BFS, JavaScript одерживает победу в оценке FFT, как с точки зрения исходной скорости, так и относительных величин отклонений от нормы. Это подчеркивает нюансы алгоритмической производительности на разных языках и платформах, подтверждая предположение о том, что ни один
отдельный язык не обладает вездесущим преимуществом во всех вычислительных сценариях. Тест 3: Lower Upper Decomposition
Разложение снизу вверх, обычно называемое LU-разложением, является важным методом численного анализа. Это включает в себя разложение матрицы на произведение нижней треугольной матрицы и верхней треугольной матрицы. Учитывая его важность при решении систем линейных уравнений и вычислении детерминант, тест производительности этого алгоритма дает ценную информацию о вычислительной математике на различных платформах. // AssemblyScript
export function LUDecomposition(matrix: f64[][]): [f64[][], f64[][]] { let n = matrix.length;
let L: f64[][] = new Array(n).fill([]).map(row => new Array(n).fill(0.0)); let U: f64[][] = new Array(n).fill([]).map(row => new Array(n).fill(0.0));
for (let i = 0; i < n; i++) { for (let k = i; k < n; k++) { U[i][k] = matrix[i][k]; for (let j = 0; j < i; j++) { U[i][k] -= L[i][j] * U[j][k];
}
}
L[i][i] = 1;
for (let k = i; k < n; k++) { L[k][i] = matrix[k][i]; for (let j = 0; j < i; j++) { L[k][i] -= L[k][j] * U[j][i];
}
L[k][i] /= U[i][i];
}
}
return [L, U];
}
// JavaScript
function LUDecomposition(matrix) { let n = matrix.length;
let L = Array.from({ length: n }, () => Array(n).fill(0.0)); let U = Array.from({ length: n }, () => Array(n).fill(0.0));
for (let i = 0; i < n; i++) { for (let k = i; k < n; k++) { U[i][k] = matrix[i][k]; for (let j = 0; j < i; j++) { U[i][k] -= L[i][j] * U[j][k];
}
}
L[i][i] = 1;
for (let k = i; k < n; k++) { L[k][i] = matrix[k][ij; for (let j = 0; j < i; j++) { L[k][i] -= L[k][j] * U[j][i];
}
L[k][i] /= U[i][i];
}
}
return [L, U];
}
Для этой оценки была поддержана согласованная структура из 120 итераций, и производительность оценивалась по двум осям - среднему времени выполнения и временной дисперсии в зависимости от итерации.
Louver Upper Decomposition
Рисунок 5 - Среднее время выполнения теста 3 Figure 5 - Average test execution time 3
Рисунок 6 - Время выполнения каждой итерации теста 3
Figure 6 - Execution time of each iteration of test 3
Среднее время выполнения:
В тесту между AssemblyScript и JavaScript по алгоритму декомпозиции LU AssemblyScript вновь захватил лидерство. Данные показали, что в то время как AssemblyScript выполнил задачу в среднем за 43 мс, JavaScript немного отстал, зафиксировав время в 61,3 мс. Это означает, что AssemblyScript примерно на 30% быстрее выполнял декомпозицию LU, чем его аналог, что усиливает его возможности в определенных вычислительных областях.
Отклонение во времени итерации:
Вникая в тонкости каждой итерации, как AssemblyScript, так и JavaScript продемонстрировали высокую степень согласованности. Время выполнения для обеих платформ преимущественно колебалось в узком диапазоне 3 мс, что позволяет предположить, что независимо от общей скорости обе платформы
обеспечивают надежную производительность при обработке LU-декомпозиции.
Таким образом, тест на декомпозицию LU дополнительно подтверждает потенциал AssemblyScript в оптимизации конкретных математических вычислений. Однако почти эквивалентная стабильность между AssemblyScript и JavaScript подчеркивает, что, хотя среднее время выполнения, несомненно, имеет решающее значение, предсказуемость и согласованность платформы также имеют существенное значение для приложений реального мира.
Тест 4: Page Rank
Алгоритм PageRank, который, как известно, ассоциируется с ранними механизмами, лежащими в основе поисковой системы Google, представляет собой алгоритм анализа ссылок, используемый для веб-картографирования. По сути, он количественно определяет важность или "ранжирование" веб-страниц путем оценки качества и количества ссылок, указывающих на конкретную страницу. Применимость этого алгоритма выходит за рамки поисковых систем, что делает оценку его производительности на различных платформах ценным занятием.
// AssemblyScript
export function pageRank(links: u32[][], damping: f64 = 0.85, epsilon: f64 = 1e-4): f64[] { let n = links.length;
let pr: f64[] = new Array(n).fill(1.0 / n); let prevPr: f64[] = new Array(n).fill(0);
while (distance(pr, prevPr) > epsilon) { prevPr = pr.slice(); for (let i = 0; i < n; i++) {
let newRank = (1.0 - damping) / n; for (let j = 0; j < n; j++) {
if (links[j].includes(<u32>i)) { newRank += damping * pr[j] / <f64>links[j].length;
}
}
pr[i] = newRank;
}
}
return pr;
}
function distance(v1: f64[], v2: f64[]): f64 { let d: f64 = 0;
for (let i = 0; i < v1.length; i++) { d += (v1[i] - v2[i]) ** 2;
}
return Math.sqrt(d);
}
// JavaScript
function pageRank(links, damping = 0.85, epsilon = 1e-4) { let n = links.length;
let pr = new Array(n).fill(1.0 / n); let prevPr = new Array(n).fill(0);
while (distance(pr, prevPr) > epsilon) { prevPr = [...pr]; for (let i = 0; i < n; i++) {
let newRank = (1.0 - damping) / n; for (let j = 0; j < n; j++) { if (links[j].includes(i)) { newRank += damping * pr[j] / links[j].length;
}
}
pr[i] = newRank;
}
}
return pr;
}
function distance(v1, v2) { let d = 0;
for (let i = 0; i < vl.length; i++) { d += (v1[i] - v2[i]) ** 2;
}
return Math.sqrt(d);
}
Для этой оценки был сохранен параметр последовательной итерации, равный 120, а показатели производительности зависели от среднего времени выполнения и вариаций между отдельными итерациями.
Page Rank
Рисунок 7 - Среднее время выполнения теста 4 Figure 7 - Average test execution time 4
Рисунок 8 - Время выполнения каждой итерации теста 4
Figure 8 - Execution time of each iteration of test 4
Среднее время выполнения:
В ходе интригующего тестирования алгоритма PageRank как AssemblyScript, так и JavaScript отображали идентичные показатели производительности. Среднее время выполнения для обеих платформ составило ровно 13 мс. Этот результат не только подчеркивает достижения и оптимизацию, достигнутые обеими платформами с течением времени, но и проливает свет на тот факт, что для определенных алгоритмов может существовать точка равновесия в производительности.
Отклонение во времени итерации:
Глубокое погружение во временные колебания во время каждой итерации рисовало несколько иную картину. В то время как обе платформы продемонстрировали похвальную стабильность, колеблясь в пределах минимального диапазона в 1 мс, JavaScript продемонстрировал заметное отклонение во время одной из своих итераций (около 102-й отметки), когда время выполнения резко возросло до 44 мс. Такой выброс, хотя и единичный, подчеркивает случайную непредсказуемость, с которой можно столкнуться в реальных сценариях. AssemblyScript, с другой стороны, продемонстрировал несколько более последовательное поведение, при этом спорадические вариации были относительно редкими.
Подводя итог, можно сказать, что тест PageRank показал сбалансированный результат производительности между AssemblyScript и JavaScript с точки зрения среднего времени выполнения. Однако при оценке детализации времени выполнения на разных итерациях незначительно превосходящая согласованность AssemblyScript и изолированный сбой в производительности JavaScript приводят к важному выводу: в то время как скорость в исходном виде имеет первостепенное значение, согласованность и предсказуемость, особенно при обширных или длительных вычислениях, могут иметь не меньшее значение.
Тест 5: Sparse Matrix Vector Multiplication
Разреженное матрично-векторное умножение (SMVM) играет важную роль в числовой линейной алгебре, особенно в ситуациях, когда данные преимущественно равны нулю, что делает типичные матричные операции вычислительно дорогостоящими и неэффективными. Оптимизация операций SMVM может привести к значительной экономии вычислительных ресурсов, особенно в таких приложениях, как методы конечных элементов, вычислительная гидродинамика и задачи обработки данных.
// AssemblyScript
export function sparseMatrixVectorMult(matrix: Map<u32, f64>[], vector: f64[]): f64[] {
let result: f64[] = new Array(vector.length).fill(0);
for (let i = 0; i < matrix.length; i++) { let row = matrix[i]; for (let j = 0; j < vector.length; j++) { if (row.has(<u32>j)) { result[i] += row.get(<u32>j) * vector[j];
}
}
}
return result;
}
// JavaScript
function sparseMatrixVectorMult(matrix, vector) { let result = new Array(vector.length).fill(0);
for (let i = 0; i < matrix.length; i++) { let row = matrix[i]; for (let j = 0; j < vector.length; j++) { if (row.has(j)) { result[i] += row.get(j) * vector[j];
}
}
}
return result;
}
Sparse Matrix Vcctor Multiplication
Рисунок 9 - Среднее время выполнения теста 5 Figure 9 - Average test execution time 5
Рисунок 10 - Время выполнения каждой итерации теста 5
Figure 10 - Execution time of each iteration of test 5
Среднее время выполнения:
Оценки продемонстрировали явное несоответствие в среднем времени выполнения между AssemblyScript и JavaScript. В частности, среднее время выполнения AssemblyScript было измерено на уровне 19,3 мс, что значительно превосходит 128,9 мс JavaScript. Эта разительная разница более чем в 100 мс подчеркивает возможности оптимизации и эффективность AssemblyScript, особенно для таких сложных операций, как SMVM.
Отклонение во времени итерации:
Изучив согласованность времени выполнения на всех итерациях, AssemblyScript в очередной раз продемонстрировал превосходный профиль производительности. Время его выполнения демонстрировало минимальные колебания, оставаясь в основном в пределах 2 мс. Это свидетельствует о надежной схеме выполнения. С другой стороны, JavaScript, хотя и работал заметно медленнее, также
демонстрировал большую волатильность во времени выполнения, колеблясь в пределах 15 мс.
Такая выраженная изменчивость может иметь последствия для задач, требующих постоянной вычислительной производительности, особенно когда речь идет об обработке в реальном времени или когда оперативность системы имеет первостепенное значение.
В заключение, тест на умножение векторов с разреженной матрицей подчеркивает мастерство AssemblyScript в обработке сложных математических операций, как с точки зрения скорости, так и согласованности. JavaScript, будучи чрезвычайно универсальной и широко распространенной платформой, в этом конкретном контексте демонстрировал ограничения. Эта дихотомия подтверждает важность выбора подходящего вычислительного инструмента для конкретных задач с акцентом на природу базовой операции и желаемые характеристики производительности.
Обсуждение результатов
Сопоставление AssemblyScript и JavaScript для решения множества сложных вычислительных задач раскрывает многогранную картину, которая проясняет сравнительные сильные и слабые стороны и особенности, присущие этим двум языкам программирования. Наша исследовательская статья охватила широкий спектр алгоритмов, каждый из которых был тщательно отобран за его особые вычислительные способности и ощутимую значимость в обширной области как науки, так и программного обеспечения.
Наиболее заметной особенностью является удивительное постоянство производительности языка AssemblyScript. Практически во всех тестах AssemblyScript демонстрировал очень незначительные различия во времени выполнения итераций. В отличие от него, JavaScript демонстрирует в вычислительной области панораму, в которой заметна значительная вариативность. Такая поразительная последовательность - одна из отличительных черт языка AssemblyScript, и она является ценным преимуществом в ситуациях, когда важна определенность и предсказуемость.
В этом сравнительном контексте обе платформы выступают с флагом своих сильных сторон: AssemblyScript неизменно превосходит JavaScript по скорости вычислений. Это превосходство было конкретно продемонстрировано в различных тестах, в частности, в поиске по принципу "Breadth First Search", "Lower Upper Decomposition" и "Sparse Matrix Vector Multiplication". Однако стоит отметить аномалию, наблюдавшуюся в тесте быстрого преобразования Фурье, где JavaScript превзошел AssemblyScript. Это указывает на то, что, хотя AssemblyScript в целом оптимизирован для высокопроизводительных задач, существуют конкретные сценарии или алгоритмы, в которых традиционный JavaScript может обеспечить превосходную эффективность.
В вопросе выбросов и аномалий некоторые тесты, такие как оценка рейтинга страницы, выявили такие особенности, как значительный скачок времени выполнения JavaScript примерно на 102-й итерации. Эти сложные особенности, заложенные в корпусе эмпирических наблюдений, требуют дальнейшего осмысления и изучения. Эта погрешность может быть обусловлена рядом факторов, включая условия проведения тестов, присущие структуре изучаемых алгоритмов или сложные нюансы в оптимизационной структуре движка JavaScript.
Производительность AssemblyScript, являющегося строгим подмножеством TypeScript, который компилируется в WebAssembly, подтверждает перспективность и потенциал WebAssembly в преодолении разрыва между веб- и нативной производительностью. Байт-код WebAssembly разработан с учетом скорости, а его совместимость с веб-браузерами позволяет приложениям работать почти на родной скорости, что наглядно продемонстрировано в наших тестах.
Подводя итог, можно сказать, что в то время как JavaScript остается неукротимой силой в веб-разработке, воплощая гибкость и повсеместность, AssemblyScript, использующий возможности WebAssembly, становится привлекательной альтернативой для задач, требующих больших
вычислительных затрат. Разработчикам и исследователям крайне важно понимать эти нюансы, гарантируя, что они используют оптимальный инструмент для своих конкретных вычислительных потребностей. Будущие исследования могут углубить изучение экологических и внутренних факторов, влияющих на производительность, и дать еще более детальное представление о сравнительных возможностях этих платформ.
Заключение
Область вычислительной эффективности в веб-приложениях остается в состоянии постоянного изменения, отражая неумолимую эволюцию цифрового ландшафта. На этой обширной территории стремление к объединению таких качеств, как надежность, быстрота и адаптивность, приобретает первостепенное значение. Это эмпирическое исследование было посвящено выяснению характеристик производительности, которые определяют AssemblyScript и JavaScript, ориентируясь в этой сложности с помощью обширного набора алгоритмических тестов.
Наш метаанализ превозносит мастерство, демонстрируемое AssemblyScript, особенно когда ему доверяют вычислительные задачи, требующие согласованности и оперативности в качестве основных предпосылок. Синергетический резонанс, присущий AssemblyScript и архитектурному проекту WebAssembly, делает его достойным соперником в неустанном стремлении к оптимизации производительности в среде web-native. JavaScript, с его обширной экосистемой и доказанной надежностью, демонстрирует свои сильные стороны, но также выявляет определенные несоответствия в производительности, особенно по сравнению с более детерминированным поведением AssemblyScript.
Однако крайне важно отметить, что, хотя показатели производительности дают бесценную информацию, при выборе платформы программирования следует также учитывать другие аспекты, такие как экосистема разработки, поддержка сообщества и адаптируемость к конкретным требованиям проекта.
Результаты этого исследования подчеркивают жизнеспособность непрерывных исследований в области веб-вычислений. По мере развития AssemblyScript и JavaScript, наряду с более широким спектром языков программирования и инструментов, техническое сообщество стоит на пороге дальнейших революционных открытий. Это исследование служит маяком, освещающим разработчикам и исследователям путь к принятию обоснованных решений, определяющих будущее эффективного, надежного и бесшовного цифрового взаимодействия.
Список использованной литературы:
1. Первое знакомство с AssemblyScript. [Электронный ресурс] - URL: https://habr.com/ru/companies/ruvds/ articles/477272/
2. Грольш Л. Веб-сборка: основы //Технический университет Брауншвейга. - 2019.
3. Основы движка JavaScript: оптимизация прототипов. 2018 [Электронный ресурс] - URL: https://mathiasbynens.be/notes/prototypes#tradeoffs
4. Оптимизируем производительность: JavaScript (V8) vs AssemblyScript (Web Assembly). [Электронный ресурс] - URL: https://habr.com/ru/companies/macloud/articles/554860/
5. Вычисление. [Электронный ресурс] - URL: https://nischayv.github.io/as-benchmarks/computation /dist/index.html
6. Лабоскин А.С. Исследование и сравнительный анализ производительности AssemblyScript // Инженерный вестник Дона, №11. 2023
References
1. First introduction to AssemblyScript. [Electronic resource] - URL: https://habr.com/ru/
companies/ruvds/articles/477272/
2. Golsch L. WebAssembly: Basics //Technical University of Braunschweig. - 2019.
3. JavaScript engine fundamentals: optimizing prototypes. 2018 [Electronic resource] - URL: https://mathiasbynens.be/notes/prototypes#tradeoffs
4. Optimizing performance: JavaScript (version 8) vs AssemblyScript (web assembly). [Electronic resource] - URL: https://habr.com/ru/companies/macloud/articles/554860/
5. Computation. [Electronic resource] - URL: https://nischayv.github.io/as-benchmarks/computation/dist/ index.html
6. Laboskin A.S. Research and comparative analysis of AssemblyScript performance // Engineering Bulletin of the Don, No. 11. 2023
© Koco6pog,OB C.K., 2023
УДК 658
Лелет Д.В.
магистрант 2 курса СпбГУАП,
ПРОДОЛЖИТЕЛЬНОСТЬ ПРОЕКТА Аннотация
Продолжительность проекта играет ключевую роль в его успехе. Она определяет время, необходимое для выполнения задач, достижения поставленных целей и получения желаемых результатов.
Ключевые слова
Продолжительность, время, цель, результат, длительность, сроки.
В современных условиях экономического и политического противостояния России и Запада особо остро встает проблема поиска отечественными производителями новых и при этом устойчивых конкурентных преимуществ. Санкционные ограничения, устанавливаемые в отношении нашей страны иностранными партнерами, заставляют отечественные предприятия осуществлять ускоренный поиск возможностей сохранения своих рыночных позиций. Одним из важнейших, интегральных параметров, обеспечивающих организации лидирующее конкурентное положение, является высокое качество выпускаемой и реализуемой продукции. При этом технико-технологический потенциал российской промышленности находится на достаточно низком уровне, что связано с высокой степенью морального и физического износа основных производственных фондов, использованием устаревших технологий и их замедленной модернизацией, что ограничивает вовлечение в хозяйственный оборот высококвалифицированной рабочей силы. Ко всему прочему для нашей экономики практически полностью исчерпались резервы экстенсивного роста: падение высоких цен на мировых рынках энергоносителей, сокращение стимулирующего эффекта от девальвации национальной валюты, низкая цена рабочей силы, сдерживающая рост производительности труда и инвестиционной активности.
Динамика производства автомобилей в крупнейших странах-производителях приведена в табл. 1.
