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

[macroevolution]

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

Comments

[agalakhov.livejournal.com]

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

К тормозам Питона GC отношения вообще не имеет. Все дело в том, что РЕФЕРЕНСНАЯ (и только референсная!!!) реализация Питона - так называемый CPython - это чистый интерпретатор. В нем нет JIT совсем-совсем. Поэтому он, как все чистые интерпретаторы, очень медленный: ему каждую переменную приходится искать в памяти ПО ИМЕНИ, в худшем случае за O(log(N)). К другим реализациям питона это не относится. В частности, PyPy - это JIT, и на тестах арифметики он по производительности ПРЕВОСХОДИТ Java, иногда процентов на двадцать. Во многом именно за счет того, что счет ссылок, в отличие от GC, поддается частичному развертыванию на compile-time (см., например, Ахо, Сети, Ульман, "Компиляторы: принципы, технологии, инструменты", главы 7 и 12 по 2-му изданию).

Что касается NumPy для вычислений, то NumPy даже в CPython работает с максимальной возможной скоростью, ибо написан на Си, местами с оптимизацией на ассемблере. Он быстрее даже фортрана.

[pphantom.livejournal.com]

А можно увидеть пример ситуации, когда NumPy обгоняет Фортран?

[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-битный. Впрочем, с генерацией этих инструкций есть проблемы даже в Си. Не все компиляторы умеют сводить код к ним. (Это вопрос халтуры при написании компиляторов, а не теории и возможностей - алгоритмы давно существуют).

[agalakhov.livejournal.com]

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

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

[pphantom.livejournal.com]

С первым абзацем можно согласиться (почти) полностью, а вот со вторым... Как-то в обычной жизни картина выглядит так: если писать код без внимательного отслеживания оптимизации, то Фортран раза в полтора-два обгоняет Си, все варианты Питона теряются где-то вдали. Действительно аккуратное написание кода на Си позволяет догнать (но не перегнать) Фортран (правда, ценой существенно больших усилий программиста), а все варианты Питона остаются примерно там же, где и ранее.

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

[agalakhov.livejournal.com]

Если программист пишет код на СИ без внимательного отслеживания оптимизации, то его надо увольнять. В 21-м веке для некритичного по скорости кода существуют более безопасные и удобные языки. Код на Си теперь по определению критичен по скорости.

Более того, начиная со стандарта C99 (именно стандарта!) это больше неверно. Стандарты C99 и особенно C11 разрешают компилятору очень сильно отклоняться от написанного программистом, если такое отклонение не запрещено явно. (strict aliasing rules, например). Вплоть до перестановки местами полей в структурах и засовывания таких полей в регистры, если на них не берется указатель. (Демонстрация: int func() { int x[1000000]; x[5] = 7; return x[5]; }, скомпилировать gcc -O2 -S и удивиться). В фортране подобные вольности запрещены стандартом. Поэтому написанный БЕЗ ОШИБОК (именно без ошибок, без глупых попыток "оптимизации" без понимания сути) код на Си, скорее всего, соптимизируется очень хорошо. Оптимизатору тут не надо помогать, ему достаточно не мешать. Существенно тут то, что оптимизатор Си может легко задействовать суперскалярные инструкции современных процессоров, а оптимизатор Фортрана почти никогда не может (хотя бы потому, что они не всегда точно соответствуют IEEE-арифметике).

Библиотека numpy - НЕ ФОРТРАНОВСКАЯ. Она почти полностью на Си написана.

[pphantom.livejournal.com]

Это если программист. На практике вычислительным программированием сейчас редко занимаются те, у кого программирование - основная профессия, а не "сопутствующий навык".

Да, такой источник оптимизации существует. Но срабатывает это все же достаточно редко: тот же приведенный пример явно не из реальной жизни. И, кстати, где в стандарте Фортрана находится запрет на "подобные вольности"? Например, в 2003-м.

[agalakhov.livejournal.com]

Приведенный пример почти из реальной жизни, только он характерен не для C, а для C++. Там за счет шаблонов очень часто порождается лишний код - временные объекты и ссылки, бессмысленные копирования и т.д. Раньше из-за этого C++ был медленным, и это породило миф, что C++ медленнее C. Это давно уже не так - современные компиляторы вырезают такой код так же эффективно, как и порождают, особенно если используется STL-библиотека с поддержкой C++11 (конкретно - move constructor). У меня есть примеры кода, которые из 100-200 строк сворачиваются в 1-2 машинных команды. (Зачем так писать? Затем, что это нужно для гибкости - изменение всего одной строчки приводит к генерации совсем другого кода. Это способ решения задач в условиях почти полного отсутствия техзадания - "сделаем лего, а потом из лего быстренько соберем решение").

Современный Си оптимизирует вычислительное программирование не хуже, чем Фортран. Раньше была проблема, что написание указателя автоматически означало, что переменная честно ляжет в память и будет честно взят указатель. Сейчас не так, сейчас компилятор лишние указатели подавляет. И даже лишние if умеет на арифметику заменять. Поэтому код на си и код на фортране скорее всего скомпилируются просто в идентичный машинный код, даже если их пишет человек с "сопутствующим навыком". Главное, чтобы этот человек не пытался "умничать" и использовать всякие "оптимизации", о которых прочитал в учебнике по Си 1989 года издания. Вот этим реально можно оптимизатор раком поставить. Например, написать malloc() вместо простого int x[100], побоявшись, что 100 элементов - это много. (Люди добрые, да современный стек массив из миллиона элементов скушает и не подавится!) Вообще, чем проще и примитивнее написана программа, тем легче оптимизатору ее понимать.

Гадости из стандарта фортрана 2003 - это, например, параграф 6.2.2.2 "Array element order", который зачем-то регламентирует расположение элементов массива в памяти. Это имеет смысл только при грязном касте через передачу в процедуру не того типа или через EQUIVALENCE. Второе имело смысл только во времена БЭСМ, первое использовалось для самодельных аллокаторов в Fortran-77 и утратило смысл в Fortran-90. Но фактически этот параграф запрещает компилятору раскладывать короткие массивы по регистрам. А значит, в программе, в которой много трехмерных векторов и скалярных произведений, компилятор, не нарушая стандарта, не сможет распихать эти массивы по регистрам и использовать инструкции SSE. Вместо того, чтобы делать скалярное произведение одной инструкцией, он сделает честный цикл из перемножений и сложений. Чтобы уж совсем забить гвоздь в крышку гроба SSE, есть еще вот такой параграф: 16.4.3.1 (7) A nonpointer array occupies a sequence of contiguous storage sequences, one for each array element, in array element order. Ну а весь параграф 16.4.3.3 "Association of scalar data objects" - это вообще гадость, не имеющая аналогов ни в каких современных языках программирования. Как раз та штука, с которой современная теория компиляторов вообще справляться не умеет.

[pphantom.livejournal.com]

Спасибо, убедительно.

[agalakhov.livejournal.com]

Вам спасибо :) Когда такие вещи разъясняешь, сам лучше начинаешь понимать, как оно устроено. В свое время именно подобные разговоры заставили меня всерьез заняться теорией компиляторов, хотя к основной моей работе это отношения не имеет.

