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

[macroevolution]

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

Comments

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