Вхід і реєстрація
Розробка · 13 листопада 2009, 20:46 143
crypto5, SWE

Python vs Others in Math

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

Итак, основные аргументы сторон:

Питон неимоверно крут для математики потому что:
— продуктивность разработки
— утверждается что для питона больше всего мат. либ
— утверждается что для других нельзя было найти либ для Symbolic integration and differentiation
— утверждается что SciPy самая крутая мат. либа из бесплатных

Питон не лучше чем конкуренты (в том числе мое мнение), потому что:
— преимущество продуктивности разработки питона вопрос спорный
— неочевидно, что для питона больше всего мат.либ.
— для других есть пакеты Symbolic integration and differentiation
, например Jasymca (Работает в несколько раз быстрее чем питоновская sympy)
— непонятно как сравнивать SciPy с другими мат. либами. Предлагаю рассмотреть фичи которые есть в ScyPi, но нельзя найти на других языках

Прошу к барьеру!

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
anonymous 18.11.2009 11:35

Св. Бубукий, спасибо, просветили школоту кратко, но исчерпывающе: -)

Відповісти
Підтримати
anonymous 18.11.2009 11:00

Me

Писать код с переменными вроде a, b, c, i, j — это тру, вспоминаются институтские лабы...;)

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

Відповісти
Підтримати
Dmitrey 18.11.2009 09:35
> alex312
> хочу заметить что основа традиционного питона написана на С, а основа SciPy — на С и Fortran
Основні операції numpy (операції над массивами — помноження, sin, cos, exp, і т.і.), які зокрема використовує і scipy, взяті з CorePy, яка використовує ассемблер. А працювати з numpy arrays набагато простіше ніж, наприклад, з С-шними слайсами (майже так само просто як у МАТЛАБ).
Щодо fortress language — він, на жаль, ще дуже сирий, наразі використовувати його для чогось більшого ніж ознайомчої мети недоцільно. Навіть маленькі программи потребують декілька секунд як для компіляції так і для інтепретації. До того ж, дуже багато тестів ще й досі не проходять, наприклад ці

projectfortress.sun.com/...g_static_tests Хоча, у своєму блозі вони недавно повідомили про значне покращення швидкості компілятора.

Відповісти
Підтримати
anonymous 15.11.2009 20:32
2 Ме

Больше ничего промычать не в состоянии? Тут обсуждается именно опыт юзанья научных библиотек.

Відповісти
Підтримати
anonymous 15.11.2009 20:21
2hellip:

Писать код с переменными вроде a, b, c, i, j — это тру, вспоминаются институтские лабы...;)

Відповісти
Підтримати
anonymous 15.11.2009 16:57
в фортране, насколько я понимаю, проблемы алиасинга нет по определению.

Есть. Вы забываете про EQUIVALENCE. Вот код на С/С++, где aliasing виден ещё рельефнее, нежели в вашем примере: 

int a[100][100], c[100][100], i, j;
int (*b)[100];
b = a;
// какой-то код
for(i=1;i<n;i++) {
    for(j=0;j<m;j++) {
        a[j][i] = b[j+1][i-1] + c[j][i];
    }
}

А вот как траблы с указателями можно успешно воспроизвести в фортрановском коде: 

INTEGER A(100,100), B(100,100), C(100,100)
EQUIVALENCE(A,B)
С какой-то код
DO J = 2, M
     DO I = 1, N
           A(J,I) = B(J+1,I-1) + C(J,I)
     ENDDO
ENDDO

Клинически чистая loop-carried dependence. А теперь будем шалить дальше и посмотрим на множественное петление: 

for(j=0;j<n;j++){
    for(i=0;i<m;i++){
       a[i][j] = b[i][j] + c[i][j];
       if(a[i][j] == 0) break;
// какой-то код
    }
}

И снова, в Фортране оказывается возможным воспроизвести говнокод: 

DO J = 1, M
         DO I = 1, N
              A(I,J) = B(I,J) + C(I,J)
              IF(A(I,J) .EQ. 0) GOTO 50
C какой-то код
         ENDDO
     ENDDO
C какой-то код
50 CONTINUE

именно для этого в C99 ввели ключевое слово restrict

... Да, но тем временем в Фортране уже десять лет существовала такая полезная штука, как 

 max_threads
Відповісти
Підтримати
anonymous 15.11.2009 13:34

Ну и наличие указателей (опять же на мой ламерский взгляд) на векторизацию влиять не должно никак.

Я думаю, що в принципі з цим можна погодитись.
Звичайно що неочевидно, чи a [i] не співпадає з b [к]
Але розібратися в цьому можливо, адже вказівники «a» та «b» беруться не з рандома, а вираховуються в програмі.
Якщо б розібратися в цьому було неможливо, то людина не могла б векторизувати таку програму.
А раз людина може — значить проблема тільки в алгоритмі компілятора.
Адже коли компілятор Фортрана повинен розкрутити цикл з виразами типу
a [expr1 (x, y), expr2 (x, y)] = b [expr3 (x, y), y, t] * c [x, y+1] +d [x+1, y] і т.д.
йому теж непросто вияснити де є залежності.
І я хочу відмітити, що тут мова не йде про те, щоб просто впевнитись, що залежностей нема.
Залежності тут є. Але компілятор виділяє незалежні підмножини значень і генерує паралельний код.
При цьому він може досить суттєво переробити алгоритм (наприклад поміняти місцями вкладені цикли, або змінити формули).
P.S. Я не заперечую, що складність еквівалентного оптимізатора для С буде вища ніж для Фортрана.

