Софт-Архив

Linpack img-1

Linpack

Рейтинг: 4.7/5.0 (1850 проголосовавших)

Описание

Между строк таблиц Linpack - № 13, 1998

Между строк таблиц Linpack

Михаил Кузьминский

Издательство «Открытые Системы»

В советские времена наши сограждане были приучены читать газеты "между строк", поскольку до скрытого смысла добраться было не так просто. Разнообразные числовые таблицы, содержащие сравнительные оценки производительности компьютеров или их процессоров, также дают богатую пищу для анализа, позволяя прийти к весьма интересным выводам. Сегодня мы предлагаем читателю путешествие в числовые дебри результатов тестов производительности Linpack.

Хотя мы достаточно часто используем такие оценки производительности в наших публикациях, полезно напомнить, что же именно представляют собой эти тесты. Строго говоря, имеется несколько разных тестов Linpack, математической основой которых является решение системы из N линейных уравнений с N неизвестными методом исключения Гаусса.

Естественно, эти тесты дают оценку производительности с плавающей запятой. Для каждого N известно, сколько операций с плавающей запятой нужно выполнить, чтобы решить систему линейных уравнений данным методом. Тогда, поделив число этих операций на время выполнения теста в секундах, можно получить оценку производительности в MFLOPS - миллионах операций с плавающей запятой в секунду. Отметим, что подобные оценки предполагают "равнозначность" различных операций с плавающей запятой, в том числе сложения и умножения, что является слабым местом: умножение может требовать больше тактов, чем сложение.

В тестах Linpack принято проводить расчеты при N=100 и N=1000, чему соответствует работа с векторами средней и большой длины соответственно. В таблицах обычно приводится также и третья характеристика - пиковая производительность R (теоретический предел числа операций с плавающей запятой в секунду). Для типичного суперскалярного микропроцессора (МП), умеющего выполнять за один такт одно сложение и одно умножение с плавающей запятой (при этом предполагается, что конвейеры заполнены), R=2xm, где m - тактовая частота в МГц.

Тесты Linpack для N=100 представляют собой программу на Фортране, исходный текст которой менять не разрешается. Лишь подпрограмма, возвращающая время выполнения, может считаться "своей" для данного компьютера. Таким образом, измеряемая производительность компьютера зависит от качества компилятора. Не исключено, что при "ручном" кодировании на языке Ассемблера теоретически и возможно было бы что-то улучшить, но программисты, как правило, все равно используют компилятор и "видят" именно такую производительность. Кроме того, современные компиляторы обычно умеют генерировать обращения к высокоэффективным (написанным на Ассемблере) подпрограммам линейной алгебры из пакета BLAS или встраивать соответствующие коды прямо в тело программы.

Эту своего рода "однозначность" (независимость от мастерства программиста) можно упомянуть в качестве одной из причин, почему в поддерживаемом нашей газетой списке top10 крупнейших российских суперкомпьютерных центров мы используем именно тест Linpack при N=100.

N=1000 допускает уже определенные "вольности" с текстом теста. Еще большие изменения становятся возможны при работе с тестом Linpack parallel, который IBM в своих информационных материалах обычно именует Linpack TPP. Задача этого теста - достижение максимальной производительности при неограниченном увеличении величины N. Поскольку это приводит к сверхбольшим векторам, для оценки того, сколь быстро с ростом N удается восходить к максимуму производительности, вводится понятие "половинной N", N(1/2) - размерности, при которой достигается половина от максимальной полученной производительности.

Оценки производительности на тестах Linpack существуют для всех компьютеров - от обычных персоналок и рабочих станций до мощных серверов и суперкомпьютеров. Естественно, в многопроцессорных системах исследуется зависимость результата от числа процессоров, то есть тест распараллеливается. Зависимость производительности от числа процессоров показывает качество распараллеливания на данной вычислительной установке.

