Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе?
Ну вот я тебе послал линк на опции конфигурации режимов GC в ответ.
Потому что да, если взять опцию Batch, то паузы будут как в оракловой джаве.
·>конечно, это статья двухлетней давности, может что-то и поменялось с тех пор... но я почему-то уверен, что нет.
В смысле, прибавилось ли у шуллеров по ссылке совести?
Сильно сомневаюсь. Насколько я понял, этот azul довольно дорогой, поэтому для его втюхивания все ср-ва хороши.
============
Кароч, там где в мире джава есть куча движков с разным GC, в мире дотнета вместо всего выбор конкретного алгоритма GC задаётся конфигурацией системы (а она иерархическая, т.е. на уровне системы, пользователя, программы и т.д.).
Здравствуйте, ·, Вы писали:
S>> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S>> В то время, когда таски бороздят все пространство ... ·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread.
Над thread pool, причём, там всё на lock-free и жутко заоптимизировано.
Здравствуйте, netch80, Вы писали:
N>Чуть более, чем все "софтины" на 17GB это нечто из полусотни, если не больше, отдельных цельных компонент, как с точки зрения разработки, так и с точки зрения использования.
абсолютно согласен
C>>>Никто не мешает софтине иметь дельта-обновления. Централизованные обновления были бы более приятными, но не являются так уж необходимыми. Ф>>Дельта-обновления — это компонентные обновления? Что ты под этим понимаешь? N>Это когда разница между последовательными версиями некоторого компонента заключается в изменении, например, одной библиотеки из 10 в его составе, и дельта-пакет содержит только эту библиотеку. N>Разумеется, дельта требует именно той уже установленной версии, под которую строилась (хотя можно и несколько последовательных дельт применить — не знаю, есть ли это вживую).
В терминологии Windows Installation Services (который ставит msi), это называется Patch. Дальше идёт Minor Update, он может менять состав компонентов.
Ф>>В третьих, MV VS сильно интегрируется в систему: в системные каталоги копируются новые библиотеки (VC++ Redistributable, например), ставится MS Build, регистрируются COM-компоненты. Твой XCode и рядом не стоял по этому параметру. N>А проверить, куда он что установил, можно? Вот я, например, вижу
Можно, но значительно сложнее: инсталлятор MS VS представляет из себя "Boostrapper Apllication", основная задача которого разруливать зависимости между компонентами, т.е. решать какие из MSI'ек здесь надо ставить, а какие нет, и возможна ли установка в принципе. При этом в системе регистрируются только сами "компоненты". Сказать, кто их поставил: VS Installer, или Windows Update сложно, но пользователю это обычно и не нужно.
Однако да, всё, что инсталлируется, оставляет след в реестре, и сказать, что ставилось можно.
Ф>>В четвёртых, если что-то пойдёт не так во время установки на макоси (отсутствует какая-нибудь либа, например), то уже ничего не исправить. Наверное, поэтому он в систему и не интегрируется. Под Windows всё иначе: во время установки создаётся VSS Snapshot, и ты в любой момент можешь вернуться к состоянию до установки. В мире *nix вообще со снэпшотами очень грустно: хочешь БД забэкапить в консистентном состоянии — останавливай, а потом бэкапь. Нехорошо.
N>Это от БД зависит.
Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют), да и сама запись не мгновенно происходит, и это не атомарная операция — это во-первых. А во-вторых часть данных может писаться не в БД, а в файлы, которые лежат рядом...
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, ·, Вы писали:
EP>>·>Сильно "ограниченный" язык даёт возможность создать вменяемую IDE и уменьшить сложность кода. Да и часто лучше иметь много простого кода, чем немного сложного. EP>>Нарезание буферов вручную на структуры это не простой код, при этом структуры встроенные в язык (например как в древнем C) — это не сложно, а наоборот намного проще. EP>>Так что получается не много простого кода VS немного сложного, а много сложного VS немного простого ·>Такого сложного, специально вылизанного кода довольно мало, только в каких-то нескольких важных местах, думаю меньше процента от всего объёма исходников.
Так именно там и происходит основной кипишь — о таком же коде и идёт разговор?
·>В том же С/С++/C# подобные части кода тоже будут не совсем классическим кодом, а аккуратно прилизанным и wtf-ным. Заоптимизированный вусмерть код везде выглядит одинаково плохо.
C#, да и C, в этом списке не в тему.
Да и не надо рассказывать про "одинаково плохо" — одно дело заменить аллокатор, использовать pool и т.п., и совершенно другое это отказ от базовых средств типа классов, GC, лямбд, ФВП, и т.п. С таким подходом можно договорится до того что код на ASM будет также выглядеть "одинаково плохо".
EP>>>>·>На c# (без native) — невозможно. EP>>>>Почему? EP>>·>Тормозной он EP>>В чём конкретно это выражается? ·>Ссылку на отстойность gc я уже тут приводил.
Даже если допустить отстойность GC — всё равно и там и там будет отказ от GC в критичных местах, только в C# это поддерживается из коробки (массив структур), а в Java делается в рукопашную.
EP>>·>Плюс win-only EP>>Да, но речь же о какой-то принципиальной невозможности. Или хочешь сказать что Win-only в данном контексте и есть невозможность? ·>Да. Скажем, где там у вас hardware networking timestamping? Или нормальная поддержка высокопроизводительного железа типа solarflare?
Не у "нас" — я вообще в стороне от этой схватки — без проблем использую любую OS, и Win-only не защищаю.
Но судя же по дискуссии выше — C# решения таки встречаются, значит Win-only не является аргументом в пользу невозможности.
EP>>·>А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе? EP>>Не знаю отсутствует или нет, но даже если отсутствует — то объяснений может быть множество. EP>>Вон ту же Java туда пытаются затолкнуть, хотя это и стоит титанических усилий. ·>Уж больше 5 лет назад как затолкнули.
Значит либо требования по производительности не такие жёсткие как рисуют, либо конкуренции особой нет раз есть ресурсы на такой распил-заталкивание.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>>·> А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе? V>Клиентских или серверных?
Здравствуйте, Cyberax, Вы писали:
C>Просто копирование изменённых файлов, обновлятором внутри самой софтины.
А нафига он внутри софтины? Это такая специфичная операция, что-то обновить?
C>Ну вот. С XCode нет таких проблем.
Не вижу никаких проблем.
Ф>>В третьих, MV VS сильно интегрируется в систему: в системные каталоги копируются новые библиотеки (VC++ Redistributable, например), ставится MS Build, регистрируются COM-компоненты. Твой XCode и рядом не стоял по этому параметру. C>Ну так это не повод для гордости. Как-то в Mac OS X умудряются обойтись без такого BDSM.
Это не BDSM, это имеет свои бенефиты, иногда очень значительные. Например, позволяет тебе прозрачно дебажить сервисы, которые общаются между собой c помощью WCF.
Ф>>В мире *nix вообще со снэпшотами очень грустно: хочешь БД забэкапить в консистентном состоянии — останавливай, а потом бэкапь. Нехорошо. C>Бред (про Линукс).
?????
Ф>>И последнее: 3 минуты — это только запись файлов на неплохой SSD, а бывает что на машине не SSD. У нас тут до сих пор многие без SSD живут. C>CCЗБ.
Но тебе всё равно придётся это учитывать при выпуске продукта.
C>>>Так как на практике таких софтин нет. Самая большая у меня в каталоге Applications — Xcode, на 10Гб. Ф>>17 Gb — это какой-нибудь Starcraft2. Игрушки бывают и больше. Ф>>Что любопытно, Blizzard не заставляет меня выкачитвать по 17 Gb каждую неделю — в абсолютном большинстве апдэйты незаметные, которые выкачиваются почти мгновенно. Ставятся столь же быстро как и выкачиваются. C>Ну вот там где надо — инкрементальные обновления есть. В 90% случаев (если не больше) они не нужны, потому никто на Mac OS X особо и не заморачивается.
Они почти везде нужны: даже у средней руки программера софта обычно не меньше чем на 20 Gb (включая SDK, документацию, ресурсники и т.д.) и всё это нужно периодически обновлять. Проще и быстрее скачать обновить один 40 Kb файл, а не сначала тянуть всё из сети, потом ВСЁ сносить, и всё заново копировать. Примеры с ресурсниками я тут уже приводил: поправили перевод двух слов для традиционного китайского, а ты уже хочешь всё сносить и всё ставить заново.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, ·, Вы писали:
·>Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх.
Здравствуйте, Философ, Вы писали:
Ф>Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют)
ЩИТО?
Ф>да и сама запись не мгновенно происходит, и это не атомарная операция — это во-первых.
Атомарная.
Ф>А во-вторых часть данных может писаться не в БД, а в файлы, которые лежат рядом...
А это не проблема БД.
Здравствуйте, vdimas, Вы писали:
V>>>Про задержки я тебе уже отвечал в цифрах: джава уступает нейтиву в двадцать-тридцать раз, дотнету в два-три раза. V>·>Погоди. Ты объясни что конкретно сранвивается. Приведённые твои ссылки на fix engines как я понял это по сути одна нативная библиотека с тремя публичными api c++, java, c#. Т.е. ты сравниваешь нативную либу с этой же либой+java wrapper. Так что-ли? V>Не так. Джава чистая, в дотнете достоверно сетевой слой и многопоточность/синхронизация нейтивные. Больше сказать не могу. ))
Т.е. нативная либа с нашлёпкой сишарп в целых 10 раз быстрее тупо написанного чистого java-кода с развесистыми fix-сообщениями. Это успех, я счетаю!
V>·>Ну потому что я хочу сравнивать java vs dotnet, а не native+java vs native. V>Ну так и отвечаю последовательно: крупные биржи нейтивные (торговые их движки).
Супер. Поздравляю. А теперь расскажи как это относится к сабжу?
V>А обслуживающие утилиты могут быть писаны на чем угодно — нейтивные, скриптовые, дотнетные и джавовские. V>Причем, в последние годы всё более популярным становится веб-интерфейс (интранет) и обе управляемых среды всё больше отдают долю скриптовым решениям даже на внутренне-утилитном поприще.
Ну да. А потом нужен какой-то универсальный апи. И конверсия между языками и прочий EE и угар. А представь когда всё на одном языке и посылка сообщения другому — это не какой-то протокол, а просто вызов метода интерфейса, и тут же можно посмотреть его имплементацию...
V>Что, прямо-таки торговый движок на джаве?
Да, FX exchange, order book, matching engine (Execution Venue), Execution Management System, market data, ITCH, и куча всякой обвязки вокруг.
V>Зашел к ним на сайт: https://www.lmax.com V>Там жесть... V>Вот сам зайди, плиз.
Зачем мне на сайт заходить, я и так знаю чем они занимаются... я к ним в офис заходил... регулярно.
V>>>Вообще ничего нельзя на ём сделать, связан по рукам и ногам. )) V>·>Что именно нельзя сделать? По сравнению с .net — она просто всемогутер. V>Ну это можно говорить только от предвзятости к дотнету. Там где в Джава, например, надо писать сложные JNI и прочие обертки, причем, падучие, сложные в отладке и которые легко гадят в память процесса (бегают по памяти), там в дотнете для обращения к нейтивным либам достаточно декларативно прописать Interop.
Не надо JNI сложные писать. Зачем? Да и сам JNI тупой и простой как пробка. Отлаживается тоже элементарно, тесты же есть, а накрайняк можно и отладчиком подцепиться.
V>Именно поэтому я порой для прототипирования юзаю дотнет, а не джаву, что всегда могу подёргать из дотнета практически любые нейтивные либы или АПИ ОС фактически даром.
Ну и JNA есть для ленивых. А вообще редко что приходится дёргать, если писать серверный код, а не GUI или специфическое оборудование.
V>>>·>Кстати, Rapid Addition FIX engine — тоже афаир pure-java. Сравнивали? Насколько медленнее нативного? V>>>Rapid сливает нам примерно двое, B2BITS примерно в полтора раза. V>·>Вот полтора-два раза уже более похожий на правду результат, а не твои "двадцать-тридцать". V>Это их нейтивный вариант сливает в полтора раза. )) V>А наш джавовский сливает нашему нейтивному в двадцать-тридцать раз, а их сливает еще больше.
Фиг знает, я не сравнивал. Может быть. Пусть так. В любом случае не одним fix engine биржа жива.
V>·>А не подскажешь удалось ли кому сделать вменяемый pure C# fix engine? V>Удавалось, а смысл?
Кому?
V>>>При том, что на дотнете всё еще удобно писать ту самую управляющую бизнес-логику. V>>>Кароч, такая же песочница, как и Джава. V>·>А ещё удобнее писать всё на одном языке. А не думать где там чё и куда можно рыбу заворачивать. V>На джаве это будет минимум два языка — еще же море XML! Не слушай на росказни J2EE быдлокодеров. Есть даже такое понятие Core Java, которое в резюме очень привлекает HR-агентов.
Кстати мода на XML уже давно прошла, его даже из EE уже почти отовсюду выпилили.
V>·>Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу. V>Уступают в 20-30 раз.
Даже если и так, то с c# дела будут ещё хуже.
V>·>На c# (без native) — невозможно. V>Возможно и они не уступают джавовским. V>Ну реально, с каких это пор джава стала быстрее дотнета в сфере latency?
Всегда была.
V>Или ты сравниваешь современную джаву с дотнетом от 2003-го года? V>Дотнет сходу вышел шустрее джавы и все года задавал ей планку. Или я пропустил какую-то важную новость вот буквально последнего года, что в джава придумали хороший оптимизатор? ))
JIT явы всегда был на голову выше шарпа.
V>Вот в дотнете хороший уже есть — это виндовый Магазин, где дотнетные приложухи сурово оптимизируются в нейтив. Никакой JIT не даст сравнимый уровень оптимизации, ес-но, это всё показывает хоть какие-то результаты лишь на стадии офлайн компиляции.
Понятно, что код прогревают. Суровая оптимизация в нейтив может быть полезна для мелких часто запускаемых утилит, а не для серверного кода.
V>>>Давай я не буду эту тему обсуждать. Я могу рассказать, что тут можно сделать, когда у тебя развязаны руки и тебе доступны все ср-ва ОС. V>·>Какие именно необходимые средства недоступны в java? V>Тонкое управление барьерами памяти, atomic-стратегиями чтения, локальное управление выделением памяти, заточенное под конкретный сценарий, дешевый lock-free и куча еще всего.
Ну java.util.concurrent много что умеет.
Управление памятью можно и с Buffer сделать.
V>Например, FIX-сообщение в джава — это развесистый граф объектов с кучей ссылок, а в нейтиве — сплошная область памяти.
Не обязательно. Почешите голову над дизайном и продумайте внутренние структуры данных.
V>·>Понятное дело, что всякие системные штуки типа set cpu affinity из явы недоступны, но они там и не нужны V>Нужны, до 2-4-х раз latency натюнить можно (и нужно).
Не нужны в самой яве. Но настраивать понятное дело нужно на уровне операционки.
V>·>т.к. это рулится во время запуска самой jvm. V>Ты не можешь гарантировать, что один и тот же джавовский поток будет исполняться на одном и том же потоке ОС всё время своей жизни. Для дотнета та же засада, кста, поэтому, управлять cpu affinity можно только для потоков, создаваемых и управляемых из нейтива. Вот почему, собсно, эта область программы тоже должна жить в нейтиве.
Не должна. Это настраивается в инфраструктуре, на системном уровне. В самом ява-приложении не нужно. Вот тут с циферками и подробностями что и как можно настраивать: https://youtu.be/-6nrhSdu--s?t=39m28s
V>·>Да, возможно ещё потребуется всякие тонкие настройки операционки и железа, типа irq balance и прочей магии. Но это всё инфраструктура, рулится и без явы, а какими-нибудь bash-скриптами и всяким /proc /etc. V>Ну так ты мне ссылку на официальные цифры твоего Rapid для их джава-движка дай, чтобы стало понятно, в каких пределах это влияет на результат.
Нет у меня... Но в любом случае Fix gateway не самый быстрый и важный компонет биржи, да и дистрибьютится он на ура.
V>·>Для LL имеет значение худший случай — тот самый длинный хвост на гисторамме в области 99.99%. Полмикросекунды это средний (или даже лучший) случай. Под виндой пробуждение потока ВНЕЗАПНО может занять десятки, сотни миллисекунд, если карты плохо лягут. V>Не только под виндой, под любой многозадачной ОС. Под ними даже не спящий поток может быть резко приостановлен на относительно долго.
Посмотри ролик выше как это можно побороть.
V>Но по ссылкам, данным мною, кста, помимо самих цифр latency есть графики РАЗБРОСА значений. Просто посмотри на них и сравни. У хороших движков разброс минимален. Можно сказать, что его и нет вовсе. С чудовищным разбросом результатов по Джава это сравнивать нельзя.
Что-то туплю. Где там графики? Или надо обязательно SDK качать?
V>·>ГЦ в C#, в zing — не опасен. V>Почитал про zing — там никакой полной сборки. )) V>Там просто очень много приседаний, чтобы размазать работу GC во времени, в итоге общая трудоёмкость сборки резко выше и в памяти могут долго находиться очень древние объекты, в итоге среднее быстредействие программ на zing заметно меньше.
Это понятно. Тут ведь как — либо предсказуемо, либо быстро. В LL важна предсказуемость.
V>Т.е. это специфический GC, который лечит клиническую кривизну кода, когда обычные явовские движки уходят в своп на десятки секунд. Ну, блин, в дотнете и проблемы-то такой с момента выхода версии 4.5 нет.
Как минимум стоит заметить, что zing появился в 2010, а 4.5 вышел в 2012.
Да и собственно по цифрам zing таки впереди.
V>>>Тут можно говорить лишь о длительностях пауз. V>>>Если для Джавы это были десятки секунд, V>·>Это скорее всего на допотопном gc или неправильно настроенном. V>Это нагрузки зависит, а не допотопности.
Да, есть такое — под конкретную нагрузку надо конкретно настраивать, чтобы он вменяемо работал.
V>Если памяти каюк и сотни миллионов объектов на освобождение, то деваться некуда. V>Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток.
Ну так лучше не делать вообще в LL-коде. Disruptor же есть.
V>Так вот, дотнетный движок легко справляется с 0-м поколением даже из "чужого" для объекта потока, а в джаве, похоже, такие объекты улетают в 1-е поколение, затем быстро упираемся в потолок и начинается сплошное GC. При том, что дотнетный тест может работать вечно без пауз — в фоне прекрасно всё чистится. Вот чтобы ты знал — для таких сценариев и нужен твой zing.
Ну не совсем. В Яве такой же подход с 0-м и 2-м поколением, а zing нужен т.к. кроме LL-важного потока в приложении бывает всякое разное, что таки может внезапно намусорить.
V>Далее. Отсутствие в Джаве value-типов делает среднюю джавовскую прогу намного развесистее в памяти, чем аналогичную на дотнете, где многое можно размещать по значению. Да, я в курсе про хот-спот и реальный эффект от него. Он мизерный, в сравнении с эффектом от продуманного разработчиком графа на value-types дотнета.
Да, есть такое. Но можно граф поуменьшить, и байт-буферы использовать.
V>·>В zing задержка более 10ms — это production issue, сразу создаётся тикет в саппорт Azul. Если интересно могу рассказать байку о последнем баге, дававшем жутчайшие тормоза вполть до 100мс на одном из хостов. V>Да я верю, спасибо за наводку, было интересно почитать про алгоритмы сборки мусора zing. V>Это круто, согласен... Перерасход памяти, правда, черезчур (на т.н. "фантомные страницы") и слишком много жутко дорогих Access Violation (на каждый неверно помеченный объект). Собственно, на этом AV построен сам принцип его работы. Оригинально, чо! )) Я в очередной раз порадовался, что большую часть времени имею дело с нейтивом...
Ага, и тем более радостно, что не с шарпом. Там даже альтернативную VM или специфичный сброщик мусора хрен запилишь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>·>Кстати, я же тебе посылал этот линк: http://mattwarren.org/2014/06/18/measuring-the-impact-of-the-net-garbage-collector/ V>·>Паузы бывают до 4 СЕКУНД!!! V>Ну вот я тебе послал линк на опции конфигурации режимов GC в ответ. V>Потому что да, если взять опцию Batch, то паузы будут как в оракловой джаве.
Ну в этой статье эти режимы и обсуждаются.
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.”
V>·>конечно, это статья двухлетней давности, может что-то и поменялось с тех пор... но я почему-то уверен, что нет. V>В смысле, прибавилось ли у шуллеров по ссылке совести?
У тебя есть другие ссылки, более совестливые?
V>Сильно сомневаюсь. Насколько я понял, этот azul довольно дорогой, поэтому для его втюхивания все ср-ва хороши.
Он того стоит. Притом его много не надо, только LL-чувствительные сервисы и только в prod работают на zing.
V>Кароч, там где в мире джава есть куча движков с разным GC, в мире дотнета вместо всего выбор конкретного алгоритма GC задаётся конфигурацией системы (а она иерархическая, т.е. на уровне системы, пользователя, программы и т.д.).
Т.е.? В "стандартной" версии движка тоже несколько алгоритмов с тучей параметров, которые можно покрутить. Просто для специфических требований требуются очень специфические алгоритмы, стандартных не хватает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
S>>> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S>>> В то время, когда таски бороздят все пространство ... V>·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. V>Над thread pool, причём, там всё на lock-free и жутко заоптимизировано.
Ну и зачем тредпул для долгоиграющих тредов?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Такого сложного, специально вылизанного кода довольно мало, только в каких-то нескольких важных местах, думаю меньше процента от всего объёма исходников. EP>Так именно там и происходит основной кипишь — о таком же коде и идёт разговор?
Код никому не интересен. Интересен весь программный продукт. Гораздо проще когда он написан на одном языке.
EP>C#, да и C, в этом списке не в тему. EP>Да и не надо рассказывать про "одинаково плохо" — одно дело заменить аллокатор, использовать pool и т.п., и совершенно другое это отказ от базовых средств типа классов, GC, лямбд, ФВП, и т.п. С таким подходом можно договорится до того что код на ASM будет также выглядеть "одинаково плохо".
Другой язык и чуть другой стиль кодирования — немного разные вещи.
Ибо все эти буферы/пулы довольно локализваны и скрыты в имплементации, дёргаешь публичные методы и особо не вникаешь какие там аллокаторы.
EP>>>В чём конкретно это выражается? EP>·>Ссылку на отстойность gc я уже тут приводил. EP>Даже если допустить отстойность GC — всё равно и там и там будет отказ от GC в критичных местах, только в C# это поддерживается из коробки (массив структур), а в Java делается в рукопашную.
Да, есть такое. Но это, как оказывается на практике, совсем не критично.
EP>>>Да, но речь же о какой-то принципиальной невозможности. Или хочешь сказать что Win-only в данном контексте и есть невозможность? EP>·>Да. Скажем, где там у вас hardware networking timestamping? Или нормальная поддержка высокопроизводительного железа типа solarflare? EP>Не у "нас" — я вообще в стороне от этой схватки — без проблем использую любую OS, и Win-only не защищаю. EP>Но судя же по дискуссии выше — C# решения таки встречаются, значит Win-only не является аргументом в пользу невозможности.
Судя по дискуссии выше C# решения при близком рассмотрении оказались просто обёртки над нативной имплементацией... ну не помогают эти ваши массивы структур. А вот "в рукопашную" на Яве как оказалось на практике — таки делается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх. S>> Вот именно, что там намного сложнее чем Thread. Там свой планировщик, CancellationToken. S>> И работа идет с пулом потоков а не с массивом processingThreads[i] = new Thread(() S>> Поверь разница велика. ·>Не понял. Ты хочешь скзать, что с tasks код "while(true)..." заработает быстрее и будет показывать лучшее время gc? За счёт чего?
За счет того, что состояние хранит не на стеке потока, и в регистрах, а в полях класса. А те которые в потоке с ними проще работать, так как в пуле их немного.
S>> А кстати в .Net Core для библиотек Thread просто нет. ·>?
Нужно отдельно добавлять пакет System.Threading.Thread
Здравствуйте, ·, Вы писали:
·>Здравствуйте, vdimas, Вы писали:
S>>>> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S>>>> В то время, когда таски бороздят все пространство ... V>>·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. V>>Над thread pool, причём, там всё на lock-free и жутко заоптимизировано. ·>Ну и зачем тредпул для долгоиграющих тредов?
В твоем примере не долгоиграющие, а долго ожидающие. Для этого существуют async await.
Для долгоиграющих задач есть свой планировщик. И опция TaskCreationOptions.LongRunning http://stackoverflow.com/questions/26921191/how-to-pass-longrunning-flag-specifically-to-task-run
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Поверь разница велика. S>·>Не понял. Ты хочешь скзать, что с tasks код "while(true)..." заработает быстрее и будет показывать лучшее время gc? За счёт чего? S> За счет того, что состояние хранит не на стеке потока, и в регистрах, а в полях класса. А те которые в потоке с ними проще работать, так как в пуле их немного.
Какое ты увидел состояние в том коде? В каких полях какого класса?
S>>> А кстати в .Net Core для библиотек Thread просто нет. S>·>? S> Нужно отдельно добавлять пакет System.Threading.Thread S>http://stackoverflow.com/questions/38080995/net-core-1-0-equivalent-for-system-threading-thread-currentthread-managedthread S> Да там например Sleep отсутствует. Для этого используется await Task.Delay.
Эээ... И что? Я всё ещё не понимаю как это относится к тому коду, к особенностям работы gc и к LL?
S> Кстати ветка по поводу асинхронного программирования. Как оптимизировать выполнения 10000 параллельных задач?
В случае LL выполнение 10000 параллельных задач не бывает. Не надо путать low latency и high throughput.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> Поверь разница велика. S>>·>Не понял. Ты хочешь скзать, что с tasks код "while(true)..." заработает быстрее и будет показывать лучшее время gc? За счёт чего? S>> За счет того, что состояние хранит не на стеке потока, и в регистрах, а в полях класса. А те которые в потоке с ними проще работать, так как в пуле их немного. ·>Какое ты увидел состояние в том коде? В каких полях какого класса?
А поток, что выполняет? В Task создается класс и автомат для перехода по await S>>>> А кстати в .Net Core для библиотек Thread просто нет. S>>·>? S>> Нужно отдельно добавлять пакет System.Threading.Thread S>>http://stackoverflow.com/questions/38080995/net-core-1-0-equivalent-for-system-threading-thread-currentthread-managedthread S>> Да там например Sleep отсутствует. Для этого используется await Task.Delay. ·>Эээ... И что? Я всё ещё не понимаю как это относится к тому коду, к особенностям работы gc и к LL?
Это относится к тому, что потоки это уже старое ненужное.
S>> Кстати ветка по поводу асинхронного программирования. Как оптимизировать выполнения 10000 параллельных задач? ·>В случае LL выполнение 10000 параллельных задач не бывает. Не надо путать low latency и high throughput.
Ты привел какой то непонятный пример с огромным количеством потоков. На GC как раз влияет количество потоков, где нужно его останавливать, смотреть стек потока регистры.
В Task все данные хранятся внутри генерируемого класса. Async/await и механизм реализации в C# 5.0 https://habrahabr.ru/post/260217/
При этом пока задача вне потока выполнения код хранится в виде делегата. Никакого стека, регистров. Нужно приостановить только планировщик.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>>·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. V>>>Над thread pool, причём, там всё на lock-free и жутко заоптимизировано. S>·>Ну и зачем тредпул для долгоиграющих тредов? S> В твоем примере не долгоиграющие, а долго ожидающие. Для этого существуют async await.
О божемодераторе, дай сил не перейти на оскорбления.
Ожидающие чего??? Какой такой тредпул в LL приложении??? Можешь объяснить в какой момент времени тред с таким таском будет отдаваться в пул?
"while(true)" это не просто долго-, но даже вечно-играющий цикл.
S>Для долгоиграющих задач есть свой планировщик. И опция TaskCreationOptions.LongRunning S>http://stackoverflow.com/questions/26921191/how-to-pass-longrunning-flag-specifically-to-task-run
Что ты мне сказки рассказываешь? Я же ссылкой даже тыкнул уже. Тебе лень было посмотреть? Вот как устроен твой магический планировщик для долгоиграющих задач:
protected internal override void QueueTask(Task task)
{
if ((task.Options & TaskCreationOptions.LongRunning) != 0)
{
// Run LongRunning tasks on their own dedicated thread.
Thread thread = new Thread(s_longRunningThreadWork);
thread.IsBackground = true; // Keep this thread from blocking process shutdown
thread.Start(task);
}
...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Не слушай на росказни J2EE быдлокодеров. Есть даже такое понятие Core Java, которое в резюме очень привлекает HR-агентов.
