Здравствуйте, Serginio1, Вы писали:

_>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
S> JS может вытестнить https://ru.wikipedia.org/wiki/WebAssembly

Это касается только JS в браузере. А скажем на сервере у JS нет никаких врождённых преимуществ, но тем не менее node.js цветёт и пахнет.

S> А TypeScript сам по себе лучше JS. И его кстати многие выбирают.

TypeScript — это не отдельный язык, а надстройка над JS. Т.е. это часть его мира, как раз усиливающая его. Собственно появление TS должно вызывать ещё большие опасения у любителей Java/C#, т.к. приводит в лагерь JS ещё и фанатов статической типизации.

S> У .net есть .Net Native и .Net Core которые очень активно развиваются

При появление в 2001-ом году это вполне могло сработать. Но не сейчас. )

Здравствуйте, Serginio1, Вы писали:

S>>> Хотя лично считаю, что для этого лучше всего подойдет C++ с хорошим менеджером памяти.
S>·>Т.е. .net не подходит. Что и требовалось доказать. Считаю вопрос закрытым.
S> Мне интересно не .Net, а как с этим справляется твоя хваленая Java
Хорошо справляется с помощью zing. Azul обещает задержки <10ms. Ты считаешь, что они лгут?

S> особенно в сравнении с кодом на C++
Тебе интересно, ты и сравнивай. Создавай новый топик, ищи оппонетнов и там рассуждай. Тут мы обсуждаем "dotnet vs java".

S>На этом самом алгоритме. При этом я могу сделать класс на C++
И накой когда сдался .net? Шоб було?

S> и из .Net дергать его методы.
Круто, конечно. И что конкретно ты будешь измерять? Цель тех тестов — измерить характеристики GC, его применимость для LL-систем.
Методы явы тоже можно из С++ дёргать. И что?

S>При этом у меня будут потери только на копировании, но в задержек не будет. Так, что .Net подходит.
Ровно до того момента как сработает GC.

S>https://msdn.microsoft.com/en-us/library/ms235281.aspx
S>А считать то голословно ты можешь, что угодно.
Голословен пока только ты. И всё от сабжа постоянно уходишь в сторону нейтива.

Здравствуйте, vdimas, Вы писали:

V>·>Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым).
V>Как правило для публичного интерфейса к таким структурам — массивам байт все-равно идут ref-объекты (кроме числовых и булевских значений), т.е. КАЖДАЯ операция чтения или записи полей такой структуры часто сопровождается созданием ref-объекта.
Может и "как правило", но не обязательно (собственно как и в C++). Просто не делай так если важно LL.

V>·>Если же замутить что-то навороченное даже на плюсах — с классами, с наследованием, виртуальными функциями, овнершипством, то в итоге получится то же самое — индирекции, перемешивание, проблемы удаления и прочие приседания. Чудес не бывает.
V>Плюсы — это мультипарадигменный язык, позволяющий играть дизайном как душе будет угодно. Виртуальные ф-ии нужны исключительно для абстрактных типов, ну или заменой им можно считать лямбды и прочие std::function.
V>Вот у тебя некий пост-процессор данных может быть таким абстрактным функциональным типом, но через это пост-процессор прогоняются вполне себе "плоские" данные. Стоимость вызова std::function примерно равна стоимости одного виртуального вызова, т.е. порядка 2-3ns в цикле для современной техники.
Ок. А можно ближе к сабжу?

V>·>Угу. Зато работает, а это — самое важное. И ещё раз повторяю, это будет малой долей всего кода системы.
V>Да не работает оно. Индексы разметки все-равно в виде ref-типов хранятся.
Ну например индекс разметки [FIX tag]->[позиция в буфере сообщения] может храниться как "new int[65536]" (tag id в fix == 2 байта) и этот самый массив в единственном экземпляре может жить в gen2 и в кеше вечно.

EP>>>Не помню точную цитату, но суть в следующем — на заре вычислительной техники кто-то возмутился по поводу компиляторов языков (что-то типа Fortran или Algol) мол зачем нагружать компьютер той рутинной работой (компиляцией), с которой хорошо справляются девушки.
V>·>Вброс: зачем нагружать компьютер той рутинной работой (сборкой мусора), с которой хорошо справляются сиплюсплюсники.
V>Скажи, неужели все эти вещи ни разу не интересны? ))
Интересны, но не в этой теме. Здесь мы обсуждаем dotnet vs java.