При N=100 распараллелиться практически не удается. Лишь для некоторых векторных супер-ЭВМ, в том числе компании SGI/Cray Research, имеются соответствующие данные, свидетельствующие о незначительном ускорении. Напротив, тест Linapck parallel всегда предполагает распараллеливание; результаты таких тестов имеются, в основном, для суперкомпьютерных систем. К недостаткам теста Linpack parallel cпециалисты в области суперкомпьютерных технологий часто относят тот факт, что позволяет так реализовать вычисления, что данные достаточно хорошо локализуются в кэше современных процессоров. Это означает, что уменьшается нагрузка на тракт "процессор-оперативная память", и его пропускная способность в нужной степени не тестируется.

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

Сквозь "линпаковский" кристалл

Естественно, в одной публикации невозможно рассказать обо всех интересных выводах, которые напрашиваются, если взглянуть на компьютеры и их процессоры "сквозь призму тестов Linapck". Мы решили остановиться на сопоставлении эффективности использования многопроцессорных компьютеров ведущих фирм-производителей на тестах Linpack. Попробуем пристальнее присмотреться к результатам данных тестов Linpack.

В табл. 1 представлены данные тестов Linpack parallel. В сравниваемых системах используются следующие микропроцессоры: DEC Alpha 21164 с частотой 600 МГц - в SGI/Cray T3E-1200; Sun UltraSPARC II с тактовой частотой 333 МГц - в серверах HPC 10000; IBM Power 2 (P2SC) c тактовой частотой 160 МГц - в серверах IBM SP2; РА-8000 с частотой 180 МГц и PA-8200 c частотой 240 МГц - в серверах от HP X- и V-класса соответственно; Alpha 21164 с тактовой частотой 440 МГц - в кластерах на базе SMP-серверов AlphaServer 8400; SGI/MIPS R10000 с тактовой частотой 195 МГц - в серверах Origin 2000. К сожалению, пока отсутствуют данные для 250 МГц версии R10000, а также результаты Linpack parallel для кластеров AlphaServer 8400 с 612-мегагерцевым Alpha 21164.

Таблица 1.

Производительность на тестах Linpack parallel, GFLOPS

Другие статьи, обзоры программ, новости

Linpack Benchmark Results - Roy Longbottom s PC benchmark Collection

Description

This benchmark was produced by Jack Dongarra from the "LINPACK" package of linear algebra routines. It became the primary benchmark for scientific applications from the mid 1980's with a slant towards supercomputer performance.

The original version was produced in Fortran but a "C" version appeared later. The standard "C" version operates on 100x100 matrices in double precision with rolled/unrolled and single/double precision options. The pre-compiled versions are double precision, rolled, optimised and non-optimised. These can be found in BenchNT.zip which also contains the source code, providing further explanatory comments. DOS versions are available in DosTests.zip and those to run via OS/2 in OS2Tests.zip. Then there is My Main Page for other PC benchmarks and results.

The benchmark has also been compiled with Microsoft 32 bit and 64 bit compilers that generate SSE and SSE2 instructions for floating point. The original 2006 64 bit version indicated poor performance on Core 2 Duo CPUs but this was corrected using a later compiler in 2009 - see Vista64.htm. Compiled codes (2006 and 2009 versions) are in Win64.zip with source code in NewSource.zip. See also Win64.htm.

Performance rating is in terms of Millions of Floating Point Operations Per Second (MFLOPS).

Linpack Reference - Jack Dongarra, Performance of Various Computers Using Standard Linear Algebra Software in a Fortran Environment from Here - PDF file including numerous results for minicomputers, workstations, mainframes and supercomputers.

The following is a sample of results. Performance tends to be proportional to CPU MHz for a given type of processor but is also affected by cache size and speed. There can also be variations probably depending on where the data happens to be stored in cache. Details of cache sizes and range of CPU MHz can be found in CPUSpeed.htm. Results include those from DOS and Windows compilations that produce very similar speed measurements. Some SSE2 and OS/2 results are included at the bottom of the table, then sample results from a later Microsoft compiler, particularly to include an Intel Atom based tablet, using Windows 10.

Other results are for the same code ported to 32-Bit and 64-Bit Linux using the supplied GCC compiler (all free software) - see linux benchmarks.htm and download benchmark execution files, source code, compile and run instructions in classic_benchmarks.tar.gz. Using Windows the file downloaded wrongly as classic_benchmarks.tar.tar but was fine when renamed classic_benchmarks.tar.gz. Results are shown separately below. A 2013 version of GCC has the option to compile for AVX1, a more recent addition to the Intel instruction set. This can potentially double maximum SSE/SSE2 speeds. Results are included below. and certainly show much improved performance. The AVX version of the benchmark is included in AVX_benchmarks.tar.gz. Further details are in Linux AVX benchmarks.htm.

