Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. EP>>>Ещё раз, не язык становится динамическим, а в коде используется больше динамических подходов. Простейшее для понимания утверждение жеж EP>·>Динамические подходы зависят от задач, а не от языка. EP>От языка в том числе — так как в одном языке статический полиморфизм реализуется легко, а в другом нет — и как следствие используется динамический
CRTP? Я что-то не замечал что он часто используется в С++.
EP>·>Использование std::map — динамический подход? EP>В каком-то смысле да. Точнее его бывает используют для случаев когда все входные данные (а бывает ещё и выходные) известны в статике. В C++ для таких случаев есть например boost::mpl/fusion/hana::map — в которых соответственно бОльшая часть ошибок ловится во время компиляции
А можно пример?
EP>·>Ок, могу согласится, что использование динамических подходов в Java проще, чем в Плюсах. Это что, плохо? EP>Я не знаю с чем ты соглашаешься, ибо я такого утверждения не делал. Моё утверждение в том что статика на C++ распространённые и легче. EP>Динамика например немного проще и лаконичней в C# как раз за счёт упомянутого тобой dynamic.
Динамикой проще пользоваться в Яве, поэтому и используют чаще чем в Плюсах.
EP>>>Замени на dynamic_ec.call("exampleMethod1", 10, 4); — типизация статическая, EP>·>Ровно такая же конструкция может быть и в С++. Почему возможность такой конструкции ставится в упрёк именно Яве, хотя ровно то же можно сделать и в С++? EP>Ставится в упрёк (точнее констатируется как факт) не возможность использовать динамические конструкции, а: EP>а) фактические засилье динамических конструкций в коде, библиотеках
Это у тебя какой-то эффект наблюдателя. Скажем, в том же Вебе — всё динамика, поэтому удивительно ожидать там статических библиотек. А в Вебе как раз Плюсы чувствуют себя несколько некомфортно.
EP>б) слабые языковые средства для перевода в статику
Ок. Более слабая система типов, согласен.
EP>·>Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка. EP>Это лишь форма. Что это меняет с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок?
Что в первой форме ты явно даёшь понять, что это просто литерал, значит компилятор о нём ничего не знает и не проверяет. А во втором случае — ты неявно ожидаешь поддержку со стороны компилятора.
EP>·>А смысл? Ни автодополнения, ни рефакторингов, ни goto definition, нифига. EP>Лаконичность динамического кода. Со строками у тебя точно также не будет рефакторингов и т.п. только форма менее удобная и выразительная. EP>Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John";
Ничем не хуже xml_root.set("person.name", "John");
И вообще плохая конструкция. Непонятно — а что если <person> может быть список? Что мы меняем? Если уж так ратуем за статику, то будь добр опиши класс:
class Person {String name;}
и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент.
EP>>>Ты не понимаешь о чём речь. И на C++ можно писать с кучей динамики, более того можно вообще дёргать eval какого-нибудь динамического языка. EP>>>Речь же о том что обычно на Java больше динамики чем на C++, а не о том что у него типизация динамическая. EP>·>Так какой такой особенной динамики? EP>·>Может ты имеешь в виду рефлексию? EP>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится.
Ну пока ещё не добавили. А runtime рефлексия заменяет compile-time при наличии runtime кодогенерации.
EP>·>Обычно делают хрень с макросами или какой-нибудь генерацией исходников каким-нибудь жутким m4. EP>Зачем m4? — это у тебя какие-то предрассудки. Без проблем для этих целей используется например Python, либо напрямую, либо через шаблонизатор типа Jinja, либо и вовсе препроцессор типа Cog. В систему сборки это добавляется одной строчкой
m4 или Пайтон — не большая разница. Приходится тащиь ещё один инструмент, что усложняет инфраструктуру. (например, теперь помимо Плюсов нам нужен ещё и Пайтон ставить, да ещё поди библиотеки какие-нибудь к нему).
EP>>>Прикольно, вообще-то это ты тут запутался. Я не говорил что у Java динамическая типизация — перечитай сообщение ещё раз. EP>·>Я не понимаю что ты имеешь в виду "больше динамики". EP>Стирание типов. Например с последующими dynamic cast'ами и runtime проверками, вместо параметрического полиморфизма и статических проверок (перегрузки, static_assert, etc).
Тоже решение. Но явно не "безупречно лучшее".
EP>>>Ты опять не понимаешь о чём речь. EP>·>Тут мне vdimas говорил, что в Java программе чаще используются касты (похоже, там у них специальный человек с плёткой стоит и заставляет всех касты в java код вставлять). EP>Это из-за того что типы чаще стираются, отсюда и касты.
Ты про дженерики что-ли?
EP>>>Дело не в UB или ещё в чём-то (в одной из форм dynamic_cast как раз исключение) — ещё раз посмотри на dynamic_ec.call — там никакого UB. EP>·>Ок. В чём тогда разница между Явой и плюсами в этом смысле? EP>Разница в том что в C++ больше статических выразительных средств, многие библиотеки имеют именно статические интерфейсы, и по факту намного меньше стирания типов за счёт повсеместного использования параметрического полиморфизма.
ABI уже пофиксили?
EP>·>Ксати, dynamic_cast вообще в Яве не существует. Опять получается, что С++ более динамичный! EP>Прикалываешься? Там не динамический cast отсутствует, а статический
static_cast вообще тупо даёт undefined behaviour в этом случае, т.е. он не проверяет runtime тип, а надеется, что программист знает что делает (правильно проверил доморощенный GetType()).
struct A {};
struct B : A {};
struct C : A {};
B b;
A &a = b;
C &c = static_cast<C &>(a);//упс...
Какой смысл от него в Яве?
EP>>>>>Возможно EP>>>·>А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик? EP>>>Твоё утверждение о невозможности — не верно. EP>·>На текущий момент — верно. EP>Нет.
Что неверно-то?
EP>·>Ты вообще читал-то сам что это, прежде чем предлагать это как возможность кодогенерации в Плюсах? "a simplified, C-like sub-language with first-class arrays and no pointer arithmetic" — так ещё никто Плюсы не оскорблял. EP>Я не предлагаю это как возможность, я лишь показываю что это без проблем реализуется. В частности в приведённом примере реализован библиотечный runtime DSL, AST которого налету оптимизируется под конкретные данные, и компилируется для CPU или GPU.
Фигня какая-то. На C++ написан JVM JIT, но как мне кажется, что это не значит, что сам C++ умеет JIT.
EP>·>Компилятор не является частью языка или платформы. javax.tools.JavaCompiler — является. Вот когда появится std::cpp_compiler или ладно, я даже согласен на boost::cpp_compiler — поговорим. EP>·>Плюс ещё java.lang.instrument есть. EP>А зачем ты ставишь какие-то непонятные искусственные рамки сферической платформы? Вот make — это часть чего? А Clang? А почему его нельзя таскать с собой? EP>Есть например Cling — интрепретатор/JIT C++ на базе Clang, посылай ему код и выбирай нужный уровень оптимизации
Ок. Я изобрёл способ, как можно ускорить любую Java-программу до производительности нативного кода: public static void main() {runClang("your app code here");}
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>·>Да те же хаки как и в плюсах V>>В плюсах без хаков. ·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче?
Речь как раз о том, что в разных языках различные по удобству средства выражения статики. В некоторых, типа Python — и вовсе сплошная динамика. В других же типа Java — есть статика, но акцент смещён в сторону динамики. В третьих сильная статика — например C++, D, Nemerle.
Ярчайший пример для иллюстрации — первые версии Java и C# — в них не было Generic'ов, и коллекции представляли из себя по сути List<Object> — так вот получались сплошные касты, хотя казалось бы задача чисто статическая, и языки статически типизированные.
Здравствуйте, vdimas, Вы писали:
V>И всё? )) V>"Сборщик мусора" — это сленг. В первую очередь GC — это менеджер памяти. А собственно GC — лишь одна из подсистем этого менеджера.
Это не сленг. Это перевод на русский расшифрофки этой аббревиатуры: Garbage Collector. Но да, это подсистема.
V>>>·>Что такое "обычный аллокатор" в java? V>>>Это который такой же как для любой нейтивной программы. V>·>malloc в смысле? V>Или HeapAlloc в виндах или mmap в линухах.
И как это всё вообще относится к нашему разговору?
Напомню: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"".
Ты имеешь в виду off-heap хранилища что-ли?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>>>·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. EP>>>>Ещё раз, не язык становится динамическим, а в коде используется больше динамических подходов. Простейшее для понимания утверждение жеж EP>>·>Динамические подходы зависят от задач, а не от языка. EP>>От языка в том числе — так как в одном языке статический полиморфизм реализуется легко, а в другом нет — и как следствие используется динамический ·>CRTP? Я что-то не замечал что он часто используется в С++.
Да не обязательно CRTP — обычный std::partition_point это уже статический полиморфизм.
EP>>·>Использование std::map — динамический подход? EP>>В каком-то смысле да. Точнее его бывает используют для случаев когда все входные данные (а бывает ещё и выходные) известны в статике. В C++ для таких случаев есть например boost::mpl/fusion/hana::map — в которых соответственно бОльшая часть ошибок ловится во время компиляции ·>А можно пример?
EP>>·>Ок, могу согласится, что использование динамических подходов в Java проще, чем в Плюсах. Это что, плохо? EP>>Я не знаю с чем ты соглашаешься, ибо я такого утверждения не делал. Моё утверждение в том что статика на C++ распространённые и легче. EP>>Динамика например немного проще и лаконичней в C# как раз за счёт упомянутого тобой dynamic. ·>Динамикой проще пользоваться в Яве, поэтому и используют чаще чем в Плюсах.
Не так. Там статикой сложнее пользоваться, а местами и вовсе нет выбора. А чуть проще действительно в C#, или например в Python.
EP>>·>Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка. EP>>Это лишь форма. Что это меняет с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок? ·>Что в первой форме ты явно даёшь понять, что это просто литерал, значит компилятор о нём ничего не знает и не проверяет. А во втором случае — ты неявно ожидаешь поддержку со стороны компилятора.
Это всё форма. Повторяю вопрос.
EP>>·>А смысл? Ни автодополнения, ни рефакторингов, ни goto definition, нифига. EP>>Лаконичность динамического кода. Со строками у тебя точно также не будет рефакторингов и т.п. только форма менее удобная и выразительная. EP>>Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John"; ·>Ничем не хуже xml_root.set("person.name", "John");
Ещё раз. Куда должна перейти IDE по "person.name"?
·>И вообще плохая конструкция. Непонятно — а что если <person> может быть список? Что мы меняем?
Зависит от реализации, поинт-то был не в этом
·>Если уж так ратуем за статику, то будь добр опиши класс: ·>class Person {String name;} ·>и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент.
Почему ратуем? Я лишь заявляю что статика на C++ намного доступнее и используется намного чаще чем на Java. И да — больше статики обычно означает больше проверок выполняемых компилятором.
При этом динамические фишки вполне имеют своё применение (в то числе C# dynamic) — я например сам использую в том числе Python и Lisp
EP>>>>Ты не понимаешь о чём речь. И на C++ можно писать с кучей динамики, более того можно вообще дёргать eval какого-нибудь динамического языка. EP>>>>Речь же о том что обычно на Java больше динамики чем на C++, а не о том что у него типизация динамическая. EP>>·>Так какой такой особенной динамики? EP>>·>Может ты имеешь в виду рефлексию? EP>>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится. ·>Ну пока ещё не добавили. А runtime рефлексия заменяет compile-time при наличии runtime кодогенерации.
Не заменяет. В частности ошибки у тебя будут ловится только на стадии runtime кодогенерации
EP>>Зачем m4? — это у тебя какие-то предрассудки. Без проблем для этих целей используется например Python, либо напрямую, либо через шаблонизатор типа Jinja, либо и вовсе препроцессор типа Cog. В систему сборки это добавляется одной строчкой ·>m4 или Пайтон — не большая разница. Приходится тащиь ещё один инструмент, что усложняет инфраструктуру. (например, теперь помимо Плюсов нам нужен ещё и Пайтон ставить,
Обычно Python уже так или иначе используется в процессе сборки, да и поставить не проблема.
·>да ещё поди библиотеки какие-нибудь к нему).
Вообще не проблема — pip install dependency
EP>>>>Ты опять не понимаешь о чём речь. EP>>·>Тут мне vdimas говорил, что в Java программе чаще используются касты (похоже, там у них специальный человек с плёткой стоит и заставляет всех касты в java код вставлять). EP>>Это из-за того что типы чаще стираются, отсюда и касты. ·>Ты про дженерики что-ли?
Нет, я не про то что там под капотом стирание типа (это не так сильно влияет). Я например про использование типа Base вместо Derived.
EP>>>>Дело не в UB или ещё в чём-то (в одной из форм dynamic_cast как раз исключение) — ещё раз посмотри на dynamic_ec.call — там никакого UB. EP>>·>Ок. В чём тогда разница между Явой и плюсами в этом смысле? EP>>Разница в том что в C++ больше статических выразительных средств, многие библиотеки имеют именно статические интерфейсы, и по факту намного меньше стирания типов за счёт повсеместного использования параметрического полиморфизма. ·>ABI уже пофиксили?
Какое ABI? Как это относится к обсуждаемой теме?
EP>>·>Ксати, dynamic_cast вообще в Яве не существует. Опять получается, что С++ более динамичный! EP>>Прикалываешься? Там не динамический cast отсутствует, а статический ·>static_cast вообще тупо даёт undefined behaviour в этом случае, т.е. он не проверяет runtime тип, а надеется, что программист знает что делает (правильно проверил доморощенный GetType()).
Иногда тип известен по построению — как в том же CRTP. Иногда он известен через другие механизмы.
·>Какой смысл от него в Яве?
Я тебе объясняю что в Java не dynamic_cast'а нет (как ты утверждаешь), а наоборот static_cast'а.
EP>>>>>>Возможно EP>>>>·>А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик? EP>>>>Твоё утверждение о невозможности — не верно. EP>>·>На текущий момент — верно. EP>>Нет. ·>Что неверно-то?
То что невозможно генерировать код в runtime.
EP>>·>Ты вообще читал-то сам что это, прежде чем предлагать это как возможность кодогенерации в Плюсах? "a simplified, C-like sub-language with first-class arrays and no pointer arithmetic" — так ещё никто Плюсы не оскорблял. EP>>Я не предлагаю это как возможность, я лишь показываю что это без проблем реализуется. В частности в приведённом примере реализован библиотечный runtime DSL, AST которого налету оптимизируется под конкретные данные, и компилируется для CPU или GPU. ·>Фигня какая-то. На C++ написан JVM JIT, но как мне кажется, что это не значит, что сам C++ умеет JIT.
Ещё раз — смотри Cling — это JIT для языка C++.
·>что это не значит, что сам C++ умеет JIT.
Что значит сам умеет? C++ отранслированный в JavaScript и запущенный в V8 — он как, умеет JIT или нет?
EP>>·>Компилятор не является частью языка или платформы. javax.tools.JavaCompiler — является. Вот когда появится std::cpp_compiler или ладно, я даже согласен на boost::cpp_compiler — поговорим. EP>>·>Плюс ещё java.lang.instrument есть. EP>>А зачем ты ставишь какие-то непонятные искусственные рамки сферической платформы? Вот make — это часть чего? А Clang? А почему его нельзя таскать с собой? EP>>Есть например Cling — интрепретатор/JIT C++ на базе Clang, посылай ему код и выбирай нужный уровень оптимизации ·>Ок. Я изобрёл способ, как можно ускорить любую Java-программу до производительности нативного кода: public static void main() {runClang("your app code here");}
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>>>> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP S>>>>·>Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет. S>>>>·>ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает. S>>>> Ну вот видишь уже подвижка. Согласился что нужен натив для андроида. S>>·>Нужен не натив как таковой, а АОТ. А вот у тебя подвижек нет, с терминами полный швах — AOT != натив. Подумай на досуге, что является результатом работы JIT? S>>JIT-компиляция (англ. Just-in-time compilation, ·>Ок. Подытож двумя словами: Что является результатом работы JIT? Что является результатом работы AOT?
·>И ещё попробуй понять как из приведённой тобой информации можно сделать вывод, что "JIT не сильно оптимизирующий компилятор"?
Ты С++ приложения компилировал? Какова скорость компиляции? S>>>> Специально для тебя выделил твои же слова. S>>·>У тебя путаница с ЖЦ приложения. S>> Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить? ·>Да, может ускорять. Дальше что? Как это влияет на жизнь батареи в типичном юзкейсе?
Быстрее запуск, значит меньше затрат на компиляцию. Некоторые приложения грузятся минутами.
Опять же JIT оптимизатор на мобильных устройствах будет жрать энергию еще и во время выполнения.
и солнце б утром не вставало, когда бы не было меня
_>Да, и главное: даже если бы ты тут и указал бы что-то реально дельное (кстати та же avalonia выглядит вполне перспективно), то это всё равно не имело бы никакого отношения к тому факту, что .net core и т.п. — это огрызки полноценного .net.
Проблема WPF в том, что он прибит к DirectX. Поэтому процессоры для Win Mo должны поддерживать DirectX.
Ну и оновное направление сейчас это не Декстоп. https://habrahabr.ru/post/313202/
Здравствуйте, ·, Вы писали:
V>>·>Да те же хаки как и в плюсах V>>В плюсах без хаков. ·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче?
Вопрос, надо полагать, риторический?
V>>·>виртуальный GetType V>>И без GetType. V>>Да и большинство типов идут без таблицы виртуальных ф-ий. ·>А моки как делаются?
На уровне исходников или через подмену реализации в процессе линковки.
Помнишь был такой термин — "заглушка"?
Никакие виртуальные ф-ии для заглушки не нужны.
·>Большинство классов в Java обычно ни от чего не наследуются, т.е. виртуальность не используется.
Да просто dynamic_cast<> работает в С++ только для классов с vtable.
Прямо отсюда можно восстановить логику моих уточнений.
V>>·>или хитроумные макросы, сам же мне C++ ORMы показывал — страх и ужас же. V>>Не ужаснее описания маппинга на XML, с той разницей, что компилятор статически проверяет соответствие по крайней мере со стороны типов С++. ·>Соответствие типов чему?
Исходнику.
·>Пишешь pojo-класс с нужными типами полей — он и маппится. Что ещё за описание?
Это маппинг на структуры, считай, что не всегда удобно и вообще не является ORM, положа руку на. Массив таких структур можно считать за "типизированный рекордсет".
Собсно, чем мне нравится низкоуровневый ORM в С++, что не происходит переливания из пустого в порожнее. В Джаве сначала драйвер заливает входной стрим в нетипизированный рекордсет, да еще боксирует простые типы. А потом ORM копирует эти данные в типизированный рекордсет. Низкоуровневый С++ маппинг заливает данные с входного стрима сразу в типизированном виде. Разница чудовищная. В обратную сторону аналогично. Отмазки насчет "SQL-сервак и так долго пашет" — херь собачья, MS SQL выдаёт данные со скоростью файловой системы — надо успевать принимать. Управляемые среды не успевают.
V>>·>Ещё раз повторяю, что "динамика" как ты называешь идёт не от языка, а от задачи. V>>От способа решения задачи, т.е. от доступного инструментария в языке. ·>Выбор способа лежит на тебе, как программисте.
Выбор языка лежит на тебе, как программисте. А затем уже всё, особо не порыпаешься.
V>>·>Ага. Шаблоны. Так бы сразу и сказал. Да, в С++ метапрограммирование развито сильнее. Непонятно почему ты это называешь динамичностью. V>>Это, наоборот, называется статичностью. В C++ прилично логики и проверок переносят в compile-time, вот и вся разница, собсно. V>>ОК, больше не буду грузить подробностями. ·>Это называется выразительностью системы типов. Динамика это возможность менять типы объектов или систему типов в рантайм.
Динамика, это, в первую очередь, нарушение принципа подстановки Лисков.
Чем это грозит было уже обсосано миллион раз неглупыми опытными людьми.
В этом смысле принятые в Джава способы проектирования архитектуры и реализации — это антипаттерн для самой парадигмы ООП. Средняя надёжность джавовских программ после их выкатывания близка к 0-лю обычно. Глюки на глюках, падения, репорты и т.д. Зато выхода за пределы массивов нет! Вернее, в коде-то их полно...
В общем, я в разные годы много посидел на разных джавовских программах. Должно пройти примерно лет 5 поддержки, чтобы джавовский продукт перестал глючить. Это верно для любой более-менее крупной джава-программы. Все эти JBoss когда-то, Tomcat, невероятно падучие Together и VisualAge (сейчас Eclipse) — список можно продолжать бесконечно. А ведь это ведущие джавовские продукты каждый в своё время, собсно. ))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ярчайший пример для иллюстрации — первые версии Java и C# — в них не было Generic'ов, и коллекции представляли из себя по сути List<Object> — так вот получались сплошные касты, хотя казалось бы задача чисто статическая, и языки статически типизированные.
Дык, у них все базовые интерфейсы, на которых вообще всё построено — нетипизированные.
Смешно же:
public void notifyObservers(Object arg)
Ошибка прилетит только в рантайме, если аргумент не того типа.
Здравствуйте, vdimas, Вы писали:
V>·>Нет, хоть какие-нибудь реальные цифры, хоть что-то похожее на проверяемые факты, а не простое форумное блаблабла. V>Я тебе именно факты привел. V>Контора продаёт нейтивные, дотнетные и джавовские решения, нейтивных намного больше.
Может просто ваше джава решение не лучшее? И за джавой идут к другим?
V>·>Я могу например предложить погуглить HFT-позиции — java составляет не менее трети, остальное native, c# — в микроскоп не видно, и в основном GUI (что не совсем HFT в общем-то). Притом многие позиции в top 10 IB, а их бедными назвать язык не поворачивается. V>Да где ты там треть увидел-то? )) V>http://www.indeed.com/q-High-Frequency-Trading-Developer-jobs.html
181 jobs http://www.indeed.com/q-High-Frequency-Trading-Developer-java-jobs.html
51 jobs
51/181 = 28%.
Ещё посмотри "low latency developer". Там даже где-то половина.
V>>>Я не могу уловить, где именно ты проводишь границу. Похоже, прямо по Джаве, ы-ы-ы. )) V>·>По Language Specification, очевидно. V>В самом языке нет потоков. А вот в системной библиотеке, являющейся частью стандарта, уже есть.
Прежде чем заявлять очередную глупось — погугли хоть 10 сек. Ключевое слово "jls-17".
Ещё намёк — в каком пакете находится класс Thread?
А вот всякие сетевые сокеты, файлы, коллекции, регекспы и прочее — да, это часть стандартной библиотеки, а не языка.
Это кстати одно время в упрёк Яве ставили, что мол треды — неотъемлемая часть языка. Даже такое чудо как green threads было.
V>>>·>Шустрость не нужна разве? Ведь dotnet уже почти работает быстрее натива... V>>>Шустрость джаве нужна, конечно. Но, боюсь у меня для тебя плохие новости. В этом плане в Джаве не ожидается НИЧЕГО в ближайшие лет 10 уж точно. V>·>Не увиливай. Почему HTTP не реализован с unsafe, а в FIX приходится? В HTTP не нужна шустрость? V>Я тебе уже ответил, но ты не понял ни слова, как обычно. V>
V>асинхронные сокеты на IOCP реализованы в нейтиве
Причём тут вообще сокеты? Зачем ты упомянул их? Как они с протоколами HTTP или FIX связаны?
В смысле у вас только IOCP сокеты в нативе, а всё остальное на c#? Ты же сам говорил, что синхронизация, многопоточность и управление памятью тоже нативные.
V>·>Врёшь. Или цитату в студию. V>Вот твоя цитата: V>
V>Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора
V>Очевидно, что ты НЕ понимаешь, что есть дисраптор и на какой именно тест я дал тебе ссылку.
Что за упрямое невежество? Я прекрасно понимаю что такое дизраптор, использовал лично.
V>·>"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные. Ссылку которую ты привёл в качестве "доказательства" — дизраптор не использовался вообще. V>Это и есть дисраптор. Это его базовый Lego-кубик (один из 3-х, вернее, с идентичным интерфейсом).
А доказать?
V>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди, ссылку на тест которой (очереди) я тебе дал.
Бред. Ты дал ссылку на тест, который реализует three producers -> one consumer используя стандартный BlockingQueue.
С дизраптором подобный тест в соседней папочке: https://github.com/LMAX-Exchange/disruptor/blob/master/src/perftest/java/com/lmax/disruptor/sequenced/ThreeToOneSequencedThroughputTest.java Вот тут используется RingBuffer и SequenceBarrier, которые собственно и образуют дизраптор.
А вот результаты запуска этих тестов и сравнения результатов:
Здравствуйте, ·, Вы писали:
·>Скажем, в том же Вебе — всё динамика
Откуда?
·>поэтому удивительно ожидать там статических библиотек.
Но они есть.
·>А в Вебе как раз Плюсы чувствуют себя несколько некомфортно.
Утверждение устарело лет на 15.
EP>>Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John"; ·>Ничем не хуже xml_root.set("person.name", "John"); ·>И вообще плохая конструкция. Непонятно — а что если <person> может быть список? Что мы меняем? Если уж так ратуем за статику, то будь добр опиши класс: ·>class Person {String name;} ·>и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент.
Дык, XmlDocument он и есть. Даешь ему схему и пусть выполняет всю "магию".
EP>>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится. ·>Ну пока ещё не добавили.
Сторонних инструментов хватает.
EP>>Стирание типов. Например с последующими dynamic cast'ами и runtime проверками, вместо параметрического полиморфизма и статических проверок (перегрузки, static_assert, etc). ·>Тоже решение. Но явно не "безупречно лучшее".
Прикольный у тебя стиль ведения разговора. ))
·>Ок. Я изобрёл способ, как можно ускорить любую Java-программу до производительности нативного кода: public static void main() {runClang("your app code here");}
Здравствуйте, ·, Вы писали:
·>Здравствуйте, vdimas, Вы писали:
V>>И всё? )) V>>"Сборщик мусора" — это сленг. В первую очередь GC — это менеджер памяти. А собственно GC — лишь одна из подсистем этого менеджера. ·>Это не сленг. Это перевод на русский расшифрофки этой аббревиатуры: Garbage Collector.
Это и есть общепринятый сленг. Но речь-то всегда идёт о менеджере памяти.
·>И как это всё вообще относится к нашему разговору? ·>Напомню: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"".
Именно так.
·>Ты имеешь в виду off-heap хранилища что-ли?
Я имею ввиду обычную кучу, вне кучи GC.
Чем куча GC отличается от обычной?
Здравствуйте, netch80, Вы писали:
S>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего. N>Судя по его словам, у него C++, C++/CLI и C#. Так что реально 3 языка, хоть и достаточно близких.
Реально языков периодически бывает много: Баши/Cаши, JS, Perl, Phyton, Make/CMake и даже любой XML с развесистой схемой, типа как в билдере Ant — это тоже полноценный язык. А обернуться назад и посмотреть за всю карьеру, так еще пару десятков наберется.
В общем, это какой-то упоротый бред рассуждать об "одном языке для всего". Это ж банально неудобно.
Здравствуйте, ·, Вы писали:
S>> Да можно такую же БД написать и на Net только какой в этом смысл, ·>Можно ли?
Можно.
·>Есть ли БД написанные на .net? Если нет, то почему?
RavenDB, к примеру.
Ну а сообще это бред, как по мне.
.Net изначально ориентировано на интероп/гетерогенность.
Молоток плохо заменяет плоскогубцы и обратно тоже верно.
·>А что значит "держать данные в БД"? БД это не волшебный сундук подаренный инопланетянами, а тоже программа, и тоже написанная на ЯП. Притом есть БД написанные и на C/C++ и на Java, в этих языках почему-то 200мб без проблем дефрагментируются. А вот в .net ВНЕЗАПНО появляются сложности и надо просить помощи у native или java... место проклятое, не иначе.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
V>>>В плюсах без хаков. EP>·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче? EP>Речь как раз о том, что в разных языках различные по удобству средства выражения статики. В некоторых, типа Python — и вовсе сплошная динамика. В других же типа Java — есть статика, но акцент смещён в сторону динамики. В третьих сильная статика — например C++, D, Nemerle.
Интересная классификация. А C куда отнесёшь?
EP>Ярчайший пример для иллюстрации — первые версии Java и C# — в них не было Generic'ов, и коллекции представляли из себя по сути List<Object> — так вот получались сплошные касты, хотя казалось бы задача чисто статическая, и языки статически типизированные.
Касты не означают динамику, каст это приведение типов. Динамика это возможность изменения типов объектов в рантайм. Тип _объекта_ ни в одном из перечисленных языков менять нельзя (только в Питоне). Object o = new String() — тип "o" будет тип String, изменить ты это не сможешь, хоть лопни. И ты можешь вызывать только методы этого типа. И ничего изменить не можешь в рантайме. Разница между C++ и Java будет лишь в том, что неверное приведение типа в C++ — UB, а в Java — exception. Всё.
Даже RTTI это тоже не динамика.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче? EP>>Речь как раз о том, что в разных языках различные по удобству средства выражения статики. В некоторых, типа Python — и вовсе сплошная динамика. В других же типа Java — есть статика, но акцент смещён в сторону динамики. В третьих сильная статика — например C++, D, Nemerle. ·>Интересная классификация. А C куда отнесёшь?
В Cи зависит от того, какой код пишешь
переменная принимает значения разных типов — динамический, фактически, тип связан со значением и компилером не проверяется
пишешь так, что значения только правильных типов — статический, здесь тип связан с переменной и проверяется компилятором
Если раскладываешь всякие касты, то получается своего рода мягкая система типов, ни статика, ни динамика.
EP>>Ярчайший пример для иллюстрации — первые версии Java и C# — в них не было Generic'ов, и коллекции представляли из себя по сути List<Object> — так вот получались сплошные касты, хотя казалось бы задача чисто статическая, и языки статически типизированные. ·>Касты не означают динамику, каст это приведение типов.
Все зависит от того, какой тип компилятор предпочитает по дефолту. Иногда это object(any и тд), иногда — точный(string, List). Когда первое, это динамика. Когда второе — статика.
Здравствуйте, ·, Вы писали:
S>>JIT-компиляция (англ. Just-in-time compilation, ·>Ок. Подытож двумя словами: Что является результатом работы JIT? Что является результатом работы AOT?
·>И ещё попробуй понять как из приведённой тобой информации можно сделать вывод, что "JIT не сильно оптимизирующий компилятор"?
S>>>> Специально для тебя выделил твои же слова. S>>·>У тебя путаница с ЖЦ приложения. S>> Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить? ·>Да, может ускорять. Дальше что? Как это влияет на жизнь батареи в типичном юзкейсе?
В целом изжержки на джыт вполне осязаемы. Обычно джыт идет где то в первых трех позициях по расходу процессора и памяти, если верить профайлеру. Издержки меньше, чем от ГЦ, но тем не менее заметные.
_>Да, и главное: даже если бы ты тут и указал бы что-то реально дельное (кстати та же avalonia выглядит вполне перспективно), то это всё равно не имело бы никакого отношения к тому факту, что .net core и т.п. — это огрызки полноценного .net.
С хабра https://habrahabr.ru/post/313202/?reply_to=9871552#comment_9871506
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>>>·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. static_cast<C &>(a) — компилятор не проверяет, что a имеет тип B, но а не тип C. Ну точно С++ — динамический!
EP>>>·>Динамические подходы зависят от задач, а не от языка. EP>>>От языка в том числе — так как в одном языке статический полиморфизм реализуется легко, а в другом нет — и как следствие используется динамический EP>·>CRTP? Я что-то не замечал что он часто используется в С++. EP>Да не обязательно CRTP — обычный std::partition_point это уже статический полиморфизм.
Ну method overloading это тоже статический полиморфизм. Может внутренняя имплементация не так элегантна как в Плюсах, но Arrays.binarySearch внешне выглядит точно так же.
EP>>>В каком-то смысле да. Точнее его бывает используют для случаев когда все входные данные (а бывает ещё и выходные) известны в статике. В C++ для таких случаев есть например boost::mpl/fusion/hana::map — в которых соответственно бОльшая часть ошибок ловится во время компиляции EP>·>А можно пример? EP>Простой пример (live demo)
Интересно. А что с этим можно делать? Чем литерал "lambda"_s лучше lambda_s? Минус видно сразу — IDE сразу сложит ручки.
EP>>>·>Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка. EP>>>Это лишь форма. Что это меняет с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок? EP>·>Что в первой форме ты явно даёшь понять, что это просто литерал, значит компилятор о нём ничего не знает и не проверяет. А во втором случае — ты неявно ожидаешь поддержку со стороны компилятора. EP>Это всё форма. Повторяю вопрос.
Так любом ЯП это форма на первом месте. Когда текст программы выглядит _ожиданно_, принцип наименьшего удивления.
ЯП в первую очередь нужен не для компьютера (который может отлавливать ошибки), а для человека, чтобы он читая текст программы сразу понимал что делается в данной строчке кода, плюс IDE в помощь в наборе/навигации кода. Поэтому форма чрезвычайно важна.
EP>>>Лаконичность динамического кода. Со строками у тебя точно также не будет рефакторингов и т.п. только форма менее удобная и выразительная. EP>>>Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John"; EP>·>Ничем не хуже xml_root.set("person.name", "John"); EP>Ещё раз. Куда должна перейти IDE по "person.name"?
В том то и дело что некуда. Потому что это по сути текст в выводе программы, как и "John".
EP>·>И вообще плохая конструкция. Непонятно — а что если <person> может быть список? Что мы меняем? EP>Зависит от реализации, поинт-то был не в этом
В этом тоже есть поинт — непонятная конструкция, непонятно что делает.
EP>·>Если уж так ратуем за статику, то будь добр опиши класс: EP>·>class Person {String name;} EP>·>и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент. EP>Почему ратуем? Я лишь заявляю что статика на C++ намного доступнее и используется намного чаще чем на Java. И да — больше статики обычно означает больше проверок выполняемых компилятором. EP>При этом динамические фишки вполне имеют своё применение (в то числе C# dynamic) — я например сам использую в том числе Python и Lisp
Ок, я наверное просто к терминологии прикапываюсь. Выразительность системы типов я не отношу к статичности/динамичности. Ты, видимо, относишь (мне непонятно почему). В общепринятой терминологии так не принято.
EP>>>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится. EP>·>Ну пока ещё не добавили. А runtime рефлексия заменяет compile-time при наличии runtime кодогенерации. EP>Не заменяет. В частности ошибки у тебя будут ловится только на стадии runtime кодогенерации
Какие конкретно ошибки? И что, например, у тебя сможет поймать компилятор в xml_root.person.name = 3.1415926;?
EP>>>Зачем m4? — это у тебя какие-то предрассудки. Без проблем для этих целей используется например Python, либо напрямую, либо через шаблонизатор типа Jinja, либо и вовсе препроцессор типа Cog. В систему сборки это добавляется одной строчкой EP>·>m4 или Пайтон — не большая разница. Приходится тащиь ещё один инструмент, что усложняет инфраструктуру. (например, теперь помимо Плюсов нам нужен ещё и Пайтон ставить, EP>Обычно Python уже так или иначе используется в процессе сборки, да и поставить не проблема.
Т.е. что инфрасткрутура более сложная для Плюсов — ты согласен?
EP>·>да ещё поди библиотеки какие-нибудь к нему). EP>Вообще не проблема — pip install dependency
Ага, ещё один пунктик в многостраничый документ для new joiners.
EP>>>Это из-за того что типы чаще стираются, отсюда и касты. EP>·>Ты про дженерики что-ли? EP>Нет, я не про то что там под капотом стирание типа (это не так сильно влияет). Я например про использование типа Base вместо Derived.
Не понял.
EP>Какое ABI? Как это относится к обсуждаемой теме?
Да, это другая тема. Игнорь.
EP>·>static_cast вообще тупо даёт undefined behaviour в этом случае, т.е. он не проверяет runtime тип, а надеется, что программист знает что делает (правильно проверил доморощенный GetType()). EP>Иногда тип известен по построению — как в том же CRTP. Иногда он известен через другие механизмы.
Как и в java.
EP>·>Какой смысл от него в Яве? EP>Я тебе объясняю что в Java не dynamic_cast'а нет (как ты утверждаешь), а наоборот static_cast'а.
Ах. в этом смысле... Ты говоришь, как будто это что-то хорошее. static_cast даёт UB, и хорошо что нет.
EP>>>Нет. EP>·>Что неверно-то? EP>То что невозможно генерировать код в runtime.
Ну так невозможно же. Вызов компилятора из командной строки это не кодогенерация. Как кстати потом этот сгенерированный код запустить? DLL-ку собранную подгрузить? Ну чтоб от антивирусника по ушам схлопотать? Или на DEP нарваться?
EP>>>Я не предлагаю это как возможность, я лишь показываю что это без проблем реализуется. В частности в приведённом примере реализован библиотечный runtime DSL, AST которого налету оптимизируется под конкретные данные, и компилируется для CPU или GPU. EP>·>Фигня какая-то. На C++ написан JVM JIT, но как мне кажется, что это не значит, что сам C++ умеет JIT. EP>Ещё раз — смотри Cling — это JIT для языка C++.
Ок, но это не часть языка. Это просто "библиотека". Этот же cling можно из java использовать ровно с тем же результатом.
EP>·>что это не значит, что сам C++ умеет JIT. EP>Что значит сам умеет? C++ отранслированный в JavaScript и запущенный в V8 — он как, умеет JIT или нет?
Не умеет. Это не часть языка.
EP>·>Ок. Я изобрёл способ, как можно ускорить любую Java-программу до производительности нативного кода: public static void main() {runClang("your app code here");} EP>Осталось всего лишь C++ код для runClang написать
Это уже мелочи. Главное Java будет работать со скоростью натива!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>Ок. Подытож двумя словами: Что является результатом работы JIT? Что является результатом работы AOT?
S>·>И ещё попробуй понять как из приведённой тобой информации можно сделать вывод, что "JIT не сильно оптимизирующий компилятор"? S> Ты С++ приложения компилировал? Какова скорость компиляции?
Ты мне предлагаешь по скорости компилятора судить о качестве оптимизации??!
Пиши тогда на Скале, у неё тоже медленный компилятор.
S>>> Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить? S>·>Да, может ускорять. Дальше что? Как это влияет на жизнь батареи в типичном юзкейсе? S> Быстрее запуск, значит меньше затрат на компиляцию. Некоторые приложения грузятся минутами. S> Опять же JIT оптимизатор на мобильных устройствах будет жрать энергию еще и во время выполнения.
ART это AOT, а не JIT. dalvik был с JIT, но его заменили на ART.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Контора продаёт нейтивные, дотнетные и джавовские решения, нейтивных намного больше. ·>Может просто ваше джава решение не лучшее? И за джавой идут к другим?
Наше лучшее. Просто самих таких клиентов резко меньше и они обычно не крупные.
А всякие JP-Morgan и прочие крупные клиенты нейтивные.
В общем, на первой странице из 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.
Кинь мне плиз мою ссылку.
·>
·>
·>
·>
Array Blocking Queue
·>
Disruptor
·>
·>
·>
Sequencer: 3P – 1C
·>
5,539,531
·>
13,403,268
·>
·>
Результаты ни о чем. У меня примерно в 20 раз улучшение быстродействия по сравнению с нейтивным аналогом BlockingQueue.
Да, я теперь внимательно посмотрел исходник и охренел.
Слишком большой штраф за абстракции.
Дорогие операции "записи" в буфер.
Писали нубы, нихрена не соображающие в устройстве современных систем. ))
Там должна была быть тривиальнейшая из всех тривиальных lock-free схема, причем, они же правильно описали — каждый раз забираем ВСЕ имеющиеся данные. Т.е. достаточно взять lock-free stack и забирать все данные за раз, чтобы не опасаться ABA-проблемы. Такая схема вдвое дешевле при записи и фактически совсем бесплатна при чтении.
Ну и столько абстракций прилепить на две простейшие операции... Я же говорю, это уже вижуал бэйсик какой-то, а ты не верил. ))
Кароч, не ведись на всю вот эту херню, на LMAX и прочие громкие названия. Не боги горшки обжигают, а нубы и лохи, по большей части.
Причем, тут на сайте полно было обсуждений lock-free, где можно было действительно почерпнуть что-то полезное и ПРИВНЕСТИ это полезное в свой продукт. Вместо этого ты взял некую нубскую либу и хвастаешься этим.
Мне вообще кажется, что они нашли, таки, нормальное решение (оно давно уже не секрет), и отдали старое своё решение в опенсорс.
Кароч, если нужен настоящий хардор, пишите в личку, пообщаемся.
Вот make — это часть чего? А Clang? А почему его нельзя таскать с собой?
Вернее, в коде-то их полно...
