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



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


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


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


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


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


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

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

Сообщение отредактировал _Pasha - Sep 28 2012, 13:22

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

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

Сообщение отредактировал _Pasha - Sep 28 2012, 13:59

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

На самом деле 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), но, так как доступ к памяти занимает много тактов при больших матрицах, это время будет определяющим в этом алгоритме, Вы бы получили решение несравненно быстрее.