Python в научных вычислениях

Я в курсе, что основная проблема в алгоритмах, но жизнь от этого проще не становится.

CUDA

Проприетарен, производительность вычислений с типом double, а именно этот тип необходим в подавляющем большинстве численных задач, где-то в 30 раз хуже производительности с типом float. Так что требуется спецоборудование от NVidia, обыкновенные массовые видеокарты дают на double примерно ту же производительность что и современные многоядерные обычные CPU.

Это да, но чтобы заиметь домашний суперкалькулятор за разумные деньги здесь и сейчас - это решение.

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

И да есть теслы с двойной точностью.

Aparapi тогда уж.

Ну и да, выбор оберток под cuda/opencl под яву приличный.

Зарезанные даблы это проблема железа и маркетинга. ЕМНИП у потребительских амдшек в этом плане все лучше, чем у потребительских нвидий - надо же как-то теслы продавать.

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

Так вот и нет, за разумные деньги решением будет обыкновенный многоядерный CPU, поскольку спецкарты от NVidia дающие значительное преимущество перед таким CPU с типом double стоят на порядок больше этого самого обычного многоядерного CPU, а приемлемые по цене массовые видеокарты от NVidia дают примерно ту же производительность с типом double что и CPU, поэтому и удобнее выбрать CPU.

CUDA

This! Остальное пыль и не смешно.

OpenCL не взлетел?

Можно считать, что не взлетел. Поддержка приложениями и экосистема у куды более развита.

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

Есть класс задач (диффуры численно решать, например), где требуется большое число ядер и на сегодня 1000 ядер теслы средней паршивости делает любой многоядерный CPU сравнимой стоимости (разрыв меньше чем в пару порядков, но где-то близко) при правильной (sic!) программной реализации алгоритмов естественно.

wxMaxima

Бя

Лучше взять emacs + imaxima, наярить slime:

