Intel Math Kernel Library известна не один год, ныне уже вышла ее 11-ая версия:
http://software.intel.com/en-us/intel-mkl/

Пользовался ли кто-то ею? Каково впечатление?

Еще вопрос про лицензию:
http://www.softkey.ru/catalog/program.php?...AodMWIARg#items
http://store.softline.ru/license/academic-licensing/intel/
http://software.intel.com/sites/default/fi...ucts_EULA_1.pdf
Тут мне не все понятно. Вот если лицензия продается к программе, пакету программ или компилятору, то тут всё ясно: купил - пользуйся.
А как быть, если это библиотека (как в данном случае), которая по своему назначению не программа, а часть, встраиваемая в самописные программы? Унаследует ли самодельная программа, использующая внутри себя "Intel Math Kernel Library", необходимость в лицензии? Т.е. надо ли покупать лицензию на каждый компьютер, на котором должна будет работать твоя программа, если последняя использует "Intel Math Kernel Library"?

Это я в том смысле спрашиваю, что интересуюсь, встроена ли в эту библиотеку какая-нибудь защита или проверяльщик лицензии? Или, однажды добыв эту библиотеку, "нехорошие люди" могут делать с ее помощью вычисления на любых компьютерах, ничего на них дополнительно не инсталлируя?

================================

Извлечения из FAQ:

Do I need to get a license for each machine being used to develop and test applications using Intel MKL library?
The number of licenses for Intel MKL that you need are determined by the number of developers in your organization. These can be deployed on any number of machines on which the application is built and/or tested as long as there is only the number of licensed copies in use at any given time. For example a development team of five developers using ten machines simultaneously for development and test activities with Intel MKL, will be required to get ten licenses of Intel MKL.

Do I need to buy an Intel MKL license for each copy of our software that we sell?
No, there is no royalty fee for redistributing Intel MKL files with your software. By licensing Intel MKL for your developers, you have rights to distribute the Intel MKL files with your software for an unlimited number of copies.

Из первого ответа вроде бы следует, что лицензии покупать на каждый компьютер надо, а из второго, что не надо . Совсем запуталась. А главное - вопрос гложет, как они это проверяют? Встроена ли в "Intel Math Kernel Library" защита от копирования (привязка к компу) или все держится на честном слове?

Пользовался и пользуюсь предшественницей IMKL - ISPL ( Intel Signal Processing Library 4.5 ) с тех еще пор, когда она была free-доступна.

А вот я что-то сомневаюсь, что это тот же продукт. У нас на фтп лежит "Intel - DSP Signal Processing Library 4.5", но SPL на MKL не похож: в MKL - линейная/матричная алгебра, а в SPL - DSP примитивы.

по поводу лицензии не скажу, но ПО должно работать без проблем и на других машинах

Конечно - не тот же. Это часть Math - DSP-библиотека.

Если о FFT на PC - fftw.org, это вроде всем известно.

Нет, FFT это прошлый век, неинтересно.

Тем кто хочет шагать в ногу со временем... И не благодарите...

Тьху на Вас



Улыбнулся.. Ищите, может и воздастся.

P.S.
Я вот, тоже увлекся SSA, хотя.. еще та муть-то, в итоге.

для любителей Питона и ... прочих - Sage

Каким бы ни был "полным" языковой пакет, но рано или поздно столкнешься с тем, что чего-то не хватает. Порочна сама вера в то, что создатели компилятора якобы предусмотрели всё, снабдив язык библиотеками на все случаи жизни. Такого не бывает. А раз так, то должны средства обмена продуктами, как между разными производителями, пишущими на одном языке программирования, так и между теми, кто пишет на разных. А для этого сами языки должны быть ОТКРЫТЫМИ для ассимиляции внешних библиотек.

Слава Богу, что под Windows существует такая универсальная (в смысле стандартизованная) вещь, как DLL. Создавая DLL-библиотеки, их производители фактически делают их совместимыми почти со всеми языками программирования. Для полного счастья необходимы только две вещи: 1) чтобы язык позволял компилировать DLL-ки (экспорт), 2) чтобы язык позволял использовать чужие DLL-ки (импорт). И в этом смысле Python плох, т.к. позволяет делать эти вещи с таким большим напрягом, что использовать внешние DLL становится сложно. А в результате Python становится похож на ... Северную Корею со своей политикой Чучхе.

