LINUX.ORG.RU

Помогите выбрать язык программирования.

 ,


1

3

Добрый вечер. Нужен какой-то язык программирования для анализа больших csv файлов, написанная программа на котором работала быстро. Все решения на python не подходят из-за медлительности, делать что-то с применением cython долго и не всегда приводит к резкому увеличению производительности.

Что мне надо:

  1. Наличие отладчика;
  2. Понятный и легкий синтаксис.
  3. Автоматическая уборка мусора. Руками освобождать память — усложнение кода.

Что я пробовал:

  1. Nim — проблемы с инфраструктурой (нормально не запускается отладка) + еще не стабилен. Но язык понравился.
  2. Rust — на мой взгляд переусложнили с unwrap(), например + зачем-то сделали 2 вида строк.
  3. С, С++ — не нравится «ручная» работа с памятью.

Сейчас присматриваюсь к Go, но отталкивает поддержка многопоточности, Scala — Хорошая интеграция с экосистемой java или .net. Еще не читал документацию.


для анализа больших csv файлов

Смотря какой анализ, так может тебе просто AWK хватит.

loz ★★★★★ ()
Ответ на: комментарий от dicos

Ну, ясно дело. Вообщем-то я говорил чисто теоретически и про прошлое. Сейчас времена поменялись сильно.

Народ верно говорит: «Скажи какой анализ?» А так, вообще, C# — вполне себе хороший вариант.

Quickern ★★ ()
Ответ на: комментарий от dicos

Эти самые условия нужно найти по историческим данным, которые у меня есть в csv формате.

Ну тогда бери R (как уже советовали) и не^W выеб^W анализируй. Потом напишешь алгоритм на чем знаешь.

Oxdeadbeef ★★★ ()

С, С++ — не нравится «ручная» работа с памятью.

Джава это C++ без ручной памяти.

Rust — на мой взгляд переусложнили с unwrap(), например + зачем-то сделали 2 вида строк.

str и String не два вида строк. Они не синонимичны.

Наличие отладчика;
Понятный и легкий синтаксис.
Автоматическая уборка мусора. Руками освобождать память — усложнение кода.

Бери джаву и не выпендривайся

Aswed ★★★★★ ()
Ответ на: комментарий от Aswed

Жаба ваша запросто может оказаться медленнее пытона на такой задаче. Пока она раздуплится, пока прогреет ЖЫД, вычисления уже и закончатся. Уж если так важна скорость, только натив. И получается выбор то невелик. По-хорошему надо конечно плюсы брать и не выделываться, но ТСу тогда пару годков еще доучиваться. Хипстоту же сразу лесом. Пока он код напишет, они пять раз апи поломают. Нах такое счастье? Языки моложе 10 лет увы не годятся для серьезных задач.

anonymous ()
Ответ на: комментарий от anonymous

да, да, пусть ТС трахается с плюсами

anonymous ()

C или Go то что тебе нужно.

Deleted ()
Ответ на: комментарий от dicos

Файл чуть меньше 2 ГБ.

Так небольшой вроде.

anonymous ()
Ответ на: комментарий от dicos

мне нужно сделать много циклов for

А может не нужно? Ты алгоритмически пробовал задачу иначе решить?

anonymous ()
Ответ на: комментарий от anonymous

Я хочу написать торгового робота для автоматической торговли на фондовой бирже. «анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

dicos ()

java или c#

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

anonymous ()
Ответ на: комментарий от dicos

«анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

Из этого ничего не следует.

Ты собрался что-ли искать бегая по файлам? Это идиотизм. Перегоняй свои файлы во вменяемое представление в памяти и уже в нём ищи. Если нет столько памяти - разбивай свои файлы на куски, строй из них представление и просто дампь память в файл, а потом загружай.

Зачем тебе csv-файлы-то анализировать мне не ясно.

anonymous ()
Ответ на: комментарий от dicos

Файл чуть меньше 2 ГБ

Значит, бинарное представление (после парсинга) легко влезет в ОЗУ, во всяком случае, если писать на С/С++. Твоя задача - выбрать нужную структуру данных и постараться сделать так, чтобы и сама структура данных, и алгоритмы работы с ней были cache-friendly.

PS. Судя по тому, что говоришь о каком-то ручном освобождении памяти в С++, с [современным] С++ ты не знаком от слова совсем.

anonymous ()
Ответ на: комментарий от dicos

Я хочу написать торгового робота для автоматической торговли на фондовой бирже. «анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

Язык программирования - здесь чуть ли не последнее дело, о чем нужно беспокоиться. Впрочем, питон будет медленным. Это бесспорно. Си/Си++ - явный перебор для непрофессионального программиста, да и для профессионального может быть тоже. Java или C# ближе к золотой середине: и дешево, и сердито, т.е. и удобоваримо по скорости исполнения, и терпимо по скорости разработки.

