[sisyphus] ATLAS vs BLAS performance

[sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

Я разобрался, как надо собирать ATLAS.
Вот предварительный benchmark.

Fortran BLAS:

> mm <- matrix(rnorm(10^6), ncol = 10^3)
> system.time(crossprod(mm))
[1] 1.572 0.004 1.580 0.000 0.000

ATLAS w/ SSE2:

> mm <- matrix(rnorm(10^6), ncol = 10^3)
> system.time(crossprod(mm))
[1] 0.344 0.020 0.369 0.000 0.000

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Ivan Adzhubey]

On Sunday 04 June 2006 17:05, Alexey Tourbin wrote:
> Я разобрался, как надо собирать ATLAS.
> Вот предварительный benchmark.
>
> Fortran BLAS:
> > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > system.time(crossprod(mm))
>
> [1] 1.572 0.004 1.580 0.000 0.000
>
> ATLAS w/ SSE2:
> > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > system.time(crossprod(mm))
>
> [1] 0.344 0.020 0.369 0.000 0.000

А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):

> mm <- matrix(rnorm(10^6), ncol = 10^3)
> system.time(crossprod(mm))
[1] 0.232 0.012 0.270 0.000 0.000


-- 
Иван

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On Sun, Jun 04, 2006 at 06:04:54PM -0400, Ivan Adzhubey wrote:
> On Sunday 04 June 2006 17:05, Alexey Tourbin wrote:
> > Я разобрался, как надо собирать ATLAS.
> > Вот предварительный benchmark.
> >
> > Fortran BLAS:
> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > system.time(crossprod(mm))
> >
> > [1] 1.572 0.004 1.580 0.000 0.000
> >
> > ATLAS w/ SSE2:
> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > system.time(crossprod(mm))
> >
> > [1] 0.344 0.020 0.369 0.000 0.000
> 
> А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):
> 
> > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > system.time(crossprod(mm))
> [1] 0.232 0.012 0.270 0.000 0.000

model name      : AMD Athlon(tm) 64 Processor 3200+
cpu MHz         : 2050.186
cache size      : 512 KB

R-2.3.1

Похоже, что процессор у Вас помощнее.  Суть в том, что разница будет
если и заментной, то не значительной.  Учитывая то, что ATLAS -- это
free software, а GotoBLAS -- проприетарный софт, то агитирую за ATLAS. :)

Осталось только в сизиф это собрать, что непросто, потому что ATLAS
пытается всеми силами собираться под процессор хост-системы.  Я уже
понял, что там нужно отровать.  Пока идея такая: в /usr/lib собрать
библиотеки с generic-оптимизацией на основе пресетов от PII; а в
/usr/lib/sse2 собрать библиотеки с оптимизацией на основе пресетов
от P4SSE2.  По идее, ldconfig и/или ld-linux.so.2 смогут разрулить такую
ситуацию как надо, примерно так же, как в случае с /lib и /lib/i686.
Ну да это уже мои проблемы.

В общем, если это будет работать из коробки как надо и если по сравнению
с GotoBLAS разница будет не хуже, чем в полтора раза, тогда я буду
доволелен.  Потому что основной разрыв по сравнению с фортраном всё
равно ликвидирован, а 10-20% на практике редко что решают.

Посмотрим...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On Mon, Jun 05, 2006 at 02:26:30AM +0400, Alexey Tourbin wrote:
> On Sun, Jun 04, 2006 at 06:04:54PM -0400, Ivan Adzhubey wrote:
> > On Sunday 04 June 2006 17:05, Alexey Tourbin wrote:
> > > Я разобрался, как надо собирать ATLAS.
> > > Вот предварительный benchmark.
> > >
> > > Fortran BLAS:
> > > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > > system.time(crossprod(mm))
> > >
> > > [1] 1.572 0.004 1.580 0.000 0.000
> > >
> > > ATLAS w/ SSE2:
> > > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > > system.time(crossprod(mm))
> > >
> > > [1] 0.344 0.020 0.369 0.000 0.000
> > 
> > А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):
> > 
> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > system.time(crossprod(mm))
> > [1] 0.232 0.012 0.270 0.000 0.000
> 
> model name      : AMD Athlon(tm) 64 Processor 3200+
> cpu MHz         : 2050.186
> cache size      : 512 KB