[agalakhov.livejournal.com]

Наверное, тут надо пояснить, почему все перечисленное так плохо для оптимизации. По теории, перед оптимизацией программу надо представить в так называемом виде "static single assignment". То есть считать, что каждая переменная присваивается ровно один раз, а каждое новое присваивание порождает новую переменную (старая после этого никуда не девается, просто ее больше не используют). Полученная программа будет иметь вид набора инструкций z=f(x,y), из которых потом строится граф потоков данных. Потом этот граф упрощают эквивалентными преобразованиями.

Если регламентировано расположение переменных в памяти, то присваивание представляется как две операции. Примерно так:
var tmp = x;
save(&y, tmp);
Операции "save" можно переставлять по коду с места на место, но эквивалентных преобразований, уничтожающих такую инструкцию, не существует. (Компилятор может, однако, породить пару save-load из других инструкций, если ему не хватает регистров.) Поэтому при разработке современных языков стараются свести появление таких штук к минимуму. В Си есть ровно два оператора, порождающих явный save: это volatile и это вызов внешней библиотечной функции. Вызовы inline и static не порождают save. В Фортране save по стандарту порождается каждым оператором создания массива.

Этим, кстати, очень просто объясняется, как же gcc "магически" уничтожил массив из 1000000 элементов. На этапе компиляции он рассматривался не как массив, а как 1000000 отдельных переменных, для которых не было регламентировано расположение в памяти. Из них 999999 - переменные, которые никогда не читались. Во всем коде была максимум одна операция save, порожденная return из функции (если нестатическую функцию не вызывают, она рассматривается как библиотечная для внешнего использования), и эквивалентные преобразования свернули весь граф потоков данных в две вершины: создать 7 и записать 7 в ответ. Эти две вершины, в свою очередь, порождают одну машинную инструкцию - записать 7 в регистр.