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

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

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


·>К кодекам не предоставляется таких требований надёжности. Пропажа или искажение пары кадров из видео никто не заметит

Если пропала пара кадров, то это что угодно из памяти процесса пропасть может. Т.е. вот кодек JPG-иконок глюканул у тебя в гуишной джава-проге и пара ордеров пропала нафик из памяти, угу. ))

Опять загоняешь, кароч.


·>а всякие глюки в играх чуть ли не рекламой являются — о, какой прикольный глитч в очередной игрушке — смотрите, корова летает.

Ну вот как раз логику на "высокоуровневом клее" пишут. Вот там баги и живут в основном.


·>Пропажа одного ордера — можно попрощаться с бизнесом.

Бывает намного хуже — невозможно снять ордер с торгов, а сильно надо. А джавовская прога заглючила.
Как тебе такой аргумент?
Ошибка выхода за границы, выловленная в рантайме в работающем в боевой обстановке приложении вообще не поможет тебе ничем. У тебя просто исключение выплёвывается наверх, а операцию совершить невозможно.

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


V>>Во многих АПИ-вызовах или нейтивных либах параметры бывают чуть сложнее, чем массив байт.
·>А бывают и не сложнее.

Достаточно того, что бывают сложнее.


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

Тебе еще рано давать советы подобного плана. Пока просто смотри и впитывай чужой опыт.


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

Чего-чего?
По современным меркам типичная с полным комплексом фишек, с клирингом, со встроенными стратегиями и т.д. и т.п. HFT-система не дотягивает по информационной сложности даже до рабочего места индивидуального предпринимателя с личной бухгалтерией и складом на 1С.

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


·>В этом и ценность.

Ценность джавы в возможности нанять на работу вчерашних студентов. Других ценностей в ней нет.

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

I>>>Спасибо, капитан. Это проблема юзера — старые файлы повреждены, новых нет. Что делать ?
C>>Использовать CoW-системы, которые не меняют данные в старой версии. Например, BTRFS.
I>Правильно. И давно на макоси CoW поддерживается ?
А что, кто-то использует Mac OS X для чего-то кроме разработки?

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

V>>>Про близкие результаты там ни слова, это ты сам себя уже уговариваешь. ))
V>·>Не понял, как "ни слова"? Это же copy-paste цитата. Может у тебя монитор заляпан и ты не увидел это предложение в документе, на который ты сослался? В том же месте, кстати заляпан, где ты не смог увидеть import java.util.concurrent в тесте на который ты сослался.
V>Чувак, ты откровенно загоняешь уже.
Тебя в угол?

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

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

V>>>Похоже, ты решил, таки, не сдерживать себя?
V>·>Я лишь привожу факт.
V>Ты лжешь.
Понятно. Тебе рационально возразить нечем, поэтому ты просто перешел на эмоциональные оскорбления и обвинения.
Даю совет: вежливо признать свою неправоту и поблагодарить собеседника гораздо полезнее не только для поднятия своей репутации, но и для собственного развития.

V>Причем, в твоей лжи больше желчи и непонятно откуда взявшейся обиды, чем попытки ДЕЙСТВИТЕЛЬНО кого-то обмануть. Никого ты настолько заурядным образом не обманешь, ес-но, лишь покажешь свои манеры.
Манеры показываешь пока только ты.

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

V>>>>>Ошибка. Не нужны. Потому что характер работы системы точно такой же — реакция на внешние события.
I>>>> И давно у тебя создание да пробуждение потока стало дешовой операцией ?
V>>>Это ты мне отвечаешь?
I>>А ты не в состоянии это понять без внешней помощи ?

V>Ты на вопрос не ответил.

Повторяю вопрос — как давно у тебя пробуждение и создание потока стали дешовыми операциями с тз LL ?

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