> В общем, если это будет работать из коробки как надо и если по сравнению
> с GotoBLAS разница будет не хуже, чем в полтора раза, тогда я буду
> доволелен.  Потому что основной разрыв по сравнению с фортраном всё
> равно ликвидирован, а 10-20% на практике редко что решают.

А вот ATLAS без оптимизации под P4SSE2:

> mm <- matrix(rnorm(10^6), ncol = 10^3)
> system.time(crossprod(mm))
[1] 0.584 0.012 0.624 0.000 0.000

Почти в два раза хуже, чем с SSE2 (но почти в три раза лучше, чем
фортран).  Значит стоит делать /usr/lib/sse2.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Mon, Jun 05, 2006 at 05:17:09AM +0400, Alexey Tourbin wrote:
> > > > ATLAS w/ SSE2:
> > > > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > > > system.time(crossprod(mm))
> > > >
> > > > [1] 0.344 0.020 0.369 0.000 0.000
^^^^^^^^^^^^^^^^^

> > > А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):
> > > 
> > > > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > > > system.time(crossprod(mm))
> > > [1] 0.232 0.012 0.270 0.000 0.000
> > 
> > model name      : AMD Athlon(tm) 64 Processor 3200+
> > cpu MHz         : 2050.186
> > cache size      : 512 KB
> 
> > В общем, если это будет работать из коробки как надо и если по сравнению
> > с GotoBLAS разница будет не хуже, чем в полтора раза, тогда я буду
> > доволелен.  Потому что основной разрыв по сравнению с фортраном всё
> > равно ликвидирован, а 10-20% на практике редко что решают.
> 
> А вот ATLAS без оптимизации под P4SSE2:
> 
> > mm <- matrix(rnorm(10^6), ncol = 10^3)
> > system.time(crossprod(mm))
> [1] 0.584 0.012 0.624 0.000 0.000

А вот собранный под Athlon64 (HAMMER32SSE2, т.е. ближе всего к тому
процессору, что у меня).

> mm <- matrix(rnorm(10^6), ncol = 10^3)
> system.time(crossprod(mm))
[1] 0.312 0.016 0.330 0.000 0.000

Т.е. немного лучше, чем для P4SSE2.  (Набор инструкций в данном случае
не отличается, отличаются только некоторые параметры управления L1/L2
кешем, или что там ещё).

SSE2 сейчас является общим знаменателем для P4 и современных атлонов.
Поскольку x86 ещё некоторое время будет существовать, то софт, для
которого специфическая оптимизация имеет смысл (и дает существенный
выигрыш, как в случае с числодробильными библиотеками), стоит
собирать праллельно и ставить в /usr/lib/sse2.  Правда, кроеме ATLAS
сходу на ум ничего не приходит.

А вообще надо переходить на x86_64, как я понимаю проблем с оптимизацией
"под архитектуру" там будет гораздо меньше (т.е. в первых Athlon64 не
было SSE3, а в P4 есс-но нет 3dNow, но остальное всё совпадает).

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Valery Pipin]

Эта радость под g77?
Alexey Tourbin wrote:
>
> Осталось только в сизиф это собрать, что непросто, потому что ATLAS
> пытается всеми силами собираться под процессор хост-системы.  Я уже
> понял, что там нужно отровать.  Пока идея такая: в /usr/lib собрать
в дебиане атлас уже давно и под разные архитектуры. Можно
посмотреть как у них сделано.

Re: [sisyphus] ATLAS vs BLAS performance

[Andrey Khavryuchenko]

Alexey,

