У eigen, blitz++, armadillo единый синтаксис? Возможно, не помню. Единый он у всего, что является прямой реализацией LAPACK/BLAS и то с некоторыми оговорками. Опять же при условии, что постоянно с этим имеешь дело, тогда и специализированные пакеты не проблема.

Ну у них жуткий плюсовый синтаксис, местами сильно извращенный;-)

Да, конечно - у каждой библиотеки своя специфика, тут Вы правы. Ну а шо делать?

А зачем биологам плюсы? Что там за задачи, требующие экстремальной производительности?

Да уж, уровень эрудиции молодых дипломированных «экспертов» поражает воображение.

А зачем биологам плюсы? Что там за задачи, требующие экстремальной производительности? Фортран конечно проще в изучении если не делать че то эдакого…

Там есть большие объёмы данных. Например, представьте себе результаты эксперимента: 29 крыс, от каждой 4-хканальная суточная запись, частота выборки 512 Гц, 16 бит. Теперь нужно найти все эпилептические разряды, посчитать связанность, хотя бы функцию когерентности и корреляцию, лучше, нелинейную, функцию взаимной информации, всё со сдвигом (например, от -3 с до +3 с) между отведениями, сделать статистический анализ значимости.

Тут обсуждение куда-то в злостный офтопик свалилось. А тема между прочим про julialang. Мой прогноз такой: фортран она конечно не вытеснит оттуда, где он ещё остался, но всякие питоны с крестами потеснит конкретно. Потому что поделие годное и имеет больше смысла. Кидайтесь какашками, юные дарования.

Это 10Гб данных всего лишь. В общем сейчас с этим любой numpy и иже с ними справятся.

Я знаю что скажем в МРТ (томографах) сейчас очень продвинутые алгоритмы, но этим занимаются все же не биологи а приматы - биологи только ставят задачу.

Я в аспирантуре вел общую физику на биофаке. Три закона Ньютона это уже за пределами понимания… я к тому, что биология (обычная, не молекулярная и не всякая там биофизика) все же предполагает очень специфический стиль мышления. Физика/химика можно научить программировать числодробилки, у них мозги под это уже отформатированы. Биолога - я не предсатавляю как…

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

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

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

Китаец пишет насколько я понял про 23-кратное ускорение относитьельно 1 ядра. ядер в проце современном не менее 8, по факту и 32 есть в десктопных камнях.. и стоят они дешевле чем Нвидия Титан.

З.Ы. возьму CFL3D на досуге и запущу Onera. Даже интересно уложится в 740 секунд или нет.

Вот насчет крестов не уверен, но в сторону питона в нынешнем виде с нелюбовью смотрят многие люди :)

и для них данный Я.П будет полезен.

ну или Ifortran (хотя он и на питоне:))

и да, за 160 узлов по профилю надо бить. и не по рукам.

сетка 51х30х160. Это в принципе некорректно.

Мы не моделировали RAST. Но по другим проектам gpu дают по производительности выигрыш на порядок по сравнению с цпу той же стоимости. Даже для данных довольно сложной структуры. Хотя конечно многое зависит от задачи.

Кроме того, хорошо писать под gpu куда проще чем эффективно заюзать векторизацию зеона.

Ну и презентация 2012 года, за 7 лет думаю многое поменялось.

по другим проектам да. просто про RANS на GPU я уже лет примерно 10 слышу. И результаты которые остаются - в лучшем случае 0. В худшем - еще и финансовые потери в случае покупки расчетных видеокарт без понимания проблемы. И да, за такую сетку бить надо было и в 2002 году.

про RANS на GPU я уже лет примерно 10 слышу.

Ок, я спрошу у коллег. Тем более тут очередной CFD уикэнд вроде…

Смотря для каких прогнозов. Там используются весьма специфические модели.

Не настолько специфические. Божечки, похоже они еще и сферические координаты используют, про рекурсивно измельчаемые сетки на основе многогранников они похоже не слышали…