Ага, особенно, когда берем приложение, далекое от вышеприведенных либ, например FreeCAD. И запросто прикручиваем туда вычислитель какого-нибудь хитрого констрейна, на основе сторонней
математики, причем разработчики FreeCAD даже не догадываются, что их полурабочее детище летает словно НЛО, приветливо, блин, подмигивая питоновым же интерфейсом... И ни одного Ким-Чен-Ира!

Леди и джентельмены - помните о тех безымянных творцах МКL из Арзамаса-16, на их костях...(обагрённых дерьмовой российской жратвой), как ещё в пластинке Давида Тухманова "По волне моей памяти"...

Это еще большой вопрос, прикрутится или нет. Ведь дело не в том, чтобы "запустить модуль", а чтобы работать на одном языке, активно используя функции, написанные на другом.

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

Например, EISPACK и LINPACK были чуть ли не национальными американскими проектами, и кучу денег на них угрохали. И всё это Фортан. А было это еще в 70-80 годах. А деньги угрохали не столько на программирование, сколько на тестирование всех этих подпрограмм и функций. Такие пакеты не то что переводить на другие языки, но и по малому ковырять страшно. Поэтому никто и не станет все это переводить, ни на Паскаль, ни на Питон. А если такой герой и найдется, то к его переводу все равно не будет ни у кого доверия.

Опять же - если новый язык изобретут, то заново что-ли всё переводить? Вот для БЭСМ-6 куча разных программ была, а где она ныне? Что на Фортране было, то кое-где пристроили, а что было в ассемблере, то сгинуло навсегда.

Вот и сейчас Фортран жив в основном благодаря тем заделам, которые были сделаны на нём в прошлом, но по-прежнему актуальны для пользователя, поскольку представляют собой базис вычислительной математики! А про новомодные языки этого сказать нельзя. И это несмотря на то, что машинный перевод с языка на язык в области языков программирования довольно успешен, вследствие их глубокой заформализованности.

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

Поэтому более чем актуально, использовать заделы прошлого в том виде, в котором они есть, или близко к тому. Если Фортран, то пусть будет Фортран. Скомпилять в стандартные для данной системы модули или оформить, как библиотеку. Это и есть попытка решить проблему утилизации "знаний предков" наиболее простым способом.

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

На этом грустном фоне особняком стоят библиотеки, которые изначально позиционируются как внешние. Т.е. их создатели уже позаботились о том, чтобы библиотечные функции получились наиболее автономными от той среды, в которой они были скопилированы. Этим мне и приглянулась Intel Math Kernel Library. Тем более что Intel еще со времен создания первого Пентиума (а может быть и того раньше?) посягал на первенство в скорости математических вычислений. Т.е. позиционировались они в прошлом (и позиционируются сейчас), как математика, адаптированная к процессорныи инструкциям Intel-архитектур (x86/64 и ia32). Одна беда - исходников они не дают.

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

Про Арзамас-16 не знала. В Новосибирске вроде в последнее время трудились на Интел

Xenia, в Sage присутствуют все доступные open-source библиотеки, можно ещё пройтись по их домашним страницам и для некоторых можно найти и реализации на Фортране.

Только по технологии "клиент-сервер". А разве есть альтернатива?



Вот у меня вечная неприязнь к питону, из-за того, что там case sensitivity. Аццкий труд! Всё время мелькает мысль, что паскаль гораздо удобнее смотрелся бы. "Hello, nurse!" и всё такое... тем более, что робкие попытки сделать паскалевский интерпретатор имеют успех. Печально, в общем. Вот интересно, я один такой? Когда читаешь чужие идентификаторы, слова и смысл воспринимаются с одного раза, но, блин, не регистр же! Это ж издевательство, ЧеГоНибудЬОбозвать, и постоянная необходимость заглянуть в мануал!


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