"AT" == Alexey Tourbin wrote:

 AT> On Sun, Jun 04, 2006 at 06:04:54PM -0400, Ivan Adzhubey wrote:
 >> On Sunday 04 June 2006 17:05, Alexey Tourbin wrote:
 >> > Я разобрался, как надо собирать ATLAS.
 >> > Вот предварительный benchmark.
 >> >
 >> > Fortran BLAS:
 >> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
 >> > > system.time(crossprod(mm))
 >> >
 >> > [1] 1.572 0.004 1.580 0.000 0.000
 >> >
 >> > ATLAS w/ SSE2:
 >> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
 >> > > system.time(crossprod(mm))
 >> >
 >> > [1] 0.344 0.020 0.369 0.000 0.000

Когда можно ждать пакеты?

 >> А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):
 >> 
 >> > mm <- matrix(rnorm(10^6), ncol = 10^3)
 >> > system.time(crossprod(mm))
 >> [1] 0.232 0.012 0.270 0.000 0.000

 AT> Похоже, что процессор у Вас помощнее.  Суть в том, что разница будет
 AT> если и заментной, то не значительной.  Учитывая то, что ATLAS -- это
 AT> free software, а GotoBLAS -- проприетарный софт, то агитирую за ATLAS. :)

Я бы хотел/просил для GotoBLAS тоже сделать nosrc.rpm.  И для ATLAS
наверное тоже.

[...]

 AT> В общем, если это будет работать из коробки как надо и если по сравнению
 AT> с GotoBLAS разница будет не хуже, чем в полтора раза, тогда я буду
 AT> доволелен.  Потому что основной разрыв по сравнению с фортраном всё
 AT> равно ликвидирован, а 10-20% на практике редко что решают.

Если бы... :(  Когда расчёты идут месяцами, то 10-20% - весьма существенное
время. 

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

-- 
Andrey V Khavryuchenko            
Software Development Company http://www.kds.com.ua/

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

On Mon, Jun 05, 2006 at 01:22:37PM +0900, Valery Pipin wrote:
> Эта радость под g77?
> Alexey Tourbin wrote:
> >
> > Осталось только в сизиф это собрать, что непросто, потому что ATLAS
> > пытается всеми силами собираться под процессор хост-системы.  Я уже
> > понял, что там нужно отровать.  Пока идея такая: в /usr/lib собрать
> в дебиане атлас уже давно и под разные архитектуры. Можно
> посмотреть как у них сделано.

Смотрел очень внимательно как сделано в дебиане и в федоре.
Могу рассказать, как сделано в дебиане, насклько я сам понял.

Одна из проблем вот в чем: можно *в принципе* собрать библиотеку с любой
оптимизацией, но её, быть может, нельзя будет протестировать в сборочной
среде.  То есть можно собрать на P166MMX библиотеку с SSE2, но ясно, что
любая проверка будет сулить обломом.  Однако же стандартная процедура
сборки atlas собирает не только саму библиотеку, но и всякие бинари --
мини тесты -- и тут же их запускает.

В дебиане сделали вот как: сначала собрали библиотеку на P166MMX и
сохранили лог сборки.  А потом написали скрипт -- парсер лога сборки,
который извлекает из лога сборки команды компиляции и скармливает их
шеллу.  Т.е. в упрощенном виде:

	./debian/ab лог_сборки_P166MMX |bash -ex

За счет этого удается собирать библиотеку с произвольными (всеми
возможными) оптимизациями.

В федоре extras собрано точно так же, там просто скопировали и
переработали debian/rules.

Что я об этом думаю: я так извращаться не собираюсь.  Я буду исходить их
того, что в сборочной среде можно выполнять SSE2 инструкции.  В этом
случае я понял, как сделать всё более-менее нормально.  Думаю, что
большая половина машин в нашей сборочной инфраструктуре умеет SSE2.
(На самом деле все P4 и все атлоны64/семпроны умеют SSE2).

Почему SSE2 -- может напишу в соседнем письме.  Суть в том, что под
каждый отдельный проц пакеты плодить не надо.  Предварительный benchmark
показывает, что от использования SSE2 по сравнению с неиспользованием
SSE2 выигрыш почти в два раза, а от подсройки под конкретный проц (уже в
пределах SSE2) -- порядка 10%.  К тому же с SSE2 есть готовое решение по
части ldconfig/ld-linux.so.2.  Достаточно пложить оптимизированную
библиотеку в /usr/lib/sse2.  А в дебиане что-то кладут в /etc/ld.so.conf.d.

Кстати в дебиане /usr/lib/libblas$suffix весит на альтернативах.  Ужос!

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Ivan Adzhubey]

