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

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

S>> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.
·>Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
·>Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.

Вот под это прекрасно подходят нативные менеджеры памяти. Да там может быть жуткая фрагментация.
Но можно сделать компромиссный GC с менеджером памяти.

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

EP>>>Речь о том что локальность (в частности C#-ский struct) позволяет более эффективно использовать железо — кэш, регистры и т.п. А не о том что нужно вручную колупаться в регистрах чтобы получить локальность.
EP>·>В принципе new MyClass[100_000] вполне локален. Может быть немного неэффективен, но не настолько страшно, как малюют.
EP>MyClass может содержать внутри ссылки на другие объекты, те в свою очередь ещё на другие, а сам массив может быть многократно перемешан/отсортирован — привет проседания на один-несколько порядков. Не говоря уже о дополнительной работе для GC.
Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым). Если же замутить что-то навороченное даже на плюсах — с классами, с наследованием, виртуальными функциями, овнершипством, то в итоге получится то же самое — индирекции, перемешивание, проблемы удаления и прочие приседания. Чудес не бывает.

EP>·>На крайний случай всегда есть new byte[1_000_000] — но таких мест где это реально требуется — очень мало.
EP>·>java быстро работать может — факт, пусть код выглядит похуже, это не show stopper.
EP>"Похуже" — это такой аутотренинг с самоуспокоением? Там от языка-то практически ничего не остаётся — классы нельзя, GC нельзя, композицию нельзя и т.п.
Угу. Зато работает, а это — самое важное. И ещё раз повторяю, это будет малой долей всего кода системы.

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

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

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

S>>> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.
S>·>Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
S>·>Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.
S>Вот под это прекрасно подходят нативные менеджеры памяти.
Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.

S>Да там может быть жуткая фрагментация.
Угу... Или не будет, если переизобретёшь явовский gc.

S>Но можно сделать компромиссный GC с менеджером памяти.
Или не париться и взять java.

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

EP>Захочу прямо, а захочу сошлюсь на букварь из которого всё следует. Здесь опять-таки форум, а не Q&A

Подумалось, что если бы Монти Пайтон выступали сейчас, и были частично айтишниками, то они могли бы сделать скетч "Q&A в стиле русскоязычного форума". Приходит клиент, говорит что у него проблема, а ему отвечают "Сам дурак, читай букварь".

Вот например приём PM на работу:
https://www.youtube.com/watch?v=i_rwAH7tDRw

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


S>>·>Что написано? "LL c# систем в мире нет", но на самом деле власти скрывают и за забором их даже куры не клюют. Так что-ли?
S>> А ты не абстрактый LL а конкретный пример на который ссылаешься. Я не верю в дефрагментацию 200 мб за 4 мс.
·>В LL не надо дефрагментировать 200мб за 4мс.

S>>·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
Я ничего не доказываю. Там вообще все на рефлексии. Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
S>>·>Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
Что ты мне доказал? Что нетовский GC плохо работает с постоянно обновляемыми данными в кэше размером за 100 мегабайт?
Ты утверждаеешь, что zing с этим справляется лучше. Голословно.
S>>·>Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.
Где статья, что Java быстрее .Net. Ты привел только код на .Net.
S>> Я ничего доказывать не должен. Ты утверждаешь что приведенный пример будет работать без задержек на Java/
·>Уверен. Если не сработает — зарепорчу баг в azul.

Вот и сделай и посмотрим. В том числе посмотрим на общую скорость.
Я уже писал можно сделать смесь GC и менеджера памяти.
·>В статье не "постоянно 200мб", а примерно раз в минуту задержки по >100мс на сборку этих самых мб.
·>Кстати, ты указывал на возможность, что это windows вызывает паузы, а не gc. Периодичность пиков может служить доказательством, что это связанно именно с gc, вряд ли винда что-то вот так периодично шалит. Хотя ещё неплохо было бы график пауз сопоставить с графиком занятости памяти — они должны совпасть.

А вот и странно, что раз в минуту. Не указан объем памяти.

processingThreads[i] = new Thread(() =>
{
  var threadCounter = 0;
  while (true)
  {
    var text = new string((char)random.Next(start, end + 1), 1000);
    stringCache.Set(text.GetHashCode(), text);

    // Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
    var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    bytesCache.Set(bytes.GetHashCode(), bytes);

    threadCounter++;
    Thread.Sleep(1); // So we don't thrash the CPU!!!!
  }
});

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

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

Ну посмотри на код. Там за цикл выделяется 200 килобайт. Из некольких потоков. Ты хоть этот тес крутил?

S>>Но опять, же проблему с задержками можно решать либо через определенные структуры данных,
·>Нельзя. Это особенность работы алгоритма gc.
·>Единственное что можно теоретически сделать — полностью 100% zero garbage код, но это сложно, очень связывает по рукам и ногам, лишаешься многих удобностей.
Можно, я тебе примеры приводил через копирование, в том числе и 13 летней давности.
А приведенный пример вырожденный. Такого в реалиях то не бывает.