Android and Raspberry Pi Versions

Later conversions were varieties to run on Android tablets and phones on ARM CPUs. Most use a Java front end for starting and displaying results, with the compiled C code for calculations. Download:

and install in the usual way for such devices. The v7 program, and single precision (SP) variety are compiled for newer hardware than the v5 version. Then there is a benchmark with all Java code. See - android benchmarks.htm. Android Native ARM-Intel Benchmarks.htm and Android 64 Bit Benchmarks.htm The former includes LinpackJava.apk results from PCs via Android x86, details are here. Latest are modified to use NEON SIMD functions that that carry out four arithmetic operations simultaneously. Download:

May 2015 - It was found that the NEON SIMD benchmark could be compiled to produce Intel SSE instructions, for the Android Native ARM-Intel Benchmarks. The benchmark can be downloaded the following. It automatically selects the target CPU at 32 bits or 64 bits from ARM, Intel or MIPS.

Latest benchmarks were compiled and run on a Raspberry Pi that uses ARM CPUs and Linux. See Raspberry Pi Benchmarks.htm and download from Raspberry_Pi_Benchmarks.zip. After this, the benchmarks were recompiled to use native code on Intel processor based Android devices. Then updated, inculding Raspberry Pi 2, exising benchmarks and new version from a later compiler.

MultiThreading Versions

This version uses mainly the same C programming code as the single precision floating point NEON compilation above. It is run run on 100x100, 500x500 and 1000x1000 matrices using 0, 1, 2 and 4 separate threads. Virtually the same programming code was used to produce execution files for ARM devices/Android, PCs/Linux and PCs/Windows. The latter two were compiled to use SSE instructions, that can carry out up to four operations simultaneously. Again see android neon benchmarks.htm. Download:

A new version, that automatically selects the target CPU at 32 bits or 64 bits from ARM, Intel or MIPS, can be downloaded from:

Slight changes were made to the original version to allow a higher level of parallelism. The initial 100x100 Linpack benchmark was only of use for measuring performance of single processor systems. The one for shared memory multiple processor systems is a 1000x1000 variety. The programming code for this is the same as 100x100, except users are allowed to use their own linear equation solver.

This program can run much slower using multiple threads due to the overhead of creating and closing threads too frequently. Using data size N x N, approximately 0.67 x N x N x N floating point calculations are carried out but, with this program, there are N breaks for handling threads (can someone do better?). Results show that overheads from these are generally constant executing up to four threads. Results below include overheads of using a single thread at 100x100 (microseconds difference from no threads / 100). In most cases, overheads (per N) increase with larger arrays, as performance becomes more dependent on higher level caches or RAM data transfers.

Results below show no performance gains due to multiprocessing on the ARM based devices. Constant performance of the Netbook, with no threads, suggests a CPU speed limitation, then gains with two threads due to Hyperthreading. The Core 2 Duo shows the best improvement using two threads. At least the Phenom shows some gain with four threads, using Linux but not via Windows.

Particularly with multithreading, it is important to verify that calculations produce the same numeric results, irrespective of the number of threads used. This benchmark checks for that and reports if there are errors. These results are shown below and are the same on Android, Linux and Windows. For completion, numeric results and a sample of performance are provided for a double precision compilation.

At some point in time, a Java version of the Linpack benchmark rearranged the order of initial data (function matgen) and this changed the numeric results. These are shown below.

Linpack for Android - GreeneComputing

Linpack for Android

The Linpack for Android application is a version created from the original Java version of Linpack created by Jack Dongarra.  That version is located at netlib.org

The LINPACK Benchmarks are a measure of a system’s floating point computing power. Introduced by Jack Dongarra, they measure how fast a computer solves a dense N by N system of linear equations Ax = b, which is a common task in engineering. The solution is obtained by Gaussian elimination with partial pivoting, with 2/3*N 3  + 2*N 2 floating point operations. The result is reported in Millions of FLoating-point Operations Per Second (MFLOP/s, sometimes simply called FLOPS ).