On Monday 05 June 2006 03:30, Alexey Tourbin wrote:
> On Mon, Jun 05, 2006 at 01:22:37PM +0900, Valery Pipin wrote:
> > Эта радость под g77?
> >
> > Alexey Tourbin wrote:
> > > Осталось только в сизиф это собрать, что непросто, потому что ATLAS
> > > пытается всеми силами собираться под процессор хост-системы.  Я уже
> > > понял, что там нужно отровать.  Пока идея такая: в /usr/lib собрать
> >
> > в дебиане атлас уже давно и под разные архитектуры. Можно
> > посмотреть как у них сделано.
>
> Смотрел очень внимательно как сделано в дебиане и в федоре.
> Могу рассказать, как сделано в дебиане, насклько я сам понял.
>
> Одна из проблем вот в чем: можно *в принципе* собрать библиотеку с любой
> оптимизацией, но её, быть может, нельзя будет протестировать в сборочной
> среде.  То есть можно собрать на P166MMX библиотеку с SSE2, но ясно, что
> любая проверка будет сулить обломом.  Однако же стандартная процедура
> сборки atlas собирает не только саму библиотеку, но и всякие бинари --
> мини тесты -- и тут же их запускает.
>
> В дебиане сделали вот как: сначала собрали библиотеку на P166MMX и
> сохранили лог сборки.  А потом написали скрипт -- парсер лога сборки,
> который извлекает из лога сборки команды компиляции и скармливает их
> шеллу.  Т.е. в упрощенном виде:
>
> 	./debian/ab лог_сборки_P166MMX |bash -ex
>
> За счет этого удается собирать библиотеку с произвольными (всеми
> возможными) оптимизациями.
>
> В федоре extras собрано точно так же, там просто скопировали и
> переработали debian/rules.
>
> Что я об этом думаю: я так извращаться не собираюсь.  Я буду исходить их
> того, что в сборочной среде можно выполнять SSE2 инструкции.  В этом
> случае я понял, как сделать всё более-менее нормально.  Думаю, что
> большая половина машин в нашей сборочной инфраструктуре умеет SSE2.
> (На самом деле все P4 и все атлоны64/семпроны умеют SSE2).
>
> Почему SSE2 -- может напишу в соседнем письме.  Суть в том, что под
> каждый отдельный проц пакеты плодить не надо.  Предварительный benchmark
> показывает, что от использования SSE2 по сравнению с неиспользованием
> SSE2 выигрыш почти в два раза, а от подсройки под конкретный проц (уже в
> пределах SSE2) -- порядка 10%.  К тому же с SSE2 есть готовое решение по
> части ldconfig/ld-linux.so.2.  Достаточно пложить оптимизированную
> библиотеку в /usr/lib/sse2.  А в дебиане что-то кладут в /etc/ld.so.conf.d.

Боюсь, это не остановит хардкорных "считателей" от упорной самостоятельной 
оптимизации. Меня - не остановит ;-) Но если получится хотя бы под SSE2 
оптимизировать из коробки - это уже отлично.

> Кстати в дебиане /usr/lib/libblas$suffix весит на альтернативах.  Ужос!

В Федоре еще хуже, по крайней мере насколько я вижу.

-- 
Иван

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Mon, Jun 05, 2006 at 09:19:46AM +0300, Andrey Khavryuchenko wrote:
>  >> > [1] 0.344 0.020 0.369 0.000 0.000
> Когда можно ждать пакеты?