I>>Не надо никаких хаков, это языковые фичи которые легко отображаются на регистры и стек. То есть — кеш первого уровня. И это без каких либо приседаний.
I>>В джаве для аналогичного эффекта тебе надо долго у муторно нарезать клочки памяти.
·>Круто, чё, молодцы. Осталось показать это в деле. Жду новый успешно выстреливший стартап на .net core, который заборет все эти тормозные явы. У вас ведь даже фора есть, ведь все ява-разработчики давно уморены долгим нарезанием памяти, .net — вперёд!

Фора есть у джавы — дотнет тупил 10 лет. Так что будет очень плавный выход.

В твоих рассуждениях нужно отделять платформу, язык и операционную систему. Иначе разницы не видно между джавой и линуксом-ораклом

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

I>>·>Как выяснилось, что можно и не сделать. Собственно опять, причём тут нейтив. В сабже его нет.
I>>На нейтиве все можно. Если постараться, то и в сто раз медленнее джавы сделать. Поэтому если речь о том "сколько можно выжать" то здесь обычно считают относительно или узкого места, или эталона в виде нативного кода.
·>Понятно. Я и имею в виду, что код на java может давать те же показатели, что и нейтив решение. vdimas вон там ссылочку о fix engine приводил.

Может, если узкое место это, скажем, сетевая карта. А если узкое место это процессор, то джаве до нейтива как до луны раком.

I>>·>Для throughput обычно кластеризуют, там вот да, c# может конкурировать Яве. Хотя тоже не особо. Вон SO обсуждали — из Шарпа там только сами странички, а остальное это либо нативные технологии типа mssql, веб-, проки-серверов, либо ВНЕЗАПНО java Elasticsearch.
I>>Ужос. Неужели оракл и линукс переписывают на джаве ? Или в джаве веб, прокси и другие сервера на джаве написаны ? На секундочку — на чем написана сам джава ?
·>Хочешь сказать это всё написано c#? Или ты опять с сабжа съезжаешь? Или тупо не читаешь, что я пишу?

Я демонстрирую тебе качество твоих же аргументов: " нативные технологии типа mssql, веб-, проки-серверов"

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

I>>>>Спасибо, капитан. Это проблема юзера — старые файлы повреждены, новых нет. Что делать ?
C>>>Использовать CoW-системы, которые не меняют данные в старой версии. Например, BTRFS.
I>>Правильно. И давно на макоси CoW поддерживается ?
C>А что, кто-то использует Mac OS X для чего-то кроме разработки?

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

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

I>>Я привел твою цитату про задачу "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток"
I>>Ты определись, а то скучно читать — задача то одна, а результаты зависят от того, с кем ты спорить взялся

V>Ну или разница в 10 лет, другая техника и совершенно другой GC и алгоритмы тоже другие.
V>На старом GC сильно заметной разницы м/у 0-м и 1-м поколением не было. Сейчас разница катастрофическая.

Другие алгоритмы

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

I>Повторяю вопрос — как давно у тебя пробуждение и создание потока стали дешовыми операциями с тз LL ?

А почему ты опять таким образом формулируешь вопрос, что у тебя в нём содержатся аж четыре утверждения?
Причем, первые три заведомо неверные, а четвертое утверждение является приписыванием первых трёх мне и одновременно с этим возмутительным нахальством. ))

Если ты хочешь что-то спросить и получить ответ, то ты не утверждай, бро, ты именно спрашивай.

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

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

S>>·>В LL не надо дефрагментировать 200мб за 4мс.
S>>>>·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
S>>Я ничего не доказываю. Там вообще все на рефлексии.
·>А зачем ты в этом обсуждении вообще COM упомянул?
Ты сказал, что .Net Core еще не в релизе. Я показал тебе статьи, где использую .Net Core. Причем уже 1.0.1
Где подправили ошибки.
S>>Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
·>Ну как и в java, уже несколько лет как: http://normanmaurer.me/blog/2014/01/07/JNI-Performance-Welcome-to-the-dark-side/ чем хвастаться-то?
Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
Смысл в том, что я через CoreClr я могу дергать статические методы, и я могу сделать обертку, что бы загружать нужные сборки, создавать объекты и дергать методы.
В большом .Net можно использовать либо IReflect Использование сборок .NET в 1С 7.x b 8.x. Создание внешних КомпонентИспользование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
или CLR Hosting API При этом все так или иначе через COM
Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.