S>>либо через БД.
·>Т.е. признать, что .net эта задача не под силу и взять native или java. Собственно к этому я и клоню.
·>Никакая мне известная БД не может использоваться в LL, там вообще жуткие задержки бывают, похуже самого плохого gc, да ещё и локи.
По алгоритму там и не нужно ждать. Послал OneWay без ожидания ответа.

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

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

EP>>·>В принципе new MyClass[100_000] вполне локален. Может быть немного неэффективен, но не настолько страшно, как малюют.
EP>>MyClass может содержать внутри ссылки на другие объекты, те в свою очередь ещё на другие, а сам массив может быть многократно перемешан/отсортирован — привет проседания на один-несколько порядков. Не говоря уже о дополнительной работе для GC.
·>Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым). Если же замутить что-то навороченное даже на плюсах — с классами, с наследованием, виртуальными функциями, овнершипством, то в итоге получится то же самое — индирекции, перемешивание, проблемы удаления и прочие приседания. Чудес не бывает.

А я не говорил про виртуальные функции и т.п. это очередной перескок.
Возьми структуру, сделай композицию с другой структурой, положи в массив и отсортируй — на C++ локальность сохранится, а на Java нет
Ты же передёргиваешь на то что если писать в Java-style то будет тормозить — да, конечно будет

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

Затем что компьютер с нею не справляется, отсюда и появляются все эти GC-free решения в управляемых языках

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

Почему "возможно"?

·>но другие достоинства managed кода и gc перевешивают недостаток "плохо выглядещего" кода.

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

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

I>>·>Неправда. Конечно, из-за строгости стандартов сделать код на Яве, который будет пахать одинаково эффективно на всех возможных имплементациях JVM на всех платформах от чайников до супер-компьютеров, но запилить под конкретное окружение на конкретном железе можно. Собственно та же ситуация, что и с нейтивом.
I>>И при этом на нейтиве все равно можно в раза два быстрее сделать.
·>Как выяснилось, что можно и не сделать. Собственно опять, причём тут нейтив. В сабже его нет.

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

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

Ужос. Неужели оракл и линукс переписывают на джаве ? Или в джаве веб, прокси и другие сервера на джаве написаны ? На секундочку — на чем написана сам джава ?

I>>Для LL — если закрыть глаза на другие технологии.
·>На текущий момент — одна технология, нейтив, у которого свои минусы.
·>И что-то сомневаюсь, что .net сможет догнать в рамках, обозначенных в сабже.

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

I>>·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.
I>>А ты хорошо понимаешь, какой код генерит С++ компилер ?
·>Он чем-то принципиально отличается от C2 compiler?

Небольшой ликбез — примерно с появлением Pentium стало экономически невыгодно писать на ассемблере. Это значит, в кратце, если ты не умеешь компилировать Си в уме, то нечего и браться руками регистрами.

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

EP>>Уверен ты и сам всё это понимаешь — тогда к чему эти сказки про регистры и ассемблер?
·>Это ты у меня спрашиваешь? Здесь я с тобой согласен.
·>Тут просто меня убеждают, что без регистров java быстро работать не может, а в шарпе обещают какие-то хаки, чтобы регистрами управлять. Ха. Три раза.

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

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

EP>>·>На крайний случай всегда есть new byte[1_000_000] — но таких мест где это реально требуется — очень мало.
EP>>·>java быстро работать может — факт, пусть код выглядит похуже, это не show stopper.
EP>>"Похуже" — это такой аутотренинг с самоуспокоением? Там от языка-то практически ничего не остаётся — классы нельзя, GC нельзя, композицию нельзя и т.п.
·>Угу. Зато работает, а это — самое важное. И ещё раз повторяю, это будет малой долей всего кода системы.

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

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

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

S>>>> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.
S>>·>Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
S>>·>Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.
S>>Вот под это прекрасно подходят нативные менеджеры памяти.
·>Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.
Вопрос пока открыт пока не покажешь этот же самый код на Java.
S>>Да там может быть жуткая фрагментация.
·>Угу... Или не будет, если переизобретёшь явовский gc.
Я то не буду. Но как MS могут добавить еще один GC для таких вырожденных случаев.
S>>Но можно сделать компромиссный GC с менеджером памяти.
·>Или не париться и взять java.
Я не пишу на Java. Ты так и не показал этот же тест на Java.
Только свои предположения. Возьми и напиши. Делов то. А я может и перейду на Java.
Заодно и .Net Core протестируем.

Я думаю, что не только мне будет интересно посмотреть на результаты
http://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/

https://www.azul.com/products/zing/pgc/

Хотя лично считаю, что для этого лучше всего подойдет C++ с хорошим менеджером памяти.

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

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

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