А вот интересно, система "ПОЛЕ" жива еще хоть где-то? Кто знает?


Ну, бывают озарения, скажем, "D" без труда "хавает" с/с++, или erlang с С-nodes. Но запросто вживить фортран -


Без набора контрольных примеров - невозможно вообще.


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

PS еще вспомнился эмулятор СР/М под ДОС, ISIS, кажется, и мы в нем ассемблер для 8080 запускали... ностальжи сплошняком.
PPS Да, прошу прощения за злостный оффтоп.

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

Например, SciLab, - также "заражен" питоном. Оказалось, что реализовать скриптовой движок почище васика или лиспа невероятно просто...

А мы щас объявим Питону ... холивар!

На самом деле MKL - это не только Саров, а еще Нижний и Новосибирск.
В Нижнем занимаются векторными и статистическими операциями, в Новосибирске - разреженными матрицами, а вот в Сарове - плотными матрицами и финальной сборкой MKL.

Не утрируйте, Xenia. Пайтон - сплошное ООП - там нет коротких выражений. Я пайтоню восновном на домашнем серваке(не для web'а) - здесь экран 1280X1024 и уже не очень то и удобно. Пайтон хорош другим - если кто программировал на другом языке (пусть java) то программировать на питоне у него получается за пару дней.
Можно на нем исключительно все кроме... микроконтроллеров и харда. Но согласитесь 70%(а у нас всем 95%) программистов это и нафиг не надо.

Идеологически - это эдакий гибрид "васика" и bash(кстати, есть движения по замене старых скриптовых интерпритаторов в unix'ах на python). То что это интерпретатор(а при очень большом желании его можно и скомпилировать правда будет "увесистый" бинарь) + легкомысленное отношение к типу переменных дает свободу творчества, немного наплевательское отношение к синтаксису позволяет сосредоточиться на задачах непосредственно алгоритмических. Словами иными вот человек допустим физик-профессионал. И ему нужен какй-то определенный софтовый проект(а грант уже проел, на услуги профи не хватает) - большой вопрос посвятить ли годы изучению C++ или поковырять python. Или инженер-механик(кстати а в автокад, кажется, вообще lisp встроен?)... Или биолог... Или школьнЕГ...

По-поводу оптимальности... так Ё... Скажите это хостерам с их вечным php. И ничего, web и не думает умирать. Кстати оптимальность задача многомерная. Вот вы задумали стартап - а там нужно и с картинками работать и с web и т.д. а денег на команду нет и инвесторам показать нечего... Неужели нужно посвятить годы медитаций в горном монастыре на понимание внутренней работы jpeg, фильтров фарроу и остальной этой бредятины а потом "вернуться в мир" и осознать - а поезд то давно ушел... да и вообще...

По-поводу того-же numpy или PyWavelets так по сути своей это же "C" библиотеки, просто оформленные для возможности работы в "пайтоне".

По-поводу ума... Ах Ксения, Ксения... Умные вообще не работают. Не бомжуют, а именно не работают т.к. им западло... На них работают другие. Вы должны знать - у Вас там много почитателей. Так что пользуетесь ли Вы модулями пайтона или чьими-то готовыми либами на asm это уже не айс.

хорошая библиотека, но, если Вам только функциональность лапака нужна, и, особенно если у Вас АМДшный процессор - проще использовать бесплатный ACML. Он последнее время идет с частичной поддержкой ГПУшных ускорителей, что, тоже может сильно помочь.

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

Еще есть АТЛАС - Automatically Tuned Linear Algebra Software, которая, было время, делала MKL по скорости как тузик грелку, но, сейчас, увы, уже нет - толпа наших программистов с Нижнего и Новосиба сделали свое черное дело.

Нет, AMDшные процессоры я юзать избегаю . Но дело совсем не в этом, а в другом - не хочу зарекаться на специфическое железо. Ведь то, что будет стоять у конечного пользователя, мне доподлинно неизвестно, и хотя написанная мною программа сможет при запуске легко получить эту информацию, не в ее власти заменить процессор или вставить видеокарту с продвинутым GPU. Поэтому рассчитывать приходится на СТАНДАРТНЫЕ способности компьютера, а MKL именно это и обещает. Т.е. она не закочевряжится, если процессор не поддерживает SSE3 или SSE4 инструкции, а просто обойдется без них.


Да, это именно тот вопрос, который меня волнует, однако вашего ответа я не поняла, а потому чуть-чуть переформулирую свой вопрос: будет ли у меня работать dll-библиотека от MKL, если я не куплю ее, а просто спишу с чужой машины или интернета? Уточняю, речь идет не об установке чужого продукта на свой компьютер, а о попытке запустить в работу DLL-библиотеку (в виде файла с расширением dll), к которой сделана самодельная линковка (многие компиляторы имеют средства для автоматической генерации библиотеки экспорта к имеющейся DDL-ке). Содержат ли продажные файлы dll-библиотек внутри себя какую-либо защиту, способную запретить этой библиотеке работать, если она не найдет, скажем, регистрационного ключа в реестре? И проверяет ли MKL-библиотека в процессе запуска наличие линцензии, даты/времени использования или чего-то в этом роде? Или, короче, говоря, велика ли надобность ее покупать, тем более за такую немалую цену?

ACML и не только на амдшниках работает кстати



да, будет, хотя я не проверял но именно сошки .so под линуксом именно так и работают - под виндой МКЛ ни разу не пользовал, но, думаю, там все то же самое.

Скажите, какая функциональность из МКЛя Вам нужна, я скажу чем Вам эту библиотеку можно заменить!

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

Для Ваших задач есть куча бесплатных и официальных альтернатив:

1. ACML точно работает в вижуал стидии, с мингвом и сугвином не смог скресить,
2. ATLAS ( http://sourceforge.net/projects/math-atlas/ ) работает под сугвином, не смог скрестить под мингв и вижуал студию, в любом случае потянет за собой лапак,
3. LAPACK (http://www.netlib.org/lapack) с сорсов компилится везде, на сайте производителя есть длл для всего. Не оптимизирована по скорости, то есть на шестиядернике может продуть раз так в 20 остальным библиотеками,
4. GotoBLAS и GotoLAPACK (вроде брать можно бесплатно, но продавать - нельзя из-за ГПЛности), ни разу не пользовал, но слышал от "академиков" восторженные отзывы.

правда как только Вам нужна работа с разреженными матрицами, то тут будет танец с бубном и этих библиотек Вам не хватит, но у меня есть своя спарсбиблиотека, часто делающая поделки Шенка (то что в МКЛе) поэтому меня это не сильно волнует

Нет, работа с разряженными и леточными матрицами мне не нужна. Однако MKL меня привлекает тем, что она обогнала (хотя и не сильно) мое творение на ассемблере - вычисление собственных значений и векторов действительной симметричной матрицы. При этом я так искусно всё это запрограммировала на FPU87-стеке, что полностью исключила запись в память всех промежуточных величин. Как они это сделали, понять так и не смогла, т.к. замена FPU87 на SSE2 такого выигрыша в скорости не дает (проверяла по скалярному произведению). Не дает такой скорости и LAPACK, взятый из исходников. А в MKL эта функция (DSYEVD) тоже относится к LAPACK, но отчего-то работает очень быстро. Я даже дезассеблировать ее пробовала, но быстро запуталась в логике (слишком уж много разных подпрограмм по ходу дела вызывает).

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

Я думаю, что основная причина, почему у Вас получилось медленнее, в том, что в Лапаке и иже с ними есть блочная работа с матрицами. Вот представьте, делаете Вы QR, но не хаусхолдерами, а блочными хаусхолдерами, в этом случае, если Ваша матрица не лезет в кеш процессора, блочный метод за одного хаусхолдера обращается один раз ко всей памяти матрицы, а скалярный - в К раз больше, где К - размер блока. А время обращения к памяти - в сотни раз больше времени одного флопа, все равно на чем он сделан. То есть если у Вас будет блочная не ассемблерная версия Вашего DSYEVD то у Вас думаю тоже все получится. Почитайте о проекте ATLAS - там об этом много и понятно написано.

Еще, когда Донгарра писал все эти бласы, они затачивались на Крей, где сложения и умножения шли парами. На данный момент это все тоже сидит в современных процессорах, поэтому, можно так написать на ассемблере, что не заметить, что два умножения (еще и зависимые по аргументам) идут друг за другом, а это очень плохо для производительности так как АЛУшки простаивать будут.

EDIT: а как Вы смогли все в стек засунуть - у Вас матрица такая маленькая? Если да, то тогда все из-за последовательности операций.

Да нет же! Я не про матрицу, а про промежуточные переменные, которые в том расчете участвуют. А в матрицу она лазает по многу раз, пока работу не выполнит.

вот как раз фетч по памяти и делает свое черное дело - в МКЛ-е блочность под процессор соптимизирована (не зря же в НН рабы сидят), а в голом лапаке - этого нет вообще. В атласе эта оптимизация происходит автоматически при инсталляции, бывали годы, когда атлас компилился больше суток!!!

EDIT: я понял о чем Вы! Вы вычисление сдвинутого Холецкого в методе разделяй и властвуй для тридиагональной симметричной матрицы в стек засунули... и, проиграли по скорости МКЛю, так?

Так и должно быть!

Вам надо на каждое собственное значение по несколько таких факторизаций выполнить, то есть по памяти Вы 2*N*N*K раз обратитесь, где N - размерность матрицы, K - среднее число итераций на каждое собственное значение.

Если бы Вы одновременно итерировали бы несколько ( собственных значений, то обращений по памяти у Вас было бы всего-то 2*N*N*K/B при том же количестве арифметических операций (7*N*N*K), но, так как доступ к памяти занимает много тактов при больших матрицах, это время будет определяющим в этом алгоритме, Вы бы получили решение несравненно быстрее.

Отчего же, к моменту вычисления собственных значений матрица уже сведена к тридиагональному виду, и существует виде всего двух векторов - главной диагонали и ее поддиагонали (вторую поддиагональ не хранят из-за ее полной симметричности первой). Т.е. итерации здесь идут на "двух палочках" , а съезжающий вниз боковой выступ динамически храниться в отдельной переменной (а у меня в регистре FPU87). Там в среднем не более 2-х итераций на каждое собственное значение (к хвосту быстрее).

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

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


Так не получится, т.к. QR/QL - это все-таки метод исчерпывания, в котором собственные значения вычисляются в монотонном порядке, причем обычно сначала ловятся бОльшие по абсолютной величине. Не "исчерпав" большее, трудно найти меньшее, т.к. нет уверенности, что итерационный процесс, начатый с разными стартовыми условиями (начальными сдвигами) сойдется к разным собственным значениям, а не к большему среди них.

начнем здесь. Вы говорили, что поместили все в фпустек, а именно факторизацию этой трехдиагональной матрицы, заданной главной и поддиагоналями. На каждое собственное значение Вам надо однажды прогнать факторизацию по этой матрице - N*2 обращений по памяти, и около 6*N арифметических операций. Далее так надо сделать для каждого собственного значения. Вот у Вас уже есть N*N*2 операций доступа к памяти. Итак, тут алгоритм на стек и только чтение по памяти.



Правильно ли я понимаю, что мы с Вами говорим о методе DSYEVD, а не о DSYEV и DSYEVX? Первый эффективен именно в блочном виде, а второй в блочном почти не реализуем если не считать приведение матрицы к трехдиагональному виду. Я все-таки склоняюсь, что мы говорим именно о DSYEVD...

Почитайте пожалуйста, статьи James Demmel и Juan Molera где-то в конце 90ых и начале 2000 они оба очень много об этом на конференциях говорили как можно выполнять эту факторизицию блочно с последующим вычислением собственных векторов. Так как я многое тогда прочитал и сейчас лениво перечитывать, найти на раз не смогу, да и немного лениво, но я точно помню, что они хвалились, что именно так надо делать и в лапак они это встроили. Еще им какой-то аспирант из Вупперталя помогал, но уже не помню его фамилию.



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

И еще, можно поинтересоваться попросить Вас сделать такой примерчик:

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

Теперь возьмите две большие (под 10к) матрицы и вызовите DGEMM из MKL с включенной поддержкой многоядерности (она у него по умолчанию), и сравните гигафлопсы. У меня разница на шестиядерниках зачастую в 10 раз зашкаливает, а ведь DGEMM-то в память обращается, вроде должен быть медленнее.

Честно говоря, я понятия не имею о том, как работает DSYEVD. Я его выбрала по списку из "Reference manual", где про него сказано только то, как под эту функция параметры подсовывать. А про существование DSYEV и DSYEVX, и их отличие от DSYEVD, я даже понятия не имею . Просветите меня пожалуйста, откуда брать информацию об алгоритмах процедур MKL? В каком документе они описаны?


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


Нет, не оптимизировала. Ибо не понимаю, чем я могу в эту сторону оптимизировать алгоритм. Я сама вообще брала алгоритмы из ... "Справочника алгоритмов на языке Алгол, линейная алгебра" Райнша и Уилкинсона. Потому как алгоритмы там понятные, а переводить с Алгола на С одно удовольствие, чего про Фортран никак не скажешь. Понимаю, что это очень старая версия алгоритмов, но все предельно ясно написано, а в современной версии LAPACK черт ногу сломит.


Нема у меня многоядерности, я на Pentium-4 живу. Однако сравнивала скорость с Core Dio 2 той же частоты. Впечатление такое, что SSE2 стали на последнем чуть быстрее, но скорость FPU87 упала даже по сравнению с Pentium-4. Поэтому мой (ассемблерный) вариант выигрыша на Core Dio 2 не дает, а MKL-ный вариант становится заметно быстрее.

Экстра вопрос: не знаете ли вы, на каком языке программирования эта MKL-библиотека компилировалась? И как она хавает матрицы: уложенные в памяти столбцами (на фортрановский манер) или строками (на С-шный манер)?

На сайте http://www.netlib.org/lapack довольно много и понятно написано о структуре лапака. Именно его функциональность поддерживает MKL. Но в MKL есть еще некоторые функции, которые находятся за пределами лапака.

Кстати, во времена Уилкинсона об алгоритме, который запрограммирован в DSYEVD еще ничего не было известно - как я помню, DSYEVD только в середине 80-х придумали какие-то американцы с незапоминающимися китайскими фамилиями. Различие DSYEVD и DSYEV в том, что первый требует дополнительно две копии матрицы в памяти, но имеет меньшую (в разы) арифметическую сложность.

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

фортрановский манер.

MKL состоит из нескольких частей - BLAS, LAPACK, FFT, Sparse, все остальное.

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

LAPACK написан на фортране, вернее взят именно тот вариант, который лежит на лапаковском официальном сайте и перекомпилирован. Для С интерфейса написаны враперы.

Сам лапак очень интенсивно использует BLAS - вот они-то написаны частично на ассемблере, частично на С, и, как мне известно, фортрана там уже нет. В них-то зарыта вся оптимизация по кешу, конвейеру и многоядерности, более того, МКЛ имеет разные ветки одной и той же функции в зависимости от типа процессора.

FFT написан на С, но имеет оптимизации по кешу, конвейеру и многоядерности, частично писанные на ассемблере.

Sparse - ядро алгоритма разрабатывалось изначально на фортране Саадом (Миннеаполис) и Болхофером (тогда еще Берлин), потом в 2002 это перенял Шенк (Базель, сейчас Лузана), являющийся ответственным за это в настоящее время, все это недавно было переведено на С, интенсивно дергает BLAS, но имеет несколько специализированных кеш оптимизированных алгоритмов для работы с целочисленными векторами.

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

Бласы с нетлиба - самые неоптимальные по скорости, вот тут надо найти что-то максимально дешевое или бесплатное, но и максимально быстрое. Как я говорил, я использую ACML - как очень хорошую и бесплатную альтернативу MKL.