Здравствуйте, ·, Вы писали:
V>>Контора продаёт нейтивные, дотнетные и джавовские решения, нейтивных намного больше.
·>Может просто ваше джава решение не лучшее? И за джавой идут к другим?
Наше лучшее. Просто самих таких клиентов резко меньше и они обычно не крупные.
А всякие JP-Morgan и прочие крупные клиенты нейтивные.
·>http://www.indeed.com/q-High-Frequency-Trading-Developer-java-jobs.html
Ты сам по своей ссылке ходил? ))
http://chk.tbe.taleo.net/chk05/ats/careers/requisition.jsp?org=SUNTRADINGLLC&cws=4&rid=156&source=indeed.com
Strong coding experience in C++ and SQL required
Ability to also code in C, Python, Java, MATLAB and/or other languages a plus.
https://jobs.rbc.com/job/New-York-Application-Developer-NY/364691300/?feedId=96900&utm_source=Indeed&utm_campaign=RBC_Indeed
C++, Java, C#
https://careers-sig.icims.com/jobs/2378/software-developer---energy-%26-commodities/job
C++, C# or Java
http://q4inc.applytojob.com/apply/1e04042b55767f5f097664567a5d507063410d720c7c0a226a2424602205156477093a/Quantitative-Developer?source=INDE&sid=tkftgFNi9ATaKlbCRuRCB0Fn2kw1qFLU01n
Слово Java упоминается, но на вакансию НЕ требуется, нужны только C++ и C#
http://www.bosmaxhire.net/cp/?E8596D361D43515B785613653D55176A482D78&AspxAutoDetectCookieSupport=1
Ищут на С++, знание Java или Питона опционально, но приветствуется
·>51 jobs
·>51/181 = 28%.
В общем, на первой странице из 10 вакансий именно на Джаву идут две, остальные сугубо С++, знание Джавы опционально, но приветствуется.
Экстраполируя, получим 10 вакансий именно на Джаву по всем страницам.
Итого 10/181=5.5%
В общем, одна восемнадцатая от одной трети отличается нормально так.
Передёрнул так уж передёрнул. ))
·>Ещё посмотри "low latency developer". Там даже где-то половина.
Если посмотреть, что там таким же макаром дела обстоят.
V>>В самом языке нет потоков. А вот в системной библиотеке, являющейся частью стандарта, уже есть.
·>Прежде чем заявлять очередную глупось — погугли хоть 10 сек. Ключевое слово "jls-17".
Глупости заявляешь здесь только ты и вот это предложение погуглить — тоже, ес-но.
Я не хуже тебя представляю, что там с потоками в Джава и как оно устроено. И при чем тут язык или системные библиотеки.
А для борьбы с глупостью стоило посмотреть на язык go, где потоки встроены в сам язык.
·>Ещё намёк — в каком пакете находится класс Thread?
Плевать с большой колокольни.
·>А вот всякие сетевые сокеты, файлы, коллекции, регекспы и прочее — да, это часть стандартной библиотеки, а не языка.
Я правильно понимаю, что от одного лишь имени собственного пакета "lang" у тебя малость зрение меняется?
·>Это кстати одно время в упрёк Яве ставили, что мол треды — неотъемлемая часть языка.
Треды — это отъемлимая часть аж бегом.
Ты демонстрируешь тут повадки новичков в Джаве, которые на голубом глазу путают язык и VM.
V>>·>Почему HTTP не реализован с unsafe, а в FIX приходится? В HTTP не нужна шустрость?
V>>Я тебе уже ответил, но ты не понял ни слова, как обычно.
V>>V>>асинхронные сокеты на IOCP реализованы в нейтиве
·>Причём тут вообще сокеты? Зачем ты упомянул их? Как они с протоколами HTTP или FIX связаны?
Напрямую связаны, ес-но.
·>В смысле у вас только IOCP сокеты в нативе
В смысле виденные мною HTTP-серваки на дотнете используют такие сетевые ср-ва (асинхронный IO), которые были разработаны в нейтиве.
·>а всё остальное на c#? Ты же сам говорил, что синхронизация, многопоточность и управление памятью тоже нативные.
Ну вот многопоточность на пуле потоков и IOCP сверху в дотнете — все нейтивное.
Джава тут сосёт не нагибаясь, ес-но.
Для HTTP-серваков на джава ручками пишут обертки над нейтивной libevent.
V>>·>"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные.
Торопишься. Не думаешь.
Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди
Тут стоило помедитировать. Это СТАНДАРТНЫЙ подход. Это, блин, сверх-мега-стандартный подход для таких вещей. Это база, уровень 0. ))
Две встречные очереди образуют "кольцо". Эдакие чётки, как у попа, только вместо пальцев правой и левой руки у нас производитель и потребитель. Один берет из пула объект, подготавливает его и пихает "туда". Другой обрабатывает и пихает "обратно".
Чем ring-buffer отличается от двух встречных очередей? Да ничем, кроме того, что реализован не на связанном одностороннем списке объектов, а через прибитый к реализации массив фиксированного размера, что считается самой худшей схемой из всех известных. )) Ну, кроме случая, где генерирование и потребление происходит заведомо с одинаковой скоростью, как при воспроизведении аудио, например. Более того, запись и чтение из кольцевого буфера на один CAS дороже, чем в стандартной схеме межпотокового буфера. Ну и, самое главное, часто мы имеем обращение к одной и той же линейке кеша из разных потоков (ядер) в такой схеме, что до 6 раз (в среднем) тормозит любую межпоточность. Ладно аудио, там десятки-сотня пакетов в секунду от силы, но для HFT это смерть. ))
V>>Это и есть дисраптор. Это его базовый Lego-кубик (один из 3-х, вернее, с идентичным интерфейсом).
·>А доказать?
Я всё доказал, пояснив общее устройство такой схемы (две встречных очереди).
Какие еще нужны доказательства?
Я, конечно, могу ошибаться, но мне кажется, что тебя сбивает с толку именно ring buffer. Он в этой схеме вообще не причем, но кажется тебе главной деталью.
Без ring buffer можно получить лучшее быстродействие, за счёт (в порядке убывания важности):
— отсутствия блокирующих ожиданий при переполнении буфера;
— на одну операцию CAS меньше;
— лучшей локальности данных.
— меньшей требуемой памяти;
По последнему. Без ring buffer можно организовать НЕСКОЛЬКО веток consumer-producer с ОДНИМ всего пулом у каждого producer и хорошим автоматическим load balancing, в то время как в случае кольцевого буфера у нас пул объектов привязан к конкретной ПАРЕ consumer-producer, а не к именно producer (ведь пул нужен именно ему).
V>>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди, ссылку на тест которой (очереди) я тебе дал. 
·>Бред. Ты дал ссылку на тест, который реализует three producers -> one consumer используя стандартный BlockingQueue.
Кинь мне плиз мою ссылку.
·>
Результаты ни о чем. У меня примерно в 20 раз улучшение быстродействия по сравнению с нейтивным аналогом BlockingQueue.
·>отсюда: https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results
Да, я теперь внимательно посмотрел исходник и охренел.
Слишком большой штраф за абстракции.
Дорогие операции "записи" в буфер.
Писали нубы, нихрена не соображающие в устройстве современных систем. ))
Там должна была быть тривиальнейшая из всех тривиальных lock-free схема, причем, они же правильно описали — каждый раз забираем ВСЕ имеющиеся данные.
Т.е. достаточно взять lock-free stack и забирать все данные за раз, чтобы не опасаться ABA-проблемы. Такая схема вдвое дешевле при записи и фактически совсем бесплатна при чтении.
Ну и столько абстракций прилепить на две простейшие операции... Я же говорю, это уже вижуал бэйсик какой-то, а ты не верил. ))
Кароч, не ведись на всю вот эту херню, на LMAX и прочие громкие названия. Не боги горшки обжигают, а нубы и лохи, по большей части.
Причем, тут на сайте полно было обсуждений lock-free, где можно было действительно почерпнуть что-то полезное и ПРИВНЕСТИ это полезное в свой продукт. Вместо этого ты взял некую нубскую либу и хвастаешься этим.
Мне вообще кажется, что они нашли, таки, нормальное решение (оно давно уже не секрет), и отдали старое своё решение в опенсорс.
Кароч, если нужен настоящий хардор, пишите в личку, пообщаемся.
