Язык для обучения программированию

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

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

Покажи, где он может быть мне полезен?

Если Вы по той ссылке этого увидеть не смогли, то я ничем помочь не могу.

Основная идея и возможности метода тем не менее изложены по той самой ссылке.

Ок. Очень заинтригован. Посмотрим.

1. аппиляция к журналам не есть аргумент истинности и научной новизны. 2. главное не заказчик а сумма контракта. 3. как показывает опыт и отчеты национальных лабораторий США и институтов ЕС фортран жив и будет. 4. ваш алгоритм применим только для регулярных сеток и фиксированным шагом по времени. для таких процессов как НДС и гидро- газодинамика на нерегулярных сеток он ничего не дает. 5. «мелко зернистое» представление данных в классах С++ проигрывает простым массивам фортрана и С. гугл в помощь.

Конторы пишут свой софт. просто вы об этом не знаете.

1) А я к журналам и не аппелирую, это yvv просил ссылок

2) Сумма контракта в РФ очень сильно зависит от заказчика

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

4) Наш алгоритм и для адаптивно-рекурсивных сеток вполне применим, он неприменим для неявных схем. Да и задач с регулярными сетками и явными схемами более чем достаточная область применения...

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

КОнторы, к-е тратят огромные деньги (у которых они есть) сами софт не пишут, работают на покупном.

Ех..

http://gmao.gsfc.nasa.gov/

http://www.gfdl.noaa.gov/

http://www.cesm.ucar.edu/models/ccsm4.0/

http://www.lanl.gov/

Пишут таки софт, поскольку купить негде. Почти весь софт на фортране кстати. Что характерно, софт в открытом доступе (зарегестрироваться надо). Можешь скачать, посмотреть, сделать лучше, и утереть им всем сопли. Слабо?

Конторы пишут свой софт. просто вы об этом не знаете.

О да, роснефть напр пишет... а Вы знаете как она это делает?

2) ваши суммы по контрактам? :) 3) Фортран дает максимальную производительномть (больше наверно только чистый ассемблер) для всех типов численных расчетов :) 4) вы похоже просто программист. поэтому такие общие рассуждения о предметной области. адаптивные сетки как раз продвинутый вариант регулярных. не забываей про тип ДУ и критерий устойчивости :) 5) навность. простые эксперименты SoA AoS. :)

я знаю кто для них пишет :)

ну не весь софт у LANL на фортране :) есть и С и С++ и даже python с java

5) незабываем про кэш и про выравнивание данных :)

Я работал с РАО ЕЭС, там всё очень серьёзно было и с софтом и с тех. документацией, но.... вниз, разработчикам и техписам падали гроши, тем не менее качество было приемлемое, это на 2005-2007 годы, дальше не скажу, не знаю.

Щас у нас аспирант защищается по моделированию у-й максвелла, он уже давно утер и нос и все остальное в плане производительности. В плане интерфейса... тут конкурировать сложно, у нас нет таких возможностей как у буржуев.

ну не весь софт у LANL на фортране :) есть и С и С++ и даже python с java

Нет, не весь. И в остальных конторах тоже. Но тот который я использую, он на фортране. Универсального языка программирования нет, к сожалению.

я знаю кто для них пишет :)

Вот я например. Но до меня очень длинная цепочка, и очень много теряется... так что это все несерьезно.

Во-во. И так везде к сожалению.

Там выше ссылка - и задачи перечислены, и публикации, в т.ч. в реферируемых журналах (далеко не полный список)

Беда в том, что те публикации на русском, как следствие – никому про них не известно. Напишите в известный (англоязычный, естественно) журнал с высоким impact factor.

Не будет никто ничего отваливать.

В России – не будет. Но если засветитесь на западе – то будут, если метод действительно настолько хорош.

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

5) есть у Intel пара отчетов где они описывают эксперименты с разными представлениями данных для эффективной векторизации вычислений - победил SoA ( 1-структура с N-массивами внутри). для GPU также хорошо. так что привет Фортран и С. С++ с классами проигрывает Фортрану/С 2-3 раза. Intel VTune в помощь если неверишь.

5) незабываем про кэш и про выравнивание данных :)

Вы не поверите... именно от кэша идет требование локальности, и именно поэтому обычные массивы и сливают;-)

аспирант защищается по моделированию у-й максвелла

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

фишка их алгоритма в фиксированном шаге по времени. он одинаков по всем шагам по времени. скорость света ведь константа:). для физических процессов НДС и газо-гидродинамики он неэффективен. слишком малый шаг по куранту будет :)

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