Але мені здається, що для багатьох кодів HPC ця різниця все-таки кількісна, а не якісна.

Відповісти
Підтримати
anonymous 15.11.2009 13:08

еще раз, медленно: наличие в С (и, соответственно, в С++) pointer aliasing затрудняет оптимизацию кода, причем в местах, которые для компилятора фортрана или напр. окамла не представляют проблемы.

Очевидно частина мого тексту не була уважно прочитана, тому цитую сам себе:

якщо... всі дані оголосити в глобальних масивах,... не передавати масивів у функції,...... немає принципових причин для різної ефективності С та Фортрана.

Відповісти
Підтримати
Sergiy Matusevych вечный чайник 15.11.2009 04:55

crypto5: дык с векторизацией-то те же проблемы! знание, что данные могут перекрываться, или, наоборот, гарантированно никогда не перекрываются, очень сильно влияет на поведение оптимизатора, но в С компилятору очень трудно различить эти два случая (особенно без *restricted). почитай википедию и еще вот примеры.

Відповісти
Підтримати
crypto5 15.11.2009 01:42
Motus
На мой ламерский взгляд, векторизация (про которую толкует Эндрю)! = распаралеливание (о котором пишешь ты). Ну и наличие указателей (опять же на мой ламерский взгляд) на векторизацию влиять не должно никак.

Хотя могу ошибаться...

Відповісти
Підтримати
Sergiy Matusevych вечный чайник 15.11.2009 01:14

еще раз, медленно: наличие в С (и, соответственно, в С++) pointer aliasing затрудняет оптимизацию кода, причем в местах, которые для компилятора фортрана или напр. окамла не представляют проблемы. все. точка. т.е. есть сложности кода (как в первом примере от hellip), а есть сложности языка. т.е. если переписать пример как-то так: 

void test(int* a, int* b) {
  int i;
  for (i = 0; i <  99; ++i) a[i] += a[i+1];
  for (i = 1; i < 100; ++i) b[i] += b[i-1];
}

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

Відповісти
Підтримати
anonymous 14.11.2009 23:27

дык все равно, во все функции массивы прередаются как указатели, т.е. внутри функций (в т.ч. библиотечных) нет гарантии, что два указателя не указывают (или не будут указывать в какой-то момент выполнения функции) на один и тот же объект.
Звичайно в С є моменти, які ускладнюють векторизацію.
Але я мав на увазі, що навіть якщо їх всі забрати, то все одно може вийти так, що Фортранівський компілятор, котрий поставляється вендором векторного суперкомп’ютера дасть набагато ефективніший код, ніж С-шний компілятор.
Забрати всі проблемні фічі можна просто — писати С-шну програму у Фортранівському стилі.
Тобто всі дані оголосити в глобальних масивах, використовувати тільки цілі та дійсні числа, не передавати масивів у функції, не викликати бібліотечних функцій всередині обчислювального циклу і т.д.
В цьому випадку немає принципових причин для різної ефективності С та Фортрана.
Але на практиці така різниця може бути.
І причина така: наприклад фірма Хітачі продає суперкомп’ютерів на сотні мільйонів доларів.
При цьому вона може вкладати мільйони в компілятор Фортрана, який поставляється з нею, і це продовжується вже багато років.
Тому математика, реалізована в цьому компіляторі (методи розкручування циклів, виявлення інваріантних перетворень типу перестановки місцями вкладених циклів, оптимізації коду на локальність кеша і т.д.) може бути краща, ніж в якомусь С-шному компіляторі.

А причиною того, чому чому замовники за це платять (замість того, щоб перейти на кластери) є старий код, який розроблявся десятиліттями для векторних суперкомп’ютерів і зараз викидати його було б дорого.

Відповісти
Підтримати
anonymous 14.11.2009 22:11
Так, топик потихоньку пора переименовывать в «Фортран против С». Чего, собственно, и следовало ожидать. В С/С++, как бы его здесь ни поносили несознательные анонимусы, всё-таки есть почти все необходимые для высокопроизводительных научных вычислений фичи. Если нужна гибкость, используем STL, виртуализацию, RTTI, IMSL etc. — и можем уже подобраться к F95/2003. Если нужна скорость, то можно все гнать через templates\явн. inline — и опять-таки из-за алгоритмической волатильности С/С++ (позволяющей эффективную реализацию более сложных алгоритмов) сравниваемся, а то и превосходим *: * F95/2003.

А сложности распараллеливания циклов и на фортране возникают. Цикл реализует тривиальную рекурсию с учётом причинных связей: 

DO 4 I = 1,99
4 A(I) = A(I) + A(I+1)
DO 5 I = 2,100
5 A(I) = A(I) + A(I-1)

Результат i-го сложения, таким образом, оказывается недоступен до тех пор, пока не начинается i+1-е сложение, поэтому для оператора с меткой 5 возникает трабл с учётом причинности. Как бы его можно было бы векторизовать? Если в массиве результатов

B(i) = sum {j = 0,...,I} A(j),

то один из возможных вариантов таков:

DO 6 I=2,N
B(I) = 0
DO 6 J=1,I
6 B(I) = B(I) + A(J)
DO 7 I=2,N
7 A(I) = B(I)

Но теперь число выполняемых операций возрастает с N до N (N+1) /2. Зато оператор векторизовался полностью.

ЗЫ. Просьба к некоторым здесь присутствующим на всякий случай вчитаться в текст поста повнимательнее, а не браться сразу за вентилятор.

Відповісти
Підтримати
Sergiy Matusevych вечный чайник 14.11.2009 21:58

Деякі компілятори Фортрана можуть виявитися ефективнішими ніж деякі компілятори С навіть при умові використання в коді тільки простих змінних і масивів:)