S>>>>·>Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
S>> Что ты мне доказал? Что нетовский GC плохо работает с постоянно обновляемыми данными в кэше размером за 100 мегабайт?
·>Ты внимательно читаешь что я пишу? Я доказал себе, тебе доказывать я не хочу, по крайней мере бесплатно. Это займёт моё время, потребует доступ к серверному железу (хотя бы 16-ядерный проц и 32гб памяти, лучше больше), у меня такого в прямой досягаемости нет. Притом для сравнения я предпочитаю linux, что не особо прокатит с c#. Или ты согласишься на тесты с mono (с win будет стоить дороже)? Ты готов оплатить моё время? Или хотя бы поспорить? Я даже тебе фору дам. Скажем, я ставлю свои $5000 против твоих $2500, на то, что zing даст лучший latency time во время сборки мусора, чем c#. И как, по рукам?
Понимаешь, все это хорошо, пока есть время. Если очередь не справляется, то начинаются задержки. Да их можно размазать.
Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
То есть скорость на выделение памяти это будет считаться задержкой?

S>> Ты утверждаеешь, что zing с этим справляется лучше. Голословно.
·>Если ты не веришь утверждениям на их сайте, можешь скачать их триал и попробовть самому: http://info.azul.com/Zing-Trial.html (сэкономишь $2500 на споре со мной).

Ты утверждаешь ты и доказывай.
S>>>>·>Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.
S>> Где статья, что Java быстрее .Net. Ты привел только код на .Net.
·>Где статья, что .net быстрее Java. Ты вообще ничего не привёл.

S>>>> Я ничего доказывать не должен. Ты утверждаешь что приведенный пример будет работать без задержек на Java/
S>>·>Уверен. Если не сработает — зарепорчу баг в azul.
S>> Вот и сделай и посмотрим. В том числе посмотрим на общую скорость.
S>> Я уже писал можно сделать смесь GC и менеджера памяти.
·>Что за смесь? И чем эта смесь поможет? Почему эту же смесь нельзя сделать на java?

S>> Там не раз в минуту память должна забиваться. Правда по алгоритму, выжившие данные должны быть в конце кучи.
S>>Но опять же поколения, которые постоянно обновляются. Нетипичная задача для ГС.
·>В каком ещё конце кучи?

По алгоритму в кэше буду добавлены последние выделенные данные
S>>·>Там "не быстро", а в течение примерно минуты. Ну чтоб пятнадцатиминутный тест показывал хоть что-то полезное.
S>> Ну посмотри на код. Там за цикл выделяется 200 килобайт. Из некольких потоков. Ты хоть этот тес крутил?
·>Нет, у меня нет винды дома, а на работе не до этого.

S>>>> Но зачем тогда C++? Или Java уже и натив обгоняет.
S>>>> Мне просто интересно справится Java как ты утверждаешь или нет.
S>>·>Я видел, что справлялась. У на одном из наших сервисов очистка примерно 1гб мусора происходила примерно раз в час, притом потоки не останавливались на время большее 1мс. Да, кстати, 1мс — это точность измерений, сколько точно микросекунд были задержки — не знаю, всё что меньше 1мс просто не регистрировалось. Если я правильно помню (могу и соврать), по gc-логам время было в среднем в районе 50мкс.
В этом тесте сборка будет не раз в час, а раз в несколько секунд.

S>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
·>Какая разница какой алгоритм?

Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.

И сравнить этот же алгоритм на C++. Который порвет всех.

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


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