Ждем ебилдов... :)  С бласом всё нормально, осталось понять, что делать
с лапаком, потому что он там реализован только частично (в частности,
R-base'у атласного лапака не хватает).

Завтра ждать можно.

> Я бы хотел/просил для GotoBLAS тоже сделать nosrc.rpm.  И для ATLAS
> наверное тоже.

Одна из проблем в чём: я ведь собираю разделяемые библиотеки, а лапак
зависит от бласа.  Следовательно, на стадии сборки лапака нужно решать,
с каким бласом его линковать, либо вешать libblas$suffix на
альтернативы, либо предусматривать в спеке возможность пересборки лапака
с разными бласами.

Статику я вообще собирать не хочу, потому что теперь мне стало ясно, что
у разделяемых библиотек есть ещё одно преимущество: можно положить две
библиотеки с разной оптимизацией в /usr/lib/lib$name$suffix и
/usr/lib/sse2/lib$name$suffx, а ldconfig/ld-linux.so.2 выберет наилучший
вариант на основе hwcap.  Со статикой так не бываеет.

> Если бы... :(  Когда расчёты идут месяцами, то 10-20% - весьма существенное
> время. 

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

Я и хочу сделать максимум возможного их коробки, но не поступаясь
принципами (типа вешать libblas на альтернативы или использовать
проприетарный софт).  Кстати atlas включает в себя gemm/ который потом
стал проприетарным GotoBLAS.  Так что должно получиться неплохо.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Ivan Adzhubey]

On Monday 05 June 2006 02:19, Andrey Khavryuchenko wrote:
> Alexey,
>
> "AT" == Alexey Tourbin wrote:
>
>  AT> On Sun, Jun 04, 2006 at 06:04:54PM -0400, Ivan Adzhubey wrote:
>  >> On Sunday 04 June 2006 17:05, Alexey Tourbin wrote:
>  >> > Я разобрался, как надо собирать ATLAS.
>  >> > Вот предварительный benchmark.
>  >> >
>  >> > Fortran BLAS:
>  >> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
>  >> > > system.time(crossprod(mm))
>  >> >
>  >> > [1] 1.572 0.004 1.580 0.000 0.000
>  >> >
>  >> > ATLAS w/ SSE2:
>  >> > > mm <- matrix(rnorm(10^6), ncol = 10^3)
>  >> > > system.time(crossprod(mm))
>  >> >
>  >> > [1] 0.344 0.020 0.369 0.000 0.000
>
> Когда можно ждать пакеты?
>
>  >> А вот с GotoBLAS 1.2 (P4 2.8GHz, R 2.3.0):
>  >> > mm <- matrix(rnorm(10^6), ncol = 10^3)
>  >> > system.time(crossprod(mm))
>  >>
>  >> [1] 0.232 0.012 0.270 0.000 0.000
>
>  AT> Похоже, что процессор у Вас помощнее.  Суть в том, что разница будет
>  AT> если и заментной, то не значительной.  Учитывая то, что ATLAS -- это
>  AT> free software, а GotoBLAS -- проприетарный софт, то агитирую за ATLAS.
> :)
>
> Я бы хотел/просил для GotoBLAS тоже сделать nosrc.rpm.  И для ATLAS
> наверное тоже.

С GotoBLAS наверное будут проблемы с лицензией. Хотя она и стала open source 
недавно, а сам Гото наверняка был бы только рад отдать проект под GPL, но его 
университет скорее всего этого не допустит. Могу впрочем у него спросить, что 
он по этому поводу думает. UT Austin - это частный университет, а в частных 
лавочках тут с technology transfer очень строго. Мы пока как-то обходим, но я 
сталкивался с ребятами из этого отдела (у нас тоже частная лавочка, как и 
большинство американских исследовательских институтов), так в советские 
времена с "первым" отделом и то проще было договориться.

-- 
Иван


-- 
Иван

Re: [sisyphus] ATLAS vs BLAS performance

[Ivan Adzhubey]