V>Это ты мне отвечаешь?

А ты не в состоянии это понять без внешней помощи ?

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

S>·>В LL не надо дефрагментировать 200мб за 4мс.
S>>>·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
S>Я ничего не доказываю. Там вообще все на рефлексии.
А зачем ты в этом обсуждении вообще COM упомянул?

S>Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
Ну как и в java, уже несколько лет как: http://normanmaurer.me/blog/2014/01/07/JNI-Performance-Welcome-to-the-dark-side/ чем хвастаться-то?

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

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>·>Нельзя. Это особенность работы алгоритма gc.
S>·>Единственное что можно теоретически сделать — полностью 100% zero garbage код, но это сложно, очень связывает по рукам и ногам, лишаешься многих удобностей.
S> Можно, я тебе примеры приводил через копирование, в том числе и 13 летней давности.
В смысле zero garbage? И что такой тест будет тестировать?

S> А приведенный пример вырожденный. Такого в реалиях то не бывает.
Что не бывает? Периодических сборок мусора?

S>>>либо через БД.
S>·>Т.е. признать, что .net эта задача не под силу и взять native или java. Собственно к этому я и клоню.
S>·>Никакая мне известная БД не может использоваться в LL, там вообще жуткие задержки бывают, похуже самого плохого gc, да ещё и локи.
S> По алгоритму там и не нужно ждать. Послал OneWay без ожидания ответа.
Какому алгоритму??! ЭТО ТЕСТ!!!

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

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

EP>>>MyClass может содержать внутри ссылки на другие объекты, те в свою очередь ещё на другие, а сам массив может быть многократно перемешан/отсортирован — привет проседания на один-несколько порядков. Не говоря уже о дополнительной работе для GC.
EP>·>Как правило в таких применениях структуры данных довольно плоские и простые (или их специально сводят к таковым). Если же замутить что-то навороченное даже на плюсах — с классами, с наследованием, виртуальными функциями, овнершипством, то в итоге получится то же самое — индирекции, перемешивание, проблемы удаления и прочие приседания. Чудес не бывает.
EP>А я не говорил про виртуальные функции и т.п. это очередной перескок.
EP>Возьми структуру, сделай композицию с другой структурой, положи в массив и отсортируй — на C++ локальность сохранится, а на Java нет
При сортировке копируй данные, а не ссылки на объекты (ровно так как ты бы делал в плюсах, ага — копиктор, функция std::swap и т.п.). Делов-то.

EP>Ты же передёргиваешь на то что если писать в Java-style то будет тормозить — да, конечно будет
Что такое именно java style?

EP>·>Вброс: зачем нагружать компьютер той рутинной работой (сборкой мусора), с которой хорошо справляются сиплюсплюсники.
EP>Затем что компьютер с нею не справляется, отсюда и появляются все эти GC-free решения в управляемых языках
Но только там, где не справляется. В 99.99% случаев сборка мусора — рутина. Собственно та же ситуация, что и с компиляцией. Компилятор тоже бывает хрень генерит.

EP>·>Возможно что аналогичный плюсовый код был бы лучше явового,
EP>Почему "возможно"?
Как минимум понятие "лучше" — субъективно.

EP>·>но другие достоинства managed кода и gc перевешивают недостаток "плохо выглядещего" кода.
EP>Ты правильно в кавычки взял, ибо во-первых он ужасен, а во-вторых дело не в том как он выглядит, а в том что его намного труднее создавать, отлаживать и поддерживать.
Голословно. Факт наличия такого кода, притом в коммерческих применениях, притом уже достаточно много лет, притом много где (кстати, недавно когда ходил по интерьвю, в Thomson Reuters набирали людей под ещё один новый проект), говорит об обратном. Ты, как минимум, не учитываешь, что этот "ужасный" код является маленькой частью большой системы, которую создавать, отлаживать и поддерживать на java проще.

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

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

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

I>·>На текущий момент — одна технология, нейтив, у которого свои минусы.
I>·>И что-то сомневаюсь, что .net сможет догнать в рамках, обозначенных в сабже.
I>На текущий момент .Net это закрытая технология прибитая гвоздями к винде. Ты хорошо понимаешь что это значит ? У джавы нет конкурентов, потому что винды нет в LL. Не потому что дотнет не тянет, а потому, что винда вот такая.
Спасибо, я это прекрасно понимаю, теперь объясни это vdimas'у, который утверждает, что: "В сфере упомянутого тобою HFT джава уступает дотнету сильно, примерно вдвое-трое по latency" и ещё Serginio1, который тоже подобную чушь порет.