Тут может быть более важна математика, чем программирование. Какие-нибудь мартингалы, или ветвящиеся процессы, или тупо технический анализ. А что, на технический анализ опираются трейдеры и игроки, и уже поэтому или, может быть, исключительно поэтому, он иногда работает)) Хотя основные деньги зарабатываются и теряются во времена катаклизмов, а их предугадать почти невозможно. Вон, Сорос хвалился тем, что предвидел нарастающие противоречия. Именно это помогало ему зарабатывать состояния. Только я что-то отвлекся...

Кстати, а не подскажешь литературу или ссылки на тему автоматической торговли на фондовой бирже? Как надыбать такой файл CSV как у тебя?

dave ★★★★★ ()

Из нативных языков (т.е. без виртуальных машин) со сборкой мусора — D или OCaml. Можно и Go, но там, боюсь, значительную часть кода будут занимать проверки кодов возврата.

Если брать менеджед языки, то в первую очередь Java (можно Gosu или Ceylon, можно и Scala, но это эдакий монстр вроде C++ для JVM). Если же платформа позволяет использовать .NET, то C#.

Но если есть подозрение, что таки нужно будет выжимать самый максимум, то C++14 (или C++11, если нет возможности использовать самые последние версии компиляторов). В крайнем случае C.

eao197 ★★★★★ ()
Ответ на: комментарий от dave

Для технического анализа есть проф.инструменты. Тут похоже ТС курсовую пишет. Тоже дело, но можно не заморачиваться сишками.

anonymous ()

ниче не знаю, Go учить тебе быстро, а cython применить долго? кто-то врет тут.

t184256 ★★★★★ ()
Ответ на: комментарий от anonymous

Стандартные контейнеры и строки?

а вот это как раз может сожрать всю производительность. если уж обрабатывать «большие» файлы (2 гига - это мелкий файлик), то без STL однозначно. и главное - никаких там потоковых чтений файлов плюсовых, это гогно работает в сотни раз медленнее обычного fopen и fread. строки - тоже то ещё тормозилово. лучше с ними вообще не работать, а сразу всё в хэши переводить.
на плюсах тоже надо уметь писать. STL - это ходунки для детей. хотите скорости - пулы и самодельные аллокаторы в помощь. хотите ещё больше скорости - кастомные библиотеки ввода-вывода, которые превосходят стандартные в десятки раз. хотите ещё больше скорости - многопоточность и синхронизация через примитивы. ну а дальше уже идёт искусство настоящей оптимизации.

Iron_Bug ★★★★★ ()
Ответ на: комментарий от Iron_Bug

без STL однозначно

Никаких однозначно тут нет даже близко. При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью.

никаких там потоковых чтений файлов плюсовых, это гогно

работает в сотни раз медленнее обычного fopen и fread

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO. Для начала, не надо сравнивать жопу с пальцем. Плюсовым аналогом fread будет блочное чтение из std::filebuf, и никаких сотен раз там нет. И даже двух раз нет, как правило.

строки - тоже то ещё тормозилово. лучше с ними вообще не работать

Зависит. И да, почти везде есть small string optimization.

STL - это ходунки для детей. хотите скорости - пулы и самодельные аллокаторы в помощь

measure first

anonymous ()
Ответ на: комментарий от anonymous

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++. или просто напиши банальный тест и прогони его. даже если там в 1.1 раз разница - это уже повод отбросить тормозную реализацию в пользу эффективности, если речь идёт про скорость. ладно там фигня в 2 гига. а если бы были сотни терабайт? вот там и вылезают все эти недоучтённые процентики.
все мои утверждения основаны на опыте. в том числе, разработке серверных приложений, которые обрабатывают огромные потоки данных. и я не один десяток раз измеряла разные функции, реализации, разные настройки оптимизации. так что меня не надо отсылать к измерениям. я их за 20 лет сделала предостаточно.
и да, вот ещё:
C++ Format - вместо стандартного I/O:
https://github.com/cppformat/cppformat
документация:
http://cppformat.readthedocs.org/en/stable/index.html
сравнительные тесты по скорости (сравнение со стандартными и другими популярными библиотеками):
https://github.com/cppformat/cppformat/blob/master/README.rst

Iron_Bug ★★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

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

Можно подумать, std::vector всегда используют так, что случаются реаллокации.

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++

Твой опыт в С++ мало чего стоит, если сравниваешь fread с потоками. Всё равно, что сравнивать fread с printf. Что до тестов плюсовых потоков, их часто пишут люди, которые даже не слышали по tie и отключённую по умолчанию буферизацию. Вот они потом и рассказывают сказки про разницу в десятки или сотни раз.

не надо отсылать к измерениям. я их за 20 лет сделала предостаточно

Ещё как надо.

anonymous ()
Ответ на: комментарий от anonymous