This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor. Software written for an Android device is written using Java code that the Dalvik VM interprets at run time.

Questions asked about the app:

What is the purpose of this app?

This is a simple benchmark test to show performance relative to other phones for a standard calculation.  Linpack has been used for years on all types of computers, with a version used to rate the TOP500 computers in the world.

What speed is better?

A higher number is better.  From the Top Devices list, you can see that each device has a certain range that they all come in at.  What can effect the number is what else is running on android and the ROM version.  It appears that Android 2.0 will also improve performance.

Does having faster speed improve the android phones or what?

Yes, it should.  The Dalvik VM has a huge impact on the Linpack number.  A better number on the same device would indicate that a new version update has improved performance.  Or it could show that something has gone terribly wrong if the number goes down.

VoxLuna   5 Jan 2010 

Might serve a purpose, but bland layout (and ugly AdMob).  Why a splash when there’s also a weblink button?  See “Louder Volume” app for UI Inspiration.

Linpack benchmark

Linpack benchmark Содержание 1 Свойства и структура алгоритма 1.1 Общее описание алгоритма

Linpack benchmark является тестом, разработанным как приложение к библиотеке Linpack для тестирования производительности компьютерных систем. По сути это генерирование некоторой системы линейных алгебраических уравнений (СЛАУ) со случайной плотной квадратной матрицей и вектором таким, чтобы решением был вектор , у которого все элементы равны 1, с последующим решением этой СЛАУ. Решение в силу неспецифичности (с рядом оговорок) матрицы делается в два этапа. Сначала для матрицы системы выполняется -разложение ( — матрица перестановок, — левая треугольная с единичными диагональными элементами, — правая треугольная матрица) методом Гаусса с выбором ведущего элемента по столбцу. На втором этапе с помощью полученного разложения последовательно решается СЛАУ вида . На третьем этапе вычисляется невязка и её характеристики, после чего выводятся данные о полученных точности и производительности вычислений. Интересно, что производительность вычисляется только для основной части алгоритма, т. е. туда не включены ни вычисление невязки, ни вычисление норм.

Не следует путать Linpack benchmark, разработанный для тестирования компьютеров традиционной архитектуры, и High Performance Linpack benchmark, который разработан для тестирования компьютерных систем с параллельной архитектурой и в основе которого лежит хоть и сходный, но другой алгоритм.

1.2 Математическое описание алгоритма

Исходные данные: невырожденная (ГСЧ подобран так, чтобы это обеспечивалось, в версии от 1992 г.) квадратная матрица (элементы ), вектор правой части (элементы ). В реальности они не вполне входные (элементы матрицы генерирует псевдослучайно сама программа, все они находятся в диапазоне (-1/2, +1/2), ), но для разбора общей схемы алгоритма удобно считать их входными данными.

Вычисляемые данные: левая треугольная матрица (элементы ), правая треугольная матрица (элементы ), матрица перестановок (вычисляется не в развёрнутом виде, а как набор номеров ведущих элементов), вектор решения (элементы ).

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

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

Вторая часть состоит из двух решений треугольных СЛАУ. Сначала c помощью «прямой-обратной» подстановки решается система , затем с помощью обратной подстановки — система . При этом в тесте треугольные матрицы хранятся в соответствующих местах матрицы . Поэтому перед началом третьей части её генерируют заново (с теми же стартовыми параметрами для ГСЧ).

Третья часть (для которой не измеряется скорость работы) состоит в вычислении сначала невязки решения и затем её равномерной нормы, а также нормы решения. По окончании этой части алгоритм выдаёт данные по точности полученного решения, а также вычисляет производительность системы.

1.3 Вычислительное ядро алгоритма

Основная часть алгоритма — разложение матрицы методом Гаусса с выбором ведущих элементов по столбцу — определяет основную часть операций. Следующая по значимости часть — вычисление невязки и её нормы — реализовано подпрограммой вычисления суммы вектора и произведения матрицы на другой вектор и функцией вычисления равномерной нормы. Третьи по значимости части — обратный ход метода Гаусса и «прямой-обратный» ход метода Гаусса.