Публикации и мои ищутся плохо. Так уж замечательно эти поисковики работают.

У него достаточно редкая фамилия.

У него достаточно редкая фамилия.

Ахаха!! Мою достаточно редкую фамилию носит половина Воронежской области. Лично знаком с полными тёзками из тех краёв.

Божечки, похоже они еще и сферические координаты используют, про рекурсивно измельчаемые сетки на основе многогранников они похоже не слышали…

Эксперты по вакууму продолжают разить интеллектом. Для справки, сферические координаты давно уже не используют, хотя было время, использовали активно. Про рекурсивно измельчаемые сетки и прочие продвинутые методы CFD все знают, тут поумнее тебя люди работают. К сожалению, многие из этих методов очень сложно применить в GCM из-за масштабов модели. У нас размер сетки на порядки больше масштаба процессов, происходящих внутри. В целом адаптирование CFD методов идёт, но медленно. Это требует слишком много человеко-часов.

я правильно понимаю что есть 2 десятка процессов которые считают отдельные модели, а затем результаты этих расчетов используются на одной большой сетке?

я правильно понимаю что есть 2 десятка процессов которые считают отдельные модели, а затем результаты этих расчетов используются на одной большой сетке?

Процессов обычно 5-10тыс. Каждый считает маленький кусочек Земли каждый шаг, потом обмениваются граничными условиями. В добавок к этому может быть (а может не быть) ассимиляция данных отдельным процессом, которая есть целая наука сама по себе.

Ну уже на таком описании видно насколько это весело :) Интерполяция в CFD довольно часто весело)

Юрий, мне вот интересно - Вы мне в лицо все это рискнете повторить в тех же самых словах? Оставляя за кадром содержательную часть Ваших спитчей (которая довольно спорная) - не говоря о том что я ведь похоже постарше Вас буду, да и должность/регалий всяких научных у меня побольше… Вы не осознаете, что выдавая такое в публичном поле, даже если это ЛОР, Вы банально теряете лицо?

Ну уже на таком описании видно насколько это весело :)

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

Вы не осознаете, что выдавая такое в публичном поле, даже если это ЛОР, Вы банально теряете лицо?

Настучи модерам, мне скор снимут, если тебя это успокоит.

Юрий, мне вот интересно - Вы мне в лицо все это рискнете повторить в тех же самых словах?

Обязательно. Могу даже два раза.

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

Будете в Москве - приходите к нам на семинар.

Спасибо. Уверен, у вас там интересно. Проблема в том что работы много, жизнь короткая, а отпуск ещё короче. В Москве бываю я крайне редко, проще говоря. Меня, кстати, крайне не устраивает ситуация, что ваши прекрасные CFD методы так плохо идут в глобальные модели. Этим неоправданно мало занимаются. Был бы рад это обсудить за рюмкой чая.

Э… мы не придумываем новые CFD методы, мы (точнее коллеги) занимаемся эффективной параллелизацией. То что Вы пишете про распараллеливание это банальный domain decomposition, мы продвинулись куда дальше.

Впрочем мы ЕМНИП когда то это с Вами обсуждали - но как обычно жизнь короткая, а задач куда больше чем людей. Иногда у нас заходит разговор о мелкой воде (тем более что кто то ее даже когда то считал), я бы занялся климатом - у меня есть очень годная сферическая сетка, и надо бы ее сделать AMR. Но не в ближайший год, мне сейчас очень поперло по другой теме, а обязательств по другим проектам никто не отменял…

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

Простите если где то бы с Вами резок.

Простите если где то бы с Вами резок.

Да ладно прекрати. Приятно пообщаться было.

У нас вычматы были на mathematica. Второй курс вообще не помню, всё как в тумане.

Вы не понимаете. Вы представляете себе, сколько нужно вычислений, чтобы посчитать когерентность в окнах по всем этим данным всех каналов со всеми. А все кросскорреляции со сдвигами тоже в скользящем окне? Дело не в гигабайтах. Дело в объёме вычислений.