EP>>>Так вот эти нарезатели байт-буферов прям как те самые девушки занимаются рутинной механической работой, с которой прекрасно справляются компиляторы, тем более в 2016.
V>·>И сейчас с супер-пупер код написанный для компьютера, а не для человека (ака оптимизированный код) выглядит плохо по сравнению с остальным кодом, даже в плюсах.
V>В плюсах это не так.
V>Самый жутко-оптимизированный код выглядит как совершенно обычный, например:
V>

V>MyType * obj = new(context) MyType(args);
V>

И что? А что в этом коде необычного?

V>·>Возможно что аналогичный плюсовый код был бы лучше явового, но другие достоинства managed кода и gc перевешивают недостаток "плохо выглядещего" кода.
V>Ты зря считаешь, что вся фишка управляемых сред только в GC. Это серьезное заблуждение. Фишка управляемых сред в огромных писанных под них библиотеках/фреймворках. А такое стало возможным не только и не столько из-за ПС, сколько из-за сознательной изолированности от конкретного железа/архитектуры и освобождения от вот этих гирь "необходимости соблюдать совместимость/портируемость". Ну и плюс чудовищные финансовые вложения, ес-но. Ну и плюс всё это было отдано Sun людям даром, хотя в итоге были затрачены сотни миллионов на разработку. Это щедрый прощальный предсмертный подарок этой конторы.
Я и не говорил, что только в GC, я так не считаю. Не приписывай мне ложных высказываний.

Здравствуйте, alex_public, Вы писали:

_>В особенности это касается Java с её escape-анализом, который при срабатывание (абсолютно не гарантированном, но всё же) позволяет достигать даже большей чем у C# локальности (прямо как у правильного C++ кода). Более того, там даже есть парочка мелких забавных трюков, которые не реализуемы (в смысле автоматически, компилятором, — руками то можно что угодно) даже на C++. Естественно в целом это не позволяет Java коду обходить C++, но сам факт любопытен. Ну а уж помочь обогнать обычный (не оптимизированный специально) C# код это позволяет без проблем.

Escape анализ не умеет преобразовывать массив ссылок на ссылки на etc в плоский массив байт. Собственно поэтому на Java и нарезают вручную байт-буфера на структуры, потому что автоматически это не происходит и является источником жёстких тормозов. Не было бы это серьёзной проблемой — никто бы и не извращался. На C# же есть какие-никакие структуры.
Профит от escape анализа какой-то действительно есть, но отсутствие косвенности в данных на порядок важнее.

Здравствуйте, vdimas, Вы писали:

Почитал внимательнее...

V>Причем, стратегия mark-and-sweep, принятая в управляемых средах, — она же самая тормозная, разве нет. Но тоже доступна в виде готовых либ.
m&s не единственная, а фактически самая примитивная и наивная реализация.

V>Просто сравни mark-and-sweep со стратегией "регионального аллокатора":
V>- пришел запрос, ты берешь такой аллокатор из пула аллокаторов и инициализируешь им поле созданного на стеке по значению некоего "контекста" запроса (этот "контекст" почти всегда есть в серверных приложухах);
V>- обрабатываешь пришедший запрос, где везде как аргумент протягивается этот самый аллокатор как часть контекста;
V>- затем выплёвываешь результат обратно в сетку;
V>- возвращаешь аллокатор в пул.
V>Всё! Никакой операции по уборке мусора нет. Если мы вернули аллокатор в пул, то считается, что мы весь мусор, связанный с обработкой этого запроса, как бэ и убрали уже, всё... хотя НИКАКИХ действий с памятью на самом деле не производили.
Собственно в точности похоже на вручную организованный young gc space. Только вместо того, чтобы компьютер сам искал объекты что является "контекстом запроса" приходится организовывать архитектуру приложения соответственным образом и внимательно следить, чтобы ничего из этого контекста не утекло куда не надо.

V>Никаких тебе shared/unique и прочих _ptr, тупо голые указатели и ссылки. ))
V>Как тебе такой алгоритм уборки "мусора"?
Закат солнца вручную.

