ЯП для физики высоких энергий

[vlad]

По мотивам: http://forum.oberoncore.ru/viewtopic.php?f=89&t=3986

С С++ все понятно - это инструмент для специалиста и для специальных областей.
С фортраном тоже все понятно - морально устарел до безобразия.
И даже с КП все понятно - info21 нашел с ним свое счастье и кто-то еще, возможно, найдет.

А вот если для мэйнстрима в физике - какой современный ЯП потянет? Я бы обозначил следующие критерии:
- высокая производительность
- масштабируемость
- независимость от платформы
- достаточная гибкость (на уровне ЯП общего назначения)
- легкость обучения

Я бы предложил джаву (с кучей оговорок, конечно). Есть другие менения?

[valexey]

Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.

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

Было несколько попыток разработать новый язык для подобных применений (и они до сих пор есть), их развивали и развивают всякие IBM и подобные. Пока ничего не вышло.

PS. А чем так плох современный фортран кроме названия?

[vlad]

Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.

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

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

Это все понятно. И это можно учесть в виде "интероперабельности с фортраном" и т.п.

PS. А чем так плох современный фортран кроме названия?

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

[valexey]

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

Так: http://fortranwiki.org/fortran/show/gen_list

[valexey]

Ну и до кучи: http://fortranwiki.org/fortran/show/Generic+programming

[valexey]

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

Сергей добивается скорости шагнув на уровень ниже, то применяя обедненный Си :-) Я не уверен что визикам поголовно такое стоит давать в руки :-) А уж как он с GC борется… От наглядности (а следовательно и надежности) программы мало что остается. Это уровнем ниже чем даже просто Си.

[vlad]

Так: http://fortranwiki.org/fortran/show/gen_list

И чего, не страшно???

[valexey]

Так: http://fortranwiki.org/fortran/show/gen_list

И чего, не страшно???

Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.

[vlad]

Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.

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

[valexey]

Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.

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

Реализация плюсатого шаблона из stl'я списка оного двусвязного, тоже знаешь ли не мало букафф содержит :-) Причем стиль реализации stl'я даже у меня периодически рвотные позвывы вызывает.

Если по теме, то возможно какая-нибудь Ада была бы хорошим вариантом.

[vlad]

Реализация плюсатого шаблона из stl'я списка оного двусвязного, тоже знаешь ли не мало букафф содержит :-)

Ну на самом деле для односвзяного списка, даже шаблонного, букв много не надо. Особенно если не претендовать на роль стандартной либы (STL).

Если по теме, то возможно какая-нибудь Ада была бы хорошим вариантом.

Да, про аду я как-то забыл. Может.

[valexey]

Кстати, а вот доказательство того, что "физикам-профессионалам" нельзя доверять выбор языка для высокопроизводительных физических вычислений:
http://forum.oberoncore.ru/viewtopic.php?f=27&t=3987

Есть любители сравнивать простенькие циклы, записав их на Шарпе, в котором -- ко всему прочему -- нет ни удобного LOOP-EXIT, ни многоветочного IF.
Даже если там есть оптимизация, она, надо ожидать, не настроена на распознавание этих управляющих структур.
Из чего следует, что в генерируемом коде вероятен оверхед.

Кстати: процессор может пред-вычислять две ветки одного IF-а, но как он справится с двумя вложенными IF-ами?

Меня здесь не интересует разница между алгоритмами, разными по идее (как простой поиск и Бойер-Мур). Чисто вопросы оптимизации низкого уровня.

Кто-нить может прокомментировать?

[info21]

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

А вот тот факт, что Вы назвали это "доказательством", -- сам по себе есть доказательство того, что Вы не понимаете, что такое доказательство.

[Peter Almazov]

Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.

А чем, конкретно, плохо подходит?

[Peter Almazov]

Даже, более конкретно вопрос - чем плох C#, используемый как FORmula TRANslator?
Чувствую, что где-то есть засада, но не пойму где.