[_Pasha 0]

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

 

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

 

к моменту рождения новояза

 

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

 

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

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

 

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

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

 

А про новомодные языки этого сказать нельзя.

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

 

Сама не раз переводила интересующие меня алгоритмы с Фортрана на С - удовольствие много ниже среднего.

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

 

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

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

 

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

PPS Да, прошу прощения за злостный оффтоп.

Изменено 28 сентября, 2012 пользователем _Pasha

[Xenia 38]

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

 

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

[_Pasha 0]

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

Изменено 28 сентября, 2012 пользователем _Pasha

[Xenia 38]

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

[Гость TSerg]

На самом деле MKL - это не только Саров, а еще Нижний и Новосибирск.

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

 

[DRUID3 0]

...чтобы выражения короче были. А то им влом длинную строку набирать...

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

Можно на нем исключительно все кроме... микроконтроллеров и харда. Но согласитесь 70%(а у нас всем 95%) программистов это и нафиг не надо.

 

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

 

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

Когда я учился программировать, компьютеры располагали скудными возможностями. Я помню, как приходилось вычищать пробелы из программ на Бейсике, чтобы они помещались в четыре килобайта памяти моего TRS-80. Мысль о том, что все эти изумительно неэффективные программы сожрут ресурсы, делая одно и то же снова и снова, кажется мне кощунством. Однако, похоже, здесь интуиция мне изменяет. Я напоминаю человека, выросшего в бедности и продолжающего экономить даже на самом необходимом, например, на лекарствах.

 

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

 

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

[iiv 19]

Intel Math Kernel Library известна не один год, ныне уже вышла ее 11-ая версия:

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

 

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

 

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

 

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

[Xenia 38]

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

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

 

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

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

[iiv 19]

Нет, AMDшные процессоры я юзать избегаю :)

 

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

 

будет ли у меня работать dll-библиотека от MKL, если я не куплю ее, а просто спишу с чужой машины или интернета?

Или, короче, говоря, велика ли надобность ее покупать, тем более за такую немалую цену? :)

 

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

 

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

[Xenia 38]

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

 

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

[iiv 19]

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

 

1. ACML точно работает в вижуал стидии, с мингвом и сугвином не смог скресить,

2. ATLAS ( http://sourceforge.net/projects/math-atlas/ ) работает под сугвином, не смог скрестить под мингв и вижуал студию, в любом случае потянет за собой лапак,

3. LAPACK (http://www.netlib.org/lapack) с сорсов компилится везде, на сайте производителя есть длл для всего. Не оптимизирована по скорости, то есть на шестиядернике может продуть раз так в 20 остальным библиотеками,

4. GotoBLAS и GotoLAPACK (вроде брать можно бесплатно, но продавать - нельзя из-за ГПЛности), ни разу не пользовал, но слышал от "академиков" восторженные отзывы.

 

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

[Xenia 38]

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

 

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

[iiv 19]

вычисление собственных значений и векторов действительной симметричной матрицы.

 

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

 

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

 

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

 

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

[Xenia 38]

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

 

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

[iiv 19]

А в матрицу она лазает по многу раз, пока работу не выполнит.

 

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

 

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

 

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

 

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

 

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