Исправляли, исправляли, да не выисправляли.

В новой версии благодаря

В новой версии, благодаря

Хорошая новость. Теперь еще амдэшникам ACML надо бы подтянуть до актуальной версии.

C интерфейс это конечно хорошо, но уже как-то привычно дергать всё по-фортрановски через указатели.

А оно параллельное или как? На кластере можно запустить? Я в этом не спец, но просто прикинул, что если есть библиотека неких базовый операций, которые сами по себе параллельны, то со всякими MPI мудохаца не нужно. Или я не прав?

> Также LAPACK стал полностью потокобезопасным (thread safe)

Шёл 2010-й год...

Нет, математика там хорошая, спору нет, но как так можно...

LAPACK, как и BLAS — стандарт, поэтому ищите подходящие для ваших нужд реализации. В новости речь идет, как я понимаю, об эталонной реализации.

Для кластера есть scalapack, но там имеются не все алгоритмы из lapack'а.

> LAPACK широко используется различными крупными компаниями для математических вычислений. В частности в Intel MKL...

Т.е. математические библиотеки Intel, AMD, Sun, HP используют код LAPACK с netlib.org ? И зачем они тогда нужны? :) Думается, они все лишь предоставляет «классический» интерфейс LAPACK для тех кому это надо, а закодировано там всё на суровом асме.

Фактически и BLAS, и LAPACK стоит рассматривать как интерфейсы функций линейной алгебры, которые каждый реализует как умеет. Да, на netlib.org можно скачать некоторую типовую реализацию на фортране, но насколько я понимаю, на практике она нигде не используется в чистом виде.

LAPACK для компов с общей памятью. Для разделяемой памяти (кластеров) есть scaLAPACK. Но вообще для реальных задач лучше что-нибудь более высокоуровневое использовать, например, PETSc.

> на практике она нигде не используется в чистом виде.

Используется в форме ATLAS. Вообще, lapack, это «высокоуровневая» линейная алгебра. На «низком» уровне находится BLAS, который обычно и тюнят под железо.

Нет, под железо затачивают blas, а lapack если и тюнят, то совсем минимально. Он же высокоуровневый.

Да. Конечно, LAPACK максимально использует BLAS, в предположении что он заточен на локальное желелзо. Так что именно производительность BLAS является узким местом. Но, наверное, LAPACK тоже оптимизируют, а не используют как есть с netlib.

Ну а ATLAS, по-моему, это уже не эталонная реализация. Да её можно забрать с netlib.org, но там же есть и типовой BLAS на фортране.

ATLAS, кстати, по моим тестам на удивление неплохую производительность даёт. Наверное его используют где-то. Хотя всё-равно он проигрывает Goto-BLAS (Гото - это японец ;) ) и BLAS из Intel MKL.

> ATLAS ... проигрывает Goto-BLAS (Гото - это японец ;) ) и BLAS из Intel MKL.

Да, так и есть. У ATLAS только одно преимущество - он free.

MKL - закрытый nonfree

GotoBLAS - nonfree, хоть и opensource

Вот это я понимаю прикладные программные разработки. Гложет чувство зависти.

C интерфейс это конечно хорошо, но уже как-то привычно дергать всё по-фортрановски через указатели.

По фортрановски — это через указатели? о_О Семь лет писал математику на Фортране, указателями пользовался 2 раза, и то можно было, как теперь кажется, без этого обойтись. Фортран как раз хорош тем, что никакие указатели для вычислений не нужны.

Кстати, где тут Сильвия, утверждавшая, что LAPACK больше не нужен, поскольку его полностью заменили на clapack?

По фортрановски — это через указатели?

Когда фортрановские функции используешь из Си, то да :) А я его только из Си и использую :)

Не использовал goto blas, но на моих q8400s и q9550 производительность близкую к теоретической для данных камней показывает именно atlas. По скорости у меня получается так: atlas > acml > mkl >> generic blas

Фортран — хорош и годен. А теперь покажите мне библиотеку на Лиспе, которая жила бы так же долго и имела привязку хотя бы к Си.

>Вот это я понимаю прикладные программные разработки. Гложет чувство зависти.

Программирование, связанное с интенсивными вычислениями, обычно на порядок проще чем программирование бизнес-приложений.

Это Лешек Мацяшек.

> Фортран — хорош и годен. А теперь покажите мне библиотеку на Лиспе, которая жила бы так же долго и имела привязку хотя бы к Си.

CASы пойдут? Типа maxima или Axiom?

