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

[macroevolution]

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

Comments

[techwork.livejournal.com]

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

[natvalbr.livejournal.com]

можно использовать PureBasic - код переводится в FlatAssembler а потом уже компилируется.

http://macroevolution.livejournal.com/186606.html?thread=12744174#t12744174

[techwork.livejournal.com]

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

[daeloce.livejournal.com]

"Именно поэтому асемблер и работает априори быстрее всех"

Распространенное заблуждение оставшееся от 90х годов. Сейчас вы никогда, как бы круты ни были, не напишете на асме быстрее чем на Си. Просто потому, что компиляторы достигли такого уровня развития, что способны просчитать и предсказать огромное количество мест критичных для скорости и с оптимизировать их. Вы же никогда не сможете в более менее сложном случае учесть даже все RAW, WAR и WAW конфликты, не говоря уже о толковом разворачивании циклов, предсказании ветвлений и прочем.

[techwork.livejournal.com]

начнём с того что сейчас объёмы программ гигантские - от сюда и ваша проблема. Это не проблема скорости работы ассемблера - это проблема скорости разработки."не неучтёте" а " не хватит времени" и позор для математика этого не знать. Учесть можно всё - вопрос лишь в количестве человекочасов на это.

[daeloce.livejournal.com]

"от сюда и ваша проблема"

У меня проблем нету :)

А если серьезно, то не отсюда. Дело не в гигантских программах. Дело в умных компиляторах. Раньше компиляторы были довольно примитивные, и с трудом справлялись с одной лишь компиляцией, и тогда действительно, переписав критичный кусок кода на ассемблере можно было его ускорить на порядки. Но те "счастливые" времена прошли. Для сведения, интеловский компилятор, ЕМНИП при оптимизации оценивает код окном в 500 комманд, т.е. он оценивает зависимости по данным, регистрам и прочему для 500 команд одновременно. И да, при оценке кода он по нему, по коду проходит около 100 раз. Вы способны это сделать? Вы способны предсказать ветвления для всех условных операторов? А развернуть каждый цикл, прооптимизировав при этом его?

"Это не проблема скорости работы ассемблера"

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

""не неучтёте" а " не хватит времени" и позор для математика этого не знать"

Ну это понятно, за бесконечное время вы сделаете идеально и максимально возможно быстро работающую программу. Вот только за любое разумное время вы сделаете хуже чем компилятор.

В общем, к чему я это все. Писать на асме для HPC в настоящее время глупость. Асм нужен в двух моментах: микроконтроллеры, где часто очень мало оперативной и флэш памяти(нормальное явление когда там 256-512 байт ОЗУ, и пару кБ флэша), хотя тут тоже можно обойтись С, но все же иногда ручное написание кода на асме даст немного более компактный код. Второе использование асма, это оценка узких мест в том же HPC, т.е. ты смотришь на ассемблерный листинг который сгенерировал компилятор, понимаешь почему это работает медленно, и меняешь код на С. Третий случай тоже есть, но общая доля много меньше процента. Это тот случай когда действительно выгоднее написать маленький кусок кода на асме - в особо специфических случаях ты действительно сможешь написать немного более быстрый код, чем сгенерирует компилятор, исключительно за счет своих априори знаний о предполагаемой работе алгоритма. Но повторюсь, таких случае ничтожно мало, и с развитием компиляторов их становится еще меньше.

[techwork.livejournal.com]

блин да что вы всё сводите к одному человеку ? И вы так ведь и не опровергли то что это вопрос лишь времени или интуиции - подбор идеальной последовательности.
А какой бы не был анализ заданный другим алгоритмом - он всегда будет следовать алгоритму. То есть форме при создании которой все возможные вариации создававший его человек также учесть не смог. Потому что иначе любую оптимальную программу можно было бы предсказать.