1.4 Макроструктура алгоритма

Как уже записано в описании ядра алгоритма, разложение матрицы методом Гаусса с выбором ведущих элементов по столбцу — определяет основную часть операций и при этом является первой макрооперацией. После неё идёт «прямой-обратный» ход метода Гаусса и сразу за ним — обратный ход метода Гаусса. После повторного заполнения матрицы следующей макрооперацией является вычисление невязки решения СЛАУ, а затем — вычисление её и вектора решения равномерных норм.

1.5 Схема реализации последовательного алгоритма

Математическое описание алгоритма описано выше. При этом в стандартном тесте из-за того, что разложение Гаусса вычисляется на месте исходной матрицы, а также из-за того, что при прямом-обратном и обратном ходе решение заанимает место правой части, после вычисления решения приходится заново перевычислять как матрицу системы, так и правую часть — для последующего вычисления невязки. После вычисления невязки её норма в принципе может быть вычислена в любом порядке с нормой решения, это не влияет на алгоритм и его результаты.

1.6 Последовательная сложность алгоритма

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

1.7 Информационный граф

Граф состоит из информационных графов своих основных частей. Первая часть (метод Гаусса с выбором ведущего элемента по столбцу) имеет самый сложный из графов. На рис.1 отражён упрощённый граф этой части, post factum по результатам выборов ведущих элементов. Зеленым отображены операции определения максимумов, с запоминанием позиций. Желтым цветом выделено обращение очередного ведущего элемента, коричневым – умножения в текущем столбце, фиолетовым – операции в других столбцах. На рис.2 приведён граф одного из слоёв (одного шага метода). Обозначения – те же самые, что в полном графе. Пунктир означает рассылку данных из ведущей строки.

Linpack

Одной из альтернативных единиц измерения производительности процессора (по отношению к времени выполнения) является MIPS - (миллион команд в секунду). Имеется несколько различных вариантов интерпретации определения MIPS.

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

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

Однако использование MIPS в качестве метрики для сравнения наталкивается на три проблемы. Во-первых, MIPS зависит от набора команд процессора, что затрудняет сравнение по MIPS компьютеров, имеющих разные системы команд. Во-вторых, MIPS даже на одном и том же компьютере меняется от программы к программе. В-третьих, MIPS может меняться по отношению к производительности в противоположенную сторону.

Классическим примером для последнего случая является рейтинг MIPS для машины, в состав которой входит сопроцессор плавающей точки. Поскольку в общем случае на каждую команду с плавающей точкой требуется большее количество тактов синхронизации, чем на целочисленную команду, то программы, используя сопроцессор плавающей точки вместо соответствующих подпрограмм из состава программного обеспечения, выполняются за меньшее время, но имеют меньший рейтинг MIPS. При отсутствии сопроцессора операции над числами с плавающей точкой реализуются с помощью подпрограмм, использующих более простые команды целочисленной арифметики и, как следствие, такие машины имеют более высокий рейтинг MIPS, но выполняют настолько большее количество команд, что общее время выполнения значительно увеличивается.

Другое определение MIPS связано с очень популярным когда-то компьютером VAX 11/780 компании DEC. Именно этот компьютер был принят в качестве эталона для сравнения производительности различных машин. Считалось, что производительность VAX 11/780 равна 1MIPS (одному миллиону команд в секунду).

Третье определение MIPS связано с IBM RS/6000 MIPS. Дело в том, что ряд производителей и пользователей (последователей фирмы IBM) предпочитают сравнивать производительность своих компьютеров с производительностью современных компьютеров IBM, а не со старой машиной компании DEC. Соотношение между VAX MIPS и RS/6000 MIPS никогда широко не публиковались, но 1 RS/6000 MIPS примерно равен 1.6 VAX 11/780 MIPS.

Измерение производительности компьютеров при решении научно-технических задач, в которых существенно используется арифметика с плавающей точкой, всегда вызывало особый интерес. Именно для таких вычислений впервые встал вопрос об измерении производительности, а по достигнутым показателям часто делались выводы об общем уровне разработок компьютеров. Обычно для научно-технических задач производительность процессора оценивается в MFLOPS (миллионах чисел-результатов вычислений с плавающей точкой в секунду, или миллионах элементарных арифметических операций над числами с плавающей точкой, выполненных в секунду).