V>Вот как это выглядит с т.з. подробностей реализации:
V>- каждый аллокатор хранит несколько относительно крупных страниц памяти, взятых у ОС по наиболее эффективной для неё кратности;
V>- возврат аллокатора в пул означает возврат этих крупных страниц в пул;
V>- сам аллокатор — это лишь value-type обертка над двумя полями-указателями на текущую оперируемую страницу и на сам пул, т.е. берет у пула страницы по мере надобности;
V>- страницы связываются м/у собой в линейный список, но всегда интересует лишь одна текущая страница, остальные считаются уже "израсходованными";
V>- запрос и возврат страниц в пул выполняются на lock-free алгоритмах;
V>- трудоёмкость выделения памяти внутри каждой страницы — это трудоёмкость приращения указателя на кратное машинному слову кол-во байт.

V>По последней операции тоже любопытное замечание: ввиду того, что в плюсах почти всё инлайно, то даже этот несчастный аргумент для приращения указателя "виден" оптимизатору. Источником этого аргумента обычно выступает явная (аналог malloc) или неявная (аналог new) операция sizeof, а эта операция возвращает константу времени компиляции. Т.е., даже эта несчастная операция увеличения курсора внутри страницы максимально эффективна из всех возможных вариантов — к указателю прибавляется константа. ))
Собственно прибавление указателя это и есть способ аллокации в java.

V>Но в реальной жизни всё происходит еще намного-намного циничнее. Если обработкой запросов занимается ТОЛЬКО пул потоков, то у каждого потока уже есть некий личный список страниц памяти — его "буфер". Т.е. никакие аллокаторы, ес-но, ни в какие пулы в таком сценарии возвращать не надо и даже относительно дорогостоящие операции lock-free (там внутри CAS) не нужны. Аллокатор в этом случае хранит всего одно поле — указатель на текущую страницу, где инициализируется первой страницей из пула потока. Если страниц не хватило, то уже в самом аллокаторе будет взята у ОС страница и добавлена в этот однонаправленный список. Усё. Ну и еще плюшки такого сценария — контекст можно протягивать, а можно и нет, ведь он локальный для потока. Это помогает в ситуации, когда надо подцепиться через колбэк-вызов от третьесторонней либы, через которую нельзя протянуть свой контекст.
А это вы изобрели TLAB.

Здравствуйте, vdimas, Вы писали:

V>·>Понятно. Я и имею в виду, что код на java может давать те же показатели, что и нейтив решение.
V>Тебя и поправили — если нейтивный код такой заведомо плохой. Иначе не может.
Теоретически некий код на java и с++ может выдавать идентичный машкод. Никто не запрещает.
А фактически ты же сам привёл документ, в котором сказано, что C++ и Java близки. Там был плохой C++?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Escape анализ не умеет преобразовывать массив ссылок на ссылки на etc в плоский массив байт. Собственно поэтому на Java и нарезают вручную байт-буфера на структуры, потому что автоматически это не происходит и является источником жёстких тормозов. Не было бы это серьёзной проблемой — никто бы и не извращался. На C# же есть какие-никакие структуры.
EP>Профит от escape анализа какой-то действительно есть, но отсутствие косвенности в данных на порядок важнее.
На практике это не является необходимостью. В том же disruptor используется ring buffer (ака большой массив объектов). Работает быстро (по крайней мере _достаточно_ быстро).
Сами объекты могут лежать в памяти локально последовательно (ну и пусть что на них ссылается массив).

Здравствуйте, ·, Вы писали:

V>>По последней операции тоже любопытное замечание: ввиду того, что в плюсах почти всё инлайно, то даже этот несчастный аргумент для приращения указателя "виден" оптимизатору. Источником этого аргумента обычно выступает явная (аналог malloc) или неявная (аналог new) операция sizeof, а эта операция возвращает константу времени компиляции. Т.е., даже эта несчастная операция увеличения курсора внутри страницы максимально эффективна из всех возможных вариантов — к указателю прибавляется константа. ))
·>Собственно прибавление указателя это и есть способ аллокации в java.

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

Здравствуйте, vdimas, Вы писали:

V>* Ваш покорный слуга в течении примерно 14-ти последних лет неоднократно портировал джавовский код на дотнет (более 14 раз). Там несложно. Сразу после портирования я почти всегда получал фактически идентичный по размеру исходник и практически идентичное быстродействие. Однако, из-за более развитых языковых ср-в донета такой портированный код ВСЕГДА подвергался затем нещадному рефакторингу, где объем исходников уменьшался примерно в полтора раза, а быстродействие (из-за агрессивного применения value-types) вырастало обычно от 30% до 50% для простых вещей и до 2-3-х раз для чего-то более сложного. Это как оно есть в реальной жизни.
Тему о быстродействии я не поднимал и спорить не хочу, ибо это бессмысленный холивар. Я возразил о HFT, для которого критичным является low latency. И в этой области факты показывают, что Java преуспевает гораздо лучше c#.
Если ты не понимаешь разницу между быстродействием и LL перечитай топик внимательно. Я несколько раз это объяснял.