Пока нет. Но я об этом думаю, как раз в целях рекламы. Но тут есть проблемы - напр. код требует некоторой нетривиальной настройки для конкретного проца. А вообще нам менеджера остро нехватает;-)

а ведь в кэше несколько строк :) и все необходимые кусочки разных массивом там хорошо соседствуют.

фишка их алгоритма в фиксированном шаге по времени.

шаг может дробится вместе с сеткой. Для ГД - Вы не представляете какой профит дает LRnLA (точнее насколько хреново считают обычные алгоритмы).

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

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

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

GPU - там отдельная история и специфическая структура данных. К GPU мы пока только подбираемся.

ведь в кэше несколько строк :) и все необходимые кусочки разных массивом там хорошо соседствуют.

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

ненадо сравнивать регулярную сетку и нерегулярную :) ненадо сравнивать кол-во тактов на ячейку для разных физ.процессов. ЭМ сливает ГД, а ГД сливает НДС по сложности арифметики на 1 ячейку :)

А начать с большого шага и подробить его в нужных местах вместе сеткой слабо? Хватит уже троллить.

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

как вы далеки от реальных высокопроизодительных научных и не очень расчетов.

ненадо сравнивать кол-во тактов на ячейку для разных физ.процессов. ЭМ сливает ГД, а ГД сливает НДС по сложности арифметики на 1 ячейку :)

Я такого не предлагал.

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

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

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

я реализовал НДС для Фортрана на type, на массивах. на С++ с классами и на С с структурами. я знаю ответ. у вас же есть только реализация на кодогенерации Python + C++.

как вы далеки от реальных высокопроизодительных научных и не очень расчетов.

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

незабывай в регулярке только 1 тип ячеек (прямоугольник либо шестигранник). в нерегулярке их много - тетраэдры, пирамиды, призмы,.. 1-го порядка, 2-го порядка. в методе КЭ разные виды аппроксимации по пространству. поэтому сетка существенно разная по типу ячеек и сложности расчетов.

я реализовал НДС для Фортрана на type, на массивах. на С++ с классами и на С с структурами. я знаю ответ. у вас же есть только реализация на кодогенерации Python + C++.

Ооооо... и сверхускорение наверное получали, да?;-) А что есть НДС?

да. и Максвелл и НЛС и ГД у нас лучше.

напряжено-деформированное состояния , прочность по простому

незабывай про разные процессоры и возможности разных компиляторов в плане поддержки векторизованных вычислений и предвычислений

Я за нерегулярку и не говорю ничего и даже не собираюсь. Задач с регулярными сетками выше крыши. Про риальные расчеты - допиливаю вот комбайн, для конечного юзера. Уже чисто инженерная задача - поточный счет синтетических сейсмограмм. 10^9 ячеек, 4x10^3 шагов по времени, одна старенькая персоналка считает 20 часов.

цена по контракту?

GPU - там отдельная история и специфическая структура данных. К GPU мы пока только подбираемся.

Вы, ребята, сильно запаздываете. В NASA целый кластер не GPU сделали в прошлом году. Считают модели высокого разрешения, которые могут моделировать штормы и ураганы. Давай свой алгоритм для pc, будешь героем во веки веков.

да. и Максвелл и НЛС и ГД у нас лучше.

НДС и ГД мы никогда и не занимались. А вот про максвелла... об этом можно где то почитать? Число тактов на ячейку на шаг на ядро назвать можете? Для задачи размером в 10^9 ячеек скажем. Пусть с векторизацией, это ес-но учитывается.

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

Разработки софта? Это закрытая информация (смеяцца будете).

какой почитать, ты же сказал что допуска нет:)

представь себе что разработчики софта сами считают - для заказчика так дешевле, не надо нанимать и обучать сотрудников

У нас каждую неделю про GPU кто то что то рассказывает на семинарах... мы пока на PC от них не отстаем, поверьте. Тем более, что по оценкам автора LRnLA GPU для 3D задач не особо эффективны... для 2D да. Подробности там же;-)

Пока нет. Но я об этом думаю, как раз в целях рекламы.

Давай. В целях рекламы. Сделай модель мелкой воды для океана. Это для студента задача, которую он сделает за неделю. Покажи, что она работает на 2 порядка быстрее, чем Cane-Zebiak модель (эти извращенцы фортран 77 использовали 30 лет назад). Никаких кластеров не надо, всё на pc считается. Результаты, в студию, пожалуйста.