Здравствуйте, Serginio1, Вы писали:
S>>> Ну вот тебе на это кстати vdimas приводит примеры. S>·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.
S>>>·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC. S>>> Можно. И кстати та же самая статья говорит, что можно. S>·>Цитату плз. S> То, что при такой нагрузке задержки начинаются только на 10 минуте.
Это не цитата. Приведи точную цитату и ссылочку. Я не понимаю откуда это и в каком это контексте, топик уже слишком большой, у меня в голове не помещается.
S>·>Цитату плз. S> То, что при такой нагрузке задержки начинаются только на 10 минуте.
Какая разница на какой минуте начинаются задержки? Интересует _только_ величина задержки.
S>·>Ещё раз — тест призван выяснить — что происходит, когда таки gc должен собрать мусор и дефрагментировать. S> Он будет справляться. Еще раз при такой нагрузке задержки начинаются только на 10 минуте. S>На обычных данных он может и справиться. Надо спрашивать у Vdimas. Я просто обратил внимание на тест где генерится огромный объем данных при этом кэш составляет порядка 200 мб и по идее сборка мусора должна происходить раз в несколько секунд, а не минут.
Но по графику пики раз в минуту.
Вообще в статье плохо видно подробности, может у него куча 16гб...
Но лучшего теста у меня нет. Если у тебя есть — показывай, не стесняйся.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
C>>А что, кто-то использует Mac OS X для чего-то кроме разработки? I>Именно. Там как и везде, разработчиков ничтожное меньшинство. И если разрабу можно объяснить преимущества копирования, то обычные юзеры приходят в бешенство, когда им раз в неделю приходится выкачивать десяток-другой гигабайт обновлений.
Обычным пользователям вообще пофиг. Они прекрасно работают на Mac OS, копируя приложения в папку Applications.
Здравствуйте, ·, Вы писали:
S>>·>Интересно. А зачем это? Почему бы не писать всё на одном из языков? S>> 1С это очень удобный конструктор и язык для работы с Базами данных. А во внутренний язык очень ограничен. Но с помощью .Net его можно расширить. Только никому это не нужно. ·>Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное. ·>Но мы опять отбиваемся от темы...
Там не поддерживаются Ws протоколы, Header итд. Куча шифрований, HAMAC итд. Проще не городить свой Rest,а взять готовый класс с сериализацией десериализацией. Тот же часто использукмый для парсинга сайта AnglrSharp, асинхронный вызов и куча куча всего. S>>>> Я именно по этому тесту и веду разговор. Он очень тяжелый для ГС. S>>·>В этом его и суть. Можешь его облегчить, но тогда прогоны будут не 5 минут, а 5 часов. Но ты можешь объяснить за счёт чего улучшится latency? S>> За счет, того что не нужно дефрагментировать большое количество памяти за счет нативного менеджера памяти. ·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти?
Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml
S>>>> Если выживших объектов немного, то поможет. S>>·>Малая сборка (YG) вроде не вызывает stop-the-world. Это будет бессмысленный тест. S>> Вот именно. ·>А зачем нужен бессмысленный тест?
Это ответ на то как поможет нативный менеджер памяти. S>>>> На самом деле классы C++ играют роль БД. На C# вся остальная нагрузка. S>>·>Ну вот как vdimas рассказывал, так им и пришлось сделать — синхронизация, управление памятью и потоки — нативные. S>> Ну при этом они используют и манагед код. Просто для многих специфических задач смешанный код подходит лучше всего. ·>Ок, подытожу. ·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). ·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
·>Тебя не убеждают реальные проекты. Я не видел c# ни в одной LL системе, видел только GUI, при этом backend либо C++, либо Java — в этом убедиться сам, изучив рынок труда для программистов HFT, если ты видел — покажи хоть один пример. Ещё иногда c# используют брокеры, но это по сути тоже клиентский код и совсем не HFT, требования значительно ниже, т.к. коннектятся-то они к биржам написанным на C++ и Java. Хедж-фанды, инвест-банки, етс — всё то же. ·>Тебя не убеждают приведённые данные о производительности gc. Тебя не убеждает даже простой факт отсутствия pauseless gc для .net в принципе. ·>В качестве доказательства твоей тз от тебя я видел только рассуждения о том, что тесты плохие и в Линуксе COM с 1С. ·>В общем, мне надоело, я пас. Оставайся при своём мнении.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> Ну вот тебе на это кстати vdimas приводит примеры. S>>·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.
S>>>>·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC. S>>>> Можно. И кстати та же самая статья говорит, что можно. S>>·>Цитату плз. S>> То, что при такой нагрузке задержки начинаются только на 10 минуте. ·>Это не цитата. Приведи точную цитату и ссылочку. Я не понимаю откуда это и в каком это контексте, топик уже слишком большой, у меня в голове не помещается.
Я специально измерил на свем компе сколько выдает циклов
var timer = new Stopwatch();
var threadCounter = 0;
int hash = 0;
Random random = new Random();
int start = (int)'A';
int end = (int)'z';
timer.Start();
while (threadCounter < 1000)
{
var text = new string((char)random.Next(start, end + 1), 1000);
hash^=text.GetHashCode();
// Use 80K, If we are > 85,000 bytes = LOH and we don't want these therevar bytes = new byte[80 * 1024];
random.NextBytes(bytes);
hash ^= bytes.GetHashCode();
threadCounter++;
Thread.Sleep(1); // So we don't thrash the CPU!!!!
}
timer.Stop();
Console.WriteLine(timer.ElapsedMilliseconds);
Console.ReadLine();
Получается порядка 1.7 сек. Пусть там запиь в Кэш тогда получается 2 секунды на 1000 циклов.
Пусть крутится 4 потока. Тогда в секунду срабатывает 2000 циклов.
Значит в секунду выделяется 100 кб* 2000= 200 мб
В минуту это 12 ГБ. Я кончно не знаю сколько там памяти, но вообще GC срабатывает при заполнении определенного количества.
Предположим, что ГС срабатывет при полном заполнении и пусть это будет 12 ГБ.
Тогда он должен сработать как минимум 10 раз до того как задержки превысят порог. При этом нужно дефрагментировать порядка 200 мб S>>·>Цитату плз. S>> То, что при такой нагрузке задержки начинаются только на 10 минуте. ·>Какая разница на какой минуте начинаются задержки? Интересует _только_ величина задержки.
А в том, что при меньших нагрузках этих задержек не будет. S>>·>Ещё раз — тест призван выяснить — что происходит, когда таки gc должен собрать мусор и дефрагментировать. S>> Он будет справляться. Еще раз при такой нагрузке задержки начинаются только на 10 минуте. S>>На обычных данных он может и справиться. Надо спрашивать у Vdimas. Я просто обратил внимание на тест где генерится огромный объем данных при этом кэш составляет порядка 200 мб и по идее сборка мусора должна происходить раз в несколько секунд, а не минут. ·>Но по графику пики раз в минуту.
Это касается старых версий
In early versions of the .NET CLR, garbage collection was a “Stop the world” event, i.e. before a GC could happen all the threads in your program had to be brought to a safe place and suspended. If your ASP.NET MVC app was in the middle of serving a request, it would not complete until after the GC finished and the latency for that user would be much higher than normal. This is exactly the issue that Stackoverflow ran into a few years ago, in their battles with the .NET Garbage Collector. If you look at the image below (from that blog post), you can see the spikes in response times of over 1 second, caused by Gen 2 collections.
В новых версиязх задержки снижены
However in the .NET framework 4.5 there were enhancements to the GC brought in that can help mitigate these (emphasis mine)
The new background server GC in the .NET Framework 4.5 offloads much of the GC work associated with a full blocking collection to dedicated background GC threads that can run concurrently with user code, resulting in much shorter (less noticeable) pauses. One customer reported a 70% decrease in GC pause times.
But as you can see from the quote, this doesn’t get rid of pauses completely, it just minimises them. Even the SustainedLowLatency mode isn’t enough, “The collector tries to perform only generation 0, generation 1, and concurrent generation 2 collections. Full blocking collections may still occur if the system is under memory pressure.” If you want a full understanding of the different modes, you can see some nice diagrams on this MSDN page.
В качестве последнего теста, программа была запущена с помощью нового режима SustainedLowLatency, чтобы увидеть, какой эффект, который имеет. На графике ниже вы можете увидеть это предлагает более низкие время пауз, хотя и не в состоянии поддерживать их в течение неограниченного периода времени. Через 10 минут мы начинаем видеть более длинные паузы по сравнению с теми, кого мы видели, при выполнении теста всего за 5 минут.
То есть при соответсвующих нагрузках вполне могут достигать небольшого времени достаточным для задачи. ·>Вообще в статье плохо видно подробности, может у него куча 16гб... ·>Но лучшего теста у меня нет. Если у тебя есть — показывай, не стесняйся.
Здравствуйте, Serginio1, Вы писали:
S>·>Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное. S>·>Но мы опять отбиваемся от темы... S> Там не поддерживаются Ws протоколы, Header итд. Куча шифрований, HAMAC итд. Проще не городить свой Rest,а взять готовый класс с сериализацией десериализацией. Тот же часто использукмый для парсинга сайта AnglrSharp, асинхронный вызов и куча куча всего.
Так не пиши ничего на 1С-языке, все эти ъ — это же жуть, и наверняка серьёзная проблема с юнит-тестами. Неужели нет никакого способа написать модуль|расширение|плагин на нормальном ЯП?
S>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти? S> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml
Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться.
S>·>А зачем нужен бессмысленный тест? S>Это ответ на то как поможет нативный менеджер памяти.
Он использует локи, критические секции, что практически не допустимо для LL.
S>·>Ок, подытожу. S>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). S>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта. S> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял.
S>·>В общем, мне надоело, я пас. Оставайся при своём мнении. S>
Я продолжу отвечать на твои вопросы, ликбез всегда полезен, но убеждать больше не буду.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>> То, что при такой нагрузке задержки начинаются только на 10 минуте. S>·>Это не цитата. Приведи точную цитату и ссылочку. Я не понимаю откуда это и в каком это контексте, топик уже слишком большой, у меня в голове не помещается. S> Получается порядка 1.7 сек. Пусть там запиь в Кэш тогда получается 2 секунды на 1000 циклов. S>Пусть крутится 4 потока. Тогда в секунду срабатывает 2000 циклов. S> Значит в секунду выделяется 100 кб* 2000= 200 мб S> В минуту это 12 ГБ. Я кончно не знаю сколько там памяти, но вообще GC срабатывает при заполнении определенного количества. S>Предположим, что ГС срабатывет при полном заполнении и пусть это будет 12 ГБ. S> Тогда он должен сработать как минимум 10 раз до того как задержки превысят порог. При этом нужно дефрагментировать порядка 200 мб
Ок. Проведи тест как считаешь нужным и замерь какой величины задержки создаёт stop-the-world во время сборки поколения 2.
S>·>Какая разница на какой минуте начинаются задержки? Интересует _только_ величина задержки. S> А в том, что при меньших нагрузках этих задержек не будет.
Они могут стать реже. Но куда они денутся?
S> В новых версиязх задержки снижены
S>
S>However in the .NET framework 4.5 there were enhancements to the GC brought in that can help mitigate these (emphasis mine)
S>The new background server GC in the .NET Framework 4.5 offloads much of the GC work associated with a full blocking collection to dedicated background GC threads that can run concurrently with user code, resulting in much shorter (less noticeable) pauses. One customer reported a 70% decrease in GC pause times.
Меня интересуют абсолютные цифры. Если улучшение на 70% от 1 секунды, то это 300мс. Это долго. Нужно <10ms, т.е. улучшение должно быть 99% как минимум.
S>
S>В качестве последнего теста, программа была запущена с помощью нового режима SustainedLowLatency, чтобы увидеть, какой эффект, который имеет. На графике ниже вы можете увидеть это предлагает более низкие время пауз, хотя и не в состоянии поддерживать их в течение неограниченного периода времени. Через 10 минут мы начинаем видеть более длинные паузы по сравнению с теми, кого мы видели, при выполнении теста всего за 5 минут.
S> То есть при соответсвующих нагрузках вполне могут достигать небольшого времени достаточным для задачи.
Ты видимо не понял. Это не улучшение, алгоритм всё тот же, характеристики те же, это просто они сделали рычажок для временного отключения сборки 2го поколения. "не в состоянии поддерживать их в течение неограниченного периода времени" это полный show stopper:
Keep the period of time in low latency [mode] as short as possible. Avoid allocating high amounts of memory during low latency periods
Типичные LL-системы, как самый минимум, должны тянуть трейдерский день, 8-17, т.е. 9 часов непрерывной работы. FX-биржа работает в рабочие дни непрерывно, т.е. 5*24=120 часов непрерывной работы.
S>·>Вообще в статье плохо видно подробности, может у него куча 16гб... S>·>Но лучшего теста у меня нет. Если у тебя есть — показывай, не стесняйся. S> Есть описание механизмов сборки мусора S>http://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/
Я это знаю. Механизм описывает почему эти паузы возникают и как fw код позволяет это организовать с помощью SP.
Для решения проблем задержек нужен совсем другой алгоритм gc, посмотри сколько всяких бывает: https://www.azul.com/resources/azul-technology/azul-c4-garbage-collector/
Например, "mostly incremental compaction" — это дефрагментация, но инкрементальная, т.е. не требуется собирать все 200мб сразу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Чуть более, чем все "софтины" на 17GB это нечто из полусотни, если не больше, отдельных цельных компонент, как с точки зрения разработки, так и с точки зрения использования. Если они внутренние, могут быть тонкие зависимости "buka 1.3.14 требует zuka от 2.7.25 до 2.8.4", но они решаются своими инсталляторами, и обновления загружают только часть из этих правок. N>В цельную, неразделимую, софтину на 17GB, даже если это почти всё — толстые данные типа карт, я не верю при всём желании.
А если "толстые данные в виде текстур", все равно не веришь? У меня для тебя плохие новости.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ·, Вы писали:
V>>Чтобы не утекло, используется специфическая типизация. Например, ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса. ·>Причём тут типизация?
Чтобы не утекло.
·>Ты тут присал "пришел запрос, ты берешь такой аллокатор из пула аллокаторов...". Вот это определяет твою архитектуру — в каком месте именно считается, что "запрос пришел"
Вопрос без исходников конкретного приложения лишен смысла.
·>в каком именно месте можно вернуть в пул (а если мы внезапно что-то решили обработать асинхронно?)
Асинхронно означает "долгий процесс". В долгих процессах другие алгоритмы работы с памятью (пулы объектов, например).
·>Согласен, но это надо далеко не всегда. В подавляющем числе приложений компьютер прибирает достаточно хорошо, чтобы стоило заморачивать себе этим голову.
Я тебе больше скажу. Даже в нейтиве описанную технику применяют ОЧЕНЬ редко.
V>>Ну да, всего-то ~200 машинных инструкций на каждую аллокацию вместо 3-4-х. В зависимости от вида применённого GC, джаве порой сначала надо достать текущий аллокатор из TLS, что порой еще дороже выходит. ·>А доказать? ·>The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions
А теперь посмотри на кол-во инструкций для выделения new int[16].
V>>Еще раз. Медленно. Доставать по всей иерархии аллокатор из TLS очень дорого (всё относительно, может для реальности Джавы и не дорого, фиг его знает ). V>>Но в нейтиве дешевле протянуть контекст явно, потому что порядок цифр другой и TLS начинает влиять. Но в некоем месте "разрыва" своего кода вполне можно выкрутиться, восстановив контекст. ·>TLAB != TLS.
TLAB ( Thread Local Allocation Buffers )
На сегодня существует лишь одна технология доступа к личным данным потока в отсутствии явных зависимостей — это Thread Local Storage. А указатель на TLAB — это лишь одно из значений (одна из переменных) локальных для потока.
Здравствуйте, ·, Вы писали:
·>Зачем в LL фин-данных строки? Клиенсктое приложение обычно не только на другом хосте работает, но и в другой сети и прямого доступа к LL-ядру не имеет. А что там клиентское приложение при получении сетевого пакета соорудит себе строчку — пофиг, клиентское приложение по определению не HFT, человек тупо физически не может заметить задержки меньше 100мс.
Клиентское приложение — это и есть HFT.
Торгуют роботы, а не человек.
Сами эти роботы работают в непосредственной физической близости от биржи, бо за 1 мкс свет проходит всего 300 метров, а даже 1 мкс может повлиять на то, кто будет кушать самые сливки с биржи, а кто остальную сыворотку.
V>>Ближе некуда — используй наиболее подходящую парадигму под каждый сценарий или их сочетания. ·>Где в C# std::function? Мы вроде dotnet обсуждаем. К чему все эти пассажы про Плюсы?
Странный ты. Сам же выдвинул аргумент против плюсов, а теперь решил, что не о них речь.
V>>Это на каждый экземпляр сообщения по такому индексу создавать? ·>Зачем тебе хранить все FIX сообщения в памяти? Храни текущее, обновляй индексы, выполняй бизнес-логику, буферы реюзай под следующее.
Роботы торгуют так: вот есть несколько заготовленных батчей ордеров, по какой-то ситуации на бирже они выставляются или обновляются.
Ордеров может быть сколько угодно.
·>Это не контейнеры, а буфер для передачи данных между потоками. Тот самый твой (context) в каком-то смысле.
Не придирайся. ))
Очередь — это тоже контейнер.
Даже если эта очередь по-умолчанию не сохраняет последовательность, как в дизрапторе.
Мне понравился исходник это дизраптора. Посмотри на него, а потом посмотри на исходник namespace Concurency от MS начиная с 2010-й студии.
Поржал. ))
Здравствуйте, ·, Вы писали:
V>>Еще раз. Гибридные появились из-за того, что уделывают расово-чистые. V>>Никаких других причин тут нет, ес-но. ·>Плохая отмаза. Расово-чистое C++ решение уделает любое гибридное.
Ну мы же не для себя софт пишем, а для клиентов.
Клиенты есть не только под нейтив.
V>>Зачем? Если ты действительно не понял этот абзац — ОК, я просто приму сие к сведению и не буду более аргументировать в эту сторону. ·>А. Перечитал, с третьего раза понял. Так бы и написал, что "c# и java написаны на C++". Зачем такие выкрутасы вворачивать?
Речь шла про "некоторые системные либы", напомню.
Большинство же либ Джавы и Дотнета, напомню, писаны соответственно на Джаве и Сишарпе.
·>А я не совсем понимаю как же ещё-то можно системные вещи писать? Ну там к железке какой обратиться или файлик записать... но обработка fix-протокола не системная вещь, ни разу.
Системный или не системный — это спекуляции.
FIX-протокол содержит внутри себя транспортный + сеансовый уровень по OSI, ну типа как SSL, VPN и т.д.
·>Какого чёрта для чисто прикладной задачи приходится использовать системные штучки, почему стандартного fw не хватает?
Прикладная задача предметной области живет уже сверху протокола.
·>Не я к личности стал прикапываться. Какая разница когда и какую я искал работу?
Разница есть когда тебя малость заносит:
Даю совет: вежливо признать свою неправоту и поблагодарить собеседника гораздо полезнее не только для поднятия своей репутации, но и для собственного развития.
Здравствуйте, vdimas, Вы писали:
V>·>А это вы изобрели TLAB. V>Еще раз. Медленно. Доставать по всей иерархии аллокатор из TLS очень дорого (всё относительно, может для реальности Джавы и не дорого, фиг его знает ).
Адрес аллокатора из TLS достаётся в один mov через регистр fs, и при частых аллокациях всё это будет максимум в L1.
Здравствуйте, alex_public, Вы писали:
EP>>Речь о том что когда на C# нужно создать массив неполиморфных объектов, содержащих внутри другие неполиморфные — то есть struct. EP>>В Java же для аналогичного по скорости кода нужно спускаться на уровень даже ниже чем C. _>Конечно. Но я немного о других вопросах говорил. И даже не о соотношение полиморфных/неполиморфных объектов в классическом ООП коде. Пускай даже стоит задача создать массив неполиморфных (во всяком случае на данном этапе разработки). Вопрос, а какой инструмент возьмёт для этого средний C# программист (это тот самый, который занимается ваянием формочек и никогда не интересовался особенностями работы кэша современных процессоров)? Ты уверен, что он выберет структурку? )
Думаю вероятнее что средний ваятель формочек на C# выберет struct нежели средний ваятель формочек(или какой там аналог) на Java нарежет вручную память на структуры.
EP>>Тут такое дело, когда речь идёт о С++ частенько путают стэковые объекты и например объекты хранящиеся по значению в векторе. И то и то являются основой хорошей производительности производительности, и имеют одни и те же предпосылки, но терминологическии это разные вещи. EP>>Так вот используя эту путаницу евангелисты Java делают вид что escape анализ работает и для случая с вектором, хотя имеет отношение только к оптимизации объектов на стэк. _>Согласен. ) Но это получается всё равно лучше чем виртуальная машина .net, в которой нет даже такого слабенького решения. )
Лучше, вот только важнее наличие структур, точнее эффект намного ощутимее (при прочих сферических равных).
Здравствуйте, ·, Вы писали:
I>>·>Круто, чё, молодцы. Осталось показать это в деле. Жду новый успешно выстреливший стартап на .net core, который заборет все эти тормозные явы. У вас ведь даже фора есть, ведь все ява-разработчики давно уморены долгим нарезанием памяти, .net — вперёд! I>>Фора есть у джавы — дотнет тупил 10 лет. Так что будет очень плавный выход. ·>Плохая отмаза. У нейтива фора была лет 30 в своё время, если не больше, но это не помешало Яве выстрелить.
Не было никакой форы, кучу софта было просто не выгодно писать, об указатели постоянно спотыкались.
Здравствуйте, ·, Вы писали:
I>>Может, если узкое место это, скажем, сетевая карта. А если узкое место это процессор, то джаве до нейтива как до луны раком. ·>Допустим. А если вспомнишь сабж? Чем dotnet в этом смысле лучше?
У дотнета с локальностью данных гораздо лучше, запросто так: value type, generics, fixed и stackalloc. Может еще чтото появилось, не в курсе, 4 года как ушел.
·>Нет. Мы сравниваем c# и java. Java-only приложений полно. А вот c#-only без помощи той же java всё как-то печальнее. Почему тот же самый elasticsearch написан именно на Яве? Ведь c# во всём лучше!?. Начат проект elasticsearch в 2010, в это время c# уже цвёл и пах во всю.
elastic search, внимание, основан на lucene, который внимание, появился ажно в 99м году и был открыт сразу же.
То есть,
1 речь про открытые технологии, а не производительность.
2 в 1999м году не было никакого дотнета
Соответственно, причины
1 в закрытости винды и в том, что дотнет был прибит к ней гвоздями
2 фора в более чем 10 лет
С таким же успехом ты можешь порассужать про интеллект негров на том основании, что в Российской РАН таких около нуля
Здравствуйте, vdimas, Вы писали:
V>А почему ты опять таким образом формулируешь вопрос, что у тебя в нём содержатся аж четыре утверждения? V>Причем, первые три заведомо неверные, а четвертое утверждение является приписыванием первых трёх мне и одновременно с этим возмутительным нахальством. ))
Ты сам утверждаешь, что для LL долгоиграющие потоки — зло. Тебе собтваенно товарищ . объяснил все что нужно. Судя по тому, что у тебя кадры в jpeg вперемешку с биржевым трафиком идут, говорить смысла нет.
Здравствуйте, alex_public, Вы писали:
_>Я смотрю тут дискуссия упёрлась во вроде как парадокс. С одной стороны C# как язык очевидно лучше Java, и просто сам по себе и с точки зрения потенциальной оптимизации. Это факт. А с другой стороны на практике Java показывает лучшие результаты и индустрия явно выбирает Java. Это тоже факт.
Индустрия выбирает открытые технологии. Упоминаемый здесь elasticsearch как раз такой, и основан на lucene, который с 1999 снова такой же — открытый.
Надо только добавить к твоим высказывания, что распрекрасную джаву очень сильно теснят всякие тормозные Python, PHP и даже JS. У них тоже особо серьезный эскейп анализ ?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8). S>> JS может вытестнить https://ru.wikipedia.org/wiki/WebAssembly
_>Это касается только JS в браузере. А скажем на сервере у JS нет никаких врождённых преимуществ, но тем не менее node.js цветёт и пахнет.
Цветут и пахнут вещи намного более тормозные, нежели C#/Java и JS.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное. S>>·>Но мы опять отбиваемся от темы... S>> Там не поддерживаются Ws протоколы, Header итд. Куча шифрований, HAMAC итд. Проще не городить свой Rest,а взять готовый класс с сериализацией десериализацией. Тот же часто использукмый для парсинга сайта AnglrSharp, асинхронный вызов и куча куча всего. ·>Так не пиши ничего на 1С-языке, все эти ъ — это же жуть, и наверняка серьёзная проблема с юнит-тестами. Неужели нет никакого способа написать модуль|расширение|плагин на нормальном ЯП?
Ну это касается, того что 1С не хочет передавать объекты ВК в праметрах. Что касается Windows и Idispatch то с этим все нормально. И можно использовать обертки на объектами .Net без всяких ъ.
В данном случае я показываю, что можно сделать и надеюсь, что 1С пойдет на модификацию Native API которое не менялось лет 6.
S>>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти? S>> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml
·>Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться.
Ну так на этом все нативные менеджеры построены. И ведь работают. А для твоего теста они подходят лучше всего. Просто в .Net ты можешь комбинировать. S>>·>А зачем нужен бессмысленный тест? S>>Это ответ на то как поможет нативный менеджер памяти. ·>Он использует локи, критические секции, что практически не допустимо для LL.
Можно так же использовать все те же interlockedexchange. Этих менеджеров памяти достаточно много. https://habrahabr.ru/company/billing/blog/238787/
S>>·>Ок, подытожу. S>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). S>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
Ну это нужно сравнивать в тестах. Что лучше. S>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего. ·>Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял.
Ну можно писать и на нескольких языках если команда большая. Делать смешанные классы на C++, а использовать их на всех других нетовских языках. Сейчас F# продвигается активно.
·>Я продолжу отвечать на твои вопросы, ликбез всегда полезен, но убеждать больше не буду.
ОК
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
S>>·>Какая разница на какой минуте начинаются задержки? Интересует _только_ величина задержки. S>> А в том, что при меньших нагрузках этих задержек не будет. ·>Они могут стать реже. Но куда они денутся?
Задержки никуда не денутся, но они могут быть меньше 4 мс или какого то допустимого порога.
S>>http://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/ ·>Я это знаю. Механизм описывает почему эти паузы возникают и как fw код позволяет это организовать с помощью SP. ·>Для решения проблем задержек нужен совсем другой алгоритм gc, посмотри сколько всяких бывает: https://www.azul.com/resources/azul-technology/azul-c4-garbage-collector/ ·>Например, "mostly incremental compaction" — это дефрагментация, но инкрементальная, т.е. не требуется собирать все 200мб сразу.
Да только в твоем примере эти 200мб постоянно обновляются и выделяются с большой скоростью, а значит сильно фрагментирут память, так как не дефрагментировали полностью, а за недефрагментированными кусками нужно следить.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
V>>А почему ты опять таким образом формулируешь вопрос, что у тебя в нём содержатся аж четыре утверждения? V>>Причем, первые три заведомо неверные, а четвертое утверждение является приписыванием первых трёх мне и одновременно с этим возмутительным нахальством. )) I>Ты сам утверждаешь, что для LL долгоиграющие потоки — зло. Тебе собтваенно товарищ . объяснил все что нужно.
Товарищ не ведает что пишет:
·>Да и тысячу клиентов можно по дюжине шлюзов разбалансить.
Т.е., передать инфу на другое ядро внутри одной системы нельзя, а на другой шлюз можно?
I>Судя по тому, что у тебя кадры в jpeg вперемешку с биржевым трафиком идут, говорить смысла нет.
А ну ясно. Ты тем самым лишь показываешь, что абсолютно не в курсе как устроены клиентские биржевые проги. Это ни разу не смертельно, ес-но, просто надо помнить, что такие расклады не позволяют тебе задавать вопросы в виде утверждений. Тут уместнее задавать обычные вопросы.