V>* Тут появляется некто (даже не знаю, как понимать этот ник) и утверждает, что наличие pure-Джавы в HFT является АРГУМЕНТОМ (о как!!!) о том, что Джава шустрее дотнета, бо в дотнете в HFT рулят гибридные нейтивно-дотнетные решения, что оскорбляет чувство прекрасного эдаких любителей расовой чистоты.
Гибридные C++/Java решения тоже есть. Но они тоже не интересны, ибо Java является просто ничего не делающей обёрткой. А "гибридные нейтивно-дотнетные решения" появились чисто из чувства прекрасного? Или таки из-за того что чистое решение тупо не работает?

V>* Этому некто сначала весьма вежливо говорят: "гхм, извините, но гибридность была выбрана исключительно по тем соображениям, что такое решение получается в три раза шустрее расово-чистого варианта, а в HFT кроме шустрости никого не интересует никакая романтика расовой чистоты". В ответ на сей вполне осмысленный аргумент этот некто решил стать в позу: "вывсёвсеврети! просто вы ниасилили HFT на расово-чистом дотнете!".
Т.е. ты хочешь меня убедить, что гибридное Java/C++ решение невозможно или что?

V>И это мы еще не касались тех вещей, что в том же дотнете сами системные либы, идущие изкаробки, зачастую выполнены в точности как наши, т.е. являются гибридными и какой-нить reflector однозначно сие показывает. И твоя твоя расово-чистая джава тоже внутри по многим системным либам сплошь нейтивная.
Можно расшифровать?

V>А ты весёлый! ))
V>Как ты думаешь, когда я своим детям хрен его знает сколько лет назад памперсы менял, мне их тоже благодарить надо было?
Что ты вокруг, да около? Не держи в себе, говори уж, сколько сантиметров?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Собственно прибавление указателя это и есть способ аллокации в java.
EP>И ты конечно же понимаешь что это полуправда. Вот только непонятно на кого рассчитанная
EP>Ибо в данном варианте деалокация практически бесплатная, а в случае GC сборка муссора неимоверно дорогая
Сборка мусора она разная бывает. Тут уже упоминали поколения. Сборка молодого поколения практически бесплатна.
А ещё есть два региона survival space, который например с fragmentation борется.

В общем, посоветую тебе почитать подробности про устройство современного gc (разных видов) — увидишь много чего похожего с теми "секретными ингридиентами" в управлении C++ памятью, и уверен что откроешь себе ещё пару интересных идей.

Здравствуйте, alex_public, Вы писали:

_>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
Ну JS это довольно узкая и забитая ниша web, где кого только нет, от PHP, python и до той же Java,C# и даже натив. Всё работает достаточно хорошо, остаётся дело вкуса.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Escape анализ не умеет преобразовывать массив ссылок на ссылки на etc в плоский массив байт. Собственно поэтому на Java и нарезают вручную байт-буфера на структуры, потому что автоматически это не происходит и является источником жёстких тормозов. Не было бы это серьёзной проблемой — никто бы и не извращался.

Да, массивы — это боль всех подобных языков. И в каждом из них обычно есть развитые средства для "борьбы" с ними. ))) Хотя никаких средствами до нативных языков всё равно не добраться. ) Хотя вот бывают решения типа numpy в Питоне, которые просто инкапсулировали массивы C. Но там тогда получается узкая специализация, а не универсальное решение.

EP>На C# же есть какие-никакие структуры.

Так в том то и дело что структуры, а не бессылочные классы. Т.е. вот если я хочу создать массив полиморфных объектов (это самый что ни на есть канонический код на всех трёх обсуждаемых языках, т.к. практически самый базовый ООП паттерн), то как ты думаешь где он будет работать быстрее всего? ) Ну в смысле в Java или в C#, потому что с C++ тут смешно сравнивать.

EP>Профит от escape анализа какой-то действительно есть, но отсутствие косвенности в данных на порядок важнее.

