g77 + lapack 3.1.1 = thread-safe ?

В общем, посмотрел я .s файлы которые генерирует g77 : как только используются локальные массивы - сразу в начале модуля появляется что-то вроде:

.file "cgbtrf.f"
.lcomm _work13.0,33280
.lcomm _work31.1,33280
....

Это значит, что одну и ту же память будут использовать несколько потоков одновременно - видимо, g77 отметается.

Есть у кого идеи? Спасибо за помощь! :)

Кстати поставил 3.1.1, до этого использовал 3.0. Непонятная странность проявилась в msvs 2005. Компилю mingw g77 с параметром -03, в результате arpack (метод Арнольди, использует функции из lapack) под студией корректно не работает (метод сразу завершается и говорит что собственные вектора не найдены). Если компилить без оптимизации то все ок, но работает медленно.

По поводу многопоточности ничего сказать не могу.

Собираешь ведь mingw .dll -ку, которую потом используешь из "метода Арнольда" под msvs 2005. Да ведь тогда всеравно откуда вызывать. В 3.1.1 появились устаревшие функции - может в них дело. В любом случае - смотреть changelog на предмет изменений в используемых методом функций.

Проблема решилась переходом на gfortran и использованием опции -fmax-stack-var-size=<N>.

Только, это требует gcc-4 использовать.

1. Собираю статическую либу (liblapack.a). Что интересно если ту же самую либу линковать в cygwin'е (соотвественно с cygwin версией основного приложения), то такого косяка не наблюдается.

2. метод называется АрнольдИ (именно с "И" на конце)

3. пока забил и откатился назад на 3.0

> 1. Собираю статическую либу (liblapack.a). Что интересно если ту же самую либу линковать в cygwin'е (соотвественно с cygwin версией основного приложения), то такого косяка не наблюдается.

Я не понимаю просто как ты получившуюся либу, скомпилированную MinGW(?) потом подключаешь в msvs 2005. Они же не совместимы, а даже если вдруг совместимы, то разные рантайм библиотеки используют.

Это я про """ ... Компилю mingw g77 с параметром -03, в результате arpack (метод Арнольди, использует функции из lapack) под _студией_ корректно не работает ... """

Просто я не нашел другого пути, как компилировать lapack под CygWin, делать dll-ку и ее уже подключать в проекте под MSVS6.0 . Ну а под линуксом и статическая и динамическая легко собирается.

> 2. метод называется АрнольдИ (именно с "И" на конце)

Сорри. Буду знать :)

> 3. пока забил и откатился назад на 3.0

Ну и ладно - любая информация интересна. Спасибо!

Кстати, а BLAS уровень кто у тебя реализует? ATLAS или та что для изучения (не оптимизированный вариант)?

> Они же не совместимы

Как ни странно они совместимы :)

> а даже если вдруг совместимы, то разные рантайм библиотеки используют.

угу, mingw...чего-то-там.a я тоже подлинковываю к приложению, но как ни странно раньше работало.

>Кстати, а BLAS уровень кто у тебя реализует?

Blas тот, что идет с lapack'ом. А большая разница в скорости с atlas?

Мда, до вчерашнего длня я был в этом уверен... проверил. Сейчас меня интересует только CLAPACK - его я могу доточить для поддержки многопоточности в нужном мне проекте.

На моей машине получилось, что голый CLAPACK где-то раза в полтора тормознее голого LAPACK, а с ATLAS начинает его догонять и иногда даже перегонять, но не очень сильно. BLAS уровень - Simple BLAS (TIMING/stime.in) результаты у ATLAS и LAPACK примерно одинаковые. Радует только, что CLAPACK начинает и "большИе" тесты переваривать с ATLAS-ом, да и с многопоточностю на уровне BLAS-а тогда проблем нет.

PS: Для BLAS-а из ATLAS я вместо blas$(PLAT).a подключал libcblaswr.a +libcblas.a + libatlas.a. Т.е. ATLAS реализует cblas, а он уже потом LAPACK-ом используется через cblaswr.a - видимо, это одна из причинн, почему ATLAS на маленьких матрицах отстает.

PPS: сильно о настройках ATLAS-а не запаривался, может и можно что-нибудь изменить.

мда.. набор скороговорок какихто )))