Мне интересно не .Net, а как с этим справляется твоя хваленая Java особенно в сравнении с кодом на C++
На этом самом алгоритме. При этом я могу сделать класс на C++ и из .Net дергать его методы.
При этом у меня будут потери только на копировании, но в задержек не будет. Так, что .Net подходит.
https://msdn.microsoft.com/en-us/library/ms235281.aspx
А считать то голословно ты можешь, что угодно.

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

V>·>Они специфичные — битодробилки и строгие (или не очень) доказательства что нигде не выходит за границы массивов.
V>Нет никаких доказательств и взяться неоткуда. Есть рантайм-проверки и куча сугубо логических багов в типичном джава-софте. Потому что полудинамический код и сколько ты его тестами не покрывай, рано или поздно какая-нить хрень вылазит. Это как оно в реальном джава-мире, а не в твоих фантазиях.
Ну начнём, с того что в джаве нет UB.

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

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

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

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

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

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

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

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

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

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

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

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

I>·>Круто, чё, молодцы. Осталось показать это в деле. Жду новый успешно выстреливший стартап на .net core, который заборет все эти тормозные явы. У вас ведь даже фора есть, ведь все ява-разработчики давно уморены долгим нарезанием памяти, .net — вперёд!
I>Фора есть у джавы — дотнет тупил 10 лет. Так что будет очень плавный выход.
Плохая отмаза. У нейтива фора была лет 30 в своё время, если не больше, но это не помешало Яве выстрелить.

I>В твоих рассуждениях нужно отделять платформу, язык и операционную систему. Иначе разницы не видно между джавой и линуксом-ораклом
Не совсем верно, ибо вот так просто взять и отделить — не получится. Вот из-за грёбаной полититки MS привязали себя к win-only и закрытым исходикам. А так c# как язык не так уж плох, но сами себя закопали. Хорошо что хоть очухались в последнее время, может что-то и смогут нагнать, но java же тоже на месте не стоит.

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

·>Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым).

Как правило для публичного интерфейса к таким структурам — массивам байт все-равно идут ref-объекты (кроме числовых и булевских значений), т.е. КАЖДАЯ операция чтения или записи полей такой структуры часто сопровождается созданием ref-объекта.


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

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

Вот у тебя некий пост-процессор данных может быть таким абстрактным функциональным типом, но через это пост-процессор прогоняются вполне себе "плоские" данные. Стоимость вызова std::function примерно равна стоимости одного виртуального вызова, т.е. порядка 2-3ns в цикле для современной техники.


·>Угу. Зато работает, а это — самое важное. И ещё раз повторяю, это будет малой долей всего кода системы.

Да не работает оно. Индексы разметки все-равно в виде ref-типов хранятся.


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

Потому что в С++ мусор убирать не надо? Может, поэтому?
Ну реально, вы с такими аргументами как с другой планеты.

За лишнюю операцию new в C++ принято больно бить по рукам. Я как-то приводил статистику по очень большому проекту, так там было что-то около 9 операций new на весь проект. Девять на многие мегабайты исходников! ))

Почему так? Потому что объекты создаются иначе, чем в Джаве, а именно:
— в 90% случаев размещаются в памяти объектов владельцев, т.е. хранятся по-значению и так вдоль всей иерархии/композиции;
— еще в 90% от оставшегося случая размещаются прямо по значению в контейнерах — линейных и связанных списках, во всяких set/map и прочих хеш-таблицах, в т.ч. мультииндексных (кстате, эффективное мультииндексное хранение данных тоже для Джавы недоступно, там на каждый индекс лупят отдельную хеш-таблицу).
— еще в 90% случаев от оставшегося создаются прямо на стеке опять по-значению.

И только для разделяемых м/у потоками данных, предназначенных как раз сугубо для перекачки данных м/у потоками или для сущностей самого-самого верхнего уровня оправданно использовать shared_ptr, intrusive_ptr, unique_ptr и т.д. Вот как раз во всём большом проекте набралось 9 таких типов.