Или частная направленная когерентность. Там будет модель размером 4x4x200 коэффициентов, которую в окне, скажем 10 с, с перекрытием 3-5 с нужно будет построить вдоль всей реализации, затем провести с ним в окне же Z преобразование, потом найти, на какой частоте из определённого набора находится максимум, оценить, превосходит ли он заданный уровень. И так для всех крыс.

Конечно, это научные вычисления, не для индустрии.

Я понимаю что это считается не в риал-тайм (можно подождать результатов минуты или даже часы), и не на ноутбуке. Если расчеты разовые, то они отлаживаются а потом запускаются грубо говоря на ночь. NumPy какой нить сливает фортрану наверное раз в десять, зависит от задачи…

Для сравнения, у меня сейчас крутится задача по магнетикам - один расчет это полмиллиона частиц и десятки тысяч шагов и таких расчетов нужны сотни.

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

Вот это и правда на numpy ну никак не сделаешь;-)

Я понятия не имею что такое эти Ваши грамматики, но С++-11 таки гораздо удобнее в работе чем С++-98.

Хороший ответ.

Владимир

Из личного скромного опыта, вычисление кривой безье - быстрее в пять раз ‘один в один’ кода на чистом питоне, тупое добавление типов, почему-то, немного замедлило. Уровень плюс/минус pypy, chez scheme вобщем. А бенчмарки для совсем в лоб вычислительной математики, с учётом оптимизаций и параллельности - бессмысленны, тк какой-нибудь cython на фибоначи даст х50, где-то юзаются сишные либы, где-то какие-то ансейф операции, где-то зрелые компиляторы с оптимизацией уровня бог, сплошная манипуляция. Это совсем не показывает регулярную производительность языка.

Julia сама по себе хороша.

но чтобы встроить её (наработки на ней) в свой приклад, надо всё вывернуть в встать в неприличную позу.

5 копеек

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

Немного бэкграунда: Универ первые курсы Си и плюсы С кафедры пришлось самостоятельно выучить Фортран на определённом уровне так как он применялся в разработке глобальной модели океана (там куча всего Навье-Стокса, через функан, явные/неявные методы, сетки и вот это вот всё). Реализация на Fortran 90+ с использованием OpenMP MPI. Запуск всего этого дела как на институтском кластере (где прав побольше), так и на BlueGene/Lomonosov (где прав почти нет) по крайней мере так было в 2010ых.

Этакий симбиоз от мира программистского и научно-вычислительного мира.

После этого сменил область на абсолютно другую ветвь и теперь это ближе к Data Science области (sas, Python, R).

Во-первых то как серьезные люди сравнивают языки забавно смотреть) Меня ещё давно учили про Тьюринг-полные языки и хоть на брейнфаке пиши. Гораздо больший вопрос в некотором удобстве того кто пишет код (а это достаточно субъективно), так и в удобстве использования сторонних готовых пакетов.

Теперь по некоторым всплывавшим вопросам и Юлии в том числе:

1. Почему фортран до сих пор жив? Потому что в некоторых областях он был и остаётся стандартом де-факто. Переписывать все эти коды очень долго(=дорого), а прогнозы погоды получать все хотят (привет совместные модели атмосферы-океана). Многие готовые внешние библиотеки оптимизированных вычислений до сих пор под него иногда работают лучше чем под другие языки. Выпускаются закрытые/платные компиляторы, хотя gfortran и становится всё популярнее. Сможет ли Юлия «убить» фортран? Смотря о какой величине потерь мы говорим.. она не собиралась этого делать, а все «убийцы» того же Си и плюсов - забирают часть себе, но оригиналов возможно в полной мере никогда не убьют. Го,раст,жаба,name your ЯП - а си всё живы внутри юниксов, а плюсы в высоконагруженных системах. Также Фортран продолжит жить в научных кругах, но часть Юлия на себя наверняка заберёт, потому что фортран со временем учить будут всё меньше, а Юлию всё больше. Хотя до сих пор на мейнфреймах жив Кобол и даже испытывает нехватку в разработчиках для поддержки этого кода.