Ну вообще то он как раз и уменьшает косвенность, перекидывая данные напрямую в стек. По сути создавая аналог канонического C/C++ кода. Просто он срабатывает в редких случаях (относительно всего кода). )))

Здравствуйте, alex_public, Вы писали:

_>Хотя вот бывают решения типа numpy в Питоне, которые просто инкапсулировали массивы C. Но там тогда получается узкая специализация, а не универсальное решение.

Это как раз пример удачного симбиоза, который без проблем работает на разных платформах.

EP>>На C# же есть какие-никакие структуры.
_>Так в том то и дело что структуры, а не бессылочные классы. Т.е. вот если я хочу создать массив полиморфных объектов (это самый что ни на есть канонический код на всех трёх обсуждаемых языках, т.к. практически самый базовый ООП паттерн)

Речь о том что когда на C# нужно создать массив неполиморфных объектов, содержащих внутри другие неполиморфные — то есть struct.
В Java же для аналогичного по скорости кода нужно спускаться на уровень даже ниже чем C.

EP>>Профит от escape анализа какой-то действительно есть, но отсутствие косвенности в данных на порядок важнее.
_>Ну вообще то он как раз и уменьшает косвенность, перекидывая данные напрямую в стек. По сути создавая аналог канонического C/C++ кода. Просто он срабатывает в редких случаях (относительно всего кода). )))

Само собой в очень редких.
Тут такое дело, когда речь идёт о С++ частенько путают стэковые объекты и например объекты хранящиеся по значению в векторе. И то и то являются основой хорошей производительности производительности, и имеют одни и те же предпосылки, но терминологическии это разные вещи.
Так вот используя эту путаницу евангелисты Java делают вид что escape анализ работает и для случая с вектором, хотя имеет отношение только к оптимизации объектов на стэк.

Здравствуйте, ·, Вы писали:

EP>>·>Собственно прибавление указателя это и есть способ аллокации в java.
EP>>И ты конечно же понимаешь что это полуправда. Вот только непонятно на кого рассчитанная
EP>>Ибо в данном варианте деалокация практически бесплатная, а в случае GC сборка муссора неимоверно дорогая
·>Сборка мусора она разная бывает. Тут уже упоминали поколения. Сборка молодого поколения практически бесплатна.

Ты видимо не понимаешь что означает "практически бесплатная" деалокация в случае регионов — там за одну простейшую/примитивнейшею O(1) операцию убивается сразу N аллокаций. Никакого обхода живых объектов, никаких отслеживаний изменений старых поколений и прочих page faults.
В этом свете высказывание "·>Сборка молодого поколения практически бесплатна" — это

·>А ещё есть два региона survival space, который например с fragmentation борется.
·>В общем, посоветую тебе почитать подробности про устройство современного gc (разных видов) — увидишь много чего похожего с теми "секретными ингридиентами" в управлении C++ памятью, и уверен что откроешь себе ещё пару интересных идей.

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

Здравствуйте, ·, Вы писали:

_>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
·>Ну JS это довольно узкая и забитая ниша web, где кого только нет, от PHP, python и до той же Java,C# и даже натив. Всё работает достаточно хорошо, остаётся дело вкуса.

Хы, ну насчёт забитой я соглашусь, а вот насчёт узкой я бы поостерёгся утверждать. ) Если смотреть по количеству программистов, то как бы эта "узкая ниша" не обошла все остальные вместе взятые. )))

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Сборка мусора она разная бывает. Тут уже упоминали поколения. Сборка молодого поколения практически бесплатна.
EP>Ты видимо не понимаешь что означает "практически бесплатная" деалокация в случае регионов — там за одну простейшую/примитивнейшею O(1) операцию убивается сразу N аллокаций. Никакого обхода живых объектов, никаких отслеживаний изменений старых поколений и прочих page faults.
EP>В этом свете высказывание "·>Сборка молодого поколения практически бесплатна" — это
Алгоритм хорошо работает в случае большого количества смертей. Когда число выживших o(N) (о-малое). Тогда алгоритм сборки — прост — скопировать o(N), грохнуть регион (ака пометить свободным). Поэтому амортизированная сложность и получается O(N). Я не пытаюсь доказать, что это универсальный всемогутер, а лишь то, что в большом количестве реальных программ это так и работает, давая полностью автоматическую сборку практически забесплатно, ценой оверхеда, не видимого за точностью измерений, без ручной возни с контекстами, владением и т.п., упрощая архитектуру приложения.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>На C# же есть какие-никакие структуры.
_>>Так в том то и дело что структуры, а не бессылочные классы. Т.е. вот если я хочу создать массив полиморфных объектов (это самый что ни на есть канонический код на всех трёх обсуждаемых языках, т.к. практически самый базовый ООП паттерн)
EP>Речь о том что когда на C# нужно создать массив неполиморфных объектов, содержащих внутри другие неполиморфные — то есть struct.
EP>В Java же для аналогичного по скорости кода нужно спускаться на уровень даже ниже чем C.