I>>>·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.
I>>>А ты хорошо понимаешь, какой код генерит С++ компилер ?
I>·>Он чем-то принципиально отличается от C2 compiler?
I>Небольшой ликбез — примерно с появлением Pentium стало экономически невыгодно писать на ассемблере. Это значит, в кратце, если ты не умеешь компилировать Си в уме, то нечего и браться руками регистрами.
Что ты мне это рассказываешь? Перлы о регистрах в топик не я притащил, а vdimas: "А вот уже как побайтно разбирать стрим — тут уже можно оптимизировать, например, читать за раз из памяти выровненные 8 байт в 64-хразрядной аритектуре и САМИМ жонглировать затем байтами уже сугубо в регистрах проца" и Serginio1: "При этом пока задача вне потока выполнения код хранится в виде делегата. Никакого стека, регистров.".

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

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

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

V>>Мы на разных языках разговариваем. У нас представление FIX-сообщения в памяти и сетке идентично, т.е. мы тупо пихаем тело сообщения в сетку и точно так же принятый блоб без изменений хранится в памяти, просто будет размечен индексами при парсинге. Для джавы такой подход — недостижимый хайтек,
N>Хм, этот "недостижимый хайтек" как раз напрямую используется нашим Java софтом

Т.е. тормозит еще больше?


N>Видимо, авторы не знали, что vdimas запретил им это использовать

Видимо, руки не оттуда растут, если используют джаву не по месту.


V>>Поверь, качественная перекачка данных из потока в поток — это ноу-хау каждой конторы, которая делает подобного рода решения — обработку сумасшедших потоков данных в реалтайме. Хорошо оттюненный конвейер data-flow перемалывает в секунду до миллиона ордеров на каждой паре системных потоков. Для джавы это всё недостижимо, ес-но.
N>Соседний отдел уже смеётся, "недостижимо", ага

Он плачет. Иначе бы они показали свои цифры на официальных забегах и тогда бы мы решили, кто тут будет смеяться.
Ну или это всё происходит исключительно у тебя в голове. Фантазируем-с.


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

Хреново оно работает. Еле-еле.

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

S>>>Вот под это прекрасно подходят нативные менеджеры памяти.
S>·>Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.
S> Вопрос пока открыт пока не покажешь этот же самый код на Java.
Оплатишь моё потраченное время — покажу.

S>>>Да там может быть жуткая фрагментация.
S>·>Угу... Или не будет, если переизобретёшь явовский gc.
S> Я то не буду. Но как MS могут добавить еще один GC для таких вырожденных случаев.
Тут ведь как... Могут добавить, а могут и не добавить!
Да, кстати, java не стоит на месте: can manage 100GB+ heaps with the majority of the gc pauses requiring < 100ms.

S>>>Но можно сделать компромиссный GC с менеджером памяти.
S>·>Или не париться и взять java.
S> Я не пишу на Java. Ты так и не показал этот же тест на Java.
Я привёл ссылки на результаты бенчмарков Zing GC. И на результаты бенчмарков .net GC. Конкретные тесты меня не интересуют. Если у тебя есть другие результаты, показывай, не стесняйся. Пока ты тупо отрицаешь факты приведённые мной, не дав ничего взамен.

S> Только свои предположения. Возьми и напиши. Делов то. А я может и перейду на Java.
Для 1С оно тебе не нужно. Но переходи — денег больше платят.

S> Заодно и .Net Core протестируем.
S> Я думаю, что не только мне будет интересно посмотреть на результаты
Ну так я тебе показал результаты уже сделанных замеров. Тебя они не устраивают. Делай замеры сам, тут тебе будет не с кем спорить.

S>http://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/
S>https://www.azul.com/products/zing/pgc/
?? Это к чему?
Ты решил доказать мне то, что я доказываю тебе?

some point in time the GC will need to clean up all the garbage and to do this is has to pause the entire runtime (except if you happen to be using Azul’s pauseless GC for Java)

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

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

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

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


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

Я-то здесь причём? Ты ведь опять пытаешься состроить загадочное лицо, не дав подробности очередных своих "а вот мы тут такое нашли, а вот оно упс!". Не надоело обсуждать вот именно так, по-загадочному? А что оппоненту надо думать после того спора? Да что угодно, собсно — может у тебя там 1-е поколение давно, а ты всё думаешь, что 0-е. И вот опять бежишь с очередным "сеансом разоблачения". ))

В общем, если тебе действительно охота разбираться — давай всё что у тебя есть, будем разбираться. Если же не охота, а чиста поупражняться опять в разбрызгивании помоев, то нуегонах сразу, нервы беречь надо.

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

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

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


V>>·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать?
V>>Т.е. на джаве асилили, а на дотнете, на котором в два раза проще и в два раза меньше кода требуется — нет.
V>>Оригинально.
·>Да, оригинально. Но факт остаётся фактом.

Факт тут лишь в очевидном неумении сложить логическую цепочку из всего двух утверждений.
Других фактов пока никто не демонстрировал, брехню одну.


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

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

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

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

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