Здравствуйте, Философ, Вы писали:
C>>Никто не мешает софтине иметь дельта-обновления. Централизованные обновления были бы более приятными, но не являются так уж необходимыми. Ф>Дельта-обновления — это компонентные обновления? Что ты под этим понимаешь?
Просто копирование изменённых файлов, обновлятором внутри самой софтины.
C>>Самая большая у меня в каталоге Applications — Xcode, на 10Гб. Вот только что проверил — снос и установка заново занимают 3 минуты. Это меньше, чем требуется типичному MSI на то, чтобы прочитать все эти таблицы обновлений. Я уж не говорю про тот Мордор, которым является установщик MSVS. Ф>Во-первых, Мордор обновляется чуть ли не раз в неделю, и состоит из огромной тучи компонентов, таких как "Visual Studio Tools for Office", "ReportViewer", "Web\Snippets" и т.д, которые могут быть установлены или не установлены, а так же установлены только частично.
Ну вот. С XCode нет таких проблем.
Ф>В третьих, MV VS сильно интегрируется в систему: в системные каталоги копируются новые библиотеки (VC++ Redistributable, например), ставится MS Build, регистрируются COM-компоненты. Твой XCode и рядом не стоял по этому параметру.
Ну так это не повод для гордости. Как-то в Mac OS X умудряются обойтись без такого BDSM.
Ф>В четвёртых, если что-то пойдёт не так во время установки на макоси (отсутствует какая-нибудь либа, например), то уже ничего не исправить. Наверное, поэтому он в систему и не интегрируется. Под Windows всё иначе: во время установки создаётся VSS Snapshot, и ты в любой момент можешь вернуться к состоянию до установки. В мире *nix вообще со снэпшотами очень грустно: хочешь БД забэкапить в консистентном состоянии — останавливай, а потом бэкапь. Нехорошо.
Бред (про Линукс).
Ф>И последнее: 3 минуты — это только запись файлов на неплохой SSD, а бывает что на машине не SSD. У нас тут до сих пор многие без SSD живут.
CCЗБ.
C>>Так как на практике таких софтин нет. Самая большая у меня в каталоге Applications — Xcode, на 10Гб. Ф>17 Gb — это какой-нибудь Starcraft2. Игрушки бывают и больше. Ф>Что любопытно, Blizzard не заставляет меня выкачитвать по 17 Gb каждую неделю — в абсолютном большинстве апдэйты незаметные, которые выкачиваются почти мгновенно. Ставятся столь же быстро как и выкачиваются.
Ну вот там где надо — инкрементальные обновления есть. В 90% случаев (если не больше) они не нужны, потому никто на Mac OS X особо и не заморачивается.
Здравствуйте, vdimas, Вы писали:
C>>Ну да. Код должен распространятся раз в месяц, в четверг. Если что-то сломалось — пишется заявление в отдел QA и через год фиксится. V>В мире Windows фиксится намного быстрее. И мне уже надоело напоминать, почему именно так — потому что всего одна "сборка".
См. начало треда.
C>>LOL. У Клинтон как раз был Exchange на Винде. V>Там в сетку вошли через их линуховые машины и атаковали клиентские компы, а не серверные.
Ты сам атаковал?
V>И да, никакой exchange-сервак напрямую в сеть никогда не торчит, только через линуховые машины или линуховые же роутеры.
Вот такой защищённый этот Windows Server.
C>>ReFS — это та штука, которая является бледным подобием BTRFS и которая выбросила на помойку такие фичи NTFS как транзакции? V>Это такая штука, потребность в транзакционности внутреннего механизма которой сильно уменьшена.
Да-да.
V>И да, транзакции там можно включить по желанию и аж более одного уровня. Но почти никогда не надо из-за банального copy-on-write, доведённого до совершенства. Там всё является транзакцией (грубо), т.е. используются те же технологии, что и для транзакций.
Для тебя это новость, но на этой основе построены ZFS и BTRFS, которым уже 15 лет и 7 лет соответственно.
C>>Ну то есть, проблемы нет. Совместимость минимум на 15 лет. В отличие от. V>В отличие от чего?
От MS, в которой PowerShell Remoting с трудом совместим внутри одной версии Винды.
C>>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509. V>Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". V>- SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание. V>Дерзай! ))
Сойдёт. $1k на бочку.
V>Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной.
Нет, она не построено идентично. В частности, нет аналога CN в X509.
Здравствуйте, Cyberax, Вы писали:
C>>>Только это работает на практике лучше, чем угрёбищный MSI. А для end-user приложений популярны разные магазины, которые автоматизируют обновление и установку. I>>На практике под макось отсутствует внятный софт. C>Типа MS Office?
Все что угодно, типа фривары и шаровары.
I>>Не дай бог поставить что нибудь нестандартное, вспотеешь вычищать. Потому пилятся потиху вещи навроде Homebrew C>Homebrew — это вполне классический юниксовый пакетный менеджер. И используется практически эксклюзивно для утилит командной строки (из графического там встречал только WireShark да gitk). Я говорю про установщики конечных приложений.
То есть, сначала ты сказал, что все в порядке, а теперь оказывается, что это справедливо только для некоторого подмножества приложений. Опаньки !
Не ты ли пять лет назад жаждал, что бы от Эппла остался "дымящийся кратер" ?
Здравствуйте, Философ, Вы писали:
Ф>>>>>Обновлять потом как будешь? Лет 8 назад я тоже только файлики копировал. C>>>>Снова файлы скопировать. Ф>>>Все файлы? У меня тут стоит одна софтина, которая 17 гигов весит. Ты каждый раз собираешься по 17 гигов копировать? C>>Да, а какие проблемы?
Ф>Проблема у тебя будет в том, что я после 4-го апдейта на 17 Gb потребую refund. Думаю, не только я.
Чуть более, чем все "софтины" на 17GB это нечто из полусотни, если не больше, отдельных цельных компонент, как с точки зрения разработки, так и с точки зрения использования. Если они внутренние, могут быть тонкие зависимости "buka 1.3.14 требует zuka от 2.7.25 до 2.8.4", но они решаются своими инсталляторами, и обновления загружают только часть из этих правок.
В цельную, неразделимую, софтину на 17GB, даже если это почти всё — толстые данные типа карт, я не верю при всём желании.
При этом, если пакетный менеджер стиля типичных нынешних юниксов, компоненты экспортированы в общее окружение и могут быть использованы всеми, поэтому обновление учтёт каждое изменение само по себе.
Ну и возможности современных пакетных менеджеров типа zypper (SuSE) заказывать и получать не целые пакеты, а дельты, могут помогать ещё больше экономить трафик — по крайней мере для типичных случаев типа firefox 48 -> 49.
Боюсь, тут Cyberax слишком завяз в контекст всяких виртуалок поверх амазона, докера и т.п., которые ставятся и сносятся целиком, но тем не менее это тоже важный частный случай.
C>>Никто не мешает софтине иметь дельта-обновления. Централизованные обновления были бы более приятными, но не являются так уж необходимыми. Ф>Дельта-обновления — это компонентные обновления? Что ты под этим понимаешь?
Это когда разница между последовательными версиями некоторого компонента заключается в изменении, например, одной библиотеки из 10 в его составе, и дельта-пакет содержит только эту библиотеку.
Разумеется, дельта требует именно той уже установленной версии, под которую строилась (хотя можно и несколько последовательных дельт применить — не знаю, есть ли это вживую).
Ф>В третьих, MV VS сильно интегрируется в систему: в системные каталоги копируются новые библиотеки (VC++ Redistributable, например), ставится MS Build, регистрируются COM-компоненты. Твой XCode и рядом не стоял по этому параметру.
А проверить, куда он что установил, можно? Вот я, например, вижу
Считаем, это аналог system32. Но — под управлением пакетного менеджера.
(правда, это не мак. я про мак тут нигде ничего не говорю)
Ф>В четвёртых, если что-то пойдёт не так во время установки на макоси (отсутствует какая-нибудь либа, например), то уже ничего не исправить. Наверное, поэтому он в систему и не интегрируется. Под Windows всё иначе: во время установки создаётся VSS Snapshot, и ты в любой момент можешь вернуться к состоянию до установки. В мире *nix вообще со снэпшотами очень грустно: хочешь БД забэкапить в консистентном состоянии — останавливай, а потом бэкапь. Нехорошо.
Это от БД зависит.
Ф>17 Gb — это какой-нибудь Starcraft2. Игрушки бывают и больше. Ф>Что любопытно, Blizzard не заставляет меня выкачитвать по 17 Gb каждую неделю — в абсолютном большинстве апдэйты незаметные, которые выкачиваются почти мгновенно. Ставятся столь же быстро как и выкачиваются.
Здравствуйте, ·, Вы писали:
V>>Ты только что сказал о системах, написанных на джаве. А я тебе возразил, что крупнейшие биржи исключительно нейтивные. ·>Погоди. Ты начал с того, что "В сфере упомянутого тобою HFT джава уступает дотнету сильно, примерно вдвое-трое по latency". Т.е. на самом деле ты хотел сказать джава уступает не дотнету, а нейтиву?
Про задержки я тебе уже отвечал в цифрах: джава уступает нейтиву в двадцать-тридцать раз, дотнету в два-три раза.
А тут уже шла речь о последних твоих утверждениях:
Так это реализация fix протокола, а не система. Давай что-то типа биржи или Order Management System, Smart Order Router и т.п.
·>Ну с этим-то я не спорю.
Э, нет. Процитированное тобой в переводе на русский звучит примерно так: "заколебетесь на нейтиве писать бизнес-логику, а вот мы джаве рулеззз!!!". Поверь мне, при отлаженной низлежащей инфраструктуре бизнес-логика на С++ выходит даже намного проще, чем на Джаве. Я бы сказал, во многие разы проще (выразительней, больше гибкости м/у ссылочными и обычными значениями и т.д.).
Джава проще изкаробки с 0-ля, разве что, потому что уже идёт с приличной инфраструктурой. Но фирмы с 0-ля в топах не обитают.
V>>А если кто-то на жабке пишет себе клиента к этим биржам, то что ж... примите мои соболезнования... V>>Дышать выхлопом от конкурентов — дело сугубо добровольное. ·>Ява даёт другие конкурентные преимущества.
Джава даёт преимущества только на ровном месте, повторюсь. Вот собрались три студента на Джаве и у них сходу преимущество перед другими тремя студентами на С++. Но уже через года три ситуация выравнивается, а еще через три года джависты далеко позади. Потому что возможности инструмента крайне ограниченные. Вообще ничего нельзя на ём сделать, связан по рукам и ногам. ))
V>>Если грамотно сделать инфраструктуру и юзать надежные либы С++, то поддерживать "живой" плюсовый код, т.е. постоянно изменяющийся наподобие скриптового, — можно и нужно. Т.е. захардкодили некую стратегию — компильнули, подключили либу в систему. Надо что-то изменить — опять подправили, компильнули и зарегали вместо предыдущей. V>>Я не спорю, что приседаний может быть чуть больше, особенно на эта отладки такой инфраструктуры. Но это же, во-первых, одноразовая работа, а во-вторых, оно является тем самым ноу-хау, которое даёт преимущество перед конкурентами, сидящими на скриптах и джаве. V>>И да, в дотнетной версии слой сетки/потоков и синхронизации нейтивный, верно! ·>Кстати, Rapid Addition FIX engine — тоже афаир pure-java. Сравнивали? Насколько медленнее нативного?
Rapid сливает нам примерно двое, B2BITS примерно в полтора раза.
V>>Все так делают, мы что, должны сливать всем? )) ·>Клёво, конечно. Но причём тут сабж?
При том, что на дотнете всё еще удобно писать ту самую управляющую бизнес-логику.
Кароч, такая же песочница, как и Джава.
·>Суть в том что на чистой java пишут реализации LL-систем (больших! а не просто тонкая обёртка над нативной либой). В .net такого никогда не было и вряд ли будет.
Ну, насколько я в курсе, коллега IT именно занят написанием больших систем для банков. Тонкая обертка над нейтивной либой — это просто наш продукт, т.е., действительно малая часть, просто эта часть очень критичная к быстродействию. И пока у нас клиентов на на дотнет-либы хватает, позволю себе с тобой не согласится.
·>synchronized в принципе плохо работает в случае жестких требований LL. Т.к. треды засыпают и могут долго просыпаться. Тут не важно нейтив или нет.
Давай я не буду эту тему обсуждать. Я могу рассказать, что тут можно сделать, когда у тебя развязаны руки и тебе доступны все ср-ва ОС. Насчет "долго просыпаться" — не так уж и долго, порядка половины микросекунды на виндах, например. При том, что у того же Rapid по ссылке данные в р-не 12 мкс, т.е., разбудить один поток — это не дорого. Намного дороже там будет потерять прогретый кеш, вот это ж-па полная. Ну и вообще мелочей много и каждая мелочь на что-то влияет, но половина из них, таки, ноу-хау.
V>>ГЦ и так постоянно работает, о чём ты? ·>ГЦ-цикл сборки я имею в виду, stop-the-world событие конкретно.
Ну, если рабочие потоки не блокируются во время сборки, то и обсуждать нечего.
ГЦ опасен только событиями полной сборки.
V>>·>Вот с zing такой проблемы нет. Конечно, количество мусора минимизируется, но даже если он и случается несколько раз в день — ничего страшного. V>>Ну вот аналогично, если не плодить объекты первого поколения, то дотнетный сервак может несколько дней жить без полной пересборки мусора. ·>Но если она таки происходит — latency spike — и звонок от клиента...
Здравствуйте, Cyberax, Вы писали:
C>>>Для SSH совершенно не нужно иметь PKI. V>>Для SSL тоже НЕ НУЖНО, но МОЖНО, потому что всего одна галочка определяет — будет ли производиться верификация подписи ключа или нет. C>Мимо. Для SSL обязательна проверка сертификатов. Её результат можно игнорировать, но она зашита в протокол.
Т.е., ты так и не последовал совету ознакомиться с вопросом? )) RFC 7250, поищи по "server_certificate_type"
Ну или вот в секции 5.3. Combined Usage of Raw Public Keys and X.509 Certificates — виден пример выбора из: обмена сертификатами или просто публичными ключами БЕЗ сертификатов.
C>Даже при использовании TLS-PSK всё равно происходит проверка сертификатов.
И что должно было усилить твоё "даже"? ))
TLS — это и есть более новые версии SSL. Ну вот так повелось, что всё вместе называют SSL, хотя полтора десятка лет используется TLS, на самом деле.
PSK вообще к делу не относится, бо это вопрос доставки публичных ключей и к теме сертифицирования самих ключей более чем ортогонально.
C>Для SSH проверка сертификатов не нужна. Собственно, сертификатов в большинстве случаев нет и клиенты просто хранят отпечаток публичного ключа.
А ну ясно. Рядом я уже описал ценность подобных аргументов:
ты выдаёшь дефолтные настройки open SSH за характеристики целого стандарта.
V>>Кароч, SSL и SSH используют абсолютно идентичную инфраструктуру X.509, поэтому глупо говорить, что вот там нужно, а вот там нет. Это только от непонимания можно заявлять. )) V>>Еще раз для тех, кто в танке. Инфраструктура ключей ИДЕНТИЧНА происходящему в SSL. V>>Медитировать над этим до просветления. C>Я уже предложил. $1k на бочку и нейтральный арбитр.
Ну ты формализируй очередное своё предложение, для начала.
Потому что по первому абзацу ты УЖЕ проиграл, гони мне $1k.
Арбитром выступает RFC 7250 и любой коллега, способный его прочитать и понять.
C>>>(да, я писал реализацию парсера для X509 с нуля) V>>Парсер ЧЕГО? C>X509-сертификатов, включая разбор ASN.
Во-первых, ASN.1.
V>>Я так предполагаю, что для языка Rust (или на чём ты там писал?) таких кодогенераторов пока не существует, верно? Получается, что ты портировал некий готовый парсер, сгенеренный для другого языка и от непонимания истории происхождения того кода только что прилюдно спалился. C>Нет. Я руками писал его с нуля, с разбором и валидацией всего.
Брехня опять. Я слишком хорошо знаком с ASN.1.
Там было бы 0.1% работы над X509 и 99.9% над собственно ASN.1.
Второе делать ручками архиглупо — там на 5 мин натравить компилятор ASN.1 на открытое описание пакета — и ву а ля, забирай готовые поля.
Кароч, не добивай себя. ))
Если ты ДЕЙСТВИТЕЛЬНО делал это руками, то с тобой много чего не так.
Ну а если честно, я в эту версию не верю, ес-но, потому что слишком уж много торчит косяков:
— "парсер" X509 (ы-ы-ы)
— ASN (без .1)
— c 0-ля валидация потока ASN (нихера себе! там валидация зависит даже от оптимизации бинарного представления енумов, проводимых компилятором в выбранном профиле кодирования! Их три самых популярных на сегодня и содержимое битового потока всех трёх несовместимо)
— не ответил, по какому именно профилю шло кодирование ASN.1... панимаешь, если это хотя бы раз в жизни сделать ручками, такое запомнится навсегда и уж намного яснее, чем подробности некоего тривиального протокола SSL или SSH. А сейчас ты даже не сможешь быстро поиском по гуглу достоверно узнать название принятого в индустрии профиля кодирования X.509 через ASN.1.
Здравствуйте, Cyberax, Вы писали:
C>>>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509. V>>Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". V>- SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание. V>>Дерзай! )) C>Сойдёт. $1k на бочку.
Ну ты СВОЁ утверждение выдели целиком, наконец. А то ты даже скопировать не смог так, чтобы утверждения твоей стороны не смотрелись как мои.
V>>Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной. C>Нет, она не построено идентично. В частности, нет аналога CN в X509.
О! Уже прогресс. Раньше ты утверждал, что в SSH вообще никаких сертификатов. ))
SSH Transport Layer Protocol
RFC 4251 dictates two alternative trust models that can be used:
1. The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain.
2. The host name-to-key association is certified by a trusted Certification Authority (CA). The client knows only the CA root key and can verify the validity of all host keys certified by accepted CAs. This alternative eases the maintenance problem, because ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible.
Здравствуйте, vdimas, Вы писали:
V>>>Ты только что сказал о системах, написанных на джаве. А я тебе возразил, что крупнейшие биржи исключительно нейтивные. V>·>Погоди. Ты начал с того, что "В сфере упомянутого тобою HFT джава уступает дотнету сильно, примерно вдвое-трое по latency". Т.е. на самом деле ты хотел сказать джава уступает не дотнету, а нейтиву? V>Про задержки я тебе уже отвечал в цифрах: джава уступает нейтиву в двадцать-тридцать раз, дотнету в два-три раза.
Погоди. Ты объясни что конкретно сранвивается. Приведённые твои ссылки на fix engines как я понял это по сути одна нативная библиотека с тремя публичными api c++, java, c#. Т.е. ты сравниваешь нативную либу с этой же либой+java wrapper. Так что-ли?
V>А тут уже шла речь о последних твоих утверждениях: V>
V>Так это реализация fix протокола, а не система. Давай что-то типа биржи или Order Management System, Smart Order Router и т.п.
Ну потому что я хочу сравнивать java vs dotnet, а не native+java vs native.
V>·>Ну с этим-то я не спорю. V>Э, нет. Процитированное тобой в переводе на русский звучит примерно так: "заколебетесь на нейтиве писать бизнес-логику, а вот мы джаве рулеззз!!!". Поверь мне, при отлаженной низлежащей инфраструктуре бизнес-логика на С++ выходит даже намного проще, чем на Джаве. Я бы сказал, во многие разы проще (выразительней, больше гибкости м/у ссылочными и обычными значениями и т.д.). V>Джава проще изкаробки с 0-ля, разве что, потому что уже идёт с приличной инфраструктурой. Но фирмы с 0-ля в топах не обитают.
Это тема другого обсуждения. Вначале давай разберёмся с сабжем в области HFT.
V>Джава даёт преимущества только на ровном месте, повторюсь. Вот собрались три студента на Джаве и у них сходу преимущество перед другими тремя студентами на С++. Но уже через года три ситуация выравнивается, а еще через три года джависты далеко позади. Потому что возможности инструмента крайне ограниченные.
LMAX exchange уже 6 лет, пока вроде вполне конкурентны.
V>Вообще ничего нельзя на ём сделать, связан по рукам и ногам. ))
Что именно нельзя сделать? По сравнению с .net — она просто всемогутер.
V>·>Кстати, Rapid Addition FIX engine — тоже афаир pure-java. Сравнивали? Насколько медленнее нативного? V>Rapid сливает нам примерно двое, B2BITS примерно в полтора раза.
Вот полтора-два раза уже более похожий на правду результат, а не твои "двадцать-тридцать".
А не подскажешь удалось ли кому сделать вменяемый pure C# fix engine?
V>>>Все так делают, мы что, должны сливать всем? )) V>·>Клёво, конечно. Но причём тут сабж? V>При том, что на дотнете всё еще удобно писать ту самую управляющую бизнес-логику. V>Кароч, такая же песочница, как и Джава.
А ещё удобнее писать всё на одном языке. А не думать где там чё и куда можно рыбу заворачивать.
V>·>Суть в том что на чистой java пишут реализации LL-систем (больших! а не просто тонкая обёртка над нативной либой). В .net такого никогда не было и вряд ли будет. V>Ну, насколько я в курсе, коллега IT именно занят написанием больших систем для банков. Тонкая обертка над нейтивной либой — это просто наш продукт, т.е., действительно малая часть, просто эта часть очень критичная к быстродействию. И пока у нас клиентов на на дотнет-либы хватает, позволю себе с тобой не согласится.
Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу. На c# (без native) — невозможно.
V>·>synchronized в принципе плохо работает в случае жестких требований LL. Т.к. треды засыпают и могут долго просыпаться. Тут не важно нейтив или нет. V>Давай я не буду эту тему обсуждать. Я могу рассказать, что тут можно сделать, когда у тебя развязаны руки и тебе доступны все ср-ва ОС.
Какие именно необходимые средства недоступны в java? Понятное дело, что всякие системные штуки типа set cpu affinity из явы недоступны, но они там и не нужны, т.к. это рулится во время запуска самой jvm. Да, возможно ещё потребуется всякие тонкие настройки операционки и железа, типа irq balance и прочей магии. Но это всё инфраструктура, рулится и без явы, а какими-нибудь bash-скриптами и всяким /proc /etc.
V>Насчет "долго просыпаться" — не так уж и долго, порядка половины микросекунды на виндах, например. При том, что у того же Rapid по ссылке данные в р-не 12 мкс, т.е., разбудить один поток — это не дорого. Намного дороже там будет потерять прогретый кеш, вот это ж-па полная. Ну и вообще мелочей много и каждая мелочь на что-то влияет, но половина из них, таки, ноу-хау.
Для LL имеет значение худший случай — тот самый длинный хвост на гисторамме в области 99.99%. Полмикросекунды это средний (или даже лучший) случай. Под виндой пробуждение потока ВНЕЗАПНО может занять десятки, сотни миллисекунд, если карты плохо лягут.
V>>>ГЦ и так постоянно работает, о чём ты? V>·>ГЦ-цикл сборки я имею в виду, stop-the-world событие конкретно. V>Ну, если рабочие потоки не блокируются во время сборки, то и обсуждать нечего. V>ГЦ опасен только событиями полной сборки.
ГЦ в C#, в zing — не опасен.
V>>>·>Вот с zing такой проблемы нет. Конечно, количество мусора минимизируется, но даже если он и случается несколько раз в день — ничего страшного. V>>>Ну вот аналогично, если не плодить объекты первого поколения, то дотнетный сервак может несколько дней жить без полной пересборки мусора. V>·>Но если она таки происходит — latency spike — и звонок от клиента... V>Тут можно говорить лишь о длительностях пауз. V>Если для Джавы это были десятки секунд,
Это скорее всего на допотопном gc или неправильно настроенном.
V>то для дотнета речь может идти о десятках ms раз в сутки. V>https://msdn.microsoft.com/library/system.runtime.gclatencymode(v=vs.110).aspx V>Речь о т.н. "серверном GC", начиная с дотнета 4.5.
В zing задержка более 10ms — это production issue, сразу создаётся тикет в саппорт Azul. Если интересно могу рассказать байку о последнем баге, дававшем жутчайшие тормоза вполть до 100мс на одном из хостов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу.
Они будут иметь намного больший объём кода, и требовать намного больших трудозатрат (нарезание буферов на структуры, GC-free, etc, etc).
Только дело тут не в Native vs JVM, а в том что Java как язык сильно ограничен.
·>На c# (без native) — невозможно.
Aside: In the Java world there is a commercial Pauseless Garbage Collector available from Azul Systems. It uses a patented technique to offer “Predictable, consistent garbage collection (GC) behavior” and “Predictable, consistent application response times”, but there doesn’t seem to be anything like that in the .NET space.
конечно, это статья двухлетней давности, может что-то и поменялось с тех пор... но я почему-то уверен, что нет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу. EP>Они будут иметь намного больший объём кода, и требовать намного больших трудозатрат (нарезание буферов на структуры, GC-free, etc, etc). EP>Только дело тут не в Native vs JVM, а в том что Java как язык сильно ограничен.
Сильно "ограниченный" язык даёт возможность создать вменяемую IDE и уменьшить сложность кода. Да и часто лучше иметь много простого кода, чем немного сложного.
А вообще, надо говорить о Java как платформе, а там есть и более другие, "неограниченные" языки типа scala/kotlin/groovy/ceylon.
EP>·>На c# (без native) — невозможно. EP>Почему?
Тормозной он и корявый. Плюс win-only (а mono ещё хуже).
А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>Кстати, я же тебе посылал этот линк: http://mattwarren.org/2014/06/18/measuring-the-impact-of-the-net-garbage-collector/ S>·>Паузы бывают до 4 СЕКУНД!!! S> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S> В то время, когда таски бороздят все пространство ...
Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Кстати, я же тебе посылал этот линк: http://mattwarren.org/2014/06/18/measuring-the-impact-of-the-net-garbage-collector/ S>>·>Паузы бывают до 4 СЕКУНД!!! S>> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S>> В то время, когда таски бороздят все пространство ... ·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх.
Вот именно, что там намного сложнее чем Thread. Там свой планировщик, CancellationToken.
И работа идет с пулом потоков а не с массивом processingThreads[i] = new Thread(()
Поверь разница велика.
А кстати в .Net Core для библиотек Thread просто нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх. S> Вот именно, что там намного сложнее чем Thread. Там свой планировщик, CancellationToken. S> И работа идет с пулом потоков а не с массивом processingThreads[i] = new Thread(() S> Поверь разница велика.
Не понял. Ты хочешь скзать, что с tasks код "while(true)..." заработает быстрее и будет показывать лучшее время gc? За счёт чего?
S> А кстати в .Net Core для библиотек Thread просто нет.
?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IT, Вы писали:
IT>У MS была офигительно эффективная джава-машина и Sun сделал всё, чтобы убрать её с рынка не честным, конкурентным путём, а задолбав судебными исками. В результате появился .net, а джавка в конце концов стала по настоящему открытой, т.к. деваться было уже некуда.
А Вы сами с MS JVM имели дело? Я имел. Это было редкостное дерьмо. В том числе и в отношении производительности. А судебные иски были вполне оправданными, иначе бы MS bх не проиграла. К счастью. Иначе мы бы имели очередную вариацию на тему VB. Судя по всему, VB для MS — как автомат Калалашникова для советской промышленности в известном анекдоте.
Здравствуйте, ·, Вы писали:
EP>>·>Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу. EP>>Они будут иметь намного больший объём кода, и требовать намного больших трудозатрат (нарезание буферов на структуры, GC-free, etc, etc). EP>>Только дело тут не в Native vs JVM, а в том что Java как язык сильно ограничен. ·>Сильно "ограниченный" язык даёт возможность создать вменяемую IDE и уменьшить сложность кода. Да и часто лучше иметь много простого кода, чем немного сложного.
Нарезание буферов вручную на структуры это не простой код, при этом структуры встроенные в язык (например как в древнем C) — это не сложно, а наоборот намного проще.
Так что получается не много простого кода VS немного сложного, а много сложного VS немного простого
·>А вообще, надо говорить о Java как платформе, а там есть и более другие, "неограниченные" языки типа scala/kotlin/groovy/ceylon.
В данном контексте речь про ограниченность в плане производительного кода, а не количества фич.
И да — я же говорю что речь не про Native vs JVM, на JVM таки может быть достаточно быстрый код.
EP>>·>На c# (без native) — невозможно. EP>>Почему? ·>Тормозной он
В чём конкретно это выражается?
·>и корявый.
Получше чем Java, ИМХО — но речь-то совсем не об этом.
·>Плюс win-only
Да, но речь же о какой-то принципиальной невозможности. Или хочешь сказать что Win-only в данном контексте и есть невозможность?
·>А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе?
Не знаю отсутствует или нет, но даже если отсутствует — то объяснений может быть множество.
Вон ту же Java туда пытаются затолкнуть, хотя это и стоит титанических усилий.
Здравствуйте, ·, Вы писали:
S>>·>Кстати, я же тебе посылал этот линк: http://mattwarren.org/2014/06/18/measuring-the-impact-of-the-net-garbage-collector/ S>>·>Паузы бывают до 4 СЕКУНД!!! S>> Кстати уже как то непривычно смотреть на new Thread. Это уже деприкейтед. S>> В то время, когда таски бороздят все пространство ... ·>Оно не деприкейтед. Надо же понимать, что все эти ваши таски — лишь более удобная в каких-то ситуациях обёртка поверх этих самых new Thread. Для измерения производительности честнее тестировать низкоуровневые API, а не ещё более непредсказуемые обёртки-мусорогенераторы поверх.
А что смешного, Sinix? Вот в исходниках тот самый new Thread: https://referencesource.microsoft.com/#mscorlib/system/threading/Tasks/ThreadPoolTaskScheduler.cs,60
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Сильно "ограниченный" язык даёт возможность создать вменяемую IDE и уменьшить сложность кода. Да и часто лучше иметь много простого кода, чем немного сложного. EP>Нарезание буферов вручную на структуры это не простой код, при этом структуры встроенные в язык (например как в древнем C) — это не сложно, а наоборот намного проще. EP>Так что получается не много простого кода VS немного сложного, а много сложного VS немного простого
Такого сложного, специально вылизанного кода довольно мало, только в каких-то нескольких важных местах, думаю меньше процента от всего объёма исходников. В том же С/С++/C# подобные части кода тоже будут не совсем классическим кодом, а аккуратно прилизанным и wtf-ным. Заоптимизированный вусмерть код везде выглядит одинаково плохо.
EP>>>·>На c# (без native) — невозможно. EP>>>Почему? EP>·>Тормозной он EP>В чём конкретно это выражается?
Ссылку на отстойность gc я уже тут приводил. Плюс JIT, C2 в java гораздо более вылизан, очень много человеко-лет вложено. .net всё время находится в догоняющих или уже просто отставшим, у микрософта другие приоритеты, в своей нише ентерпрайз, UI, облаков и веба; ему это уже не надо.
EP>·>и корявый. EP>Получше чем Java, ИМХО — но речь-то совсем не об этом.
Ту хум хау. Корявость выражается ещё и в том, что нет открытости платформы, когда можно копаться где угодно, на любом уровне — от компилятора языка, оптимизаторов, вплоть до ядра операционки и драйверов в поиске и решении проблем с производительностью.
EP>·>Плюс win-only EP>Да, но речь же о какой-то принципиальной невозможности. Или хочешь сказать что Win-only в данном контексте и есть невозможность?
Да. Скажем, где там у вас hardware networking timestamping? Или нормальная поддержка высокопроизводительного железа типа solarflare?
EP>·>А если ты считаешь что это всё неправда и c# — торт, то как ты объяснишь полное наличие отстутствия HFT систем на шарпе? EP>Не знаю отсутствует или нет, но даже если отсутствует — то объяснений может быть множество. EP>Вон ту же Java туда пытаются затолкнуть, хотя это и стоит титанических усилий.
Уж больше 5 лет назад как затолкнули.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Про задержки я тебе уже отвечал в цифрах: джава уступает нейтиву в двадцать-тридцать раз, дотнету в два-три раза. ·>Погоди. Ты объясни что конкретно сранвивается. Приведённые твои ссылки на fix engines как я понял это по сути одна нативная библиотека с тремя публичными api c++, java, c#. Т.е. ты сравниваешь нативную либу с этой же либой+java wrapper. Так что-ли?
Не так. Джава чистая, в дотнете достоверно сетевой слой и многопоточность/синхронизация нейтивные. Больше сказать не могу. ))
V>>А тут уже шла речь о последних твоих утверждениях: V>>
V>>Так это реализация fix протокола, а не система. Давай что-то типа биржи или Order Management System, Smart Order Router и т.п.
·>Ну потому что я хочу сравнивать java vs dotnet, а не native+java vs native.
Ну так и отвечаю последовательно: крупные биржи нейтивные (торговые их движки).
А обслуживающие утилиты могут быть писаны на чем угодно — нейтивные, скриптовые, дотнетные и джавовские.
Причем, в последние годы всё более популярным становится веб-интерфейс (интранет) и обе управляемых среды всё больше отдают долю скриптовым решениям даже на внутренне-утилитном поприще.
V>>Джава даёт преимущества только на ровном месте, повторюсь. Вот собрались три студента на Джаве и у них сходу преимущество перед другими тремя студентами на С++. Но уже через года три ситуация выравнивается, а еще через три года джависты далеко позади. Потому что возможности инструмента крайне ограниченные. ·>LMAX exchange уже 6 лет, пока вроде вполне конкурентны.
Что, прямо-таки торговый движок на джаве?
Зашел к ним на сайт: https://www.lmax.com
Там жесть...
Вот сам зайди, плиз.
V>>Вообще ничего нельзя на ём сделать, связан по рукам и ногам. )) ·>Что именно нельзя сделать? По сравнению с .net — она просто всемогутер.
Ну это можно говорить только от предвзятости к дотнету. Там где в Джава, например, надо писать сложные JNI и прочие обертки, причем, падучие, сложные в отладке и которые легко гадят в память процесса (бегают по памяти), там в дотнете для обращения к нейтивным либам достаточно декларативно прописать Interop.
Именно поэтому я порой для прототипирования юзаю дотнет, а не джаву, что всегда могу подёргать из дотнета практически любые нейтивные либы или АПИ ОС фактически даром.
V>>·>Кстати, Rapid Addition FIX engine — тоже афаир pure-java. Сравнивали? Насколько медленнее нативного? V>>Rapid сливает нам примерно двое, B2BITS примерно в полтора раза. ·>Вот полтора-два раза уже более похожий на правду результат, а не твои "двадцать-тридцать".
Это их нейтивный вариант сливает в полтора раза. ))
А наш джавовский сливает нашему нейтивному в двадцать-тридцать раз, а их сливает еще больше.
·>А не подскажешь удалось ли кому сделать вменяемый pure C# fix engine?
Удавалось, а смысл?
Дело в том, что опенсорсные джавовские и дотнетные движки не так уж сильно отстают от коммерческих, в отличие от нейтивного варианта, где опенсорс сливает до 10-16 раз.
V>>>>Все так делают, мы что, должны сливать всем? )) V>>·>Клёво, конечно. Но причём тут сабж? V>>При том, что на дотнете всё еще удобно писать ту самую управляющую бизнес-логику. V>>Кароч, такая же песочница, как и Джава. ·>А ещё удобнее писать всё на одном языке. А не думать где там чё и куда можно рыбу заворачивать.
На джаве это будет минимум два языка — еще же море XML!
V>>·>Суть в том что на чистой java пишут реализации LL-систем (больших! а не просто тонкая обёртка над нативной либой). В .net такого никогда не было и вряд ли будет. V>>Ну, насколько я в курсе, коллега IT именно занят написанием больших систем для банков. Тонкая обертка над нейтивной либой — это просто наш продукт, т.е., действительно малая часть, просто эта часть очень критичная к быстродействию. И пока у нас клиентов на на дотнет-либы хватает, позволю себе с тобой не согласится. ·>Вот что я и пытаюсь доказать. На java (без native) возможно писать критичные к быстродействию системы, притом они только немного уступают по цифрам нативу.
Уступают в 20-30 раз.
·>На c# (без native) — невозможно.
Возможно и они не уступают джавовским.
Ну реально, с каких это пор джава стала быстрее дотнета в сфере latency?
Или ты сравниваешь современную джаву с дотнетом от 2003-го года?
Дотнет сходу вышел шустрее джавы и все года задавал ей планку. Или я пропустил какую-то важную новость вот буквально последнего года, что в джава придумали хороший оптимизатор? ))
Вот в дотнете хороший уже есть — это виндовый Магазин, где дотнетные приложухи сурово оптимизируются в нейтив. Никакой JIT не даст сравнимый уровень оптимизации, ес-но, это всё показывает хоть какие-то результаты лишь на стадии офлайн компиляции.
V>>Давай я не буду эту тему обсуждать. Я могу рассказать, что тут можно сделать, когда у тебя развязаны руки и тебе доступны все ср-ва ОС. ·>Какие именно необходимые средства недоступны в java?
Тонкое управление барьерами памяти, atomic-стратегиями чтения, локальное управление выделением памяти, заточенное под конкретный сценарий, дешевый lock-free и куча еще всего. Например, FIX-сообщение в джава — это развесистый граф объектов с кучей ссылок, а в нейтиве — сплошная область памяти.
·>Понятное дело, что всякие системные штуки типа set cpu affinity из явы недоступны, но они там и не нужны
Нужны, до 2-4-х раз latency натюнить можно (и нужно).
·>т.к. это рулится во время запуска самой jvm.
Ты не можешь гарантировать, что один и тот же джавовский поток будет исполняться на одном и том же потоке ОС всё время своей жизни. Для дотнета та же засада, кста, поэтому, управлять cpu affinity можно только для потоков, создаваемых и управляемых из нейтива. Вот почему, собсно, эта область программы тоже должна жить в нейтиве.
·>Да, возможно ещё потребуется всякие тонкие настройки операционки и железа, типа irq balance и прочей магии. Но это всё инфраструктура, рулится и без явы, а какими-нибудь bash-скриптами и всяким /proc /etc.
Ну так ты мне ссылку на официальные цифры твоего Rapid для их джава-движка дай, чтобы стало понятно, в каких пределах это влияет на результат.
·>Для LL имеет значение худший случай — тот самый длинный хвост на гисторамме в области 99.99%. Полмикросекунды это средний (или даже лучший) случай. Под виндой пробуждение потока ВНЕЗАПНО может занять десятки, сотни миллисекунд, если карты плохо лягут.
Не только под виндой, под любой многозадачной ОС. Под ними даже не спящий поток может быть резко приостановлен на относительно долго.
Но по ссылкам, данным мною, кста, помимо самих цифр latency есть графики РАЗБРОСА значений. Просто посмотри на них и сравни. У хороших движков разброс минимален. Можно сказать, что его и нет вовсе. С чудовищным разбросом результатов по Джава это сравнивать нельзя.
V>>>>ГЦ и так постоянно работает, о чём ты? V>>·>ГЦ-цикл сборки я имею в виду, stop-the-world событие конкретно. V>>Ну, если рабочие потоки не блокируются во время сборки, то и обсуждать нечего. V>>ГЦ опасен только событиями полной сборки. ·>ГЦ в C#, в zing — не опасен.
Почитал про zing — там никакой полной сборки. ))
Там просто очень много приседаний, чтобы размазать работу GC во времени, в итоге общая трудоёмкость сборки резко выше и в памяти могут долго находиться очень древние объекты, в итоге среднее быстредействие программ на zing заметно меньше. Т.е. это специфический GC, который лечит клиническую кривизну кода, когда обычные явовские движки уходят в своп на десятки секунд. Ну, блин, в дотнете и проблемы-то такой с момента выхода версии 4.5 нет.
V>>Тут можно говорить лишь о длительностях пауз. V>>Если для Джавы это были десятки секунд, ·>Это скорее всего на допотопном gc или неправильно настроенном.
Это нагрузки зависит, а не допотопности.
Если памяти каюк и сотни миллионов объектов на освобождение, то деваться некуда.
Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток.
Так вот, дотнетный движок легко справляется с 0-м поколением даже из "чужого" для объекта потока, а в джаве, похоже, такие объекты улетают в 1-е поколение, затем быстро упираемся в потолок и начинается сплошное GC. При том, что дотнетный тест может работать вечно без пауз — в фоне прекрасно всё чистится. Вот чтобы ты знал — для таких сценариев и нужен твой zing.
Далее. Отсутствие в Джаве value-типов делает среднюю джавовскую прогу намного развесистее в памяти, чем аналогичную на дотнете, где многое можно размещать по значению. Да, я в курсе про хот-спот и реальный эффект от него. Он мизерный, в сравнении с эффектом от продуманного разработчиком графа на value-types дотнета.
V>>то для дотнета речь может идти о десятках ms раз в сутки. V>>https://msdn.microsoft.com/library/system.runtime.gclatencymode(v=vs.110).aspx V>>Речь о т.н. "серверном GC", начиная с дотнета 4.5. ·>В zing задержка более 10ms — это production issue, сразу создаётся тикет в саппорт Azul. Если интересно могу рассказать байку о последнем баге, дававшем жутчайшие тормоза вполть до 100мс на одном из хостов.
Да я верю, спасибо за наводку, было интересно почитать про алгоритмы сборки мусора zing.
Это круто, согласен... Перерасход памяти, правда, черезчур (на т.н. "фантомные страницы") и слишком много жутко дорогих Access Violation (на каждый неверно помеченный объект). Собственно, на этом AV построен сам принцип его работы. Оригинально, чо! )) Я в очередной раз порадовался, что большую часть времени имею дело с нейтивом...