Конечно. Но я немного о других вопросах говорил. И даже не о соотношение полиморфных/неполиморфных объектов в классическом ООП коде. Пускай даже стоит задача создать массив неполиморфных (во всяком случае на данном этапе разработки). Вопрос, а какой инструмент возьмёт для этого средний C# программист (это тот самый, который занимается ваянием формочек и никогда не интересовался особенностями работы кэша современных процессоров)? Ты уверен, что он выберет структурку? )

EP>>>Профит от escape анализа какой-то действительно есть, но отсутствие косвенности в данных на порядок важнее.
_>>Ну вообще то он как раз и уменьшает косвенность, перекидывая данные напрямую в стек. По сути создавая аналог канонического C/C++ кода. Просто он срабатывает в редких случаях (относительно всего кода). )))
EP>Само собой в очень редких.
EP>Тут такое дело, когда речь идёт о С++ частенько путают стэковые объекты и например объекты хранящиеся по значению в векторе. И то и то являются основой хорошей производительности производительности, и имеют одни и те же предпосылки, но терминологическии это разные вещи.
EP>Так вот используя эту путаницу евангелисты Java делают вид что escape анализ работает и для случая с вектором, хотя имеет отношение только к оптимизации объектов на стэк.

Согласен. ) Но это получается всё равно лучше чем виртуальная машина .net, в которой нет даже такого слабенького решения. )

Здравствуйте, alex_public, Вы писали:

_>>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
_>·>Ну JS это довольно узкая и забитая ниша web, где кого только нет, от PHP, python и до той же Java,C# и даже натив. Всё работает достаточно хорошо, остаётся дело вкуса.
_>Хы, ну насчёт забитой я соглашусь, а вот насчёт узкой я бы поостерёгся утверждать. ) Если смотреть по количеству программистов, то как бы эта "узкая ниша" не обошла все остальные вместе взятые. )))
Забитая как технологиями, так и, как следствие, программистами.

Здравствуйте, ·, Вы писали:

·>Ну начнём, с того что в джаве нет UB.

На большинство UB ругается компилятор в С++.


V>>·>К кодекам не предоставляется таких требований надёжности. Пропажа или искажение пары кадров из видео никто не заметит
V>>Если пропала пара кадров, то это что угодно из памяти процесса пропасть может. Т.е. вот кодек JPG-иконок глюканул у тебя в гуишной джава-проге и пара ордеров пропала нафик из памяти, угу. ))
V>>Опять загоняешь, кароч.
·>JPG-иконки и HFT? Хм... Я промолчу.

В клиентской проге? Именно так.


V>>·>а всякие глюки в играх чуть ли не рекламой являются — о, какой прикольный глитч в очередной игрушке — смотрите, корова летает.
V>>Ну вот как раз логику на "высокоуровневом клее" пишут. Вот там баги и живут в основном.
·>На клее пишут в основном скрипты сценария игры, а не графику и физику.

Летающая корова не противоречит законам физики, если из скрипта ей задали параметры как у воздушного шарика. ))


V>>·>Пропажа одного ордера — можно попрощаться с бизнесом.
V>>Бывает намного хуже — невозможно снять ордер с торгов, а сильно надо. А джавовская прога заглючила.
·>И тут приходит С++ и всех спасает. Угу-угу.

Статическая типизация, действительно, много где спасает.


V>>Как тебе такой аргумент?
·>Это не аргумент, а софизм.

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


V>>Ошибка выхода за границы, выловленная в рантайме в работающем в боевой обстановке приложении вообще не поможет тебе ничем. У тебя просто исключение выплёвывается наверх, а операцию совершить невозможно.
·>Это лучше, если операцию совершить невозможно, да ещё и с громким бабахом, чем если бы совершилась втихую какая-то другая операция.

