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

[macroevolution]

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

Comments

[Роман Игнатьев (from livejournal.com)]

И если нужна - тоже Python. Тот же Python(x,y): http://code.google.com/p/pythonxy/wiki/Welcome
А модули сам выбираешь, какие нужно.

[yva.livejournal.com]

Пардон, но почти всё написанное - полная ерунда.

[chebudzee.livejournal.com]

С каких пор освоить питон проще чем джаву? Джава куда проще синтаксически и читабельнее. Да и быстрее, чего уж греха таить. Питон хорош... да не для чего он не хорош. Всегда есть варианты лучше и проще. Тот же руби, если интересует именно простота в освоении. У питона синтаксис сильно грязный, читать код на нём сплошное мучение.

[chebudzee.livejournal.com]

Что за бред? В питоне тоже есть GC и оно работает гораздо медленне чем java.

[chebudzee.livejournal.com]

Все твердящие про простоту питона -- сказочники. Из моего опыта в коммерческой разработке на питоне -- разработчика вилами не загнать читать чужой код на питоне. Питон подавляет своим необъятным синтаксисом. Буквально каждое дейтсвие имеет свой синтаксис, даже очень похожие действия делаются по разному. Например splat-оператор (*) можно исползовать только в аргументах функции. Если же вам нужно "свернуть" в массив переменные вне аргументов функции -- для этого уже совсем другой непохожий синтаксис.
Это write-only язык, который тем не менее активно пиарят, приписывая ему свойства, которых у него нет.

[agalakhov.livejournal.com]

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

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

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

[sumerk.livejournal.com]

Я не пишу на питоне сам.

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

А ваше недовольство мне понятно - меня любая невыразительность или громоздкость в ЯП раздражает, все то, что сделано неэргономично.

Но в комментах к этому посту несчастному Александру Владимировичу советуют начать писать на Це. Или на Дельфи. Какая гадость!

[vassili prigarin (from livejournal.com)]

А возьмите меня.
Сейчас есть время и я могу Вам чего-нибудь порешать. Пришлите мне описание задачи (pdf | doc/docx | opendoc | tex) и, весьма желательно, ссылку (идеально, pdf со статьей) на что-нибудь похожее: чтобы я смог понять слова и представить себе контекст. А я Вам отдам картинки, числа и, если захотите, саму программу расчёта. Способ оплаты при успешном осуществлении проекта- поблагодарите меня в публикации "за помощь в организации расчётов". Если задача окажется сложной в вычислительном и/или программистском плане,- ну, обсудим по скайпу и решим. Оценку времени на решение/сложность я сообщу Вам по получении задачи. Если Вам это интересно, пожалуйста, в ответе укажите мне почтовый адрес для связи (или прямо в ФБ напишите).

[pphantom.livejournal.com]

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

[agalakhov.livejournal.com]

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

[agalakhov.livejournal.com]

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

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

[pphantom.livejournal.com]

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

[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 - НЕ ФОРТРАНОВСКАЯ. Она почти полностью на Си написана.

[agalakhov.livejournal.com]

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

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

[pphantom.livejournal.com]

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

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

[pphantom.livejournal.com]

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

[agalakhov.livejournal.com]

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

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

[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" - это вообще гадость, не имеющая аналогов ни в каких современных языках программирования. Как раз та штука, с которой современная теория компиляторов вообще справляться не умеет.

[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 в регистр.

[pphantom.livejournal.com]

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

[pphantom.livejournal.com]

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

[agalakhov.livejournal.com]

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

[agalakhov.livejournal.com]

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

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

[serge shikov (from livejournal.com)]

> понимаю, что на VBA она будет работать невыносимо медленно. Насколько я понимаю, программа, написанная почти на любом другом языке, компилируемом, будет работать в разы быстрее.
Ну вообще говоря, у VB (не VBA) нет никаких принципиальных причин, по которым он был бы невыносимо медленным, и никаких серьезных узких мест.

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

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

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

А без этого выбирать язык - это чистой воды дилетантство.

С точки зрения простоты и быстроты - я бы посоветовал clojure или groovy. Первый - это диалект lisp, и хорош гибкостью в первую очередь. Второй - синтаксический упрощенная версия Java. Оба на платформе JVM, а это значит, что взяв 64-битную версию, вы не будете иметь проблем, если нужно много памяти. И легко перейдете на более быструю машину, если такая подвернется, не имея проблем с перекомпиляцией. И еще у вас будет куча готовых инструментов, которые есть для JVM. Но это мои предпочтения.

Уже предложенный VB.Net - вполне достойный вариант, как и сама .Net в качестве платформы (опять же, куча инструментов тоже никуда тут не делась, хоть и другая). И дальше есть куда расти, на c# или f# например.