В С++ есть сборка мусора в виде сразу нескольких либ и стратегий.
Причем, стратегия mark-and-sweep, принятая в управляемых средах, — она же самая тормозная, разве нет. Но тоже доступна в виде готовых либ.

Просто сравни mark-and-sweep со стратегией "регионального аллокатора":
— пришел запрос, ты берешь такой аллокатор из пула аллокаторов и инициализируешь им поле созданного на стеке по значению некоего "контекста" запроса (этот "контекст" почти всегда есть в серверных приложухах);
— обрабатываешь пришедший запрос, где везде как аргумент протягивается этот самый аллокатор как часть контекста;
— затем выплёвываешь результат обратно в сетку;
— возвращаешь аллокатор в пул.

Всё! Никакой операции по уборке мусора нет. Если мы вернули аллокатор в пул, то считается, что мы весь мусор, связанный с обработкой этого запроса, как бэ и убрали уже, всё... хотя НИКАКИХ действий с памятью на самом деле не производили.

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

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

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

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

Скажи, неужели все эти вещи ни разу не интересны? ))


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

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

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

·>Возможно что аналогичный плюсовый код был бы лучше явового, но другие достоинства managed кода и gc перевешивают недостаток "плохо выглядещего" кода.

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

А так-то дай тебе голый GC и буквально только базовые типы и ты сольёшь в скорости разработки любому плюсовику с такими же начальными условиями, но БЕЗ GC. Потому что девять new на огромный проект погоды не делают.

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

I>>>На нейтиве все можно. Если постараться, то и в сто раз медленнее джавы сделать. Поэтому если речь о том "сколько можно выжать" то здесь обычно считают относительно или узкого места, или эталона в виде нативного кода.
I>·>Понятно. Я и имею в виду, что код на java может давать те же показатели, что и нейтив решение. vdimas вон там ссылочку о fix engine приводил.
I>Может, если узкое место это, скажем, сетевая карта. А если узкое место это процессор, то джаве до нейтива как до луны раком.
Допустим. А если вспомнишь сабж? Чем dotnet в этом смысле лучше?

I>>>Ужос. Неужели оракл и линукс переписывают на джаве ? Или в джаве веб, прокси и другие сервера на джаве написаны ? На секундочку — на чем написана сам джава ?
I>·>Хочешь сказать это всё написано c#? Или ты опять с сабжа съезжаешь? Или тупо не читаешь, что я пишу?
I>Я демонстрирую тебе качество твоих же аргументов: " нативные технологии типа mssql, веб-, проки-серверов"
Нет. Мы сравниваем c# и java. Java-only приложений полно. А вот c#-only без помощи той же java всё как-то печальнее. Почему тот же самый elasticsearch написан именно на Яве? Ведь c# во всём лучше!?. Начат проект elasticsearch в 2010, в это время c# уже цвёл и пах во всю.

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

I>>Не надо никаких хаков, это языковые фичи которые легко отображаются на регистры и стек. То есть — кеш первого уровня. И это без каких либо приседаний.
I>>В джаве для аналогичного эффекта тебе надо долго у муторно нарезать клочки памяти.
·>Круто, чё, молодцы. Осталось показать это в деле. Жду новый успешно выстреливший стартап на .net core, который заборет все эти тормозные явы. У вас ведь даже фора есть, ведь все ява-разработчики давно уморены долгим нарезанием памяти, .net — вперёд!

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

1. Пишем канонический код на C++ и получаем бесплатно гарантированное (ну если правильные опции компилятора стоят) максимальной быстродействие.
2. Пишем канонический код на Java и есть шанс, что после прогрева он тоже будет работать довольно шустро. Ну а если нужны гарантии, то надо уже писать свою ВМ под конкретную узкую задачу. Что впрочем тоже не проблема в Java мире, благодаря открытости данной платформы, и вполне применяется (в той теме были ссылки).
3. Пишем канонический код на C# и получаем тормознутый результат. Плюс есть возможность заморочиться и написать более менее оптимизированный код (только структуры, unsafe операции, своё выделение памяти и т.п.), но тогда требуется соответствующая квалификация и теряется большая часть смысла от управляемой платформы (тогда уж лучше сразу на C++ писать).