Однако, в С++ принято бегать итераторами по коллекциями.


V>>И это я еще не даже не начинал спрашивать, где ты видел в плюсах выходы за границы. Не в С, а именно в С++. Мне было бы ОЧЕНЬ любопытно взглянуть на пойманную такую хрень в реальном коде, это была бы сенсация.
·>Разве оператор std::vector[] проверяет границы в проде? Или вы боитесь делать релизные сборки?

А разве кто-то использует индекс в векторе вместо итератора?


V>>·>А бывают и не сложнее.
V>>Достаточно того, что бывают сложнее.
·>Недостаточно.

Ну вот ты и проиграл спор.
Путать необходимое с достаточным — это сильно. ))


V>>·>В общем ценность и необходимость JNI ты преувеличиваешь основываясь на своём опыте с С++CLR или как он там.
V>>Тебе еще рано давать советы подобного плана. Пока просто смотри и впитывай чужой опыт.
·>Какие советы?

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


V>>·>Java достаточно хороша, чтобы решить и малое количество сложных задач hft (пусть и не идеально) и огромное кол-во число простых задач, т.е. именно то, чем является типичная hft-система в целом.
V>>Чего-чего?
V>>По современным меркам типичная с полным комплексом фишек, с клирингом, со встроенными стратегиями и т.д. и т.п. HFT-система не дотягивает по информационной сложности даже до рабочего места индивидуального предпринимателя с личной бухгалтерией и складом на 1С.
·>И что? Странное у тебя возражение. Я говорю, что java хорошо подходит для hft-системы, а ты мне возражаешь, что бухгралтерия. Спасибо, понятно, а в киеве дядька.

Сосредоточься:

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

V>>Кароч, ты лишь опять спалился отсутствием серьезного опыта в разработке сложных систем.
·>А ты опять палишься на софизме.

Хочешь сказать, что у нас здесь происходит парадокс бла-бла?


V>>·>В этом и ценность.
V>>Ценность джавы в возможности нанять на работу вчерашних студентов. Других ценностей в ней нет.
·>Ты так говоришь, как будто это что-то плохое.

Если конечная система состоит из туевой хучи некритичных простейших модулей, то это даже хорошо.

Здравствуйте, ·, Вы писали:

V>>·>Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым).
V>>Как правило для публичного интерфейса к таким структурам — массивам байт все-равно идут ref-объекты (кроме числовых и булевских значений), т.е. КАЖДАЯ операция чтения или записи полей такой структуры часто сопровождается созданием ref-объекта.
·>Может и "как правило", но не обязательно (собственно как и в C++). Просто не делай так если важно LL.

А как делать?
В публичном интерфейсе все-равно джавовские строки будут торчать, иначе как клиентское приложение будет работать?


V>>·>Если же замутить что-то навороченное даже на плюсах — с классами, с наследованием, виртуальными функциями, овнершипством, то в итоге получится то же самое — индирекции, перемешивание, проблемы удаления и прочие приседания. Чудес не бывает.
V>>Плюсы — это мультипарадигменный язык, позволяющий играть дизайном как душе будет угодно. Виртуальные ф-ии нужны исключительно для абстрактных типов, ну или заменой им можно считать лямбды и прочие std::function.
V>>Вот у тебя некий пост-процессор данных может быть таким абстрактным функциональным типом, но через это пост-процессор прогоняются вполне себе "плоские" данные. Стоимость вызова std::function примерно равна стоимости одного виртуального вызова, т.е. порядка 2-3ns в цикле для современной техники.
·>Ок. А можно ближе к сабжу?

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


V>>Да не работает оно. Индексы разметки все-равно в виде ref-типов хранятся.
·>Ну например индекс разметки [FIX tag]->[позиция в буфере сообщения] может храниться как "new int[65536]" (tag id в fix == 2 байта) и этот самый массив в единственном экземпляре может жить в gen2 и в кеше вечно.

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

V>>Самый жутко-оптимизированный код выглядит как совершенно обычный, например:
V>>

V>>MyType * obj = new(context) MyType(args);
V>>

·>И что? А что в этом коде необычного?

Дисраптор — это межпоточные lock-free контейнеры для бедных, там в публичном интерфейсе этих контейнеров ничего сложного и не должно быть.
Ты же говорил, что в С++ код будет страшный в случае "низкоуровневых оптимизаций".