macroevolution: (anomalocaris)
macroevolution ([personal profile] macroevolution) wrote2015-01-11 02:41 pm

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

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

[identity profile] agalakhov.livejournal.com 2015-01-30 06:09 pm (UTC)(link)
Согласен. Но тут важно уже то, что указано в -L. В системе может быть (и скорее всего) есть несколько libblas.so, лежащих в разных местах. Впрочем, при динамической линковке это решается настройками системы. Но мне чаще встречались фортранные программы, которые тащат копию BLAS внутри себя, а не используют -lblas. И я понимаю, почему: в то недолгое время, когда я считал на суперкомпьютерах, я успел намучиться с разными странными компиляторами, которые там встречаются. Уж проще принести все с собой.

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