Рубрика «быстродействие»

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

Известный комикс (https://xkcd.ru/505/), которым и навеяна идея статьи
Известный комикс (https://xkcd.ru/505/), которым и навеяна идея статьи

Инфляция временных единиц

Читать полностью »

Это вторая часть статьи про numba. В первой было историческое введение и краткая инструкция по эксплуатации numba. Здесь я привожу слегка модифицированный код задачи из статьи про хаскелл «Быстрее, чем C++; медленнее, чем PHP» (там сравнивается производительность реализаций одного алгоритма на разных языках/компиляторах) с более детальными бенчмарками, графиками и пояснениями. Сразу оговорюсь, что я видел статью Ох уж этот медленный C/C++ и, скорее всего, если внести в код на си эти правки, картина несколько изменится, но даже в этом случае то, что питон способен превысить скорость си хотя бы в таком варианте, само по себе является примечательным.

Python (+numba) быстрее си — серьёзно?! Часть 2. Практика - 1

Читать полностью »

Давно собирался написать статью о numba и о сравнении её быстродействия с си. Статья про хаскелл «Быстрее, чем C++; медленнее, чем PHP» подтолкнула к действию. В комментариях к этой статье упомянули о библиотеке numba и о том, что она магическим образом может приблизить скорость выполнения кода на питоне к скорости на си. В данной статье — чуть более подробный разбор этой ситуации (часть 2) и рекомендации по «приручению» numba (часть 1).

Python (+numba) быстрее си — серьёзно?! Часть 1. Теория - 1

Читать полностью »

Уже 20 лет прошло с момента выпуска первой 3D-версии КОМПАС — V5.11. За это время мы поняли, что потребности наших пользователей растут пропорционально возможностям КОМПАС-3D, так же как и функциональность КОМПАС расширяется пропорционально запросам пользователей. Только вот одна загвоздка: наращивая долгие годы технологическую часть, мы упирались в проблему производительности при работе со сложными большими проектами. Теперь и этот рубеж преодолен, и мы готовы рассказать, как нам удалось ускорить КОМПАС-3D на более чем 30 базовых операциях.

Как мы разогнали САПР КОМПАС-3D → Часть 1 - 1Читать полностью »

На Хабре в комментариях к статьям о выходе новых версий операционных систем, выпуске новых моделей ноутбуков, накопителей данных, модулей памяти и т.п. регулярно высказывается мнение о том, что только наипоследнейшая версия операционной системы известного вендора даёт возможность современному гику не скатиться в унылое г… очувствовать себя человеком, и только тот, у кого стоитустановлена Windows 8, 10, 11, 9000 (нужное подчеркнуть), будет пользоваться популярностью у девушекработодателей и клиентов. По причинам изложенным ниже я полагаю таковое мнение глубоко ошибочным и даже ущербным, показывающем неспособность владельца компьютера оптимально использовать имеющиеся в его распоряжении аппаратные и программные ресурсы.
Читать полностью »

Тесты в предыдущей статье убедительно показали высокую эффективность «автоматной» реализации примера «Дисплей» по сравнению с условно названной «неавтоматной» версией. Вкратце итог: обе реализации автоматные, но разница в эффективности многократна и глубинная причина видится в том, что вариант А1 («автоматный») изначально проектировался как автомат, а вариант А2 («неавтоматный») нет. Не столько автоматная реализация, сколько автоматное проектирование является основой высокой эффективности. Для простых алгоритмов автоматные реализации получаются сами собой. Есть смысл говорить о том, что автоматное программирование, это не столько реализация программы в виде конечного автомата, сколько автоматное проектирование, фундаментом которого является конструктивная декомпозиция. Я несколько раз касался темы автоматного проектирования и конструктивной декомпозиции, но чтобы раскрыть эту тему нужны практические примеры. В этой и следующих нескольких статьях я проведу практикум, покажу процесс автоматного проектирования, пытаясь по возможности приводить ход рассуждений присущих автоматному проектированию.
Читать полностью »

В предыдущих двух статьях речь шла о диаграмме состояний и переходов, используемой для описания динамических процессов в автоматном стиле, и о том, что диаграмма состояний и переходов даёт наилучшее понимание таких процессов. Также были рассмотрены базовые методы реализации автоматов, заданных диаграммой состояний, и были очерчены артефакты автоматной схемотехники, доставшиеся от неё автоматному программированию. Но, до сих пор совершенно не затронут вопрос: насколько эффективны автоматно-реализованные программы?
Я бы сформулировал вопрос иначе: насколько эффективны автоматно-спроектированные программы? Такая формулировка вопроса намекает, что автоматное проектирование — источник высокой эффективности программ. Я ещё практически не касался столь важной темы как эффективность, и пример «Дисплей» идеально подходит для иллюстрации эффективности автоматного проектирования. В первой статье я познакомил читателей с «лабораторной» версией этого модуля, но тестировать я буду «боевой» вариант, процесс проектирования которого я приведу в следующей статье. Исследование эффективности будет выполнено для платформ msp430 и CortexM3.
Чтобы не быть субъективным, оценивая эффективность, нужно с чем-то сравнивать результаты. Поэтому я проведу тот же комплекс испытаний для неавтоматной реализации примера «Дисплей» любезно предоставленной michael_vostrikov, за что ему огромная благодарность и плюсы в карму.

Читать полностью »

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

Если мне надо узнать, "какой язык быстрее для меня на моей задаче", то я прогоню самый примитивный бенчмарк в мире. Если разница будет существенной (скажем, на порядок) — то скорее всего и на пользовательской машине все будет примерно также.

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

Читать полностью »

16 июня 2016 года в рамках симпозиума 2016 Symposium on VLSI Technology and Circuits, прошедшего недавно в Гонолулу, группой специалистов факультета Электроники и Вычислительной техники (Department of Electrical and Computer Engineering) Калифорнийского Университета в Дэвисе был представлен действующий прототип чипа KiloCore, на кристалле которого уместилась тысяча независимых программируемых процессоров. Общее число транзисторов на кристалле чипа составило 621 миллион единиц, а максимально развиваемое быстродействие приблизилось к рекордной отметке 1.78 триллиона операций в секунду.

image
Читать полностью »

Недавно очередной раз отработал со студентам 2-го курса 2-семестровую дисциплину «Алгоритмические языки». Обзорно рассмотрели несколько дюжин языков программирования. Один из студентов, Вадим Шукалюк, захотел получше с ними познакомиться, получить более четкое представление о каждом из них. Посоветовал ему провести небольшое исследование. Чем и увлёк. Предлагаю свой отчёт по проделанной за несколько месяцев вместе с ним работе.

У каждого языка программирования есть свои достоинства и недостатки. Одна из важнейших характеристик транслятора с любого языка — это скорость исполнения программ. Очень трудно или даже невозможно получить точную оценку такой скорости исполнения. Ресурс http://benchmarksgame.alioth.debian.org/ предлагает игровую форму для проверки такой скорости на разных задачах. Но число языков, представленных на этом ресурсе, довольно невелико. Предельную ёмкость стека, критическую величину для рекурсивных вычислений проверить проще, но она может меняться в разных версиях транслятора и быть зависимой от системных настроек.

Тестировались следующие трансляторы: си (gcc, clang, icc), ассемблер (x86, x86-64), ява (OpenJDK), паскаль (fpc), яваскрипт (Google Chrome, Mozilla Firefox), лисп (sbcl, clisp), эрланг, хаскель (ghc, hugs), дино[1], аук (gawk, mawk, busybox), луа, рубин, бейсик (gambas, libre office), питон-2, пи-эйч-пи, постскрипт (gs), пролог (swipl, gprolog), перл, метапост, ТEХ, тикль, бэш. Исследовались как собственно скорость исполнения нескольких небольших, но трудоёмких алгоритмов, так и:

  • качество оптимизации некоторых трансляторов;
  • особенности при работе с процессорами Intel и AMD;
  • предельное число рекурсивных вызовов (ёмкость стека).

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js