Так что выбор индустрии вполне понятен и логичен — с точки зрения целевой аудитории Java/C# (не самые продвинутые программисты на планете, в особенности в области оптимизации и железа) подход Java выглядит более логичным.

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

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

V>>>>Похоже, ты решил, таки, не сдерживать себя?
V>>·>Я лишь привожу факт.
V>>Ты лжешь.
·>Понятно. Тебе рационально возразить нечем, поэтому ты просто перешел на эмоциональные оскорбления и обвинения.

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

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

* Вот есть Джава и Дотнет, это родственные технологии. Все года их сравнивают, измеряют быстродейдствие и прочее, сами эти технологии тоже развиваются, но заметно УПЕРЛИСЬ в потолок эффективности своего JIT-а уже в середине (даже ближе к концу) 2000-х. Т.е., примерно после 2007-го года результаты быстродействия ИДЕНТИЧНОГО кода на Джаве и Дотнете стали совсем уж неприлично близкие.

* Доступность обзоров и результатов. На сегодня накоплены многие тысячи таких обзоров и сравнений. Инерционность, вызванная большой массой сравнений, их стабильность и достоверность, вызванная, опять же, бесконечнократным независимым подтверждением, позволяет относить сведения о сравнимой скорости Джавы и Дотнета в область ЗНАНИЙ. Получается так, что кто об этом не в курсе, тот демонстрирует лишь своё НЕЗНАНИЕ. Вот что ты в этом споре демонстрируешь. ))

* Ваш покорный слуга в течении примерно 14-ти последних лет неоднократно портировал джавовский код на дотнет (более 14 раз). Там несложно. Сразу после портирования я почти всегда получал фактически идентичный по размеру исходник и практически идентичное быстродействие. Однако, из-за более развитых языковых ср-в донета такой портированный код ВСЕГДА подвергался затем нещадному рефакторингу, где объем исходников уменьшался примерно в полтора раза, а быстродействие (из-за агрессивного применения value-types) вырастало обычно от 30% до 50% для простых вещей и до 2-3-х раз для чего-то более сложного. Это как оно есть в реальной жизни.

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

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

И вот как коллеги должны понимать заскоки подобного рода? Как мега-передёргивания (т.е. троллизм) или как слепую заангажированность (т.е. как слабоумие)?

Блин, даже перед бессловесной скотинкой поставь стог свежего сена и стог протухшего — она и то сделает правильный выбор. Но ты же себе и коллегам отказываешь в такой банальной способности!

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

Видишь, как много ты оставил за скобками в своих утверждениях?


==============
·>Даю совет: вежливо признать свою неправоту и поблагодарить собеседника гораздо полезнее не только для поднятия своей репутации, но и для собственного развития.

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

http://www.rsdn.org/forum/job/4429393.1

От: . 21.09.11 15:51
Назначили телефонное интервью, в котором "Experience of financial markets and Risk is desirable", написали, что будут технические и математические вопросы. С техническими я примерно представляю о чём, а какая математика может быть?

))

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

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

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

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

I>>На нейтиве все можно. Если постараться, то и в сто раз медленнее джавы сделать. Поэтому если речь о том "сколько можно выжать" то здесь обычно считают относительно или узкого места, или эталона в виде нативного кода.
·>Понятно. Я и имею в виду, что код на java может давать те же показатели, что и нейтив решение.

Тебя и поправили — если нейтивный код такой заведомо плохой. Иначе не может.

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

S>·>А зачем ты в этом обсуждении вообще COM упомянул?
S> Ты сказал, что .Net Core еще не в релизе. Я показал тебе статьи, где использую .Net Core. Причем уже 1.0.1
S>Где подправили ошибки.
Ок. И причём тут COM?