дык все равно, во все функции массивы прередаются как указатели, т.е. внутри функций (в т.ч. библиотечных) нет гарантии, что два указателя не указывают (или не будут указывать в какой-то момент выполнения функции) на один и тот же объект. отсюда — менее оптимальный код и сложности с распараллеливанием. почитай, в частности, про ключевое слово restrict в C99, и дискуссии C vs. Fortran на stackoverflow.com.

Відповісти
Підтримати
anonymous 14.11.2009 21:40
> фигассе нема. про указатели в С слышал?:)
Ок, поправляю:)

Деякі компілятори Фортрана можуть виявитися ефективнішими ніж деякі компілятори С навіть при умові використання в коді тільки простих змінних і масивів:)

Відповісти
Підтримати
Sergiy Matusevych вечный чайник 14.11.2009 21:29

деякі компілятори Фортрана можуть виявитися ефективнішими ніж деякі компілятори С, хоча в самій мові видимих причин для цього нема.

фигассе нема. про указатели в С слышал?:)

Відповісти
Підтримати
anonymous 14.11.2009 20:30
> PS. 2 Andrew Я уважаю ваше мнение, но категорически не согласен с тем,
> что HPF перспективнее, чем все остальные подходы OpenMP.
А я і не мав на увазі, що HPF перспективніший взагалі.
Я мав на увазі що він кращий для вендорів векторних суперкомп’ютерів, і тому вони його фінансують більше, ніж OpenMP.

Що може мати свій вплив на ефективність компіляторів, і тому деякі компілятори Фортрана можуть виявитися ефективнішими ніж деякі компілятори С, хоча в самій мові видимих причин для цього нема.

Відповісти
Підтримати
anonymous 14.11.2009 20:20
>> я зрозумів, Jasymca вміє інтегрувати диф. рівняння тільки першого порядку.
> Где ты такое прочитал?
В документації на Jasymca.
> Интегрирование аналитическое или численное?
Аналітичне звичайно.
> SciPy такое умеет?
Ні, SciPy — це чисельна ліба. А SimPy вміє, наскільки я пам’ятаю.
> Ход мысли к сожалению я потерял.
Я мав на увазі, що якщо я буду шукати лібу в Гуглі (50_000 лінків)
то це займе набагато більше часу, ніж по списку де є 10 потрібних лінків.
Але саме головне — в Гуглі я можу пропустити потрібну лібу.
Звичайно список — не панацея.Просто він інколи дуже корисний.
> Java vs Python?
Теж цікавий інвестігейшен:)
Але сам по собі факт, що джаву більше юзають, малоінформативний.
Хотілося б почути пояснення, чим вона краща.
От Віндовс теж більше юзають ніж Лінукс.
Це ж само по собі не одначає, що він всім кращий.
Взагалі я не стверджую, що Пітон безумовно найкращий.
Я просто описав ті його переваги, які я бачу.
Може якісь інші мови мають і більше переваг.

Просто хотілося б про них почути щось конкретне.

Відповісти
Підтримати
anonymous 14.11.2009 20:06
Теоретично можна легко знайти ліки від СНІДу — формула ліків є теоретично тривіальним
наслідком рівняння Шредінгера
Ну ничего себе...
Ты знаешь, он совершенно прав. Теоретически можно построить квантовомеханическую модель структуры комплекса ВИЧ-протеазы с подходящим ингибитором и, решив для неё уравнение Шредингера, найти, какие заместители и функциональные группы следует ввести в структуру молекулы, чтобы действие вируса подавлялось наиболее заметно. Но этого никто не делает, потому что все — именно все — методы моделирования структуры молекул страдают от экспоненциального роста количества состояний квантовой системы. В отсутствие квантовых компьютеров дело безнадежное. Так что покамест синтетики-химеги теоретиков-химегов терпеть не могут, потому что ересь у тех получается знатная.
Пока наилучшие результаты из пакетов моделирования молекул даёт программа GAUSSIAN, написанная на Фортране и С.

PS. 2 Andrew Я уважаю ваше мнение, но категорически не согласен с тем, что HPF перспективнее, чем все остальные подходы OpenMP. В OpenMP гораздо изящнее проведена, например, политика защиты при обновлении синхронизируемой глобальной потоковой суммы через critical (computing.llnl.gov/...ynchronization.

Відповісти
Підтримати
anonymous 14.11.2009 20:04
>> Зокрема тому, що там є кому за це платити.
> Intel разумеете?:)
Ні, вендорів векторних суперкомп’ютерів типу Хітачі, Фюджитсу, Сіменс і т.п.
Десь в інтервалі 1990−2000 років вже всім стало очевидно, що співвідношення MFLOPS/$
для кластера з офісних компів набагато краще, ніж для векторних суперкомп’ютерів.
Тому продавати їх стало не так просто.Звичайно можна дати відкат, але якісь легенди про
людське око теж потрібні.
Наскільки я розумію, магістральний напрямок був такий:
Вендори почали порівнювати швидкодію на вибраних задачах.
Задачі вибиралися сильнозв’язні і такі, що були написані на Фортрані 20 років тому
(коли це фінансувалося грандіозними вливаннями у воєнку в часи холодної війни)
Якщо тепер просто перекомпілити під МРІ, то через сильну зв’язність це працювати
на кластері буде дуже повільно і кластер програє. А переписувати всю задачу — фінансування
вже нема.
От тому вендорам є зміст фінансувати доробку HPF (як взагалі так і конкретно під їхні машини) ,

а не розробку розумних компіляторів під МРІ і т.п.