> Программирование, связанное с интенсивными вычислениями, обычно на порядок проще чем программирование бизнес-приложений.

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

Есть только одна проблема. Качество полученного кода вызывает кровавые слёзы. И программа хороша, и считает быстро, но как надо отладить или модифицировать...

> А теперь покажите мне библиотеку на Лиспе, которая жила бы так же долго и имела привязку хотя бы к Си.

Правило №1: В каждом треде, касающемся программирования, должен быть толстотролль, который упомянет лисп.

> Качество полученного кода вызывает кровавые слёзы. И программа хороша, и считает быстро, но как надо отладить или модифицировать...

Всё равно это будет быстрее, чем в случае красивого, но не _рабочего_ (в смысле не делающего то, что нужно) кода.

У программистов? Может быть. В текущей науке часто время - это более важный фактор. Время написания кода намного превышает время счета. Поэтому не грузись насчет качества, главное, чтоб физика не страдала. В тоже время всякие инженерные задачи вероятно требуют обратного.

> Но вообще для реальных задач лучше что-нибудь более высокоуровневое использовать, например, PETSc.

PETSc тоже использует LAPACK или ScaLAPACK.

> По скорости у меня получается так: atlas > acml > mkl >> generic blas

а на сколько велика разница?

На dgemm примерно так: 40gflops > 36 gflops > 28 gflops >> ~1 gflops

2011 год на носу, а вменяемой математической библиотеки нет до сих пор :(

И приходится все алгоритмы самому реализовать.

А чем сабж невменяем?

> 40gflops > 36 gflops > 28 gflops >> ~1 gflops

То есть получается что мкл в полуторку медленей атласа? По мне эта разница чуть более чем дофига. У меня получалось примерно одинаково, ну да есть разница, но на проценты. К тому же зависит от размера матриц довольно сильно. Смотрел год-полтора назад, может что изменилось с того времени. Остановился на мкл, ибо там много чего еще кошерного есть окромя бласа.

То есть получается что мкл в полуторку медленей атласа?

да

К тому же зависит от размера матриц довольно сильно

естественно зависит, я смотрел на матрицах размерности > 5000

Раз уж зашла про это речь

а кто что-нибудь скажет про Eigen? Я пользуюсь им в плюсах для матричной арифметики, и по сравнению с BLAS код получается примерно в 1000 раз более короткий и читаемый. А если судить по их бенчмарку, то еще и более быстрый.

> Eigen

хрень какаято. атлас опустили ниже некуда. откуда у них руки растут?

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

Сейчас мне нужна реализация аппроксимации изображений симплекс-сплайнами. И опять реализация отсутствует.

> CS-декомпозиции

CS-разложение!

В бенчмарке использовался только один поток, что не серьезно.

lapack отвечает только за линейную алгебру

> > Также LAPACK стал полностью потокобезопасным (thread safe)

Шёл 2010-й год...

Нет, математика там хорошая, спору нет, но как так можно...

Присоединяюсь. Я сам предпочитаю заботиться о потоковой безопасности. Недеюсь их потуги можно будет отключать.

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

Если открыть, скажем github, и посмотреть кто-что пишет, то можно понять, что разработка на серьезном уровне процентов на 50 состит из написания велосипедов или написания вообще не реализованных штук.

Те, кто кричат про стандартные решения везде и повсюду, ничего не писали серьезного. Так что все нормально.

> Время написания кода намного превышает время счета.

Это вы ребятам с World Community Grid раскажите, пусть посмеются

> 2011 год на носу, а вменяемой математической библиотеки нет до сих пор :(

GSL, GMP, LAPACK вот. Что еще надо?

fftw3 вот еще вспомнил

>По скорости у меня получается так: atlas > acml > mkl >> generic blas

У меня почему то всегда программы с исп. mkl быстрее чем что либо другое. Но это не тест dgemm, а вполне специфическое приложение на поиск eigenvalues с stebz и stein. Думаю некоторую разницу дали в вашем случае еще и разные компиляторы? Это все тестировалось на одном процессоре, и если да то на амд или интел?

На intel q8400s и q9550 результаты примерно одинаковые. На 8400 все пропорционально медленнее, но качественно картина не меняется.

Много чего еще надо, например работу с разреженными матрицами. Кстати gsl имеет некошерную лицензию, что исключает её серьезное использование.

> Кстати gsl имеет некошерную лицензию, что исключает её серьезное использование.

Это какую же, ребе?

GPL конечно же

> GPL конечно же

А, понятно. Проприетарщики.