S>>>Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
S>·>Ну как и в java, уже несколько лет как: http://normanmaurer.me/blog/2014/01/07/JNI-Performance-Welcome-to-the-dark-side/ чем хвастаться-то?
S> Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
Что из натива? JNI — Java Native Interface. Ты хоть по ссылке-то перешел прежде чем вопросы задавать?

S>Смысл в том, что я через CoreClr я могу дергать статические методы, и я могу сделать обертку, что бы загружать нужные сборки, создавать объекты и дергать методы.
S> В большом .Net можно использовать либо IReflect Использование сборок .NET в 1С 7.x b 8.x. Создание внешних КомпонентИспользование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
S>или CLR Hosting API При этом все так или иначе через COM
S> Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.
Статические наверное потому, что у них возникли проблемы интеграции с gc. В общем я не понимаю к чему ты это всё рассказываешь. JNI позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
А ещё для изврлюбителей иметь дело с COM, есть J-Interop, JACOB, jacoZoom.

S>·>Ты внимательно читаешь что я пишу? Я доказал себе, тебе доказывать я не хочу, по крайней мере бесплатно. Это займёт моё время, потребует доступ к серверному железу (хотя бы 16-ядерный проц и 32гб памяти, лучше больше), у меня такого в прямой досягаемости нет. Притом для сравнения я предпочитаю linux, что не особо прокатит с c#. Или ты согласишься на тесты с mono (с win будет стоить дороже)? Ты готов оплатить моё время? Или хотя бы поспорить? Я даже тебе фору дам. Скажем, я ставлю свои $5000 против твоих $2500, на то, что zing даст лучший latency time во время сборки мусора, чем c#. И как, по рукам?
S> Понимаешь, все это хорошо, пока есть время. Если очередь не справляется, то начинаются задержки. Да их можно размазать.
Запуск gc раз в минуту — значит справляется. Когда не справляется — gc пашет постоянно или приложение падает с OOME.

S>Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
S>То есть скорость на выделение памяти это будет считаться задержкой?
Нет, не будет. Как минимум выделение памяти не блокирует все треды (если конечно gc кучу не заблокировал из-за нехватки памяти).

S>>> Ты утверждаеешь, что zing с этим справляется лучше. Голословно.
S>·>Если ты не веришь утверждениям на их сайте, можешь скачать их триал и попробовть самому: http://info.azul.com/Zing-Trial.html (сэкономишь $2500 на споре со мной).
S> Ты утверждаешь ты и доказывай.
Не понял. Доказательство тут: https://www.azul.com/products/zing/zing-performance/ Чем тебя не устраивает "Delivers max latencies under 10 msec out of the box, without tuning"? Там же ещё есть и ссылки на всякие графики и бенчмарки. Ты считаешь это враньё и я эту страничку сфабриковал? Какое именно ты доказательство от меня требуешь?

S>·>В каком ещё конце кучи?
S> По алгоритму в кэше буду добавлены последние выделенные данные
Я не понимаю о чём ты и какое это отношение имеет к сабжу.

S>>>·>Я видел, что справлялась. У на одном из наших сервисов очистка примерно 1гб мусора происходила примерно раз в час, притом потоки не останавливались на время большее 1мс. Да, кстати, 1мс — это точность измерений, сколько точно микросекунд были задержки — не знаю, всё что меньше 1мс просто не регистрировалось. Если я правильно помню (могу и соврать), по gc-логам время было в среднем в районе 50мкс.
S> В этом тесте сборка будет не раз в час, а раз в несколько секунд.
Судя по графикам сборка была раз в минуту. Если ты считаешь, что чувак в той статье налажал и сделал всё неправильно — проведи свои тесты, .net у тебя есть, наверняка.

S>>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
S>·>Какая разница какой алгоритм?
S> Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.
Ты же сам нашел статью о TTSP. Вот почитай её и пойми о чём речь, потом, если останутся какие-то возражения, приходи, продолжим разговор.

S> И сравнить этот же алгоритм на C++. Который порвет всех.
Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.