Відповісти
Підтримати
crypto5 14.11.2009 18:57

Наскільки я зрозумів, Jasymca вміє інтегрувати диф. рівняння тільки першого порядку.

Где ты такое прочитал? Интегрирование аналитическое или численное? SciPy такое умеет?

Якщо списка — нема це вже погано.

Ок, я действительно не нашел такого каталога програм для джава. Вместо этого успешно использую гугл.Ну и у меня есть большие притенции к этому списку, как я уже говорил в нем собраны не только питон библиотеки, и также много комерческих програм.

Наприклад якщо мені треба знайти лібу для розрахунку молекул,
то на Пітоні я дивлюся в список і вибираю з 10 ліб.
А якщо списку нема, я шукаю в Гуглі (наприклад 50_000 лінків)
В більшості сайт зробленимй так, що його можна браузати півгодини
і навіть не взнати на якій мові це написано (про біндінги я мовчу)
В результаті я можу це шукати тиждень і більше
і цілком можливо, що буду потім півроку юзати лібу, яка мені підходить
в 10 раз гірше, ніж якась інша ліба, яку я не знайшов, тому що мені не дали

часу на те, щоб передивитись всі ліби.

Ход мысли к сожалению я потерял.

Крім того, якщо списку ліб нема, це мабуть все-таки щось означає.
Або ліб менше, або ком’юніті гірше, або на цій мові ніхто тих ліб

не використовує, бо вона гірше підходить для даної роботи.

Или наоборот, либ настолько много что их никто не взялся каталогизировать!

Якщо це воно — jmol.sourceforge.net/.../JmolUserGuide
то наскільки я зрозумів, це не програма для молекулярного моделювання, ,
а програма для візуалізації просторової структури молекули

(яку розрахувати повинен хтось інший)

Тут я сливаю. Я не сильно шарю что такое молекулярное моделирование.

Щось не дуже віриться:)
Алгоритми для компіляторів Фортрана розробляються ще з часів Крей-1

І я не чув щоб хтось їх побив.

Теперь слышал.

Там все исходники открыты, можешь скачать посмотреть потестировать. Тасколько я понимаю фортран до сих пор хорош в определенных областях (например в BLAS вычислениях), но в общем случае это не факт.

Теоретично можна легко знайти ліки від СНІДу — формула ліків є теоретично тривіальним

наслідком рівняння Шредінгера

Ну ничего себе...

дійсно цікавий інвестігейшен:)

C++ vs. Python

Java vs Python?

Відповісти
Підтримати
anonymous 14.11.2009 17:30
Зокрема тому, що там є кому за це платити.
Intel разумеете?:)
Давайте разберемся сначала с историей вопроса. Вы должны бы знать, что IBM сейчас отошла от собственно компьютерного бизнеса и переключилась на консалтинг, оставив за собой преимущественно сектора мэйнфреймов и суперкомпьютеров, где тусуются правительственные заказчики. И там до сих пор активно используется компилятор VS/XL Fortran, выпущенный аж в 1965-м, с соответствующими разумными усовершенствованиями.
Watcom и Sun Studio Fortran Compiler, как известно, распространяются свободно.
Чего там надобно буржуям, промышляющим моделированием молекул и атмосферных течений? Говорите, параллельные вычисления? А между прочим, компилятор Co-array Fortran для линукс-архитектуры тоже опенсорцевый, и все компиляторы, восходящие к Сray, уступают ему по производительности.
Сколько альтернатив насчитали, не прибегая к Интел и мелкомягким? То-то же. Главное здесь — цель исследования, а не скорость впаривания его заказчику. Заказчик уйдет, придет другой с похожей задачей. Я всё это в своей компании очень хорошо наблюдаю, мы как раз моделирование молекул среди прочего и юзаем.

Поехали дальше. Несоответствие стандарту в плане собираемости несобираемого — изъян и gcc, и мелкософтовских компиляторов. Extension везде есть. Потому и не надо утыкаться в Intel, хоть там и соотношение к другим конторам примерно такое, как между Мерседесом GL500 и КИА Черато. Под Linuх есть проверенные, вылизанные, особенно начиная с тех пор, как расплодились многоядерные рабочие станции, AMD-совместимые PathScale и тот же, вышеупомянутый, SunStudio.

Відповісти
Підтримати
anonymous 14.11.2009 15:15
Хоч і радили мені не кормити цього троля, але ладно, ще раз йому відповім:)
to: anonymous
>> Алгоритми для компіляторів Фортрана розробляються ще з часів Крей-1
>> І я не чув щоб хтось їх побив.
> И снова бугага.
Крім “бугага” ще слова якісь знаєш?
Не можеш нічого корисного сказати — не засмічуй форум
> Во времена Крей1 в книжках по Фортрану писали, что не стоит
> использовать процедуры, потому что их вызов замедляет выполнение.
А тепер пишуть, що пришвидшує?
> Я уже не говорю про то насколько “вылизывались” кодогенераторы последние 10 лет.
А чого?
Розказав би — от була б якась корисна інформація.
Якраз основні зусилля в покращенні кодогенерації і були направлені на Фортран.

Зокрема тому, що там є кому за це платити.

Відповісти
Підтримати
anonymous 14.11.2009 15:01
Соррі, перший раз в житті спробував тут запостити лінк, вийшов глюк:)
Зараз спробую ще раз:)
> Давай тогда пойдём другим путём: набери в инете
> job math C++ и job math python — money talks
дійсно цікавий інвестігейшен:)
C++ vs. Python
Але взагалі то мова не про поточну популярність мови, а про її ефективність.
Поточна популярність може диктуватися різними причинами.
Перед 2000 роком Кобол був ледве не самим популярним в об’явах про пошук програмістів на закордон.

