Посоветуйте язык программирования

[macroevolution]

Я всю жизнь программировал только на бейсике, на разных его версиях.  Так получилось. Когда писал кандидатскую, набралось очень много таблиц с данными (это были морфологические признаки морских ежей), и я задолбался обсчитывать их на калькуляторе. Поэтому быстренько освоил бейсик (тогда персональные компьютеры IBM только начали появляться, и к ним прилагался язык GW-Basic). Освоил - и сразу почувствовал себя человеком. С тех пор не переучивался, сейчас пишу все свои программки на VBA в MS Access. То есть в программировании я дилетант, но опытный. Программированием пользуюсь сейчас для имитационного моделирования эволюционных процессов в популяциях. Подумываю об одной новой модели, но понимаю, что на VBA она будет работать невыносимо медленно. Насколько я понимаю, программа, написанная почти на любом другом языке, компилируемом, будет работать в разы быстрее. Вопрос такой: какой из этих языков мне будет быстрее и проще всего освоить? Времени, сил и желания преодолевать трудности и вникать в программистские проблемы - не имеется. Мне бы этот язык просто скачать (можно купить, если не слишком дорого), освоить за пару-тройку дней - и вперед. Т.е. главное, чтобы он был максимально простым в освоении для того, кто знает бейсик, без всяких интеллектуальных "понтов", но работал хотя бы раз в 10 быстрее.

Comments

[agalakhov.livejournal.com]

Запросто. numpy.linalg.eig для действительно большой матрицы. Тогда питонный код будет заниматься только чтением исходных данных и выводом результата, т.е. на время работы почти не повлияет, и получится просто соревнование между компилятором Фортрана и компилятором Си. Лет десять назад победил бы фортран, но на современных компиляторах с оптимизацией под суперскалярный процессор фортран и си либо вообще равны (и генерируют почти идентичный машинный код), либо си чуть быстрее (в силу большей свободы оптимизации, которую стандарт си дает по сравнению со стандартом фортрана).

[pphantom.livejournal.com]

Это же просто вызов из LAPACK, написанной на Фортране. За счет чего произойдет обгон?

[agalakhov.livejournal.com]

Это не вызов LAPACK. Это вызов другой библиотеки, делающей то же самое. Она, скорее всего, оптимизирована немножко лучше, чем референсный LAPACK, за счет этого и выигрыш. Впрочем, фортрану тоже никто не запрещает пользоваться той же библиотекой, но это программист должен сделать вручную :)

Вообще в фортране обычно получается хорошая скорость на самих вычислениях, но плохая на вызовах функций. Соглашение вызовов фортрана более архаичное, чем си, оно фактически требует честную передачу параметров через стек и запрещает инлайн. Фортран стабильно выигрывал у Си, пока Си не умел инлайнить и подавлять лишние переменные. Соответствующие алгоритмы для Си появились где-то в середине 2000-х. Ключевой из этой серии - алгоритм LSRA - в конечном итоге породил бум на JIT-компиляторы и привел к созданию LLVM. Это алгоритм поиска оптимального размещения переменных в регистрах за O(n), а не за O(n*log(n)), вокруг него все теперь и строится. Компиляторы фортрана его тоже теперь используют, но в фортране от него проку мало, поскольку многие переменные по стандарту обязаны лежать в памяти.

[pphantom.livejournal.com]

В каком смысле "вручную"?

[agalakhov.livejournal.com]

В том, что вызов библиотеки в фортране содержится явно. Программист, а не компилятор, выбирает, какую версию библиотеки он будет использовать. Я не могу в фортране просто написать "хочу BLAS", я должен указать, какой именно BLAS и откуда его брать. Мне лично несколько раз приходилось вносить такие изменения именно в фортранный код, заменяя какой-то левый BLAS на мой ATLAS. Ускоряет, кстати, процентов на десять по моим измерениям.

В этом принципиальное отличие от "встроенных в язык" библиотечных возможностей и от "установленных в систему" библиотек. Когда я пишу import numpy в питоне или std::sort в C++, я могу рассчитывать на то, что использую наилучшую из имеющихся на данном компьютере реализаций. Если я обновлю систему, и новая версия диагонализации матриц в ней начнет использовать видеокарты через CUDA, мне для этого ничего не придется делать со своим кодом. Он просто начнет магически работать быстрее.

[pphantom.livejournal.com]

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

[agalakhov.livejournal.com]

Согласен. Но тут важно уже то, что указано в -L. В системе может быть (и скорее всего) есть несколько libblas.so, лежащих в разных местах. Впрочем, при динамической линковке это решается настройками системы. Но мне чаще встречались фортранные программы, которые тащат копию BLAS внутри себя, а не используют -lblas. И я понимаю, почему: в то недолгое время, когда я считал на суперкомпьютерах, я успел намучиться с разными странными компиляторами, которые там встречаются. Уж проще принести все с собой.

Тут есть еще одна тонкость. На современных процессорах вызов подпрограммы дорогой. И условный переход тоже дорогой. Поэтому мелкие функции вроде умножения матриц 3x3 делать библиотечными невыгодно - вызов дороже вычисления получается. Мой любимый пример - набор инструкций процессора ARM Cortex M4, дешевого, как грязь, в котором, помимо всего прочего, есть инструкции вида int64=int64+int16*int16+int16*int16 или int64=int64+int32*int32, выполняемые за один такт. Притом, что процессор так-то 32-битный. Впрочем, с генерацией этих инструкций есть проблемы даже в Си. Не все компиляторы умеют сводить код к ним. (Это вопрос халтуры при написании компиляторов, а не теории и возможностей - алгоритмы давно существуют).