2. Что с пакетным менеджером? Фортран действительно из другой оперы, но та же популярность пайтона, в некоторых задачах научных вычислений себе забрала в том числе и из-за удобства подключения внешних библиотек и их использования. Потому что зачастую бывает гораздо проще оттуда вызвать методы из внешних библиотек(которые реализованы на низкоуровневых языках). И если в Юлии это реализуют в итоге на современном уровне, то это ей может сильно помочь. Потому что например заставить работать на кластере версию популярного пакета Petsc(который к слову есть под c,c++,FORTRAN и Python https://www.mcs.anl.gov/petsc/features/index.html) - это огромная боль и страдания, а уж поставить что-то своё на большие суперкомпьютеры ещё сложнее. При этом совершенно очевидно, что в больших и сложных системах необходимо пользоваться внешними высокооптимизированными готовыми реализациями, а не переизобретать велосипед(который скорее всего получится хуже), и только какие-то определенные куски или специфичные алгоритмы и подходы реализуются самостоятельно на pure-синтаксисе.

3. Замена си/плюсам? Изначально спроектированные первый под системное программирование, второй под высокооптимизированные системы с ооп - они прекрасно живут в этих областях, но могут использоваться и в других само собой. Юлию проектировали для быстрой разработки и быстрого вычисления на современных вычислительных архитектурах. Поэтому заменять никто ничего не будет, а скорее вопрос будет ли доминировать Юлия в той области, которая для неё считается основной.

4. Матлаб/октав Мало работал с ними, но у них есть свои специфичные готовые к реализации пакеты/коды - в основном с решением дифуров. И те кто исторически их использует может применять связку с Юлией. Но опять же дойдёт ли до того чтобы в Юлии набралась критическая масса реализованных подходов и будут ли новые исследования/публикации вестись в ней сказать сложно.

5. Python/R В Юлии также сейчас идёт большой уклон на популярное направление DS/ML и упомянутой выше проблеме двух языков. Когда отдельно быстро пишется быстро прототип(опять же с использованием внешних библиотек и систем Keras,tensorflow,pytorch) и последующей реализацией результатов на высокопроизводительном языке в промышленном контуре(++,#,java,etc). Сейчас все очень забито питоном и куча хайпа вокруг него, а те кто больше по статистике любят R. Юлия пытается влезть во все эти области и имеет некоторые преимущества над языками, разработанными с более старыми подходами, но конечно не является святым граалем и не лишена недостатков.

6. cfd? кто-то уже начинает делать и с Юлией (https://www.researchgate.net/publication/335398490_CFD_Julia_A_Learning_Module_Structuring_an_Introductory_Course_on_Computational_Fluid_Dynamics) (https://www.youtube.com/watch?v=wp7AYMWlPLw).

Просто она слишком молода и удастся ли ей выстрелить сказать сложно. Другие языки гораздо старше и даже пайтон с ар, не говоря про си и фортран. Поэтому говорить о том, что сейчас Юлия может серьезно и полноценно конкурировать с готовыми и давно развитыми решениями? Нет. Только как дополнительный инструмент. Но в будущем она может стать новым стандартом.

Кстати, я всё ещё жду решения на 5 строк. Ведь мужик сказал — мужик сделал. Можешь фигурные скобки убрать ради экономии места.

Приблизительно так

void sort(S& s, int k) {
    std::sort(s.begin(), s.end(), [=k](const S& a, const S& b) { return a[k] < b[k]; });
}

А как ты синтаксическое дерево построишь без порождающей грамматики и правил вывода?

Твой вопрос я прочёл. Да, распереживался, понимаешь.

Это мне переживать надо. -10 за два дня, а я просто спросила.

Ну вот наконец то правильный бенчмарк хоть кто то написал не поленился :))

https://stackoverflow.com/questions/59679662/list-of-vectors-slower-in-julia-than-r