Але це ж не означає, що Кобол став найкращою мовою.

Відповісти
Підтримати
anonymous 14.11.2009 14:56
> Давай тогда пойдём другим путём: набери в инете
> job math C++ и job math python — money talks
дійсно цікавий інвестігейшен:)



Але взагалі то мова не про поточну популярність мови,  а про її ефективність.
Поточна популярність може диктуватися різними причинами.
Перед 2000 роком Кобол був ледве не самим популярним в об'явах про пошук програмістів на закордон.
Але це ж не означає, що Кобол став найкращою мовою.
Відповісти
Підтримати
anonymous 14.11.2009 14:23
> Тут вы немного не правы. Какие инструкции процессора использовать
> указывает компилятору программист, и если компилировать код в
> режиме совместимости с i386, то естественно никаких инструкций,
> которые появились в пеньке использоватся не будут.
Так, але:
1. Не кожному компілятору це можна вказати
2. «Вказати використовувати SSE» і «добитися результативного використання SSE» — це
зовсім різні речі
Візьмем наприклад такий код
for x: =0 to n do
for y: =0 to n do
a [x, y]: =b [x, y] *c [x, y]
Наприклад кожна операція SSE працює з 2 числами в одному регістрі.
Якщо просто реалізувати множення через SSE, то буде використовуватися тільки половина регістра.
Для того, щоб використовувати другу половину регістра необхідно змінити логіку
програми (зробити розкручування циклу)
Типу такого:
for y: =0 to n/2 do
a [x, 2*y]: =b [x, 2*y] *c [x, 2*y]
a [x, 2*y+1]: =b [x, 2*y+1] *c [x, 2*y+1]
І ці два множення зкомпілювати в одну інструкцію.
Тут для людини очевидно, що це можна зробти, але для компілятора
в загальному випадку треба перевірити взаємну незалежність даних,
обробити ситуацію, коли «n» не ділиться на 2 і т.д.
Також може виявитися, що операнди SSE-інструкції при такому
розкручування цикла не попадають в один cache stride.
А якщо змінити порядок циклів, то попадуть (різниця в швидкодії — не порядок)
Для людини просто поміняти
for x: =0 to n do
for y: =0 to n do
на
for y: =0 to n do
for x: =0 to n do
Але для компілятора це далеко не тривіально.
Далеко не всі компілятори вміють такі речі робити.
В цьому до речі і є перевага компіляторів Фортрана над іншими.
> И хочу заметить что основа традиционного питона написана
> на С, а основа SciPy — на С и Fortran
Так але просто «С» — це одне,

а «С + ручна оптимізація + вставки на асемблері» — це інше

Відповісти
Підтримати
anonymous 14.11.2009 14:11
2 Andrew

Давай тогда пойдём другим путём: набери в инете job math C++ и job math python — money talks

Відповісти
Підтримати
anonymous 14.11.2009 13:59
>> В математических расчётах скорость разработки не имеет такого
>> критического значения, как в оутсорсинге.
Ми взагалі-то почали цю розмову з того, що математик йде працювати
на аутсосінгову фірму і буде там розробляти математично-орієнтовані задачі:)
Питання було, яку мову програмування йому краще використовувати.
І швидкість розробки тут може бути дуже важлива (знаю точно:))
>> Математические библиотеки пишутся один раз и используются
>> десятками лет, так как численные методы используемые на
>> практике не менялись уже много лет.
Не згідний.
По-перше є чисельні методи (наприклад квантово-механічний
розрахунок молекул або моделювання антен) які постійно
вдосконалюються, і в книжках їх не знайдеш — know-how фірм,
які з цього живуть, просто так не роздається.
По-друге ми обговорюєм цю тему в контексті питання
«яку мову програмування варто вивчати математику для своєї роботи»
Звичайно існують задачі, де є вже готовий алгоритм і навіть
бібліотека вже написана (наприклад на Фортрані).
Але математику не будуть платити гроші за це.
Від нього захочуть розробки чогось нового.
Якщо ж він просто використовує цей готовий метод у своїй роботі,
то вичати цю мову програмування (наприклад Фортран) для цього не потрібно.
По-третє «пишуться один раз і використовуються роками» — це в основному
про студента, який реалізовує чисельний метод з книжки.
Якщо говорити про розробника, то в нього режим роботи може бути зовсім інший.
Наприклад він пробує одну конструкцію алгоритму, запускає, аналізує
результат, думає, міняє, реалізує новий алгоритм, запускає, і т.д.
Тобто кожен новий варіант програми запускається 1 раз.
Таким чином час розробки виходить набагато більший ніж
час прогону програми.
>> Реализовывать что — то новое нужно примерно в 1% всех вычислений.
Так, але за цей 1% якраз і платять гроші.
А за 99% запусків готових бібліотек отримують гроші сисадміни:)
Раніше ще була популярна тема — читати в книжці алгоритм і реалізовувати програму.
Але по мірі напрацювання загальнодоступних бібліотек (, а особливо зараз- у зв’язку
з поширенням опен-сорс) це відходить в минуле.
>> (парсання вхідних даних і робота з динамічнми
>> структурами даних в Пітоні простіша)
> Скорость!!! Я как — то писал парсер файла размером в
> несколько сот (!!!) мегабайт, файлов было несколько
> — данные по сканированию участка звёздного неба.
> Парсинг на питоне занимал туеву хучу времени, фактически
> можно было запустить прогу и идти отдыхать на денёк.
> Паскалевская прога работала несколько минут.
Це напевно якийсь особливий випадок.
Я парсав файли десь в 5 гігабайт.
Типова швидкість Пітона: 10−30 МБ/сек
Типова швидкість Делфі: 50−80 МБ/сек (лімітується диском)
Але написати парсалку на Делфі може зайняти години, а на Пітоні — хвилини.
Я ще ніколи не чув, щоб хтось жалівся на швидкість парсання Пітона.
Думаю, що в більшості випадків вона задовільна.
Крім того треба врахувати ще один момент.
Не всі задачі працюють з таблицями чи матрицями.
В деяких задачах зустрічаються складні динамічні структури даних.
Написати парсання їх на С буде занадто складно — це займе в 10 раз
більше часу, ніж на Пітоні зробити все.
>> Та й не всі обчислювальні задачі є критичними по швидкості.
>> Буває що критичний час розробки, а прогон програми і так
>> часу багато не займає.
> Тогда их можно написать на любом языке и дискуссия
> излишня. Написал, получил результат, забыл.
Ні, тоді треба писати на тій мові, на якій розробка займе
тиждень, а не місяць. Інакше інший аналітик розробить це
швидше, з витікаючими звідси наслідками.
>> Зараз є багато задач, де вхідні дані це не числа, а наприклад текст.
>> В цьому випадку більшість часу затрачається у внутрішніх лібах
>> типу регекспів чи менедження динамічних списків.
>> І тоді швидкість інтерпретованої мови практично така ж, як і компільованої.
>> А зручність роботи може бути значно більша.
> Это, извините, чистой воды романтика. Код написанный знающим
> программистом на С будет всегда быстрее кода на любом интерпретируемом
> языке. Списки в этом случае пишутся самостоятельно, ручками,
> регекспы заменяются парсингом в ручную — же и будет быстрее по любому.
Теоретично так.
Теоретично можна легко знайти ліки від СНІДу — формула ліків є теоретично тривіальним
наслідком рівняння Шредінгера. Але практично є певні ускладнення в його
інтегруванні (наприклад це займає багато часу).
Так само теоретично наш математик може розробляти свої алгоритми на С (наприклад місяць).
Якщо він це робить в себе вдома, то це може і спрацює.
Але якщо він працює в аутсорсінговій конторі, і американський математик на Пітоні
це розробить за тиждень, то нашому математику запишуть −1.

