Здравствуйте, white_znake, Вы писали:
_>Не за счет объемов центики превращаются в солидные суммы, а за счет левериджа, при чем леверижд должен быть достаточно большим (больше 10 к 1)
как раз плечо и позволяет увеличить объем, это связанные вещи
_>Если ты в теме HFT, то расскажи, есть ли в HFT хеджирование операций? Ведь на хеджировании тоже нужно время, которое ценится в HFT, а с другой стороны, не используя хеджирование можно потерять большие суммы при использовании большого левериджа в случае, когда ожидания не оправдались.
хз к чему тут хеджирование и HFT в вопросе.
применяют разные схемы контроля за рисками. будь то SL/TP уровни (самое простое и надежное) или сделки на связанных (коррелируемых) инструментах или опционы\фьючи (тут не спец, к сожалению, не подскажу подробностей)
Здравствуйте, white_znake, Вы писали:
_>Хотелось бы услышать мнение работающих в данной области.
Я пользуюсь терминалом cTrader, который на .NET написан, да еще и ботов своих писать можно на C#.
Есть терминалы MetaTrader — они на C++, но скорее по историческим причинам.
"Профессиональные" терминалы обычно на Java.
Софт брокера или биржи это обычно Java+Oracle.
Хотя в нашей мосбирже (ММВБ) вроде как на C++. Люди там слегка упоротые, не факт что оправдано такое решение. Причем весь прикладной софт у низ на .NET написан.
HFT только C++, но это действительно не обычный трейдинг в классическом понимании слова.
Здравствуйте, Слава, Вы писали:
С>Но всё же, а неужто панковский Go уже научился обгонять весьма быструю Яву, с ее десятками лет труда, вложенных в JVM?
изначально я полагался на интуицию:
go
1) без VM
2) компилируется в нативный код
3) как и java имеет gc
4) жрет мало памяти
то есть оснований для отставания от java не вижу.
однако оказалось, что компилятор довольно туп, а библиотеки сами по себе тормозные (яркий пример — regexp)
то есть фундаментально вроде есть возможности для ускорения, но ленивое развития скорее всего все тормозит
ну опять же из-за слабого распространения и скудного набора вспомогательных либ бизнесу тяжело клепать продукты на go
Здравствуйте, uzhas, Вы писали:
U>изначально я полагался на интуицию: U>go U>1) без VM U>2) компилируется в нативный код U>3) как и java имеет gc U>4) жрет мало памяти U>то есть оснований для отставания от java не вижу.
Интуиция подводит.
1) Java также копилируются в нативный код. Только JIT, а не compile-time. Сама по себе компиляция в нативный код не дает заметных преимуществ, только если у тебя не C++ компилятор.
2) Виртуальная машина Java какбы... виртуальная. Её физически не существует во время исполнения.
3) Зато наличие промежуточного кода дает много возможностей платформе — динамическая генерация, инлайнинг и перестроение кода во время выполнения (hotspot).
4) Наличие gc и "жрет мало памяти" — практически несовместимые вещи.
В самом go не заложено ничего, за счет чего он мог бы быть значительно быстрее java. А учитывая детские болезни он еще не скоро станет быстрее.
Здравствуйте, gandjustas, Вы писали:
G>1) Java также копилируются в нативный код. Только JIT, а не compile-time. Сама по себе компиляция в нативный код не дает заметных преимуществ, только если у тебя не C++ компилятор.
JIT — это халтура, да еще и в рантайме
компиляция в данном контексте — это когда из исходников генерится нативный код (в итоге получаем программу). и потом запускается только он
беда у go в аналогичном халтурном компиляторе (это все разжевывается по ссылкам, что я дал)
G>2) Виртуальная машина Java какбы... виртуальная. Её физически не существует во время исполнения.
ну да, это не интерпретатор, согласен
G>3) Зато наличие промежуточного кода дает много возможностей платформе — динамическая генерация, инлайнинг и перестроение кода во время выполнения (hotspot).
я не спорю о наличии доп. возможностей
"зато" ведет к тормозам (см. пункт 1)
G>4) Наличие gc и "жрет мало памяти" — практически несовместимые вещи.
покликай бенчмарки, проги на go жрут в разы меньше памяти, чем проги на java
G>В самом go не заложено ничего, за счет чего он мог бы быть значительно быстрее java. А учитывая детские болезни он еще не скоро станет быстрее.
по задумке он предназначен для системного уровня (инфа из вики)
и не вижу принципиальных проблем внедрить более агрессивную оптимизацию при компиляции
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>1) Java также копилируются в нативный код. Только JIT, а не compile-time. Сама по себе компиляция в нативный код не дает заметных преимуществ, только если у тебя не C++ компилятор. U>JIT — это халтура, да еще и в рантайме
Сегодняшние JITы работают не хуже компиляторов. Только C++ заметно отличается.
U>компиляция в данном контексте — это когда из исходников генерится нативный код (в итоге получаем программу). и потом запускается только он
И что?
U>беда у go в аналогичном халтурном компиляторе (это все разжевывается по ссылкам, что я дал)
Беда у go много в чем.
G>>3) Зато наличие промежуточного кода дает много возможностей платформе — динамическая генерация, инлайнинг и перестроение кода во время выполнения (hotspot). U>я не спорю о наличии доп. возможностей U>"зато" ведет к тормозам (см. пункт 1)
Ты о чем? При чем тут тормоза? Тормоза по сравнению с чем? По сравнению с C++ любой код тормозит, потому что в компилятор C++ вбухано стотыщмиллионов часов и работает он по полчаса над helloworld.
G>>4) Наличие gc и "жрет мало памяти" — практически несовместимые вещи. U>покликай бенчмарки, проги на go жрут в разы меньше памяти, чем проги на java
Это в которых сравнивается потребление памяти для двух вложенных циклов? Надо сравнивать на реальных программах, а не микробенчмарках. На микробенчмарках вообще можно показать что угодно.
G>>В самом go не заложено ничего, за счет чего он мог бы быть значительно быстрее java. А учитывая детские болезни он еще не скоро станет быстрее. U>по задумке он предназначен для системного уровня (инфа из вики)
Задумка хороша. Я бы выбрал go вместо C если не нужно быстродействие.
U>и не вижу принципиальных проблем внедрить более агрессивную оптимизацию при компиляции
Принципиальных проблем вообще очень мало существует. Всегда есть проблема эффективности вложений. Вкладывать в скорость кода go никому не надо.
Здравствуйте, uzhas, Вы писали:
U>то есть оснований для отставания от java не вижу. U>однако оказалось, что компилятор довольно туп, а библиотеки сами по себе тормозные (яркий пример — regexp)
Ну вот, а сперва вы меня зачем-то заминусовали. Зачем? Я ж не с потолка беру то, что пишу. Про Go я брал данные не из тех источников, которые вы привели (хотя — благодарю вас за хорошую подборку ссылок), а полагался на мнения людей, авторитетных для меня, и данные тестов, которые они приводили. И вдобавок — это уже из области интуиции — ну что доброго может придти от гугла? Вот, они например написали GWT, а на нем основан Vaadin. Вы с этим поделием дело имели? Где там скорость и удобство? Это ж монстр монстроидальный.
Гугл может делать что угодно и как угодно, у них тумбочка с бесконечными деньгами есть. Однако же, что в Go есть GC — я знаю, и что нельзя, хоть убейся, сразу и быстро сделать быстрый GC — это я тоже знаю. Для JS сколько лет его делают и доделывают — и всё равно результат не впечатляет. Чем разрабатывать 100500 по счёту язык, лучше бы они довели до ума GC для Ada, патчи для нее такие есть, но всё оно какое-то кривенькое.
Здравствуйте, white_znake, Вы писали:
_>Приветствую коллеги
_>Интересует сабж, особенно в конторах типа хеджинговых фондов. _>Я последнее время прогал на .NET, сейчас проект на Node.JS, но вот хотел бы поразрабатывать софт для трейдинга. _>Отсюда вопрос: надо ли вспоминать C++ (на котором не было опыта с 2010 года) или C++ уступает свою роль Go? _>Сильны ли позиции Java в данной области?
_>Хотелось бы услышать мнение работающих в данной области.
Вот как раз в разделе предложения о работе, некая инвестиционная компания на 200К ищет специалиста
Требования:
Высшее образование
Отличное знание языка T-SQL. Опыт разработки на платформе MS SQL Server от 7 лет.
Опыт работы с версией MS SQL Server 2012 от 2-х лет
Опыт работы в составе группы разработчиков
Опыт автоматизации бизнес-процессов брокерской компании будет огромным плюсом
Основные задачи:
Разработка серверной логики
Решение интеграционных задач
Решение задач по оптимизации работы системы
Участие в проектировании архитектуры системы
Участие в тестировании
Используемые инструменты:
MS Visual Studio 2013, SSMS, Jira, TFS
Здравствуйте, Слава, Вы писали:
С>Гугл может делать что угодно и как угодно, у них тумбочка с бесконечными деньгами есть. Однако же, что в Go есть GC — я знаю, и что нельзя, хоть убейся, сразу и быстро сделать быстрый GC — это я тоже знаю. Для JS сколько лет его делают и доделывают — и всё равно результат не впечатляет.
Не впечатляет оттого, что JS сам по себе неудачный язык. Go это как раз попытка сделать язык для которого можно реализовать быстрый GC.
Здравствуйте, white_znake, Вы писали:
AT>>Было бы здорово, если бы ты рассказал, что понимаешь под трейдингом — коннективити, риск (сценарный или живой?), ордера, прайсинг, букинг etc? Резонно предположить, что на каждом этапе и на каждом рынке (в зависимости от его особенностей), может быть что-то свое. _>На чем пишут интересные штуковины типа статистического арбитража?
Java, C++. Если offline (аналитика), то phyton, так как кванты с ним наиболее знакомы.
Здравствуйте, white_znake, Вы писали:
_>Приветствую коллеги
_>Интересует сабж, особенно в конторах типа хеджинговых фондов. _>Я последнее время прогал на .NET, сейчас проект на Node.JS, но вот хотел бы поразрабатывать софт для трейдинга. _>Отсюда вопрос: надо ли вспоминать C++ (на котором не было опыта с 2010 года) или C++ уступает свою роль Go? _>Сильны ли позиции Java в данной области?
_>Хотелось бы услышать мнение работающих в данной области.
Здравствуйте, uzhas, Вы писали:
U>то есть оснований для отставания от java не вижу. U>однако оказалось, что компилятор довольно туп, а библиотеки сами по себе тормозные (яркий пример — regexp)
Хм. Если go семантически близок к железу (=Си), то почему никто до сих пор не написал транслятор, который преобразует Go в Си и даст его на растерзание gcc, на оптимизатор которого никто особо не жалуется?
Здравствуйте, white_znake, Вы писали:
_>Хотелось бы услышать мнение работающих в данной области.
Выбери брокера и софт с API для автоматической торговли, попроси демо-доступ. Напиши простой тест на любимом языке программирования — обновление информации о ценах ("стаканом" у нас это называли) — сколько раз в секунду сможешь эту информацию получить. Чем больше, тем лучше. Потом замерь размещение заявки и её снятие — твой робот же должен быстро реагировать на изменения рынка.
Но для успешной торговли твоим роботам нужна какая-то стратегия, не только скорость реакции.
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, white_znake, Вы писали:
_>>Хотелось бы услышать мнение работающих в данной области.
V>Выбери брокера и софт с API для автоматической торговли, попроси демо-доступ. Напиши простой тест на любимом языке программирования — обновление информации о ценах ("стаканом" у нас это называли) — сколько раз в секунду сможешь эту информацию получить. Чем больше, тем лучше. Потом замерь размещение заявки и её снятие — твой робот же должен быстро реагировать на изменения рынка.
V>Но для успешной торговли твоим роботам нужна какая-то стратегия, не только скорость реакции.
Стратегии — это самое главное: Spoofing, FixManipulation, WashTrades etc.
Вещи критичные к скорости, на C. Всякие высокоуровневые вещи на Java/Scala. Математические модели на питоне. Тулзы кто на что горазд: мне нравится Eclipse RCP
Здравствуйте, bazis1, Вы писали:
U>>то есть оснований для отставания от java не вижу. U>>однако оказалось, что компилятор довольно туп, а библиотеки сами по себе тормозные (яркий пример — regexp) B>Хм. Если go семантически близок к железу (=Си), то почему никто до сих пор не написал транслятор, который преобразует Go в Си и даст его на растерзание gcc, на оптимизатор которого никто особо не жалуется?
Go и так полагается на стандартные бэкенды. Но вот например —
For signed integers, the operations +, -, *, and << may legally overflow and the resulting value exists and is deterministically defined by the signed integer representation, the operation, and its operands. No exception is raised as a result of overflow. A compiler may not optimize code under the assumption that overflow does not occur. For instance, it may not assume that x < x + 1 is always true.
При таком ограничении возможности оптимизатора уже значительно урезаны.
Здравствуйте, bazis1, Вы писали:
B>Хм. Если go семантически близок к железу (=Си), то почему никто до сих пор не написал транслятор, который преобразует Go в Си и даст его на растерзание gcc, на оптимизатор которого никто особо не жалуется?
Потому что в сфере применения Go: написание всевозможных Web-сервисов, на миллисекунды всем, вобщем-то, плевать
Здравствуйте, pestis, Вы писали:
P>Нет. В терйдинге важна не производительность языка, а возможность писать сложные алгоритмы надежно и без ошибок. Поэтому в трейдинге рулят Scala и F#, слышал что некоторые используют Haskel.
По моим данным, в трейдинге важны мозги, поэтому пишут на brainfuck
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Вещи критичные к скорости, на C. Всякие высокоуровневые вещи на Java/Scala. Математические модели на питоне. Тулзы кто на что горазд: мне нравится Eclipse RCP
А как же пэхапэ?