On Monday 05 June 2006 03:53, Ivan Adzhubey wrote:
> > Я бы хотел/просил для GotoBLAS тоже сделать nosrc.rpm.  И для ATLAS
> > наверное тоже.
>
> С GotoBLAS наверное будут проблемы с лицензией. Хотя она и стала open
> source недавно, а сам Гото наверняка был бы только рад отдать проект под
> GPL, но его университет скорее всего этого не допустит. Могу впрочем у него
> спросить, что он по этому поводу думает. UT Austin - это частный
> университет, а в частных лавочках тут с technology transfer очень строго.
> Мы пока как-то обходим, но я сталкивался с ребятами из этого отдела (у нас
> тоже частная лавочка, как и большинство американских исследовательских
> институтов), так в советские времена с "первым" отделом и то проще было
> договориться.

Ошибся, оказывается UT Austin - это public university. Тогда еще не все 
потеряно...

-- 
Иван

Re: [sisyphus] ATLAS vs BLAS performance

[Andrey Khavryuchenko]

Alexey,

"AT" == Alexey Tourbin wrote:

 AT> On Mon, Jun 05, 2006 at 09:19:46AM +0300, Andrey Khavryuchenko wrote:
 >> >> > [1] 0.344 0.020 0.369 0.000 0.000
 >> Когда можно ждать пакеты?

 AT> Ждем ебилдов... :)  С бласом всё нормально, осталось понять, что делать
 AT> с лапаком, потому что он там реализован только частично (в частности,
 AT> R-base'у атласного лапака не хватает).

 AT> Завтра ждать можно.

Спасибо.

[...]

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

 AT> Я и хочу сделать максимум возможного их коробки, но не поступаясь
 AT> принципами (типа вешать libblas на альтернативы или использовать
 AT> проприетарный софт).  Кстати atlas включает в себя gemm/ который потом
 AT> стал проприетарным GotoBLAS.  Так что должно получиться неплохо.

Оччень хорошо :)

-- 
Andrey V Khavryuchenko            
Software Development Company http://www.kds.com.ua/

Re: [sisyphus] ATLAS vs BLAS performance

[Andrey Khavryuchenko]

Ivan,

"IA" == Ivan Adzhubey wrote:

 IA> On Monday 05 June 2006 02:19, Andrey Khavryuchenko wrote:
 >> Я бы хотел/просил для GotoBLAS тоже сделать nosrc.rpm.  И для ATLAS
 >> наверное тоже.

 IA> С GotoBLAS наверное будут проблемы с лицензией.

Вот поэтому и nosrc.rpm - только с инструкциями для сборки и инсталляции.

-- 
Andrey V Khavryuchenko            
Software Development Company http://www.kds.com.ua/

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Mon, Jun 05, 2006 at 11:50:22AM +0400, Alexey Tourbin wrote:
> On Mon, Jun 05, 2006 at 09:19:46AM +0300, Andrey Khavryuchenko wrote:
> >  >> > [1] 0.344 0.020 0.369 0.000 0.000
> > Когда можно ждать пакеты?
> 
> Ждем ебилдов... :)  С бласом всё нормально, осталось понять, что делать
> с лапаком, потому что он там реализован только частично (в частности,
> R-base'у атласного лапака не хватает).
> 
> Завтра ждать можно.

Эх!  Дело осложняется SEGV.

at@localhost ~build/LAPACK/TESTING 15 $ LD_LIBRARY_PATH=.. ./xeigtstd < dec.in
 Tests of the Nonsymmetric eigenproblem condition estimation routines
 DLALN2, DLASY2, DLANV2, DLAEXC, DTRSYL, DTREXC, DTRSNA, DTRSEN, DLAQTR

 Relative machine precision (EPS) =     0.444089D-15
 Safe minimum (SFMIN)             =     0.222507-307

 Routines pass computational tests if test ratio is less than   20.00


 DEC routines passed the tests of the error exits ( 35 tests done)
zsh: segmentation fault  LD_LIBRARY_PATH=.. ./xeigtstd < dec.in
at@localhost ~build/LAPACK/TESTING 15 $ 

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]