Можно подумать, std::vector всегда используют так, что случаются реаллокации.

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

Твой опыт в С++ мало чего стоит, если сравниваешь fread с потоками.

думаю, у меня более чем достаточно опыта. и мой опыт практический. у меня нет возможности жировать и разбрасываться ресурсами. я всегда выжимаю из железа всё, что оно может. так что я знаю, что говорю. ни одна реализация в плюсах не быстрее связки fopen+fread. можно играться с мапами, но там тоже свои особенности. где-то тут на ЛОРе буквально вчера обсуждался вопрос про мапирование и подводные камни, с ним связанные.
измерения проведи сам. это тебе домашняя работа. у меня более серьёзных задач достаточно. да, ещё не забудь про open/read. они простые, но шустрые.

Iron_Bug ★★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от dicos

У меня не для бирж, но похожая. В общем, изначально писаная на сишке + питон, но теперь неспешно переписываю на golang. Хз чем тебе не нравится многопоточность в нем.

jori ()
Ответ на: комментарий от Iron_Bug

Минуточку, не надо выкручиваться. Вот что ты написала

никаких там потоковых чтений файлов плюсовых, это гогно работает в сотни раз медленнее обычного fopen и fread

написать такое мог только человек, слабо знакомый с IO в плюсах, о чём уже было сказано. Если до сих пор не поняла, поток в C++ - это аналог printf/scanf. А не аналог fread/fwrite. Это первое.

Второе: «сотни раз» многое говорит о твоих так называемых измерениях. Десятки-сотни раз получаются только у чайников, не знакомых с плюсовым IO. Реальная разница в правильных тестах отнюдь не столь драматична, и не всегда в пользу C.

На этом вопрос о твоём «опыте» можно закрывать.

anonymous ()
Ответ на: комментарий от dicos

Если приложение будет работать 24 на 7, время-от-времени пожевывая CSV, то Java будет смотреться неплохо.

мне нужно сделать много циклов for

Stream.parallel() // optional
        .filter()
        .map()
        .reduce();
GoodPerson ()
Ответ на: комментарий от anonymous

Второе: «сотни раз» многое говорит о твоих так называемых измерениях. Десятки-сотни раз получаются только у чайников, не знакомых с плюсовым IO. Реальная разница в правильных тестах отнюдь не столь драматична, и не всегда в пользу C.

Давай, ты же не чайник. Покажи мне векторы, строки и прочие куллстори из крестов. Предложи свои бенчмарки, придумай задачки. Покажи правильные.

anonymous ()
Ответ на: комментарий от anonymous

Нафига? Всё равно сраные анонимусы обосрут.

rupert ★★★★★ ()
Ответ на: комментарий от anonymous

Да, действительно, мне «бегать» по файлу не надо, нужно будет загрузить этот файл в оперативную память и потом работать с оперативной памятью.

dicos ()
Ответ на: комментарий от dave

Могу порекомендовать блог компании iiInvest

Из действующих торговых систем могу только порекомендовать систему Герчика, которая основана на линиях сопротивления и поддержки. Или производные от них. Эти линии чертят трейдеры исходя из своего опыта. Объяснить толком не могут.

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

У меня есть только данные по фьючерсам. Сейчас интернет медленный, если нужна информация по какому-то определенному фьючерсу, то могу вечером или завтра на эл. почту выслать. Если нужна информация по всем фьючерсам, то писал для себя такую штуку: https://bitbucket.org/dicos/moex_info/overview

dicos ()
Ответ на: комментарий от dicos

Спасибо! Я только присматриваюсь к этой области. Думаю, а стоит ли тратить на нее свое время. Когда-то давно с другом написали небольшое приложение на Java для технического анализа. Было интересно. Все было новым для меня: и Java, и рынок ценных бумаг. Сейчас же нужен сильный коммерческий стимул)

Хочу спросить, а имеют ли смысл трейдинговые приложения под андроид? Или десктоп преобладает и будет преобладать?

dave ★★★★★ ()

Сейчас присматриваюсь к Go, но отталкивает поддержка многопоточности

но отталкивает поддержка многопоточности

что, прости?

derlafff ★★★★★ ()
Ответ на: комментарий от dicos

Файл чуть меньше 2 ГБ.

Любой компилируемый, какой тебе больше нравится.

mix_mix ★★★★★ ()
Ответ на: комментарий от Iron_Bug

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

std::vector<> так устроен, что реаллокация и копирование каждого элемента происходит _в_среднем_ не более одного раза. Для подавляющего числа приложений этого более, чем достаточно.

dave ★★★★★ ()
Ответ на: комментарий от derlafff

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

dicos ()
Ответ на: комментарий от dave

Трудно сказать, может быть кому-то удобнее иметь с собой не ноутбук, а планшет, на котором будет работать программа с приятным и удобным интерфейсом.

dicos ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.