І йому доведеться або перебиратись на Пітон, або мати трабли.

Відповісти
Підтримати
anonymous 14.11.2009 12:12
А помоему уже обганяет; -)
Это потому, что JIT компиляция по сравнению с JIT интерпретацией скачком повышает скорость выполнения. Но циклы, используемые для перекомпиляции, очень примитивны. И кроме того, в табличках и на графиках даётся сумма собственно времени считывания данных, времени векторизации, синхронизации и Ethernet-магии.

anonymous, ты не в теме, несколькими постами выше уже поминали Fortress.

Відповісти
Підтримати
anonymous 14.11.2009 11:00

А якщо писати код на plain С, то він транслюється в інструкції FPU (типу FLD, FMUL)

Бугага, “эксперт” продолжает жечь. По моему козачек засланный и его цель скомпрометировать пользователей Питона.

Щось не дуже віриться:)
Алгоритми для компіляторів Фортрана розробляються ще з часів Крей-1
І я не чув щоб хтось їх побив.

И снова бугага. Во времена Крей1 в книжках по Фортрану писали, что не стоит использовать процедуры, потому что их вызов замедляет выполнение. Я уже не говорю про то насколько “вылизывались” кодогенераторы последние 10 лет. “Эксперт” видимо еще более непревзойденное светило в разработке компиляторов чем в теоретической оченки языков программирования. А учитывая широчайше-глубочайшие познания в области библиотек для Лиспа можно смело утверждать, что перед нами никто иной как Гай Стил. Простите, не узнал в гриме.

Відповісти
Підтримати
anonymous 14.11.2009 10:51

В даному випадку під векторизацією я маю на увазі використання векторних
інструкцій CPU (типу SSE).
SciPy/NumPy використовує їх.
А якщо писати код на plain С, то він транслюється в інструкції FPU (типу FLD, FMUL)
Що само по собі набагато повільніше (в мене різниця бувала десь в 5 раз і це ще не рекорд).
А навіть якщо спробувати дописувати вставки на асемблері, то будуть ще

граблі з вирівнюванням даних на cache stride, особливо в стекових змінних.

Тут вы немного не правы. Какие инструкции процессора использовать указывает компилятору программист, и если компилировать код в режиме совместимости с i386, то естественно никаких инструкций, которые появились в пеньке использоватся не будут. И хочу заметить что основа традиционного питона написана на С, а основа SciPy — на С и Fortran