Как единица измерения, MFLOPS, предназначена для оценки производительности только операций с плавающей точкой, и поэтому не применима вне этой ограниченной области. Например, программы компиляторов имеют рейтинг MFLOPS близкий к нулю вне зависимости от того, насколько быстра машина, поскольку компиляторы редко используют арифметику с плавающей точкой.

Ясно, что рейтинг MFLOPS зависит от машины и от программы. Этот термин менее безобидный, чем MIPS. Он базируется на количестве выполняемых операций, а не на количестве выполняемых команд. По мнению многих программистов, одна и та же программа, работающая на различных компьютерах, будет выполнять различное количество команд, но одно и то же количество операций с плавающей точкой. Именно поэтому рейтинг MFLOPS предназначался для справедливого сравнения различных машин между собой.

Однако и с MFLOPS не все обстоит так безоблачно. Прежде всего, это связано с тем, что наборы операций с плавающей точкой не совместимы на различных компьютерах. Например, в суперкомпьютерах фирмы Cray Research отсутствует команда деления (имеется, правда, операция вычисления обратной величины числа с плавающей точкой, а операция деления может быть реализована с помощью умножения делимого на обратную величину делителя). В то же время многие современные микропроцессоры имеют команды деления, вычисления квадратного корня, синуса и косинуса.

Другая, осознаваемая всеми, проблема заключается в том, что рейтинг MFLOPS меняется не только на смеси целочисленных операций и операций с плавающей точкой, но и на смеси быстрых и медленных операций с плавающей точкой. Например, программа со 100% операций сложения будет иметь более высокий рейтинг, чем программа со 100% операций деления.

Решение обеих проблем заключается в том, чтобы взять каноническое или нормализованное число операций с плавающей точкой из исходного текста программы и затем поделить его на время выполнения.

LINPACK - это пакет фортран-программ для решения систем линейных алгебраических уравнений. Целью создания LINPACK отнюдь не было измерение производительности. Алгоритмы линейной алгебры весьма широко используются в самых разных задачах, и поэтому измерение производительности на LINPACK представляют интерес для многих пользователей. Сведения о производительности различных машин на пакете LINPACK публикуются Аргоннской национальной лабораторией (США) и периодически обновляются.

В основе алгоритмов действующего варианта LINPACK лежит метод декомпозиции. Исходная матрица размером 100х100 элементов (в последнем варианте размером 1000х1000) сначала представляется в виде произведения двух матриц стандартной структуры, над которыми затем выполняется собственно алгоритм нахождения решения. Подпрограммы, входящие в LINPACK, структурированы. В стандартном варианте LINPACK выделен внутренний уровень базовых подпрограмм, каждая из которых выполняет элементарную операцию над векторами. Набор базовых подпрограмм называется BLAS (Basic Linear Algebra Subprograms). Например, в BLAS входят две простые подпрограммы SAXPY (умножение вектора на скаляр и сложение векторов) и SDOT (скалярное произведение векторов). Все операции выполняются над числами с плавающей точкой, представленными с двойной точностью. Результат измеряется в MFLOPS.

Использование результатов работы тестового пакета LINPACK с двойной точностью как основы для демонстрации рейтинга MFLOPS стало общепринятой практикой в компьютерной промышленности. При этом следует помнить, что при использовании исходной матрицы размером 100х100, она полностью может размещаться в кэш-памяти емкостью, например, 1 Мбайт. Если при проведении испытаний используется матрица размером 1000х1000, то емкости такого кэша уже недостаточно и некоторые обращения к памяти будут ускоряться благодаря наличию такого кэша, другие же будут приводить к промахам и потребуют большего времени на обработку обращений к памяти. Для многопроцессорных систем также имеются параллельные версии LINPACK и такие системы часто показывают линейное увеличение производительности с ростом числа процессоров.

Linpack

Терминальная программа LinPac автор Radek Burget, OK2JBG