On Mon, Jun 05, 2006 at 02:11:45PM +0400, Alexey Tourbin wrote:
> On Mon, Jun 05, 2006 at 11:50:22AM +0400, Alexey Tourbin wrote:
> > On Mon, Jun 05, 2006 at 09:19:46AM +0300, Andrey Khavryuchenko wrote:
> > >  >> > [1] 0.344 0.020 0.369 0.000 0.000
> > > Когда можно ждать пакеты?
> > 
> > Ждем ебилдов... :)  С бласом всё нормально, осталось понять, что делать
> > с лапаком, потому что он там реализован только частично (в частности,
> > R-base'у атласного лапака не хватает).
> > 
> > Завтра ждать можно.
> 
> Эх!  Дело осложняется SEGV.
> 
> at@localhost ~build/LAPACK/TESTING 15 $ LD_LIBRARY_PATH=.. ./xeigtstd < dec.in
>  Tests of the Nonsymmetric eigenproblem condition estimation routines
>  DLALN2, DLASY2, DLANV2, DLAEXC, DTRSYL, DTREXC, DTRSNA, DTRSEN, DLAQTR
> 
>  Relative machine precision (EPS) =     0.444089D-15
>  Safe minimum (SFMIN)             =     0.222507-307
> 
>  Routines pass computational tests if test ratio is less than   20.00
> 
> 
>  DEC routines passed the tests of the error exits ( 35 tests done)
> zsh: segmentation fault  LD_LIBRARY_PATH=.. ./xeigtstd < dec.in
> at@localhost ~build/LAPACK/TESTING 15 $ 

В результате изнуряющих опытов обнаружено следующее: все сборки с sse2
сегфолтятся.  В частности, а) сегофолтится сам atlas, если попросить его
сделать 'make sanity_test'; б) сегфолтится один из тестов при сборке
лапака.

В сборке без sse2 сегфолтов нет.

В сборке для x86_64 один из тестов лапака входит в бесконечный цикл.
Также при сборке лапака для x86_64 не удается выполнить большее
количество тестов.

В результате в сизиф уходит сборка без sse2 для i586 и частично
сломанная сборка для x86_64.  Однако 'make check' от R-base в последнем
случае выполняется нормально (как и в первом).

Если у кого-то окажется достаточно квалификации и времени для того, чтобы
расковырять сегфолт в sse2-сборке -- прошу:

	rpm --rebuild --with sse2 atlas-3.7.11-alt1.src.rpm

Кстати в других дистрибутивах я вообще не видел, чтобы кто-то что-то
вроде 'make test' пробовал сделать -- почему-то только мне в голову такие
крамольные мысли приходят.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [sisyphus] ATLAS vs BLAS performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Tue, Jun 06, 2006 at 03:14:45PM +0400, Alexey Tourbin wrote:
> В результате изнуряющих опытов обнаружено следующее: все сборки с sse2
> сегфолтятся.  В частности, а) сегофолтится сам atlas, если попросить его
> сделать 'make sanity_test'; б) сегфолтится один из тестов при сборке
> лапака.
> 
> В сборке без sse2 сегфолтов нет.
> 
> В сборке для x86_64 один из тестов лапака входит в бесконечный цикл.
> Также при сборке лапака для x86_64 не удается выполнить большее
> количество тестов.
> 
> В результате в сизиф уходит сборка без sse2 для i586 и частично
> сломанная сборка для x86_64.  Однако 'make check' от R-base в последнем
> случае выполняется нормально (как и в первом).
> 
> Если у кого-то окажется достаточно квалификации и времени для того, чтобы
> расковырять сегфолт в sse2-сборке -- прошу:
> 
> 	rpm --rebuild --with sse2 atlas-3.7.11-alt1.src.rpm
> 
> Кстати в других дистрибутивах я вообще не видел, чтобы кто-то что-то
> вроде 'make test' пробовал сделать -- почему-то только мне в голову такие
> крамольные мысли приходят.

Проблема локализована; скоро будет мега-оптимизированный ATLAS,
по скорости сравнимый c GotoBLAS (в /usr/lib/sse2/ будет лежать
мега-оптимизированный libatlas.so).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]