Відповісти
Підтримати
anonymous 14.11.2009 10:35
> Я как джава программист юзаю Jakarta Commons Math и Jasymca.
Наскільки я зрозумів, Jasymca вміє інтегрувати диф. рівняння тільки першого порядку.
>> www.scipy.org/...opical_Software
> Во первых по этой ссылке много не питоновых либ, а байндингов
> к не питон либам, к которым обычно есть и например джава АПИ.
> Во вторых если такого списка нет под рукой для другой платформы,
> это не значит что либ нету или они хуже.
Як мінімум спірне питання.
Якщо списка — нема це вже погано.
Наприклад якщо мені треба знайти лібу для розрахунку молекул,
то на Пітоні я дивлюся в список і вибираю з 10 ліб.
А якщо списку нема, я шукаю в Гуглі (наприклад 50_000 лінків)
В більшості сайт зробленимй так, що його можна браузати півгодини
і навіть не взнати на якій мові це написано (про біндінги я мовчу)
В результаті я можу це шукати тиждень і більше
і цілком можливо, що буду потім півроку юзати лібу, яка мені підходить
в 10 раз гірше, ніж якась інша ліба, яку я не знайшов, тому що мені не дали
часу на те, щоб передивитись всі ліби.
Крім того, якщо списку ліб нема, це мабуть все-таки щось означає.
Або ліб менше, або ком’юніті гірше, або на цій мові ніхто тих ліб
не використовує, бо вона гірше підходить для даної роботи.
> К тому же важен вопрос качества, а не количества.
> Например для Джава для молекулярного моделирования
> Jmol вполне себе программа.
Якщо це воно — jmol.sourceforge.net/.../JmolUserGuide
то наскільки я зрозумів, це не програма для молекулярного моделювання, ,
а програма для візуалізації просторової структури молекули
(яку розрахувати повинен хтось інший)
> На сановских блогах утверждают, что JVM сейчас подобрались
> к фортрану по скорости вычислений:)
> А помоему уже обганяет; -)
> shootout.alioth.debian.org/...4/benchmark.php test=all& lang=java& lang2=ifc& box=1
Щось не дуже віриться:)
Алгоритми для компіляторів Фортрана розробляються ще з часів Крей-1
І я не чув щоб хтось їх побив.
Як правило ставиться задача наблизитися до них, і то не дуже досягається.
Для того щоб випередити в 3 рази, потрібно було б мабуть якісь відкриття
зробити в теорії компіляції, а щось не було чути про таке.
>> тому що plain С не векторизує код
> А можно поподробнее как SciPy (NumPy?) векторизирует код?
В даному випадку під векторизацією я маю на увазі використання векторних
інструкцій CPU (типу SSE).
SciPy/NumPy використовує їх.
А якщо писати код на plain С, то він транслюється в інструкції FPU (типу FLD, FMUL)
Що само по собі набагато повільніше (в мене різниця бувала десь в 5 раз і це ще не рекорд).
А навіть якщо спробувати дописувати вставки на асемблері, то будуть ще

граблі з вирівнюванням даних на cache stride, особливо в стекових змінних.

Відповісти
Підтримати
anonymous 13.11.2009 23:09

Якщо на С заюзати ліби типу BLAS, то швидкість програми зрівняється, але на Пітоні реально

результат буде швидше, тому що розробити програму на Пітоні можна швидше

В математических расчётах скорость разработки не имеет такого критического значения, как в оутсорсинге. Математические библиотеки пишутся один раз и используются десятками лет, так как численные методы используемые на практике не менялись уже много лет. Реализовывать что — то новое нужно примерно в 1% всех вычислений.

(парсання вхідних даних і робота з динамічноми структурами даних в Пітоні простіша)

Скорость!!! Я как — то писал парсер файла размером в несколько сот (!!!) мегабайт, файлов было несколько — данные по сканированию участка звёздного неба. Парсинг на питоне занимал туеву хучу времени, фактически можно было запустить прогу и идти отдыхать на денёк. Паскалевская прога работала несколько минут.

Та й не всі обчислювальні задачі є критичними по швидкості. Буває що критичний час розробки, а прогон програми і так часу багато не займає.

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

Зараз є багато задач, де вхідні дані це не числа, а наприклад текст.
В цьому випадку більшість часу затрачається у внутрішніх лібах типу регекспів чи менедження динамічних списків.
І тоді швидкість інтерпретованої мови практично така ж, як і компільованої.

А зручність роботи може бути значно більша.

Это, извините, чистой воды романтика. Код написанный знающим программистом на С будет

всегда

быстрее кода на любом интерпретируемом языке. Списки в этом случае пишутся самостоятельно, ручками, регекспы заменяются парсингом в ручную — же и будет быстрее по любому.

Відповісти
Підтримати
crypto5 13.11.2009 22:53

Я взагалі-то мав на увазі трохи інше.
Що якщо мені покажуть функціональний аналог SciPy на іншій мові, то є зміст продовжувати розмову і розглядати інші питання:)
SciPy — це набір базового функціоналу типу матричного множення чи чисельного інтегрування.

Якщо в певної мови нема навіть цього, то про інше і говорити нема чого.

Я как джава программист юзаю Jakarta Commons Math и Jasymca.

А якщо говорити про інше:
Для прикладу список Пітоновських бібліотек
www.scipy.org/...opical_Software
Там є групування по різних темах, можна для порівняння вибрати будь-яку
Мені наприклад було б цікаво порівняти розділ “Molecular modeling”.

(Я сам цим не займаюсь, просто цікаво).

Во первых по этой ссылке много не питоновых либ, а байндингов к не питон либам, к которым обычно есть и например джава АПИ. Во вторых если такого списка нет под рукой для другой платформы, это не значит что либ нету или они хуже.К тому же важен вопрос качества, а не количества... Например для Джава для молекулярного моделирования Jmol вполне себе программа.

На сановских блогах утверждают, что JVM сейчас подобрались к фортрану по скорости вычислений:)

А помоему уже обганяет; -) shootout.alioth.debian.org/...4/benchmark.php test=all& lang=java& lang2=ifc& box=1

тому що plain С не векторизує код

А можно поподробнее как SciPy (NumPy?) векторизирует код?