(require 'asdf)

(progn
  (flet ((%gpath (p)
           (push (merge-pathnames p
                                  *default-pathname-defaults*)
                 asdf:*central-registry*))) 
    (let ((*default-pathname-defaults*
            #P"/usr/share/sbcl-source/contrib/"))
      (map nil #'%gpath
           '(#P"sb-cltl2/"
             #P"sb-introspect/")))
    (let ((*default-pathname-defaults* (user-homedir-pathname)))
      (%gpath #P".emacs.d/site-lisp/slime/")
      (asdf:initialize-output-translations
       `(:output-translations (t ,(merge-pathnames #P".cache/maxima/lisp/"))
         :ignore-inherited-configuration)))) 

  (asdf:oos 'asdf:load-op :swank))

(swank:create-server :dont-close nil
                     :port 23146)
 
(to-maxima)

Далее M-x slime-connect <RET> 127.0.0.1 <RET> 23146 <RET>

А потом после вот таких лекций появляются CGH на жабе (на жабе, едрить! CGH!!!!) или алгоритмы CAM на пистоне.

Не, понятно, что на разок для теоретика сойдёт, чтоб за 3 часа работы скрипта таки получить proof-of-concept, но вообще за такое, конечно, надо розгами пороть. Да и вообще - аццкий матан теоретик осилил, а какой-нибудь ЯП c нормальной скоростью работы он не может. Сразу сомнения появляются в способности теоретика и в матан.

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

теслы средней паршивости делает любой многоядерный CPU сравнимой стоимости

Вообще-то теслы стоят как минимум на порядок (в 10 раз) больше чем многоядерные CPU т.е несколько сотен тысяч рублей, ничего удивительного что они эффективнее при такой то цене. Бюджетные же видеокарты, примерно одной ценовой категории с многоядерными CPU, не имеют преимущества в счёте перед CPU на типе double, а преимущество есть только на типе float, который фактически в численных вычислениях никто не использует.

Правильный ответ важнее быстрого. Взяв «какой-нибудь ЯП c нормальной скоростью работы» вероятность напороться на гейзенбаги и прочие прелести повышается в разы.

Я вообще-то с Intel Phi сравнивал, а 8 ядер против 1000 — это ниочём.

Вообще-то речь была про это:

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

Бюджетные же видеокарты, примерно одной ценовой категории с многоядерными CPU, не имеют преимущества в счёте перед CPU на типе double,...

Писал свою очень кривую реализацию БПФ на OpenCL, она работала на нормальной игровой видеокарте чуть быстрее, чем fftw на четырехъядерном процессоре. Только моя программа использовала double-double арифметику. Что я делаю не так?

Ты в курсе, что есть numpy? Что кроме аццкого матана есть довольно простые и стандартные задачи, которые реализованы в написанных на C и оптимизированных модулях питона? О каких проблемах со скоростью работы идет речь? Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить. Но так же никто не делает.

Во-первых, непонятно что вы сравниваете? БПФ с ДПФ? Ну так на то БПФ и называется быстрым что требует меньшего числа операций.

Во-вторых, выше утверждалось что восьмиядерный процессор должен быть по производительности примерно на одном уровне с нормальной игровой картой на типе double, а поскольку они из одного ценового диапазона то выбирать GPU вместо CPU нет смысла.

Во-первых, непонятно что вы сравниваете? БПФ с ДПФ?

Скажи что ты шутишь. Какой алгоритм кроме БПФ имеет смысл обсуждать?

Во-вторых, выше утверждалось что восьмиядерный процессор

Это AMD теперь выпускает восьмиядерники? Я бы купил устройство с 16 нормальными ядрами по цене видеокарты, может быть и OpenCL не пришлось бы учить.

Приятель писал с использованем Numpy\scipy?

Правильный ответ важнее быстрого.

Вообще-то ответ должен быть и правильным и быстрым. Брать и выдавать взаимодополняющие условия за взаимоисключаеющие - это дешёвая демагогия.

А можно узнать альтернативы, которые не сорта говна?

Ты в курсе, что есть numpy? Что кроме аццкого матана есть довольно простые и стандартные задачи, которые реализованы в написанных на C и оптимизированных модулях питона?

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

О каких проблемах со скоростью работы идет речь? Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить.

А представь себе задачку раз так в 100500 сложнее чем FFT. И библиотечек кем-то написанных нет и быть не может, потому как никто таких задач ещё не решал.

Но так же никто не делает.

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

Правильный ответ важнее быстрого.

Каким боком питон к получению правильного ответа? Какие ваши доказательства? Понимаю еще Haskell или Idris.

Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить. Но так же никто не делает.

Но так же никто не делает.

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

Каким боком питон к получению правильного ответа? Какие ваши доказательства? Понимаю еще Haskell или Idris.

А что, только программы на Haskell и Idris могут давать правильный ответ? %)

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

Какая нафиг разница? Что то, что другое неизбежно приводит к аццким тормозам в руках нескушённого юзера, непостигшего тонкости ужора ресурсов используемым язычком и неспособного написать на сях шуструю библиотечку к используемому язычку. Вне зависимости от всяких там JIT и прочих костылей.

Пара килобаксов для суперкалькулятора это разве не оно?

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

Больше в единицу времени происходит итераций вида «покодил»-«запустил»-«прослезился». Правильная комбинация символов находится в значительной степени экспериментальным путём при тестировании на известных данных. Помогают конечно ещё всякого рода кукбуки, коих у Python уже вполне достаточно.

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

Какая нафиг разница?

А, окей.

неспособного написать на сях шуструю библиотечку

Ты не поверишь, но люди избегают писать на Си, потому что он убогий и устаревший, а не потому, что на что-то там неспособны.

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

Ну то есть в этом разницы между Haskell и Python нет.

Не благодари

Да я и не собирался.

Фи, так приземленно думать. «покодил»-«запустил»-«прослезился» — действительно, это для любого языка справедливо. Зачем же выбирать лучший? Хей, бери тот, у кого батареек больше!

Подходы к программированию можно разделить на операционный и аксиоматический. По мне, второй подход гораздо эффективнее, и больше ложится на функциональные языки. А вообще, отсылаю к Дейкстре как авторитету: http://www.beroal.in.ua/article/dijkstra/ewd1012.html

Ты не поверишь, но люди избегают писать на Си, потому что он убогий и устаревший, а не потому, что на что-то там неспособны.

Ну да, то-то на убогом и устаревшем написано 99% всего софта, а на современных и развитых - аж полторы поделки. Отличненько, чо.

люди избегают писать на Си, потому что он убогий и устаревший, а не потому, что на что-то там неспособны.

Ну да, то-то на убогом и устаревшем написано 99% всего софта

Давай 146% - тоже чушь, но хоть с намеком на юмор.

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

Ну то есть в этом разницы между Haskell и Python нет.

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

На чём там пистон c жабой и прочими «современными языками» написаны? Ась?

«Вероятность, отличная от нуля» может быть на 0.01, так и 0.99, и если у двух языков они разные, то отсюда никоим образом не следуют отсутствие разницы

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

Вам бы логику подучить. Хотя не... для программиста на Питоне это ненужный, и скорее даже вредный навык.

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

На чём там пистон c жабой и прочими «современными языками» написаны? Ась?

У меня сейчас запущены Eclipse, Firefox и Claws. На Си из них написан только Claws, так что не рассказывай мне о 99%.

И кстати, Java VM написана на Си++

Можно примеры крупных или значимых систем на программировании с «аксиоматическом» подходом?

Фи, так приземленно думать. «покодил»-«запустил»-«прослезился» — действительно, это для любого языка справедливо. Зачем же выбирать лучший? Хей, бери тот, у кого батареек больше!

Впервые наблюдаю столь продолжительное бомболейо...

Про вероятности там не говорилось, да ты и был достаточно осторожен, чтобы не называйть чисел.

Да, я проявил осторожность, а вот ты нет — сделав из моего посыла вывод о равнозначности любых двух языков (что заведомо неверно), а потом подставил вместо них Haskell и Python. Таким приблизительно образом могла выглядеть логическая цепочка, но, возможно, что ты не строил логически строгую цепочку. В любом случае, не хочется продолжать этот спор и лезть в бутылку. Тем более, я не считаю Haskell лучше Python, это дело вкуса. Надеюсь, не обидел.

я проявил осторожность, а вот ты нет

Да неужели? Посмотрим:

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

Ну то есть в этом разницы между Haskell и Python нет.

Я выполню текстовую подстановку, если ты не можешь: «Программа и на Python, и на Haskell может дать правильный ответ, и в этом разницы между Python и Haskell нет». ХЗ, с какой радости ты стал уличать меня в незнании ТВ.

Надеюсь, не обидел.

Нет, удивил.

По-моему, ты плохо улавливаешь смысл прочитанного. Если я скажу, что математика строже других дисциплин, мне в подтверждение нужно приводить практически значимый и при этом математически строгий результат? Очевидно, что нет. Зато даже школьнику очевидно, что нельзя в космос запустить ракету без строгих математических выкладок.

Вот блин, совсем фигню я написал. Пошел убиваться головой апстену, или что сейчас модно?

А что, нынче С++ перестал быть языком компилируемым в команды процессора упакованные в executable формат целевой системы и стал жрать память и процессор как не в себя всякими лишними прослойками и костылями для исправления кривизны рук программиста? А вот фортран ещё есть, например. Или ObjC какой.

И, кстати, что интересно, из списка «Eclipse, Firefox и Claws» самый тормозной (с точки зрения интерфейса) это Eclipse, по понятным причинам, потом идёт Firefox, из-за сраного XUL, а самый быстрый внезапно Claws.

Даже в такой, казалось бы несложной вещи как логика работы гуя (даже не сам гуй, в смысле отрисовки примитивов, заметь), все эти «современные и удобные» резко сливают компилируемым языкам без всяких сраных JIT'ов и прочих vm.

Ну и Eclipse - это типа шутка такая, выдавать его за софт? Эту хрень хоть один человек на Земле станет использовать по собственной воле, а не по принуждению?

А что, нынче С++ перестал быть [...]

Си++ перестал быть убогим устаревшим Си.

а самый быстрый внезапно Claws.

И самый убогий. Если бы у меня была более-менее интенсивная переписка, я бы давно свалил... да на тот же Thunderbird.

Ну и Eclipse - это типа шутка такая, выдавать его за софт?

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Эту хрень хоть один человек на Земле станет использовать по собственной воле, а не по принуждению?

Зависит от уровня антижабина в крови.

Си++ перестал быть убогим устаревшим Си.

И конечно же там int a = b + c преврашается в нечто иное, нежели в сях? И вызовы функций там, видимо, внезапно обросли тоннами оверхеда вместо обычного call целевого процессора?

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Да хоть какой-нибудь KDevelop. Тупо потому что не тормозит.

Зависит от уровня антижабина в крови.

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

И конечно же там int a = b + c преврашается в нечто иное, нежели в сях?

Эээ... это такой автотроллинг? Просто для протокола: в Си++ это очень сильно зависит от типов a и b, и может включать в себя хоть матричные операции,

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Да хоть какой-нибудь KDevelop.

Те версии KDevelop, которые я пробовал, гораздо хуже понимают и Си, и Си++ (и не умеют в Python, ага %)).

Тупо потому что не тормозит.

Ну да, только тянет за собой KDE.

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

Зависит от исходных условий.