Удобная терминальная программа для Linux с BayCom-подобным интерфейсом. Работает только с портами прописанными в /etc/ax25/axports. Программа поддерживает протоколы AUTOBIN, YAPP и 7PLUS для передачи и приема бинарных файлов. Для Linpac есть дополнительный модуль который позволяет работать не только в текстовой консоли, но и в X11 и модуль для автоматического обмена почтой с F6FBB. Домашняя страница linpac.sourceforge.net.

Инсталяция

Распакуйте архив с исходниками программы LinPac в директории /root. Для инсталяции программы дайте последовательно команды: Дайте команду linpac и ответьте на несколько вопросов, после этого в вашей домашней директории будет создана директория LinPac/ внутри которой будут располагаться ваши файлы настроек. В качестве имени порта используйте то имя которое указано у вас в файле /etc/ax25/axports. Для конфигурирования программы служит файл /root/LinPac/macro/init.mac Также можно сделать изменения в файлах: ctext.mac, info.mac, quit.mac. Файл init.mac в вашей директории, перечитывается каждый раз при запуске LinPac.

Файлы и директории

Файлы с вашей конфигурацией записываются в /your_home_dir/LinPac/

Программа располагается в директориях /usr/local/bin/. /usr/local/share/ и /usr/local/doc/.

В /your_home_dir/LinPac/user/ могут заходить пользователи из эфира.

F1-F8 переключение между виртуальными терминалами

F10 мониторинг и передача unproto-пакетов

Alt+X выход из программы

c sp0:rw6hqn-2 соединиться с указанным позывным через порт sp0

Linpack test

of the Theoretical Department of INR RAS

Total performance: 304.6 GFlops (2.77 GFlop/processor)

  • cluster01-07. 14 processors,
performance 36.62 GFlops (2.62 GFlop/processor)
  • Optimizing over Nb: graph. Nb=28 .
  • Optimizing over problem size: graph. N=40000 .
  • Optimizing over other parameters: HPL.dat. HPL.out .
  • cluster11-16. 24 processors, performance 70.50 GFlops (2.94 GFlop/processor)
    • Optimizing over Nb: graph. Nb=48 .
    • Optimizing over problem size: graph. N=53000 .
    • Optimizing over other parameters: HPL.dat. HPL.out .
  • cluster21-23. 24 processors, performance 68.66 GFlops (2.86 GFlop/processor)
    • Optimizing over Nb: graph. Nb=28 .
    • Optimizing over problem size: graph. N=55000 .
    • Optimizing over other parameters: HPL.dat. HPL.out .
  • cluster31, 32, 34-36. 48 processors, performance 128.8 GFlops (2.68 GFlop/processor)
    • Optimizing over Nb: graph. Nb=28 .
    • Optimizing over problem size: graph. N=76000 .
    • Optimizing over other parameters: HPL.dat. HPL.out .
  • Linpack

    А вот кто хочет кластер понастраивать?

    Граждане читатели!

    У дружественной мне компании-интегратора есть задача: они поставили заказчику железо в виде blade-сервера, в каждом блейде есть infiniband, на шасси - infiniband-свитч. Все вместе - маленький вычислительный кластер, я так понял что 12 блейдов, наверное 24 процессора, всего ядер получается пара-тройка сотен. Никаких GPU нету, чистый CPU-кластер.

    Нужно: провести какую-то настройку этого дела, взгромоздить туда MPI (не знаю какой), запустить HPL и продемонстрировать, что все работает и с какой-то разумной скоростью считает. Получать безумную эффективность не надо, работает, масштабируется как-то - и прекрасно.

    Естественно, не бесплатно.

    Если вы на практике имели дело с (начальной) настройкой чего-то подобного и имеете желание подработать день-другой (ну я не знаю сколько там надо на самом деле), пишите мне на lexa@lexa.ru и я вас дальше сконнекчу.

    По датам это, ориентировочно, нужно в середине следующей недели, вторник-четверг.

    P.S. Дефолт-сити.

    P.P.S. Обратились, собственно, ко мне, но я не настоящий сварщик и вот прямо в данное время не хочу/не могу учиться за счет заказчика, не до того.

    P.P.P.S. Спасибо за советы "какой готовый дистрибутив взять", но я пытаюсь решить другую задачу: не найти удочку, а нанять умелого рыбака.