Відповісти
Підтримати
anonymous 13.11.2009 22:20
> По моему мнению питон не подходит для реализации вычислительных
> задач как и любой другой высокоуровневый и при этом интерпретируемый
> язык по одной причине: скорость выполнения программы уж очень мала.
Це не завжди так.
Наприклад, якщо рівняння можна виразити в матричному вигляді, то лібою SciPy його можна
рахувати швидше ніж на plain С (тому що plain С не векторизує код)
Якщо на С заюзати ліби типу BLAS, то швидкість програми зрівняється, але на Пітоні реально
результат буде швидше, тому що розробити програму на Пітоні можна швидше
(парсання вхідних даних і робота з динамічноми структурами даних в Пітоні простіша)
Та й не всі обчислювальні задачі є критичними по швидкості.
Буває що критичний час розробки, а прогон програми і так часу багато не займає.
> Другое дело, что питон можно использовать в качестве языка для
> создания моделей исекственного интеллекта. Там как не странно
> не нужно большой скорости вычислений
Справа не тільки в тому, що не потрібна велика швидкість.
Зараз є багато задач, де вхідні дані це не числа, а наприклад текст.
В цьому випадку більшість часу затрачається у внутрішніх лібах типу регекспів чи менедження динамічних списків.
І тоді швидкість інтерпретованої мови практично така ж, як і компільованої.

А зручність роботи може бути значно більша.

Відповісти
Підтримати
anonymous 13.11.2009 22:17
crypto5, эта тема закрылась из-за того, что в ней разгулялся тролль-анонимус. Я подозреваю, что утащить эту ветку в бан и было его изначальным намерением. Стыд мне и срам за то, что поддался на провокации мерзавца. *посылает луч диареи*
Теперь по теме. Огромное количество либ, не панацея. Вспоминается апория Зенона на тему кучи. Имхо, Core libs должны планироваться, проектироваться и создаваться централизованно. Чтобы не было ни дупликации, ни пробелов. Но сетевые либы на С и FORTRAN начали формироваться ещё тогда, когда Интернета в современном понимании не существовало, почитайте книжку Марпла, например, которую я хотел продать в одном из ранних топиков. Да, первым побуждением при составлении чисто вычислительной программы часто бывает полезть в сетевые репозитории на С и FORTRAN, хотя бы затем, чтобы посмотреть код и в случае необходимости переписать его на другом языке; специфика деятельности такова, что широко используется параллельное программирование, кстати, именно для Molecular Modelling (drug discovery), поэтому иногда приходится писать на специальном расширении С, приспособленном к параллельным вычислениям — Сm*. Я уже как-то упоминал этот язык.
Всё тут зависит от личных пристрастий. В МАИ, например, по сведениям инсайдеров, никто вообще не хочет слышать о программировании не на FORTRAN.
Python хорошо подходит для переписывания известных медленных мест, обычно это обработка больших масивов данных на С. Ещё полезно то, что его можно использовать, например, внутри LaTeX.
На сановских блогах утверждают, что JVM сейчас подобрались к фортрану по скорости вычислений:): mrgreen:
Для разработки численных моделей некоторые знакомые в Москве использовали FORTRAN в течение пятнадцати лет, не съезжая с 80-го стандарта (!). А теперь делают так: формулировка задачи и обработка/визуализация результатов реализуется на PYTHON, а все вычислительные алгоритмы на С++. *ОМГ* Иногда портируют коды через f2c:) ^_^

Еще в качестве замены фортрану и питону предлагается Fortress. Там можно даже символы UNICODE использовать для сумм, произведений, интегралов и всё такое прочее, но с б-гомерзким MATHCAD:) он не имеет ничего общего:)

Відповісти
Підтримати
anonymous 13.11.2009 22:04
> утверждается что SciPy самая крутая мат. либа из бесплатных
Я взагалі-то мав на увазі трохи інше.
Що якщо мені покажуть функціональний аналог SciPy на іншій мові, то є зміст продовжувати розмову і розглядати інші питання:)
SciPy — це набір базового функціоналу типу матричного множення чи чисельного інтегрування.
Якщо в певної мови нема навіть цього, то про інше і говорити нема чого.
А якщо говорити про інше:
Для прикладу список Пітоновських бібліотек
www.scipy.org/...opical_Software
Там є групування по різних темах, можна для порівняння вибрати будь-яку
Мені наприклад було б цікаво порівняти розділ «Molecular modeling».
(Я сам цим не займаюсь, просто цікаво).
Про швидкість розробки — до того як я почав писати на Пітоні, найшвидшою мовою для розробки я вважав Делфі.
Але практика показала, що як правило на Пітоні набагато швидше.
Типові мої програми невеликі (до 1000 рядків, але 1000 рядків Пітона це десь 3000 Делфі)
Основна перевага в швидкості розробки виникає через зручні структури даних та тому, що часто можна легко знайти готову лібу замість того, щоб писати її.
Правда ця різниця в основному виникає в програмах зі структурами даних, які погано виражаються в Делфі.
Але в мене майже всі такі.

Цікаво було б взнати який в кого є досвід порівняння Пітона з іншими мовами (або інших мов між собою)

Відповісти
Підтримати
anonymous 13.11.2009 21:04
По моему мнению питон не подходит для реализации вычислительных задач как и любой другой высокоуровневый и при этом интерпретируемый язык по одной причине: скорость выполнения программы уж очень мала.
Любые математические либы пишутся на С или Fortran, на втором месте паскаль, можно ещё лисп в виду простоты, а значит большой скорости работы, но это на любителя

Другое дело, что питон можно использовать в качестве языка для создания моделей исекственного интеллекта. Там как не странно не нужно большой скорости вычислений, да и для ряда вещей можно использовать уже существующие питоновские обёртки вокруг сишных либ

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись